Real-Time Fraud Prevention for Banking and Payment-as-a-Service Models

Konrad Krupiński

UniCredit

Head of Financial Crime Prevention

Digital channels and partner platforms have made it easier for banks to onboard customers, process payments and launch new services. They have also made the risk perimeter harder to see. A bank may remain accountable for a transaction even when much of the customer journey takes place inside a partner’s platform.

In that environment, fraud prevention cannot operate as a separate control function that reviews transactions after something suspicious has happened.

Konrad Krupinski, Head of Financial Crime Prevention at UniCredit in Poland, presented the operating approach used by a bank providing Banking-as-a-Service and Payment-as-a-Service solutions. The experience raises practical questions for any bank working through partners: who owns each control, what data must be shared, how should AML and fraud teams work together, and how early can the bank intervene?

From Direct Digital Banking to Partner Distribution

The business was originally designed as a digital bank. It had no physical branch network, customers completed onboarding through an app and Vodeno provided the supporting technology platform.

Following the pandemic, the business shifted its attention from acquiring customers directly to providing banking and payment capabilities through external platforms and financial institutions.

That shift changed the fraud exposure. Suspicious activity could originate inside the bank’s app, but it could just as easily begin on a marketplace, an e-commerce platform, a non-financial partner’s interface or a financial institution connected to local payment systems.

The bank still needed enough information to understand what was happening across the journey, even where the partner controlled the customer-facing channel.

Its activities covered three main business arrangements.

Through Banking as a Service, non-financial companies could embed banking products into their own platforms. The partner managed the brand, customer interface and first-line support. UniCredit provided the regulated banking services behind the proposition.

Under Payment as a Service, the bank worked with financial institutions that needed access to local payment infrastructure. These partners already had customers but did not necessarily have a local branch or the systems required to process payments in a particular market. The bank processed transactions, applied an additional layer of screening and performed its AML and fraud prevention responsibilities.

The third arrangement involved the purchase of receivables portfolios, including portfolios originated by e-commerce platforms. The partner collected and stored the information used for credit assessment, the bank provided the regulated service and Vodeno handled the technology.

The controls could not be identical in every case. Sometimes the bank had a direct relationship with the end customer. Elsewhere, it received payment instructions through another financial institution or assessed a portfolio using data collected by a partner.

What could remain consistent was the underlying discipline: clearly assigned responsibilities, access to relevant data, continuous monitoring and the ability to intervene without delay.

Why Separating AML and Fraud Prevention Creates Blind Spots

At UniCredit NV/SA, AML and fraud prevention were brought together within Financial Crime Prevention. In a partner-led digital business, the reason is practical.

Fraud and money laundering may form different parts of the same sequence. A single transaction rarely explains which one the bank is looking at. The answer depends on who initiated it, what happened before it and where the funds went next.

A customer may pass onboarding without raising concerns. Weeks or months later, their transaction activity may no longer match the profile they provided. External information may contradict their application, or the nature of the payments may be inconsistent with the expected use of the account.

Investigating that change requires more than a transaction alert. Analysts need access to onboarding records, monitoring results, previous investigations, external intelligence, decision rules and case history.

When AML and fraud teams work from separate data and separate queues, each sees only a fragment. The customer journey does not respect those organizational boundaries. Account creation, login, a change of personal details, the addition of a beneficiary, a transfer and an account recovery attempt may all belong to the same fraud scenario.

Fraud Signals Often Appear Before the Payment

The bank’s objective was to intervene before either the customer or the institution suffered a loss. This meant placing controls at several stages of the customer journey rather than concentrating them at the point of payment.

One of the main tools was device fingerprinting, which builds a digital profile of the device being used. In the case presented, ThreatMetrix was integrated into the bank’s app and into partner applications. According to the case data, the tool identified up to 98 percent of fraudulent attempts before they resulted in a loss.

The bank used device intelligence during onboarding, login, changes to personal information, account funding, credit applications and account recovery. Different activities triggered different rules and risk scenarios.

A successful login was not treated as proof that the legitimate customer was in control of the account. The surrounding details mattered.

Has the device been used before? When was the app installed? Has the phone number or time zone changed? Was the location consistent with the customer’s previous activity? Has the app disappeared from the original device? Was an account recovery process underway?

Seen separately, none of these events necessarily proves fraud. Seen together, they may provide enough evidence to stop the next action before a transfer is attempted.

Onboarding Works as a Chain of Checks

The onboarding process used several layers of verification.

It began with the device profile. The next steps depended on the country and could include local identity schemes, document verification and biometric controls.

Identity information was extracted from the document using optical character recognition. The document was checked through the device camera, and the customer’s face was compared with the photograph. The submitted information was then checked against external sources.

In Poland and Belgium, the bank had access to government databases. These connections allowed it to check in real time whether a document was registered, whether it had been reported stolen and whether the information matched official records. In Poland, the process also used the national identification number registry and passport database.

The results then passed into the AML and Anti-Fraud enterprise platform for the final decision and scoring, together with other verification results and checks, e.g: against sanction, PEP/RCA, adverse media, government or commercial databases plus identity and ID document verification. 

AI Extends the Rules, but Does Not Remove Human Judgment

At the time of the case, rules, rulesets and dedicated policies still formed the core of the bank’s fraud controls.

They determined which events required attention, how the risk score should change and whether an action should be approved, referred for review or blocked.

The bank was beginning to introduce more AI-based decisioning, but analysts remained involved. They reviewed uncertain cases, challenged model outputs and took responsibility where the evidence required professional judgment.

This matters because AI does not make the bank less accountable. Nor does it remove the need to investigate. It can help connect events, interpret context and reduce the amount of noise reaching analysts. The resulting decision still needs to be explainable and open to review.

If the operations team cannot understand why an onboarding application or transaction was rejected, the model becomes difficult to manage, regardless of its technical performance.

How an Account Takeover Develops

One case involved a money mule account that was later taken over by a fraudster. The account remained in the original customer’s name, but someone else gained effective control (The UBO is a different person than the one which data bank has on file)

The events unfolded in sequence. An account was opened and accessed for the first time. The primary phone number changed. The app was removed from the original device, and access from that device was closed. An account recovery process began, the app appeared on a new phone and the time zone changed.

Within a short period, the customer appeared to have moved from Europe to Asia.

Any one of these actions might have been legitimate. Together, they told a different story. The accumulated signals produced a negative risk score, and further activity was blocked automatically.

The fraudster had valid credentials, but the device and behavioral evidence did not fit the customer’s history.

Had the bank waited for a suspicious transfer, the money might already have been gone. By monitoring the sequence, it was able to act during the takeover itself.

Reporting Is Part of Fraud Prevention, Not Just Oversight

Fraud reporting helped the bank understand where its controls and operations were under pressure.

Alerts were analyzed by brand, market and stage of the customer journey.

Poland processed a substantial share of the transactions and generated 61 percent of the system’s payment-related alerts. That information could be used to investigate whether the volume reflected genuine exposure, market activity, overly sensitive rules or a combination of the three. It also informed staffing and prioritization.

Alert volume on its own is a weak measure. Too many alerts can bury analysts in false positives. Too few can create misplaced confidence.

A useful reporting framework therefore needs to track the quality and outcome of alerts, not just the total. The bank should know which rules generate them, how many lead to confirmed cases, how long reviews take and what effect the controls have on legitimate customers.

Five Questions for Banks and Fintech Companies

Banks and fintech companies working through digital or partner channels should examine five areas.

Where do the first warning signs appear?

A control framework that begins at the payment stage may miss a phone number change, a new beneficiary, a fresh device or an account recovery attempt. These events often provide the first indication that control of the account is shifting.

Do AML and fraud teams see the same customer history?

If onboarding, transaction monitoring and investigations sit in different systems, the risk profile may be updated too late. The problem becomes more serious when a partner controls part of the customer journey.

Who is responsible for each decision?

A BaaS or payment-services partner may own the interface, brand and customer communication. The bank still remains responsible for regulated services, monitoring and compliance within its role. Contracts need to define that division, but operating procedures must make it work in practice.

Can the bank act before funds move?

Blocking rules are only one part of the answer. Early intervention also depends on real-time data, connected systems, clear escalation routes and analysts able to review difficult cases.

Can AI decisions be challenged and explained?

More complex models place greater demands on data quality, oversight and accountability. If nobody owns the outcome, or if analysts cannot understand why the model acted, the technology creates a new control problem instead of solving the existing one.

Real-time fraud prevention is moving closer to the start of the customer journey. The payment may be the moment when the loss becomes visible, but it is rarely where the fraud began.

Banks that can connect the events leading up to that payment have more time to act. Those that cannot are left investigating the money after it has moved.