EUR Payment Execution via Swift Service (Barclays Frankfurt)

The purpose of this RFC is define how we will send EUR payments via Swift Service.

Problem Description

Today, we are releasing SWIFT EUR payments using our Ebury UK source account and we want to start to release our EURO payments using the Barclays Frankfurt source account. For releasing EUR payments, we are currently generating the MT103 message via FXSuite and then uploading it to AutoClient. As we had built on the past our Swift Service for managing all the information and files related to Swift Messages, we want to release our EUR payments using this service. The source account election is a process done by BOS and we need to change this in order to select the correct one. The source account will be related to the payment scheme selected and this will be assign when the payment was released from BOS.

Background

Nowadays, we are releasing all our Citibank payments via Swift Service using a route table in FXSuite. When the routing rules decide that a payment will be released via Swift, if we could find a source account on our route table with the currency, the beneficiary bank country and the Ebury Entity (for USD) with the information of our payment, this will be sent to Swift Service. We will include on our route table our Barclays Frankfurt source account for routing all our EUR payments via Swift Service.

If you want to know more about Citibank outgoing flow, please review this document or check this folder.

For releasing a payment, apart from the payment information received from BOS, we need to set some information in runtime like the source account and recipient and institution information. The recipient and institution information will be included on MT103 headers. This information will be selected after the routing rules execution because it depends on the scheme and the bank entity which will instruct the payment. The institution information will be always the same for releasing Swift payments because we can only do it under EBURGB2L BIC, but the recipient information will change. For Swift Barclays payments we are always hardcoding BARCGB22 as recipient information and for Citibank payments we are always using CITIGB2L. As we want to release our EUR payments under Barclays Frankfurt branch (BARCDEFF), we should implement a new logic for selecting this information in a runtime instead of using hardcoded values. This new logic will allow us in the future to release payments using different bank branches.

The source account election is a process done by BOS. Our proposal wants to change this in order to select the correct one. We are currently selecting always Barclays source account and then the routing rules are overriding this information with the proper one depending on the scheme and the bank branch intermediary selected. We are currently displaying a wrong information in BOS, because we show on the payment description that our payment was released with a Barclays source account, but then we are releasing the payment via FPS, SEPA or Swift Citibank without updating this information:

BOS_PAYMENT_INFORMATION

As we previously commented, when the routing rules decide that our payment will be released via Swift Service, we will publish the payment information to Swift Service (overriding the source account and selecting as recipient the Citibank BIC information). As we don't want to continue hardcoding information, when Swift Service is processing a payment, it's the moment to decide the source account and the scheme bank intermediary for releasing the payment (Barclays, Citibank, etc). So our current source account table in FXSuite will change it functionality. Now we will use it as a switch for sending payments via Swift Service if we found a source account on it (now it means that a payment will be released via Citibank). A source account should be related to a scheme bank intermediary but nowadays it doesn't contain the information needed for generate the MT103 (institution and recipients information). The decision of releasing a payment using an specific bank branch, comes from the operation's team.

Following the Swift message structure, a Swift message consists of the following blocks or segments:

  • Block 1: Basic Header Block. It contains institution BIC information. Ebury could only execute SWIFT payments under one BIC EBURGB2L.
  • Block 2: Application Header Block: It contains the recipients BIC (bank branch BIC)
  • Block 3: User Header Block
  • Block 4: Text Block (This will contain the source account information)
  • Block 5: Trailer Block

An example of a header MT103 is: {1:F01EBURGB2LAXXX0000000000}{2:I103BARCGB22XXXXN}{3:{111:001}{121:e9304f18-1a0c-4606-b49b-982d61b834dc}}

As you could see on the previous example, on blocks 1 and 2 we are populating institution and recipient information with the following structure:

  • BIC: EBURGB2L/BARCGB22
  • Logical terminal: A/X
  • Branch: XXX/XXX

To sum up, we need a new logic for getting this information in runtime (recipient, institution and source account) and we will get it using the payment scheme selected, the currency, the beneficiary bank country and the client's Ebury entity. For creating these new rules and select the correct source account, we need a system managing account's information in a proper way.

For creating post-execution actions related to an executed payment, the MT message generated will also contains on header the institution BIC and the recipients one. If you want to create post-execution actions in BOS, you could only do this when your payment scheme is SWIFT and the bank intermediary is Barclays (UK).

For executing post-execution actions, we could create MT199 and MT999 (restricted MT192, MT195, MT196). These two messages are created using references from the payment object (in FXS) and for header information, the system is extracting this information from the FXSuite Partner object (Ebury). The narrative get it from the filled textbox in BOS when creating the query.

For inbound post-execution actions, the system is checking if the payment exists in FXSuite and the query references match payment references (the system is nor checking BICs or headers information).

For outbound post-execution actions, the operation's team want to execute to them under London BIC for payments executed via Barclays Frankfurt. This means that on header information, we should include as recipient information the London BIC.

Solution - Outgoing process

Our proposal wants to include all the logic for managing internal bank accounts information in ADS, create a new service for managing source account rules in a new service (including the logic for recipients and institution information), create a new Transformer project for generating MT103 messages and the logic needed for routing EUR payments via Barclays Frankfurt.

We want to divide the project in three phases:

  • Execute EUR payments out from UK account: Build the minimum changes needed for release EUR payments via Barclays Frankfurt.
  • Include CRUD logic in BOS for managing internal accounts in ADS
  • Source account/scheme bank intermediary election in a new service: Select the correct payment source account and recipient information after executing the routing rules instead of hardcoding this information.

Phase 1

As we have a deadline for routing EUR payments via Barclays Frankfurt, we will include the minimum changes needed, hardcoding Barclays information in FXS, and then we will include all changes related to the source account election.

Here you could see an L3 diagram with the changes on phase 1 (green lines):

OUTGOING_EUR_PAYMENTS_PHASE1

The changes covered in this phase are:

  • Create a Transformer project for Barclays MT103 message generation.
  • Include a change in Swift Service for generating the MT103 message using Barclays or Citibank Transformer project depending on the BIC received.
  • Include a new bank scheme intermediary (Barclays DE) in FXS/BOS for Barclays Frankfurt. This new bank intermediary will be used for defining post-execution actions.
  • Include a change in FXS for routing payments with scheme_bank_intermediary Barclays DE to Swift Service.
  • Include a change for creating MT messages for post-execution actions.
  • Include Barclays Source Account on the route table in FXSuite.

Phase 2

The purpose of this phase, is including in ADS (Account Detail Service) the logic for managing our internal accounts information.

When the operations team is going to create an internal account, they have different possibilities (account types):

  • Business
  • Charges
  • Clients: Operation's team only creates this kind of account types
  • Office
  • A1

For other types of account (different from Client's one) they are created like private account (for not displaying these movements in BOS). This is quite interesting because we could review these accounts types and remove them in the future in a different project, in case we are not using them.

We will be focused on Clients account (from the operation's point of view, they only want to see movements in BOS from Client's accounts). These could be:

  • Private - Settlement accounts that shouldn't be displayed on BOS interface.
  • Collections (or settlement accounts) - For incoming movements.
  • Source accounts - For releasing payments.

Our proposal wants to include the internal account management as part of ADS (Account Details Service).

We will include the functionality to create, update, delete and get internal account information in BOS (CRUD) using ADS. As we cannot delete the current model in BOS, we will split the BOS form for generating an internal account in 2 forms:

  1. We will have a form (form step 1) with all the information needed for generating an account in ADS.
  2. When the account is created in ADS, an event will be generated.
  3. BOS will be subscribed to the event and when it receives the event, the bank account will be created in BOS.
  4. When a new internal bank account is created in BOS, the operation's team could edit it with information that we won't include in ADS (form step 2 - post-account information). This information is related to how we will use the internal bank accounts (main, syncs, allow preload movements, etc.), it's not information related to the account itself (IBAN, account number, BIC, etc.).

INTERNAL_BANK_ACCOUNTS

On the future, we want to redefine the way we are using these checks. If we try to simplify our flow, all our internal bank accounts are collections accounts (for debit or credit entries). Some of these checks are used for defining if we want to sync entries in BOS but we already have blacklists in FXS for avoiding the creation so it has no sense that we continue using these fields and that's the reason why we don't want to include this information in ADS. Basically, all these checks are defining if an account is a collection account, a source account or if it could be used in a funding group.

To sum up, our second phase will manage the internal accounts using ADS (Account Detail Service):

OUTGOING_EUR_PAYMENTS_P2

As per modeling in ADS, as part of this phase we include merging customer accounts and internal accounts in inheritance in database. More info in ADS modeling proposal: ADS internal accounts.

Also, because of unique in the IBAN and common tables we will need to update how segregated accounts are created and updated. More info in segregated accounts proposal: ADS internal accounts.

Phase 3

Today, we can release Swift payments via Barclays or Citibank but in the future we will have the possibility to release Swift payments using a different banks. The routing rules process should decide the payment scheme (Swift, SEPA, FPS) and the source account election should be done after the routing decides the scheme. Our proposal wants to create a new service (we could call it Payment Scheme Service) for managing these 2 processes (extract the routing rules from FXS to this new service will be covered in a different project).

We want to build a new service for selecting the payment source account. This service will receive some payment information (payment scheme, client's Ebury entity, currency and beneficiary bank country) and will return the payment source account and the bank branch for releasing the payment. Once we get this information and the payment was sent to Swift Service, this service will decide if the MT103 message should be generated using our Citibank or Barclays Transformer project. Then, we will upload the payment to AutoClient following our current Citibank flow.

Our new service should select a source account and bank entity based on scheme, currency, beneficiary bank intermediary and Ebury entity. We are including on these rules a new component "the Bank Entity". As we previously commented, we will need the bank entity information for indicating the recipient bank when we send the payment.

Once we have the Payment Scheme Service (PSS) created and working, we will include a change in FXSuite for selecting source account and recipients information in runtime and this will create a new event broker indicating the payment source account selected:

OUTGOING_EUR_PAYMENTS_P3

You could review the entire C4 model here.

Solution - Incoming process

As we are currently receiving MT940 and MT942 from Barclays Frankfurt using our new incoming flow with Transformer, we don't need to include any change for processing entries from Barclays Frankfurt. If you want to know more about this incoming flow, please check this C4 model.

For Barclays UK movements, we are using an enrichment process to extract the bank account mask from the MT103. As for Barclays Frankfurt we don't have bank account masks, we don't need to use this process. Furthermore, following Barclays Frankfurt documentation, the beneficiary account information should be received on the field 86 in the MT942.

Alternatives

  • Internal Accounts management as part of ADS (our proposal) and manage source account rules in a new service

    • Pro: We don’t mix the payments domain with account domain. “Source account” is a concept it becomes from the payments use of the accounts, not an account concept per se.
    • Pro: We don't need to create a new service for manage account information
    • Pro: ADS includes collections (settlements) accounts. An account could be used as collection/source account and it's better to manage account information on the same service for avoiding update accounts in two different services.
    • Con: Manage account information on the same service can make ADS too big triggering the usual problems when services grow: Hard to maintain, hard to scale, hard to manage and being a bottleneck if it fails.

  • Manage source account information in a different service

    • Con: We need to create a new service with new infrastructure, new CI process, etc.
    • Con: Manage account information in 2 different services (a collection account could be a source account at the same time).
    • Pro: Different account information in different services.

  • Manage all the account information in ADS like we are currently doing in BOS model

    • Con: Some fields are related to how we use accounts (i.e. if we want to sync entries between FXS and BOS). As we currently have 2 blacklists in FXS for avoiding entries creation (from MT940 and MT942) it has no sense to mark sync/don't sync account information in ADS. We don't want to include in other services information that will be removed on the future.
    • Pro: We don't need to create 2 step forms so we could reuse BOS forms.

Caveats

  • If we start to use bank account masks and we won't receive them on the MT942 as the documentation says, we should include a change for using the enrichment process.

Operation

For enabling this workflow we just need to include the Barclays source account on our route table in FXSuite.

Security Impact

To avoid payment fraud, we should follow SWIFT SCP and to do that, ACBalancer should be the only service with AutoClient credentials. As we will route our EUR payments via Swift Service, we will continue following this rule.

Technology

* Communication system: AWS - SQS/SNS
* Locking system: Redis
* Deployment: ECS - NAT-only cluster
* Active Monitoring system: Prometheus
* File generation: Transformer 3.7

Deployment

We will need DevOps help to deploy the new processes in production.