Where sanctions screening happens in a payment

Sanctions screening happens everywhere in a payment, and that is the problem. The originating bank screens a cross-border payment before it leaves, every intermediary in the correspondent chain screens it again, and the beneficiary bank screens it once more on arrival. Three institutions, three screening systems, three sets of list subscriptions and match thresholds, applied to one transaction. Each check exists for good reason. Together they form one of the largest sources of delay, cost, and failure in cross-border payments.

The lists

The screening universe is a stack of overlapping lists. OFAC’s Specially Designated Nationals list anchors the US regime, extended by the 50 Percent Rule to entities majority-owned by listed parties, which is what makes ownership research part of payments compliance. The EU maintains a consolidated financial sanctions list, the UK’s OFSI runs its own, and the UN Security Council’s consolidated list binds member states. They overlap heavily and differ at the edges, update on different schedules, and carry different secondary-sanctions consequences. A global bank screens against all of them simultaneously, plus its own internal watchlists.

Alongside list screening runs the Travel Rule: FATF’s Recommendation 16 requires originator and beneficiary information to travel with the payment, because a name you never received is a name you cannot screen.

Where the payment actually stops

Screening is name matching under uncertainty, and the tuning dilemma is unforgiving. Match too tightly and a transliterated name slips through, with regulatory consequences measured in enforcement actions. Match loosely and the system flags thousands of innocent near-matches. The industry literature on transaction monitoring reports false-positive rates in the region of 90 to 95%, and each alert stops the payment until a human clears it. LexisNexis Risk Solutions put the global cost of financial crime compliance at $206.1 billion a year in its 2023 study, a figure driven substantially by the people reviewing exactly these queues.

The delay concentrates where the data is worst. The BIS’s study of SWIFT gpi data found most cross-border delay sits at the beneficiary leg, where incoming payments queue for checks, currency controls, and repairs. A payment held for a compliance query can then miss a cut-off, converting a two-hour review into a two-day delay. Multiply by every hop, since each institution re-screens the same payment against its own configuration, and the compliance stack becomes a structural component of why international payments take days.

Screening the same payment N times

The repetition is not carelessness; it is architecture. In a correspondent chain, each bank bears its own regulatory exposure and cannot outsource its screening obligation to the bank before it. So the system performs the same fundamental check N times with N different error rates, and the payment’s fate depends on the strictest configuration it meets. The chain also fragments context: each intermediary sees only its hop, one reason richer, structured data matters. ISO 20022 gives screening systems discrete fields, full names, addresses, and purpose codes instead of free-text lines, which measurably reduces false matches, though it changes the quality of the checks rather than the number of times they run.

What programmable settlement changes

The deeper question is where screening sits relative to settlement. Today it is a gate before the money moves and an investigation after, systems bolted around the rails. On programmable infrastructure the relationship can invert: the outcome of the checks becomes a condition inside settlement itself, so a payment that has not satisfied its screening policy cannot settle at all, at any speed. That design is examined in what if compliance ran inside settlement; its relevance here is that it replaces N sequential re-screenings with one enforced policy, evidenced to every party that needs proof.

Where Frame fits

Frame is the settlement layer for global finance: one integration to orchestrate payments at scale across fiat rails, stablecoins, and tokenized deposits, with compliance enforced on every transaction and settlement in seconds instead of days.

Sanctions policy is exactly the kind of condition Frame’s Rules Engine enforces in settlement. The institution’s screening requirements, lists, thresholds, jurisdictional rules, are expressed as policy that every transaction is evaluated against, and a transfer that cannot satisfy the policy that governs it does not settle. Every settled transaction produces verifiable evidence that its conditions were met, without exposing the underlying business data, which is what a compliance officer needs when the question arrives months later: prove this payment was screened, and against what.

See how a rail-neutral settlement layer works: the Frame Blueprint.