Sanctions Screening on ISO 20022: What Structured Data Changed

Screening reads parties, agents, countries, and sometimes free text. The recurring defect is omission: ultimate parties skipped, or a cover payment screened on its two agents instead of the real underlying debtor and creditor. Structured addresses cut false positives because a town in a dedicated element is no longer a candidate name. And a test proving the engine was called proves nothing about what it examined.

Sanctions screening is the control that stops a payment leaving the bank. It is also, in most ISO 20022 programmes, the system nobody scoped properly, because it sits downstream of the payment engine and belongs to a different department.

This closes the field-by-field track of The ISO 20022 Reference, following cover payments. It is written for the analyst on the payments side who needs to specify what gets submitted, not for the compliance specialist who tunes the matching engine.

What does screening actually read?

Four categories, and the boundaries of each need to be explicit in your specification rather than assumed.

The named parties. Dbtr and Cdtr, with their names and addresses. And critically UltmtDbtr and UltmtCdtr, the parties on whose behalf the payment is really made.

The ultimate parties are the most commonly omitted, and the omission is consequential. In a payment factory arrangement, a shared services entity is the debtor while the actual paying subsidiary is the ultimate debtor. Screening only the debtor screens the treasury centre, which is never on a list, every single time. The party you needed to examine was the one you skipped.

The agents. DbtrAgt, CdtrAgt, and the intermediaries. Institutions appear on sanctions lists, and so do their jurisdictions. Getting this right depends on reading the agent fields correctly in the first place, which is why the agent chain matters here: screening InstgAgt and believing you screened the originating bank is the same class of error.

Countries and jurisdictions. Every country code in every address, plus country of residence elements where present, plus the currency, which carries jurisdictional signal of its own.

Free text. RmtInf unstructured content, and any other narrative the message carries.

That last one is a genuine policy question rather than a technical one, and it needs a written answer. Free-text remittance regularly contains names, places, vessel names, and goods descriptions, so it is a real screening surface. Screening it produces a higher volume of low-quality alerts, because unstructured text matches badly by nature. Many institutions screen it anyway. What must not happen is the question being settled by whichever fields the integration happened to map, because that leaves a regulatory control defined by a developer’s default.

Why structured addresses changed the false positive rate

This is the part of the ISO 20022 business case that is genuinely true, and it is worth understanding mechanically rather than accepting as a slogan.

Take an unstructured address line:

14 MALLOW STREET, CORK, IRELAND

To a matching engine, that is a string. It has no way to know that CORK is a town. So CORK is evaluated as a candidate name, and if anything resembling it appears on a list, an alert is raised and a human clears it. The same happens for street names that resemble surnames, which is extremely common.

Now the structured form:

<PstlAdr>
  <StrtNm>Mallow Street</StrtNm>
  <BldgNb>14</BldgNb>
  <TwnNm>Cork</TwnNm>
  <Ctry>IE</Ctry>
</PstlAdr>

The engine now knows what each component is. The town is a town. It is evaluated against place lists and country rules rather than against individuals and entities. An entire class of alert disappears, and it was never a real risk in the first place.

This is the concrete payoff behind the structured addresses deadline. It is also why hybrid addresses, where some components are structured and a remainder is free text, deliver only part of the benefit: the engine still has an unclassified string to deal with.

Alert volumes move in both directions

Programmes brief their steering committee that ISO 20022 reduces false positives, which is true and incomplete. Two things happen at once:

True hits can rise. Better-identified parties, LEIs, ultimate parties actually populated, and full addresses mean genuine matches surface that previously slipped through on thin data. That is the control working better, and it is the outcome compliance wanted.

Noise falls. Structured components remove the spurious place-name and reference-data matches described above.

The net effect on volume depends entirely on your tuning, and your tuning was calibrated against the old data shape. So alert volumes will move after go-live, possibly sharply, and the operations team needs to be warned rather than ambushed. Build a tuning period into the plan with a defined review point, and instrument the alert reasons so the shift can be attributed rather than argued about.

The failure mode to avoid: alert volume spikes at go-live, the operations team cannot clear the queue, pressure builds to loosen thresholds under time constraint, and a control is weakened for a capacity reason. Anticipating this in the plan is an analyst’s job, and it is a downstream impact item that belongs in the register from day one.

The defects you will actually find

Three, and I have found all three in live systems.

1. Ultimate parties not submitted. The integration maps Dbtr and Cdtr and stops. Payment factories and collections arrangements then route real counterparties past the control, invisibly, because the screening result is clean and nobody looks at what was examined.

2. Cover payments screened on the agents. A pacs.009 COV is handed to screening, the integration reads the top-level debtor and creditor, and those are two banks. The real parties are inside UndrlygCstmrCdtTrf and are never submitted. This is the exact gap the cover message type was created to close, reopened by an implementation detail. Full detail in cover payments.

3. Truncation before screening. A name is shortened to fit a legacy field somewhere in the chain, and the shortened name no longer matches the list entry it should have matched. Screening then runs correctly against degraded input. This is the truncation ledger with a compliance consequence, and it is the hardest of the three to detect because everything looks healthy.

All three share a signature: the system runs, reports clean, and examined the wrong thing. That is why the testing has to be shaped differently.

How to test screening properly

The standard test asserts that the screening service was invoked and returned a result. That test passes on all three defects above.

Assert the input, not the invocation:

• A payment with UltmtDbtr populated, asserting the ultimate debtor’s name appears in the set of names submitted to the engine.
• A pacs.009 COV, asserting the underlying debtor and creditor were submitted, and that the agents alone were not.
• A payment with a name at the maximum permitted length, asserting the full name reached screening untruncated.
• A structured address, asserting the components were submitted as components rather than concatenated back into one line, which some integrations do to fit a legacy screening interface. That last one silently gives back the entire false-positive benefit.
• A known test entity from your list, asserting a hit is raised. Every screening deployment needs this, and it needs re-running after every configuration change.
• An intermediary agent in a restricted jurisdiction, asserting the agent chain was screened and not just the parties.

The general principle is the one from negative test design: assert the observable thing that would be wrong if the defect existed, not the convenient thing that is true either way. For screening, the observable thing is the list of names submitted. Log it, and test against the log.

What to specify

1. The submission set: every field submitted to screening, listed explicitly, per message type. Not “the parties.”
2. The cover payment rule, stated separately, because it is the exception everyone misses.
3. The free-text policy: screened or not, decided by compliance, written down.
4. The truncation rule: screening happens before any truncation, and if that is impossible, the residual risk is documented and accepted by a named owner.
5. The hit handling process: who investigates, what the SLA is, what happens to the payment while it waits, and what the customer is told. Payments held in screening are invisible to the customer and generate support contact.
6. The tuning plan post go-live, with a review point and instrumented alert reasons.

The takeaway

Screening reads parties, agents, countries, and possibly free text, and the failure is almost never the matching engine. It is the submission set: ultimate parties omitted, cover payments screened on their two agents instead of the underlying customer transfer, or names truncated before they reach the engine. All three produce a clean result on an incomplete examination.

Structured addresses genuinely cut false positives, because a town in a dedicated element stops being a candidate name, and that benefit is lost if your integration concatenates the components back into one line for a legacy screening interface. Expect alert volumes to move in both directions after go-live, and plan the tuning window before operations is buried.

That closes the field-by-field track. The scheme track begins with SEPA Credit Transfer, where the rulebook layer above ISO 20022 decides most of what you can actually send. The full map is on The ISO 20022 Reference.

Ahmed is a Senior Technical Business Analyst with 10+ years in banking and payments. He builds practical guides and tools for analysts at The Tech BA Toolkit.

Tags: ISO 20022, Payments, Compliance, Sanctions Screening, Systems Analysis