Closing Out a Trade
The term 'close out' is practically a synonym of what's usually used in Ebury as 'sell back'. The slight difference is that 'close out' is more of a generic reference, while 'sell back' is the most common use case of the 'close out' process.
Generally when a trade is 'closed out', it means that its value is returned ("sold back"). This can happen for a list of reasons, which --from now on-- we would like to have clearly indicated on Ebury Sellback Trades.
Problem Description
As for now, Ebury transactions made no distinction on trades being sold back. As a new requirement, we would need to introduce a classification across those transactions.
Four different reasons could be identified, why a trade may be closed out:
- Client close out
- Credit risk close out
- Compliance close out
- Dealer error
Closeout Reason must be defined interactively using the BOS UI at Sellback trade creation time and possible to change after (typically in case of an error). The already existing Sellback creation and display UI facilities have to be extended accordingly.
For more highlights on 'sellback' vs. 'closeout' terminology, we suggest you to take a look at the Closeout Provision blueprint Problem Description section (definition + diagram).
Solution
We are moving towards a tactical solution (see Alternatives).
Data
Sellback Trades are technically represented as specific Spot Trades in BOS.
We are introducing a new BOS Data Model (DB table) to store Sellback Relations. This table will point to Sellback trades (Foreign Key relation), and refer to various Sellback "characteristics" as table columns.
This solution allows us for a flexible, extensible structure in the future.
The first reference Foreign Key relation will point to Closeout Reasons (that would have its own, small table to map the reason strings to IDs).
Visualization, manipulation
The BOS UI Sellback pages need to be extended with corresponding facilities.
The Sellback Creation views have to add Closeout Reason as a mandatory field to be specified at creation time.
The Trade Display views have to add Closeout Reason to be displayed on the Detailed View pages. This will apply both to the Sellback Trade, and the "original" Trade that was closed out.
From the Sellback Detailed view, the Closeout Reason field also has to be available for modifications (choice), when editing the trade (typically to correct a potential Sellback creation mistake).
Alternatives
The only alternative that worth discussing is a potential strategic solution.
In the near future we can't count on any other service to own Sellback information than BOS. We can't affort taking the overhead on this project to lay down the data-wise heavyweight foundations of a Trades (or Sellbacks) E20 service within the scope of this task.
As for UI pages, we don't have a Production-ready alternative that could host requested new interactive functionalities.
Caveats
Nothing in particular, the change is pretty simple and straightforward.
Operation
Nothing to mention, all would be hosted by the well-known BOS environment and workflows.
Security Impact
There is no security impact for the change.
Performance Impact
No performance impact is foreseen. The DB modifications are lightweight and flexible. Whenever additional database JOIN operation has to be invoked, we are taking advantage of Django's optimal pre-fetch facility.
Developer Impact
There is no higher impact foreseen, as generally for similar BOS extensions.
Data Consumer Impact
All references to Sellback objects now will have to retrieve an additional
DB column, that is storing the Foreign Key relation (i.e. an id). This overhead
is negligible.
Deployment
To be deployed as regular BOS releases, seamlessly. No downtime is required.
Dependencies
This task has no external dependencies.