Friday, February 3, 2017

Using the Relationship Management Application

The Relationship Management application provides functions for managing authorisations for a business relationship.
When an institution consents to receive messages from a specific correspondent, that consent is recorded in an Authorisation in the Relationship Management application. A correspondent can send you messages only when you have authorised that correspondent to do so.
An authorisation is represented by different names in the Relationship Management application of each party. When you authorise a correspondent to send you messages, that authorisation is represented in your correspondent's Relationship Management application as an Authorisation to Send. That same authorisation is represented in your Relationship Management application as an Authorisation to Receive.

An authorisation can have a new version in preparation, which can be reviewed, changed by different operators until it is enabled and made the active version. An active authorisation stays valid until you revoke the authorisation, your correspondent deletes it, or the authorisation expires (based on the validity period of the authorisation).

The Relationship Management Application (RMA) enables the user to control which institutions
(BIC8s) can send traffic to them. RMA also enables the user to control the type of traffic that these
institutions can send. On FIN, this means that RMA enables the user to control which FIN Message
Types (MTs) its correspondents can send them.

RMA enables the user to issue authorisations to correspondents that the user wants a business
relationship with. Only correspondents that have accepted an authorisation from the user can send
that user traffic. Correspondents may only send the type of traffic that the user has allowed in the
authorisation. Similarly, the user can only send traffic to correspondents that have issued the user
with an authorisation-to-send.
Users cannot grant themselves an authorisation-to-send to a correspondent. Therefore, RMA
stops unwanted traffic at the sender. A sender must have an authorisation-to-send, issued by a
correspondent, before they can send traffic to that correspondent. Therefore, receivers of traffic
are in complete control of who can send them traffic, and what type of traffic.
RMA authorisations
Each authorisation 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. This resembles the way in which Bilateral Key Exchange (BKE) keys are stored in
the user's environment for direct management by the user.
When a user issues an authorisation to its correspondent, the correspondent stores the
authorisation as an authorisation-to-send (to the issuing user). The user (that has issued the
authorisation) stores an authorisation-to-receive (from that correspondent).
The following illustration shows this concept. When institution A issues an authorisation to
institution B, it sends an authorisation message to B, and at the same time it stores an RMA
authorisation-to-receive-from-B record. When institution B receives and accepts the authorisation
message, it then stores an RMA authorisation-to-send-to-A record.
Institution A issues an authorisation to institution B



RMA authorisation-to-send records enable the user to keep track of the correspondents that have
authorised them to send traffic to. RMA authorisation-to-receive records enable the user to keep
track of the correspondents to whom they have issued an authorisation: these are the
correspondents that the user is willing to receive traffic from.
Authorisations are XML messages that customers exchange over SWIFTNet by means of InterAct
store-and-forward messaging. Authorisations-to-send and authorisations-to-receive are RMA
records that the user stores in its local environment. The padlocks on the authorisation-to-send in
the illustration symbolise that an institution cannot grant itself an authorisation-to-send.

1 comment: