DFO Transaction Receipts Automation
Reference Documents
| Reference | Document Location |
|---|---|
| PRD Transaction Receipt Automation | |
| Tech analysis for Transaction Receipt Automation | |
Problem Description
Client Terms and Conditions specified that Ebury needs to send a Transaction Receipt (TR) to the client when a FX transaction is booked.
At the moment Options and Dynamic Forwards are created/managed outside BOS using the third-party component ICE, and they cannot benefit from the existing BOS email service to send the TR to the clients.
Currently, the process to send the TRs is completely manually. There are templates per country and language available on ICE platform, that will be downloaded by the Dealer every time a new Option or Dynamic Forward (DF) is booked and forward to the Operations team which will be adding the missing information and sending the email to the client.
The goal is to automate this process, removing human intervention by skipping this manual process and errors due to the Legal and Risk impact behind.
Background
Transaction Receipts for Dynamic Forwards and Options are receipts, containing information about a financial transaction, that Ebury team has the responsibility to send to the client every time a new FX transaction is booked.
The client within the next hour after receiving the TR can request to Ebury any changes in the contract with no costs.
Solution
Ebury already has systems to integrate with ICE, Dynamic Forwards and Options.
The DFO Trade Engine periodically retrieves trade updates from ICE’s API, with the aggregated view of a package later being published to a kafka topic.
These messages will include all the information related to an ICE trade, and when a package has just been created on the platform or has experienced relevant changes, we will be able to identify it and trigger an email notification generation process.
The new TR generation workflow will be consuming messages from the packages topic and getting the necessary information from those messages to generate the Transaction Receipt template to send to the client.
It will also need to keep track of all notifications sent as well as any errors and exceptions, storing into a database for troubleshooting and audit purposes. A TR must be sent at least once, but the database will also be used to avoid sending duplicates, as far as possible.
However, the TR is only being sent if any of the required fields for the TR are being updated, otherwise the TR does not care about those changes and a new TR is not sent, as it would be duplicated.
Dealers do not have permission to update or delete a trade after its creation. The creation of the trade generates new trade leg updates messages. However, with status 'unverified' which will not trigger the generation of the TR, only after the trade is reviewed by trade support, and they update the necessary information of the trade and the status moved from ‘unverified’ to another status that it should be checked if the required details to send the TR are valid.
Structured products have two legs per expiry, one buying and one selling, the TR will need to contain the expiry dates. The TR needs to understand trades as a package, and not individual trade legs. It needs to wait until all the trade legs for a Trade have been fetched and only by then generate the TR for the client. In case one of the trade legs for one trade is updated, and the trade package is already completed and verified, a new TR should be sent to the client. This package aggregation is outside the scope of the TR module, and will be handled by the DFO Trade Engine service.
Also, if the credit conditions of the client are updated the TR needs to be sent again, with the new credit conditions. This will be managed by the Operations team verifying again the trade, so that it generates a new potential TR generation request where the Credit Conditions will be requested again from SalesForce. If they differ from the ones originally sent (by looking them at the sent TRs storage), a new client notification will be triggered.
To send the notification for the client it is also necessary to get client information that can be obtained from SalesForce, however, currently Ebury does not have a system that allows us to request this data from SalesForce. This service will need to have the capacity to connect to SalesForce API in order to request the necessary data.
After consuming a new message from the verified packages topic, this new service needs to understand: * If the TR should be sent * Trade details are first verified by trade support and dealers are not able to update/delete a trade. Only when trade support updates the status of the trade to mean verified the TR should be sent. Moreover, we need the package’s information also to be validated before sending a notification. * If the Transaction Receipt meets all the requirements to be sent to the client, that will be done by checking the data available on the consumed messaged and requesting the client information and Credit Conditions to SalesForce.
Overview
Service Ownership
| New Service | Service Name | Service Owner |
|---|---|---|
| Yes | Transaction Receipts Service | TEG Team |
| No | SalesForce (SF) | CRM Team |
Alternatives
-
This new service, part of the DFO domain, and it could be create as a complete new service outside of the DFO Trade Engine system. However, in this case, a complete new infrastructure would be needed for this service, and as it is DFO domain specific, making it part of the current DFO system will remove the need for some extra infrastructure configurations.
-
An alternative whilst Ebury Message service is under development, would be to everytime a new trade is created/updated the new workload consumes messages from trade updates topic and then sends an internal email to the Dealer containing the necessary information for the Transaction Receipt and the Dealer prepares and send the email to the client. However, this would still be very time consuming for the dealer and would have the risk of human error.
Operation
There are no additional infrastructure requirements, the components will be deployed using the current k8s cluster environment as microservices, on the existing dfo namespace. As for monitoring, the same Ebury standards can also be applied here, with the use of the logs system, sentry, Grafana, and alerts on Prometheus systems.
Security Impact
Any secret that may be used should be configured and managed in Vault. To avoid any security impact, sensitive information, as emails and names, will only live in the context of the process and will not be stored in the database.
While logging, we should keep in mind that logs shouldn’t include any sensitive information.
Performance Impact
This project will not affect any other system performance.
Developer Impact
No developer impact
Data Contracts
We will use a new model to store Transaction Receipt Status on the current DFO-TE database. The communication between services will be done by events through Kafka message system.
Data Sources
The main sources will be used
- Trade Packages information (DFO services)
- Client data from SalesForce
Deployment
All components will be deployed on kubernetes using the current Ebury stack, and the messages will use kafka topics to communicate with each other
Dependencies
This service depends on the ICE Trades Packages pipeline which will provide the information about when a package of a trade is complete and verified.
There is also a strong dependency on the communication and notifications system to send the notifications to the clients, satisfying all the requirements we have in other systems (translations, templating, dynamic content, etc).
It also has a dependency on SalesForce, from where the client information and credit conditions necessary for the TR will be fetched.
Based on RFC Template Version 1.1