Are you Screening everything and correctly?
This ISO 20022 question that may expose a much bigger sanctions screening problem.
For years, financial institutions have invested heavily in sanctions-screening technology. They have tuned thresholds. Reduced false positives. Added transliteration. Improved fuzzy matching. Introduced machine learning. Built sophisticated case-management systems. And, increasingly, they are exploring artificial intelligence to make alert review faster and cheaper.
But there is a more fundamental question that should come before all of these:
Are you actually screening everything you should be screening?
Because the effectiveness of a sanctions-screening system is not determined only by how accurately it matches a name against a sanctions list. It is also determined by whether the system ever receives and processes all the relevant information in the first place. That distinction becomes significantly more important in the ISO 20022 world.
A screening engine can have excellent matching algorithms, sophisticated AI, low false-positive rates and highly automated alert disposition. None of that matters if a sanctions-relevant piece of information is sitting inside the payment message in a field that the engine never examines. The transaction will not generate an alert.
The investigator will never see it.
The AI will never analyze it.
And the payment may simply continue.
AI cannot close what was never alerted.
That may be one of the most important weaknesses institutions should examine as they modernize their sanctions-screening environments.
The problem was never just name screening but transaction message screening
Traditional payment screening evolved largely around relatively predictable data.
- Who is sending the payment?
- Who is receiving it?
- Which banks are involved?
- Which countries are involved?
- Does one of those names resemble a sanctioned person or entity?
In the MT world, much of this information was concentrated into relatively few fields. Screening architectures were consequently designed around those fields.
ISO 20022 changes that model.
The message is richer, more granular and much more structured. Information about a transaction can now appear across numerous discrete data elements representing debtors, creditors, ultimate parties, agents, addresses, identifiers, countries, instructions and remittance information.
Swift itself describes ISO 20022 as providing more structured and granular information than FIN messages and notes that the additional information creates an opportunity for institutions to rethink existing screening approaches.
But richer data creates a new compliance obligation at the technology level:
You need to know which information you are receiving, where it is located and whether your screening system is actually evaluating it.
That sounds obvious. In practice, it may not be.
Free text is not disappearing
There is a perception that ISO 20022 solves the free-text problem because it introduces structured data. It certainly helps. But structured messaging does not mean there is no unstructured information. ISO 20022 payments can contain free-format information in areas such as remittance information, instructions for agents and regulatory reporting.
Swift’s own “Guiding principles for screening ISO 20022 payments” is particularly explicit on this point. It identifies, among others:
`<Ustrd>` – Unstructured remittance information
`<AddtlRmtInf>` – Additional remittance information
`<InstrInf>` – Instruction information
And Swift’s guiding principles state that, “when present, unstructured information tags should be screened against all list elements”, using fuzzy matching. Those list elements include individuals, entities, vessels, aircraft, BIC/LEI information and embargo data. That should trigger an important question for every institution running a legacy sanctions filter:
“Does your current screening system actually do that?”
Not theoretically. Not according to a product brochure. At message-field level.
What happens if it does not?
Consider a simplified ISO 20022 payment.
- The debtor is clean.
- The creditor is clean.
- Both banks are clean.
- The addresses produce no sanctions match.
But the remittance text contains the name of a sanctioned vessel, sanctioned entity, restricted location or other sanctions-relevant reference.
If the screening engine examines only the debtor, creditor and bank-party fields, the transaction appears completely clean. There is no false negative generated by the matching algorithm. The problem is more fundamental.
“There was never a screening decision at all.”
The relevant information was simply outside the control perimeter. That distinction matters enormously. A false negative means the screening engine evaluated something and failed to identify the match. A coverage failure means the information was never submitted to the matching process.
Those are different risks, requiring different controls, different testing and potentially different remediation. And one of them cannot be solved by better alert investigation.
A legacy engine can be working exactly as designed and still be wrong for today’s payment .This is where legacy technology becomes dangerous.
Many established screening platforms were designed when payment messages contained fewer data elements, architectures were less flexible and computational capacity was more expensive. Banks frequently configured specific message fields for screening. That configuration may have been perfectly appropriate at the time.
Years later, however, the surrounding payment format has changed significantly. The screening engine may still function exactly according to specification. The problem is that the specification is outdated. It may parse only selected fields. It may flatten structured ISO 20022 information into a legacy representation. It may concatenate information incorrectly. It may truncate content during MT-to-MX or MX-to-MT transformations. It may ignore newly available ISO 20022 elements.
Or it may send only a subset of the original message to the screening service.
This creates an uncomfortable possibility:
“The institution may believe it is screening an ISO 20022 payment when it is actually screening only a legacy representation of that payment.”
Swift has specifically highlighted mapping to and from legacy formats as a source of problems and has emphasized that institutions need to adapt screening as structured and new ISO 20022 data elements are adopted. This makes data lineage part of sanctions compliance.
An institution should be able to demonstrate not only that a payment passed through its sanctions engine, but also “exactly which data elements from the original payment message reached the screening engine and what happened to each one.”
That is a very different standard.
“Screen everything” does not mean match every XML field against every sanctioned name – There is an important distinction here.
ISO 20022 contains many data elements, and not every field should indiscriminately be fuzzy-matched against every sanctions-list entry. Dates, amounts, transaction references, identification codes, addresses, country information and names do not necessarily require identical matching logic.
Swift’s approach is therefore better described as “targeted screening”. Different data elements should be treated differently according to their meaning.
Names may require fuzzy name matching or phonetic matching.
Structured identifiers such as BICs or LEIs may warrant exact matching.
Countries and geographical information can be evaluated against embargo information.
Some information may be used primarily to support alert disposition rather than generate an alert, and free-text fields may require broader screening because their contents are not semantically constrained.
Swift explicitly describes this field-by-field approach and notes that no information needs to be discarded merely because it is not itself used to trigger a match.
The simplistic question is not: “Do you screen every field?”
The better question is: “Have you identified every sanctions-relevant data element, defined the appropriate screening behavior for it and verified that your screening solution in production receives every sanctions-relevant data element and implements that behavior?”
There is also an important terminology distinction.
A field being mandatory under a particular ISO 20022 message definition, CBPR+ usage rule, market infrastructure requirement or regulation does not automatically mean that it is sanctions screenable.
Equally, a field does not need to be mandatory to create sanctions risk. An optional free-text field may become extremely relevant the moment someone places sanctions-sensitive information inside it. Coverage therefore needs to be based on “meaning and risk”, not simply on whether an XML element is technically mandatory.
Then comes AI
The industry is understandably excited about using AI in sanctions compliance. Alert disposition is an obvious opportunity. A capable AI system can potentially examine an alert, compare transaction information with sanctions-list information, analyze names and addresses, identify contradictory information, summarize evidence and provide an investigator with a proposed rationale.
That could transform the economics of sanctions operations. But it creates a temptation to move too quickly from:
“AI can help analyze alerts”
to:
“AI can solve sanctions screening.”
Those are very different propositions.
Generative AI introduces characteristics that are especially important in a regulatory control. NIST describes “confabulation” as the phenomenon in which generative AI systems can confidently present erroneous or false content. Importantly, NIST also notes that AI can generate apparently logical explanations or citations that purport to justify an answer even when that answer is wrong.
That second point deserves particular attention in financial crime compliance.
Explainability is not the same thing as correctness.
A system can produce an extremely convincing explanation for an incorrect conclusion.
The fact that an AI can explain why it believes an alert is false does not prove that the alert is false. Conversational AI is also designed to generate useful responses. A compliance decision, however, is not a conversation. It is a controlled decision that may need to remain reproducible, defensible and auditable years later.
There are further questions around non-deterministic behavior, model updates, changes in underlying data, performance deterioration and version-to-version behavior.
The U.S. banking agencies’ revised 2026 model-risk guidance stresses validation, understanding model limitations, outcomes analysis and ongoing monitoring where model performance can deteriorate as data, customers, activities and conditions change. Interestingly, the agencies explicitly state that generative and agentic AI are evolving so rapidly that they are outside the scope of that particular model-risk guidance, while still saying institutions’ governance and risk-management practices should determine appropriate controls for such technologies.
That is not a prohibition on AI. It is a warning against treating AI as just another deterministic piece of software.
Regulators are not saying “AI must never screen”
This distinction is important for the credibility of the debate. It would be inaccurate to claim that regulators universally require AI to be restricted to alert disposition.
OFAC’s 2022 guidance for instant payments explicitly acknowledges artificial-intelligence tools that may enhance sanctions-screening functions and reduce false positives, and encourages institutions to consider emerging technologies where appropriate to their risk.
So the argument against making generative AI the sole initial screening control should not rely on a regulatory prohibition that does not exist. The stronger argument comes from control design. A primary interdiction layer should generally provide extremely high confidence regarding:
- Coverage
- Repeatability
- Data lineage
- Matching behavior
- Version control
- Testing
- Auditability
- The ability to demonstrate exactly why a payment was or was not stopped.
OFAC’s broader sanctions-compliance framework reinforces this principle by expecting technology used within sanctions controls to be appropriately selected and calibrated for the institution’s risk profile and routinely tested for effectiveness.
AI cannot close what was never alerted
This may be the most important point.
Imagine that an institution adds an extremely sophisticated AI capability to its existing alert-management platform. The AI analyses every sanction alert.
But upstream, the sanctions engine still ignores three relevant ISO 20022 free-text elements. The AI has solved nothing about that exposure.
Because the AI missed those transactions there is no alert, case decision or human review.
The institution has automated the visible part of the problem while leaving the invisible part untouched.
This is why financial institutions should resist beginning their sanctions-modernization program with the question, “Where can we deploy AI?”
The first question should be -“What exactly are we screening today?”
The screening-coverage test every institution should perform
Before evaluating another AI model, institutions should be able to answer seven less glamorous but more fundamental questions:
- Message coverage: Which payment-message types enter the sanctions-control environment, including pacs.008, pacs.009, pacs.009 COV, pacs.004 and other relevant messages?
- Field coverage: For every message type, which XML elements are extracted, which are screened, which are used only for investigation, and which are ignored?
- Matching coverage: What does each screened element match against, individuals, entities, vessels, aircraft, geographic restrictions, BICs, LEIs or other relevant identifiers?
- Free-text coverage: Are unstructured remittance, additional remittance and instruction fields actually screened, rather than merely stored in the payment record?
- Transformation integrity: Is anything lost, truncated, reformatted or moved when payments are translated between ISO 20022 and legacy formats or passed between systems?
- Regression evidence: Can the institution inject known sanctions-relevant terms into every relevant field and prove that the expected alert is generated?
- Production lineage: Can investigators and auditors demonstrate which original message element triggered an alert, what value was screened, which list record matched and which matching logic produced the result?
If any of those answers are uncertain, the organization may have a more fundamental problem than excessive false positives. It may not know its true false-negative exposure.
The future should be layered, not fashionable
Modern sanctions screening does not require choosing between deterministic screening and artificial intelligence.
They solve different problems.
The initial screening layer needs comprehensive message coverage, appropriate field-level logic, strong list management, controlled fuzzy and exact matching, deterministic processing where appropriate, full data lineage and continuous testing.
The intelligence layer can then help determine what the resulting alert actually means.
- AI can enrich.
- AI can contextualize.
- AI can compare.
- AI can summarize.
- AI can challenge.
And, under appropriately validated governance, AI may increasingly support or automate parts of alert disposition. But it should never become a convenient answer to weaknesses earlier in the transaction-processing chain.
Because an extraordinary AI alert-disposition engine sitting behind an incomplete screening engine simply produces very sophisticated answers to an incomplete set of questions.
The real modernization question
ISO 20022 gives financial institutions more information than they have ever had within a payment message. That is an enormous opportunity for better sanctions compliance. It is also an uncomfortable test of legacy architecture.
A screening solution that was designed around yesterday’s payment format should not automatically be assumed to protect tomorrow’s payment infrastructure simply because someone added an ISO 20022 interface to it.
Only after answering those questions does, it make sense to discuss how artificial intelligence can improve the alerts that remain. The future of sanctions screening will undoubtedly involve AI.
But before asking whether AI can close an alert correctly, every institution should answer a simpler question:
“Did your screening system generate the alert that should have existed in the first place?”
AI no matter how advanced cannot close what was never alerted.
References
* Swift, “Guiding principles for screening ISO 20022 payments”, October 2021. Swift’s guidance describes targeted field-level screening for ISO 20022 and specifically recommends screening unstructured information tags when present.
* U.S. Department of the Treasury, OFAC, “A Framework for OFAC Compliance Commitments”. OFAC emphasizes risk-based controls, appropriate calibration of technology and routine testing for effectiveness.
* U.S. Department of the Treasury, OFAC, “Sanctions Compliance Guidance for Instant Payment Systems”, September 2022. OFAC discusses AI and other emerging technologies as tools that may enhance sanctions screening and reduce false positives.
* NIST, “Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile”, NIST AI 600-1, July 2024. NIST identifies confabulation, over-reliance and other risks associated with generative AI.
* Federal Reserve, FDIC and OCC, “Supervisory Guidance on Model Risk Management”, April 17, 2026. The revised guidance discusses validation, monitoring and model deterioration and notes separately that generative and agentic AI remain outside the document’s model definition while still requiring appropriate governance and controls. ([OCC.gov][2])
[1]: https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.600-1.pdf “Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile”
[2]: https://www.occ.treas.gov/news-issuances/bulletins/2026/bulletin-2026-13a.pdf “Model Risk Management – Revised Guidance”
[3]: https://ofac.treasury.gov/system/files/126/instant_payment_systems_compliance_guidance_brochure.pdf “Sanctions Compliance Guidance for Instant Payment Systems”
