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.

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.

Choosing a network

Selecting an FIX order routing network

A critical component of building an electronic trading infrastructure is choosing an appropriate network model to connect with your trading partners. In today’s market, routing networks, leased lines and the Internet are all are popular options with varied features and benefits to each.

This guide is strictly vendor neutral and consequently general in content. Every vendor has their own value proposition and their offerings tend to be some mix of that described here.

A high level overview of the different network options together with their associated advantages and disadvantages is presented here. Additionally, a section is devoted to aspects of networks that are relevant to any selection exercise such as cost, functionality and service levels. Finally, a set of guidelines for undertaking any selection such as this is included as a conclusion.

Leased Lines

A leased line is simply a direct connection between you and your counterparty via a telecommunications circuit. The connection is available all day, every day at a fixed cost depending on the size of the circuit (56k, 64k, T1, etc.).

Advantages

Leased lines are appealing because they are a private physical connection between trading partners.

Disadvantages

If your firm maintains connections with many trading partners, a dedicated circuit to each can become costly and complex in terms of managing a data center. Additionally, leased lines often take a number of weeks and usually months to have installed.

The Internet

The Internet is a worldwide public network of computers, sustained by a multitude of users all with different business practices in mind. The Internet can provide either a very low-speed connection at little cost or a much higher-speed connection at a greater cost.

Advantages

The Internet is a scalable connectivity solution, and has a significant cost saving derived from its multiple uses. Unlike leased lines, connecting to your trading partners via the Internet does not require dedicated hardware to be ordered for each installation, and is therefore much quicker to get set up. With the largest number of participants of any network, you can generally connect to most anyone you want and the set-up cost is trivial.

Disadvantages

The Internet offers no real form of control. For instance, heavy trading days a few years ago all but collapsed the Internet for a brief time, and the Internet regularly slows down when the US trading day begins. Although relatively cheap to deploy, the opportunity cost of your Internet connection failing can be high.

The Internet is also insecure. It is possible to employ software encryption such as PGP-DES-MD5 or SSL to overcome this, but some firms still believe it is easier to intercept Internet traffic than data sent over a secure private network. For this reason some firms have a policy of not using the Internet for sensitive business traffic. Thus a connectivity solution using the Internet may present problems connecting to all necessary trading partners.

Point-to-Point VPN

In a point-to-point VPN (Virtual Private Network) you have one physical connection into the network but separate logical connections to each of your counterparties.

Typically point-to-point VPN’s take whatever data you send and pass it untouched to the recipient. The network effectively functions as a postal service.

Some VPN’s are private, meaning only data from permissioned users of the VPN operate on the network. Others are public, and your data traverses a shared infrastructure contending for space with a variety of other network types such as voice and video.

Encryption is generally implemented at the router level. Outgoing traffic is encrypted by the router at one end of a connection and decrypted by the router at the other end. This implies a requirement for all parties to have more powerful routers, increasing usage costs and affecting the overall speed of delivery.

Advantages

The main advantage of point-to-point VPN’s is a reduction in complexity and cost of managing many connections. Regardless of the number of connections to trading partners, you only have to manage a single physical line into the network. Adding a new connection is straightforward and only a logical activity. Unless there is a problem with the network as a whole, when one connection fails all your remaining connections are unaffected. Acting as a postal service, point-to-point VPN’s are generally very fast.

Disadvantages

Any trading network is only as good as the trading partners connected to it. If the trading partners you do business with are not connected to the network you choose, that is obviously a big disadvantage. Also, VPN’s that operate over public networks present the risk that your traffic will lose out in priority to other types of traffic. Additionally, if there is a problem with the network or you lose your physical connection into it, you will lose access to all of your trading partners.

Hub-and-Spoke

In the hub and spoke network model, you make one physical and logical connection to the network. All communication between you and your trading partners is passed through a hub where you will generally find a FIX engine.

Your FIX engine sends a FIX message into the hub with information that tells the hub who the recipient should be. The hub receives and parses the message before routing it on to the appropriate destination.

Through this single logical connection you are able to communicate with any other participant on the network with no need to have new logical connections created, install hardware, or undertake the task of FIX certifying your OMS application with your counterparty’s.

The infrastructure of a hub and spoke network allows messages to be operated on and even stored. Depending on the capabilities of the FIX engine in the hub, this can includes functionality such as message validation, symbol translation (e.g. ISIN to SEDOL), protocol translation (e.g. SWIFT to FIX) and archiving of trade information.

An important aspect of a hub is that the underlying physical network can be the Internet, a network owned and run by the hub, or belong to a point-to-point network vendor. Thus a hub can be viewed as consisting of two separate layers. One provides the functionality of the hub (as described above), whilst the second layer provides the underlying network.

Some interoperability is possible, though this is dependant on whether the hub is open or closed. In the scenario where a hub can be reached through more than one VPN, interoperability at the hub level can override a network’s lack of interoperability. In an open hub situation, a firm connected to the hub via “VPN A” can reach a firm connected to the hub via “VPN B”. However, if the hub is closed then this is not possible. The hub only allows participants on the same underlying network to exchange information.

Advantages

The main advantage of a hub and spoke network is that it’s a simple and cost effective means of connecting many trading partners. You manage a single logical connection and can reach any other firm on the network.

Some hub and spoke networks have the notion of FIX certification. Here all participants of the network test their functionality against that of the hub to the point where the participant’s trading application is “FIX certified” against the hub. FIX Testing and Certification is covered in chapter 10 of this guide. The advantage is that once certified, you can trade with any other certified counterparty over the network without additional testing. This saves a great deal of time and money.

Other hub and spoke networks offer syntactical certification as an alternative to functional certification. Here the hub is only concerned with the FIX messages you send and that the way you send them conforms to the FIX specification. It will simply pass FIX messages from sender to receiver. This way you can use the hub to connect to others but not be restricted by the functionality of the hub’s FIX implementation.

In a scenario where a hub uses a point-to-point network for its physical infrastructure interoperability amongst the networks may be possible. However, this depends on permission from the hub.

Disadvantages

In some instances, the functionality available via a FIX hub and spoke network is governed by the capabilities of the FIX engine in the hub. While you and your trading partners may be able to send and receive FIX allocation messages or perform Program Trading via FIX, if the hub doesn’t support that functionality it cannot be used.

An obvious disadvantage is that a single point of failure exists in the network. If the hub fails then all connectivity to your trading partners is lost. Additionally, as it relates to service levels, there can be a latency effect implied by messages passing through a hub that stores or operated on them. The amount of latency varies from network to network but it is something that should be borne in mind in any selection exercise.

The choice of underlying network also defines some of the performance and service levels of the hub. If the performance or service level of the underlying network is poor, the hub will suffer as a result.

One size doesn’t fit all

Any connectivity project should include some consideration of how many counterparties are being targeted and their profile. No doubt there will be large tier brokers on the list and most of the time these will be targeted first. These firms will likely be connected to most networks and have the resources to connect to you, but what about the others? What about counterparties you don’t trade with often, or those that only connect to one or two networks, or don’t have much in the way of resources?

It is not uncommon for firms to use at least two networks. A second network can provide access to additional trading partners, or provide redundancy for disaster recovery or backup purposes. All network types have advantages and disadvantages, and no one type is necessarily better than another. As with most aspects of an implementation, your solution will depend on your goals and objectives.

Costs of FIX networks

There are a number of costs associated with implementing and using a FIX network. They often increase depending on a number of factors including but not limited to the level of redundancy you want, hardware encryption, the number of connections you have and the amount of traffic you send.

Capital costs

Most network vendors charge an installation fee but nothing for the router which generally remains their property. In today’s market it is quite common for a vendor to give you a larger router than you initially need. This means that increases in bandwidth can be accommodated easily. If you want to employ hardware encryption, the router will need to be more powerful and operating costs rise accordingly.

It is common for an ISDN line to be purchased to act as backup, and in many cases also common to have an identical router, providing for two levels of redundancy.

You generally need to purchase a local tail (a very small leased line) to provide connectivity from the networks’ point of presence (PoP) to your building. If your offices are in a financial or commercial center then this cost should be minimal. Costs for this will rise if the PoP is far from your building.

Finally, a person or team of people is needed to manage the installation and running of the network.

Costs for using the connection

There are a variety of pricing models across the vendor community, but they are all predicated on three basic models.

• Per Message
• Bandwidth
• Percentage of Trade Value

You should be aware that it is very common for these cost models only to apply to the broker. Many network vendors use some variation of these cost models as the pricing structure for the broker, but only charge the buy-side a notional flat-fee per connection. This incentivizes buy-sides to connect, but brokers may be reluctant to participate because the cost model of the network chosen is much more expensive than others.

Per message

This model is as its name suggests. You pay a fee for each message sent over the network. A “message” can be classed as a FIX message, an order, or an executed order, depending on the network. Often this model is banded so that you pay a lower amount the more messages you send. This model is ideal if you generally have low trading volumes.

Bandwidth

In this model you pay monthly for a certain amount of bandwidth. This can be quite cheap as it is feasible to support two or three counterparties trading light volumes over a 64k connection. Some networks support dynamic bandwidth allocation. If you exceed your allotted bandwidth you will be allowed to do so, but will be charged for the next highest bandwidth denomination (i.e. 128k if exceeding 64k).

The bandwidth model is ideal if you are trading with relatively high volumes, or are unsure of future growth potential. It scales easily, therefore you can manage the cost based upon your business.

Percentage of trade value

An additional pricing model is one where network providers register as a broker/dealer. Here the network provider charges the broker a certain number of basis points of the value of the trade with a cap and a collar. For example, $2.50 minimum up to a maximum of $25 per trade. This model has not yet gained traction in Europe.

Opportunity Costs

Opportunity costs arising from a network being unavailable are something that must be also considered. How significant an impact on your business would an outage be? Would you be able to notify your counterparties quickly enough? Would you have the capacity to take all would-be electronic orders via the phone? Would you lose money? How much?

Working on what the opportunity cost might be is somewhat difficult and factoring this into a selection exercise even harder. A good approach would be to compare networks on their published availability and how quickly they undertake to resolve any problem. Does the vendor you are considering have an SLA and what are its components? Another source of information would be any anecdotal evidence in the market, such as client testimonials.

Summary

The right choice of network is crucial to a successful electronic trading operation. Community is probably the most important aspect of a network. You can select the most appropriate network, but if you can’t reach your counterparties it becomes useless. Although getting connected to one network is of most importance, don’t discount connecting to more than one. This may be the only way you can connect to the bulk of your counterparties.

Costs are also paramount. It is recommended that you identify trading volumes and the number of connections you plan on maintaining, and calculate the resulting costs over a number of networks. Service is also an important aspect of the decision regarding networks. Beginning with a reasonable time-to-install and leading on to high availability, SLA’s and support infrastructure, you want to feel comfortable that the vendor won’t let you down.

Redundancy options are also vital. In recent times, quiet markets have created the false illusion that manual trading can be used as a backup when networks fail. As some firms send as much as 70 – 80% of their trades electronically using FIX, this is no longer an option. A backup network connection will be imperative as volumes rise.

Electronic trading can’t begin until you have connectivity in place. There are many aspects involved in network selection and the task should be managed as a project that begins as early as possible.

Choosing a FIX engine

A FIX engine is a piece of software that manages a network connection, creates and parses outgoing and incoming messages, respectively, and recovers if something goes wrong. A FIX engine manages the session and application layers and is the single piece of software you need in order to FIX-enable trading or order management systems.

In the context of a trading system your FIX engine is the interface to the outside world, which, together with a network, connects you to outside world and allows you to trade and exchange related information in a standard fashion. Thus, to FIX-enable an application refers to the integration of a FIX engine and connection to a routing network.

FIX engines and their place in FIX implementations

Implementing FIX has different meanings depending if you are using an off-the-shelf OMS or building your own solution. FIX-enabled OMS come in two flavors. Some vendors select a FIX engine and integrate it into their system. If this is the case selecting a FIX engine has little relevance to you. You get what you are given. Other vendors allow clients to select which FIX engine they should use. In this instance, and for those building their own solutions, this chapter is a must-read.

How do FIX engines differ

All FIX engines do essentially the same thing but differ in three main ways:

1. Capabilities/throughput
2. Technologies used
3. Support and services offered

On the softer side, engines differ by how many firms use them. Popular engines will have been more widely tested against than others, in itself an advantage for new entrants selecting the same engine.

The following data represents an overview of the features you should look at and their meaning.

Decision criteria: Capabilities

Decision criteria: Technologies used

Decision criteria: Support and services offered

But how do you really select a FIX engine?

FIX engines have become, to some extent, a commodity item and with so many engines available there is an implication that consolidation lies ahead.

Identify your performance requirements

Many FIX engines give prominence to the number of messages they can process a second. Being able to process many messages tells you much about an engine but this is sometimes achieved with extremely high performance configurations that may not match what you are planning to use. You need to ask yourself just what level of performance you need. If you regularly undertake statistical arbitrage or heavy list trading then a very powerful engine might be appropriate. Otherwise it is not so relevant.

Further to this, some engines do not store messages, and this is how they achieve a high-speed appearance. Messages stored in a database by the engine gives the ability to restore in the event of a hardware failure.

Baseline requirements

• Support for all FIX versions (at least all common FIX tags)
• Support for financial messaging protocols other than FIX (i.e., CMS)
• Encryption
• Persistence (the ability to log data to a flat file or database)
• A High Availability (HA) option
• Support for other messaging protocols like IBM MQ Series.
• Monitoring tools

Hardware requirements and considerations

Consideration should be given to the different hardware requirements for the FIX engine chosen. Buyers should have an understanding of the infrastructure currently in place at their firm, the current and anticipated trading volumes, and how the engine selected will perform in that environment. Also, understand that any benchmark performance statistics provided by a vendor are dependent not only on the FIX engine software, but the hardware they are running on.

Platform support and codebase

FIX engines tend to run on most all platforms or be specialized to operate under a Microsoft� environment. Finding an engine that runs on your platform is rarely an issue. Better to focus on whether you want an engine that runs as a Java or C++ codebase, implying a consideration between flexibility and performance.

Support for other messaging protocols

Desirable because of any legacy messaging protocols you have, multi-protocol support can be very useful, and this could include support for such messaging protocols as IBM MQ Series, TIBCO Rendezvous or Smart Sockets, interfaces into middle and back office protocols like OASYS or SWIFT, or even lightweight protocols to connect directly to ECNs.

Consideration should also be given to support for other financial messaging protocols (for example, CMS), and what is required in order for the engine to support them.

Pre-built ECN interfaces

Connectivity to ECNs and ATSs has become more important as firms look to other sources of liquidity and lower commissions. Most ECNs and ATSs now have FIX interfaces, but historically these have tended to be flavors of FIX, implying additional development and testing requirements. Some FIX engines have pre-built interfaces to such liquidity sources, saving you time and money. However, these interfaces can change as the ECN/ATS introduces new technologies and trading tools. Careful consideration should be given to how the FIX engine supports these destination specific configurations, and how easily they can be modified.

Pre-built counterparty interfaces

Taking this idea further some FIX engines, recognizing that it is not uncommon for firms to implement slightly different interpretations of FIX, have engaged with many leading counterparties and tested against them. They then provide their FIX engine with pre-built interfaces to these counterparties, the idea being to reduce the time, effort and cost required to go live. Again, understanding the complexities surrounding how the FIX engine builds these interface-specific configurations is important.

Business logic

Less common in FIX engines is business logic within the engine itself. The idea is that you put business logic in the engine rather the application that sits on top of it – and provide a cleaner interface to the application. Uses would include logic to deal with different counterparties, message validation, protocol translation, and version mapping. This is quickly gaining popularity and it is likely more vendors will implement it.

Alerting, monitoring, and automated testing

With an increasing amount of business being transacted using FIX, alerting and monitoring are becoming vital. Increasingly FIX engines are starting to provide tools to monitor FIX connections and alerting functionality beyond that. Some are provided as applications, others as web front-ends, and others as frameworks easily integrated into other monitoring functionality you have in place.

Some vendors also offer testing tools, certification harnesses, and FIX simulators. Some are provided as simple stand alone tools allowing you to test the validity of your FIX implementation. Others allow you to host what you have at their site and permit your counterparties to test against this in an automated fashion.

Sound, automated testing tools significantly reduce your need for initial testing and the associated cost, getting you “to market” far faster. With further testing implied when one party upgrades to a new version or implementation of FIX, these tools can be used many times saving further time and resource.

Cost

Historically FIX engines were very expensive and as FIX has become more mainstream so the price has fallen. Most FIX engines charge on a licensing basis and, although some do not, you are generally charged in a different way, such as through support fees. Although freeware FIX engines exist they are best used for educational purposes or perhaps as a base on which to build your own engine. Unless the FIX engine seems really expensive (and some do still exist) price shouldn’t be a major issue. More important is the ability of the vendor to be flexible around your needs, such as offering the engine on a rental basis or perhaps pay-as-you go support.

Selection checklist

Taking into account the functionality to look for in a FIX engine and some of the more important aspects to examine, the following lists a suggested selection checklist.

• Performance is important but only in so far as the engine does what you need it to do now and in the near future
• Eliminate those engines without the baseline options
• Give bias to those that have proven themselves in the market
• If appropriate, select those with interfaces to liquidity venues you need or might need
• Give bias to those offering business logic in the engine
• 24×7 support is a must if you operate in more than one time-zone
• Alerting, testing and monitoring save you time and money. Identify engines with some or all of these features
• Prices have fallen but make sure you are comfortable with the price of any engine relative to its peers and that the cost model suits your needs
• With future consolidation almost certain make sure that any vendor looks committed to the space

Testing a FIX implementation

Why trading partners need to test

The FIX Protocol is the global standard for the electronic exchange of trading information, and much of its success can be attributed to its flexibility and openness. While the FPL publishes a specification inclusive of accepted FIX messages, structure, message flows and required versus optional tags, trading applications often behave in different ways depending on the functionality offered and business needs they satisfy. Different trading applications may require a specific tag or value within a message that the FPL has listed as optional or perhaps not defined at all. In addition to the published tags, FIX also reserves a large suite of tags that can be ‘user defined’, providing an additional layer of flexibility and opportunity for customization. This allows varying trading applications and systems to customize and differentiate themselves, offering different functionality for different business purposes. This openness and flexibility means that system compatibility must be ensured via a comprehensive testing process.

Testing compatibility with trading partners before “going live” is a critical step in the connectivity process. Since all products and environments have their own unique features, there are many areas where potential problems can arise. The purpose of testing is to identify and fix these problems before they have a chance to negatively impact something in production.

What to test

Certification is about ensuring that your trading partners’ systems are compatible with yours. The interfaces you’ve chosen (e.g. FIX versions, message types), the way you represent information (e.g. product identifiers, currencies), and the types of transactions you support are all components of this interface and must all be tested thoroughly with each trading partner. Therefore, during the testing process, it is recommended that each possible scenario be tested both on a session and an application level.

While the session level is relatively consistent across implementations within a version of FIX, the application level allows for much flexibility regarding the different types of messages supported as well as the information communicated in them. Because of this testing each scenario a firm has incorporated within their applications is necessary to ensure the highest degree of compatibility.

Testing Scope & Effort

The following give a guide as to the breakdown in resources for each testing cycle.

Sample testing scripts

FIX session level testing is fairly standard in nature within each version. Application testing will depend mostly on the types of trading a firm does and the capabilities of the order entry application. Testing script should be inclusive of all scenarios a firm expects its traders and order entry application(s) to encounter, and inclusive of all expected and required behaviors of a firm’s trading partners. Sample application testing scripts have been included in Appendix A at the end of this section.

The Global Fixed Income Committee has begun the process of creating a suite of test scripts specific to fixed income products. The availability of fixed income scripts will allow application developers to have an industry “certified” standard with which to test their message flow and required/optional tags. The work is results from collaboration between the Technical and the Business Practice Subcommittees. The work will follow the successful method of documenting business practices through extensive industry input and then a template will be given to the Technical Committee to generate scripts.

Buy side and Sell side approach

Buyside and sellside firms that have built their own trading applications should seek to test and certify with all of their trading partners. It is recommended that each firm establish and document a “Rules of Engagement” guide with regard to FIX implementations. Generally speaking, the buyside and sellside should agree on many different parameters regarding their interface, including but not limited to:

• Network connectivity and support
• Infrastructure (e.g., internal LAN, Citrix, Desktop setup) and compatibility with other applications (Bloomberg, Reuters, etc.)
• FIX version
• Client vs. Server relationship
• FIX header message information
• All FIX message types supported
• All required tags within each FIX message type and status.
• While the FIX Protocol defines required versus optional tags within each message, different firm’s applications often require tags that the FPL did not require.

Vendor approach

One of the main selling points for vendor-based FIX solutions is that the client who purchases the vendor application can reap the benefits of previous testing and certification between the vendor and various trading partners. While buy side and sell side firms seek to test and certify their applications with their respective trading partners, vendor systems generally seek to test and certify with as large a number of trading partners as possible. While client demand will ultimately drive the priority of who tests and when, it is in the vendor’s best interest to offer “off the shelf” connectivity to as many pools of liquidity as possible. This will drastically reduce the amount of time it takes the buyer of such a system to begin trading with their trading partners if they have already certified with the vendor in question.

With regard to FIX testing and certification, there are generally two approaches vendors can take also. They can either maintain all update capabilities to the software themselves, or allow the client to make certain changes to the source code. Allowing clients to access source code does provide greater flexibility, but reduces the level of service and support the vendor can provide. Prohibiting access to source code makes it easier to provide better service and support, but the user loses flexibility in terms of changing how the interface behaves. Therefore, depending on the vendor software a firm chooses to purchase, the FIX testing and certification process may be outsourced to the vendor. If the client is allowed access to source code, they would need to be involved in the testing and certification process as well if they choose to make changes to it.

Vendor software is generally designed for either buy side or sell side clients. Depending on this, each vendor tests and certifies with the appropriate trading partners. While buy side and sellside firms that build their own trading software only focus on testing with their specific trading partners, vendors generally seek to certify with as many trading partners as possible.

With regard to the set-up of FIX sessions with trading partners for vendors, there are two basic models followed:

• Service Bureau – The vendor maintains one FIX session with a firm, and manages each client’s order flow via that session, identifying trading partners using the appropriate FIX tags.
• Point-to-Point – The vendor maintains multiple sessions with each firm, establishing one per client or perhaps many. For example, different trading desks or business units within a firm may require/desire separate FIX sessions.

Choosing one of the above methods is a matter of preference. There is nothing that can be communicated via the FIX message using a service bureau set-up that cannot be sent via a point-to-point connection.

Issues with testing/what can go wrong

Historically, testing has been a manual process, where a representative from each firm connects a development system with his/her trading partner’s development system and they run through the various scenarios in each others testing scripts. This approach has generally proven successful if a firm needs to connect with a small number of trading partners and has very limited trading functionality. However, the proliferation of ECNs and ATSs, the increased globalization of the marketplace, as well as more sophisticated trading tools and functionality have created many issues with regards to FIX testing and certification. Testing in the past has required trading partners to schedule a mutually acceptable time for them to test. If a firm has numerous trading partners to test with and limited testing resources, the scheduling process can often get difficult and very busy. Once a date and time are agreed upon, each set of test servers and applications must be functioning in order to test, which is not always the case with development/test/QA systems.

While one of the greatest strengths of the FIX Protocol is its flexibility, it does allow for different interpretations and implementations (discussed in the first section regarding ‘Why the Need to Test’). This means that one or both of the trading partners will inevitably have to make changes to their engine and/or application during the testing process in order to certify. In some instances these are simple changes that can be made during the scheduled testing period, but often they are larger changes that require users to change their code (or in the case of systems they have bought from vendors, contact their vendor to make the changes). In this case, testing must be stopped and re-scheduled for a later date. Depending on the scale of the change(s), this can add significant length to the testing process.

The aforementioned scenarios address efficiency issues associated with the testing process. There are also potential issues surrounding the quality and effectiveness of testing. Test/development/QA machines often lose access to log files over time, which makes troubleshooting problems extremely difficult, especially if there are long gaps of time in between testing sessions. Adding to the frustration level is the quality of the tests performed. When dealing with manual processes, human error is always a concern. Ensuring that instructions regarding a system’s behavior, and that all testing scenarios have been successfully completed accurately is paramount and difficult to guarantee.

Automated Testing

Certification is about ensuring that your trading partners systems are compatible with yours. The interfaces you’ve chosen (e.g. FIX versions, message types), the way to represent information (e.g. product identifiers, currencies), and the types of transactions you support are all components of this interface and must all be tested thoroughly with each trading partner.

With appropriate technology, certification can be automated. This creates a couple of advantages. First, automating tests ensures that nothing gets missed during the certification process. Not only does it make sure that every scenario a firm requires its trading partners to test is completed, but it also makes certain that the components of the FIX message are in accordance with the design of a firm’s system. Additionally, by logging the results of each test, it creates transparency with regards to the structure of the FIX messages and helps identify areas where a firm may be struggling against your system’s implementation. Second, automates testing means that people are no longer required to manually participate in every single test session. This creates much greater flexibility in terms of scheduling and systems availability, and allows many trading partners to test simultaneously.

Automated certification requires a technology platform that is flexible enough to simulate any conceivable scenario that might be necessary in your environment.

Questions to ask during and after testing

1. Do I have the best combination of information to ensure a maximum of successful trade messages (i.e. adding in Tag 15:Currency, Tag 100:Exchange destination)
2. Symbology database: “is it clean & up to date?”
3. Standardization: where is the industry moving to with symbology?
   • RIC’s are most intuitive symbology but intellectual property of Reuters
   • ISIN’s are most widely accepted (outside of the US)
   • No real consensus at present but a very important issue going forward.

How can you argue for sufficient testing resources?

Business Drivers – Maximize ROI by:

1. Making sure the implementation is effective and efficient the first time will reduce the probability of having to do it again in the future. This greatly reduces operational as well as opportunity costs.
2. Reducing processing errors from the front office trade capture through to allocation & settlement errors (better DMA capabilities).
3. Effective and efficient testing methods will increase access to more trading partners in a shorter amount of time, helping to grow the business.

Technology Drivers – Implement best practices to:

1. Compress delivery cycles & do it right the first time!
2. Adhere to budgetary constraints.
3. Reduce potential processing errors.

Summary of Key points

1. Plan, document, and gain the resources you need to run an effective test program.
2. Identify the areas that need testing, then develop the scenarios and scripts to exercise them.
3. Implement the FIX solution that best matches your firms and your OMS’s capabilities.

Training

How to approach the task of training users

• Understand who your audience and its IT abilities; develop the course around that.
• You may need to deliver different types of training, i.e., groups versus one-on-one.
• Always follow up with each user after the training session as not everyone likes to ask questions during the training session.
• Insure all training material is to the point and make sure any screen shots reflect the version and screens that the user will use.
• Try to have some understanding of the user’s role. In particular use examples that reflect his day-to-day business activities.

Going live – the do’s and don’ts

• Do ensure that all your test scripts have been performed and the results have been checked. If this is not possible due to time constraints write a risk log and get business signoff.
• It is best to have the business user do the testing and sign off.
• Do ensure you have changed the COMP ID to your LIVE ID especially if your test box becomes your LIVE environment. This is a regular problem especially for the first connection.
• Try a connectivity test prior to your Go LIVE day. This will give you time to fix any firewall problems. As these usually fall under change control policies, it is best to tie into those timeframes. Failing this you could see significant delays.
• If in doubt do a regression test. Don’t leave it for the Go LIVE day.
• Do test end-to-end (i.e. front to back office to front again) and check your data.
• If possible try creating a user test machine that replicates a dealer desktop and perform your user acceptance testing. This way should the application have compatibility issues with another application that is already installed this will be highlighted.
• It is best to do a fail over test of your network connection prior to Go LIVE.
• Discuss having a parallel LIVE with your business user, this will give you time to correct any flaws. You could start by sending small volume of trades for one week. However, it is advisable that the dealer keep a record of his trades should you experience problems with the system. Do check each trade with back office and follow it through to settlement. Just because it looks OK in your trading system does not mean it will look OK when it hits the back office. Compliance may want to see these checks and spot-check them.
• Don’t leave things to the last minute.

Go LIVE Day

• Organize emergency conference call numbers for the duration of your Go LIVE plan. Should there be a problem then you can get the correct people discussing the issues immediately.
• Hold a kickoff meeting with both buy and sell side key people and if necessary your network provider.
• Always end the day with a conference call of key people and write minutes of what has been achieved against the plan. Assign actions and agree completion dates if required.
• Write a checklist of all the actions to be completed on Go LIVE day and ensure this is distributed to your team and counterparties.
• Have relevant IT people on call. A common area of trouble on “Go Live” day is firewall configurations.

Fixed income external systems

About electronic trading platforms

• Many fixed income security types can now be traded on electronic trading platforms, from the most liquid government securities through to less liquid credit products.
• Many of the largest dealers, buy side institutions, and retail broker dealers are actively trading on these platforms.
• Increasingly these platforms are using FIX to enhance the services that they provide to their dealer and institutional investor clients.

Going beyond trade execution

• A number of these platforms have evolved their services to include broader STP solutions for the bond markets. These services may include not only trades executed over the platforms but also trades done by phone.
• The FIX connectivity that the platforms offer can be leveraged across these services for the benefit of investors, dealers, and custodians.
• This connectivity enables investors and dealers to easily and cost-effectively automate each step of the investment cycle.

Using FIX with electronic trading platforms

• By embracing the FIX Protocol, these platforms have allowed a growing number of investors and dealers to link in-house OMS systems for the exchange of both pre-trade and post-trade messages.
• These links enable industry participants to eliminate the re-keying of data between systems, lowering error rates and increasing the efficiency of the process.
• FIX interfaces can provide well-defined and standardized access to inventory management, order routing, and trade confirmation services.
• The use of the FIX Protocol enables trading participants to leverage their existing technology investments and expertise.
• Some of the specific uses of FIX connectivity with the electronic trading platforms are detailed below.

  • Real-Time Inventory Management

    IOI, NewOrder, and Quote messages can be used to update inventory for institutions using the electronic trading platforms.

  • Order Routing

    Customers can send orders to the platforms using the FIX NewOrder message.

  • Notices of Execution

    Customers can receive FIX ExecutionReport messages notifying them of trade executions which can update participant systems in real time.

  • Allocations

    Investors can send allocation instructions to dealers using the FIX Allocation message. Investors can receive back FIX Allocation messages containing net money calculations.

  • Confirmations

    Customers can receive FIX Confirmation messages as individual allocations are reviewed and confirmed by dealers.

Connecting to an electronic trading platform using FIX

These are the typical steps required to integrate to an electronic trading platform via FIX:

• Request a copy of the FIX interface document from the platform.
• Identify, build, or procure a FIX engine to implement the Protocol and to serve as the bridge to your OMS application.
• Enhance your OMS application to exchange the component messages with the platform.
• Exchange network data with the platform in order to configure firewalls and session identities in both environments.
• Bring up the FIX session and start testing.
• Following successful testing, move your applications into production.

Fixed income dealer systems

Vision

The sell-side of fixed income community has invested considerable time meeting with clients and considering strategic position in the arena of direct client connectivity for fixed income orders, trade execution, and post trade reporting. As part of this assessment, the community has identified an opportunity in the availability and functionality offered to clients in functional areas such as order management, price transparency, and efficient processing of tickets through direct connectivity via FIX Protocol. As such, the challenge of connecting directly to clients becomes more significant.

The opportunity is to provide desktop transparency both internally and to clients for offerings (multi-channel), order entry, order tracking, trade tracking, trade history, and reporting, as well as to improve the efficiencies of our current trade processing by providing real-time order tracking, easy order entry, and allocations, all in one desktop solution. The goal is to provide quality information to the client desktop as the e-component of fixed income trading becomes more significant. Connectivity allows sales personal to know if a client has submitted an order electronically, if a client has executed a trade electronically, and what levels are being distributed to the offering channel that a particular client is viewing (web based, direct, B2B, etc). Dealer systems provide real-time status of an order, direct connectivity to downstream systems for submission of allocations, and tracking of trade status from execution to settlement.

Product perspective

Single dealer systems can be a desktop application for debt-securities personnel, offering improved access to trader and operations data that is directly related to covered clients. They will provide views of offerings, track orders and trades, and provide order entry features. Single dealer solutions must be geared toward a multi-product, scaleable platform whereby other products would be accessible (other fixed income products on multiple trading systems in multiple back office and settlement systems). As such, these solutions need to be integrated into the debt technology architecture across several systems.

Key business processes

At a high level, single dealer systems would be used by institutional and middle markets debt sales people in three stages of the trade life cycle: Pre-Trade, Execution and Post-Trade. The functions would include:

• View offerings to various channels
• Enter orders
• Track orders, including status and notification of Fill or Reject by trader
• Track trades from execution to settlement
• Allocations
• Reporting (trades, orders, etc by client or by date)
• Query trade history for clients covered

Product features

Single dealer systems will provide a rich variety of productivity functions to fixed income personnel. Among these functions are:

Monitor/Blotter – contains list of securities that currently have open orders placed by either a trader or a client and displays best bid and offer for each.

Offerings – deliver both bid and ask prices to each specified ‘channel’ of distribution. Offering levels may be specified at a security specific level or applied for an entire channel.

Order Entry & Routing – the routing supported by fixed income would send the order directly to either a trading desk or even a specific named trader.

Allocation and Confirmation – Middle office client allocations system providing full management for the Electronic Trade Confirmation (ETC) business cycle for block and allocation level clients and full process support for manual allocation clients including FAX. Monitor cancels and corrects.

Notification/Alert Monitor – displays a list of notifications pertinent to the clients covered by that salesperson. Notifications are given for trade fills, open trade, counter-orders, no-interest responses from trader, order cancellations, news events; credit upgrades/downgrades, as well as recommendations.

Reporting – generate customizable and flexible reports on historical trade database available to fixed income personnel.

Compliance Monitor – ability for Compliance to review all bids, offers, trade executions, bids wanted, and orders. Reporting to regulatory authority including MSRB, NASD, FIPS, ACTS etc.

Rules of engagement

Many firms with larger FIX implementations have chosen to support their counter parties by supplying them with rules of engagement documents. This section describes the most common elements of an engagement document. Generally, these documents represent a supplement to the official FIX specification as published on the FPL website. Or you may wish to in include these rules in your standard business terms that can be updated yearly.

Session level and connectivity rules

Network Options

This section usually describes the supported networks and vendors. For example, specifics regarding recommendations for particular vendors would appear here. Additionally, mention might be made of special handling of certain providers, the non-support of Internet based connections, required hardware encryption methods, and the like.

FIX Versions

It is important that at the outset of the document the firm describe their support for varying versions of the FIX Protocol. Most firms support at least FIX 4.0, some support more than just this one version. Any differences between message types, or support for a certain message type only starting with a specific version of the Protocol, will be dealt with later in the document.

Encryption Support

This section may contain information about the encryption requirements stipulated by the firm. For example, a firm might require any Internet based connectivity to be encrypted using a specific implementation, such as PGP-DES-MD5 as described in the FIX Protocol specifications. In addition, a firm would list any supported or unsupported encryption mechanisms.

Duplicate and Resend Message handling

While the FIX specification is detailed in describing required handling of potential duplicate information, some firms choose to implement additional safety checks to protect themselves and the client they connect with. This section is the place to detail any such implementation.

For example, firm SELL will know, and assume the counter party knows, that tags 43 and 97 can indicate potentially duplicate information, either contained within a message with the same sequence number, or in a message with a new sequence number. The rules in processing these messages are detailed and mostly clear, however, firm SELL might decide to improve on the session level handling of duplicates, and institute a rule as follows:

If a message is received from counter party BUY today that shows the following identical fields it will be considered a duplicate, and will be excluded from further processing: Symbol (55), Side (54), and ClOrdID (11).

This rule would be implemented one level above the session layer, and serves as an additional safe guard against duplicate information.

Start of Day / End of Day Procedures

In many cases, a publisher of a rules of engagement document will describe here the ways a FIX session will be started and terminated. Information reflecting the roles and responsibilities of each counter party to the connection can be found here.

For example, a firm might decide to initiate all connections, and not accept any incoming requests for a TCP socket. Additionally, a schedule will be defined here outlining the minimum down time of the firm’s infrastructure to accommodate the roll-over of sequence numbers. Some firms allow End of Day (EOD) to run at any time during the day.

Counter Party Identification

Every party to a FIX connection generally has their own way of identifying originator and destination for each connection. In this section, you are likely to find information about the preferred way of identification, such as values for SenderCompID (49), SenderSubID (50), TargetCompID (56), TargetSubID (57), and any OBO (on-behalf-of) ID values required or supported.

Failover Procedures

Many firms operate two or more production machines for FIX connectivity. In some cases, network equipment is installed that make the number of machines at the counter party transparent to the other side in that a virtual IP address exists to which connection request are issued or from where they originate.

Usually, when a machine handling a FIX connection fails, the connection will drop. While a brief interruption of service may result, generally all it takes to get back to normal operating conditions is to reconnect, and sync up sequence numbers (resend any messages generated but not received previously).

It helps if this section contains any procedures to follow in case of a failure of hardware or telecom equipment describing the above processes in as much detail as possible.

Definition of Security ID Conventions

For any trading system, the correct identification of securities in a FIX message is of utmost importance. There are several fields within each FIX message, incoming or outgoing, that allow for identification of securities. A rules of engagement document should specify which symbology is preferred, and, if more than one is supported, which conventions are acceptable.

For example, Symbol (55) might be required in the implementation, but the last word in identity and validation of the security might be performed based on the combination of SecurityID (48) and IDSource (22) to avoid problems with mistyped symbols. Additionally, some other fields might be accepted in an incoming message, but remain unused for validation or identification purposes.

Additionally, there are cases in international symbology where an ID number describes a security listed in more than one location (for example, ISIN numbers are not exchange specific. Rules governing the handling of such cases should be outlined in this section as well.

Lastly, not all ID sources might be accepted or understood by the party, so it is a good idea to list the acceptable forms of SecurityID (48) here as well.

Business message types

It is not always practical or desirable for a counter party to support or even accept all FIX message types. For example, a sell side firm might not accept list orders, but single orders only. This section contains the “meat” of the rules of engagement as it describes the messages supported, any modifications or customizations desired to properly process the message, and the like. A possible list of business message types detailed in a rules of engagement (from a sell side perspective) could include the following items:

• Indications of Interest (out)
• Single Orders (in)
• Day Orders (in)
• Multi-Day Orders (in)
• List Orders (in)
• Day Orders (in)
• Multi-Day Orders (in)
• Order Modify Requests (in)
• Order Cancel Requests (in)
• Order Cancel Rejects (out)
• Don’t Know Trade (in)
• Order Status Requests (in)
• Report Busts and Corrections (out)
• Allocations (in)
• Allocation Acks (out)

In addition to the business message types accepted this section could include any conventions for single fields within the business messages, such as the use of the following:

• Account (1)
• HandlInst (21)
• OrdType (40)
• Price (44)
• Text (58)
• TimeInForce (59)

For example, some firms require a certain value to be contained in the Account (1) field for every message received, others only support certain order types (40), and some firms may not accept multi-day orders. This is the area of the rules of engagement to list any requirements of for specific field values.

Test scripts

In order to ensure safe and continuous operation of any system, particularly mission critical transaction handling components, testing is highly recommended. At the time of this writing, no formal standard for certification of FIX engine technology and abilities exists; however, many firms have created specific testing scripts to be executed by a newly connected counter party. This is the section to describe the test bed environment along with any specifics that would help quickly implement the testing effort. The current version of the FIX Protocol (4.4) contains an extensive amount of material that describes the standardized changes in order state for a number of scenarios, along with expected behaviors for session level state changes. These parts of the official specification should form the basis upon which any testing procedures are built.

Examples and Glossary

A really well executed rules of engagement document contains sample message sets that can be used for testing, or that describe in more detail the instructions given earlier. For many implementers, seeing the actual message shortens the learning cycle tremendously. Another good idea is a short but precise guide to language used in the document. For example, some people might understand “Cancel/Replace;” others might mean “Modification,” with the ensuing consequences in changing order id and other parameters in a message.

The FIX process for fixed income

Introduction

This section and the enhancements to the Protocol have been the result of the joint effort between The Bond Market Association and FPL’s Global Fixed Income Committee. This section summarizes how FIX messages can be used to support fixed income trading activities for the following fixed income asset classes:

• US Treasury Bonds
• US Corporate Bonds
• Municipal Securities
• Agency Securities
• To-Be-Announced (TBA) Mortgage Backed Securities
• Euro Sovereign Bonds
• Euro Corporate Bonds
• US and European Commercial Paper

The usage models are described as between two counterparties, an Initiator and a Respondent.

Note that this section should be used as a starting point and serves merely to provide guidance in the reader’s FIX implementation. Full details can be found in the FIX Protocol Specification Documents.

Message Dialog

In fixed income the trading dialog typically starts in one of two ways:

• One party sending out offerings to their clients and their clients responding to the offerings.
• An interested party initiating an inquiry or a bid/offer request. Once the dialog is initiated a trade could be consummated. The allocation of the trade could be conducted “pre-trade” or “post-trade” directly with the trading counterparty.

The diagrams below attempt to illustrate the various dialogs that can happen to facilitate a FI trade and the message flows to use depending on the initiation point of the dialog.

Note that the diagrams will also show, via the green colored circles, the next step in the message dialog and do not show error conditions (i.e. one party receiving an unknown CUSIP) that can occur during the dialog.

Indication of Interest (Offerings)

Offerings are communicated using the Indication of Interest (IOI) message type. The recipient of the offerings can elect to ignore the IOI messages or respond to specific IOI messages via the use the Quote Response message type.

Offerings can be sent by the Respondent to an Initiator on a continuous basis as long as the Initiator wants to receive them. The Initiator has the option to ignore the messages sent by not responding or to respond to an offering of interest by sending a Quote Response message back to the Respondent to either “hit” or “lift” the offering. Figure 1 below illustrates the message flow. The Respondent will pickup on the message dialog flow at “B” in the Negotiated Trade diagram (see next section).

Figure 1: Indication of Interest/Offerings

Negotiated Trade /Inquiry/Bid or Offer Request

A negotiated trade dialog can be initiated not only via the offerings or IOIs as indicated above, but also via a “my bid or offer”, an inquiry/bid or offer request, both using a Quote Request message type. The difference between a “my bid/offer” message and an inquiry/bid or offer request message is that in a “my bid/offer” the Initiator sends a Quote Request message with a “my bid/offer” price set for the security in question. The Respondent would respond with a Quote message. The rest of the dialog would follow the dialog described below and it is illustrated in the “My bid/offer” diagram below.

An inquiry, bid or offer request/wanted begins with a Quote Request from the Initiator. It is possible for the Respondent to send an unsolicited Quote message to their counterparty to initiate the negotiated trade dialog, however, this arrangement should be bilaterally agreed upon by the counterparties involved.

In the negotiation dialog, the Initiator would send a Quote Request message to the Respondent to inquire about a certain security, inquire for a list of securities that meet certain stipulations and parameters, request a bid or offer or request a quote on a certain security. Should the Respondent choose not to provide a quote a Quote Request Reject can be sent with the appropriate reject reason code set. At this point the current dialog would terminate. Alternatively the Respondent can respond to the Quote Request with a Quote message. The Quote message would provide the pricing levels for the securities requested by the Initiator.

The Initiator will respond to the Quote from the Respondent via the use of the Quote Response message type. The Quote Response message type can be used to end the dialog, “hit/lift” the Quote, or counter the Quote. A “hit/lift” response from the Initiator indicates to the Respondent that the Initiator agrees with the price level and the quantity, and want to complete a trade. On the other hand, if the Initiator responded with a counter offer then the negotiation can continue until one party decides to terminate the dialog or a trade is completed.

To a “hit/lift” or counter message from the Initiator, the Respondent can respond with another “counter” message using the Quote message type, end the negotiation dialog with a Quote Status Report, or give the Initiator an Execution Report message indicating that the trade has been completed. This Execution Report message may or may not include calculations for information such as accrued interest, gross trade amount, etc.

Lastly, if the Initiator deems that there are discrepancies in the Execution Report message received from the Respondent, the Initiator may use the Don’t Know Trade (a.k.a. DK Trade) message type to “reject” the trade information. Resolving the error or discrepancies would be done manually and is currently out of scope for the suggested use of the Protocol.

The diagram, Negotiated Trade, on the following page illustrates this flow with some additional details of what values within certain fields can be used.

Figure 2: My Bid/Offer

Figure 3: Negotiated Trade/Bid or Offer Request

Out-of-Band Negotiated Order

A trade that is negotiated “out-of-band” is a trade negotiated through other means such as verbally on the phone or via an alternate trading system platform. In this dialog it is assumed that the Respondent is able to send the completed trade information electronically using the FIX Protocol. The initiation of the order placed by the Initiator could be through the New Order message type or through other means (i.e. verbally or via an alternate trading system platform) agreed upon between the counterparties.

When an order is placed by the Initiator using the New Order message type the Respondent could either accept the order or reject the other using the Execution Report message type. If the order is rejected the dialog ends. If the order is accepted the negotiation can begin out-of-band or “offline”. When the negotiation is completed and the terms of the trade are agreed upon the Respondent would send the Initiator an Execution Report message to confirm that the trade has been completed. The terms of the trade are reiterated in the Execution Report message.

In the event that the Initiator deems that there are discrepancies in the Execution Report message received from the Respondent, the Initiator may use the Don’t Know Trade (a.k.a. DK Trade) message type to “reject” the trade information. Resolving the error or discrepancies would be done manually and is currently out of scope for the suggested use of the Protocol.

Figure 4: Out-of-Band Negotiated Trade

Allocation Instructions

Allocation instructions can be communicated by the Initiator via three different options:

1. Pre-allocated Order – in this option the Initiator would communicate the allocation instructions within the New Order message when the order is placed with the Respondent.
2. Pre-trade allocation – in this option the Initiator would communicate the allocation instructions to the Respondent in a separate message using the Allocation message. The Allocation message is sent after the order is placed with the Respondent but before the trade is completed by the Respondent.
3. Post-trade allocation – in this option the Initiator would communicate the allocation instructions to the Respondent in a separate message using the Allocation message after the trade has been completed by the Respondent.

For the Initiator options 2 and 3 represents the same message flow. The main difference is when the Allocation message is sent – in option 2 it is sent prior to the trade being completed and in option 3 it is sent after the trade has been completed.

Once the trade is completed and the Respondent is ready to act on the allocation instructions, assuming no errors in the allocation instructions from the Initiator, the message flow for the Respondent is the same regardless of which option is used by the Initiator to communicate those allocation instructions.

Note that these options work for fixed income because of FI’s simple trading practices – there is no concept of “done for day”, one set of allocations is applied to a single order usually filled in a single execution.

In the Pre-allocated Order scenario the Initiator would send a New Order message that includes the allocation information needed by the Respondent to allocate the trade once the trade is completed. Note, however, that if even one account cannot be identified, or the quantity of one allocation instance does not meet minimum quantity/minimum increment rules for the instrument, or the sum of allocated quantities does not equal the block trade quantity, the entire request must be rejected. If erroneous allocations are sent via the New Order message, the entire New Order message is rejected using the Execution Report message with the appropriate reject code.

If the pre-allocated Order is accepted and filled, the Respondent communicates that information to the Initiator using the Execution Report message type, setting all the appropriate status values per standard Protocol usage.

At this point in the message flow the Respondent would begin to allocate the trade according to the allocation instructions already provided in the New Order message and communicating that information back to the Respondent according to the message flow shown in Figure 5, starting with the AllocationReport.

Figure 5: Allocations

In the Pre-trade allocation scenario the Initiator would send the allocation instructions, after placing the order but before the Execution Report message indicated that the trade is completed, to the Respondent using the AllocationInstruction message type. On the other hand, in the Post-trade allocation scenario the Initiator would send the allocation instructions to the Respondent after receiving the Execution Report message indicated that the trade is completed – again using the AllocationInstruction message type.

Before accepting the request the Respondent should determine that all accounts are known, the quantity of each allocation instance meets minimum quantity/minimum increment rules for the instrument and the sum of allocated quantities equals the block trade quantity. If any error is found the Respondent must reject the entire Allocation using the AllocationInstructionAck message with the appropriate reject reason code. In this event, whether the trade that has been completed or is pending completion, the order is a still a live order. A rejection of the AllocationInstruction message does not equate to a reject of the order placed in this case. The Initiator can send a new AllocationInstruction message with the correct instructions and information to the Respondent.

If the Respondent accepts the AllocationInstruction, the message flow would continue as shown in Figure 5 with the Respondent sending the AllocationReport message to communicate the sub-account level calculations for net monies and accrued interest if appropriate. At this stage the Initiator still has the option to reject the validated/calculated allocation message due to differences in calculations of net money, gross amounts, etc., for each of the allocated sub-accounts. Alternatively the Initiator can acknowledge back to the Respondent that the validated/calculated message is accepted. Both the Initiator’s response is communicated via the use of the AllocationReportAck message type.

Figure 6: Confirmation and Affirmation

Figure 6 illustrates the message flow of the confirmation process for each of the allocated account instance (the sub-accounts in the AllocationInstruction message) the Respondent would use once the allocation calculations have been confirmed by the Initiator.

The Confirmation message is an optional message that the Respondent can use to report back, confirms or raise an exception of the booking/confirm status of each of the allocation instances in the trade. When the “confirmed” status is reported to the Initiator it indicates that that piece of the allocated trade is ready to settle. Each Confirmation message will report the details of a single “ticket”, therefore the account names, fees, net money and settlement information are reported using fields designated for single account trades.

Once the “confirmed” is received from the Respondent the Initiator has the final say by sending the ConfirmationAck message with the “affirmed” status. However, should the Initiator disagree with the Respondent’s “confirm” the Initiator can send a reject using the ConfirmationAck message with a status of “rejected” and provide a reason for rejection.

Post Trade Reporting to a Third Party or Virtual Matching Utility (“VMU”)

Figure 7 illustrates the messages needed by the Initiator and the Respondent to send trade notices to a third party or VMU for trade matching.

Figure 7: Post Trade 3rd Party or VMU Trade Reporting

The Allocation Instruction message type is used by the Initiator to report one or more orders and block trades along with associated allocations to a 3rd party or VMU for trade matching.

The Respondent will use the Trade Capture Report, or an Execution Report depending on the 3rd party’s requirements, message type to report trades to a 3rd party. This notice of execution will be for block level trades.

Message Usage Details

This section provides some details for the use of specific fields within messages. These usage guidelines supplement the usage already described in the main volumes of the specification. These usage guidelines discuss requirements for fixed income that are required by the baseline Protocol or make clarifications specific to fixed income usage.

General Usage Rules

1. PriceType field must be present when the following price fields are used in any message: Price, BidPx, OfferPx, MktBidPx, MktOfferPx, MidPx.
2. AvgPx field is usually expressed as “percent of par”. Where it is not, such as in certain Confirmation scenarios, AvgParPx and LastParPx have been added for communicating the percent-of-par price that will drive settlement calculated from the negotiated price.
3. LegPriceType must be present when LegBidPx or LegOfferPx is used in the NoLegs repeating block of any message that contains this repeating block.
4. In all trade and post-trade messages where price information is being communicated, a limit or execution price is always conveyed in Price or LastPx, respectively, with PriceType set appropriately. Depending on market convention for a particular asset class other fields may be used to supplement the quote or execution price such as YieldData component block and/or SpreadOrBenchmark component block. Yield and Spread should communicate only derived information, never the negotiated price.
5. All FIX messages identified for use in FI trading except New Order Single support both single instrument trades “outrights” and trades of two instruments – one to be sold and the other to be bought as a replacement. In the US the latter are often called “swaps”, in other regions they are “switches”, and two-instrument trades involving the sale and purchase of futures contracts with different contract settlement months are called “rolls”. The NoLegs repeating block is used to identify and link the two sides of the trade. LegSwapType can be used instead of LegQty on one side of the trade to instruct the Respondent to calculate the LegQty based on the opposite leg’s quantity. To submit a new order for a swap or roll use New Order Multileg instead of New Order Single.
6. LastPxPar conditionally required in the Execution Report, Allocation, and TradeCaptureReport messages when LastPx is expressed with a PriceType other than “percent of par” (i.e. when LastPx is expressed as “discount” or “yield” PriceType then LastPxPar must be used to express the price in “percent of par” equivalent.)
7. When SettlType is not “regular” then SettlType must to be specified. SettlType “future” requires a value for SettlDate.

Indication Of Interest

An IOI must specify price information by using either one of the sets of price information fields (see General Usage Rule’s section)

Either the IOIQty or the NoLegs repeating block is required. If the NoLegs repeating block is used, put “0” (zero) in the IOIQty field. IOIQty is required and used for offerings of single instruments. The NoLegs repeating block is used for multilegs (swaps/switches/rolls). In fixed incomes use there would only be two legs – a buy leg and a sell leg.

ValidUntilTime is where the IOI sender can specify the “firm time” of the offering.

Quote Request

In this message the Initiator can specify what form the quote should be in by using the QuotePriceType field.

The ClOrdID field has been added to this message allowing the Initiator to assign a ClOrdID when requesting for quotes that are of QuoteType “Tradable” and OrdType of “Limit”.

To submit a “my bid/offer” quote request the Initiator will need to specify QuoteType of “Tradable” and OrdType of “Limit”. Pricing information must be specified using either one of the set of price information fields (see General Usage Rules section)

ValidUntilTime – used by the Initiator to indicate the period of time the resulting Quote must be valid for.

ExpireTime – used by the Initiator to indicate the period of time when this quote request expires

OrderQtyData component block – required when QuoteType is “Tradeable”

Quote Response

Initiator will use the QuoteRespType field to indicate what type of response this is, i.e. “hit/lift”, “counter”, etc.

IOIid is required if the Quote Response is used to respond to an IOI (offering) message, the field would contain the ID of the IOI message.

Fields required when QuoteRespType is “hit/lift” or “counter quote”: OrderQtyData component block, Side, ValidUntilTime, ClOrdID (see paragraph below), and either one of the set of price information fields (see General Usage Rules section).

In the initial use of the “hit/lift” QuoteRespType, the Initiator is required to assign a ClOrdID. This ClOrdID will be reused throughout the negotiation process, including in the “counter”, until the negotiation ends in either a fill or the negotiation dialog is terminated by either party.

In a “counter quote” to a Quote, only a limited set of data elements can change depending on the security type. Price can be expected to change, but also Instrument being quoted can change in some markets as well as Stipulations and ClearingCode within the Parties component block.

In a “counter quote” with a “my price” set, OrdType must be “Limit” and either one of the set of price information fields (see General Usage Rules section).

Quote

Fields required when QuoteType is “counter” or “Tradeable”: OrderQtyData component block, Side, ValidUntilTime, and either one of the set of price information fields (see General Usage Rules section).

New Order – Single

For OrdType only the following enumeration are applicable: 1 (market), 2 (limit), D (previously quoted), E (previously indicated).

For OrdType of “limit” either one of the set of price information fields (see General Usage Rules section) is required.

TradeDate is required and is set by the Initiator.

HandlInst is required by the Protocol but is not a required field for FI. However, for the purposes of being compliant to the Protocol the counterparties should bilaterally agree on the value to use.

New Order – Multileg

TradeOriginationDate is used for municipal new issue market. Specifies the date in which agreement in principal between counterparties, prior to actual TradeDate.

TradeDate is required and is specified by Initiator.

For the Multileg Order, if the following fields are not applicable to all legs of the trade then the NestedParties component block associated with each leg within the NoLegs repeating block will be used: Account, AccountType, NoAllocs repeating block, SettlType, and SettlDate.

Execution Report

This message should always use SettlType “future” with a value for SettlDate. Stipulations component block information must be reiterated and echo back by the Respondent if Initiator had provided information in the Stipulations component block.

For multilegs only use the NoLegs blocks of the Execution Report message for swaps/switches/rolls when OrdStatus is “new”. The partial fill or fill (OrdStatus) Execution Report for each of the legs will be reported separated and execution price for each leg is conveyed in LastPx, AvgPx and LastPxPar, if applicable.

The following fields are required when OrdStatus is “partial”, “filled” or “calculated”: PriceType, Price

The following fields are required when ExecType is “trade” or “trade correct”: LastQty, LastPx, AvgPx, LastPxPar (when conditionally applicable)

The following fields are required when OrdStatus is “filled” or “calculated” AND if NumDaysInterest is populated and not zero: AccruedInterestRate, AccruedInterestAmt

GrossTradeAmt and NetMoney is required when OrdStatus is “filled” or “calculated”.

NumDaysInterest is required where applicable based on security type and when OrdStatus is “filled” or “calculated”.

InterestAtMaturity is required in lieu of AccruedInterestAmt for security types that pay lump-sum at maturity.

Allocation Instruction

PreviouslyReported, ReversalIndicator and MatchType is conditionally required when Initiator is sending the Allocation Instruction message to a 3rd party or VMU.

This message should always use SettlType “future” with a value for SettlDate.

GrossTradeAmt – Initiators are required to send this information when sending Allocation post-trade.

For Financing Trades Use QtyType and ContractMultiplier if necessary to identify how quantities are to be expressed and specify in OrderQty the block cash amount to be allocated and in AllocQty the cash amount to be assigned to each fund.

Allocation Report

Respondents are required to send this information when reporting the Allocation back with calculations.

NetMoney is required from Respondents when reporting the Allocation back with calculations.

NumDaysInterest, AccruedInterestAmt and AccruedInterestRate is required from Respondents when reporting the Allocation back with calculations for security types where this information can be derived or is available.

InterestAtMaturity is required in lieu of AccruedInterestAmt for security types that pay lump-sum at maturity.

AllocNetMoney is required from Respondents when reporting the Allocation back with calculations.

AllocAccruedInterestAmt is required, if the value is not zero, from Respondents when reporting the Allocation back with calculations. AllocAccruedInterestAmt should be calculated and rounded appropriately for each allocation instance. This means that the sum of AllocAccruedInterestAmt will not always match AccruedInterestAmt.

AllocInterestAtMaturity is required, if value is not zero, from Respondents when reporting the Allocation back with calculations. AllocInterestAtMaturity is required in lieu of AllocAccruedInterestAmt for security types that pay lump-sum at maturity. Similar to AccruedInterestAmt, the sum of AllocInterestAtMaturity will not always match InterestAtMaturity.

For Financing Trades use the same quantity rules as given for the Allocation Instruction above.

Trade Capture Report

This message should always use SettlType “future” with a value for SettlDate.

Parties component block is required.

GrossTradeAmt and NetMoney are required.

NumDaysInterest is required where information is applicable.

AccruedInterestRate is required if NumDaysInterest is used and is not zero.

AccruedInterestAmt is required is required for security types that trade with accrued interest.

InterestAtMaturity is required in lieu of AccruedInterestAmt for security types that pay lump-sum at maturity.

Instrument component block

Symbol – use “[N/A]” when there are no applicable symbol. For corporate bonds the symbol or ticker for the company issuing the security can be used in this field.

SecurityID and SecurityIDSource are both required.

SecurityType is required.

Factor is conditionally required when it is not equal to one (1) for MBA, TIPS, ABS.

OrderQtyData component block

OrderQty is to be expressed as par amount.