Create Trades without Broker-Deal for Specific Currencies
This document describes an approach to enable Online (EBO and API) to create trades from payments or multipayments without a broker-deal. Actually it is a complementation to the previous RFC.
References
The reference document table contains links to relevant information for the RFC:
| Reference | Document Location |
|---|---|
| TFT-3633 | This is a link to the Task |
| Cover Multipayments | This is a link to the how Cover Multipayments works |
| Rate Channel selection per brand/currency | This is a link to RateChannel selection per brand/currency RFC |
The existing implementation uses some terms that don't match 100% with the domain terminology we employ nowadays. Hence, in the table below, you can find a handy reference to the mapping between terms in code vs our current business language so that you can read this RFC easily.
| Code term | Domain term |
|---|---|
| Partner + FxPartner | Brand |
| Liquidity Provider | Rate Channel |
| Currency | Currency |
Problem Description
Given an Online Client
When the client is completing a trade and currencies of the transaction is listed as currencies with no broker-deal in the RateChannel
Then the trade will be created without broker-deal (this will keep the trade as Non Verified).
Currently, EMP can process around 1k payments daily, ensuring customer performance. One way to achive this goal is to create trades without linking to a broker-deal at the time of its creation. Nowadays, all brands can do multipayments in cover currencies as long as the currency is enabled in the main RateChannel, and the partner has it active in the Multipayment product. It implies certain currencies must configure the broker-deal manually for trade creation. So later, a dealer will make the broker-deal manually in BOS once they bought at a given RateChannel. At that point, we can verify the trade. Note that the former only applies to Xignite, since in the case of Barx and smartTrade, we already have a contract with the RateChannel, and BOS creates the broker-deal immediately.
Soon, Ebury will integrate EMP as a brand, and we need to keep the previous behaviour without impacting our currently Ebury brands. In general, Ebury doesn’t follow the flow described above. Usually, when Xignite is the rate channel, a new broker deal is created with “Ebury” as the LP. Then, the Trade Support team manages the exposure of these trades through the Position Aggregator in BOS. They check the exposure on each currency periodically and net our position by manually buying via an LP platform. Then, a new broker-deal is then created (“Treasury FX Deal”).
However, we already have a workflow in Ebury that looks like we need to implement for EMP. Nowadays, we can declare currencies as cover for a particular RateChannel in FXS, which applies to all clients. When clients do a multipayment via EBO or the API, the corresponding broker deals are not created in BOS when clients bought those cover currencies. Therefore, BOS keep the trade non-verified. This workflow has a limitation: When, later, we create a broker-deal as cover/no-cover, the corresponding payments aren’t marked as cover/no-cover (but they should), so this requires manual actions to fix it.
Background
The functionality to define when creates a broker-deal for a trade is inside BOS:
Although we use the configuration defined in FXSuite to provide BOS information when the trade should automatically create a broker-deal. The diagram below shows the current data model status to define a currency as cover, as you can see on the diagram below:
Also, the image below shows the page to configure cover currencies for a specific RateChannel in FXSuite
Using this data model, we're currently implementing a function that works as in the following:
1. The Operation team configure the cover currencies for each RateChannel independent of the Brand
2. The client executes an Online multipayment via EBO or API
3. BOS ask FXSuite for quotes to supply the multipayment.
4. If the Quotes returns with the flag __is_cover__ turned on, BOS skips the broker-deal creation.
5. Later, the dealer will create the broker-deal manually to fulfil the trades.
Solution
Following the previous solution described on the RFC, we propose to add a new boolean field to the new RateChannelRouter (defaults to True), so that we can configure the possibility to create broker-deal per Ratechannel and Currency for each Brand. It can be configured regardless the current currency is cover or not flag, and only for specific brands (initially only set to False for EMP, we might use it for other brands in the future).
Interface
Because of the former, now we propose minimal changes to the current solution in order to meet EMP expectations. As explained above, right now we only check if the currency is cover or not to decide for createing the broker-deal for the trade.
In this approach, we keep the existing interfaces and just augment them to check if the relation between the RateChannel and Currency per Brand enables create the broker-deal.
Data model
The main benefit of this approach is that the implementation will keep the current behaviour and will enable EMP to decide whe create the broker-deal for trades according to the RateChannel selection per Brand and Currency.
Alternatives
Reuse currenty FXSuite Implementation
Using this alternative we should keep the currenty design and reuse the is_cover flag from FXSuite implementation and register of RateChannels. In the first place, FXSuite returns is_cover to BOS, and there’s specific logic for cover trades, broker deals, drawdowns, settlements, payments, etc. The EMP migration presents risks by itself, so we discourage introducing additional ones by reusing the existing mechanism.
In addition, the existing implementation in FXS binds a cover currency to an existing rate channel, regardless of the brand using it. For “real” cover currencies, this is not a problem, but if we reuse this, the EMP migration will impact all brands simultaneously. Again, this creates an unnecessary risk that should be avoided.
Finally, cover currencies and special treatment for some brands (no broker deal, trade not verified) are different concepts and should be kept separate.
Caveats
N/A
Operation
For this solution, the Support Team will keep making the configuration for each Brand.
When we apply the strategic solution for the Select RateChannel per brand and currency, it will be adequately managed by Operations teams.
Security Impact
No security impact is to be considered. There is no sensitive data or any change in our security rules.
Performance Impact
No performance impact on the system, since we will keep the same flow and api calls only add a new condition check.
Developer Impact
No developer impact.
Data Contracts
No data contracts impact.
Data Sources
No previous information or transformation required.
Deployment
We will folow the current deployment process without need rollout in stages.
Dependencies
For implementing this RFC we need the tactical solution from
Rate Channel Selection per Brand and Currency.