Real-time payment fraud detection: an architecture for irrevocable rails

Card fraud is mostly unauthorized and partly recoverable through chargebacks. Instant credit transfers invert both properties. In an authorized push payment scam, the genuine customer logs in on their own device and sends the money, persuaded by someone posing as their bank, a seller, an investment manager or a romantic partner. Once the payment settles, mule accounts move the funds onward within minutes, so the only control that reliably works is one that acts before the order is submitted.

Rules on who bears the loss have shifted. In the UK, payments made by Faster Payments or CHAPS on or after 7 October 2024 are covered by mandatory reimbursement of up to £85,000 per claim, with claims allowed up to thirteen months after the payment and an exception for complicity or gross negligence¹. Sending and receiving firms split the cost equally², which gives the receiving bank a direct stake in catching mules.

In the euro area, Regulation (EU) 2024/886 requires the payee's PSP to make funds available within 10 seconds of receiving the payment order, and requires the payer's PSP to offer verification of payee, free of charge, from 9 October 2025³. The payer can still proceed after a mismatch warning. The same regulation replaces per-transaction screening against EU restrictive measures with at least daily screening of customers³, so sanctions checks should not sit in the instant path while fraud scoring still does.

In the United States, Regulation E defines an unauthorized transfer as one initiated by someone other than the consumer without actual authority⁵, which is generally read as excluding a payment the customer sent under deception. On rails such as FedNow and RTP, prevention carries more of the weight.

Scam payments look legitimate on credentials, so useful features describe context: a first payment to a new payee, an amount far above the customer's range, a new device or remote-access tool, a failed payee check and hesitation during setup matter more together than alone. ColdAI's fraud work describes models reading transaction patterns, behavioral biometrics and network graphs⁶; the architecture question is which of those can be computed in time.

Keep feature definitions in one place and compute them with the same code in training and serving, with point-in-time joins, so the model never trains on information it would not have had at decision time. Graph features, such as how many unrelated senders paid a payee account recently or whether it shares a device with known mules, are the costliest to compute and the most informative for mule detection; precompute them and serve them by account key.

Labels arrive late and noisily: scam reports can come weeks after the payment, from customer claims rather than ground truth. Mark maturity windows and treat held-and-cancelled payments as evidence too; building a training dataset covers labeling and leakage.

Receiving-side detection looks at accounts, not single payments. Typical mule patterns include new accounts suddenly receiving first-time payments from many unrelated senders, dormant accounts waking up with pass-through activity, and funds leaving within minutes for other banks or crypto exchanges. Onboarding data such as reused identity documents and devices linked to known mules strengthens the score.

Because a receiving bank usually cannot refuse a valid instant credit, its levers sit on outbound activity: restricting onward transfers, stepping up authentication and opening an investigation. Alert handling then follows the bank's financial crime process; AI support for that queue is covered separately in AML alert triage.