MiFID Regulation service

Ebury entities are registered in different countries where laws and regulations are based and must be accomplished by clients related to each entity to apply regulations accordingly.

We must be able to set validations for clients based on entities, applying each regulation that could be for each trade type, reason for trade, etc.

Problem Description

Currently, the process to decide if a trade must be marked as MiFID or not has the following parameters to decide:
- If a client is MiFID (based on the MiFID classification of the client + the MiFID status given by Salesforce)
- If the selected Reason for Trade is MiFID
- The EMIR classification of the Client
- The trade type of the deal you are creating

This logic is static, doesn't check the Ebury Entity of the client and any change costs development, which doesn't fit with the requirement:
Implement an scalable solution to design the conditions of a regulation by the user given a dynamic input, in this case, is the MiFID regulation, where the input is the Ebury Entity (and for the future with the Trade type and the Reason for Trade).
This solution must be able to return the MiFID Reason for Trades.
Also, check if for a given entity, trade type and reason for trade, returns if it must be MiFID or not (to double-check in the trade creation).
Product team asks for an scalable solution which fits with any other regulation that it may come in the future with a different I/O.

Background

Currently, Ebury has entities created around the world, based on different countries, timezones and regulations. As we are growing and expanding around the world we expect to meet all regulations and apply them only to the entity related. In certain cases, entities will share the same regulation (Entities in Europe as Ebury UK and Ebury Belgium).
For this particular case, the main goal of this project is related to the fact that Ebury Partners Switzerland and Ebury Partners Australia will get their own license. These entities will be children of Ebury Partners UK Limited with their own MiFID regulation.

With the present logic of BOS, all Forwards/Drawdowns which client has the conditions to be MiFID and the selected Reason for Trade is MiFID will be marked as MiFID without check if the client Ebury Entity is regulated by MiFID. This logic keeps static into the code with no possibility to change without escalating a requirement with a proper development inside BOS.

At this moment, the Ebury Entity is defined/used in the following places of BOS¹:
- Field of BankAccount, which is set from Internal Bank Accounts page
- Field of Client, which is synced from Salesforce, this has a caveat explained in its section
- Used by our new Account Details service (ADS)

Solution

Create a new service which manages the MiFID regulation. This service will be created most basic as possible to solve the most important point of the requirement (do not mark a trade as MiFID if the entity is not regulated). After accomplishing that, we refactor the MiFID logic of BOS to move it to this new service.

Proposed technologies for the service:
- Python 3 as language for the service
- FastAPI as framework to develop the REST API
- OpenAPI to build the client lib as this practice recommends

Pros

• Less code inside BOS to maintain
• Opportunity to develop with new technologies
• Separate logic and tests to the core application will produce a clear scope of the service (not X usages in the BOS code) so would be easier to expand

Cons

• Development/time cost will be greater than the alternative solutions²

Phases

Milestone 1 - Product MVP

Create the new service with a JSON with the rules of Entity-IfItIsRegulatedByMiFID (UniqueID-Boolean). BOS will ask to this service in trades.controllers.trades.common.trade_is_mifid, api.controllers.trades.confirm_and_complete_new_trade_of_client and trades.controllers.trades.common.allow_mifid_forward_creation with the client Ebury Entity Unique ID and if the service returns True continue as we do now, otherwise, skip MiFID validations.

Milestone 2 - Engineering MVP

Move the logic of MiFID from BOS to the new service, this requires changes in:
- trades.controllers.trades.common.trade_is_mifid
- api.controllers.trades.confirm_and_complete_new_trade_of_client
- trades.controllers.trades.common.allow_mifid_forward_creation
- clients.models.client.Client.is_mifid (currently this is a property but it should be a field into the Client table, and as a consequence we would remove the unnecessary fields from the table (mifid_classification and mifid_status), the aim of this new field is to not calculate it every time we need it and update it only if there are changes from Salesforce (in the sync))

This will require to create another JSON of TradeType-IsMifid.

Milestone 3 - Improvements

• Move the MiFID Reason For Trade knowledge from BOS to this new service. In this milestone, we will assign them a Unique ID(it may be the current ID) and move the MiFID flag to this service as another JSON of RFTUniqueID-IsMiFID. Affected file: trades/translations.py. Note: The RFT texts will be still on BOS for translations purposes.
• BOS will ask to this service which RFTs are MiFID and save it in cache (Redis) to avoid more requests than necessary since this information probably won't usually change. Affected file: trades/services/reasons_for_trade_service.py

At this point we will be confident to say BOS is agnostic about MiFID regulation, just database fields about MiFID but no logic.

Milestone 4 - End of project

• Differentiate the TradeTypes and ReasonForTrades per Entity (adding the tuple (EntityUniqueID-[TradeType/ReasonForTrade]) in both JSONs)

Possible future developments

• Endpoint to retrieve/edit this "matrix", for that, we should convert the JSONs into DB tables
• Display this matrix into BOS as a new view with new permissions (read-only/write)

Some diagrams to show some relevant workflows:
BOS Workflow

Endpoint life cycle logic

Alternatives

Option A

• Create a BosSetting of EntitiesRegulatedByMiFID, add the proper entities and BOS will check if the client Ebury Entity is in this setting in trades.controllers.trades.common.trade_is_mifid, api.controllers.trades.confirm_and_complete_new_trade_of_client and trades.controllers.trades.common.allow_mifid_forward_creation, if the entity is inside this setting continue as we do now, otherwise, skip MiFID validations.
• Move the MiFID logic to a separated Django app to centralize this regulation logic (similar of Milestone 2 but inside BOS)

Option B

• Create a BosSetting of EntitiesRegulatedByMiFID, add the proper entities and in the Salesforce sync, if the entity is not regulated (the setting doesn't contain this entity), then the mifid_status of the client will be None

Both options achieve the Product MVP.
The diagram related to this alternative solution would be this:

Caveats

• Regarding the proposed solution, we can accept more parameters than necessary at the beginning into the requests (trade type, reason for trade) and in case it is not implemented, we wouldn't use them and return an extra "warning" informing those parameters were ignored since the rules are not implemented yet.
• Currently inside Client model we have two different fields to manage the Ebury Entity, "company_entity" and "ebury_entity":
  -- company_entity: CharField which is kept for compatibility reasons in the code but is deprecated so we shouldn't extend the use
  -- ebury_entity: ForeignKey to the model CompanyEntity, this model has a field named unique_id shared between Salesforce, BOS and ADS

Operation

To add/edit/delete rules, a dev requirement must be escalated and in a 1-point User Story should be done amending the proper JSON file.

Security Impact

N/A - The service would be inside our backoffice environment, as other services that we have, so it will be restricted to internal access only.

Performance Impact

The service may slightly decrease the performance due to BOS would have to request the information to an external service instead of inside its code. For the Reason for Trades, we will cache them to avoid more requests than necessary.

Developer Impact

The selected technologies are quite new (FastAPI was born last year) so problems might appear in the middle of the development to adapt/implement the solution with these technologies.
If a new Trade Type/Reason for Trade is added to BOS, it should be added to this service also.

Data Consumer Impact

Initially, the data source would be JSON files, maybe an endpoint to retrieve them would be necessary.

Deployment

Steps to deploy the proposed solution:
- Create the infrastructure of the service without logic and deploy into production
- Add value to the service with the first endpoint returning always True and add the call to this service into BOS
- Add the JSON with Entity-IfItIsRegulatedByMiFID and the logic into the endpoint
-- Milestone 1 complete --
- Mirror the MiFID logic from BOS to the service
- Remove the MiFID logic from BOS
-- Milestone 2 complete --
- Copy MiFID knowledge about which Reason For Trades are MiFID to this service
- Ask to this service about this information and cache it
- Remove MiFID knowledge about which Reason For Trades in BOS
-- Milestone 3 complete --
- Make the necessary changes into the JSON and logic to differentiate a MiFID regulation by Entity-TradeType-ReasonForTrade
-- Milestone 4 complete --

Dependencies

The new incoming Brexit project (Entities migration) will migrate the Ebury Entities of the clients.

References

• Product requirement
• Jira epic
• Draft document previous to this RFC