Closeout Ledger

Closeout Value falls under a different consideration from the generic trades-related processes. Closeout Value is carefully followed and handled by Risk Management.

We need to ensure a clear separation between regular and Closeout-related processes within our transactional workflows.

Prerequisites

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

• Closeout - Basics

blueprints.

Reference Documents

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

Problem Description

Making sure that the base terminology is set, as a quick reminder we include a diagram from the definition of Closeouts (see [Closeout Provisions] Problem Description section).

The difference between the original amount set by a trade, and the Closeout Value (generated when the trade was sold back) is causing a major issue for account balances.

Currently the Closeout Value, and any related transactions are considered on the Trade Ledger. This makes it very difficult for the business to manage credit risk.

Trade balance calculations that are applied on the Trade Ledger now include Closeout Value (see simulation below).

Starting from now, all transactions impacting the Closeout Value are supposed to be handled separately.

This kind of means like the Trade's ledger actions get "frozen" after the Sellback creation. Any transactions impacting the trade after it was sold back (funds in, write off, etc.), are to be tracked in a different space, have to be clearly distinguished from transactions before. This group of transactions is to appear on the new Closeout Ledger.

This means that impacted ledger entry generations, balance calculations, and a list of related operations have to be rectified, and new processes have to be defined.

Client Status

A Client that has a Closeout debt towards Ebury, will have certain restrictions applied (similar to the existing Active Credit scenario). Namely automated funds transfer would be disabled, disallowing the Client from automatically funding other open trades.

Instead, incoming funds from the Client (same currency as the Closeout debt) will remain on the Client's account. An automated notification will be sent to the Reconciliation Team, who will transfer the funds manually. (The primarily target is obviously the Sellback in debt, but may be possible to adjust on Client request).

Aside of a few specific cases --when Automatic Funds From Balance may not be applied-- this impacts all Ebury clients.

Closeout Actions

There are interactive actions that are currently impacting the value of the Original Trade, however in the future they should take action on the Closeout Value:

• Funding In
• Write Off

One of the main differences is that now the impact will show for the Closeout Value (instead of taking effect on the Original Trade's value, as before).

The second main difference is impacting Funds In action. Instead of the funds being automatically applied on the Client's trades, Funds In would become target of manual reconciliation (preferably towards the Sellback in debt).

Write Off currently:

Write Off in the future should be applied against the Closeout Value (displayed on the Closeout Ledger)

Funds in current behavior:

Funds in the future should be applied against the Closeout Value (displayed on the Closeout Ledger)

Trade Status and Balance Calculations

Any operations impacting the Closeout Value would be take out from Trade Balance Calculations. This means that the Trade Balance would be balanced out at the moment of Sellback creation.

However the lifetime of the trade doesn't change. The trade remains open until the Closeout is not fully funded or written off.

User Interface

Closeout Ledger native will display exactly as any other ledgers (client, trade, fee, etc.) on the same BOS UI view.

Reporting

Quantum reporting will required for transactions that appear as Closeout Ledger entries.

New QXT message sub-types (instruments) will be introduced for specific Closeout Ledger transactions, all under the ActualCashFlow main category.

Solution

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

For more information see Alternatives.

Background

Giving highlights on the underlying context/implementation of Ledgers in BOS.

BOS has its own internal terminology of money movements, representing various "stages" of transactional status with separate so called "virtual" accounts. These "virtual" accounts (CurrencyAccounts) do not map to real-life bank accounts. They are rather part of an internal accounting system. There are "virtual" accounts for various participants of internal Ebury money movements, like for clients, trades, payments, fees -- even for Ebury itself. These participants are represented as a group (i.e. 'trades' or 'payments' instead of an individual trade/payment).

So, to take an example: funding a trade translates to moving money between Client and Trade type of "virtual" accounts (that belong to the same Client user).

When we refer to "moving money" this action also manifests as data records in the BOS database.

"Virtual" accounts have their so called entries associated, representing every single money movement as an entry on the account. Every movement is a 'credit' on one side, and a 'debit' on the other side. This is reprsented by so called CurrencyAccountEntry data model objects, uniquely bound together, as a debit and credit 'move' with so called Asset-s (in our case).

So whenever we "move money" (for example, we'd automatically deduct a fee), we are performing a so called MoneyWorkflow action, that resutls in two CurrencyAccountEntries on two different types of "virtual" accounts of the same client. (In our example, the user's "virtual" account of a Client type is debited, while the user's "virtual" account of a Fee type is credited. Asset objects (of different transaction types types) will make sure that the two "sides" of the money movement "belong together", together with keeping track of additional characteristics (for example the actual participants of the movement, like the particular Fee instance being involved).

What we refer to as 'Ledger Entries' is represented as a CurrencyAccountEntry in this model of business data and workflows. The CurrencyAccount types (Client, Trade, Payment, etc.) precisely correspond to the BOS ledger types.

As a clear consequence, we need to introduce a new, "Closeout" CurrencyAccount type, to represent the "Closeout side" of money movements that belong to the Closeout Ledger. (To increase clarity, we are also planning to introduce a new Asset type, clearly marking Closeout-related transactions.)

All in all, introducing new 'ledger' displays/entries/etc. maps to the introduction of new (or old but altered) underlying transactional workflows.

When we separate Closeout Value-related ledgers, in reality we introduce new money movement workflows, that will be applied on trades, after the trade was sold back. These new MoneyWorkflows will result in transactional objects that are clearly associated with Closeout movements, instead of "regular" movements (i.e. for trades within their life-cycle, before being completed or sold back).

Data

These changes are to be introduced on a data level. We'll need to extend the current CurrencyAccount data model with a new type, specifically for Closeouts. Similarly, we need to add a new transaction type for Asset-s.

MoneyWorkflows

Moneyworkflows represent the core functionality, the actual (virtual) money movement behind the ledger. This is the core part of the solution, where the Business Logic lies.

Existing moneyworkflows will need to be extended to correspond to the requested functionalities targeting Closeouts. This sounds fairly straightforward, as Closeouts functionalities are (almost) identical to already existing Trade functionalities. I.e. it seems no "revolutionary" new behavior or feature is to be introduced.

Yet reality is a bit more complex than that. There may be additional, internal movements that need to be defined in addition, introducing additional complexity, further than a moneyworkflow "changing" target.

Balance Calculations

"Re-targeting" existing workflows (write-off, etc.) is pretty delicate.

Non-negligible adjustments have to be performed on balance calculations, with particular attention.

Furthermore, introducing the Closeout Ledger has implications on the Original Trade’s status calculation as well (fully funded, etc.).

User Interface

The existing BOS UI Ledger interface will be able to display the new Closeout ledger type (after minor modifications).

Interactive access

BOS UI interactive calls have to be adjusted, to refer to the "re-targeted" workflows instead of the current ones.

Client Status

As soon as the Client has an open Sellback with a debt, AFFB for the Client would get disabled, and kept as such until the Closeout debt is recovered.

We are planning to reuse already existing workflows implemented for a very similar purpose (Active Credits).

AFFB alrady has a way to only take action under certain conditions. We will have to add a new check --whether the Client has any Closeout debt in the currency in question-- so that AFFB mechansims would be bypassed.

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 introduced 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 introduced 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.

No braking changes are to be introduced, but instead extension of existing choice fields defining types for CurrencyAccount-s and Asset-s.

Data Sources

• Input data sources
  • BOS Trades information (see [Closeouts Basics])
• 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.