Introduction

The Functional Framework component of the Architecture embodies the data, metadata, and processing rules that support financial securities transaction management. The sample data on this site is derived from the activities of a hypothetical broker/dealer in fixed income securities, primarily Treasuries and corporates.

In your environment you may naturally have additional questions:

• What do you do if you want to use the Framework to support other security classes, e.g., equities?
• How do you add commissions and fees to a transaction?
• How do you create a completely new type of transaction?
• Is there a way to handle new forms of settlement?

These are the topics we address on this page. The effort needed to accomplish them falls naturally within the three components of the Framework. The effort is summarized below in terms of database changes, programming, and populating tables.

Component	Database changes	Programming	Table loads	Comments
Data Structures	No	No	Auto	The tables will be populated as a result of the Processing Rules. No database or programming changes are required.
Knowledge Base	No	No	Yes	This is where the bulk of the effort is required, in setting up new entries in the various tables of the Knowledge Base. In the Detailed Model below, the relevant entities have unshaded headers.
Processing Rules	No	Perhaps	No	Basic processing of transactions and settlement requires no additional programming. Trading P&L and interest require no additional programming. Programming may be required for new types of accruals.

This topic is a companion to Adapting the Framework, which addresses utilizing portions of the Architecture within an existing system environment. Here, however, we remain within the Architecture.

We repeat the Detailed Model from the Data Structures.

Detailed Model

Register Structure

The Register data structure comprises three entities. From from the top down, the entities are linked by many-to-one relationships.

Entity	Description
Transaction	One row for each logical transaction (e.g., a BUY, SELL, REC). Its primary key (e.g., 12) is constant over the history of the transaction.
TxRegister	One row for each version of a Transaction. E.g., 12-1 is the original BUY, 12-2 is the reversal generated during the correction process, and 12-3 is the new value resulting from the correction.
TxRegDtl	Each version (TxRegister row) can have any number of distributions associated with it. The original BUY (12-1) has two distribution items, 12-1-1 for the quantity and 12-1-2 for the principal.

The primary component of the Knowledge Base relevant to the Register is the Register Type, referred to as TxRegType in the model. The Knowledge Base discussion presents a simplified version, based on the Generalized Model. However, as mentioned in the Knowledge Base discussion, the Detailed Model is the true underlying conceptual model.

Adding a New Distribution Line Item

One of the first questions you might well have is, "How do you extend the Register to accommodate additional types of transaction amounts?", e.g.,

• Fees.
• Commissions.
• Bond interest.

The question can be restated as, "How do we control the number and type of TxRegDtl entries?".

The Knowledge Base discussion of Register Type presents two sets of distribution information, one for the Quantity and a second for the Principal. When developing a concrete implementation of the Architecture, however, the Register Type provides for any number of distributions. Some transactions may have no Quantity (e.g., wires, coupon payments); others may have no monetary amounts (e.g., free receives, segregation moves). Likewise there may be multiple distributions of quantity and/or money. This is how the additional distribution line items are established.

The discussion in Register Type of the control fields (Type and Account) applies individually to all monetary and quantity distributions.

The answer to the question, then, is simply to set them up via the Register Type maintenance function.

Adding a New Class of Securities

What is necessary in order to add a new class of securities, e.g., equities, to the Framework presented on this site, which is for fixed income?

In general is is not necessary to set up new Register Types (e.g., BUY, SELL, REC). The distribution in terms of the quantity and monetary account codes are the same as for a Treasury Bill, for instance. The quantity on a BUY is still long the trading account and short the counterparty. The money is a debit to firm inventory and a payable to the counterparty.

You may wish to set up new Register Entries for control, audit, or other purposes. But even within fixed income, a bond will have interest (and the associated distribution) while a discount instrument such as a Treasury Bill won't.

The important point is that the Distribution Account codes be used consistently. This enables the processing components, such as Inventory and Trading P&L, to be reused without reprogramming. This is the reason the Distribution Account codes were standardized up front.

Adding a New Accrual

Standard accruals (e.g., realized and unrealized P&L, coupon interest, loan interest, funding) can normally be reused without reprogramming as they are based on Distribution Account codes, which are general.

Any specialized accruals, however, will have to be programmed. An example is medium-term loan syndications, which have related borrows and loans that need to be accounted for. Mortgage-backed securities have a principal and interest payment component that has to be addressed.

However, all accruals share a common structure. In particular, the sole output of an accrual process is a set of register entries. These are processed by the standard Processing Rules, in particular Transaction Operations and Positions and Balances. At this level, they are just another form of transaction input, such as on-line entry, batch file submission, or XML messages.

Adding a New Type of Settlement

More precisely, here we are considering new ways of closing a Register Entry. From the Knowledge Base perspective, a cancel of a BUY is very similar to settlement via a REC. The process will require new entries in either or both of two metadata entities of the Knowledge Base:

Knowledge Base	Model Entity	Discussion
Register Type	TxRegType	The Register records the distributions that update the Positions and Balances. For example, a cancel is recorded in the Register as a REV entry, while a receive is a REC. The metadata (including the Register template) is set up in the Register Type.
Association Type	TRAType	This links the Register item being closed (e.g., the BUY) with the newly generated Register item (e.g., the REV or REC). The cancel uses CXL and regular settlement uses SETL. These are set up in the Association Type entity.

From a Data Structures standpoint, there is only one difference between cancelling a Buy and having it settle via a Receive: the distribution. The REV entry simply reverses the distribution of the BUY (they thus net to zero for both quantity and money). A REC differs from the REV in that the credit is to the G/L account CSH (rather than long inventory) and the short is to the BOX (rather than the trader position). The long and debit entries are the same as for the REV.

As with all codes from the Knowledge Base, these are just examples used in one implementation. Any codes can be used. For instance, in the sample implementation it was decided to use a single Register Type (REV) for all cancellation (reversal) records. You could proliferate them (differing only in the code) for each type of record being cancelled, but that was found to be overly complex with no compensating benefit.

Another example is a counterparty DK'ing a trade. There are many ways it could be effected, but the simplest is to use the existing REV Register Entry and set up a new Association Type, DK. It will match CXL in almost all respects, with the only difference being in the code used.

You see this in the Association Type for the pair-offs. There are separate codes for early and late pair-offs, reflecting when these were handled operationally. Everything about the Associations is identical, except for the codes. But those codes helped during the operational and proof processes, so were felt to be worthwhile.

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