The buy-side OMS, an appreciation part two...

The term OMS is used as an umbrella for a number of pieces of distinct functionality, this post will list them and provide some direction for a future landscape.
Firstly, have a look at the first post in this series - The buy-side OMS, an appreciation part one...
What functional and non-functional requirements exist for a modern OMS?
  • High availability
Many pieces of buy-side technology have an appalling level of availability and require system intervention and restarts after any technology issues.  A modern platform should offer a much more considered implementation of high availability.
  • Real-time position keeping
Not nasty long running batch jobs but a true real-time transactional position keeping capability
to allow the users to see their genuine positions rather than an approximation.
  • Server-side real-time data interfaces
The system needs to perform all calculations on the server-side and implement an MVC pattern rather than having portfolio level calculations implemented on the client-side.  Client-side calculation is a recipe for a system that does not scale, will not provide the same functionality on different devices and which will show different results for different users. Client-side for show, server-side for a Pro.
  • Powerful, configurable compliance engine
We've covered this before in more detail in Buy-side compliance systems: Still 20th Century technology?
  • Portfolio modelling capability
While not strictly part of an order management workflow, the orders have to come from somewhere.  A portfolio management toolkit is therefore needed to provide that source of orders.  This can be a series of screens, a Java API, a COM API, a .net API, a message based API, interface to R/Matlab/SAS or all of the above.
  • Multiple portfolio rebalancing capability 
A refinement of the above.  A portfolio manager should be able to quickly and easily implement a trade idea such as "For every portfolio I look after, sell Stock A and buy Stock B".  For many OMS platforms this simple instruction is highly involved and painful to implement process.
  • True multiple platform capability
A user should be able to perform every function on every device.  Not a half-baked mobile app implementation but a true capability.
  • Multiple asset class capability and workflows
Many buy-side OMS platforms have a legacy of an equity background and cannot handle the nuances of different asset class workflows.  A modern OMS needs to be able to handle workflows such as:
  1. RFS based FI and FX
  2. RFQ based for FI, FX, ETF and Equity
  3. Single orders for Equity and FX
  4. Program trades for Equity
  5. Multiple leg/basket trades for Futures and Options
  6. Single Equity, Futures, Options and FX Algorithmic orders
There will be more workflows over time as the market evolves.  Who knows how the Fixed Income world will change in the next few years?
  • Powerful role based security model
The system must be designed from the ground up such that data is securely held and encrypted where appropriate.  The database should not contain clear text details such as client names, contact details and so on.
  • Zero client-side deployment footprint
No fat client - all running in a web browser implementation. But not your grandfather's browser - use modern technology to create a reactive platform. 
  • Remote hosted, SaaS business model
No lumpy upfront costs - pay per user on a matrix approach per functional area utilised in any month
  • Timestamping using PTP
Accurate timestamps are mandatory. NTP is not accurate enough.
A system that embodied these characteristics would have a powerful competitive advantage in the market...
This is one of a series of posts on this topic -

Comments