Closeout Provision Ledger

Up to this point the Closeout Ledger was only focusing to funding-related transactions.

In addition, we are introducing another transaction type, which is linked to the Client Closeout Provision. The reliability of the Client has a crucial meaning in terms of expected return of funds on Sellback Trades. This information is to be added to the Closeout Ledger.

Prerequisites

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

blueprints.

Reference Documents

Reference Document Location
CLSBUS Closeout Business Document
CLSEPC Closeut Ledgers Epic
CLSBPBSCS Closeout - Basics
CLSBPPRV Closeout Provision

Problem Description

As for now, Closeout Ledgers have taken into account the full Sellaback Value. However, based on Client reliability, there may be an amount of 'debt' (loss) on instead.

In order to reflect that, the Closeout Value should be adjusted with the Client Provision "proportion". Client Provision is a percentage value, expressing the "realistically expected portion" of the funds (value of the original trade being "sold back") to be returned. (See Closeout Provision)

Two new actions can have an impact on Closeouts Ledgers: 1. A Provision value may be introduced or changed for the Client owning the trade that's been sold back.

  1. Provision expresses a different (higher or lower) Closeout amount to be expected, compared to the previous(ly expected) amount. This means that the previous amount has to be re-calculated, and adjusted with the missing or additional (credit or debit) delta. This correction value manifests as a "money movement" (added to, or subtracted from) the previous value to meet the corresponding new percentage of the sold-back full amount.

Provision

New Workflows

The source of Client Provision SalesForce data synced to BOS.

If the Provision value changes for a Client, the Closeout Value has to be adjusted for all the Client's open Sellback trades. This means that a new Closeout Ledger entry has to be generated for each related Closeout Value, to record the difference compared to the value that was corresponding to the old Provision percentage.

(Given the low number of open Closeouts per client, this is a negligible overhead.)

These workflows would be triggered by the Salesforce -> BOS synchronization (CRM) Provision create/update workflows (See [Closeouts Provision]).

Provision increased

Provision decrease

All of this provision money movements will be in a new ledger called Provision Ledger

For the demonstration examples below, we are using the same use case as in Closeout Ledger.

New Balance

Write Off

Funds In

Due to the provision movements are in a different ledger we are not impacting any existing ledger or workflow.

Reporting

Quantum reporting has to be set up for new Ledger Entries reflecting a Client Provision change.

There are separate, dedicated Quantum instruments to be set up for this purpose under the ActualCashFlow main type.

Solution

We are moving towards a tactical solution, as in terms of Ebury 2.0 terminology.

For more information see Alternatives.

We need to set up new money workflow similar to the ones extended in Closeout Ledger, that corresponds to the credit/debit delta creation following a Provision value being introduced or updated for the Client in a new Provision Ledger to avoid impact any existing workflow.

The provision entries will be displayed in the Closeout Ledger to understand the data for ops teams.

Data

Data schema structures for Client Provision data have been already introduced within the scope of the Closeout Provision blueprint.

We are planning to extend the Asset data type, so we could distinguish money movements relating to Client Provision calculations applied on the Closeout full value.

MoneyWorkflows

New money movements need to be defined.

Note that whenever a Closeout delta value is added to (or deducted from) the Closeout Value, on each occasion the opposite movement has to be applied on the Ebury virtual account to keep balance.

Unlike for Closeout Ledger, here we need to clearly identify, define and implement new MoneyWorkflows from scratch for the new purpose.

Balance calculations

Further, balance calculations shouldn't be directly impacted by the new entries.

Visualisation

A new Provision Closeouts Ledger entries will natively show on the BOS UI Closeout Ledger views.

Will be displayed in the new Sellback Trades Pages and in the Closeout section of the trades with a close out movement.

Alternatives

The only alternative that worth discussing is a potential strategic solution (as in terms of Ebury 2.0 terminology).

As for now there are no solutions to take over the role of the services and workflows involved in this process (trades data representations and manipulation actions, Ebury internal money movement workflows, interactive UI, etc.). Moving this solution from tactical to strategic would go along the rest of the components/workflows within this frame. However, Ebury 2.0 correspondents of this entire tactical frame/system (Trades Command/Query Services, Money Movement Command/Query Services (?), internal data representations and workflows concept review, interactive UI, etc.) has to be planned for, so that we can have a reference for the migration of our solution within.

Clearly, initiating Ebury 2.0 efforts on any of those components within the scope of this task would create a major overhead, increasing the weight with magnitudes. Which would strongly contradict to deadlines that the Equilibrium deliverables could allow for.

Thus, we have no choice, but inserting the new components/workflows to their suited places within the old frame.

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

MoneyWorkflows are a well-established part of BOS. Changes that are about to be introdued are no different from the existing workflows.

Since there is no extreme load foreseen around Closeouts, changes proposed here should safely integrate in the already existing frame and load.

Provision

Provision changes trigger money movements on each related open Closeout. However, given the amount of a Client's active Closeouts, this is negligible.

Developer Impact

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

Data Contracts

Changes introduce on the Data level are fully compatible with existing workflows and data consumption -- as much as any future ones using the existing frame where the new workflows are implemented within.

Data changes: extension of the Asset data model type (choice) field with a new type label.

Data Sources

  • Input data sources
    • Client information from Salesforce to BOS via CRM (see [Closeouts Provision])
  • Data Transformation Requirements: none
  • Output data:
    • CurrencyAccountEntry Data Model objects (i.e. data in the corresponding SETTLEMENTS.CURRENCY_ACCOUNT_ENTRY table)
    • Asset Data Model objects (i.e. data in the corresponding SETTLEMENTS.ASSET table)

Deployment

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

Dependencies

This task has no external dependencies.