Outgoing Payment Service

Reference Documents

Product requirements and similar RFCs to show how other Payment schemes can be implemented.

Reference Document Location
PRD CM-002 - SCT outgoing through Santander
ACH Master ACH Master RFC
ACH Outgoing ACH Outgoing Payment Service RFC

Glossary

Term Description
Autoclient Balancer This service abstract Autoclient infrastructure and connection handling. Autoclient balancer manages logic about authentication, connection and other logic in Autoclient SFTP server, not swift-related logic, neither other logic
BOS BOS (Back Office System) is the core service for the finantial transactions at Ebury. It is responsible for FX products lifecycle and the money flows through incoming funds, internal accounting and payments
EBO Currently Eburyonline is undergoing a major frontend and backend revamp where the Online team is bringing the legacy code to a new modern architecture. This new stack has been used in major parts of Eburyonline such the Dashboard, Trade Finance, Convert & Pay with great success, and now we continue improving every aspect of Eburyonline in other parts of the application
Ebury API Ebury API allows Ebury customers to programatically access Ebury's platform. The long term plan is to be the only public API to access all Ebury's internal systems (e.g. BOS, FXS) and to be used by Ebury's own customer frontend applications (EBO). As a point of contact for all internal systems, the API converts data received from users (the API clients) to the format required by the internal systems and back to a specific format useful to users
FXSuite FXSuite is the service first created to connect with third parties from BOS.
Outgoing Payment Service Outgoing Payment Service (OPS, the subject of this RFC, is an orchestration service implementing payment workflow and commanding other services to execute payments in their payment scheme. Outgoing Payment Service will use information provided by PSSDS (Routing Rules) and the-BAVS (Account Reachability) service to make routing decisions
PSSDS Payment Scheme Static Data Service serves as the source of truth for the rules in the new Routing Rules Project. This service includes all the required logic to determine, manage and prioritise all the possible routes through which a payment can be released in Ebury. Developed by Ebury, can be found at https://github.com/Ebury/pssds
SCT SEPA Credit Transfer
SEPA Payment Cashless payments in euro currency that are processed via the Single Euro Payments Area network to facilitate cross-border bank transfers in 36 Eurozone and non-euro area countries. Based on ISO20022 message standards
Sepa-Core SEPA Core is the service which manages incoming and outgoing SEPA payments received through connection with Santander. SEPA Core exchanges: 1) pacs payment messages with Santander for receiving and returning funds; 2) internal bank account entry messages with BOS for creating bank account entry (BAE)
Swift-Service Swift-service handles two main flows: Incoming error files: Reads error files sent by AC-Balancer, parses them using Transformer-swift and then publishes updates to discard payments to FXSuite; Outgoing payments flow: Flow that receives payments aimed at Swift network (Currently for Citibank and Barclays Frankfurt only), parses them using Transformer-swift, and sends them to ACBalancer for the payment message to be published
the-BAVS the-BAVS is a vendor-agnostic service for all bank-and-account validation needs at Ebury. Developed by Ebury, can be found at https://github.com/Ebury/the-bavs
E-mail Service The Email Service is for sending emails from different services. Currently only to Ebury users, later it can be expanded to send emails to external recipients as well.

Problem Description

At present we don’t have local rails in the EU therefore our EUR payments cost more to be delivered and at times intermediary charges are deducted from the nominal. Customers are demanding that payments are local, fast and cheap. Market research and analysis shows that this is a must-have for any company that wants to compete in the international payments space. Currently, all our EUR payments are sent internationally thanks to our correspondent bank, Barclays Germany, through Target2 (European Real Time Gross Settlement). All key competitors are offering SEPA Credit Transfer payments, and this is a ‘right to play’ capability. Whilst wire payments meet the need from a payment speed perspective, our cost base and reputation can suffer as a result. Additionally, some EIS (Ebury Institutional Solutions) clients have specialist use-cases that require SEPA Credit Transfer.

Background

We have connections to ABN and Santander to receive incoming SEPA payments implemented in SEPA Service (ABN) and SEPA Core (Santander). We will use Santander to implement outgoing SEPA payments using SEPA Core as a basis for adding outgoing flow.

There are three main flows in Outgoing Payment Service that have to be supported for payments through SEPA Core:

  • Outgoing "Payment" is money sent from Ebury to the beneficiary. (BOS to Scheme)
  • "Recall" is used to cancel payment due to an invalid amount or details. It assumes the Payment was successfully processed by the beneficiary bank. (BOS to Scheme)
  • "Return" is returning a payment either in response to a Recall message or by an initiative of the beneficiary or beneficiary bank. (Scheme to BOS)

Solution

We introduce the Outgoing Payment Service as a proxy that intercepts payments sent from BOS to FXSuite. If a payment should be sent through SEPA, Outgoing Payment Service will do so. Otherwise, the payment will be forwarded to FXSuite to be processed as before.

Next, we can see the majors difference between the existing architecture and the propose one.

Current Architecture Current Architecture

Proposed Architecture Proposed Architecture

Outgoing Payment Service

Outgoing Payments

  1. BOS publishes an outgoing payment to Kafka topic and it is consumed by Outgoing Payment Service.

  2. NOTE: An important change regarding the consumption of Kafka topics by the FX Suite (FXS) application. This change aims to prevent FXS from consuming the same Kafka topic as of today. Please take note of the following details:

    1. Change Strategy: The approach to prevent FXS from consuming the same Kafka topic involves changing the topic names in FXS (http-kafka-connector). This will ensure a clear distinction and separation of topics between different processes.
    2. OPS Activation: The topic name changes will be implemented once the OPS system is activated.
    3. Feature Flag: There is no mention of implementing a new feature flag (a switch) in FXS to enable or disable the topic consumption. Therefore, the primary method for distinguishing topics will be through topic name changes.

  3. Outgoing Payment Service calls PSSDS to determine which scheme should be used according to the rules defined by Ebury.

  4. When SEPA is the scheme, the Outgoing Payment Service will call the-BAVS to check if the beneficiary is reachable via SEPA (Apply Financial)
  5. When the beneficiary is reachable through SEPA
    1. Payment will be stored in the local database
    2. "Routing selected" event is sent to the BOS via Kafka topic (same as FXSuite)
    3. Outgoing Payment Service will send it to SEPA Core
  6. Otherwise payment is sent to FXSuite to be processed using the existing flow

Payment status updates will be received from SEPA Core. The outgoing Payment Service will update the local database and produce an event for BOS to update the status there. Status values:

  • “Bank never sent the payment” in case Santander API rejected the payment straight away due to invalid format or misconfiguration. Send a status update to BOS.
  • Positive. Outgoing Payment Service will create a debit Bank Account Entry and send it to BOS.
  • Negative. The outgoing Payment Service will send an email to the Payment Investigation team.

Recalls

  1. BOS publishes a recall message to a new Kafka topic and it is consumed by Outgoing Payment Service.
  2. Using the original payment ID Outgoing Payment Service checks if that payment was sent through SEPA Core. If not, send an email to OPS team.
  3. Enrich the Recall message with pieces of information from the original (if needed) and forward the Recall message to SEPA Core.

Recall status updates will be received from SEPA Core. The outgoing Payment Service will update the local database and produce an event for BOS to update the status there.

  • Positive. Nothing to do. Work will be done on the resulting Return message.
  • Negative. The outgoing Payment Service will send an email to the Payment Investigation team.

Return

  1. SEPA Core will publish a Return message when it's received from Santander.
  2. Outgoing Payment Service will
    1. Store this message
    2. Create a credit Bank Account Entry and send it to BOS to be reconciled manually
    3. Send an email to the Payment Investigation team to investigate the reason for the return and to reconcile it.

Alternatives

An alternative approach would be to implement SCT Outgoing functionality in FXSuite, but it is a legacy service.

How to implement the Outgoing Payment Service as a proxy:

Outgoing Payment Service Proxy

  • Outgoing Payment Service consumes from existing ebury.events.payments.pre-execution-check-completed.v1 topic (A), forwards messages to a new topic (B) and we set up http-kafka-connector to forward messages to the FXSuite.
  • BOS publishes payments to a new topic (A), Outgoing Payment Service consumes from it and forwards non-SEPA payments to the existing topic ebury.events.payments.pre-execution-check-completed.v1 (B) which is processed by http-kafka-connector

Security Impact

The service will be deployed in a private network (Kubernetes cluster) and it will communicate through Kafka topics using SSL and SASL authentication (username/password).

Outgoing Payment Service will store payment information in the database including PII.

Performance Impact

The PSSDS service will be called two times: once by Outgoing Payment Service to determine if payment should be sent to SEPA. The majority of payments will then be sent to FXSuite which calls PSSDS the second time. The load on PSSDS might double in the worst case.

Developer Impact

No direct impact.

Data Sources

Input Kafka topic ebury.events.payments.pre-execution-check-completed.v1 - BOS published outgoing payments

Output Kafka topic ebury.events.payments.routing-selected.v1 - FXSuite publishes selected route for BOS to consume. The Outgoing Payment Service will do the same for SEPA payments.

We will define new topics on BOS side for:

  • outgoing payment recalls
  • status updates of outgoing payments
  • bank account entries (instead of using SQS)

NOTE: At this moment, we're keeping using, without any modifications, the existing contract used by BOS and FX Suite. It means that consume payment from BOS, publish payment to SEPA Core for SCT payments and publish payment to FXS for non-SCT payments will forward the payment messages "as is".

SEPA Core will have several new topics, they will be defined in the RFC for SEPA Core.

Deployment

The service can be deployed in four stages:

  1. Deploy the Outgoing Payment Service running in a dry-run mode. It means Outgoing Payment Service will just listen to payments notification and display forwarding decisions, but without taking it in effect. Any payment flow will be imapacted. It will consume ‘payment initiation requested’ events produced by BOS and calls PSSDS to determine schema and the-BAVS to determine if the route is achievable, logging the result for inspection, and in case of no SCT SAN route, forwarding payment to a new topic that is not listened to by any other service. No message will be forwarded to the FXSuite nor SCT service.
  2. Deploy the Outgoing Payment Service as a proxy with SEPA rules enabled. It will just forward payments to FXSuite when non-sct payments and forward payments to SEPA-CORE when payment is elegible to SCT. In case SCT does not work correctly, payments can be routed through SWIFT (on disbling SCT routing rules).
  3. Deploy Outgoing Payment Service with Return flow implemented. At this stage the service will be ready to receive SCT Returns of an Outgoing Payment. It will be notified by Sepa-Core Service, who is responsible to receive this type of messages from schema via SANTANDER, when a new Return message arrives.
  4. Deploy Outgoing Payment Service with Recall flow implemented. At this stage the service will be ready to receive SCT Recall requests of an Outgoing Payment comming from BOS.

Dependencies

The Outgoing Payment Service relies on Kafka and Postgres as its primary dependencies. These components are crucial for the proper functioning of the service. It is essential to ensure that Kafka and Postgres are appropriately configured and available.

Proxy Functionality: The Outgoing Payment Service acts as a proxy between BOS and FXSuite, enabling the forwarding of payments to the appropriate destination based on the eligible scheme. This functionality ensures seamless communication and facilitates a smooth flow of payments across systems.

Services: For the solution to function cohesively, it is important to ensure that the SCT flow is supported by the following services:

  1. SEPA-CORE: The Outgoing Payment Service must be equipped to handle SEPA-CORE transactions and integrate seamlessly with the relevant processes and systems.

  2. PSSDS: the implementation of the SCT flow necessitates the creation of new rules within PSSDS. These rules will enable the return of SCT as a valid route for eligible payments, aligning with the desired payment schema.

  3. the-Bavs

  4. BOS: The SCT flow should be seamlessly integrated into the existing processes and functionalities of BOS.

Upon the implementation of the SCT, PSSDS rules will be updated to include SCT as a valid payment route. This addition will introduce a new execution path within the Outgoing Payment Service, enhancing the capabilities and options for payment processing.



Based on RFC Template Version 1.1