|Eclipse Software, Inc.||Functional Framework|
|ESI Home||Architecture||Glossary||Links||Contact Us||Site Info|
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.
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.
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.
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.
Another example is a security Receive. It is a single register entry.
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.
|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.
The framework addresses the description above through three components:
Copyright 2005-2018, Eclipse Software, Inc (ESI). E-mail: WebSite@eclipsesoftware.biz.