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:

RFS based FI and FX
RFQ based for FI, FX, ETF and Equity
Single orders for Equity and FX
Program trades for Equity
Multiple leg/basket trades for Futures and Options
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.