Eclipse Software, Inc. Functional Framework

Contents

Key Links

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:

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:
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.
DateActivity
6/01/XXFirm 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/XXAt end-of-day the security is marked to 98.5.
6/02/XXIt's learned that the trade was input with an incorrect price. The price is corrected to 99.5.
6/02/XXAt end-of-day the security is marked to 98.5.
6/03/XXAt end-of-day the security is marked to 98.5. There is no other activity associated with the trade.
6/04/XXThe trade settles. 1,000,000 bonds of TBill are received from counterparty 7334, and $995,000 is wired to that counterparty.
6/04/XXAt 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:


Last updated: August 2, 2016.   Copyright 2005-2017, Eclipse Software, Inc (ESI).  E-mail: WebSite@eclipsesoftware.biz.