SWIFT gpi Tracker confirmation

This RFC describes the solution for implementing credit advise confirmation to SWIFT gpi Tracker for Ebury Partners UK to be compliant with SWIFT gpi Mandatory Service rulebook.

Background

SWIFT gpi (global payments innovation) is an initiative that improves the SWIFT customer experience by increasing the speed, transparency and end-to-end tracking of cross-border payments.

SWIFT gpi operates on SWIFT’s secure and resilient global platform. A SWIFT gpi member is a SWIFT user subscribed to the following gpi services:

  • gpi Tracker, enables gpi members to track gpi payments along the full payments chain

  • gpi Directory, a complete list of gpi participant financial institutions

  • gpi Observer, provides gpi members with a global view of their and other gpi member’s adherence to the gpi SLAs

Ebury Partners UK is a gpi member. It has a single connected BIC, EBURGB2L, registered under the SWIFT gpi Directory. This BIC is used for exchanging all MT messages on the SWIFT network across all the Ebury entities, which means that Ebury Partners UK acts as a correspondent bank for all the other Ebury entities. As a gpi member, Ebury Partners UK must be compliant with the SWIFT gpi Mandatory Service rulebook.

To be compliant with SWIFT gpi Mandatory Service rulebook, every credit under the beneficiary account for all credit advice received from Barclays must be confirmed to the gpi Tracker.

Problem

As a credit advice, from Barclays we receive MT103 Copy instead of MT910. For each MT103 received, we need to confirm it to gpi Tracker by sending status updates.

There are three status updates we need to send.

Confirmation of a Transferred Payment (ACSP, with appropriate reason code)

Confirmation of a Transferred Payment is sent when MT103 is forwarded to another financial institution. In our case, when EBURGB2L receives MT103s for a virtual account held by an Ebury non-connected BIC, e.g. EBURNL21, we need to send Confirmation of a Transferred Payment.

It must be sent immediately or by the end of the day at latest.

Confirmation of a Credit (ACCC, with appropriate reason code)

Confirmation of a Credit is sent when funds are credited to the beneficiary account.

It must be provided no later than 4 hours after crediting the beneficiary account.

Confirmation of Pending Payment (ACSP, with appropriate reason code)

Confirmation of Pending Payment is sent when it is not possible to transfer the payment or credit beneficiary account within the same day of the value date as it requires further processing.

It must be sent immediately or by the end of the day at latest.

Additional statuses

In addition to the above, there are also:

  • Confirmation of Rejected Payment, which we do not use as we do not reject MT103, so it is out of the scope of this project

  • Confirmation of Returned Payment, which is still not mandatory to be sent, so it is out of the scope of this project

Solution

Requirements

Ebury uses SWIFT Alliance Lite 2, which does not allow us to make an API connection directly with the SWIFT gpi Tracker. Therefore, we will use Santander’s infrastructure to connect to SWIFT gpi Tracker. Santander provided us with the API for sending gpi status updates to them, which they will pass further to the SWIFT gpi Tracker. Specification of Santander’s API and mapping between API parameters and MT103 fields is provided in this document.

We distinguish two main use cases:

EBURGB2L receives credit for a virtual account held by an Ebury non-connected BIC, in which case we need to send:

  • Confirmation of Transferred Payment (ACSP) status update

  • Confirmation of a Credit (ACCC) status update

EBURGB2L receives credit on pool account held by Ebury, in which case we need to send

  • Confirmation of a Credit (ACCC) status update

Confirmation of a Credit will be sent as soon as bank account entry is reconciled and relevant events are successfully processed (almost immediately, without delaying). However, in case when Confirmation of a Credit cannot be sent by the end of the day of the value date indicated in MT103, Confirmation of Pending Payment needs to be sent.

MT files of interest

MT files that are of our concern for this solution are MT103 and MT942.

MT103 are triggers for sending status updates to gpi Tracker, but also a source of information for generating messages to be sent to gpi Tracker. When MT103s are received and processed, they are stored in the FxSuite database.

MT942 are triggers for generating bank account entries to be reconciled with an account (client / pool). When MT942 are received and processed, each entry in MT942 is enriched with MT103 data (if it exists) and bank account entry is created in FxSuite and synchronised with BOS.

Bank account entry created in BOS can be automatically reconciled with an account or manually as a result of human intervention.

Status updates to gpi Tracker should be executed when:

  • MT103 is received and processed in FxSuite - Confirmation of Transferred Payment or Credit, depending on the account type (virtual, pool)

  • Bank account entry is reconciled in BOS, either auto or manual - Confirmation of a Credit

Proposed solution

We propose the following solution, taking into account future Ebury 2.0 architecture.

SWIFT gpi Tracker confirmation solution

We will use:

  • Existing services to receive and parse MT103 messages (FxSuite, Swift service and Transformer), reconcile bank account entries and credit accounts (BOS)

  • New service, SWIFT gpi Tracker Gateway, to store MT103 data, bank account entry data and their relations needed to send gpi status updates

  • New service, SWIFT gpi Tracker Interface, that will communicate to Santander’s API for sending gpi status updates

Sending gpi status update on MT103 reception

  1. FxSuite reads MT103 and MT942 files from AutoClient.

  2. For each MT103 received, FxSuite will publish a MT103 command event to Kafka topic to parse MT103 message.

  3. MT103 command event received in Kafka topic will be consumed by Swift service and parsed using Transformer parser. Swift service will publish MT103 received domain events.

  4. MT103 received domain events will be consumed by SWIFT gpi Tracker Gateway, that will process the events, store relevant information and publish MT103 gpi status update command events.

  5. MT103 status update command events will be consumed by SWIFT gpi Tracker Interface that will connect to Santander’s API to send relevant gpi status update: Confirmation of Transferred Payment, for MT103 of virtual account or Confirmation of Credit, for MT103 of pool account

Sending gpi status update on crediting account

  1. For each MT942 received, new bank account entries will be created in the FxSuite database. Existing synchronisation process will create new bank account entries in BOS based on the entries from FxSuite.

  2. Reconciliation of bank account entries in BOS will be done automatically where possible or manually with human intervention. Regardless of reconciliation mode, when reconciliation is done and the account is credited for the given amount, BOS will publish BAE reconciled domain events.

  3. BAE reconciled domain events will be consumed by SWIFT gpi Tracker Gateway, that will process the events, store relevant information and publish BAE gpi status update command event. At this stage, relation between BAE and corresponding MT103 needs to be established.

  4. BAE gpi status update command events will be consumed by the SWIFT gpi Tracker Interface that will connect to Santander’s API to send relevant gpi status updates: Confirmation of Credit.

Sending gpi status update at the end of the day

  1. In the SWIFT gpi Tracker Gateway there will be a process to check if for each MT103 message there is a corresponding reconciled BAE. If by the end of the day (predefined cutoff time) there is no corresponding reconciled BAE for the given MT103, a BAE Pending gpi status update command event will be published.

  2. BAE Pending gpi status update command event will be consumed by the GPI Tracker interface that will connect to Santander’s API to send relevant gpi status updates: Confirmation of Pending Payment.

Publishing events from BOS

For publishing events from BOS, we see two options:

  1. Using Change Data Capture process in BOS PostgreSQL

  2. Publishing events as a part of reconciliation procedure

The main benefit of using CDC to publish events is that it doesn't require adjustment of the existing code. The process is asynchronous and isolated of the existing processes. CDC process is already setup in BOS. For our implementation, we would need to extend existing setup.

However, at this stage we want to capture only reconciliation of the bank account entries that needs to be reported to the SWIFT gpi Tracker, which may be easier to identify during execution of the reconciliation process, which is the reason why we are considering publishing events from BOS via e.g. ebury-edm library during reconciliation process. The major drawback with this approach is the fact we need to interfere into existing process and amend the code.

We will evaluate both technical options for publishing events taking into consideration performance impact, ability to capture and filter out required data, level of legacy code adjustment etc.

Operations

New services will not have impact on existing operations.

Security Impact

Kafka events are encrypted in-transit (TLS) and at rest (MSK).

Performance Impact

As we will need to publish domain events from BOS, it may have performance impact on BAE reconciliation, depending on the technical implementation of publishing events. We will take it into considerations when selecting the best approach.

Deployment

For deploying required infrastructure, we will use Terraform. New services will be deployed in terraform-natonly.

For deploying code we will use Jenkins CI.