Picture one bank's payment filter early on a weekday, before the first analyst has opened the queue (illustrative). Two pacs.008 messages arrive for one payee. The first was built natively, with the payee's town and country in elements of their own. The second started life as an MT 103 that SWIFT converted on the way, so it carries a conversion flag, and the payee's address arrives as lines of free text. Both are ISO 20022 messages, and the hold and release steps of SWIFT sanctions screening apply to both, yet the filter cannot read them the same way.
The message format changed almost everywhere, while much of the address data inside it did not. More than 98 percent of payment instructions now go out in ISO 20022, SWIFT said on 27 August 2026. Its FAQ on removing unstructured addresses still put the share of payment messages carrying them at about 65 percent when read in October 2026.
What is ISO 20022, and which payment messages does a filter read?
ISO 20022 is a multi part international standard for financial messages. ISO Technical Committee TC68 Financial Services prepared it. It holds a central dictionary of business items and the design rules that turn message models into XML or ASN.1 schemas. The current edition has nine parts, published in April 2026, according to the ISO 20022 Registration Authority. After coexistence ended, SWIFT called it the standard language for payments between countries.
For a filter, the layout changed. An MT 103 packs a party's account, name and address into a single field. A pacs.008 gives each its own tag: the creditor's name in Nm, the town in TwnNm, the two letter country code in Ctry.
No official body certifies software against ISO 20022, the Registration Authority's FAQ says. With its Technical Support Group, the Registration Authority publishes a compliance checklist that implementers and tool providers can tick through, so a vendor page that calls its software ISO 20022 compliant is making its own claim. The same FAQ says cryptocurrencies are not inherently ISO 20022 compliant. Digital token identifiers sit under another standard, ISO 24165, and some exchanges may adopt ISO 20022 for their dealings with banks.
Which messages carry the parties?
SWIFT's screening principles were drafted on the pacs.008, the customer credit transfer between banks, by representatives of 14 global and regional banks. SWIFT says the analysis may also be applied to the pacs.009 COV, the cover payment, and the pacs.004, the payment return.
What did the end of coexistence with MT change for screening?
Coexistence began in March 2023 and ended on 22 November 2025. Since then, the FIN service no longer carries MT payment instructions between banks across borders, as SWIFT's conversion FAQ states. A bank that still sends an MT 103, MT 103 STP, MT 200, MT 202, MT 202 COV, MT 205 or MT 205 COV goes through contingency processing, and the receiver gets an ISO 20022 message. Five other types (MT 102, MT 102 STP, MT 103 REMIT, MT 201 and MT 203) are rejected at the network and never delivered.
So every cross border payment instruction a bank receives over SWIFT now arrives in ISO 20022, and rules can target single elements. Some are ISO 20022 in format only. Written as an MT, they still carry the name and address of fields 50 and 59 as free text.
How should a filter treat a converted MT message?
Treat the flag as a routing key. SWIFT marks every message it converted, so the receiver can tell, and its FAQ says converted messages carry no "structured and rich data" and are not processed by Transaction Manager. Send flagged messages to the free text rules the filter ran on MT 103s, with whole address lines screened against every relevant list, and keep the element rules for native messages. The flag also shows which counterparts still send MT, so the bank can ask each one when native messages will start. Conversion runs "for a period", and SWIFT does not intend it as a lasting or complete solution for MT users.
Which ISO 20022 elements are screened, and against which list?
Table 1. Targeted screening of a party and an agent in a pacs.008, as SWIFT's Guiding principles for screening ISO 20022 payments (October 2021, pp. 18 to 27) set it out.
| Element (tag) | What it holds | Matched against | Match type | Note |
|---|---|---|---|---|
Party name (Nm in Debtor, Creditor) | Name of the payer or payee | Individuals and entities; embargo data by risk appetite | Fuzzy | Name only; codes belong in their own tags |
Agent name (Nm in FinInstnId) | Name of a bank in the chain | Entities; embargo data by risk appetite | Fuzzy | Name only; the BIC belongs in BICFI |
| Town Name, Town Location Name, District Name, Country Sub Division | Place names | Embargo data | Fuzzy | Town and country are the minimum address |
Country (Ctry) | ISO two letter code | Embargo data | Exact | |
Post Code (PstCd) | Postal code | Embargo data, by risk appetite | Exact | For programs aimed at a region, not a country |
| Street Name, Building Number, Building Name, Floor, Post Box, Room | Street level detail | Not matched | None | Can still be shown to the analyst |
Address Line (AdrLine, up to 3) | Free text address | Embargo data; individuals and entities by risk appetite | Fuzzy | Lines joined before screening |
| Any BIC (party), BICFI (agent) | Bank identifier code | Sanctioned BICs; embargo data through characters 5 and 6 | Exact | Needs lists enriched with BICs |
| LEI | Legal Entity Identifier | Sanctioned LEIs, if any; embargo data where a location can be inferred | Exact | |
Other identification (Othr, Id) | Registration or personal ID number | Identifiers of sanctioned entities or individuals | Exact | Issuer name goes against entities |
Country of Residence (CtryOfRes) | Where a person lives or a company is run | Embargo data | Exact | Filled only when it differs from the address country |
Ustrd, AddtlRmtInf, InstrInf | Remittance and instruction text | Every list type, vessels and aircraft included | Fuzzy | The widest net in the message |
SWIFT calls this targeted screening. Each element is matched only against the list type it can hit, which avoids the two mismatches the principles name: a debtor name hitting vessel names, and street name information hitting embargo data. Nothing is discarded from the message, and an element that is not matched can still be shown to the analyst who clears an alert raised elsewhere. Free format text gets fuzzy matching; structured identifiers such as country codes, BICs and LEIs get exact matching.
The matrix came out of workshops between SWIFT and the 14 banks. The Payments Market Practice Group endorsed it in October 2021, and the Wolfsberg Group added its endorsement in November 2021. SWIFT calls the result a "target state" and says the paper is not designed to provide any recommendation, so treat it as market practice that each bank adopts in line with its own risk appetite. The baseline was SWIFT's 2020 survey of MT 103 screening, in which every responding bank screened fields 50, 52 and 59, and 95 percent screened remittance field 70.
complead, formerly Sanction Scanner, screens the payment message itself. With payment screening, the payment message is parsed, whether SWIFT MT or ISO 20022, and every party field is extracted. A match holds the payment before release, and a clean message passes without a pause. Payments on hold are ranked by score, each showing the field that matched, so the analyst can see whether a town element or a free text address line raised the hit.
Do structured and hybrid addresses cut false positives?
They cut one common kind of false positive: a street word hitting embargo data. In a structured address, the street level elements (street, building, floor, post box, room) are not matched at all, and only the town, town location, district, country subdivision and country go against embargo data, the country code by exact match.
Picture a payee at 12 Havana Road, Leeds (illustrative). Sent as free text lines, "Havana" hits the embargo data for Cuba, and the payment waits for an analyst. Sent structured, Havana Road sits in the street element, Leeds in the town element and GB in the country element. Nothing hits.
A hybrid address keeps town and country structured and puts the rest in free text lines. CBPR+ has allowed it since November 2025, and Fedwire adds it on 22 November 2027 with up to two lines of 70 characters. Under SWIFT's principles, address lines still go against embargo data and are joined before screening, so a place name split over two lines is not missed.
The gain depends on clean mapping. SWIFT's postal address FAQ reports mapping errors such as a post code and a town name together in the town tag, and notes that translation tools can only produce unstructured addresses. SWIFT also offers a free, open source tool that uses AI to structure customer addresses. The principles warn that richer data could raise the number of hits, while the structure allows a more targeted screening that may reduce false positives overall.
Are BICs and LEIs screened by exact match?
Yes, in SWIFT's own example. For the debtor agent in a pacs.008, the BICFI is matched exactly against lists of sanctioned BICs, and its fifth and sixth characters, the country code, are matched exactly against embargo data. A BIC with IR in those positions points to Iran even when the bank's name is on no list. The agent's name is still matched against entities, fuzzily.
Exact matching on a SWIFT BIC code works only if the list carries codes, and regulators differ here: some include BICs in their designations, others do not. Most data vendors close the gap by adding the BICs of designated financial institutions to their sanctions feeds, SWIFT notes, and it calls matching against such an enriched list the most effective method. Its fallback turns the BIC into a name and address and matches those, which generates more false positives. For agents, SWIFT's address FAQ keeps a BIC alone as a valid option instead of a name and address.
LEIs work the same way. Each is matched against sanctioned LEIs where a list carries them, and against embargo data when a location can be inferred from it.
When will unstructured addresses be removed from payment messages?
Table 2. Where four payment systems stand on ISO 20022 addresses (sources read 12 November 2026)
| Network | ISO 20022 since | Unstructured address today | Next dated step | Source |
|---|---|---|---|---|
| SWIFT (CBPR+, cross border) | Coexistence ended 22 November 2025 | Accepted; the 14 November 2026 removal was deferred on 27 August 2026 | Update promised "by December, at the latest" (27 August 2026); deferred release on 12 June 2027 holds no payments changes | SWIFT notice of 27 August 2026, updated 21 September 2026 |
| Fedwire Funds Service (US) | Move completed, announced 15 July 2025 | Accepted "until further notice" | Hybrid format from 22 November 2027; removal not in that release | Federal Reserve scope document of 6 November 2026 |
| CHAPS and RTGS (UK) | 19 June 2023 | Accepted; November 2026 release deferred in full | Removal expected in the November 2027 release, "subject to confirmation" | Bank of England page, updated 27 August 2026 |
| T2 (euro area) | Launched March 2023 | No address date on the ECB's T2 page | None published there | ECB T2 page |
It depends on the network, and the dated statements do not agree. On 27 August 2026, SWIFT deferred every payments change of Standards Release 2026, the structured address rule planned for November included, and said it would give an update by December at the latest. On 21 September it set 12 June 2027 for the deferred release, which covers MT, securities, tracker and investigation messages but no payments changes.
The two central banks read the next step differently. The Bank of England expected, on 27 August, to fold the removal into its November 2027 release, subject to confirmation. The Federal Reserve runs the Fedwire Funds Service, which settles more than $4.7 trillion in wire transfers on an average day. Its scope document of 6 November says no new removal date has been set and that removal has been agreed globally to sit outside the November 2027 release, so Fedwire participants keep accepting unstructured addresses until further notice. If your filter plan assumes a removal date, note beside it which of these statements it rests on.
SWIFT ties structured addresses to future data requirements such as FATF Recommendation 16.
What should a screening team retune now?
- Split flagged from native messages. Converted messages carry no structured data, so element rules would read empty tags while the free text goes unread.
- Write the element to list map down. For every row of Table 1, record the list type and match type the bank chose, risk appetite choices included. SWIFT's matrix is market practice, so the choices and the reasons are the bank's own.
- Join address lines before screening. A town split across two lines can slip past a filter that reads each line alone.
- Match codes exactly against enriched lists. BICs and LEIs give exact answers only when the list carries them, and the name and address fallback produces more false positives.
- Set fuzzy thresholds per list and keep them on record. Free text still needs fuzzy name matching, and one threshold rarely suits every list. In complead, a team can give each list type, and each single list, a threshold of its own, for example a lower one on sanctions lists than on watchlists.
How did the ISO 20022 address timeline shift in 2026?
- 20 February. SWIFT's final usage guidelines for Standards Release 2026, with the validation that retires unstructured addresses, became available.
- April. The current edition of ISO 20022, in nine parts, was published.
- 27 August. SWIFT put off every payments change planned for Standards Release 2026, and the Bank of England deferred its November 2026 RTGS release in its entirety.
- 21 September. SWIFT set 12 June 2027 for the deferred release, with no payments changes in it.
- 6 November. The Federal Reserve published the Fedwire scope for 22 November 2027: hybrid addresses arrive, and the removal of unstructured ones is not part of it. The November issue of On the Wire adds that the date is shared with CHIPS and SWIFT.
Back at the bank from the opening, the native message cleared on its town and country elements, and its street never touched the embargo data. The flagged one went through the free text rules, where its joined address lines raised a hit that an analyst cleared by hand, with the payee, the lists and the thresholds the same for both. The bank then asked the sending bank when it would start sending native ISO 20022 messages, and kept the flag rule in place until then.