Ah – the lure of the OEMS: That single platform combining the speed, workflow, intuitive design and trading tools of an EMS with the all the extensive functionality of an OMS wrapped into one. But is this the front-office equivalent of the fountain of youth? Is it possible to combine these two historically best of breed applications? The sheer number of firms claiming to offer an OEMS would lead you to believe the answer is yes; but there is a distinct absence of definition around OEMS moniker. In the interests of separating the real from the swamp water let’s draw a line in the sand and define the “top 10” things an application must support to call itself an OEMS.
1. Account Level Information: Positional data at an account level, trade history and all the subsequent things that hang off the concept of an account, including the underlying foundation required for numbers 2-5 below.
2. Blocking and Allocations: Central to all OMS’, the ability to block orders from across accounts and then support fair allocation back to those underlying accounts.
3. Compliance: Support for pre- and post-trade compliance rules applied at the account level that support both regulatory rule sets, account specific restrictions and aggregate and firm rules.
4. Broker Restrictions: Critical to directing trades and supporting post-trade allocations, broker restrictions require the notion of an account.
5. Trade History: Key OMS functionality that provides a full audit trail and support for TCA.
6. Liquidity Access: It should go without saying that an OEMS must have access and full support for electronic and global Algo trading. It also needs to support high fill throughput without degrading application response time.
7. Desk Structures: Whether you are supporting global follow-the-sun trading or simply looking to pass your blotter over to a colleague when you head off for that meeting mid-day; desk structures allow you to efficiently pass orders. 8. Rich GUI (look and feel): At the center of many EMS’ roots as day trading applications user adoption and experience must be exceptional. The application has to have that intuitive nature that lends itself to user adoption. It needs to scream “User Guide Not Required”.
9. Easy (Unified) Workflows: The old Burger King slogan “have it your way” seems strangely appropriate. The application has to be built to support flexible workflows that facilitate context specific workflows.
10. New Functionality delivered without Upgrades. Central to the EMS is the concept of new functionality released on a relatively frequent basis and without the need for any IT involvement. Adding new functionality without the need for any upgrades is central to the EMS and has to be included in any OEMS.
The list above is sure to show gradient differences across the nuances of trader needs, but it does reflect the needs of most traders today. And that is at the heart of the dream of the OEMS – putting all of the disparate tools traders use today into one context sensitive application. At the end of the day it will be the “OEMS’s” success in satisfying the needs of the trader that will define it.