ISO 20022 after November 2025: what TCSPs should check now

The November 2025 milestone has passed. On 22 November 2025, the coexistence period between MT and ISO 20022 messages for in-scope SWIFT cross-border payment instructions ended. SWIFT describes ISO 20022 as the required standard for those payment instructions, with contingency conversion still available for certain remaining MT traffic.

That does not mean every MT message has disappeared or that every corporate-to-bank channel changed on the same day. For Trust and Corporate Service Providers (TCSPs), the right question is no longer “Are we ready for the deadline?” It is “Are our live bank connections producing complete, structured and usable data?”

What changed — and what did not

ISO 20022 is a common financial-messaging framework. Its structured messages can carry richer party, account, remittance and regulatory data than many legacy formats. Used well, that structure can support better reconciliation, screening and investigation.

The November 2025 SWIFT milestone applied specifically to in-scope cross-border payment instructions exchanged between financial institutions through CBPR+. It did not impose one universal file format on every TCSP. A bank may still accept a corporate payment file in PAIN.001, a proprietary format or another agreed channel, then transform it for onward processing. Statement delivery may likewise use CAMT.052 or CAMT.053, MT940 or a bank-specific format according to the service agreed with the bank.

SWIFT’s roadmap beyond November 2025 also shows that migration work continues for other message groups. Treat ISO 20022 as an ongoing data and process programme, not a completed one-off conversion.

What TCSPs should verify now

1. Inventory each live bank connection. For every banking partner, record the channel used for statements and payments; the exact message or file versions in production; whether the bank performs any conversion; which legacy formats remain supported and until when; and who owns testing and change notifications on both sides. Do not assume that two banks using “CAMT.053” have implemented identical options. Version, bank usage guidelines and optional fields can all affect downstream processing.
2. Test data quality, not just file acceptance. A technically valid message can still contain incomplete or poorly structured data. Sample live files and check whether the information needed for reconciliation, sanctions screening, client reporting and exception handling arrives in consistent fields. Pay particular attention to party names and addresses, remittance information, account identifiers, charges and transaction references. Confirm how your systems handle missing, repeated or truncated values.
3. Reconcile end to end. Test the complete route from payment creation to bank acknowledgement, booking and statement reconciliation. A format conversion between systems can change references or move information into different fields. Your controls should detect rejected files, duplicate submissions, unprocessed transactions and unmatched statement entries.
4. Keep operational fallbacks current. Document what happens if an ISO 20022 file fails validation or a connection is unavailable. Teams should know how to identify the error, who to contact and which approved fallback can be used without weakening payment controls.
5. Monitor each bank's roadmap. Bank-specific timelines still matter. Ask banking partners about planned message-version upgrades, the retirement of legacy statement formats, testing windows and changes to mandatory data. Include technology providers and administration-platform vendors in those conversations.

What good looks like after migration

Success is not simply receiving an XML file without a validation error. A sustainable operating model should make the data understandable and controllable throughout its lifecycle.

• Clear ownership: someone maintains the inventory of banks, channels, message versions and bank-specific usage rules.
• Representative testing: test packs cover routine payments and statements as well as missing data, charges, returns, rejections and other exceptions.
• Visible service measures: teams monitor rejected files, unmatched transactions, repair volumes and recurring data-quality issues rather than discovering them case by case.
• Controlled change: bank notices, message-version upgrades and mapping changes move through documented assessment, testing and release processes.
• Preserved information: integrations retain the structured source data needed for reconciliation, reporting and investigation instead of flattening it too early.

The objective is a traceable path from the originating system to the bank and back again. When an exception occurs, the team should be able to identify where the data changed, who owns the next action and whether the same issue affects other accounts or banks.

Where Flinq fits

Flinq supports CAMT and PAIN formats alongside bank-specific formats. This allows a TCSP to receive and normalise information from different banking partners without assuming that every bank has implemented ISO 20022 in the same way.

The value now lies in making the richer data operational: validating it, preserving it through integrations and using it to improve reconciliation and reporting.

Check your live ISO 20022 connections

Review your current bank formats, data quality and end-to-end processes with the Flinq team.

Identify the remaining gaps