AML for Instant Payments: Screening in Real Time

Traditional payment rails gave compliance teams a gift they rarely noticed: time. A batch ACH or Bacs payment might sit for hours or days before settling, leaving a comfortable window to run sanctions and AML checks, investigate alerts, and hold anything suspicious. Instant payments take that window away. Schemes like SEPA Instant, FedNow, RTP and the UK's Faster Payments settle irrevocably in seconds, around the clock. Compliance now has to happen inside that window, and that changes everything about how screening is designed.

The core tension

Instant schemes impose a hard service-level agreement. SEPA Instant, for example, targets end-to-end completion within about ten seconds. Within that budget the sending bank must format and send the payment, the scheme must route it, and the receiving bank must validate and confirm — and somewhere in there, sanctions screening and fraud checks must run. There is no overnight batch, no manual review before release, and once the payment is accepted it is final. Screening that used to take minutes must now complete in milliseconds, or the payment fails the SLA.

Sanctions screening cannot be skipped

Speed does not relax the law. Sanctions obligations are strict-liability in many regimes — processing a payment for a sanctioned party is a violation regardless of how fast it happened. So real-time sanctions screening is non-negotiable on instant rails. The engineering response is to make screening fast rather than to skip it:

• In-memory watchlists so name-matching runs in milliseconds without database round-trips.
• Pre-screening and caching of known-good counterparties to clear repeat payments instantly.
• Tuned matching that balances catching true hits against generating false positives that would blow the SLA.
• Structured ISO 20022 data feeding the engine clean name and country fields for precise matching.

Because the payment is time-boxed, a screening hit typically forces the payment to be rejected within the SLA rather than parked for review; the safe default when in doubt is to fail fast and let the customer be investigated separately.

Fraud, not just laundering

Instant, irreversible settlement is a gift to fraudsters. Authorised push payment fraud thrives when money cannot be recalled, so instant rails demand real-time fraud scoring alongside AML. Behavioural models assess each payment in-flight — device signals, velocity, beneficiary risk, deviation from the customer's pattern — and can challenge or block a suspicious transfer before it settles. Tools like Confirmation of Payee add a pre-send name check. The distinction matters: AML screening asks "is this party sanctioned or a laundering risk?", while fraud controls ask "is this customer being scammed right now?"

Post-event monitoring still matters

Not everything can be decided in ten seconds, and regulators do not expect it to be. Real-time controls handle the go/no-go decision; transaction monitoring continues afterward to detect patterns that only emerge over time — structuring, mule networks, layering across many small instant payments. Because instant rails make funds move faster, monitoring must also react faster, shrinking the gap between an alert and an intervention like freezing an account or filing a suspicious activity report. The model is layered: instant decisioning at the point of payment, continuous analysis behind it.

Availability changes the risk profile

Instant schemes run 24/7/365, including nights, weekends and holidays when staffed operations are thin. Fraudsters deliberately exploit these windows. That forces compliance to be genuinely automated and always-on, not dependent on an analyst being awake. It also raises resilience stakes: if the screening system is down, the bank must decide whether to stop sending payments (hurting customers) or send without screening (breaking the law) — and the only acceptable answer is a highly available screening service with a fail-safe that stops payments rather than skipping checks.

Designing for the SLA

The practical lesson is that compliance must be engineered as a low-latency, high-availability service sitting directly in the payment path, not as a batch job bolted on afterward. Every millisecond of screening latency competes with the scheme deadline, so architecture choices — in-memory data, parallel checks, aggressive caching, clean structured input — are compliance decisions as much as engineering ones. On instant rails, speed and control are not opposites; they have to be built together.

Key takeaways

• Instant payments settle irrevocably in seconds, removing the batch window compliance once relied on.
• Sanctions screening is mandatory and must run in milliseconds, defaulting to fast rejection on a hit.
• Irreversibility makes real-time fraud scoring essential alongside AML checks.
• Post-event transaction monitoring still catches patterns that cannot be judged in the SLA window.
• 24/7 operation demands automated, highly available screening with a fail-safe that stops rather than skips.