Overview of Relationship

Management Application (RMA)

Introduction
• It is a service provided by SWIFT to manage the business relationships between FIs.
• The overall objective of RMA is to stop unwanted traffic at the sender.
• RMA enables the user to control which institutions can send traffic to them.
• RMA also enables the user to control the type of traffic that these institutions can send.
• By not receiving unwanted traffic, users save time and effort in treating this traffic, and are less exposed to
the risks of wrongly processing such unwanted traffic.
• This helps protect the users against audit, regulatory compliance risks, avoid fines and damage to reputation.
• Once an RMA user grants an authorization, it remains valid until the business relationship ends or changes.
• Each authorization results in two RMA records, one record at the issuer, and one record at the
correspondent. The RMA records are stored in the issuer's and the correspondent's local environment.
• RMA authorizations are always uni-directional (that is, one user authorizes another to send traffic).

The two parts of RMA

1. RMA management Software
• RMA management software is the software that each user operates in its local environment, to perform the
exchanges and store the resulting authorization records in the user's local RMA data store.
• Each authorization results in two RMA records, one record at the issuer, and one record at the
correspondent. The following illustration shows this concept.

Institution A issues an authorization to Institution B

Institution A Institution B
SWIFT
authorization authorization authorization authorization
-to-receive -to-send to -to-receive -to-send to A
from B from

Authorization

• When institution A issues an authorization to institution B, it sends an authorization message to B, and at the
same time it stores an RMA authorization-to-receive-from-B record. When institution B receives and
accepts the authorization message, it then stores an RMA authorization-to-send-to-A record.
• The padlocks on the authorization-to-send in the illustration symbolize that an institution cannot grant itself
an authorization-to-send.
• RMA authorization-to-send records enable the user to keep track of the correspondents that have
authorized them to send traffic to.
• RMA authorization-to-receive records enable the user to keep track of the correspondents to whom they
have issued an authorization: these are the correspondents that the user is willing to receive traffic from.
• Authorizations are XML messages exchanged over SWIFTNet through InterAct store-and-forward messaging.

Written and Published by Pradyumna Acharya B. Follow on LinkedIn by clicking Here for more such articles. 1
 2. RMA Traffic Filtering
• Applications (for example, SWIFTNet FIN interfaces) can make decisions to authorize traffic, based on the
authorizations that the RMA management software has stored.
• Traffic filtering occurs at both the sender's location and the receiver's location, as follows:
o When the sending interface sends traffic to a correspondent, the interface must check that the
traffic is authorized. If there is no matching authorization-to-send, then the interface does not send
the traffic.
o When the receiving interface receives traffic from a correspondent, the interface must check that
the traffic is authorized. If there is no authorization-to-receive, then the interface flags the traffic as
non-authorized (for example, puts it in an investigation queue).
• Filtering of received traffic offers a double assurance: RMA stops unwanted traffic at sender's location only.
• RMA filtering applies only to SWIFTNet FIN messages that require authentication. Ex: MT 1xx & MT 2xx
• If users want to exchange any unauthenticated SWIFTNet FIN messages with counterparty, then they can do
so without an authorization. Ex: MT 9xx

Permission lists
• If a permission list is present in an authorization, then message categories that are not explicitly included
(permitted) in the list, are by default excluded (not permitted).
• Example:
o include all messages in Category 1 & Category 2
o include all messages in Category 7, but exclude MT 760 and MT 761
This permission list permits all messages of Category 1, Category 2 and all messages in Category 7, except
MT 760 and MT 761. All other authenticated messages are excluded.

RMA queries and answers

• Institutions can use RMA to exchange short text messages, which are called RMA queries and answers.
• The query and answer mechanism routes the short messages to the RMA software of the correspondent.
• Individuals who manage relationships at the receiving institution can read these messages & reply to them.
• The advantage of this mechanism over e-mails (or MT 999s) is that the message reaches the appropriate
personnel within an institution that deal with correspondent relationships.
• Thus, even with correspondents with whom there is no relationship yet, there is no need to know a name,
telephone number, or e-mail address of any person at the correspondent.
• RMA query and answers also help to keep track of the entire conversation, together with the authorization.

Operations on authorizations
• A user can grant an authorization-to-send to its correspondent, so that correspondent can send them traffic.
• However, a user cannot grant themselves an authorization-to-send to send traffic to the correspondent.
• Only the correspondent can grant that user the right to send traffic. This is why a lock is shown on the
authorization-to-send records in the previous illustration.
• The issuer can issue authorizations and can, at any time, revoke authorizations.
• The correspondent that receives an authorization-to-send can accept or reject the authorization.
• If a correspondent rejects an authorization, then the issuer is notified.
• The correspondent that has accepted an authorization can decide to delete the authorization at a later stage
and the issuer is notified if a correspondent deletes an authorization.
• To modify an authorization (for example, to modify the type of allowed traffic within a service), the user
must issue a new authorization, replaces the previous one, to its correspondent.

Written and Published by Pradyumna Acharya B. Follow on LinkedIn by clicking Here for more such articles. 2
Flow 1 - Authorization Issued by Receiver & Accepted by Sender

Source: Axway Support

Step Description
1 The receiver creates an (authorization to receive). The receiver is the issuer of the authorization.
2 The authorization is stored in the RMA data store with the status "Enabled"
3 The authorization is submitted to the messaging interface
4 The authorization is received by the messaging interface of the correspondent, that is the sender of
the flow to authorize
5 The (authorization to send) is transmitted to the RMA application
6 The (authorization to send) is stored in the RMA data store with the status "To validate"
7 The user accepts the (authorization to send)
8 The (authorization to send) status is set to "Enabled". It will be taken into account at the filtering
time

Flow 2 - Previously Issued Authorization Revoked by Receiver

The issuer of an enabled authorization to receive (receiver of the authorized flow) revokes the authorization.
• The status of the authorization to end is set to "Revoked" within his data store.
• An RMA Revoke message is sent to the receiver of the (authorization to send).
• At the receiver site (sender of the authorized flow), status of the authorization to send is set to "Revoked".

Written and Published by Pradyumna Acharya B. Follow on LinkedIn by clicking Here for more such articles. 3
Flow 3 - Authorization Issued by Receiver & Rejected by Sender

Source: Axway Support

Step Description
1 The receiver creates an (authorization to receive). The receiver is the issuer of the authorization
2 The authorization is stored within the RMA data store with the status "Enabled"
3 The authorization is submitted to the messaging interface
4 The authorization is received by the messaging interface of the correspondent, that is the sender of
the flow to authorize
5 The (authorization to send) is transmitted to the RMA application
6 The (authorization to send) is stored in the RMA data store with the status "To validate"
7 The user rejects the (authorization to send)
8 The (authorization to send) status is set to "Rejected". It will be taken into account at the filtering
time
9 The rejection is submitted to the messaging interface
10, The rejection is received by the messaging interface and transmitted to the RMA application of the
11 issuer of the authorization
12 The status of the authorization is set to "Rejected" in the data store of the issuer of the authorization

Flow 4 - Previously Accepted Authorization Deleted by Sender

The receiver of an enabled authorization to send (sender of the authorized flow) deletes the authorization.
• The authorization status is set to "Deleted" within his data store.
• An RMA Reject message is sent to the issuer of the authorization to receive.
• The issuer of the authorization to receive (the receiver of the authorized flow) sees and processes the event
as a rejection of authorization.

Written and Published by Pradyumna Acharya B. Follow on LinkedIn by clicking Here for more such articles. 4