Payment Screening: How It Works and What It Misses

Payment screening answers one question before money moves: may the institution transact with this party? In this article, we cover how payment screening works, how it differs from transaction monitoring and fraud screening, what list checks miss in instant payments and lending, and which device and session signals help close that gap.

What is payment screening?

Payment screening is the check a financial institution runs on a payment before it executes. The payer, the payee, their banks and other details in the payment message are compared against sanctions lists, PEP (Politically Exposed Person) data and internal watchlists. A potential match holds the payment for review; a confirmed match means it is blocked or rejected.

Payment screening is usually viewed as a sanctions control, and the obligations behind it are strict: OFAC regulations apply to payments of any amount, and EU providers of euro instant transfers must screen their customers against EU sanctions lists at least daily.

For digital lenders, that framing misses a different problem. A loan disbursed to a mule account, or a payout requested from a session the borrower does not control, passes sanctions screening because no party on it is listed. Lists show whether the institution may make the payment; they cannot show whether the payment is what it appears to be.

How the payment screening process works

The process runs in the short window between a payment order and its execution, whether the payment is a domestic transfer, a cross-border wire or a loan disbursement.

1. Extracting the data from the payment message

The screening engine reads the fields that identify the parties: names, addresses, account identifiers, bank identifiers, country codes and free-text payment details. Free text matters, because a sanctioned party can appear in a remittance note rather than a name field.

2. Matching against sanctions lists and watchlists

Those fields are compared against the lists the institution is bound by – for example OFAC, EU, UN and UK sanctions lists – plus PEP data and internal watchlists. Matching is fuzzy by design, so it catches transliterations, misspellings and reordered names. The same design is also where false positives come from.

3. Reviewing the alert and deciding

A potential match holds the payment. An analyst compares secondary identifiers such as date of birth, nationality or address, then releases the payment, rejects it, or freezes the funds and reports. Amount does not change the obligation: OFAC states that there is no minimum or maximum amount subject to its regulations.

Why timing defines payment screening

Screening happens before funds move. That is what separates it from transaction monitoring, which looks at activity after execution. Once a transfer has settled, the institution can only investigate and try to recover.

Payment screening vs transaction monitoring vs fraud screening

The three controls can be run by the same teams and sometimes bought from the same vendor, which is why they get mixed up. All three answer different questions at different moments.

A gap in one of these controls is rarely covered by the other two. A sanctions engine typically has no view of the device, and a fraud model is not built to match names against an asset-freeze list.

Our guides to transaction fraud and payment fraud prevention cover the fraud side in more depth.

What list screening cannot catch

List screening asks whether a party appears on a list. In the fraud patterns below, no party does. The payment message is clean, and the risk sits in who initiated it, from what device, and where the money goes next.

Authorized push payment fraud

In authorized push payment (APP) fraud, the account holder is manipulated into sending the payment themselves. The payee is usually an ordinary account, not a listed entity, so sanctions screening clears it.

The scale is visible in regulator and industry data. In the EEA, losses on credit transfers reached €2.2 billion in 2024, and payment service users bore about 85% of them, mainly through scams that tricked them into initiating the transfers (EBA/ECB, 2025). In the UK, APP fraud losses rose 19% to £576.4 million in 2025 (UK Finance, 2026).

Mule accounts on the receiving end

Fraud proceeds often land in accounts held by real people, who then move the funds on. Screening the account holder's name returns nothing, because that person is not on any list. The patterns behind these accounts are covered in our article on bank drop fraud schemes.

Account takeover

When a fraudster takes over a genuine account, the payment comes from the right customer's account to a payee no list knows. The FBI reports that account takeover incidents handled through its Financial Fraud Kill Chain can involve 50 or more transactions to different recipient accounts at several banks at the same time (FBI IC3, 2025 report). How these takeovers start is covered in our guide to account takeover.

Payment screening for instant payments

Instant payments make these gaps harder to close: a transfer settles in seconds, so there is no window to hold it for review, and money that has reached a mule account can be hard to recover. Brazil, India and the EU show the same pattern – the controls act at the moment of payment or after it, while the warning signs appear earlier.

Brazil: Pix

Brazil's refund mechanism for Pix, the MED, lets a payer's bank block and return funds once fraud is suspected – after the transfer has gone through. The central bank itself notes that fraudsters quickly spread the money across other accounts, out of reach of the original mechanism (Banco Central do Brasil, Voto 105/2025). As our analysis of Pix fraud prevention shows, the signals that separate a scam from a genuine payment appear earlier, at onboarding and login: the Pix key pasted rather than typed, an active phone call during the transfer, or geolocation that does not match the IP.

India: UPI

In an April 2026 discussion paper, the RBI proposed a one-hour delay at the payer's bank for authorized push payments of ₹10,000 and above, including UPI transfers, with merchant payments exempt. As we argue in UPI fraud controls are too late, a delay still acts at the payment, after a call or message has already pressured the customer. Device consistency, session behaviour and telecom signals such as SIM swaps can show the risk building beforehand.

European Union: SEPA Instant

The EU's Instant Payments Regulation (EU) 2024/886 moved sanctions screening off the instant transfer: providers check their customers against EU lists at least daily and may not repeat the check on each payment (Article 5d), because per-transaction screening rejected too many legitimate transfers (recital 25). The check added at payment time, verification of payee, confirms only that the payee's name matches the account (Article 5c), so a mule account opened in a real name passes.

What the three markets have in common

In all three, the checks at or after the payment – lists, name matching, delays, refunds – see only part of the picture. The earlier signals sit in the device and session behind the transfer, which we cover in the next section.

Screening the session behind the payment

Fraud screening adds what the payment message does not carry: the device and session that produced it. A payment from a familiar device, in a session that behaves like the customer's earlier ones, carries different risk from the same payment sent from an emulator minutes after a password reset.

Device and behavioural signals at the moment of payment

The signals typically used fall into a few groups:

• Device linkage – whether the device has been seen with other accounts, applications or payees.

• Environment – emulators, virtual machines, and rooted or jailbroken devices.

• Connection – IP and geolocation that do not fit the declared profile or the account's history.

• Behaviour – how fields are filled, for example pasting details that people usually type.

• Payment – amount, timing and payee measured against the account's own history: an unusual amount, a first payment to a new payee, or a burst of payments in a short window.

None of these is proof of fraud on its own. But each shifts the risk estimate. Together they help separate a customer making an unusual payment from a session that has been taken over or scripted.

This is the layer device intelligence covers, alongside sanctions screening rather than instead of it.

Payment screening in digital lending

A lender's own payout, the loan disbursement, clears sanctions screening as long as no party is listed. Lenders can check that payout earlier, at application: who applied, from which device, and which account they asked to be paid into.

One device submitting several applications with different payout accounts, or linked to accounts with earlier defaults, can say more about where the money will go than the payee's name. As Temitope Adetunji, CEO of CashExpress Nigeria, puts it: "When one smartphone is used by ten people, traditional scoring is powerless." (CashExpress case study)

Device intelligence services such as JuicyScore work at this stage: JuicyScore uses 250+ parameters for device scoring, without relying on direct user identifiers such as names, phone numbers, or email addresses.

Reducing false positives without adding friction

Every false positive is a delayed payment and an analyst's time. EU legislators found that screening every transfer flagged a very high number of payments, most of them involving no one under sanctions (recital 25, Regulation (EU) 2024/886). Three levers reduce that load:

• Tune list matching. Set match thresholds by list and payment corridor, and clear name-only hits automatically when secondary identifiers such as date of birth or country do not match.

• Route fraud checks by risk. Let low-risk sessions through, step up medium-risk ones with a biometric check or a confirmation screen, and hold high-risk ones for review. Device and session signals are collected in the background, so they add no step for the customer.

• Close the loop. Add accounts and devices confirmed in fraud cases to internal watchlists, so the same mule account or device is flagged on its next payment.

One caveat on step-ups: UK Finance reports that in 2025 criminals used social engineering to compromise customers' one-time passcodes (UK Finance, 2026). A passcode can be talked out of a customer; device and session signals still work when that happens.

Key takeaways

• Payment screening checks the parties to a payment against sanctions, PEP and watchlists before it executes.

• Transaction monitoring works after execution; fraud screening checks the payment and its session in real time.

• APP fraud, mule accounts and account takeover usually pass list screening, because no party is listed.

• On instant rails – such as Pix, UPI, SEPA Instant – controls act at or after the payment, while warning signs appear earlier, at onboarding and login.

• Device and behavioural signals add the session view lists lack, with no extra step for the customer.

• Tuned list matching, risk-based step-ups and watchlists fed by confirmed fraud reduce false positives.

• For lenders, the loan disbursement needs screening as well as the application.

Book a demo to see how JuicyScore's device and behavioural signals can add to your fraud and credit decisions.

Editor’s note: this article was reviewed and updated in October 2026 with the latest data, insights and industry developments.

Stay ahead of payment fraud

For more analysis of fraud and risk in digital lending and payments, subscribe to our newsletter.

FAQ

What is the difference between payment screening and transaction monitoring?

Payment screening checks a single payment before it executes, comparing the parties against sanctions lists, PEP data and watchlists. Transaction monitoring reviews account activity after execution, across many transactions, looking for patterns such as structuring or unusual counterparties. Screening can stop a payment; monitoring raises alerts for investigation.

What is the $3,000 bank rule?

In the US, the Recordkeeping Rule and the Travel Rule require financial institutions to collect, keep and pass on originator and beneficiary information for funds transfers of $3,000 or more. It is a recordkeeping threshold, not a screening threshold: OFAC sanctions apply to payments of any amount.

What is screening in AML KYC?

In AML, KYC and KYB, screening means checking customers – individuals, and businesses with their owners – against sanctions lists, PEP lists and adverse media, at onboarding and periodically afterwards. Payment screening applies the same lists to individual payments and their counterparties. For euro instant transfers, EU rules now require daily customer screening instead of per-transaction checks.

Does payment screening stop APP fraud?

Usually not on its own. In authorized push payment fraud the payee is typically an ordinary account, not a listed party, so sanctions screening clears the payment. Stopping it depends on fraud controls: payee verification, device and session signals, and behavioural checks that flag an unusual session.

Does payment screening slow down payments?

Automated checks add little time; the delay comes from alerts that need human review. For euro instant transfers, the EU moved sanctions checks to daily customer screening partly for this reason. Tuning match thresholds and clearing matches on secondary identifiers reduces the number of payments that stop.

How do you integrate fraud screening into the payment flow?

Collect device and session signals from login onward, score them before the payment is authorized, and route the result: approve, step up or hold. Run it alongside sanctions screening, not instead of it, and feed outcomes – confirmed fraud and false declines – back into the rules so thresholds stay current.