Brexit - EEA ccy changes

As part of Brexit, Barclays notified us that on the 19th July 2021, Barclays will start to process payments to and from the UK as one-leg-out payments. All EUR and EEA payments executed from Barclays (across all branches) sent via MT103 will be charged international cross-border fees.

We are executing all our Swift payments using as the ordering bank the Barclays UK BIC EBURGB2L, which is connected to the Swift network and thus is treated as a payment coming from the UK (international): {1:F01EBURGB2LAXXX0000000000}{2:I103BARCGB22XXXXN}{3:{111:001}{121:de174cd0-f807-440c-b857-c8f940417220}}{4:

We need to migrate our EUR SWIFT payments to be executed under the new Belgium BIC.

The purpose of this document is to define the changes to be applied in our system for releasing Swift payments using a new Ebury Belgium BIC instead of the UK one (EBURGB2L).

This solution is a tactical feature for releasing EUR payments under the new Belgium BIC. After this deployment, it's mandatory to define properly where to include this logic (i.e. on the routing rules) and remove it from FXSuite.

Terms glossary

  • Payments with MT103 authorisation: Also known as “swift 3 payments” or “AUTH payments” or “Authorize in lite 2”. They are payments that need an extra validation once in Alliance platform.
  • Payments with MT103 authorisation Queue: Table shown in pre-execution view in BOS.

  • Verification method: The type of verifications/authorizations Ebury has to do over a payment. Right now:

    • No verifications need: swift0
    • One verification in pre-execution: swift1
    • Double verification in pre-execution: swift2
    • One verification in pre-execution + Alliance Lite2 verification: swift3
    • Manual execution: sif, bib, MT103

  • PaymentExecution: The process that sends payments from BOS to FXS.

  • verified_in_BIB_by: The flag that the BOS payment sending daemon is using to send the payments to FXSuite or not.
  • PR email send: Email with Payment Receipt sent to clients.

Background

A new on-boarding application by Ebury Partners Belgium for the connected BIC will be required.

AutoClient could be prepared to send/receive multi-bics files. The multi-BIC configuration allows customers that operate more than one BIC to upload and download messages and files of those BICs on a single AutoClient instance managed by the parent BIC with a single token/certificate. Different pre-defined multi-BIC configurations are available.

The multi-BIC configuration is a payable option available upon customer request. It can be requested either as part of the initial set-up services, or ordered as an additional configuration change request. This configuration is done by Swift and no changes on our AutoClient tokens/config needs to be done. For using the multi-bic function, a new folder structure is needed as we cannot upload MTfiles to different institutions on the same path.

Here you could see the changes and assumptions to using multi-bics configuration in Autoclient:

  • The UK BIC will be the Master and the new BE BIC will be the Child
  • The migration needs downtime, so this changes can be done during the weekend depending on the release calendar
  • Staging environment will be available for testing before going into production
  • New version of Autoclient does not support stopping payment in Alliance Lite 2 with the prefix "AUTH" in reference ( field 20). So, we loose the third verification in Alliance for payments.
  • The structure of the Autoclient folders will change. The UK folder will be duplicated for BE BIC:
    • EBURGB2L
      • emission
      • reception
      • fileact
    • BEBIC (We are waiting for the Belgium BIC information)
      • emission
      • reception
      • fileact
  • Autoclient configuration will remain the same, the token configuration is based on the master BIC, we don't expect any change
  • Payments Signature (LAU Key), the token configuration is based on the master BIC, we don't expect any change

Apart from the AutoClient changes, the MT103 format for the EUR payments should change. The new Belgium BIC as ordering bank institution should be included on header information and a change on field 72 with the sender bank should be also populated.

We are assuming that MT103 messages sent using the BE BIC as an ordering bank could send post-execution actions under the UK BIC. In that case, we don’t need to include any change in our system as the system is allowing post-execution actions when the payment instrument it SWIFT and the bank intermediary is Barclays UK or Barclays DE. AS we are not validating the sender institution, there's no impact on the post-execution flow.

Post execution payments are affected. All should continue as they are but for BarclaysDE intermediary that will use same sender as EBPBBEBB, the same as it was sent.

  • Payment Routing: SWIFT-EBURGB2L-BARCGB22 > Post execution: SWIFT-EBURGB2L-BARCGB22
  • Payment Routing: SWIFT-EBPBBEBB-BARCDEFF > Post execution: SWIFT-EBPBBEBB-BARCGB22 *

We will include a hack in BOS for allowing this to happen.

Payment’s confirmations (MT940 and MT942 messages) for payments executed from BE bank, will be received under the UK BIC.

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.
  • 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

On blocks 1 and 2 we are receiving institution and recipient information with the following structure: BIC: YOURCODE/YOURBANK Logical terminal: A/O Branch: XXX/XXX

Here you could see an example: {1:F01EBURGB2LAXXX0638464592}{2:O9420720201211CITIGB2LOXXX08692987842012110720N}{3:{108:01211MAF12250LON}}{4:

For parsing the MT942 files, we are not validating the institution BIC received in block 1, we are just using the recipient one for using the correct Transformer endpoint so no impact in our platform. The process for parsing MT942 will work for UK and BE BIC institutions.

We are assuming that there’s no impact on the entry creation nor the reconciliation process as we are not linking the ordering bank to our payments.

Payments with MT103 authorisation Queue in BOS

Currently, the payments that go through the “Payments with MT103 verification” queue in the Pre execution page in BOS, following the Payments algorithm, are sent to Swift Network with the prefix “AUTH” at the beginning of the reference field 20 in the MT103. Thanks to this prefix, those payments are sent to Manual approval in Alliance Lite 2.

Swift team informed that these customizations is a very old rule which is not compliant with Swift current Lite2 settings. This rule should be deleted. New possible rules to be included are based on currency, amount or type of MT message, but any of these rules reproduce the controls established under Ebury’s current settings.

“Payments with MT103 verification” queue in BOS has a particular verification method, which consist in the following steps:

  1. BOS calculates the queue the payment should be released through taking into account different criteria (explained below).
  2. Once the payment reaches the “Payments with MT103 verification” queue in Pre execution, a Payments team member performs all necessary steps to check the payment information and do the first check in BOS (called AUTH (MT103) ). Thanks to this first check, the payment message is sent to Alliance through FX suite with field 20: AUTH + PI. In Alliance, the payment is retained in the Message Authorisation queue until it is released from there.

  3. Another member of Payments team performs all necessary steps to check the payment information and, if everything is correct, execute the payment:

    1. From Alliance Lite 2 platform.
    2. Sending the Payment Receipt to the client, marking the payment as paid in BOS clicking on the “AUTH LITE2” button in the queue in pre pre-execution page. This action makes the payment disappear from the “Payments with MT103 verification” queue in BOS, it is marked as paid and it is awaiting the debit to be reconciled (the payment would be shown in the Post execution page in “Not debited payments” queue.
    3. All payments above 500K GBP or equivalent are stopped in Swift Payments Control tool upon Fraud team approval. This is applicable to payments sent from all queues in Pre execution, not only “Payments with MT103 verification”.

The payments that are currently being released through this verification method are those that meet the following criteria (Payment Algorithm).

  1. (Automatic) Payments allocated offline (from BOS by back office or front office) for amounts higher than 250K GBP or equivalent. BOS criteria cannot be covered with the new settings in Alliance because offline criteria would not be respected, but would cover all payments above that amount including those allocated online (which have different thresholds).
  2. (Automatic) Payments allocated offline (From BOS by Back office or front office) to a new beneficiary (beneficiary not paid previously) created offline (from BOS, via multi beneficiary file or simple creation, by back or front office). Alliance cannot cover these specific settings established in BOS.

pre-execution-view

Current permissions in BOS behaviour

  • Operation permissions: all users have access to Pre execution queue.
  • Management permission: 2 consecutive checks allowed in double verification queue in BOS.
  • The user who allocated the payment is not able to perform the first check on that payment, but will be able to do it for the next one.
  • Beneficiary verification permissions: separated and only assigned to australian and Canada offices + Payments team in Malaga.
  • Beneficiary creation via file or simple: granted with Operation permissions.

Solution - Incoming Flow

AutoClient Changes

We have several processes reading files from AutoClient:

  • FXS reading from reception folders (incoming funds flow):
    • /archive
    • /error/backup
    • /reception/FIN: MT9%% copied to this folder
    • /reception/MAN: FIN messages originated from GUI will be copied to this folder as well
    • /reception/RECON/: messages originated from Autoclient which are NACK/ACK. System messages (MT0%%) are copied to this folder
    • /reception/RECON/backup
  • AutoClientBalancer reading from the/error/ folder (discard payments flow)
  • AutoClientBalancer reading from the/reception/FILEACT/ABN (SEPA ABN incoming flow)

We will need to change these processes and the alarms related to these folders for reading from the new path /eburgb2l/:

  • FXS reading from reception folders (incoming funds flow):
    • /reception/EBURGB2L/FIN: MT9%% copied to this folder
    • /reception/EBURGB2L/MAN: FIN messages originated from GUI will be copied to this folder as well
    • /reception/EBURGB2L/RECON/: messages originated from Autoclient which are NACK/ACK. System messages (MT0%%) are copied to this folder
  • AutoClientBalancer reading from the /error/ folder (discard payments flow). This folder structure won't change. Only applies to incoming files folders
  • AutoClientBalancer reading from the /EBURGB2L/reception/FILEACT/ABN (SEPA ABN incoming flow)

Furthermore, as a new folder estructure will be also created under the Belgium bic, the system should also read files from these new paths.

FXSuite Changes

As the incoming funds flow was not moved to Swift Service, changes in FXSuite are required for reading files from new UK paths and the BE ones.

On the following image, you could see a diagram with the changes to be applied related to the Swift incoming flow:

swift_incoming_flow

The current process will be reading files from AutoClient using a setting in FXSuite. For reading files from the new Belgium BIC folders, we just need to include the new value on FXSuite settings.

ACBalancer Changes

As previously mentioned, AutoClient is receiving files for the incoming SEPA flow under the folder /reception/FILEACT/ABN so a new deployment should be done for configuring the new ABN path (/reception/EBURGB2L/FILEACT/ABN/).

One more change on settings is needed for the incoming error folder. The system is reading files from this folder for discarding payments. As the process it's only parsing the PID of the payment on the MT103 for discarding it, it does not matter where the file has been read for, the process just needs the key from S3.

On the following image, you could see a diagram with the SEPA ABN incoming changes:

sepa_abn_incoming_flow

Solution - Outgoing Flow

AutoClient/AutoClientBalancer Changes

The emission path structure won't change, so we only need to include changes related to MT103 mapping information in Transformer and FXS.

FXSuite Changes

In the past, we were always releasing our Swift payments using the EBURGB2L BIC as part of the basic header block (sender information). For the new sending flows, we have settings in FXSuite to define them for the different bank institutions and bank intermediaries:

  • BARCLAYS_UK_INSTITUTION_BIC
  • BARCLAYS_FRANKFURT_INSTITUTION_BIC
  • CITI_INSTITUTION_BIC
  • BARCLAYS_UK_INSTITUTION_BIC

But we have configured the same value for all the institution BICs (EBURGB2L).

As we now need to include a logic for selecting different sender information, we need to define where we should include this logic in our system. This information is not a technical decision and should be done by the operations team, so we suggest including this information as part of the routing rules.

The new routing rules project is returning the payment instrument and the bank intermediary for releasing a payment but it should also return the payment sender information instead of hardcoding this information for each payment.

As the routing project is not finished, we need to find a solution in the meantime.

As FXSuite is currently selecting the recipient/institution information when we route payments via Swift Service (Barclays DE, Barclays UK or Citibank). Our solution proposes to include the logic for selecting the institution information at this point when the currency selected is EUR.

Once we have the routing project done, we will move this logic out of FXSuite.

Transformer Changes

Following the requirements defined by product, we need to include some changes on the MT103 format for EUR payments.

On the following image, you could see a diagram with all the changes related to the outgoing flow (EUR payments):

swift_outgoing_flow

Pro

  • Routing table in FXS managing the information to be populated on the JSON payment information (Belgium BIC or UK one). As this information should be part of the payment, this logic should not be included as hardcoded information in Transformer. If this information is manage on the new routing rules in the future, operations team will have the capability of changing the payment routing without any development.

Con

  • This solution will include more logic into FXSuite and should be removed in the near future.
  • We will override JSON payment information for generating the MT103 but this information is not saved in our system. If ops team needs to check this value, it will be only contained on the MT103 generated or in the MT103 ACK/NACK received.

Changes for removing payments with MT103 authorisation Queue

BOS

Rules/criteria need to remain the same but instead of sending those payments to Alliance Lite 2, we need to retain them in BOS. The AUTH payment needs to be verified twice in BOS by 2 different ops members before being released automatically to Alliance Lite 2. The payment algorithm should be updated to the solution we will put in place.

Proposal 1: Merge swift3 into swift2

Moving the swift3 payments to swift2 and include the most restrictive constraints defined in swift3 to the swift2 as well:

  • Add new permissions group to the "Authorise" button in swift2.
  • Add validation to avoid users who allocated the payment to click in verify neither authorise.
  • Add validation to avoid users to click verify and authorise. It should be clicked by different users.
  • Change the algorithm to select swift2 instead of swift3.
  • Remove the table in pre-execution "MT103 authorisation Queue".

PRO: No needing development in FXSuite to activate the project.

PRO: We simplify the verification method as we will remove swift3, so less code to maintain.

CON: This solution implies changing the behavior on sending swift2 payments.

Alternatives
Proposal 2: Apply the change only under the MT103 verification queue

Change pre-execution view and fields handling the payment sending to FXSuite, to allow having a new check for the swift3 payments. The behavior will be similar on what we have for swift2 but with different scheme permissions.

Change the order on the "Authorise" buttons. Right now it is:

  1. Click on “AUTH (MT103)” Authorise button.
  2. Payment is sent to FXSuite with the PaymentExecution.
  3. Click on “AUTH LITE2” Authorise button.

Change it to:

  1. Click on “AUTH (MT103)” Authorise button.
  2. Click on “AUTH LITE2” Authorise button.
  3. Payment is sent to FXSuite with the PaymentExecution.

The changes in payment field filling and actions for swift 3 will be:

  • “AUTH (MT103)” Authorise button in pre-execution:

    • [Remove] verified_in_BIB_by
    • verified_by
    • verified_date
    • authorised_by
    • authorised_date
    • entered_in_BIB_by
    • executed_in_bib_by
    • accepted_in_BiB
    • If needs treasury approval (above treasury approval threshold):
      • Send payment needing treasury approval email
    • [Remove] verified_bib_date
    • [Remove] charging_instructions

  • “AUTH LITE2” Authorise button in pre-execution:

    • [Remove] authorised_in_BIB_by
    • [Remove] authorised_bib_date
    • [Remove] paid_on
    • [Remove] PR email send
    • [New] verified_in_BIB_by
    • [New] verified_bib_date
    • [New] charging_instructions

  • PaymentExecution

    • [New] authorised_bib_date
    • [New] paid_on
    • [New] held_to_deliver,
    • [New] discarded
    • [New] authorised_in_BIB_by

  • [New] PR email send which happens after moved_to_schema is set to True.

PRO: Impacts only swift3 payments.

CON: We are not harmonizing swift2 and swift3 payments pre-execution behavior.

CON: No improvement on the Swift2 authorisation controls.

Proposal 3: Moving swift3 to manual execution

Due to the number of payments, sending them under the BIB queue is not a sustainable solution with the current FTE available in the payments team. This will require creating and verifying the payment manually which will be a huge amount of work for them taking into account the process is different for each CCY.

FXSuite

If the implementation is the "Proposal 1", we don't need to do any changes for activating the feature, only remove the code no longer used.

  • Remove AUTH prefixes in the MT103 generated for field 20. Change Payment.unique_reference function implementation.
  • Remove verification method checks in the routing rules.
  • Remove resend logic with cardinals in reference (no PID + "-<number>"). Example “PI1234-2”.
  • Remove discarding payments in FXSuite manually from UI.
  • Remove email notification for reset payments, as we won't have reset payments.

Developer Impact

N/A

Deployment

For deploying code we will use existing Jenkins CI.

Operation

  • Operations will need to perform the 2 Authorisation checks in swift3 payments before the payment being sent to FXSuite.
  • Operations team will no longer authorise payments in Alliance Lite 2.
  • We won’t have the possibility of reset and resend payments already sent to FXSuite. So we won’t see “PI1234-2” or “PI1234-3” payment references anymore.
  • We won’t have the possibility of discarding payments in FXSuite manually.
  • MT103 manually generated will not have the AUTH in the field 20. This shouldn't be affecting Mass Payments as they are using only SIF format.

Security Impact

We will mimic the level of security checks we do right now with the authorisation in Alliance Lite 2. What we will lose, is the verification in a different platform out of Ebury (right now Alliance).

Permissions in BOS pre-execution check buttons will be:

  • Limited access to this double verification functionality. A new permission needs to be implemented to restrict access to this section to specific roles. (Payments team + AU + CA).
  • Users who allocated the payment should NOT be able to perform a check on that payment.
  • Users should be limited to only 1 check per payment, NOT being able to perform consecutive checks on a payment.

Caveats

This solution is a tactical feature for releasing EUR payments under the new Belgium BIC. After this deployment, it's mandatory to define properly where to include this logic (i.e. on the routing rules) and remove it from FXSuite.