Client Closeout Provision

A further extension is introduced relating to the sell back / close out process.

When a trade is closed out, it's likely to generate a loss on Ebury's side, which loss is supposed to be paid back by the Client. Closeout Provision allows to express probability expectations on the amount that should be -- and the amount that is likely to be returned to Ebury.

Prerequisites

This Blueprint is based on the pre-requisites implemented within the scope of the

blueprints.

Reference Documents

Reference Document Location
CLSBUS Closeout Project Business Document
CLSEPLDG Closeout Ledgers

Problem Description

Whenever a trade is closed out (or "sold back"), there is an unavoidable mismatch between the value of the trade (time of creation) and the value of the trade (time of the close out). The difference simply comes from the rate changes, that happen in-between the time passed.

Thus the value of the Sellback trade is often less than the amount that was originally foreseen for the trade. There is a difference, so called Closeout Value between the amount covered by the Sellback trade, and the originally foreseen amount.

We could call this difference implicitly a "debt", the amount that the Client owes to Ebury -- as the company "lent" the amount in advance, using the rate applied at the time of the trade creation.

Closeouts Value

Now, the Closeout Value may or may not be fully recovered from the Client. Generally there is a level of predictability on Clients, allowing for a fair estimation on the chances to what proportion the missing amount would be paid back to Ebury.

This estimation is expressed with the so called Closeout Provision.

Provision is a numeric value, expressing the "reliability" of the Client. The lower the Provision is, the more reliable the Client would be.

The practical use of Client Closeout Provision is to be applied on the loss represented by Closeout Value, calculating the company's "realistic expectations" regarding the loss -- knowing the Client.

Provision has to be defined manually. Provisions may change over time.

Provisions will have an impact on Closeout Ledgers calculations (see [Closeouts Ledgers]).

Solution

Provision data

  • is to be registered in SalesForce as the Source of Truth

  • is linked with each Client (in case defined at all)

  • is numeric, referring to a percentage

  • may change over time

In terms of handling Provision data for further usage, we choose a tactical solution (see Alternatives).

Provisions data is to be synced to BOS by the periodic CRM process.

The data is BOS is to be stored historically, linked to the Client it corresponds to. This is so that we would have a full track of Provision data per Client, as those values would have been used for various calculations over time.

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 (i.e. Closeouts) information than BOS. We can't afford 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.

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 prefetch facility.

As for SF -> BOS synchronization, querying for the extra piece of information is a negligible overhead, thanks to the SF API interface that provides quick access to the new chunk of data. (Processing on BOS side is also negligible.)

Developer Impact

There is no higher impact foreseen, as generally for similar BOS extensions.

Data Contracts

None of the existing data contracts are impacted by the change.

New ones will be introduced by brand-new data schema objects introduced within the scope of this Blueprint.

Data Sources

  • Input data sources
    • Client information from Salesforce
  • Data Transformation Requirements: none
  • Output data:
    • new data in the new CLIENT.CLOSEOUT_PROVISION table, historically stored

Deployment

To be deployed as regular BOS releases, seamlessly. No downtime is required.

Dependencies

This task has no external dependencies.