SWIFT, AML/CFT, and Sanctions Screening in Practice

The compliance theory is straightforward: every cross-border payment must be screened against sanctions lists, monitored for money-laundering and terrorist-financing patterns, and reported where required.

The operating reality is harder. The product decisions inside that compliance envelope determine whether throughput survives, false positives are bearable, and the customer experience is acceptable.

Table of contents

• The screening stack
• Which lists, when, and why
• The matcher problem
• The review queue is a product
• AML/CFT monitoring vs sanctions screening
• ISO 20022 and the data advantage
• Key takeaways
• FAQ

The screening stack

A real screening implementation has four layers:

1. List management. The lists themselves, OFAC, UN, EU, UK HMT, country-specific, internal, with versioned updates.
2. Matcher. The algorithm that compares payment parties to list entries.
3. Decision logic. What automatic actions follow a match (block, hold, allow with logging).
4. Review queue. The human surface for ambiguous matches.

Each layer is a product. The quality of each determines the false-positive rate and the customer experience.

Which lists, when, and why

The list overlay must reflect:

• The jurisdictions the platform operates in.
• The jurisdictions of every party to the payment.
• Any contractual obligations to sponsoring banks and scheme partners.
• Any internal sanctions or restricted-counterparty lists.

A platform that screens only against OFAC is non-compliant in most non-US jurisdictions. A platform that screens against every global list with no jurisdictional logic produces an unbearable false-positive rate.

The matcher problem

Sanctions matchers are fuzzy by necessity, names transliterate across scripts, identifiers are inconsistent, and the same person appears multiple ways in different lists.

The product decisions are:

• Match tolerance. Tighter tolerance reduces false positives but risks misses. Looser tolerance is the reverse.
• Field weighting. Should a date-of-birth match outweigh a partial name match? In which jurisdictions?
• Alias handling. Lists include known aliases; the matcher must use them, but with careful tolerance.
• Negative news. Adverse media screening is a different product than sanctions screening and should not share thresholds.

The right answer varies by program. The wrong answer is to leave the vendor's defaults unchanged.

The review queue is a product

A sanctions hit that requires human review enters a queue. That queue is the highest-stakes UX in the compliance product:

• Decision support. Reviewers need the matched fields, the candidate list entries, the payment context, and the platform's prior decisions on the same party.
• SLAs. Every hold has a clock, both the customer's clock and the regulatory clock.
• Audit trail. Every decision, every reviewer, every justification, append-only.
• Feedback loop. Every confirmed false positive informs matcher tuning.

A queue without these properties degrades, slower reviews, inconsistent decisions, audit findings.

AML/CFT monitoring vs sanctions screening

The two are often conflated. They are different:

• Sanctions screening is per-payment, list-based, and largely deterministic.
• AML/CFT monitoring is pattern-based, behavioral, often model-driven, and operates across many payments and many customers.

Both are required. They need separate engineering, separate metrics, and separate review queues.

ISO 20022 and the data advantage

Structured party data in ISO 20022 messages reduces the matcher's ambiguity. Full structured names, addresses, identifiers, and purpose codes feed cleaner inputs into screening. False positives fall. True positives become easier to confirm.

This is one of the most underrated reasons to take the ISO 20022 migration seriously.

Key takeaways

• The compliance theory is simple; the product decisions are not.
• Lists, matcher tuning, decision logic, and the review queue are each separate product surfaces.
• Sanctions screening and AML/CFT monitoring are different products that share infrastructure.
• ISO 20022 gives the matcher cleaner inputs and reduces false positives at the source.

FAQ

Can fuzzy matching be safely tuned tighter? Only with telemetry, confirmed false positives and confirmed misses over a long enough window.

Is automated decisioning acceptable for sanctions? Auto-block on confirmed exact matches is standard. Auto-clear on partial matches without human review is generally not.

How often should lists be updated? As frequently as the issuing authority publishes, for some lists this is daily.