Introduction

The Functional Framework component of the Architecture embodies the data, metadata, and processing rules that support financial securities transaction management. Those discussions are in the context of a comprehensive implementation of all the components.

In practice, completely new development of a system is much less common than extending or adapting an existing system. On this page we address how to adapt components of the Framework within the context of existing systems.

This is doable because the Framework is as much a conceptual model as a concrete implementation. We look to extend the benefits of the conceptual model to other implementations.

For a discussion of how to expand the capabilities from within the Architecture, see Extending the Framework.

Modify Your Database?

In general the database is the most difficult part of a system to change. If you have that option, you can simply use the material on this site as a guide (the Framework presented here has been implemented almost exactly as presented).

For the remainder of this discussion we will assume the database is fixed, and we will look for other avenues for exploiting the Framework. In addition, non-database adaptations have the following characteristics:

• They are faster to implement.
• They are easy to implement incrementally or in stages.
• They are much cheaper.
• They are low risk.

The Importance of Mapping

The crucial preparation is to be able to map your current transaction stores, positions, and balances to those described in the Framework. This enables all the adaptations given below. Effectively we are implementing the Adapter design pattern (see [Wiki:Adapter]).

We are particularly concerned with the Register and Positions and Balances entities. The Association is used less frequently as it directs none of the Processing Rules or Positions and Balances updates. It will be used primarily for reporting.

For both entities described below, we need mappings both from the existing system to the Framework model, and from the Framework model to the existing system.

Mapping the Register

Within the Framework, all transactions and events are recorded in a single data store, the Register. Mapping an existing step will usually require the following steps:

• Identify all transaction data stores (e.g., pending trades, journals, bookkeeping entries).
• Map source stores to the Register model:
  • Cancellations are represented explicitly by two records.
  • Corrections are represented by three records.
  • Settlement activity is explicitly represented in independent records.
• Pay particular attention to getting the three dates (trade, settlement, and effective) set appropriately.
• Build self-balancing distributions for each transaction/event.
• Ensure that signs are represented accurately: all amounts in the Register model are unsigned. Any source sign information is mapped to the the appropriate side (debit/credit).

Mapping the Positions and Balances

A similar process must be followed for the positions and balances. It is usually simpler than the Register mapping, where there can be quite a bit of variability in representing cancellations/corrections and settlement activity. This process will normally involve the following steps:

• Identify all position and balance data stores. Common stores include trader positions, customer records, cage data, and other tables.
• Map source stores to the PandB model:
  • All entries are identified by an account, in particular the same accounts used in the mapping to the Register entries.
  • All entries are for a single account.
  • There are separate entries for money and quantity, and for each date basis.
  • All values are end of day balances.
  • Translate the values to the trial balance format so that the signs are consistent and correct.

It is important that all mappings be consistent with those used for the Register. It will be useful to get in the habit at this point of building the mappings on a table-driven foundation.

The adaptations that follow are presented in order from the easiest to the most complicated to implement. More importantly, each one builds naturally on those presented earlier.

Views / Reporting

Once the mappings have been built, the first step is to produce a function/view that takes a set of parameters (e.g., date range, account type), collects the source data, and creates an output in the Framework model.

The output can be in any form (e.g., result set, file, temp table), with a pipe architecture that can then convert to other formats (e.g., XML).

This output can be used immediately as the basis for user reporting.

Verification / Reconciliation

The model view can be used to verify/reconcile the current databases, without impacting the existing structures directly.

There are a number of reconciliations that can be implemented immediately:

• That the Register entries tie out to the Positions and Balances.
• That the Positions and Balances are internally consistent:
  • They are self-balancing.
  • No accounts have invalid amounts. E.g., the Box can only be short, reverse repo inventory can only be long.

Once those reconciliations are in place, you can create shadow versions of the accruals: trading P&L, dividends, and coupon interest. The output of those accruals can be compared to that created within the existing system.

Replace Existing Processing

Though we are considering only adaptations that don't modify the existing database, we can proceed to replace existing processing that does update the existing data structures.

The reasons for doing this are that the Framework model is generally easier to implement (once the mappings have been done) and reconciliation is built in.

Updating Positions and Balances

The logic for updating the existing positions and balances can be replaced with Framework-based updates through the following steps:

• Use the Register map from the existing system to obtain the transactions in terms of the Framework model.
• Use the verification logic to determine how the Register records should impact the Framework Positions and Balances.
• Use the Framework map to the existing system to translate these updates to the structures of the existing system.

P&L Accruals

You can use a similar approach for the trading P&L, interest, and dividend processing. Translate into the Framework model, use the algorithms given in the Processing Rules to determine the required updates, and map back into the structures of the existing system.

Metadata

One of reasons for the flexibility, extensibility, and transparency of the Architecture is the use of metadata structures in the Knowledge Base to control as much of the processing as possible.

This approach can be applied to any existing system by modifying hard-coded processing to be metadata-based.

Migrating

Though we have said that we are focused on adaptations that do not modify the existing database, the steps given above provide a means for an incremental approach to migrating to a Framework-based architecture. It is possible to replace part of the existing transaction structures with ones that are Register- and Association-based. Likewise it is possible to replace portions of the Positions and Balances structures with those from the Framework.

The only other modification to the work done earlier is to replace the mappings with ones that are more direct.

Copyright 2005-2021, Eclipse Software, Inc (ESI).  E-mail: WebSite@eclipsesoftware.biz.