Intercompany deals: end-to-end review

Prerequisites

• Requirements have been detailed in the TL105PRD
• Business process is described in this set of diagrams;

Reference Documents

Reference	Document Location
TL105PRD	TL-105 - Intercompany deals: end-to-end review (PRD)

Problem Description

There is an automated process within Quantum (the Treasury Management System used by Ebury) responsible for "mirroring" broker deals that meet certain prerequisites. This mirroring process is currently implemented through a feature called EWF on Quantum, which allows the definition and application of changes to deals based on a set of triggers and specific conditions. Although the feature is quite powerful to use, it lacks any capability of version control or consistent deployment between testing and production environments. This makes the mirroring process inconsistent, error-prone and difficult to maintain operationally.

Background

Whenever a transaction is booked at Ebury, at least three sets of financial instruments are sent from BOS to Quantum: - Client deal - Broker Deal - Deal Set

The "Client Deal" instrument represents the relationship between a client and an Ebury entity, specifically the entity with which the client signs a contract.

The "Broker Deal" instrument represents the relationship between the EPUK entity and a liquidity provider (e.g., a bank or broker that provides the transacted cash). The EPUK entity acts as a provider of liquidity for the rest of the group.

The deal sets are a type of instrument used to group multiple deals and cashflows together.

Treasury Systems carries out a mirror process in Quantum to assign broker deals (always booked under EPUK) to the client entity once they have assigned to a client deal, for the cases where the client's entity is not EPUK. This relationship creates a reverse reflection of the Broker Deal and is generated to ensure completeness and for financial reporting purposes.

Entity	Counterparty	instrument
Ebury Partners UK Limited	Liquidity provider	Broker Deal (BOS)
Client	Client's Ebury Entity	Client Deal (BOS)
Ebury Partners UK Limited	Client's Ebury Entity	Mirror Deal - 01 (Quantum EWF)
Client's Ebury Entity	Ebury Partners UK Limited	Mirror Deal - 02 (Quantum EWF)

Summary of the current broker deal mirror process implementation: - The mirroring process for Broker Deals is implemented on Quantum using a resource called "EWF". - This resource enables to apply changes to deals based on a set of triggers or specific conditions. It works in a similar way to a database trigger, as it can be seen in the following screenshot

• Given a ForeignExchangeDeal instrument that satisfies the conditions defined as "prerequisites" and a trigger time, new instruments are created according to an instrument mapping expression.
• The expressions and instrument creation logic is defined using a DSL, with possibility of including simple if / then expressions and arithmetic expressions
• There are triggers for the operations: insert, update, delete

Some problems with the current solution are need for additional manual work to set up, lack of version control and synchronisation between quantum staging and production environments. The configuration of the process is done using a DSL, so it requires specific technical knowledge of Quantum inner workings.

Solution

The proposed solution is to replicate the mirroring process implemented on Quantum in another service, ideally Treasury Service, as it already processes the Client Deal and Broker deal instruments from BOS. This new mirror broker deal functionality will be responsible to:

• Identify the deals that should be mirrored on Quantum.
• Replicates the prerequisites and trigger conditions EWF Quantum logic
• Create the mirror instruments
• Send the mirror instruments to QuantumGateway
• Keep a history with the instruments produced and the versions of the serializers and trigger rules used to produce each instrument

The fields of the mirrored instruments can be derived by processing the original broker deal, with the exception of the "deal number". Deal number is an unique identifier for each trade, and is only created by Quantum after a deal is processed. The presence of this unique field complicates the production of mirrored instruments. This problem can be solved in two different ways: - Creating the Broker deal instruments using the Quantum REST API, that returns the deal number on its responses - Keep sending broker deals in QXTs format and query Quantum for a deal number after the QXTs are processed. This is the strategy currently being used for "Unwind" instruments (produced by another the service TradeFinanceQuantumProcessor).

For this solution it is preferable to use the Quantum API instead of QXT file importation. The reasons for this is that the QXTs have limited functionality( for example, unwinds cannot be done using QXTs files) and the API is more comprehensive and simpler to debug problems.

The following diagram demonstrates how the new mirror deal process flow:

Service Ownership

New Service	Service Name	Service Owner
No	QuantumGateway	TRE Team
No	TreasuryService	TRE Team

Alternatives

The only viable alternative that could enable versioning control and synchronisation between the three different Quantum environments would be to use QXTs to load system configurations directly to Quantum. - One Quantum environment would be defined as the source of truth for broker deal mirroring logic - A script would periodically export these configurations from this environment and check if there was any change - In case of changes, the system would designate a new version number, store in a database and would upload these configurations to the other Quantum environments.

Any changes to the mirror process will be developed by a member of the Treasury team, consistent with the current practice. Some disadvantages of this approach are: - The process doing the synchronisation will need access to all Quantum environments. - It still requires manual intervention for any changes done to the mirror process. - The solution requires inner knowledge of how the EWF Logic on Quantum works and its DSL. - If Quantum removes the functionality of importing configurations from a QXT or exporting it, the solution will have to be re-implemented. - If the exported configuration fails to be loaded to Quantum, this would require manual intervention to be fixed

Caveats

In case the Quantum API is not used to create the broker deals instruments, additional development effort will be needed to implement a deal number reporting mechanism similar to what is current done for TradeFinanceQuantumProcessor unwind operations. QuantumGateway would need to continuously fetch a report from Quantum that returns a mapping between the ticket number and deal number.

The Quantum API is not idempotent, so in case of an API call failure, it's necessary to check first if an API request was executed and the correspondent instrument created on Quantum before proceeding to retry failed API calls.

Operation

The new functionality will run on TreasuryService.

Security Impact

No security impacts.

Performance Impact

The performance impact on TreasuryService is expected to be low, as the calculations to identify for which instruments a new mirror broker deal needs to be created are not costly.

There can be a decrease in the performance on QuantumGateway, depending on the Quantum API response time. This can be mitigated by parallelizing the api calls done to Quantum.

Developer Impact

From the developer point of view, this will change the communication between QuantumGateway and Quantum. At this moment, BrokerDeal instruments are created via sending a QXT file to Quantum via the SFTP protocol, after this change is implemented, the intention is to start using the Quantum REST api (that is currently being used only for doing unwinds over "MoneyMarketDeal" instruments).

Data Contracts

A new data source to inform "deal numbers" from Quantum will be created. The existent data contract between TreasuryService and QuantumGateway is not expected to be changed.

Data Sources

• Input data sources: Data will be fetched from BOS and Quantum
• Transformation requirements: a broker deal event from BOS that matches some prerequisites will be transformed on two different instruments as described on Quantum FX EWF Mirror logic mapping spreadsheet
• Output data - the target location of the transformed data is a Kafka topic

Deployment

To enable the changes proposed on this RFC, the current Mirror Broker Deal logic implemented on Quantum via EWF logic will need to first be disabled. The deployment of the service itself will be done via the deployment pipelines that are already being used for TreasuryService.

Dependencies

None

Based on RFC Template Version 1.1