Background

This page introduces the functional framework — the terminology and components — we will use to discuss the Architecture for managing securities transactions, positions, and balances. It is supported by the Technical Foundation component of the Architecture.

The Framework is derived from experience with the design, development, and support of systems that have proven successful in production use. Much of the material will be recognizable as table layouts and sample data from operational databases, and algorithms that are re-formatted program code. The meaning of the functional framework at one level is simply operational: it works, and it works well.

The presentation of the Framework here is not exhaustive. It addresses only those features relevant to managing transactions, positions, and balances. For simplicity it does not address multi-company environments or multi-currency in detail. It is also directed towards US accounting and regulatory requirements.

Description

A useful description of the purpose of the Framework is:

This Framework centers on events of consequence to positions and balances of importance to the firm. These events are captured through operations that result in the production of one or more related register entries.

This description is an extension of [FASBCon6], ¶134ff. It extends that reference to the implementation level; thus "operation" and "register" above. The biggest difference from the FASB discussion is that we are also concerned with open items, which leads to "related". In general the concept of open items is the biggest difference between a general ledger system and a sub-ledger such as a trading system.

Each part of the definition has specific business and IT meanings.

events of consequence

[FASBCon6] uses the term "event", which it then defines as "happening of consequence". We have simply combined them.

Right from the start, then, "event" is both broad and nebulous! The events include:

• Securities transactions and agreements such as buys and sells, repos and reverses.
• Receives and delivers, wires, coupon and interest payments.
• Calls, conversions, assignments and exercises, and maturation.
• Cancellations, corrections, and repricings.
• Occurrences such as price changes (these affect unrealized P&L, a component of "balances").

Basically, if positions and balances are going to be affected, it is an event of interest to us. In practice, "event" is used only to set the stage. The specifics emerge from the implementation.

positions and balances

This narrows our focus. We are not particularly focused here on such things as counterparty structures, the security master, or trade routing.

But we are including all positions and balances. We are not looking solely at a subset of transactions (e.g., only buys and sells, ignoring repos), nor are we looking only at quantity or money. We are also interested in both trade date and settlement date values.

of importance to the firm

We include not just the firm's positions, but also those of clients and anyone else of enough importance to the firm that positions and balances need to be held.

operations

The second half of the definition is the extension to the implementation level. Operations are used to implement the capture of events. They include:

• Trade and agreement entry.
• Cancellations and corrections.
• Agreement repricings.
• Collateral movements.
• Pair-offs.
• Settlement via receives and delivers.
• P&L calculations of all sorts.

register entries

The impact of a operation on positions and balances is recorded in one or more register entries (records). The operation to enter a Buy of a T-Bill would result in a single register entry. A correction of it would result in the creation of two: the reversal of the prior entry and the new value.

Another example is a security Receive. It is a single register entry.

related

Unlike a general ledger, where journal entries are independent, stand-alone entities, it is necessary to be able to relate register entries. Two examples are seen above. First, the three register entries associated with the correction of the Buy (original, reversal, and new value) must be linked. Second, the new register entry for the Buy must be associated with the Receive that closes the transaction.

Example

In presenting the Framework we will discuss a simple example of the firm buying a Treasury bill for its own account. The firm, which we refer to as OurCo, could be a broker/dealer, investment bank, hedge fund, pension fund, or similar institution.

Date	Activity
6/01/XX	Firm trader 9012 executes a trade to buy 1,000,000 (face value) of security TBill from counterparty 7334 at a price of 98.5. Settlement will be on 6/04/XX. ("TBill" is a specific bill with a particular issue and maturity date, but we refer to it simply as "TBill" to save space in the presentation.)
6/01/XX	At end-of-day the security is marked to 98.5.
6/02/XX	It's learned that the trade was input with an incorrect price. The price is corrected to 99.5.
6/02/XX	At end-of-day the security is marked to 98.5.
6/03/XX	At end-of-day the security is marked to 98.5. There is no other activity associated with the trade.
6/04/XX	The trade settles. 1,000,000 bonds of TBill are received from counterparty 7334, and $995,000 is wired to that counterparty.
6/04/XX	At end-of-day the security is marked to 98.5.

The initial discussion will be on trade entry, correction, and settlement. End-of-day prices, and thus unrealized P&L, will be addressed later.

Components

The framework addresses the description above through three components:

• Data Structures. The transactions, positions, and balances that are the focus of the framework are organized in a set of entities described in Data Structures.
• Knowledge Base. The data and processing is organized, controlled, and extended through the use of metadata described in the Knowledge Base.
• Processing Rules. The transactions, and the updated position and balances, utilize a set of explicit processing rules described in Processing Rules. The computation of P&L is also covered by this component.

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