ISO 20022 MX Migration: Short-, Medium-, and Long-Term Priorities
On paper, SWIFT’s move from MT (Message Type) to MX (its ISO 20022, XML-based payment messages) might look like a low-level technical migration. But the switchover has been a big heavy lift for anyone involved. MX is a different philosophy. In the conventional MT format, the message structure was very limited, and at times it could not handle complex investment data, like multi-asset class transactions or other sophisticated requirements.
Now, we have a richer data model with MX, enabling straight-through processing for even the complex investment workflows that were previously manual. This data makes the transition quite significant and strategically critical for asset managers as well. In the short term, firms are focused on absorbing the change; in the medium term, they need to stabilize MX/MT coexistence; and in the long term, the real opportunity is to treat this as a data transformation play.
From cutover to coexistence: the new operational reality for asset managers
The ISO 20022 cutover has not been a clean, overnight switch. Readiness has varied. In our experience, most testing happened with the counterparties and brokers that deal directly with asset managers’ flows. Some of those counterparties were ready to test early, which gave us valuable feedback on what was working and what was not.
That early testing mattered because now we are supporting MX and MT together. The original plan was for all cash messages to be moved to MX by the November 2025 deadline. But certain messages that originally were going to be part of this November 25 deadline itself, were postponed, specifically the MT101 message and the MT210.i
Coexistence shows up very clearly in cash payment flows between banks. In the legacy MT world, if Party A made a payment to Party B, Party A would send a SWIFT message (MT103 for confirmation). Party B would receive a notification (MT210 for incoming funds).
In the coexistence phase, one side of that flow can move to MX while the other remains on MT. So, for a single payment now, you have to have this dual capability of supporting MX and MT. The trick is that the new MX format (pacs.008) contains much more data.
For asset managers, these messages represent real investor money moving in and out of funds through banks, custodians, and administrators, such as subscriptions, redemptions, and capital calls. If the objective is to send it to the respective counterparty, there might be multiple hops to other banks or intermediaries in the chain, especially with cross-border payments.
When different parts of that chain use different formats or interpret the MX standard differently, a single mismatch can delay a payment, trigger an exception, or create uncertainty about when cash will settle in an investor’s account or be withdrawn.
New mandatory data and the address scramble
One of the biggest practical changes in MX is with party and address information. In the MT world, address attributes were included in a structured way. In MX, they are now made mandatory for compliance reasons. That sounds like a simple field addition, but it has turned into a real data exercise for every firm in the chain.
Under the current rules, certain address attributes were made mandatory. Others remain optional. But regulators have also agreed to a temporary escape hatch. If address data is missing for a certain entity, a value “address line not provided” can be added. This flexibility gives everyone breathing room to keep payments flowing while they clean up their reference data, but it is not a long-term solution.
However, the harder part is sourcing the data consistently. For example, in many cases, brokers and banks must get address data from their banks, from their clients, from their brokers, and it is not possible to extract all the information from every entity on day one.
For asset managers, this transitional period means building processes and systems that can ingest address data from multiple sources, validate it, and feed it into payment instructions and reconciliations without creating new breaks. The firms that get this right will be able to move smoothly as more of today’s “optional” elements become mandatory in the next phase of ISO 20022.
Exception management as investor value
Even with MX in place, the basic rule of payments has not changed: Messages have to follow at least a certain minimum set of guidelines. If a required element is missing or mis-mapped, the payment can still fail, regardless of whether it is MT or MX.
What MX changes is the amount and richness of data that could be in the message. Right now, in MX, the standard supports plethora of information that could be sent out in the message. Some elements exist mainly to enhance and enrich payment data. That creates a new kind of exception landscape: Some breaks are about missing mandatory fields, but others are about inconsistent ways of populating optional fields across banks and brokers.
As of now, firms are focused on getting to a stable baseline, not on filling every possible field. Over time, people will start seeing the power of MX. When more and more information is added to payment messages, firms can start applying analytics or internal algorithms to track payments, such as better analysis of where payments are coming from, or how much is paid to a certain party over time.
Better payment message data will also eventually help track subscriptions and redemptions that do not post when they should, capital calls that miss a funding window, or fund-level payments that are held up for additional checks. Treating MX as a richer data source for investigations and analytics can eventually help improve liquidity management and the investor experience.
Looking ahead: turning MX data into an advantage
Right now, most firms are still in what I would call phase one of the MX journey. They are trying to get familiar with the format and meet whatever minimum guidelines have been set. The next phase is where the richer data really starts to matter, and you treat this more as a data transformation play than a one-off technical migration. For example:
- Improved cash visibility and forecasting: Structured remittance, purpose codes, and ultimate debtor/creditor feed treasury and capital-call calendars.
- Faster exception resolution: Richer fields show whether a break is missing data, a mapping issue, or a counterparty rule.
- Better compliance and AML: Standardized party and address data strengthens screening, sanctions checks, and cross-border transparency.
- Operational and liquidity analytics: Dashboards are available on where payments come from, how long they take, and which flows break most.
- Strategic differentiation: Firms that invest in MX data and cross-team usage will run leaner operations and give investors clearer answers.
In the end, the same MX fields that feel like extra work today are the ones that will power better decisions tomorrow. The more we see this as a data transformation opportunity, rather than just a technical conversion project, the more value we’re going to get out of it.
Authored By
Priyank Pradip Vora
Priyank works in Product Management at Arcesium, where he addresses complex technical and functional challenges by building innovative solutions that solve real-world problems. He brings experience in managing the complete product lifecycle — from discovery to launch — while focusing on understanding customer pain points and delivering products that drive real value.
Share This post
[i] SWIFT, 2025. https://www.swift.com/standards/iso-20022/iso-20022-faqs/implementation
[ii] SWIFT, 2016 (archived). https://www.academia.edu/33952843/SWIFTStandards_MT_General_Information
[iii] SWIFT, 2025. https://www.swift.com/standards/iso-20022/iso-20022-financial-institutions-focus-payments-instructions/document-centre
Subscribe Today
No spam. Just the latest releases and tips, interesting articles, and exclusive interviews in your inbox every week.
