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).
Banking platform registration: To help us serve you more efficiently, please complete your U.S. Capital Private Bank banking platform registration and account-opening profile at https://uscapitalprivatebank.com at your earliest convenience, where applicable.
The CRM Portal at https://www.uscapitalprivatebank.com/crm is used for communication, support tickets, service coordination, and status follow-up. The banking platform provides the secure account environment needed for onboarding, document verification, account setup, transaction preparation, and more organized client service.
Registration does not guarantee approval, funding, transaction completion, instrument issuance, compliance clearance, or activation of any banking service. All services remain subject to review, documentation, verification, compliance screening, internal approval, and applicable banking procedures.
Banking platform reminder: The CRM Portal is used for communication, support, and service coordination. For secure onboarding, document verification, account setup, transaction preparation, and more efficient client service, please also register on the U.S. Capital Private Bank banking platform at www.uscapitalprivatebank.com as soon as your CRM Portal registration is complete.