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.

ISO 20022 will impact all financial institutions and other users of the Swift network that initiate, process or settle cross-border payments along with the associated Payment Market Infrastructures (PMIs), though only the Cross-Border Payments and Reporting (CBPR+) messages are subject to the industry adoption timelines.

Irrespective of instruction method (Swift or non-Swift channels), all clients should develop and implement capabilities to store and process the enriched and more structured data available with the ISO 20022 messaging standard. This will allow non-Swift users to also benefit from the improved transparency, data quality, efficiencies and risk reduction associated with the adoption of ISO 20022.

While there are numerous benefits of migrating to the new ISO format, including richer and more structured data, Corporates (non-financial Institutions) are currently out of scope and not subject to the mandatory migration timelines.

We have a robust plan to complete the transition to ISO 20022 ahead of the November 2025 deadline, marking the end of the MT/MX coexistence period for payment clearing and settlement messages.

We are planning a market-side and client-side, BIC-by-BIC risk-based migration approach to convert clients and processes from MT to MX. We will be able to support both MT and MX instructions from our clients in all markets in which we operate.

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 in July 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 migration. This minimizes data truncation when translating an MX message to an MT payment instruction.

In 2024, Swift refocused the November 2025 adoption deadline on payment clearing and settlement messages. Retirement dates for the MT payment initiation, cash management and reporting messages are deferred beyond November 2025.

State Street will continue to accept MT message formats until the end of the coexistence period, which is November 2025 for the in-scope MT1xx and 2xx category message formats and a later date (to be determined) for the MT9xx category messages. Per Swift’s latest guidance, 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.

At this time, State Street is unable to support MX cancellation messages (camt), but this will be addressed prior to migration.

The timeline when State Street will begin sending outbound ISO 20022 MX messages to clients is to be confirmed.

Clients can continue to send MT messages until the end of the coexistence period, in November 2025 for the in-scope Payment Clearing and Settlement MT 1xx and 2xx category messages, and until further notice for the message types that have been deprecated, but supported after November 2025. Please refer to Swift’s CBPR+ Portfolio for the latest information. (You will need to log in via your Swift credentials.)

State Street has adopted Swift’s in-flow translation tool that converts the MX format into an MT message and embeds that MT message in the MX, allowing us to consume MX formatted instructions during coexistence. Although we have the ability to process MX messages by translating them into MX, we do not recommend the use of enhanced data in the MX messages prior to migration as this may result in the truncation of data.

Clients who send payment instructions to State Street via the Swift network will be expected to adopt the payment clearing and settlement message updates by November 2025.

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, and 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.

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, user guidelines as well as translation and readiness portal
  (Note: 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
• Swift Knowledge Center: Further information on ISO 20022 Customer Adoption Guide, Message Standards and Tooling for independent testing
• For further information on market practice and message formatting recommendations, please refer to the International Securities Association for Institutional Trade Communication (ISITC) Securities Related Payments guide (no login required)
• To support our clients, we are testing with all major vendor providers. Our scope for client testing is limited, focusing on clients with high volumes or complex requirements, and is driven by our internal development and testing milestones.

Swift has extended the coexistence period for MT9xx messages beyond November 2025. We will continue to send client statements and confirmations in MT format post November 2025.

We will provide an implementation date for outbound cash reporting messages in the ISO 20022 format when available.

We will continue to support these messages as long as they are supported by Swift.

No. Once the camt formats become available, our clients will have the option to choose between MT9xx or camt.xxx, but we are unable to accommodate both.

Yes. Since March 20, 2023, we have been able to receive and process camt messages in MX format using the in-flow translation and the Swift multi-format message described in this document.

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 during coexistence this may lead to data truncation.

• 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 code is recommended for all payment messages. Our initiation tools will have purpose code selection ability.
• LEI is to be used for Financial Institution parties in GBP payments. We will support clients with this requirement by looking up BIC to LEI cross reference when FI party is expressed with BIC.

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)

It is recommended that all Swift payments include a fully structured address as of November 2025. However, unstructured addresses will be accepted until November 2026. You will also have the option of using a ‘hybrid’ address (e.g., partial structured/unstructured data), which 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, such as ultimate debtor, ultimate creditor and initiating party.

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.

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.

Swift acknowledges it has been common market practice for debtors to instruct a customer credit transfer via MT103 but has highlighted this as improper usage and is strongly advocating for the industry to adopt the correct usage as defined by the ISO 20022 standard.

Swift has pushed the mandatory adoption of pain.001 and the retirement of the MT101 from November 2025 to a date yet to be confirmed.

State Street will accept both pain.001 and pacs.008 messages in accordance with the ISO 20022 beginning in November 2025. Longer term, Swift has noted that proper pain.001 usage is fundamental, and we anticipate mandatory action in the future.

Service level indicators currently populated in tag 72 should be mapped to the relevant tag in the MX pacs.008 or pacs.009 as indicated below. Other common tag mappings are included for reference purposes and are standard mapping from MT to CBPR+ MX.