CNY Payments Execution via Swift Service (Barclays UK)

The purpose of RFC is defining the changes needed for releasing CNY payments via Barclays UK using CIPS format.

Problem Description

We release all CNY payment via CNPAS and as of the 1st of January we need to release them via CIPS, the format will be different when the beneficiary bank country is China.

Today, we are releasing Swift CNY payments using our Ebury UK source account and we will continue releasing them with this bank intermediary. For generating the MT103 message, we are currently doing it 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 CNY payments using this service and generate the MT103 using Transformer.

Background

Nowadays, we are releasing 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 swift service route table our Barclays UK source account for routing all our CNY payments via Swift Service.

If you want to know more about Swift Service 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 the MT103 headers and the process will also assign a bank scheme intermediary to each payment based on the recipient information (source account BIC). If we could find a source account in our swift service routing table in FXS, then the process will override the payment source account, the institution/recipient information and the bank scheme intermediary. For CNY, if the account found is the Citibank one, we will populate CITIGB2L as recipient information and in other cases we will release our CNY payments via Barclays UK so BARCGB22 BIC will be selected as the recipient. We could not have 2 source account on this table for the same currency and beneficiary bank country. The decision of releasing a payment using a specific bank intermediary, comes from the operation's team (who will include the source account on this table via the support 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

As we are currently releasing CNY payments via Barclays UK and we will continue doing it but with a different format on the MT103 file, we should continue executing post-execution actions via Barclays UK. 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.

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 so if we don't change it, we will continue doing it on the same way.

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

Solution - Outgoing process

Our proposal wants to include all the logic needed for releasing CNY payments via Swift Service using CIPS MT103 format. For doing this, we will need to include a logic in FXS for selecting the recipients and institution information depending on the source account BIC, create a new Transformer project for generating MT103 messages and changes on the process for sending payments via Swift Service instead of using the old FXS flow. For managing this, we want to create a new bank scheme intermediary in FXS called 'Barclays UK'. This new bank intermediary will be used for indicating that a payment was released using Swift Service or the old flow in FXS. As we will continue releasing the CNY payments via Barclays UK, we need to include some change in BOS for execute post-execution actions under Barclays UK. 'Barclays' bank intermediary means 'Barclays UK', so the idea, is deprecating 'Barclays' bank intermediary once all our payment executions will be migrated to Swift Service.

Here you could see an L3 diagram with the changes to be implemented:

OUTGOING_CNY_BARCLAYS_UK

The changes covered are:

  • Create a Transformer project for default Barclays MT103 message generation for international payments and domestic CNY payments
  • Include a change in Swift Service for generating the MT103 message using the new Transformer parsing created for Barclays depending on the recipient BIC received
  • Include a new bank scheme intermediary (Barclays UK) in FXS and BOS
  • Include a change in FXS daemon for routing payments with scheme_bank_intermediary 'Barclays UK' to Swift Service. With this solution we don't need to change the old FXS daemon for not executing CNY payments
  • Include a change in BOS for allowing post-execution actions when the payment scheme is 'Swift' and the bank intermediary is 'Barclays UK'

Here you could find the C4 model for this proposal.

Solution - Incoming process

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

Alternatives

  • Create new bank intermediary 'Barclays UK' in BOS (our proposal)

    • Pro: We won't have a data inconsistency between FXS and BOS (in terms of naming)
    • Pro: We don't need to include any change on the old process in FXS for not executing CNY payments as this daemon is only taking payments with 'Barclays' bank intermediary and 'Swift' scheme
    • Pro: We don't need and extra development for not sending payment receipts with an invalid MT103 file
    • Con: We need an extra development in BOS for executing post-execution actions under 'Barclays UK' bank intermediary when 'Barclays' bank intermediary will do (and means) exactly the same

  • Create new bank intermediary 'Barclays UK' only in FXS

    • Pro: We don't need to include any change on the old process in FXS for not executing CNY payments as this daemon is only taking payments with 'Barclays' bank intermediary and 'Swift' scheme
    • Pro: We don't need an extra development in BOS for executing post-execution actions as we are translating 'Barclays UK' to 'Barclays' in BOS. Furthermore, the bank intermediary 'Barclays UK' and 'Barclays' will do (and means) exactly the same.
    • Con: We will have a data inconsistency between FXS and BOS (in terms of naming)
    • Con: We need an extra development in BOS for avoiding sending wrong data on the payment receipt

  • Not creating a new bank intermediary 'Barclays UK' in FXS/BOS

    • Pro: We won't have a data inconsistency between FXS and BOS
    • Con: We need to include a change on the old process in FXS for not executing CNY payments as this daemon is taking payments with 'Barclays' bank intermediary and 'Swift' scheme
    • Con: We don't need an extra development in BOS for executing post-execution actions under 'Barclays UK' bank intermediary when 'Barclays' bank intermediary will do (and means) exactly the same
    • Con: We could not detect in FXS if our payment was routed via Swift Service or via the old flow as we are not displaying any different information
    • Con: We need an extra development in BOS for avoiding sending wrong data on the payment receipt

I would like to remark (as a Pro), that we are implementing the default parsing for Barclays international payments, so in the future, for executing payments via Barclays with Swift Service we only need the domestic mapping in Transformer.

Operation

For enabling this workflow we just need to include the Barclays UK source account on our Swift Service 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 CNY payments via Swift Service, we will continue following this rule.

Technology

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

Deployment

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