This is post that has been requested several times, but we have never been able to write about this topic without producing a "War and Peace" tendency article. And so today, here's the long version of the answer to that question...
Background readingThe buy-side OMS, an appreciation part one...
The buy-side OMS, an appreciation part two...
OMS and EMS: Next moves?
OMS: Managing Drift
OMS: Broken business models
EMS: Staging is not an EMS
[We strongly recommend reading at least the first two of these blog posts before proceeding]
Order Management System as a workflow engine
The term OMS is short for "Order Management System". So what do we mean by this term? In this article we are looking at buy-side OMS only (a future article may look at sell-side OMS, in the meantime, this, this and this may be of interest). Look at the workflow in most modern long-only, institutional asset management firms:
Portfolio Managers create orders - in terms of specific instruments (sell 1.5m of bond X, buy 27 futures contracts etc.) or in terms of portfolio effect (sell euro denominated bonds in the long end of the portfolio to bring euro weighted average duration down to 9 years).
Trader receives the order and then executes that order in the market.
So how does an OMS come into play here? Somewhere the firm needs to record all of the details of the orders proposed and executed in the market, along with details such as decision making time, decision maker name and other meta-data. The place where that is recorded is generally within an OMS.
With that explanation we reach an important point: An OMS is a state machine. What do we mean by the term state machine? Wikipedia has a good explanation here and an interesting commentary here gives a counterpoint. For our purposes, we can consider a state machine as defining the states of an order as we go through the order lifecycle, for example:
- Created by PM
- Sent to dealing desk
- Accepted by dealer
- Sent to broker(s) for RFQ
- Executed
- Allocated
- Sent to back-office for further processing
Given that (vastly over-simplified) lifecycle, how does the OMS work? In essence, the states of the order are only valid in certain sequences - the states and the transitions between them are a subset of the mathematically possible set of state transitions. In other words - it makes sense for an order to move from "Created by PM" to "Sent to dealing desk" but it makes little sense for an order to mov3 from "Executed" to "Created by PM". So, from a starting point of "Created by PM" we do not have six valid next states. Understanding the valid state transitions is crucial to design and build of an OMS and sadly, per the link here it's often poorly implemented by developers who don't really understand financial markets.
OMS as a time stamping engine
Whether under EU regulation such as MiFID/MiFIR/MiFID2 or other, timestamping is critical for reconstructing the audit trail of orders for a firm, for TCA and for management information reporting. Again, this is typically performed within an OMS.
OMS as a portfolio management tool
In the above example trades the Portfolio Manager will require a considerable amount of data
OMS as a portfolio management tool
In the above example trades the Portfolio Manager will require a considerable amount of data
- instruments held in the portfolio
- calculated values of positions (value in instrument currency and portfolio base currency)
- derived values (percentage of portfolio held in an instrument)
- instruments not held in the portfolio
- benchmark weights
- mandate restrictions
- compliance restrictions
OMS as a state machine
If we continue to look at the state machine as the core of the OMS then fairly quickly one can imagine a state machine whereby the states are contained within one structure in the system (call it a database table if you will) and the valid state transitions are contained within a second structure
For the above example we would therefore have something like (partial list)
initial state valid next state
1 2
1 3
3 4
3 5
3 6
This is a vastly simplified version of an OMS that we designed and built in 2002.
OMS as a compliance engine
Before reading this section, a look at Buy-side compliance systems: Still 20th Century technology? will help. The OMS at a simple level can implement workflow hooks to allow third parties and/or vendor implementation staff and/or in-house developers to capture events and throw exceptions based on rules. In widespread usage this is really a very simplified implementation of a CEP, a complex event processing engine. More accurate to call it a simple event processing engine.
OMS as a market data sink
Real time and near-time market data is often shown within an OMS. The classic example is for equity markets where a price feed is often integrated into the OMS. Sadly in many cases this is a client-side integration whereby there is a link from a fat-client desktop application to a middleware layer such as DDE (yes, really).
OMS as limit minder
In the cases of OTC instruments the OMS can be used as a limit minder. In the case of an exchange traded instrument a limit order can generally be sent to an exchange. For OTC instruments such as spot FX the OMS can be used to manage limit orders and allow a degree of automation of sending an order to market when the market is within range of the limit price.
OMS as a market data sink
Real time and near-time market data is often shown within an OMS. The classic example is for equity markets where a price feed is often integrated into the OMS. Sadly in many cases this is a client-side integration whereby there is a link from a fat-client desktop application to a middleware layer such as DDE (yes, really).
OMS as limit minder
In the cases of OTC instruments the OMS can be used as a limit minder. In the case of an exchange traded instrument a limit order can generally be sent to an exchange. For OTC instruments such as spot FX the OMS can be used to manage limit orders and allow a degree of automation of sending an order to market when the market is within range of the limit price.
OMS as an interconnected entity
Consider FIX. FIX has a state model for orders that is simple yet robust. If we can take the core OMS state model and expose it directly via FIX Orchestra then it's entirely possible to have a future state where the OMS auto-generates the FIX Orchestra machine-readable rules-of-engagement directly from the state model and state transition model. In an interconnected world this is the true full-stop at the end of FIX...
What would this mean? That a savvy sell-side would expose the order state model directly to FIX Orchestra and auto-generate their FIX Orchestra machine-readable rules-of-engagement. This would then be shipped to any connected firms which will then be able to automate on-boarding testing immediately and after every change implemented by the sell-side.
Note that for FIX Orchestra to work fully both sides of any order flow need to use FIX Orchestra. That's not mandatory, since it's possible for the machine readable rules-of-engagement that Orchestra creates to be parsed and made human readable. But that would be rather like printing an email and replying in handwriting by letter - viable but somewhat missing the point...
Exchange creates a new order type - new FIX Orchestra file - sell-side can trade immediately.
Sell-side connects to a new exchange - new FIX Orchestra file - buy-side can trade immediately.
Sell-side creates a new trading algorithm - new FIX Orchestra file - buy-side can trade immediately.
Sell-side implements FIX allocations - new FIX Orchestra file - buy-side can trade immediately.
The shift in Electronic Trading will be huge - as the trading world will move to a model of computer-to-computer trading whereby the human is moved off the critical path and into a supervisory role.
Update 27th October 2018
End of the line for buy-side OMS
Summary of whitepaper on the evolution of the multi-asset-class trading desk
Whitepaper on the evolution of the multi-asset-class trading desk
Driving OMS reform
Comments
Post a Comment