ISO 20022 is a new global financial messaging standard that allows for more structured and rich data content. March 20, 2023, marked the official start of an industry-wide transition to ISO 20022 (MX) messaging across the Swift network for payments, confirmations and reporting messages (FIN/MT), using the Cross Border Payments and Reporting schema definition (CBPR+).

Swift will support both MX and MT message types until November 2025, the “coexistence” period, at which time Swift will retire general usage of the in-scope FIN/MT payment and cash messages, and all market participants are expected to have converted to MX messaging.

Read on for more information regarding State Street’s approach to this transition.

Who is driving the transition to ISO 20022?
This is an industry-driven transition. In 2018, the Swift community announced its intention to adopt ISO 20022 messaging for cross-border payments and reporting.

What are State Street’s timelines for ISO 20022 migration?
We are aligned with industry transition dates. For markets in which State Street is a direct participant of the payment system, transition dates are established by the regulator:

• Europe’s Target2 converted on March 20, 2023
• Canada's LYNX and Australia’s RITS began sending MX messages to State Street on March 20, 2023 and as of October 2024, we are now sending MX instructions to both LYNX and RITS
• United Kingdom CHAPS migrated all payments (both incoming and outgoing) in June 2023
• Hong Kong CHATS and US CHIPS migrated to MX messages in April 2024 (both incoming and outgoing)
• Fedwire will transition last in March 2025

Regarding the ISO 20022 milestones for CBPR+, we have been able to receive and process MX messages from our clients using Swift’s multiformat mode, which includes the full MX message with an embedded MT translation, since March 20, 2023. Consistent with other industry participants and the recommendation of Swift and other market infrastructures, we recommend clients continue to use the MT message, or like-for-like, data content (e.g., refrain from using the enhanced data elements available with MX messages) when instructing payments in MX format until later in the coexistence period. This minimizes data truncation when translating an MX message to an MT payment instruction.

What is State Street’s approach to the ISO 20022 migration during the “coexistence” phase?
State Street will continue to accept MT message formats until the end of the coexistence period, which is until November 2025 for the in-scope MT1xx and 2xx category message formats and a later date (to be determined) for the MT9xx category messages. Earlier this year, Swift announced that certain MT message types, including category 9xx (e.g., confirmation and reporting) messages, exception and investigations messages, and the MT210 advice to receive messages will continue to be supported beyond November 2025.

Our systems have been enhanced to support both FIN and FINplus/MX messages during coexistence, and we are able to receive and process MX cash messages from our clients. The timeline when State Street will begin sending outbound ISO 20022 MX messages to clients is still to be confirmed.

When will State Street mandate clients send MX/ISO formatted payment instructions?
Clients can continue to send MT messages until the end of the coexistence period — in November 2025 for the in-scope MT 1xx and 2xx category messages, and at a later date for the message types that have been given an exception. Please refer to Swift’s CBPR+ Portfolio for the latest information. (Note you will need to log in via your Swift credentials.)

What will the impact be during coexistence?
During the coexistence period, we will continue to accept MT messages and provide MT reporting. We will communicate ISO 20022 client migration plans when our timelines for development and testing work are confirmed. If clients send MX formatted instructions to State Street during this period, we have ensured the ability to consume the MX instruction by having implemented the processing of the Swift multiformat message — a solution in which Swift translates the MX format into an MT message and embeds that MT message in the MX. If clients use enhanced data in the MX messages, this can result in truncation of data.

What can clients do to test their readiness? What tools are available?
Our scope for client testing will be limited and driven by our internal development and testing milestones. We strongly recommend that clients familiarize themselves with the documentation and message verification functionality that is available within the Swift MyStandards portal, and leverage the industry testing tools available to support readiness.

These resources include:

• Swift MyStandards: Access to CBPR+ message schemas and a translation library, MyStandards | Swift (You will need to log in via a Swift account to access the above link)
• CBPR+ Sample Library: Access to several message type samples provided by Swift
• Test Sparring Partner: Access to an integrated testing tool that simulates real-world messaging conditions. We are currently compiling a comprehensive client information pack that we will distribute in due course

How will State Street handle statements and reporting? Will you continue to send MT900/MT910/MT940/MT942/MT950 messages in the Swift MT format?
We will provide an implementation date for outbound cash reporting messages in ISO 20022 camt format when available. At this time, implementation is still planned for 2025. As noted previously, Swift announced earlier this year that the coexistence period for MT9xx messages will be extended beyond November 2025. In cases where a receiver is not capable of processing MX messages, we will continue to use the Swift MT 9xx series during the coexistence period.

Will State Street generate both MT9xx and camt.xxx messages based on demand?
No. Once the camt formats become available, our clients will have the option to choose between MT9xx or camt, but we are unable to accommodate both.

Can State Street receive camt.052, camt.053 and camt.054 messages instead of the equivalent MT9 xx?
Yes. As of March 20, 2023, we have been able to receive camt messages in MX format.

How long will State Street continue to generate/support MT9xx series messages?
We will continue to support these messages as long as they are supported by Swift.

What do State Street’s clients need to do longer-term, to ensure ISO 20022 readiness?
Since additional data requirements are being introduced with ISO 20022, clients should (where relevant) enhance their IT systems, improve static data quality, and most importantly obtain and update their counterparty databases with complete address details.

We advise our clients to:

• Check whether adjustments to your IT systems are necessary to support ISO 20022 payment information in the account statement and reconciliation feeds
• Prepare to provide structured postal addresses, include purpose codes on payments instructions and legal entity identifiers (LEIs) for payment beneficiaries

We also recommend that clients familiarize themselves with the documentation that is available on the Swift Standards page.

What are the requirements around structured data and additional data elements?
During the coexistence period, the recommendation is to avoid the use of structured data formats. Structured data means that individual data elements are positioned in specific fields (e.g., zip code in its own field, apartment number in its own field, etc.) rather than having blocks of undifferentiated text. Once used, structured data will support increased straight through processing (STP) throughout the processing chain but may lead to data truncation during coexistence.

We also strongly encourage clients to include purpose codes and legal entity identifiers (LEIs) for payment beneficiaries on the payment instruction across all markets. Purpose codes and LEIs are required for payment beneficiaries on payment instructions in certain markets. Effective May 2025, both are required for GBP payments clearing through UK CHAPS (State Street has approval from the Bank of England to comply with this mandate by the industry date of November 2025).

For more information on purpose codes, please refer to the following resources:

• UK recommended purpose code list: RTGS Renewal Programme - UK recommended purpose code list (bankofengland.co.uk)
• External code sets contained in the ISO 20022 catalogue of messages: External code sets | ISO 20022 (iso20022.org)

When will it be mandatory to send structured data for debtor and creditor parties?
Starting in November 2025, the recommendation is that all Swift payments include a fully structured address. However, unstructured addresses will be accepted until November 2026. You also have the option of using a ‘hybrid’ address (e.g., partial structured / unstructured data) — this will become the minimum requirement from November 2026. In this hybrid format, at a minimum, the town name and country code must be structured (other data elements can be structured or unstructured). A maximum of two unstructured address lines can be provided and they must not repeat any of the structured data. Currently, you are only required to use structured addresses if you are referring to parties that do not exist in MT.

What is State Street’s approach to adopting enriched data?
The major payment market infrastructures (T2, CHAPS, FED/CHIPS, CHATS, LYNX and RITS) have already defined timelines for adopting ISO 20022, starting with the ability to use like-for-like mappings while enhanced formatting is available. In the next phase, the market (e.g., the payment market infrastructures and Swift CBPR+) will be moving toward making the enhanced formats mandatory, including structured addresses. We will start to use enriched information as and when these groups go live with mandating the enhanced ISO formats.

What is Swift’s latest guidance on the correct usage of pain.001 vs. pacs.008 messages?
Swift advised that in the current FIN/MT environment, the MT103 “Single Customer Credit Transfer” is being misused as a payment initiation request instead of the MT101 “Request for Transfer.” In the context of the ISO 20022 migration, this is creating some implementation inconsistency and confusion within the community. Swift stresses that when using ISO 20022 messages to request that an amount of money is moved from the debtor to the creditor, the pain.001 is the correct message for the debtor or initiating party to send to their payment service provider.

Who should I contact if I have further questions on the ISO 20022 migration?
Please contact your State Street client service representative if you have any questions or require further information.

For more details please refer to our Client Guide.