ISO 20022 sanctions screening: one pacs.008, field by field

ISO 20022 sanctions screening is the screening of payment messages in the ISO 20022 format, such as the pacs.008 customer credit transfer, against sanctions lists before the payment moves. The fields that matter are the ones that name a party, a bank, a place or a thing: the debtor and creditor, their agents and any intermediary, ultimate parties, addresses, and the free-text remittance information where many hits sit. ISO 20022 carries more of that data, in more structured form, than the old SWIFT MT and Fedwire formats, which means more to screen and better identifiers to clear a hit with. Botminds' Payment Sanctions Screening reads each held message as plain fields, each with its ISO 20022 path, and the sample wire below shows what that looks like on a real-shaped pacs.008.

Which ISO 20022 fields need sanctions screening?

Every field that identifies a party, a financial institution, a location or an object, plus every free-text field. The Wolfsberg Group lists the transactional attributes most commonly screened: "The parties involved in a transaction, including the remitter and beneficiary", "Agents, intermediaries and FIs", "Vessels, including International Maritime Organisation (IMO) numbers", "Bank Names, Bank Identifier Code (BIC) and other routing codes", "Free text fields, such as payment reference information or the stated purpose of the payment in Field 70 of a SWIFT message", and geography, "including a multitude of addresses, countries, cities, towns, regions, ports" (Wolfsberg Guidance on Sanctions Screening, 2019).

It is just as explicit about what not to screen: "amounts, dates and transaction reference numbers have no relevance from a screening perspective." Leaving them out is not a gap; screening them only creates noise.

In a pacs.008 those attributes map to a handful of element groups: the debtor (Dbtr) and creditor (Cdtr) with their postal addresses; the ultimate debtor and ultimate creditor where a payment is made on someone else's behalf; the debtor agent and creditor agent (DbtrAgt, CdtrAgt) and any intermediary agents, identified by BIC; remittance information, structured or unstructured (RmtInf); purpose codes; instructions to the next agent; and regulatory reporting. The filter should read all of them, and the analyst should see them laid out, not as one raw block of XML.

The Kestrel wire, unfolded

The sample wire is a $412,880.00 freight payment from a grain exporter in Duluth, Minnesota to a ship-chartering company in Bergen, Norway, sent as an outgoing SWIFT pacs.008 on October 22, 2026. It stopped at 10:14:22 AM on one phrase in the remittance text: MV KESTREL DAWN. The screening service scored it 91 against SDN entry 61207, a crude oil tanker listed as KESTREL DOWN. Every other field passed.

The agents read the 31 fields of the message into plain rows in 0.4 seconds, located the hit in the remittance information, and then used other words in the same field to settle it. The text carries IMO 0000836; the listed tanker is IMO 0000519. The ports are Duluth and Rotterdam, neither in a sanctioned region. Both BICs are clear. The recommendation, nine seconds after the stop, was to release, with the reason "an identifier differs". The analyst released the wire after 3 minutes 44 seconds.

The message reader's view: fields, paths and the words that hit

Where hits hide in remittance information

Remittance information is where screening meets commerce. It is free text written by the customer, the customer's accounts-payable system or a trade platform, and it carries whatever the payer thinks the payee needs: invoice numbers, ship names, ports, goods, sometimes a third party's name. A filter that screens free text will hit on it far more often than on party names, because the vocabulary is unbounded.

The same field often holds the cure. Shipping references carry IMO numbers; trade references carry ports of loading and discharge; invoice references point to documents the bank can ask for. The useful design separates two jobs: screen every word for what it might match, then read the rest of the field for identifiers that confirm or rule out the match. In the Kestrel wire, the hit and its clearance sat in the same line of text. Vessel sanctions screening works through that ship hit identifier by identifier.

Structured remittance (RmtInf/Strd) helps where it is used, because a creditor reference or an invoice number in its own element is not mistaken for a name. Many corporate payments still arrive unstructured, so a screening setup should expect both.

The remittance field causes many of the hits and contains much of the evidence. Screening that reads only for matches sees half of it.

Do you screen BICs and LEIs?

Yes for BICs, wherever they appear, and yes for LEIs where the bank's lists carry them. OFAC names the omission directly among the root causes of past violations: screening software that left out the SWIFT codes of designated and blocked banks (OFAC, A Framework for OFAC Compliance Commitments, 2019; how to plant that failure in a test file is in sanctions screening testing). A bank's name can be abbreviated, translated or misspelled in a message; its BIC cannot, so a BIC on a listed entry is the most reliable single thing to screen for in the agent fields.

OFAC's own list carries both identifiers on some entries. In the SDN List of October 26, 2026, 220 entries carried a SWIFT/BIC code and 184 a legal entity identifier, out of 19,471 (our count from OFAC's SDN list files). ISO 20022 has room for an LEI in party and agent identification, so where the message carries one, it can rule a party in or out more firmly than its name.

Does structured address reduce false positives?

It can, because it tells the filter which part of an address is a street, which is a town and which is a country. The Federal Reserve made the point when Fedwire moved to ISO 20022: richer data helps "improving sanction screening processes", and "The ISO 20022 format allows for more structured and longer fields (e.g., names and address components) compared to the former proprietary FAIM format" (Federal Reserve Financial Services, ISO 20022: exploring its impact on the Fedwire Funds Service).

The mechanism is simple. Geographic sanctions programs care about towns, regions and countries. In an unstructured address, "Crescent Harbor Road, Port Townsend" is one string, and a filter cannot tell that "Crescent Harbor" is a street rather than a party. In a structured address, the street name sits in its own element and the town in another, so the bank can decide what each element is screened for. On the sample bank's desk, one OFAC listing of a company called Crescent Harbor produced lookalike hits on street names and company names in four U.S. states; structure does not stop those, but it lets the analyst and the filter see at once that the words are a street.

Structure also changes what the Travel Rule data looks like. For funds transfers of $3,000 or more, U.S. banks must pass on the originator's name, account number and address, among other items (31 CFR 1010.410(f)), and an address split into elements is easier to check for completeness and to screen than four lines of free text.

How is a pacs.008 different from an MT103 for screening?

A pacs.008 carries more parties, more structure and longer fields, and that is both its benefit and its cost. The ultimate debtor and ultimate creditor have their own elements, so a payment made on behalf of someone else names them where a filter will look. Names and addresses are no longer squeezed into a few fixed-width lines. Purpose and category codes give the analyst context that an MT103 often left to free text.

The cost is volume and change. More populated fields means more strings to screen and, at first, more hits; a filter tuned on MT103 data meets fields it has never seen. Conversion between formats can also lose or move data: a structured address flattened into lines, or ultimate-party information pushed into remittance text. Wolfsberg's advice applies directly: "Particular attention should be directed to any points within the transactional process where relevant information could be changed, modified or removed in order to undermine screening controls."

What changed with Fedwire's ISO 20022 move

The Fedwire Funds Service cut over to ISO 20022 on July 14, 2025, replacing its proprietary FAIM format, and the Federal Reserve says participants "were immediately able to utilize the CPMI payments data models for high-value USD wire payments" (Federal Reserve Financial Services, June 2, 2026). Customer transfers now travel as pacs.008 and bank transfers as pacs.009, with their own cut-off times (Fedwire Funds Service operating hours).

More change is scheduled. The Federal Reserve planned a November 2026 release to roll out "the hybrid postal address format" and two structured payment investigation messages, and has since rescheduled that release to November 2027, with its scope to be published later (Fedwire Funds Service upcoming releases). Internationally, the Committee on Payments and Market Infrastructures has encouraged market participants "to begin preparations to align with the harmonised ISO 20022 data requirements in earnest by end-2027 at the latest", as the Federal Reserve's article reports. A screening configuration set in 2025 will need revisiting as those changes land.

Identifier by identifier: what the agents checked on the Kestrel wire

Richer data cuts both ways

ISO 20022 gives screening more to work with, and more to get wrong. More parties and longer fields mean more hits unless the filter is tuned to the new structure; richer identifiers mean more hits can be cleared on evidence rather than judgement. Which effect wins depends on whether the identifiers reach the person deciding.

That is where Payment Sanctions Screening fits. It does not replace the filter that stops the payment, and it does not change the filter's threshold. It reads each held message as plain fields with their paths, finds the words that hit and the identifiers that can settle them, and hands the analyst a cited recommendation. How it sits beside an existing filter and payments hub is set out in payment screening solutions that sit beside your filter, and the difference between screening payments and screening customers in name screening vs transaction screening. The full solution is on the Payment Sanctions Screening page.

Questions people ask

Does ISO 20022 increase sanctions screening false positives?

It can at first, because more populated fields and new party elements give the filter more strings to match. It also carries more identifiers, structured addresses and purpose codes that let analysts clear hits faster. The Federal Reserve lists improved sanctions screening among the benefits of the richer format.

What is the ultimate debtor in ISO 20022, and should it be screened?

The ultimate debtor is the party on whose behalf the debtor pays, and the ultimate creditor the party on whose behalf the creditor receives. They have their own elements in a pacs.008, unlike in an MT103, and should be screened like any other party because they may be the real counterparty.

Which SWIFT field is screened for remittance information?

In an MT103 it is field 70, remittance information, which the Wolfsberg Group names as a commonly screened free-text field; field 72, sender to receiver information, should be screened too. In a pacs.008 the equivalents are RmtInf and the instructions to the creditor agent and the next agent.

When did Fedwire move to ISO 20022?

On July 14, 2025, when the Fedwire Funds Service replaced its proprietary FAIM format with ISO 20022 messages. A further release that would add the hybrid postal address format was planned for November 2026 and has been rescheduled to November 2027.

Should amounts and dates in a payment be screened?

No. The Wolfsberg Group's guidance says amounts, dates and transaction reference numbers have no relevance from a screening perspective. Screening them adds alerts without adding detection.