What they “changed” in late November 2025 was essentially this:
SWIFT stopped processing key legacy FIN MT payment instruction messages for cross-border payments (CBPR+) and moved the community to ISO 20022 “MX” messages as the default/required format. The CBPR+ “coexistence” period ended 22 November 2025 (you’re remembering the right window). Swift+1
What did they replace it with?
✅ Replaced
Legacy SWIFT FIN MT payment instruction formats (the “old language”)
➜ With
ISO 20022 MX messages (CBPR+ usage guidelines) — the “new language” on SWIFT for cross-border payments. Swift+2Swift+2
In practical terms, the biggest replacements are:
-
MT103 (customer cross-border credit transfer) ➜ pacs.008 JPMorgan Chase+1
-
MT202/MT202 COV (bank-to-bank transfer related to customer payments) ➜ pacs.009 JPMorgan Chase+1
-
Returns/recalls/related flows are handled with the ISO 20022 family such as pacs.004 (returns), etc. Swift+1
(Your PDF already shows the high-level mapping like MT customer payments ↔ pacs.008 and FI transfers ↔ pacs.009.)
f2346415-db14-465f-bba8-bb00547…
How the “new system” works (in detail, but clearly)
1) Messages become structured data (not free text)
MT messages are field-based text (e.g., :50K: ordering customer, :59: beneficiary, :70: remittance).
MX messages are structured ISO 20022 XML where parties, accounts, IDs, addresses, purpose codes, remittance details, and agent roles are separate, well-defined elements. NICE Actimize+1
Result: computers can read and validate payments far more precisely (less ambiguity, less “guessing” by screening engines).
2) CBPR+ rules enforce consistency globally
SWIFT uses CBPR+ (Cross-Border Payments and Reporting Plus) usage guidelines to standardize how ISO 20022 is used for cross-border payments. Swift+1
3) Better compliance and screening outcomes
Because MX carries richer party and payment data, banks can:
-
run more accurate sanctions/AML screening,
-
reduce false positives caused by truncated names/addresses,
-
automate regulatory reporting and investigations more effectively. NICE Actimize+2Swift+2
4) Business continuity: translation/contingency existed (but with limits)
To avoid “payment gridlock” for institutions that weren’t ready, SWIFT and major banks described contingency/translation measures around the cutover—useful short-term, but not meant as a long-term crutch. BNY+1
The difference between the old system and the new system
A) Format and information content
-
Old (MT): compact text fields, many “free text” areas, inconsistent structure
-
New (MX ISO 20022): highly structured data, richer remittance info, clearer party roles and IDs NICE Actimize+1
B) Processing and automation
-
Old (MT): more manual repair, more exceptions, harder straight-through processing
-
New (MX): designed for STP, machine validation, faster investigation handling, better analytics Swift+1
C) Compliance and rejection risk
-
Old (MT): truncation + free text = more screening friction and ambiguity
-
New (MX): better data = fewer avoidable rejects/holds and cleaner end-to-end traceability NICE Actimize+1
D) Network/service changes you’ll hear mentioned
SWIFT references updates tied to its standards environment and services (e.g., standards releases effective 22 Nov 2025, and ISO 20022 messaging on SwiftNet/FINplus contexts depending on domain). Swift+1
What this means operationally for you (USCPB / cross-border workflows)
-
If a counterparty “only speaks MT” for cross-border payment instructions after the cutover, expect higher friction: translations/contingencies may work temporarily, but banks will push everyone to native MX. Swift+1
-
For payment proofs, confirmations, and compliance logs, you’ll increasingly see pacs.008 / pacs.009 references instead of MT103/MT202. Swift+1
If you tell me which flow you care about most, I’ll map it precisely:
-
Customer wire (old MT103 → new pacs.008), or
-
Bank-to-bank settlement (old MT202 → new pacs.009), or
-
Returns/recalls/investigations (pacs/camt ecosystem).
