The Automation of Order Management
Institutional buy-side access to sell-side brokers has been an ongoing activity since the earliest days of computer systems. In the early 1980s, brokers began putting standalone terminal-based systems on institutions' trading desks to facilitate specific execution requirements. Institutions utilized these automated interfaces to facilitate quantitative portfolio rebalancing and order working capabilities, as well as to accomplish quantitative execution objectives such as volume weighted average price (VWAP) and single order, low quantity executions to streamline processing.
These initial terminal based forays into automating the execution process were characterized by extensive sell-side competition to place proprietary terminal systems in buy-side trading rooms. By the late 80s, it was common to see several computer systems provided by different brokers side-by-side. Sometimes more than one was supplied by the same vendor on behalf of different brokers! Needless to say, this terminal proliferation required significant labor to integrate the disparate systems with front- and back-office processing.
The second wave of buy-side execution systems, in the early 1990s, was the advent of order management systems (OMSs) to address trading requirements in integration with portfolio management systems. As portfolio accounting grew in scope and complexity, separate vendors such as Merrin Financial serviced just the order processing function from the buy-side trading desk. These systems were characterized by their tight integration with portfolio accounting systems and the vendor's willingness to address sell-side specific requirements such as soft-dollar budgeting, compliance, average pricing and account allocation and electronic order delivery to brokers.
While buy-side firms are presented with many more choices-including both standalone and integrated order management systems-the key to making productive purchasing decisions is understanding requirements.
Today, there are many advanced, capable and successful sell-side provided proprietary systems such as the Investment Technology Group QuantEx product used primarily to access the Posit liquidity network as well as some exchange destinations. However institutions have found that taking control of the execution process has benefits in the areas of independent broker access and portfolio system integration.
Sell-Side Access
The interface to the buy-side order routing system is the order management system (OMS). The OMS provides interfaces to the portfolio system and tools to automate the trading function, including order routing system access.
The extent to which the order management system provides access to brokers is a key consideration in an institution's purchasing decision. Other factors that affect the decision include: a variety of destinations accessed-brokers, alternate liquidity sources and exchanges and buy-side trading functions, such as block trading, and the vendor's ability to provide service for a secure, data communication network. Order flow constraints such as soft dollar step outs and wrap commitments must be considered here.
The institution will want to make a defined inquiry into how brokers and destinations are supported. This will include not only the scope-numbers of destinations accessible-but reliability concerns, such as end-to-end handshaking, the definition of order delivery, sharing of order identification keys and timestamps, monitoring and alerting capabilities and service level agreements from brokers.
In the area of sell-side access, a true N-way network, allowing all institutions to access all brokers, is still a long way off. The closest we have initial efforts to integrate buy-side networks with sell-side delivery capabilities. For example, DavNet integrates with Merrin and Thomson for sell-side delivery.
Trading Support
Information flows are another important ingredient in buy/sell-side connectivity. To support trading, brokers work to integrate their information component with automated systems.
One example of this is the electronic delivery of floor looks from exchange floor hand-held terminals to buy-side trading desks as implemented in the DavNet DavLook integration with the New York Stock Exchange Broker Booth Support System. Another example is the routing of indication of interest messages, primarily via the FIX format, from the buy to sell side from an integrated desktop application.
FIX: A Cause or An Effect?
FIX is increasingly becoming the lingua franca of equity trading connectivity. The extent to which the institution needs or wants to become involved in the FIX protocol is questionable-this should be a function of the order management system. It's up to the vendor to implement the FIX interface for the institution and to resolve message content and delivery issues with destinations.
Proprietary Trading Interface
To the extent the institution engages in quantitative trading activities that are not handled by the order management system, the connectivity issues broaden. Here, the proprietary trading system will require integration with broker processing systems. While FIX is an option, the institution must evaluate its willingness to acquire and support a FIX protocol implementation. A higher level application programming interface (API) may offer a more service-oriented approach to trading system integration with order delivery. Coupled with the desire to be broker-neutral and the need to trade non-FIX supported derivatives such as futures and options, a vendor solution like DavNet may be more cost effective than internal support of the basic FIX engine.
Post-Trade Support
The messaging requirements continue into the post-trade function. Many orders are worked during the course of the trading day and then average priced and allocated to specific accounts or funds. Generally speaking, this is a core function of the order management system, which must in turn send messages to broker back-office systems. It is my view that, increasingly, FIX allocation messages are supplanting proprietary solutions such as Thomson's Oasys.
For proprietary trading interfaces, the order routing system should have the ability to feed the order management system with both copies of orders and matched execution reports in real time. For example, DavNet fulfills this requirement by providing copies of orders and reports to client applications across the network with optional format conversion which may include a database interface, such as SQL or ODBC.
While buy-side firms are presented with many more choices today, the institutional firm's objective should be to acquire integrated solutions on a cost effective basis. Initially, the impetus of institutional-to-broker order routing was to fill specific trading requirements, today the activity has migrated to an automation function to control costs and reduce errors-widely known as straight through processing (STP). To succeed, the institutional manager needs to make informed decisions that will typically involve integration of existing portfolio, trade management and post-trade systems with the emerging order routing and connectivity applications.
However, the open systems environment promoted in the move from proprietary broker systems to open order management systems poses new challenges in freely servicing automated destinations as the specific broker from end-to-end no longer controls the service.
Redefine the Service Equation
To the extent with which they fulfill the mainstream requirements, existing system vendors will probably be best able to service their institutional clients on a cost effective, service oriented basis. Where there are specific requirements for trading and information flow not addressed by traditional buy-side system vendors, the institution will start by working with broker-supplied proprietary solutions both to control costs and reduce implementation timeframes.
Finally, where they feel both a need to control the specific technology implementation and broker access component, institutions will develop a deeper involvement with the underlying technologies either through acquiring specific components such as FIX engines directly, or by working with dedicated order routing systems vendors.
Nick Davidge founded Davidge Data Systems in 1982. He is currently the CEO and Chief Technical Officer. Nick has over 17 years of experience in developing and supporting order routing systems and networks. He may be reached at [email protected] or www.davidge.com. Davidge Data Systems Corp. 20 Exchange Place, NY, NY 10005 212 269-0901.
Tweet This