Sanctions screening at instant-payment speed

Sanctions screening for instant payments no longer happens per transaction — the Instant Payments Regulation moves it to the customer level, refreshed at least daily. Screening every SEPA Instant credit transfer inside a ten-second end-to-end envelope — alongside Verification of Payee and authorisation — was never realistic with engines built for the rhythm of card and batch SCT settlement. So the regulation changed the model instead of the deadline. This walkthrough covers what Article 5d actually requires, how it reshapes screening architecture, where transaction-level screening still applies, and what a true hit obliges you to do.

1. What the Instant Payments Regulation changed

The Instant Payments Regulation — Regulation (EU) 2024/886, amending the SEPA Regulation (EU) 260/2012 — caps the time a SEPA Instant Credit Transfer may take at ten seconds from the payer’s instruction to funds being available to the payee. Inside that envelope sit customer authorisation and SCA, Verification of Payee, sanctions controls, network settlement and crediting at the payee’s PSP.

For sanctions specifically, Article 5d introduces the decisive shift: PSPs offering instant credit transfers must screen their customers at onboarding and at least daily against updated EU sanctions lists — and, for SEPA-only instant transfers, they rely on that customer-level result instead of screening each individual transaction.

2. The customer-level screening model

Historically, the payer’s PSP checked the parties and message fields against sanctions lists before releasing each payment. Under the IPR model for SEPA instant transfers:

• The PSP screens its customer base at least daily against EU sanctions lists — immediately after any list update takes effect.
• Screening covers the customer, beneficial owners and authorised representatives — not just the account name.
• Individual SEPA-only instant transfers between screened customers need no fresh transaction-level check.
• A list update triggers prompt re-screening; a true match triggers an immediate freeze.

Transaction-level screening does not disappear. It continues for payments outside the SEPA-instant scope: correspondent legs touching non-EU institutions, cross-currency flows, and other payment types not covered by the customer-level regime.

3. Why this changes the architecture

A per-transaction engine parses each payment for screenable fields, runs fuzzy matching against list indexes, and queues hits for investigators — with latency rarely a hard constraint. The customer-level model is a different operational pattern:

• The full customer master is screened on a schedule, with list updates triggering delta re-screens rather than full runs.
• The payment hot path reads a precomputed “screened-clean” flag on the customer record — effectively a single key-value lookup.
• The screening result must be tied to the list version it was computed against, so a stale flag is detectable.

PSPs whose KYC data and sanctions engine already share a customer master face a moderate lift. Where KYC and screening sit in separate systems synchronised by batch, the IPR forces convergence: the screening result has to be authoritative, current and queryable in milliseconds.

4. Which lists, in what scope

The IPR does not change which lists apply to you. It changes how often you must screen against them and where in the flow the check sits.

5. Worked example — a list-update day

Facts: A retail EMI with 1.5 million customers runs its customer-level screening nightly. At midday, a new EU sanctions package enters into force, adding several hundred designations.

What the rule says: Daily screening is the floor, and the customer base must be checked against updated lists — the PSP must re-screen without delay once new designations take effect, not wait for the next scheduled nightly run.

What the practitioner does: Trigger a delta screen of the full customer master against the new entries only — a few hundred names against 1.5 million records is fast, whereas a full re-screen of all lists is not. Instant payments keep flowing on the existing clean flags for unaffected customers; any new alert suspends the flag for that customer pending review.

6. The false-positive problem

Customer-level screening at scale produces false positives: a large customer base generates thousands of name-match alerts per refresh through sheer name overlap — common surnames, transliteration variants, partial matches. The tooling around the engine matters more than the engine:

• Calibrated matching — token-based comparison, transliteration handling, disambiguation on date and place of birth.
• Ranked queues — alerts ordered by genuine match probability, so investigators clear the risky ones first.
• Clean-record cache — a resolved false positive is cached and only reopened when the relevant list entry changes.
• Audit trail — every alert, disposition and override persisted with the analyst’s identity, because the regulator will ask.

7. Worked example — the recurring false positive

Facts: A customer’s name closely matches a designated person; date of birth differs by fifteen years and the nationality does not match. The alert re-fires on every screening cycle.

What the rule says: The obligation is to screen against updated lists and freeze true matches. Nothing requires re-investigating an identical alert on identical data — but the discounting decision must be documented and revisited if either the customer’s data or the list entry changes.

What the practitioner does: Record a reasoned disposition (mismatched date of birth and nationality), whitelist the customer-to-list-entry pair, and configure the cache to invalidate on any change to that list entry or to the customer’s identity data. This keeps the daily alert volume proportional to genuine change, which is what makes the daily cadence operationally sustainable.

8. Interaction with Verification of Payee

The same ten-second envelope must accommodate VoP alongside sanctions controls, and the two are independent checks that run in parallel: VoP matches the payee name against the IBAN via the payee’s PSP, while the sanctions control is a lookup of the customer-level screening result. VoP happens before the payer confirms the order; the sanctions flag is checked on the processing path. Neither is a substitute for the other — a VoP “match” says nothing about sanctions status, and a clean screening flag says nothing about whether the IBAN belongs to the intended payee.

9. The freeze obligation on a true hit

Facts: The daily re-screen returns a strong match — name, date of birth and nationality all align with a newly designated person holding an active account.

What the rule says: EU sanctions regulations require immediate freezing of the designated person’s funds and prohibit making funds available — no outbound payments, no inbound crediting to their free disposal — plus reporting to the national competent authority for sanctions enforcement in your member state.

What the practitioner does: Freeze the relationship at account level the moment the match is confirmed, file the report to the national authority, and route all customer communication through counsel and the AML representative — tipping-off-style restrictions mean the customer must not learn about reports filed. The screening flag flips to blocked, which automatically stops instant payments without any transaction-level logic.

10. FAQ

11. What to do, today

• Head of FinCrime: confirm your screening cadence meets the daily floor and that list updates trigger immediate delta re-screens, not next-day batches.
• Architecture lead: move the payment hot path to a single lookup of a precomputed clean/blocked flag on the customer record, versioned against the list state.
• Screening operations: implement whitelisting with change-based invalidation so recurring false positives don’t consume the daily cycle.
• MLRO: rehearse the true-hit playbook — freeze, report to the national authority, controlled communication — and align it with your suspicious-activity-reporting workflow.
• Compliance: document the boundary cases where transaction-level screening still applies and prove both paths in your control testing.

Related: Verification of Payee under IPR · What is the IPR report? · AML representative across the EU · SCA exemptions under the PSD2 RTS · Funds transfer information under Reg 2023/1113 · PSD2 fraud reporting under Article 96(6)