Table of contents
How does ISO 20022 implementation for cross-border impact different players in the industry?
ISO 20022 will impact all financial institutions active in cross-border payments as well as market infrastructures and corporate-to-bank flows, though only the cross-border payments and reporting messages are subject to the CBPR+ programme adoption timelines. Organizations will have to consider and implement solutions to process and store richer and more structured ISO messages that will impact the core payment application, middleware, reconciliation, AML/KYC, archiving, reporting applications, messaging interface and acquisition channels. To extract and realize the true benefits of ISO 20022, it needs to be implemented end-to-end. Payment MIs from major reserve currencies are live or plan to adopt ISO 20022 for domestic clearing and settlement, while the Corporate to Bank Market Practices (CGI) continues to promote wider acceptance of ISO 20022.
What standards management tools are available and where can they be found?
MyStandards is a web-based platform provided by Swift to facilitate the management and implementation of ISO 20022 (and FIN MT) standards and related market practice information. This collaborative platform provides access to the published guidelines (CBPR+ or market infrastructure-related guidelines), user testing via the Readiness Portal, and access to the Translation Rules, all available in MyStandards.
Will I be able to use FINplus as well as FIN for payments and cash reporting?
During the coexistence period, financial institutions will be able to send ISO 20022 (MX) for messages in scope of CBPR+. As a receiver, you may continue to receive FIN; ISO 20022 or multi-format MX messages (MX with embedded translated MT). The delivery format will depend if the payment message is processed by the Transaction Manager and on your preferred delivery format.
What are the different testing environments available for CBPR+ messages?
There are two messaging services available for the testing of CBPR+ messages: The FINplus Pilot Current replicates the message versions and features of the FINplus Live service, and the FINplus Pilot Future will be used to introduce new message versions and features. The CBPR+ changes for the SR 2023 will be made available for testing on Pilot Future in July 2023.
For more information, read the FINplus Service Description.
What is the cost of the FINplus migration? Are there extra fees?
The pricing for ISO 20022 messages has been published in an updated Price List for Messaging and Solutions.
Do I have to implement ISO 20022 for all flows at once or can I continue to send MTs?
You are free to choose which channel/format you use as a sender, including a mix of different channels/formats (FIN/MTs or FINplus/ISO 20022). For instance, you might want to prioritize a corridor for your migration to ISO 20022. Note that for payment and cash reporting flows, there is a migration period until November 2025. After this coexistence period, the MT messages on FIN will be removed for the MT1xx, 2xx and 9xx for the cross-border payments. This does not apply to the other MTs (3, 4, 5, 6, 7).
How will gpi be impacted by the ISO 20022 migration? If my institution is using MT for gpi confirmation and tracking today, when should we implement ISO 20022 for gpi?
Swift fully supports interoperability, payments tracking and interaction with the Tracker using either MT or ISO 20022 will be supported until the end of 2025, and each customer can adopt ISO 20022 at its own pace. In addition, during the coexistence period, the format and method of confirmation are independent of the underlying payment instruction. You can use the channel of your choice to confirm your MT 103 and pacs.008 messages. For example, you can use MT 199 messages to confirm your pacs.008 or trck.001/API to confirm your MTs 103.
How sender of messages being NAKed or abort on FINplus is notified?
There are 3 levels of validations performed by the Swift network.
Level 1 is the network validation, a NAK response back from the network is generated in case of failed validation against the CBPR+ Usage Guidelines or generic InterAct controls. The FINplus services also check for reused UETRs for all CBPR+ messages and valid Service Type Identifiers for gpi messages.
Level 2, is a new business validation rule introduced with Transaction Manager, including consistency controls of Instruction Identification, End-to-End Identification elements, message type or concordance of key data elements in Cover and Advice flows is introduced. In case of failure sender institution receives an abort (xsys.012 message). More information on the business validation rules < Knowledge Base article #5025819.
Level 3 of the error is related to the non-delivery of the ISO message. This could be due to the recipient not acquiring its messages for 14 days or too many failed delivery attempts on the recipient’s queue.
When is the latest to shift from local to central RMA?
All users must switch from local to central RMA management through the RMA Portal. After having activated the central management feature in the Portal, you will be creating and updating your RMA authorisations using its screens, directly updating the database used by the central RMA filter. Once local RMA is no longer supported RMA messages can no longer be exchanged over the Swift network and synchronization of local applications – if required, for local filtering, for example – will happen through distribution files pushed by the RMA Portal. The central RMA management features in the RMA Portal have been made available in January 2023, it is important to plan for those activities.
More information on RMA support page.
For data truncation, what is the scope change between the data visible on the case manager and data available in the transaction copy?
During the coexistence period a rich ISO 20022 message could be relayed with a legacy format that may result in data truncation. While market guidance has been published by CBPR+ to support the investigation process and limit the use of rich data, Transaction Manager and Rich Data Access respectively address the strategic and tactical risks of data truncation. Access to truncated data via case manager will be manual and scope limited to customer credit transfer based on the latest point-to-point data exchanged versus full transaction data with Transaction Manager.
Are the unpublished BICs allowed in the Header (DN) and the Payload?
Swift requires the emitted message to include both requestor and responder identification to process and route messages onto SwiftNet and at the receiver's site. In the scope of FINplus, Swift defines a service user by a non-wildcard level-3 Distinguished Name (DN). The Requestor and Responder DN must identify the services participant’s BIC, and branch code, registered within Swift through the BIC registration process. The BIC referred to in the DN's second segment must be published. The branch in the third segment can be published or unpublished.
More information in the Getting Started Guide.