This site has been put in static mode and is no longer active. You will not be able to login, but public content
will be visible for reference purposes. Please visit our new site at http://www.fixtradingcommunity.org.

Implementation Guide

Contents | Previous | Next | Terms of Use

2. General infrastructure

This chapter discusses the infrastructure which needs to be in place before implementing an electronic trading system utilizing the FIX protocol. A review of the firm's IT infrastructure is useful to insure that it has the capacity to support the order management and FIX systems that are necessary in order to accomplish the stated STP goals. Order management systems are covered in the last section.

Internal network (LAN) and firewalls

If an order management system (OMS) is already in place, it is necessary to review how the business communicates with the outside world. The flow of traffic needs to be understood before networking components such as firewall rules can be applied. The following diagram shows an example of a basic system and data flows.

Basic system and data flows

Desktop

If implementing a new OMS, the firm's current desktops should be reviewed to insure they are sufficient to run the new application and will perform well with it. Any new application should be tested against existing applications. A popular solution in these scenarios is "thin client" as a means of application delivery.

Thin client technology

The term "thin client" computing is a label that has been used for a number of years. It describes a method of providing users access to software applications that are installed on a centralized server environment. Although the thin client architecture in itself does not interact with FIX processes directly, it does provide a potentially-useful method of managing and deploying order management systems, accounting, and other line-of-business applications to the desks of dealers and fund managers.

As a technology, thin client computing will be recognized by many different names, such as server-based computing, Microsoft Terminal Services, and Citrix MetaFrame. The concept, however, is the same. The software application that would normally be installed on a desktop PC is installed on a server, which is located in a managed data center. The users connect to the server and launch the application using a thin client application that is installed on their PC or workstation.

To the users this process of launching the software application is completely transparent. As far as they are concerned, they click on the application icon and the software runs in exactly the same way as it if was installed locally. There are no changes to its look, feel, or functionality.

In reality, all the application processing is occurring on the server in the data center, and what the user is seeing on his desktop monitor are screen updates being passed to it by the server. All inputs from the user's keyboard or mouse are seamlessly sent to the application on the server and are acted upon accordingly.

Writing a 'request for tender'

Provide prospective suppliers with sufficient information so that formal proposals may be submitted that are responsive to your needs. This document is sometimes referred to as a request for tender ("RFT"), request for quote ("RFQ"), or a request for proposal ("RFP"). The following section describes in detail the type of content to consider adding to the RFT.
  • Give an overview of your company. This will help the supplier gain an understanding of your firm's business and size. The more information provided the better equipped the supplier will be when proposing a business solution.
  • Give a detailed scope and objective. Break this down between business and IT needs.
  • Requirements - identify the main requirements for the supplier to consider.
  • Identify the contract term.
  • Request for tender schedule.
  • Evaluation criteria.
  • Response format. All bidders should be encouraged to follow the standardized response format. Otherwise it will be difficult to compare each response.
  • Request information on the company including financials. Other potential information requests can include:
    • Site management structure
    • Training approach
    • Staff profiles
    • Accreditation
    • Subcontracting and partners
    • Competitive advantage
    • Sample documents
    • Proposed solution
    • Testing
    • Disaster recovery
    • Virus management
    • Project management approach
    • Recourse approach

Order Management Systems[1]

If you are in the market for a buy-side order management system ("OMS"), you face one of the most important business decisions you will make. With the right system, your firm will be positioned to reap the full benefits of connectivity and take a decisive step toward straight through processing.

It is important to choose carefully but not allow prudence to turn into vacillation. The cost of "analysis paralysis" can be substantial. OMS technology can translate into productivity gains, better execution, fewer errors and reduced costs. The longer you wait to implement a system, the longer you incur opportunity costs.

In reality, while there are many good OMS packages, no system will satisfy 100 percent of requirements or cover all equities, FX, and fixed income products. It makes more sense to identify a product to meet most needs and close gaps after it's up and running. This isn't to suggest that you rush the selection and review process - only that you time-box it. From beginning to end, the decision-making should be completed in less than six months.

Talk to people who have already purchased and implemented an OMS. You will find the industry takes a "co-operation" approach here, and competitors will be more than willing to discuss lessons they've learned - and the mistakes they've made. Of course, no two buy-side firms are identical, and the product will have to reflect specific objectives, requirements, and organizational structure.

Considerations when buying an OMS System

  1. Bare bones or loaded? The level of functionality you'll need can range from basic to complex. A no-frills OMS--one that can receive orders from asset managers, route slices or the whole order for execution, then allocate and book the trades into downstream systems--may be sufficient. Or, you may need a system that can perform compliance checks, kick-off programs or calculate real-time positions. A user interface should be straightforward and uncluttered by convoluted processes or pop-up windows. The best systems clearly display order events as they occur (instead of polling to refresh) and provide multiple ways to sort and find information.
  2. Build vs. buy. Custom building an OMS can be prohibitively time consuming and expensive. Unless you're a very large firm with highly specialized needs and extensive resources, "buy" is probably the better option. Several high-performing off-the-shelf packages meet basic needs. Beyond that, some vendors excel at compliance, others in portfolio modeling, still others in external connectivity. Beware of vendors claiming to be all things to all people.
  3. Vendors. The vendor relationship is essential in any successful order management system installation. Explore prospective vendors carefully, paying attention to people, clients, sales approaches, market position and financial stability. What levels of customer service and support are they willing--and equipped--to provide? The vendor's approach to working with clients and effectiveness at solving problems will be key to how happy you are with the system.
  4. Price range. You can purchase a no-frills OMS for under $50,000--or shell out millions of dollars for a high-end, global customized system. Considering all costs, a low six-figure yearly expense is typical. If equal alternatives are available, get at least two final bids before making a purchase. Know what your firm can handle--and that where quality is concerned, you get what you pay for.
  5. Technology. Operating systems, server hardware, messaging and development languages are important, along with system design and architecture. The choice of database, disks and hardware all contribute to ongoing system costs and ease of administration. Avoid getting lost in benchmarks and techno-jargon and remember that what it all comes down to is a reliable functionality, speed and ease of use. Be wary of solutions that emphasize "flexible technology" over "out-of-the-box" functionality. Help and support are critical, certainly, but the system should be built on solid technology.
  6. Consider your infrastructure currently available to you and decide if this can support the system you are considering. In some cases you may need to consider Thin Client software so you can reduce the strain on your internal LAN. Or you may want to deliver the software to other offices and control in from one site.
  7. Capacity. When evaluating a system, know how many messages it can it handle, peak and sustained, front to back. Will the system be snappy and responsive, or will it lag as activity increases? Do screens refresh quickly under volume? You'll need to find a balance between getting adequate capacity versus paying extra for high capacity ceilings. Don't let vendors tell you capacity and performance is strictly hardware dependent. Software design will determine how well speed and throughput scale. One formula for estimating your capacity requirements: number of users (traders, operations staff and portfolio managers) times the number of connected brokers, times total orders on a peak day, times 10. So, if you had 10 users, 20 connected brokers and 100 orders on a peak day, your message activity level would be 200,000. For an eight-hour day, that averages out to 417 messages per minute. Plan for growth, and employ a strategy to retest and increase capacity.
  8. Connectivity. How many portfolio managers will use the system? Will it link readily to the accounting system and other internal systems? Integration work can delay delivery, so it is wise to determine timetables for activation, along with the communications mechanisms supported. Real-time data transfer is preferable to batch processing.
  9. Links to internal systems are essential, but don't overlook external connectivity: You can't automatically route small orders without connectivity to fast, reliable broker execution services. Confirm how your system links to custodians, prime brokers, and trade matching services. Done right, connectivity vaults an OMS to the cornerstone of a buy-side firm's capabilities.
  10. Reliability and recoverability. Reliability is essential, but don't confuse it with fault tolerance. When the occasional outage occurs--and it will--how quickly will you be able to get back up and running? What if the broker you sent an order to breaks? Are you able to gain control of the orders for alternative execution? Can you complete an order that was routed and filled by inserting a last execution? Do you have a backup way to book and confirm trades with your custodian? Think through potential breaking points.

Many firms take a weighted average approach, sometimes overweighting asset managers and post-trade operational requirements in selecting a system. Traders are the primary OMS users and their views should have priority. They have the most at stake.

Implementation

Once you've made your decision, understand that deploying a full-blown OMS--adding accounts, training, integration and connecting brokers--can take months, or even years for global enterprises. A small team of technology and trading staff should work together to identify and tackle key issues. You will encounter things you couldn't have anticipated, no matter how carefully you've planned. So build a bit of wiggle room and map realistic phases that solve the biggest issues first with fixed delivery dates.

There are many arguments for installing an OMS, the biggest being to help buy and sell-side traders get better execution with less effort. An OMS enables you to handle more trades in less time--and with fewer errors. In short, it gives you a critical advantage in the marketplace, so decide how to move, and then put the trade on the tape.




1. The section "Order Management Systems" is copyright © 2003 Risk Waters Group. All rights reserved. Used by permission.

Contents | Previous | Next | Terms of Use