SCT Outgoing Master RFC
Reference Documents
| Reference | Document Location |
|---|---|
| SCT Outgoing through Santander PRD | Link to Product Requirements Document (PRD) |
| Outgoing Payment Service RFC | Outgoing Payment Service RFC |
| SEPA Core changes RFC | SEPA Core changes RFC |
| BOS changes for SCT SAN document | BOS changes for SCT SAN document |
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 an existing connection with Santander to receive incoming SEPA payments. As part of implementing sending SEPA Credit Transfer (SCT) outgoing payments via Santander, we will introduce new bank scheme intermediary (SCT SAN), new services such as Outgoing Payment Service, and make changes to existing services such as SEPA Core, BOS, FXSuite, PSSDS and the-BAVS. This RFC will give an overview of all the aforementioned changes.
Solution
Outgoing Payment Service
We will introduce a new service, Outgoing Payment Service, that acts as an orchestrator for the different actions that take place as part of the SCT outgoing flow. It intercepts outgoing payments sent from BOS to FXSuite, and checks if a payment should be sent via SEPA SCT, by checking eligibility with services such as PSSDS and the-BAVS, or if it should be forwarded to FXSuite to be processed as it is currently.
When a payment should be processed via SEPA SCT, Outgoing Payment Service stores necessary information in its local database, publishes Kafka events consumed by BOS and SEPA Core, and also consumes messages from the Kafka topics that SEPA Core service posts to. Note that the payment message that will be passed from Outgoing Payment Service to SEPA Core will be the same as the one published by BOS.
It also acts as a coordinator for other message types related to SEPA SCT outgoing payments, such as recalls issued by BOS, or returns received from Santander via SEPA Core, by enriching them with any necessary information, applying additional checks or sending emails to Operations or Payment Investigation teams.
Full details on this can be found in the Outgoing Payment Service RFC
SEPA Core
Changes need to be applied to SEPA Core to implement the outgoing payment flow logic.
Outgoing messages that are destined for Santander
An 'outgoing flow consumer' will be introduced in SEPA Core that will consume Kafka events that Outgoing Payment Service produces to. Validation will be performed on these messages and logic to convert the outgoing payment related messages to the ISO20022 message format, finally sending them to Santander via Payments Hub ISO2002 API.
- Outgoing flow consumer will consume messages for:
- outgoing payments as pacs.008.
- payment recalls as camt.056.
Incoming messages from Santander
For messages originating from Santander, an 'incoming flow consumer' will be introduced, that will receive messages originating from Santander. Specifically, Santander will post messages to webhooks, exposed by Kong Gateway, and will ultimately be consumed by the 'incoming flow consumer' in SEPA Core for further processing. The messages will contain links that SEPA Core will use to download the actual payment messages from Payments Hub API. The messages would then be uploaded to S3 for backup purposes, converted to the format expected by Outgoing Payment Service, and produced to the respective Kafka topics.
- Incoming flow consumer will consume messages for:
- payment status as pacs.002.
- payment returns as pacs.004.
- payment recall positive result as pacs.002/pacs.004.
- payment recall rejection as camt.029.
Full details on this can be found in the SEPA Core changes RFC
BOS
An overview of the changes required in BOS for SCT Outgoing: - IBAN Assignment: - We will generate IBANs for EUR accounts of clients that will be used in payment messages to SEPA SCT. By default, they will not be visible to clients (in places like Transaction Report or EBO). - New Bank Scheme Intermediary Definition: - Add the new schema, or reuse SEPA, and new bank intermediary values for SCT SAN to BOS code. - Beneficiary: - No changes needed, just check that the new SCT SAN appears in the beneficiary information 'Schemes' field. - Reconciliation: - Debit bank account entry will be created by Outgoing Payment Service for outgoing payments and credit bank account entry for returns. - New Field for PI page: - Update status options for the 'Ready' field. Also include new field 'External ID' or 'Scheme ID' to facilitate post-communication for a message with Santander. - KPI Report: - Include SCT SAN payments in the report. - R-transactions Process in Post Execution Page: - In case an outgoing payment needs to be cancelled, a Recall is initiated from the PI page in BOS (which will send a camt.056 message to Santander via Outgoing Payment Service). These payments also need to be listed in the Post Execution page. - New Screen for the Routing Rules: - We will need a route for SCT SAN which in BOS 'Payment Routes' page is populated from PSSDS. We can also add a details page similar to FPS to configure anything specific for SCT SAN (draft configuration).
Full details on this can be found in the BOS changes for SCT SAN document
the-BAVS
The reachability of the beneficiary to SCT can be checked via Apply Financial using the IBAN and the BIC of the beneficiary bank account. Changes need to be made to the-BAVS to support this check and Outgoing Payment Service will call it to determine if it will forward the payment to FXSuite, as currently, or to SEPA Core.
PSSDS
Through migration scripts, a new schema "SCT SAN" will be added to PSSDS configuration and also make necessary changes to store and retrieve respective SCT rules.
Service Ownership
| New Service | Service Name | Service Owner |
|---|---|---|
| Yes | Outgoing Payment Service | PAY Team |
| No | SEPA Core | PAY Team |
| No | BOS | ONL Team |
| No | FXSuite | ABC/PAY Team |
Security Impact
Security will be addressed in the RFCs for each specific service.
Performance Impact
By adding the Outgoing Payment Service as a interceptor between BOS and FXSuite for outgoing payments, it results in calling PSSDS service twice in cases when the payment intercepted is not meant to be processed by SCT.
Based on RFC Template Version 1.1