The purpose of this article is to cover how all lifecycle stages of all transaction types should be considered when building position views for both front, middle and back-office use cases. This article is one in a series we've done on IBOR Technology.
State – all trade lifecycles in asset management
In accounting terms, a trade is either posted (and wholly visible in the accounts) or not posted (and wholly invisible): this is a poor reflection of reality.
Transactions almost all emerge into the world in an uncertain state, mature into greater certainty over a period, and end up (almost) certain only after they are complete and settled. Even then, late changes and disputes can occur.
A trade starts as an idea in a portfolio manager's head or as an output from a model. It may or may not take place, and its timing and terms are uncertain. Over time it acquires some greater commitment and definition, as it progresses from an idea into a firm intention (as an order). However, it may still fail in whole or in part, and its price is still uncertain.
The order becomes accepted as a placement, and its probability steps up accordingly. When (and if) it is executed, then its value and quantum become clear, and its probability of completion takes a further step up. At this point, default or other settlement failures are still a material risk.
Ultimately the transaction is given effect by settlement in the Back Office, and it becomes an actual movement of cash and stock. Late adjustments and reversals apart, its terms are now well known, and its certainty is high.
This completes a lifecycle of a trade, from idea or model, to settlement.
All transactions go through key stages in the trade lifecycle
Most transactions goes through state transitions in a similar way:
-
fixed income trade lifecycle, e.g. income from the coupon of a bond;
-
an elective corporate action;
-
a fee paid to a custodian or service provider;
-
monies received from a client as a portfolio cash injection; and
-
the payment of proceeds from liquidation or litigation.
All have a set of key stages and all grow in certainty and precision as they progress through the stages.
A consequence of this evolution is that our view of transactions changes over time. Our expectation of the impact that a transaction will have on position data - holdings and cash - is not constant either.
How positions are affected by the trade lifecycle
Transaction states are our way of representing the increasing precision and certainty of transactions over time. To understand positions, we need to know what transactions have been included in the position that is presented. More specifically, when we are presented with a position, we need to be very clear on what transactions and what states of those transactions it includes – and excludes.
Transaction data in all states provides value. In conventional buy-side technology, transactions are captured at arbitrary points in their trade lifecycles, and at different points for different transaction types, making position data consistency hard or impossible to achieve. Capturing each transaction as soon as it appears ‘over the hill’, in an uncertain state, will add value to some consumers in some contexts, and will enable us to achieve consistency in the quality of position data.
This is where the Investment Book of Record (IBOR) comes in. A key principle of IBOR design is that we should not lose data that is of value, just because we fail to capture the full lifecycle of transactions.
Challenge for efficient Transaction Lifecycle Management
1. Front to Back trade lifecycle states aren't standardised
An obvious problem with transaction states is that every system vendor decides on the states of trades and positions that it will support; consequently, they’re generally very different between platforms, and there is no standard or consensus.
2. Asset classes don’t share transaction states
Another obvious problem with trade state is that the lifecycles of different transaction types are themselves diverse. For example, the state of an equity trade might transition over its trade lifecycle between the following states:
-
“What-if”
-
“Routed” (to market)
-
“Working” (acknowledged)
-
“Executed” (part of in full)
-
“Confirmed” (matched)
-
“Settled”
At the same time, the lifecycle of a dividend could have the following states:
-
“Estimated”
-
“Declared”
-
“Post-ex date”
-
“Paid out”
There are upwards of 100 transaction types recognised in most asset management contexts. Hence, it would be complex in the extreme for consumers of positions to understand the exact content of a position in terms of the native states of all of its constituent transactions. Fortunately, for the purpose of IBOR, we do not need to do this.
Position states are universal through the various buy side trade lifecycles
The native states of transactions are very important for their detailed management, but, from an IBOR point of view, we just need to know how certain the underlying transactions are, and therefore how certain the resulting position is.
It’s a potential strength of IBOR design that key events in each transaction’s lifecycle move certainty upwards in discrete steps, and those key events are very consistent across transaction types.
For position purposes, we need just a small number of states:
1. Estimated: Also called “pre-trade”, where the timing, quantity and value of the transaction are imprecise.
2. Known: Often called “executed”, where the timing, quantity and value of the transaction are known with precision, but the terms are not locked and there is no contractual obligation on the parties.
3. Contractual: Sometimes referred to as “confirmed”, where the terms are locked and there is a contractual obligation to pay / deliver, but the payment and delivery are yet to take place; and
4. Physical: Also described as “final”, where the payment and delivery have taken place, and the transaction is complete (unless unwound).
Positions states explained
The first position state of any transaction, “Estimated”, is the most uncertain state. We have some expectations about the timing and quantity / value of the position impact of the transaction, but all of these are imprecise at this stage. Think of an order, where we don’t know when or if the transaction will happen, nor how much of it will happen, nor the price at which it will happen. However, we do have loose expectations of all of these.
The next position state, “Known”, corresponds (for an order) to execution. We acquire precise data regarding the price, quantity and timing, and our certainty steps up. However, there is no obligation on the parties to complete the trade until confirmation.
At confirmation, the trade details are formally locked and a contractual asset and a contractual liability are created. This step creates the next step-up in certainty, and generally triggers recognition of the trade from an accounting perspective. The transaction is now in a Contractual state.
There is still a risk of failure or default before settlement. On settlement, delivery and payment physically take place, and our certainty takes its final quantum step up. Certainty can never reach 100%, but this is as close as it gets. This position is the “Physical” state.
Live position extraction
These position states enable us to generalise across all transaction types, and to describe the certainty of both transaction and position data in a simple and consistent way. The trade states required by the IBOR can be mapped from the more detailed trade lifecycle events in underlying transaction processing platforms. For users, it becomes fast and intuitive to understand positions delivered by the Investment Book of Record, since the number of states to consider is just a handful.
Variations of the transaction lifecycle states in the Front and Middle Office
Some IBOR designs deploy variants on these 4 states, which can serve useful purposes, depending on context.
Pre-trade state
Some Investment Books of Record split “Estimated” into multiple states, for example into:
-
Simulation: Where a portfolio manager in the Front Office might be playing around with different rebalancing scenarios to understand the impact on exposures and cash ladder.
-
Pre-trade: Where a rebalancing scenario has been finished. Orders are generated and checked officially for pre-trade compliance, after which trading takes ownership for execution, before the next workflow step is handed over to the Middle Office.
The splitting of states here is only relevant for transactions that require a proactive effort by the manager, such as deciding to allocate a deposit of cash. For transactions that are a function of assets held, e.g. a coupon payment or a dividend, the “Estimated” state would not be subdivided.
Working state
Another variation we’ve seen is the addition of another state between the “Estimated” (e.g. pre-trade) and “Known” (e.g. executed). The name of such a state could be “Working” (which is the case in Limina's Investment Book of Record). For an equity order, this would be when it’s in the market but hasn’t yet been filled.
Naturally, it’s not applicable to all transaction types, for example a dividend would transition directly from “Estimated” to “Known” (declared) and hence skip the “Working” state.
Mapping asset management trade lifecycle stages to position states
It’s common for position views in conventional asset management platforms to be constructed from a mix of different transaction states, which are generally the latest transaction states available to the platform at the time that the position view is presented. This creates an inconsistent position view, where, for example, a simulated order is included while an estimated (i.e. undeclared) dividend isn’t.
An example of a problem that this creates is that the forward-looking cash ladder can’t be trusted. This is because hypothetical settlement payments for an order are included, but an estimated dividend isn’t.
Let’s look at two consumers of the position data and how this example could impact them:
-
Portfolio manager: They can see the implication of the order, but not the dividend. Hence, over time, the front office will start to feel that the data is incomplete.
-
Middle Office operations: When reconciling against custodian or accounting positions, the positions in the reconciliation will include orders that are not yet seen by the counterparty, so there are false recon breaks. A parallel spreadsheet that adjusts for these is often created as a workaround.
A properly constructed Investment Book of Record will always construct positions from a consistent set of transactions in a consistent state or set of states. In other words, it would support both a view where the order and the undeclared dividend are included (for the Portfolio Manager in the Front Office), in parallel with a view where neither is included (in the Middle and Back Office for Operations). This enables the best Position and Cash Management.
Summary
In this article, we have explored state, which is the first important parameter of transactions. The second key parameter of transactions (and positions) in the context of an IBOR is time, which we explore in this article about better portfolio views.
.svg)
