[SWIFT] RMA evolution update

RMA evolution update IMPORTANT NOTICE!

Due to the global pandemic of COVID-19 and its associated challenges imposed on both SWIFT and our customers, SWIFT has decided to delay the enforcement date for live traffic from 4 April 2020 to 2 May 2020. This will give more time for customers who want to upload their distribution file before the activation date. The enforcement in T&T will be activated as planned on the 4th of April so customers can still test (self addressed) RMA authorisations as of then. An external communication is tentatively planned for the 18th of March to the full community.

Additional information: Tip 5023827 - Steps to centralise RMA Tip 5023550 - RMA evolution Frequently Asked Questions

Updates On 15/01/2020, SWIFT updated the application service profile (ASP) for the RMA service to include the message types supporting authorisations for interact services (xrma.006) If you need to exchange an authorisation for FINPlus, you will need to upload this ASP update in your messaging interface. During the warning period SWIFT noticed a lot of “dormant RMA” records (RMA set up before 2018 and for which no traffic was seen in last 24 months) triggering a warning (a FIN message sent for that dormant RMA relationship after 15 Feb). Because of that SWIFT also bootstrapped based on traffic from 2016 to 2018 to cover as well these dormant RMA’s. With this second round of bootstrapping SWIFT also took the traffic from February 2020 into account.

Summary

SWIFT is implementing the next step in the evolution of RMA (Relationship management application). This tip will describe the approach, implementation and customer impact of the project. This tip will be updated with more information once it is available. To provide an additional safety-net and protect customers from unwanted incoming transactions, from May 2020, all FIN traffic which is subject to RMA today for which a valid RMA relationship is missing or not respected will be nacked by SWIFT. This means that there is no change or impact for customers following their RMA obligations.

As part of the customer security program, security controls increased focus on managing and maintaining business relationships in scope of financial crime compliance. RMA is the technical implementation of these business relationships and aims to control traffic exchanged between institutions. Background and Limitations of the current model

The creation of RMA authorisations is based on a RMA-message exchange between 2 institutions. An institution sends an authorisation to his counterparty which allows the counterparty to send them traffic. When the correspondent accepts this authorisation, traffic can be exchanged. This exchange creates an authorisation to Receive at the issuer and an authorisation to send at their correspondents. Because only the "authorisation to send" can be used to control the traffic, the implementation has an inherent desynchronization risk for the receiving institutions which are subject to regulation on incoming traffic. This means RMA currently relies heavily on the behaviour of the correspondent institutions to process and respect the authorisations granted and compliance decisions could be circumvented or ignored by their counterparty

To address this risk, since 2016, SWIFT is recording all RMA revocations and NACKs all messages for which the authorisation is revoked, regardless if the correspondent bank has processed the revocation. The objectives of the next step in RMA evolution are: Give institutions strict control on ALL incoming traffic. A unilateral enforcement of RMA authorisations Provide a rich and easily accessible RMA reporting platform.

Approach To address the community concerns, SWIFT plans to complement the current RMA infrastructure with a centralised platform to enforce all RMA authorisations. To achieve this, the existing infrastructure that enforces the RMA revocations will be expanded to include all authorisations. This approach has the following benefits: SWIFT can expand on the existing platform, no need for additional channels No impact on existing institution's RMA procedures. No impact on interfaces or back-office integration.

While the primary responsibility and first check is still at the institution interfaces, SWIFT will record and enforce the authorisation to send and NACK every message for which the RMA authorisation has not been processed or respected. The aim of the project is to provide an additional safety-net to protect institutions from unwanted transactions. Next to the deployment of a centralised RMA, RMA+, or the ability to create granular authorisations down to the message type, will become available to every Alliance user for free. SWIFT will also provide access to an RMA portal to easily report on centrally stored authorisations using O2M. Central database bootstrap and RMA import functionality

SWIFT aims to have the full solution in place as of beginning of May 2020. The central database will be bootstrapped based on exchanged FIN traffic to ensure no existing traffic is nacked. The central database will be pre-populated based on: Bootstrapped authorisations: SWIFT will do an assessment based on historical statistical data related to the message exchanges. The assumption is that all currently exchanged traffic is covered by a valid authorisation and the central database will be populated with authorisation that will allow any kind of message to be exchanged between these sender and receiver. Bootstrapped authorisation will never override any existing authorisations or revocation. Recorded RMA Revocations: All authorisations which have been revoked since 2016 are recorded and will be complemented by the bootstrapped authorisations. Uploaded authorisations : SWIFT will provide an RMA upload functionality allowing the upload of authorisations currently stored in the interface. The uploaded RMA file will be treated as a partial file, the records will replace the bootstrapped authorisations including additional information like signature, expiration date and granularity and it will add new authorisations not detected during bootstrap . This step requires action from the community and while optional, highly recommended for RMA+ users. After the initial bootstrap, the central database will be kept up to date and synchronised by populating the newly exchanged authorisations centrally. Note : the RMA upload functionality will be made available in March 2020, a detailed user guide on the steps to upload the RMA records from the interfaces will be published and communicated through this tip.

RMA central enforcement for T&T Central RMA validation for FIN test and training will be available for self addressed messages as of 4 April 2020. Traffic addressed to counterparties will not be subjected to a central RMA check or storage. The reasons are: 1.RMA for T&T service is optional and customers can bypass this on the interface at any time. 2.The interfaces can not validate the relationship between a signing BIC and a BIC0 (which signing BIC can sign an RMA for which BIC0) RMA and ISO 20022 During consultations on the ISO 20022 program, the community requested assistance with the migration from existing FIN authorisations to corresponding MX authorisations. To cater for this request, SWIFT will do a translation of the centralized FIN RMA authorisations to their MX counterparts and a distribution file will be made available through the RMA portal in o2m for download. The translation allows institutions to start with a fully up to date and synchronized MX RMA database (reflecting the existing FIN RMA authorizations that are centrally known) and avoids the need to do a manual review, translation and recreation of FIN authorisations. The translation will be offered to the whole SWIFT community free of charge. See attached pdf for further details.