SWIFT RMA / RMA Plus

Permission controls for Swift financial messaging.

Plain English

What is Swift?

Swift is a secure global messaging network used mainly by banks and other financial institutions to exchange standardised financial instructions and information.

Financial institutions use Swift to communicate securely with each other about payments, securities, trade finance, account information and other financial activities. [1][2][3]

One important thing: Swift does not move the money

A Swift message can tell another financial institution what needs to happen, but the message is not the money itself.

Swift provides the secure messaging infrastructure. The actual movement of funds takes place through banks, payment systems, fintechs and other financial institutions. [1]

For example, a Swift message might effectively say:

“Pay £50,000 to this account.”

Swift carries the instruction.

The relevant financial institutions process the actual payment.

What is a Swift message?

A Swift message is a standardised financial instruction or piece of financial information sent from one institution to another.

Different messages have different purposes.

Examples include:

• 💸 Payment instructions Instructions to make or process a payment.

• 📄 Account information and statements Balances, transactions and reporting information.

• 🏦 Bank-to-bank payment information

• 📦 Trade finance messages For example, letters of credit and related instructions.

• 📈 Securities and custody messages Settlement instructions, confirmations and reporting.

• 🔎 Confirmations and reporting messages Transaction confirmations, balance reports and other financial information. [2][3]

Important: not every Swift message automatically requires RMA. RMA applicability depends on the Swift service and the particular message type. [4]

What is RMA?

RMA is not the messaging system itself. Swift is the messaging network. RMA is a permission control around that messaging relationship.

RMA helps a financial institution control which counterparties are authorised to send it relevant Swift traffic.

A counterparty in this context simply means the other bank or financial institution involved in the messaging relationship.

Swift describes RMA as a filter that enables financial institutions to define which counterparties can send them relevant FIN traffic, with unwanted traffic blocked at the sender level. [5]

Swift's traditional description of RMA refers to FIN traffic. RMA is also used in the newer FINplus/MX environment, where current Wolfsberg guidance states that all FINplus messages require RMA. [7][11]

In plain English

The receiving institution is effectively deciding:

“Who am I willing to receive certain Swift messages from?”

Simple example

Imagine:

Bank A → Swift → RMA permission gate → Bank B

Bank A wants to send a financial message to Bank B.

• Bank A creates the financial instruction.

• Swift provides the secure messaging route.

• RMA controls whether the relevant messaging relationship is authorised.

• Bank B receives the permitted traffic.

Simple way to remember it

Swift = the secure road for financial messages.RMA = the gate controlling who is allowed to send relevant traffic toward you. 🔐

The road carries the message.

The gate controls access.

What does “blocked at the sender level” mean?

It does not simply mean Bank B receives an unwanted message and then deletes it.

The RMA control is designed so that unwanted FIN traffic can be stopped at the sender side before it reaches the receiving institution. [5][7]

That makes RMA a preventive messaging control rather than only a reaction after unwanted traffic has arrived.

What is RMA Plus?

RMA Plus makes the permission control more precise by allowing more granular control over which message types can be exchanged with an individual counterparty. [5][6]

That is all you need for now.

The detailed difference between RMA and RMA Plus is explained in the Professional view.

Why is RMA used?

RMA gives a financial institution greater control over the Swift traffic it is willing to receive.

Relationship Management is designed to stop unwanted messages before they leave the sender's messaging interface. Wolfsberg notes that this can reduce the time and effort involved in dealing with unwanted traffic and reduce exposure associated with processing it. [7]

Plain English

The institution decides:

“Who am I willing to receive these messages from?”

before the relevant traffic reaches it.

That is why the gate analogy works.

In practice

What does an RMA review look like?

Imagine a financial institution reviewing its existing RMA relationships.

One authorisation was established several years ago, but there has been little or no recent activity.

1. Situation

An RMA authorisation still exists with another financial institution.

The practical question becomes:

“Why is this permission still open, and do we still need it?”

2. Review

The team may consider:

• why the RMA was originally established;

• whether it is still being used;

• what types of messages are being exchanged;

• whether there is still a valid business requirement;

• whether it relates to a customer or non-customer relationship;

• whether the risk associated with the relationship has changed;

• whether the existing due-diligence position remains appropriate.

For non-customer RMAs, Wolfsberg recommends ongoing lifecycle management and suggests reviewing relationships to identify those that may warrant cancellation because they are no longer being used. [7]

3. Decision

Depending on the circumstances, the institution may:

• retain the authorisation;

• modify it;

• restrict it more precisely where appropriate;

• or revoke it.

Swift's Relationship Management Portal supports granting, modifying and revoking RMA authorisations. [8][9]

Why this matters

This is where RMA stops being only a technical Swift acronym.

It becomes a question of:

business need + messaging permission + risk + ongoing governance

Professional view

RMA vs RMA Plus

RMA provides the authorisation mechanism used to control relevant Swift messaging relationships between counterparties.

RMA Plus adds greater granularity.

Swift describes RMA Plus as allowing institutions to specify which message types they want to receive from, and send to, individual counterparties. [5][6]

Professional shorthand

RMA: Is this counterparty authorised for the relevant messaging relationship?

RMA Plus: Which message types are authorised for that counterparty?

How does an RMA authorisation work?

For incoming traffic, the receiving institution controls whether the relevant messaging relationship is authorised.

Swift's Relationship Management Portal includes functions to:

• grant authorisations to receive traffic;

• approve or refuse authorisations to send traffic;

• modify existing authorisations;

• revoke authorisations. [8][9][10]

The important concept is:

RMA represents permission around messaging. It is not simply a technical connection between two institutions.

RMA lifecycle management

An RMA should not simply be established and forgotten.

A practical lifecycle may involve:

1. A business or messaging requirement is identified

2. The relationship and relevant risk are assessed

3. The RMA authorisation is established

4. Messaging activity begins

5. The relationship is managed and reviewed

6. The authorisation may be modified if requirements change

7. The authorisation may be revoked when it is no longer required

Swift provides the technical ability to create, accept, reject, modify and revoke authorisations. Wolfsberg separately recommends ongoing risk-based management for non-customer RMAs. [6][7][9]

Important: this seven-stage sequence is a practical explanation of the lifecycle. It is not a prescribed seven-step Swift regulatory process.

Does an RMA mean two banks have a correspondent banking relationship?

No. Not necessarily.

Correspondent banking generally refers to a relationship in which one financial institution provides banking services to another financial institution.

An RMA has a different purpose.

It is fundamentally a messaging authorisation.

It should not automatically be treated as evidence that a correspondent-banking customer relationship exists.

Wolfsberg specifically distinguishes customer relationships from non-customer RMAs, demonstrating that an RMA can exist where the counterparty is not otherwise a customer of the institution. [7]

So:

RMA ≠ automatically a correspondent-banking customer relationship

and:

RMA ≠ replacement for KYC or CDD

What are KYC and CDD?

KYC means Know Your Customer.

CDD means Customer Due Diligence.

In simple terms, these are processes used by financial institutions to understand who they are dealing with, the nature of the relationship and the risks associated with it.

RMA has a different purpose:

RMA controls messaging permission.

It does not replace applicable KYC, CDD, sanctions, financial-crime or broader risk-management controls.

What is a non-customer RMA?

A non-customer RMA is generally created where a financial institution needs to send or receive Swift messages to or from another institution in support of a customer's business, while having no other customer relationship with that third-party institution. [7]

Wolfsberg gives examples involving areas such as:

• cash management;

• custody;

• trade finance;

• payment market infrastructures;

• securities market infrastructures. [7]

These relationships may involve transactional or reporting-only messaging.

Simple example

A corporate customer needs its bank to exchange messages with another financial institution to support the customer's business.

The two financial institutions may therefore require an RMA even though the second institution is not a customer of the first institution.

That is a non-customer RMA.

Customer vs non-customer RMA: why does the distinction matter?

Wolfsberg recommends distinguishing RMA relationships that support existing customer relationships from non-customer RMA relationships because the due-diligence approach may differ. [7]

Where an institution already has a customer relationship subject to due diligence, the requirements of that due-diligence programme apply.

For non-customer RMAs, Wolfsberg recommends a risk-based approach that considers factors such as the type of messages being exchanged and whether the relationship is transactional or reporting-only. [7]

There is also an important jurisdictional nuance:

The legal definition of a “customer” can vary.

Wolfsberg notes that in some jurisdictions the establishment of an RMA itself may be treated as a form of customer relationship and therefore become subject to risk-based due diligence. [7]

For an international institution, the correct question is therefore not only:

“What type of RMA is this?”

but also:

“How is this relationship classified in the jurisdiction that applies?”

Understanding FIN, FINplus, MT and MX

These terms matter because RMA requirements depend partly on the Swift service and message type.

What is FIN?

FIN is Swift's traditional structured financial messaging service.

It is strongly associated with traditional MT messages and has long been used for areas such as payments, securities, treasury and trade. [3]

What is an MT message?

MT means Message Type.

MT is the traditional Swift message format.

Different MT numbers represent different types of financial messages.

For RMA purposes, the important point is:

RMA applicability is not identical across every MT message type. [4][7]

What is FINplus?

FINplus is a Swift messaging service used for ISO 20022-based financial messaging.

It supports newer MX messages.

For RMA purposes, Wolfsberg's updated guidance states that all FINplus messages require RMA. [7][11]

What is an MX message?

MX is an ISO 20022-based financial message format.

These messages use the newer ISO 20022 structured messaging model.

Wolfsberg notes that the newer signed MX messages require RMA. [7][11]

What is ISO 20022?

ISO 20022 is an international standard and data model for financial messaging.

For a beginner, the useful mental map is:

MT = traditional Swift message formatMX = ISO 20022-based message format

and, at a high level:

FIN → traditionally associated with MT messagingFINplus → used for ISO 20022 / MX messaging

Which messages require RMA?

This is where the answer becomes more technical.

Do not use the rule: “Every Swift message requires RMA.”

Swift's own RMA training specifically teaches users to identify the message types for which RMA is mandated. [4]

For traditional FIN/MT messaging, the requirement is not identical across every message type.

Wolfsberg notes that a small number of legacy MT messages do not require signing and therefore do not necessarily require an RMA relationship. [7]

FINplus and MX messages

The position is different in the newer environment.

Wolfsberg's revised guidance states that:

• newer signed MX messages require RMA;

• all FINplus messages require RMA. [7][11]

Professional rule

Never determine RMA applicability from the word “Swift” alone.

Check the current:

Swift service → message type → applicable RMA requirement

Current example: admi.024

admi.024 provides a useful current example of how RMA arrangements can evolve as Swift messaging requirements change.

Swift states that:

• since November 2025, usage guidelines for admi.024 have been available for bilateral use through a manual RMA process;

• from November 2026, institutions will be required to receive admi.024, supported by an automatic RMA bootstrap that enforces its mandatory-to-receive status. [12]

What does that terminology mean?

Bilateral agreement An arrangement between two institutions.

Manual RMA process The relevant RMA permission is established through the normal authorisation process rather than being created automatically.

Automatic RMA bootstrap The required RMA authorisation is established automatically to support a mandatory messaging requirement.

Mandatory-to-receive Institutions covered by the requirement must be able to receive the relevant message.

Swift also states that, in this context, the target retirement dates for MT 199 and MT 299 remain under review. [12]

So this entry should not state or imply a fixed retirement date for those message types unless Swift later confirms one.

Is RMA still an “Application”?

Yes.

RMA still means Relationship Management Application, and Swift continues to use the RMA terminology. [4][6]

But the way institutions manage RMA authorisations has changed.

Swift moved RMA management from local interfaces to its central Relationship Management Portal.

Swift set 30 March 2024 as the final migration deadline. After that date, local RMA authorisations were no longer honoured on the network in the previous way, and management moved to the central portal. [13]

Today, the Relationship Management Portal supports operational activities including:

• searching RMA relationships;

• granting authorisations;

• modifying and revoking authorisations;

• approving or refusing authorisations to send traffic;

• managing authorisations in bulk. [8][9][10][14]

So someone working today may still say:

“RMA”

while actually managing those authorisations through Swift's Relationship Management Portal.

Professional judgement

What should experienced compliance professionals watch for?

This is where RMA becomes more than a definition.

An active RMA does not necessarily prove an active customer relationship

An RMA is a messaging permission.

The relationship behind it needs to be understood separately.

A non-customer RMA may exist specifically to support another customer's business. [7]

No recent traffic is a review signal, not an automatic answer

Wolfsberg recommends considering reviews to identify non-customer RMAs that may warrant cancellation because of non-use. [7]

The practical implication is:

“No traffic” should trigger a question, not automatically produce a revocation.

The institution still needs to understand why the RMA exists and whether the business requirement remains valid.

Reporting-only and transactional RMAs may carry different risk

Wolfsberg distinguishes reporting-only non-customer RMAs from transactional non-customer RMAs. [7]

Reporting-only relationships can present lower financial-crime risk because the messages do not initiate transactions.

Transactional relationships may require additional identification, risk assessment and screening.

This means two RMAs with similar technical configuration can require very different compliance treatment.

Sanctions considerations do not disappear because an RMA is considered lower risk

Wolfsberg notes that even where a reporting-only non-customer RMA may justify reduced financial-crime due diligence, sanctions obligations still need to be considered based on the information available to the institution. [7]

So:

Lower financial-crime risk does not mean “no controls”.

Message type matters

Due diligence should consider what messages the RMA holder actually uses and the risk associated with that activity. [7]

An RMA supporting reporting messages is not necessarily equivalent in risk to one that enables transactional payment instructions.

This is where granular messaging permissions such as RMA Plus can become particularly relevant.

Ownership matters

Wolfsberg recommends considering a designated accountable person for relevant RMA procedures. [7]

Without clear ownership, dormant permissions, outdated relationships and inconsistent reviews can become governance problems.

Local law can change the classification

A relationship labelled “non-customer RMA” under one institution's general framework may be treated differently under local law.

Wolfsberg notes that some jurisdictions may consider establishment of an RMA itself to constitute a customer relationship. [7]

For an international institution, the correct question is therefore not only:

“What type of RMA is this?”

but also:

“How is this relationship classified in the jurisdiction that applies?”

Key takeaways

Swift is a secure financial messaging network.

Swift messages carry financial instructions and information, not the money itself.

RMA is a permission control around relevant Swift messaging.

RMA helps control which counterparties may send relevant traffic to an institution.

RMA Plus adds more granular message-level control.

An RMA does not automatically mean a correspondent-banking customer relationship exists.

RMA does not replace KYC, CDD, sanctions or other applicable risk controls.

Non-customer RMAs require risk-based lifecycle management.

Not every traditional Swift MT message automatically requires RMA.

All FINplus messages require RMA under the current framework described in Wolfsberg's revised guidance.

RMA applicability should always be checked against the current Swift service, message type and applicable rules.

Official sources