What a Swift RMA authorisation controls

What an authorisation controls

Relationship Management is a service on SwiftNet, Swift’s messaging platform, that lets a Swift user control the messages it accepts from its counterparties. The Wolfsberg Group describes its objective as stopping unwanted messages “before they leave the sender’s messaging interface”.

That is the part most often misread. The filter sits on the sending institution’s own interface, not on the receiver’s. A message the sender has no authorisation for never reaches the network, so the receiver never sees it and has nothing to review or return.

According to the Wolfsberg Group’s 2024 guidance, a Swift user controls three things through RMA:

• Which other Swift users can send it traffic. Each authorisation names one counterparty, identified at BIC8 level.
• Which messages it can send. The authorisations an institution holds from others bind its own outgoing traffic.
• The validity period of the relationship. An authorisation can carry a start and end date.

RMA has governed Swift traffic since 2009, when it replaced Bilateral Key Exchange (BKE), the earlier arrangement in which pairs of institutions exchanged authentication keys. Swift states that RMA or RMA Plus is mandatory for user-to-user messages requiring an end-to-end signature, which covers most FIN message types.

The receiver grants the authorisation

Permission runs towards the sender and is granted by the party that will receive. An institution issues an authorisation to a counterparty, and that counterparty may then send it messages. Swift’s interfaces present the two sides separately.

An authorisation covers one direction. Two institutions that each send to the other hold one in each direction, issued separately. An institution that wants to stop receiving a counterparty’s traffic revokes what it issued; deleting an authorisation it holds only stops its own sending.

RMA Plus restricts by message type

A plain RMA authorisation permits a counterparty to send any message type that requires one. RMA Plus narrows it to specified types, so the permission matches the business the two institutions actually do.

Swift has defined business profiles that group message types, and an institution can assign an authorisation at different levels within those profiles. A counterparty that only sends account statements does not need permission to send payment instructions, and an authorisation narrowed to a reporting profile cannot be used to instruct one.

The Wolfsberg Group ties the two together: due diligence on the holder “should consider the message types used by the RMA holder and the risk associated with the activity conducted”. The profile is therefore part of the risk decision, not only a configuration detail.

RMA is set per service, not only for FIN

RMA is usually described as a payments control. It is wider than that. It governs SwiftNet services generally, and every authorisation names the service it applies to. SwiftNet 7.0 extended RMA from FIN to services built on InterAct and FileAct, so the same mechanism gates securities, trade, reporting and file-transfer traffic as well as payments.

Whether RMA applies to a given service, and how, is set in that service’s Application Service Profile rather than by one network-wide rule. Two institutions can therefore be authorised for one service and not for another, and an institution reviewing its authorisations has to look at each service it uses rather than at a single list.

The authorisations themselves travel over Swift: RMA uses an InterAct store-and-forward service to exchange authorisation messages between institutions. Where that exchange is not in place, authorisations can be loaded locally instead, through a bootstrap process.

This is also why RMA is not only a bank concern. Corporates, funds and market infrastructures that are Swift users hold authorisations for the services they exchange traffic on.

Every FINplus message needs an authorisation

Not all Swift traffic requires an RMA. The distinction is the signature. Every FINplus message is signed, so every one requires an authorisation. FINplus carries Swift’s ISO 20022 MX messages, including the CBPR+ payment messages. The legacy MT schema includes a number of FIN messages that are not required to be signed, and those do not need one.

Appendix A of the Wolfsberg guidance lists the MT messages that require no authorisation. They are confirmations, advices, statements and free-format messages, concentrated in categories 3, 6 and 9 and the n9x query and answer messages.

This matters on migration. An institution whose MT traffic with a counterparty ran without any authorisation needs one in place before the ISO 20022 equivalent can be sent. The Wolfsberg Group records that the migration became available in 2023 and must be implemented by November 2025, and that institutions should revisit their RMA due diligence because of it.

How an authorisation ends

An RMA authorisation holds one of four statuses: enabled, revoked, rejected or deleted. There is no expired status. An enabled authorisation stays valid until the issuer revokes it, the counterparty deletes it, or its validity period ends.

• A validity period is optional. An authorisation can be issued as timebound, with a date it is valid from and a date it is valid until. It is not a required field, and Swift publishes no default period and no maximum.
• Expiry is not a status change. The record stays enabled and simply stops authorising traffic outside its window, which is why expiry shows up as a rejection at send time rather than as a state in the data store.
• Revocation propagates quickly. Swift operates a central revocation check that blocks traffic from a revoked counterparty within 15 minutes of the network acknowledging the revocation message.
• Nothing is purged automatically. Deleting authorisations for counterparties that no longer exist is a controlled function an interface must support, not something it does on its own.

A warning before a validity period ends is an optional item in Swift’s RMA interface conformance framework, intended to allow prolongation and avoid unexpected rejections. The interface conformance statements published in January 2025 for Alliance RMA, Finastra’s Total Messaging and Bottomline’s GTExchange each record support for it, so most institutions have the warning available without it being guaranteed by the standard.

Authorisations are managed centrally

Swift moved authorisation management off each institution’s local interface and into one central service. In Swift’s words, “from November 2021 until December 2023, the existing Relationship Management Application (RMA) solution used on your local interface will be gradually replaced by the central Relationship Management Portal provided by Swift”.

What moved is management, not filtering. The local interface keeps a data store that the outgoing message is checked against, fed from the portal through distribution files and queues. Institutions can delegate portal management, and order additional distribution queues, through Swift’s ordering pages. RMA is built into Alliance Access and Alliance Entry, and Alliance RMA is also available as a standalone product.

The due diligence the guidance expects

The Wolfsberg Group published its Guidance on Swift Relationship Management Application (RMA) Due Diligence in 2024, supplementing its 2022 Financial Crime Principles for Correspondent Banking and retiring its 2016 RMA guidance.

It bounds the risk carefully. Using an RMA for a purpose not intended when it was established is, in its words, “predominantly an operational risk, not a financial crime risk”. The financial crime concern it names is narrower: poorly controlled arrangements may give counterparties with inadequate systems and controls access to international banking systems, for example where an institution receives and acts on payment instructions from a non-customer.

The guidance divides authorisations by whether the holder is a customer. A cross-border transactional or liability account relationship requires an RMA, and the institution’s existing customer due diligence applies to it. A non-customer RMA is created where the institution sends or receives messages to a third party in support of a customer’s business and has no other relationship with that third party. Non-customer authorisations are then split again.

Institutions classify their own message types as transactional or reporting. The guidance also asks them to control approval of requests, to consider designating an accountable person for the procedures, and to bring relationships newly in scope into the programme within a reasonable period.

What the directory shows

The minimum the Wolfsberg Group recommends for a transactional non-customer authorisation is narrow: name and address, a risk evaluation based on that information, and a review against watchlists. The Elucidate directory holds the public record behind each of those, matched to the BIC an authorisation names.

Because an authorisation is issued at BIC8 level, the institution page for that BIC8 is the unit to check. Where a counterparty holds no BIC, and so cannot be an RMA counterparty, the directory still carries its register entry.

Identification and assessment stay separate. The fields above are the public record, drawn from Swift, GLEIF, the sanctions lists and public registers. The assessment is a separate product: the Elucidate FinCrime Index scores an institution’s financial crime risk, and that score is not one of the directory’s published fields. It can be had for the counterparties in your file — ask what the index covers.

What the directory does not do matters as much for a file that will be reviewed:

• It identifies; it does not assess. A listing is a status set by the authority that publishes it, not an assessment by Elucidate. The assessment is a separate product you can put next to it: the Elucidate FinCrime Index scores the same counterparty, on one method for every institution it covers.
• Sanctions matching covers the BIC and its LEI. Institutions that hold no BIC are not screened, and a missing match does not mean that no listing applies. Screen against the official lists.
• It does not apply ownership rules. An institution owned by a listed person can be subject to sanctions without being listed itself. See when sanctions reach the companies a listed person owns.
• Group data is consolidation, not control. Group membership follows the accounting-consolidation relationships reported to GLEIF. It does not show ownership shares or control.
• Register coverage is partial. Bank licences from national supervisors are not tracked, and absence from a register is not evidence that an institution is unregulated.

Each field’s source, how it was matched and what it excludes are set out in the directory’s methodology.

Swift does not define a dormant authorisation

An authorisation that is no longer used stays effective. Swift’s 2016 information paper puts the exposure plainly: institutions “may therefore have a large number of inactive RMAs in place, and may not even be aware of them”.

Swift uses the words active, dormant and unused as groupings, in Compliance Analytics and in its information papers, but publishes no threshold that separates them. What is measurable is the date of last traffic. Swift’s RMA usage review supplies a file of counterparties, enabled inbound and outbound authorisations, the type and volume of traffic exchanged and when the last transaction with each counterparty occurred, assessed over a 12-month window. Swift Services can also carry out the removals, notifying the counterparties and creating the RMA messages once the institution approves. Swift now presents the review within its Business Intelligence Services as Relationship Management Application analysis.

The Wolfsberg Group’s ongoing-management procedures are to “consider a review of relationships to identify those that warrant cancellation due to non-usage”, and to screen against watchlists periodically to the institution’s own standards. Its retired 2016 edition went further, asking for periodic review of message volumes to judge whether changes in usage warranted further due diligence or cancellation.

One practical asymmetry follows from the design. An interface can list the authorisations due to expire, because the dates sit in its own data store, but it does not hold last-traffic dates. Identifying unused authorisations needs centralised traffic data, which is why the usage review exists as a Swift service rather than an interface report.

What an RMA is not

• Not an account. An authorisation permits messages. Settlement runs through nostro and vostro accounts, which are opened and closed separately. See how a cross-border payment travels.
• Not due diligence, and not evidence of it. An authorisation records a permission. It carries no assessment of the counterparty, and its existence says nothing about what checks preceded it.
• Not a correspondent banking relationship. Non-customer authorisations exist precisely where the two institutions have no other relationship. See correspondent banking due diligence.
• Not a public record. Authorisations are bilateral, held in Swift’s central service and the two institutions’ interfaces. No public source lists which institutions have authorised which.
• Not a network-neutral term. Other messaging networks and market infrastructures control which participants may send to whom in their own ways, under their own names. RMA is specifically Swift’s service, on SwiftNet.
• Not a “Reciprocal Mutual Agreement”. Several web pages give that expansion. RMA is the Relationship Management Application, a Swift service.

Sources

• Wolfsberg Guidance on Swift Relationship Management Application (RMA) Due Diligence, 2024, which replaces the retired May 2016 edition. The Wolfsberg Group.
• RMA and RMA Plus: managing your correspondent connections, information paper, July 2016, and the accompanying news item, 10 July 2018. Swift.
• RMA Service, training catalogue, which states the November 2021 to December 2023 migration window. Swift.
• Relationship Management Portal, ordering pages, on portal subscription, delegation and distribution queues. Swift.
• Business Intelligence Services, which carries the Relationship Management Application analysis and the RMA Usage Review and Removal Service factsheet, March 2017. Swift.
• Compliance Analytics, on RMA overviews and the status and evolution of RMA relationships, updated monthly. Swift.
• About RMA, Axway Financial Exchange documentation, on the authorisation record, per-service scope and the Application Service Profile. Undated vendor documentation, consistent with Swift’s conformance statements.
• RMA Interface Conformance Statement: Alliance RMA, January 2025, on the mandatory and optional features of a conformant RMA interface. Swift.

Reviewed 5 November 2026. Swift’s RMA service descriptions, operations guides and business profiles handbook are available only to Swift users, and interface behaviour varies by product and release: confirm the current position with your Swift administrator. This is not legal advice.

Cite this page

Use this reference to cite the guide. Add the date you read it if your citation style asks for one.