| Eclipse Software, Inc. | Positions and Balances |
| ESI Home | Architecture | Glossary | Links | Contact Us | Site Info |
Contents
Key Links |
Positions and balances were introduced in Data Structures. Though they represent derived data, having a concrete model is important for two reasons:
The Framework uses a uniform foundation for all positions and balances: the Distribution Accounts. There are explicit charts of accounts for both money and quantity amounts. These are used for storing all positions and balances, for all Date Bases.
This is in contrast to the many systems that use a variety of structures for accounts stored in different entities: trader positions, customer positions, stock record, fails, the cage, etc.
The approach used here was adopted because it increases transparency and decreases reconciliation issues. It is also much, much simpler.
Securities processing involves the use of multiple date bases. These are actually quite simple, simple not in the "simple to describe, but difficult to implement" sense, but in the "simple to describe and simple to implement" sense. There are two underlying concepts for date bases: contractual terms and accounting control. Understanding them makes the entire topic straightforward.
We'll start with the original Framework example. A trade is made on 6/01 to purchase a TBill, with settlement on 6/04. It is corrected on 6/02 due to an incorrect price entered on 6/01. It settles on 6/04 via a Receive, which captures the receipt of the securities and the sending out of money.
In addition to trade date and settlement date, we use the term effective date to describe the date that an action is entered into the system. The effective date of the trade is 6/01, as it was entered into the system on that date. The correction has an effective date of 6/02. The receive has an effective date of 6/04.
It is important to realize that the terms of the Buy transaction, including the trade date and settlement date, are part of a contract. The contract is binding as of the trade date. This is the reason trade date reporting is important.
The settlement date is when ownership changes hands, regardless of whether the transaction actually settles. If a Buy were failing across a coupon payment date, for instance, the firm would be entitled to the coupon payment from the bond issuer, even though the firm has not received, or paid for, the bond. The same is true for anything having to do with ownership of a security: dividends, voting rights, calls, splits, conversions, etc.
It is this ownership aspect of the settlement date that makes settlement date reporting important. It is also the reason that, from a purely financial point of view, fails to receive are always good: you get the benefits of ownership without having to pay anything. Likewise, fails to deliver are always bad financially (there are other considerations, of course).
This applies to trade date and settlement date for contractual transactions. In Data Structures we see that all Register entries, not just trades, have a trade date and settlement date. Trade date and settlement date for the other register entries are discussed below. They are usually straightforward.
| Register Entry | Description |
|---|---|
| Buys and sells | The dates agreed to contractually, as discussed earlier. See R12-1 in the example. |
| As of trades | These are simply trades where the effective date is greater than the trade date. |
| Receives and delivers | The trade date and settlement date are the same, the date the money and securities changed hands (non-DVP situations are set up differently in the Knowledge Base, of course). This also applies to wires and to forms of settlement generally. See R39-1. |
| Money differences | To a certain extent it's irrelevant, because the Register entries have no distribution and thus don't affect positions and balances. From a control standpoint, the trade date and settlement date would be set to the settlement date of the original trade. The same applies to pair-off differences. |
| Journals | Trade date and settlement date are set to the date of the situation/event the journal entry applies to. For realized P&L accruals, for instance, this is the business date being accrued for. |
| Repurchase agreements | Both the open and the close have the same trade date, which is contractual. The open's settlement date is normally the same as the trade date. The close's settlement date is the end date, which may either be fixed or open. |
| Reversals | Trade date and settlement date are that of the original register entry. The Association Type should be set up so that no fields are modifiable and the effective date is set automatically. See R12-2. |
| Corrections (new value) | This record reflects whatever changes were made. In general the Association Type disallows changing the trade date. See R12-3. |
This table shows that for all register entries other than contracts (and their audit history), the trade date and settlement date are normally the same.
In addition to the business (i.e., contract) nature of securities transactions, the major influence is accounting procedures. Accounting proceeds on the basis of formal periodic procedures (see that entry in [AcctLangBus05]). The most well-known is the year-end process, which includes making adjusting entries and closing accounts. Once the process is complete, entries can not be made to the closed year (except under very unusual circumstances).
Firms almost always have quarterly and monthly closing processes as well.
Securities firms also perform closes, (internal) reporting, and reconciliations on a daily basis.
Daily closes means that any event that should have been recorded on a prior day, but wasn't, gets posted on the current day. We saw in the Framework example that the price was entered incorrectly on 6/01, the trade date. It was corrected on 6/02. Rather than go back and change the prior (closed) day, the correction hits the books on 6/02. This was reflected in the positions and balances.
Rather than two date bases, there are (at least) five that are relevant to securities processing:
As we will see, TE and SE are required for regulatory reasons. Those are the two reflected in the example in Data Structures. The question is whether you would want to implement any of the other three.
ED is useful because control is performed on a day-to-day basis, and it is natural to ask what was done on a given day. On the other hand, since effective date is almost always the same as or later than trade date, TE amounts can usually be used to serve the control purpose as well. You would want an exception report in that case that shows Register items where effective date is less than trade date.
SD is useful because it is the accurate record of security ownership. You may not pick up coupon and dividend payments correctly if you rely on SE. Funding and cost of carry will also be incorrect. The tradeoff is that having both SD and SE will naturally lead to control and reconciliation efforts that might not be worth the additional effort.
TD may be useful, but the added value is less than in the SD/SE case.
Finally, we note that the only date on the Association entity is the effective date. This is because Associations deal only with open/closed status and history and do not affect positions and balances.
Trade date / settlement date basis is often confused with accrual / cash accounting. This is not a productive analogy; in fact, it is particularly misleading because the situations have a surface similarity that is not reflective of the business realities.
In accrual accounting, if you buy something it hits your books when you receive the invoice. In cash accounting, it hits your books when you pay. These are two separate events. In trade date and settlement date accounting, however, the events are exactly the same in both bases. The only difference is which date to associate them with.
Two approaches to storing positions and balances are generally encountered:
The Data Structures for positions and balances depicts the model we are using. The primary key encapsulates most of the design decisions that were made:
| Field | Description |
|---|---|
| Date Basis | The model exhibits storing the TE and SE bases. Including this field explicitly provides for additional bases and makes the processing simpler. |
| Amount Type | The only types we've encountered are quantity (positions) and money (balances). This field emphasizes the commonality in the processing of these two types of data |
| Year-Month | Given the over-all approach of the Framework, the major decision has to do with the time dimension. Having the rows represent months (the other alternatives are day and year) was arrived at through experience. |
| Book Type | Used to distinguish books and records from memorandum values (primarily stock record locations) and off-balance sheet figures (such as notional amounts). This field can also be used for budgets, forecasts, or similar uses. |
| Account Type | Used because, unlike a general ledger with a uniform chart of accounts, this is a sub-ledger application with different types of accounts. |
| Account | Includes general ledger (money) accounts and locations (stock record), but also sub-ledger accounts for customer receivable/payables and trader positions. |
| Security | Positions and balances are almost always by security. |
| Trading Acct | Necessary for general ledger accounts so that we can report by trader. |
A fairly extensive example can be found in Coupon Interest.
Returning to a comparison of the two approaches, the sub-ledger approach is based on a particular use of the data, not the data in and of itself. The benefit is that many standard reports for traders and counterparties can get the majority of their fields from a single row in the database. The drawbacks are:
The major benefit of the general ledger approach is that it easily extended without reprogramming. It is efficient because only the accounts being used are stored. Once the infrastructure is built it is easy to update.
The big drawback to the general ledger approach is that it is more abstract. This is not a trivial point. You have to build a fair amount of infrastructure in order to support the flexibility. Reporting information from the system almost always requires many accesses to different rows, usually in the same tables.
The beginning balance bucket is a convenience. It makes it simpler to derive month-to-date values.
We start by noting that all date bases are updated for all transactions. It is customary to look at certain subsets for certain purposes (see Position Reporting). Trade date figures are used for trader positions. Repos are referred to as a "settlement date concept".
These statements are about reporting, not about accounting for transactions. Just because people don't normally look at repos on a trade data basis is not a reason to omit updating trade date amounts for them. Nor is there any reason to decide not to update trading P&L on the settlement date books. Simply don't report them.
The Framework approach makes the update of positions and balances very simple. When a Register entry is created, all position and balance records that will be affected by it are updated at that time. The steps are:
A given amount on a trade will update four rows: the debit and the credit, for two date bases (or more, if established in the Knowledge Base). In our example, which includes only quantity and principal, eight rows at a minimum will be updated.
Benefits of this processing approach include:
The two topics of this section can be considered reporting applications, but the discussion here centers on our Framework and on the commonality between the two applications.
Trader positions are accounted for on a trade date basis (we'll get into the reasons for this in Inventory and Trading P&L). A trader position report typically has columns for the following:
In the Framework, all the fields are obtained from the PandB entity. To create a trader position report for 6/03 use the Day 3 bucket of the TE / PRIM records. Position uses AmountType = "Q" and account type = "T". All the money fields (position, P&L) use AmountType = "M". We will discuss position and P&L in Inventory and Trading P&L.
Generally settlement date position is not of concern to the trader; they are managing risk and profitability on a trade date basis. If you wanted to include it, just pick up the current SE values.
The Framework uses a typical general ledger architecture approach. All the data is there, just spread among multiple rows. A sub-ledger approach, using a trader record, would get most of the fields from a single row, but with the limitations mentioned earlier.
There are many ways in which the stock record is presented. The situation is somewhat confused as the term is used to describe both a function and a report.
[AICPABDSec06] defines it this way (¶2.08):
The stock record is a double-entry accounting system for shares of stock or principal amounts of debt by security issue.
(Note that in this case they are using "principal" to refer to the face amount (quantity) of the bond. The term is also often used to refer to the money associated with the amount of securities, as in "principal = price * quantity".)
As a report, the stock record can be defined very easily:
The stock record report is the settlement date basis quantity trial balance.
The Framework incorporates an explicit double-entry accounting system, as described in a number of areas:
Given the above, the stock record report is simply a subset of the PandB entries. Taking a look at the Framework example, the stock record is nothing more nor less than the rows with keys SE-Q-PRIM for whatever month you are reporting, and the bucket for the appropriate day.
On 6/04, for 6/04 the stock record for security TBill is:
| Security TBill | ||||||
|---|---|---|---|---|---|---|
| Account | Long | Short | ||||
| T | 9012 | 1,000 | ||||
| L | Box | 1,000 | ||||
This seems very similar to what we did for the Trial Balances we looked at in Transaction Operations. Indeed, all we've done is take the SE-Q records rather than the TE-M. Which is another way of expressing the definition given above of the stock record report.
The stock record report really is that simple, given the appropriate framework (which can be a bit of a given, of course). A surprising point is that, given the stock record's being a type of trial balance, you only seldom hear reference to a stock ledger, and almost never to a stock journal. Thinking in those terms makes stock record processing much easier to understand.
Looking back at the trader position and stock record together, we see that at one level they are very similar. You just select different subsets of records from a single entity (PandB), based on the report requirements. Since all updates to all sets of books are done at transaction time, the data is always coming from a consistent source.
In this section we take a look at some of the implications of the Framework.
It's the end of the day on 6/03. Our stock record has no entries, as nothing has a settlement date of 6/03 or before.
On 6/04, rather than the processing that occurs in the example, we consider a disaster where the firm is not able to conduct any business, not even wire cash or move securities. What will the stock record be at the end of 6/04?
It won't be the 6/03 stock record (empty), because our trade has now reached settlement date. Though no processing is going on, we still acquire ownership of the security on 6/04, along with the liability to the counterparty. Thus the stock record looks like:
| Security TBill | ||||||
|---|---|---|---|---|---|---|
| Account | Long | Short | ||||
| T | 9012 | 1,000 | ||||
| C | 7334 | 1,000 | ||||
The point is that if we look at the SE-Q-PRIM rows for Day 4 as of 6/03 in the PandB entity, they have exactly the values above. We have a position and a fail.
The Framework supports this in a couple of ways.
Copyright 2005-2021, Eclipse Software, Inc (ESI). E-mail: WebSite@eclipsesoftware.biz.