Options in TMS
Prerequisites
Reference Documents
The reference document table contains links to information relevant to the RFC, a link to the referenced document is also required. Here is an example:
| Reference | Document Location |
|---|---|
| TL-027 | PRD |
| TL-027 | Technical document |
| TL-028 | PRD |
| TL-028 | Technical document |
Problem Description
As Ebury innovates offering new attractive products for our clients, product has taken the decision of developing Options and Dynamic Forwards for clients. Our strategic approach has decided to take this logic outside BOS, as it's deprecated.
The chosen Trade Management tool for FX Options and Dynamic Forwards is ICE.
This initiative addresses the need of a solution that integrates the information from the transactional system (ICE) with TMS (Quantum) to enable trade information interchanges that will allow Quantum capabilities to be utilised for Treasury purposes (Settlement, Reconciliation, Treasury reporting) which are currently done manually.
The information we need to send to Quantum comes from a CSV file that the Analytics Team builds by aggregating information from different sources like ICE and Salesforce and uploads to S3; the aggregation actually happens in the Data Warehouse, and the CSV is actually a snapshot of the information in the Warehouse.
As a short-term solution for feeding information to Quantum, the Treasury Systems Team will be reading the CSV and manually generating and uploading QXTs to Quantum. We need to implement a solution that does that automatically, without human intervention, to make the process scalable.
Background
The situation currently faced by the back office teams (especially Operations, Accounting and Treasury) is that every financial event has to be manually observed and manually processed in a non-supported system (ie. Google sheets).
For instance, if Ebury sells a client a Dynamic Forward structure where the back-to-back deal with the LP results in the LP having to pay Ebury a premium amount, the Trade Support Team has to manually record the premium in the relevant Google sheet and the Reconciliation Team has to log into the different bank accounts in order to identify whether the LP has effectively settled the expected premium or not.
Apart from the obvious inefficiency, processing the financial events in such a manual approach carries over a high risk of inaccuracy and completeness very difficult to identify. This would compromise the scalability of these products and their auditability.
To address this, the end goal is to have a strategic scalable architecture that will allow the end-to-end management of these and other complex FX products. For the Treasury Team, this translates to having the up-stream features sending information to the TMS in currently known formats and structures, since Quantum is a third party provider with limited bandwidth to adapt to Ebury.
While the upstream systems are designed there is a requirement for an MVP that would allow the use of the Treasury Systems for financial reporting and will get operational processes away from Google sheets.
Solution
The strategic solution would be for the DFO Service to retrieve data from ICE via the ICE Gateway, publish that data on Kafka for the Data Warehouse to ingest, aggregate that data in order to publish Financial Instrument Domain Events that can be consumed by the Treasury Service.
A tactical step would be for the Data Warehouse to fetch data from ICE and generate a report in a file for the DFO Trade Engine Service to read and aggregate in order to publish Financial Instrument Domain Events that can be consumed by the Treasury Service. Also, from the DFO side, we will be storing and then publishing some information ('TicketNumber', and 'DealSetName').
This solution also requires an update on the Treasury Service in order to handle all these new messages that will come from the DFO Trade Engine Service, with the corresponding mapping. On top of that, it will require an extra consumer to consume and store the 'TicketNumber' and 'DealSetName' locally. That information will be used to enrich the information sent from BOS.
From BOS side, we need to adjust the serializer for spots to take those related to Options products and use the right instrument. The 'DealSetName' will be then enriched by the Treasury Service as mentioned above. For this, we might have to include a new "reason for trade" specific for Options spots and potentially a new field to fill the 'TicketNumber' information.
Service Ownership
No new service would need to be created. Both, the DFO Trade Engine Service and Treasury Service will have impactful modifications, while the changes on BOS and Quantum Gateway side are going to be less significant but still required to fulfill the requirements.
| New Service | Service Name | Service Owner |
|---|---|---|
| No | DFO Trade Engine Service | TEG Team |
| No | Treasury Service | TRE Team |
| No | Quantum Gateway | TRE Team |
| No | BOS | TRE Team |
Alternatives
There are three alternatives for this project: - A different approach of connecting ICE to Quantum directly. This would automate most of the issues but would require an in-depth analysis of the ICE platform plus the Quantum API. This goes against the strategic approach taken by business. - Using the Quantum API instead of creating the QXTs. This option was considered and discarded because: - Currently the operations are being manually created and uploaded as a QXT in Quantum, meaning the new instruments are working. - Using the Quantum API also has downsides as if the API is down ,the entire process fail - We don't have the full context on how Quantum handles the information internally, potentially causing issues if the data we send in the requests is not correct, blocking the process until it's amended. - Keep the full manual process. As the manual process requires considerable amount of hours and is prone to errors, this was discarded.
Caveats
For this specific project, in order to save time, we have decided to split the solution in 2 phases: - Phase 1 (TL-027): Update the DFO Trade Engine Service and send the new operation(s) creation - Phase 2 (TL-028): Process the dealset associated from the BOS deals created to reflect the operations
Operation
The DFO Trade Engine Service will read the CSV from S3 and publish domain events to Kafka, that will be consumed by Treasury Service, which will produce Kafka messages for Quantum Gateway to process and send the corresponding QXTs to Quantum
Security Impact
The security impact of this project is minimal. - The Kafka messages created wouldn't contain any sensitive data. No client personal information will be present, only the client identifier.
Performance Impact
The performance impact of this change in the service would initially be small as a low amount of clients is performing options operations. Quantum Gateway and Treasury Service are already handling a high amount of elements in core hours, so adding a small amount of elements shouldn't have a noticeable impact on these services.
Due to the service simplicity, if the list of clients using options starts to grow, the performance of the service is not expected to be affected.
Developer Impact
We are updating an important service that is owned by another team. We will not update the main flow of the service, but we will be adding new functionality. Coordination with TEG Team for releases / important changes in the code are a must on this project.
Data Contracts
A new data contract between the DFO Trade Engine Service and Treasury Service will be created. This data contract would be a notification event.
The event source would be an operation done in ICE to reflect an operation for options. The message content will be defined in later stages of the development, the structure would be similar to the already existing one in 'ebury.treasury.quantum.outgoing'.
Data Sources
For the project, the input data would be a CSV report of the open transactions done in the ICE platform, coming from the Analytics Team using the data warehouse. The CSV will contain information related to the operation: Operation Trade type, client information, client entity and branch information, dates related to the movement, dealer information, action.
This CSV need to be processed adding the business logic necessary to provide a QXT file for Quantum, which will be done in Treasury Service. An initial mapping of the data that should be generated can be found in the Option Structures
The final output of this process will be a Kafka message, inserted into the new topic that Treasury Service will consume.
The Treasury Service will then produce a message for Quantum Gateway to process and finally upload the resultant QXT to S3 and Quantum SFTP.
Deployment
Since the service will run in Kubernetes, no actions are expected from the Platform Team.
For the deployment, Treasury Team can handle staging and production releases.
The deployment of the service will be done in 2 phases: - Staging release, where we will be able to test end-to-end from the initial CSV report to the Quantum entries. - Once we have confirmed that all the requirements were done, a production release can be done.
Dependencies
None.
Based on RFC Template Version 1.1