About RMA

Relationship Management Application (RMA) is a service provided by SWIFT to help manage the business relationships between financial institutions. SWIFTNet 7.0 enables RMA capabilities for services based on InterAct and FileAct.

RMA consists of two main functions:

• Authorization: Customers exchange or create authorizations, indicating "who can send traffic to whom"
• Filtering: The customers' messaging interfaces apply these rules to control which traffic they can exchange with which correspondent

RMA uses a SWIFTNet InterAct Store and Forward service to exchange the permission data between financial institutions.

RMA usage is defined per service. The rules regarding its use are specified in the Application Service Profile (ASP), associated with each service.

Advantages of using RMA

RMA provides a SWIFT user with more control over the sending or receipt of messages in a many-to-many InterAct or FileAct service:

• It provides full control over the traffic received from a user's correspondents
• It allows customers to control the traffic they receive from other users in a many-to-many environment, thus ensuring that traffic is only exchanged with those users with whom they have a business relationship
• It can reduce operational risk – unwanted traffic is blocked at the sender's side when used on a bilateral basis
• It can enable the fine tuning of correspondent banking relationships – customers only receive the traffic reflecting the type of business that they conduct with their correspondent

RMA service parameters

As of SWIFTNet 7.0, service parameters, including those for RMA, are defined in the relevant Application Service Profile (ASP).

Service Administrators define the parameters of their service. Each Service Administrator must provide service participants with the information they need to correctly use the service in question, including RMA-related information.

SWIFT keeps track of all service parameter and makes them available to all participants in a downloadable ASP package.

RMA authorizations

Within the context of FIN and SWIFTNet services, RMA standardizes:

• How two partners agree to exchange documents (MTxxx for FIN, RequestType for InterAct/FileAct)
  • By exchanging authorization messages on a dedicated InterAct service
  • Or, for a transitory period, through a manual, local authorization process ("Bootstrap mode").

  Note: You do not have to renew an RMA authorization as long as the business relationship with your correspondent does not change.

  RMA authorization data model

  The following figure shows the data model of an RMA authorization.

  

  • The issuer is the sender of the authorization to receive, and therefore the receiver of the flow which is the object of the authorization. The issuer is identified by their BIC code
  • The correspondent is the receiver of the authorization to send, and therefore the sender of the flow which is the object of the authorization. The correspondent is identified by their BIC code
  • The service is the SWIFTNet service, object of the authorization
  • The status is the position of the authorization within the RMA lifecycle
  • The dateTimeIssued is the date of the beginning of the validity of the instruction contained within the authorization
  • The validityPeriod is the period of application of the permissions contained within the authorization
  • Permissions is a structure which depends on the service related to the authorization:
    • SWIFTNet service: The permission is a list of request type patterns and permission criteria which can have the value Exclude or Include
    • FIN service: The permission is a list of sub-structures (maximum one per category of FIN message). Each sub-structure is a list of FIN format patterns and permission criteria which can have the value Exclude or Include

    RMA authorization lifecycle

    When RMA is mandatory for a service, meaning when authorizations are exchanged, the initiator of the authorization exchange is always the receiver of the flow to authorize.

    Authorizing a flow

    

    Steps in the authorization flow:

    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 RA 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

    Refusing to send a flow

    

    Steps in the authorization flow:

    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 RA 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 "Enabled". It will be taken into account at the filtering time
    9	The rejection is submitted to the messaging interface
    10, 11	The rejection is received by the messaging interface and transmitted to the RMA application of the issuer of the authorization
    12	The status of the authorization is set to "Rejected" in the data store of the issuer of the authorization

    Deleting an authorization

    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

    Revoking an authorization

    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 (the sender of the authorized flow), the status of the authorization to send is set to "Revoked".

    Authorization to receive: state transitions

    This diagram shows the state transitions relating to authorization to receive.

    

    Authorization to send: state transitions

    This diagram shows the state transitions relating to authorization to send. Transitions from "Revoked" to "Rejected" and vice versa are not shown.

    

    RMA filtering

    FEX provides an RMA filtering exit that is used in conjunction with Axway Gateway. The exit is used by Gateway to interface itself with the FEX RMA Server to provide RMA capability.

    RmaQuery and RmaAnswer

    In some cases, Relationship Managers may wish to communicate with their peers within another organization to ask questions or to resolve problems with the authorizations exchanged.

    The free-format RmaQuery message can be used to do this. The response to an RmaQuery message is an RmaAnswer message. The peer Relationship Manager sends the RmaAnswer (in response to an RmaQuery) back to the sender of the RmaQuery.

    More information

    For more information about RMA, refer to the following SWIFT documents:

    • RMA Service Description
    • RMA Operations Guide
    • Relationship Management Application Vendor Specifications