FIX protocol

The Financial Information eXchange (FIX) Protocol is a messaging standard developed specifically for the
real-time electronic exchange of securities transactions. FIX is a public-domain specification owned and
maintained by FIX Protocol, Ltd.

What is FIX?

The Financial Information eXchange ("FIX") Protocol is a series of messaging specifications for the electronic
communication of trade-related messages. It has been developed through the collaboration of banks, broker-
dealers, exchanges, industry utilities and associations, institutional investors, and information technology
providers from around the world. These market participants share a vision of a common, global language for the
automated trading of financial instruments.

FIX is the industry-driven messaging standard that is changing the face of the global financial services sector, as
firms use the protocol to transact in an electronic, transparent, cost efficient and timely manner. FIX is open and
free, but it is not software. Rather, FIX is a specification around which software developers can create
commercial or open-source software, as they see fit. As the market's leading trade-communications protocol,
FIX is integral to many order management and trading systems. Yet, its power is unobtrusive, as users of these
systems can benefit from FIX without knowing the language itself.

Background

Since its inception in 1992 as a bilateral communications framework for equity trading between Fidelity
Investments and Salomon Brothers, FIX has become the de-facto messaging standard for pre-trade and trade
communication globally within the Equity markets, and is now experiencing rapid expansion into the post-trade
space, supporting Straight -Through- Processing (STP) from Indication-of-Interest (IOI) to Allocations and
Confirmations. From this foundation, the protocol is gathering increased momentum, as it continues to expand
across the Foreign Exchange, Fixed Income and Derivative markets.

The significant adoption of FIX within the financial services community was empirically highlighted by the FIX
Global Survey which was conducted by TowerGroup at the end of last year. The results cited that 75% of buy-
side and 80% of sell-side firms interviewed currently use FIX for electronic trading, and that both groups plan to
focus substantial efforts on expanding their FIX usage to over 93%, as well as leveraging FIX across additional
asset classes by 2008. The survey also revealed that FIX is developing a key role within the post trade space, as
over 80% of buy-side firms, and over 95% of sell-side firms surveyed currently support, or plan to support FIX
for allocations.

Further to this, FIX is gaining increased attention within the exchanges community as over three quarters of all
exchanges surveyed supported a FIX interface, with the majority handling over 25% of their total trading
volume via FIX.

Organization

The success of the FIX Protocol is primarily due to the voluntary efforts of its member firms from the buy-side,
sell-side, vendor and exchange communities who work together to help achieve the FIX Protocol Limited (FPL)
mission statement, "To improve the global trading process by defining, managing and promoting an open
protocol for real-time, electronic communication between industry participants, while complementing industry
standards."

Technical and business professionals from the FPL member firms coordinate their activities and organize their
work through a series of committees, subcommittees, and working groups, all overseen by a Global Steering
Committee that aims to ensure consistency of protocol application as it is extended into new markets, asset
classes, and phases of the trade lifecycle. In addition to rigorous engineering and technical efforts undertaken to
ensure the ongoing applicability of the protocol to financial-market systems, the FIX Protocol benefits from an
energetic educational and marketing effort that seeks to keep the specification viable, relevant, and responsive
to the needs of market participants.
Usage

No one knows with certainty how many people use FIX or how much of the global volume of securities
transactions is effected via the FIX Protocol. What is certain is that virtually every major stock exchange and
investment bank uses FIX for electronic trading, as do the world's largest mutual funds and money managers
and thousands of smaller investment firms. Leading futures exchanges offer FIX connections and major bond
dealers either have or are implementing them.

Both "adopters" - users of the FIX Protocol - and vendors of FIX-related technologies use the FPL website to
inform the marketplace of their FIX capabilities and capacities. If you want to know whether your counterparties
offer FIX communications capabilities, just ask them. If you want to learn more about FIX or how to implement
FIX connectivity for your business, send a message to a member of FPL's Global Education & Marketing
Committee, or to the FPL Program Office.

Costs

While the FIX specification is open and free, implementing FIX requires planning, software, and network
services, if not other goods and services. For some organizations, obtaining and maintaining productive FIX
connectivity can be a relatively inexpensive process, measured in a few thousand dollars of start-up expenses
and a few hundred dollars of recurring charges. At the opposite end of the spectrum, creating a large-scale,
continuously-operating FIX network serving tens of thousands of users can easily be a multi-million-dollar
proposition. The best place to start your due diligence is the FIX Implementation Guide. Dozens of top FIX
experts have volunteered their time to create a guide that is useful at the business and technical level.
Investing even an hour reviewing the guide will help you understand the type of planning and resources
required to implement FIX in a way that helps your business.

Implementation Guide

1. Introduction
2. General infrastructure
3. Choosing a network
4. Choosing a FIX engine
5. Testing a FIX implementation
6. Training
7. Fixed income external systems
8. Fixed income dealer systems
9. Rules of engagement
10. The FIX process for fixed income

1. Introduction
This document provides information and resources that explain how to implement and integrate the FIX Protocol
specification for trading applications and interfaces. A brief history of the Protocol is included. Members of the
FIX community have contributed to the development of this document.
Since its first release in 1995, the FIX Protocol has continued to expand to include support for more asset
classes as well as additional steps in the trade lifecycle. The latest version of the Protocol, Version 4.4, has
added detailed support for a wide selection of fixed income instruments, futures and options, and more
comprehensive support of post-trade allocations, among other features.

FIX and the future

Before we can look to the future of FIX Protocol, we should take a quick look back to where, when and how FIX
began.
FIX began as a collaborative process between Fidelity Management & Research and Salomon Brothers equity
trading departments. The firms sought to create an electronic communication protocol to improve order routing
and trade processing between counter-parties and exchanges. The two firms undertook a proof of concept pilot
to prove the feasibility of the effort. Once successfully completed the firms organized a U.S. based FIX
Committee, which contained some of Wall Street's major names. The committee held its first meeting in June of
1994. The committee held monthly meetings with each firm working toward a production version of the
Protocol. In January 1995, FIX version 2.7 was released to the financial community. As interest in the Protocol
gained momentum, the U.S. Committee created a FIX Technical Committee to answer questions, add
information and anticipate changes to the Protocol. From this initial technical committee came the release of FIX
3.0 in September 1995, FIX was off and running.

The early days of the Protocol and most of the implementation efforts focused on equities. In 1996, a European
FIX committee was created to represent the interests of firms in the UK and Europe. In 1998, the Japanese FIX
Committee began. The Protocol expanded to cover, option trading, ECN features and allocation messages. In
late 1999, the FIX organization took steps to extend the Protocol beyond equities.

With the approval of FIX Protocol members, Putnam Investments and Merrill Lynch volunteered to expand the
use of the FIX Protocol to fixed income. The two firms collaborated much like Fidelity and Salomon Brothers did
years earlier. The proof of concept pilot began in December 1999 and the firms worked through Y2K planning.
By March 2000, the firms successfully completed the proof of concept pilot. The proof of concept included
adding four user-defined tags (UDT) to support fixed income. The UDT's included yield, maturity, benchmark
and spread to benchmark. Also, in March 2000, FIX version 4.2 was released and included the four tags to
support fixed income. The success of the proof of concept pilot lead the FIX Protocol organization to create the
Fixed Income Working Group (FIWG). Since 2000, the FIWG has added tags, message formats and attributes to
expand FIX Protocol's ability to support fixed income products. The FIWG is now known as the Global Fixed
Income Committee.

Over the years the financial community has witnessed FIX Protocol grow as a technology and as an
organization. In order to facilitate growth and prepare for the future, FIX Protocol Limited (FPL) entered into
several Statements of Understanding (SoU) with other industry organizations.

The first such SoU occurred in July 2001, with SWIFT. This statement of understanding focused on convergence
between pre-trade and post trade processing in the use of ISO 15022 XML. The organizations and their
members agreed that such convergence would bring straight through processing (STP) closer to realization.

The second SoU occurred in October 2001, with The Bond Market Association, effectively merging the standards
efforts of both organizations. The Bond Market Association represents securities firms and banks that
underwrite, trade and sell debt securities. The Association strives to standardize market practices and
commonly used documentation, both to promote efficiency and to reduce costs in the largest securities
markets, the $17 trillion global debt markets, with three million active issues and as many inactive issues. A
long-standing goal of the BMA is to help modernize the electronic infrastructure of the fixed income markets to
facilitate STP.

The Association published plain English documents that describe current business practices in various fixed
income markets. The purpose of these documents was to serve as a blueprint for the Protocol development
effort to make sure that FIX captures the complex needs of fixed income trading. The FIX Technical
Subcommittee performed a Gap Analysis based on the plain English documents and suggested changes in FIX
message flows and formats that are now incorporated into FIX 4.4.

A complete new set of messages was added to the Protocol based on the plain English document that described
institutional allocations.

These plain English documents provide a very good reference source for explaining the trading process. The
documents are available at the BMA web site:

http://www.sifma.net/story.asp?id=458#topdog1

The Bond Market Association has also strived to educate its membership about FIX and the benefits that the
Protocol offers through seminars and educational events conducted with the help of FIX professionals.
The strong relationship between the two organizations was also demonstrated late in 2002, during a meeting
with U.S. regulators in Washington, D.C. A portion of this meeting was dedicated to a presentation and Q/A
regarding Protocols, standards and STP and their impacts on the financial services community. The BMA's
ongoing communications with regulators in New York, Washington, D.C. and internationally continues to allow
both organizations to maintain a dialogue to educate and update regulators.

The Bond Market Association continues to work with the FIX Protocol Ltd, particularly with the Global Fixed
Income Committee and its subcommittees, in various initiatives, such as the Certification Initiative, to support
the increasing use of a standard electronic trading protocol in the fixed income industry.

In 2002 FIX Protocol Limited (FPL) realized that expansion in Protocol adoption required the organization to
adapt and grow. Therefore, FPL decided to open membership and restructure the organization across industry
asset classes and geographic regions. FPL also decided to search for an Executive Director (ED). This newly
created position helps run the FPL organization and educate the financial community on the use of the Protocol.
The ED, reports directly to the FPL Global Steering Committee.

The future of FIX will continue to satisfy its member's needs and requirements as evidence by increased support
for products such as fixed income, futures, derivatives, and CIVs. FIX will also continue the increased support
for full trade life cycle processes such as allocations, confirmations, and execution reporting. These new
industry-wide initiatives will build upon the recently released FIX 4.4 and include new technology such as XML.
In addition, growing cooperation between FPL, the Bond Market Association, SWIFT and other industry
organizations continues to operability from the front office to the back office.

Audience

The intended audience is users who wish to implement the FIX Protocol. This document has been written for the
buy and sell sides, technology vendors, exchanges, and other interested market participants.

The benefits of FIX

The fixed income community will leverage the experience of OMS providers, system vendors, integrators and
developers who have a deep knowledge of supporting FIX on the equity side of the business.

Reduces reliance on broker and proprietary solutions. By embracing FIX, users leverage open standards
embraced by the BMA and global fixed income communities for multiple security classes.

Flexible protocol that allows you to be responsive to changing customer and market demands.

Benefits to the dealer

Helps to increase efficiency by freeing up valuable time otherwise used to communicate price and execution
data. Allows for greater focus on complex trading issues that require client contact, market color and
commentary.

Helps to reduce costs associated with manual errors in the trade entry, execution, and post trade processes, by
allowing for a more seamless integration of various order management applications and functionality.

Improves dissemination of price information, allowing for more efficient monitoring of market liquidity.

Benefits to the sales trader

Allows traders to continue speaking with dealers via the telephone and email for complex trading issues that
require market color and commentary, but the transmission of information such as side, quantity, issue, price,
etc. is communicated electronically so there is less potential for human error.

Seamless and real-time communication of execution data throughout the day, so the dealer is constantly kept
up-to-date with the status of their order without having to be called several times a day to report on progress.
This enables traders to concentrate more efforts on executing trades, rather than reporting on the status of
orders.
Although electronic, the dealer can still "touch" the order (i.e., cancel, change the nominal, place limit prices
and other instructions against the order) at any time during the day. The sales trader has the ability to "accept"
or "reject" any of these change requests from their order management application.

Benefits to IT

Minimizes business risk by helping to prevent loss, modification or misuse of business critical information
exchanged between organizations.

Improves system scalability by embracing an industry standard protocol, and improves operational efficiency
and control of the investment process through automation.

Reduces the need to support multiple solutions across business units (Fixed Income, Equity, Derivatives, etc.),
which is inefficient and not cost effective.

Benefits for the buy and sell sides

Increase in speed and efficiency of entire trade entry, execution and reporting process, which helps to facilitate
STP and reduce costs associated with manual errors.

Enables seamless connectivity to multiple counter-parties and enhances price transparency and access to
liquidity.

Helps to increase efficiency by freeing up valuable time otherwise used to communicate price and execution
data. Allows for greater focus on complex trading issues that require dealer contact, market color and
communication.

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

Internal network (LAN) and firewalls

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

o Site management structure

o Training approach
o Staff profiles
o Accreditation
o Subcontracting and partners
o Competitive advantage
o Sample documents
o Proposed solution
o Testing
o Disaster recovery
o Virus management
o Project management approach
o 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.
11. 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.

3. 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.
4. 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

• Does the engine support all current FIX versions

• Does it support all tags of each version

Versions supported • Can it support more than one version at once

• What is involved in supporting new versions of FIX?

• Can the engine support fixed income, derivatives, FX etc.

Support for asset classes
other than equities • What is involved in adding support for additional products?

High availability, load • Does the FIX engine support a software-based high availability option
balancing, and scalability for high-volume, many-connection implementations

• How many messages a second can the engine process

Speed and robustness
• What fall-back and redundancy options are available

• Does the engine support common encryption methodologies

Encryption options
• Is SSL supported
 • Each FIX connection tends to be slightly different. Can you embed
Ability to implement per- counterparty specific logic within the engine rather than having to
connection business logic implement from outside within your systems?

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

• Not all FIX engines run on all platforms. Some FIX engines sell
themselves on the basis that they will run on all platforms, others take
Platforms supported the opposite view and market themselves on the basis that they are
optimized to run on one platform only.

• Does the engine restrict your implementation to a specific architecture

Architectural flexibility • Are you forced to use a database for persistence or a particular type of
middleware for example

• FIX engines supplied as class libraries (APIs) offer complete flexibility

over your implementation but you have to do the work.
Provided as a set of class
x solution • FIX-in-a-box solutions provide ready-made functionality for many
commonly used activities and seamlessly handle network connectivity.
They are easier to implement but aren't so flexible.

Decision criteria: Support and services offered

Access to source • Some FIX engine vendors make available the source-code so that you can modify
code their product. Typically this is only done for a fee and for the largest clients.

• What level of support is offered and at what times.

Support offered
• Is on-site support available

• How many updates and upgrades does your license entitle you to
Upgrades and
updates • Does the vendor charge a license fee for an engine in a disaster recovery / stand-
by environment

Cost and pricing
options
Monitoring tools
• Is the cost reasonable? Is the vendor flexible around how you would like to pay?
• Does the engine come with tools that allow monitoring of your FIX sessions. A
good error translator can prevent you spending of a great deal of time trying to
find an error message.

But how do you really select a FIX engine?

A current list of FIX engine vendors can be found on the FIX Protocol website. With over a hundred engines
listed any selection process would appear to be non-trivial. 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 th

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

• 24x7 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

5. 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.

Connectivity Testing 10%

FIX testing (session) 10%
FIX/OMS (front office) 40%
Integration testing, E-2-E 40%
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. See the Fixed Income Section of www.fixprotocol.org
for updates. The Global Fixed Income Committee hopes to publish these scripts in the fourth quarter of 2003.

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

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)

• Symbology database: "is it clean & up to date?"

• 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.

6. Training
How to approach the task of training users

1. Understand who your audience and its IT abilities; develop the course around that.
2. You may need to deliver different types of training, i.e., groups versus one-on-one.
 3. Always follow up with each user after the training session as not everyone likes to ask questions during
the training session.
4. Insure all training material is to the point and make sure any screen shots reflect the version and
screens that the user will use.
5. 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

1. 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.
2. It is best to have the business user do the testing and sign off.
3. 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.
4. 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.
5. If in doubt do a regression test. Don't leave it for the Go LIVE day.
6. Do test end-to-end (i.e. front to back office to front again) and check your data.
7. 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.
8. It is best to do a fail over test of your network connection prior to Go LIVE.
9. 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.
10. Don't leave things to the last minute.

Go LIVE Day

1. 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.
2. Hold a kickoff meeting with both buy and sell side key people and if necessary your network provider.
3. 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.
4. Write a checklist of all the actions to be completed on Go LIVE day and ensure this is distributed to your
team and counterparties.
5. Have relevant IT people on call. A common area of trouble on "Go Live" day is firewall configurations.

7. Fixed income external systems

About electronic trading platforms
 1. 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.
2. Many of the largest dealers, buy side institutions, and retail broker dealers are actively trading on these
platforms.
3. Increasingly these platforms are using FIX to enhance the services that they provide to their dealer and
institutional investor clients.

Going beyond trade execution

1. 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.
2. The FIX connectivity that the platforms offer can be leveraged across these services for the benefit of
investors, dealers, and custodians.
3. This connectivity enables investors and dealers to easily and cost-effectively automate each step of the
investment cycle.

Using FIX with electronic trading platforms

1. 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.
2. These links enable industry participants to eliminate the re-keying of data between systems, lowering
error rates and increasing the efficiency of the process.
3. FIX interfaces can provide well-defined and standardized access to inventory management, order
routing, and trade confirmation services.
4. The use of the FIX Protocol enables trading participants to leverage their existing technology
investments and expertise.
5. 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

1. These are the typical steps required to integrate to an electronic trading platform via FIX:
2. Request a copy of the FIX interface document from the platform.
3. Identify, build, or procure a FIX engine to implement the Protocol and to serve as the bridge to your
OMS application.
4. Enhance your OMS application to exchange the component messages with the platform.
5. Exchange network data with the platform in order to configure firewalls and session identities in both
environments.
6. Bring up the FIX session and start testing.
7. Following successful testing, move your applications into production.

8. 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.

9. 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.
10. 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:

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.
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.

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

PriceType field must be present when the following price fields are used in any message: Price, BidPx, OfferPx,
MktBidPx, MktOfferPx, MidPx.

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.

LegPriceType must be present when LegBidPx or LegOfferPx is used in the NoLegs repeating block of any
message that contains this repeating block.

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.

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.

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.)

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.

FIX Repository

The FIX Repository represents the raw data behind the FIX specification in "database-compatible format". Files
include an XML data dictionary with complete enumeration values, XML message content and XSLT scripts
illustrating how to generate C# header files from the FIX Repository. Also included are XSLT scripts which
generate a FIXimate-like (HTML) data browser for the FIX Repository.

The FIX Repository is available for versions 4.0 and later of the FIX Protocol specification. Note that many parts
of the most recent FIX Protocol specification documents (including Volume 6), the FIXML Schema, and FIXimate
are "generated" from the FIX Repository.

There are a number of parts to the FIX Repository:

• Fields
• Enumerations

• Components

• Messages � special type of component

• Message Contents

• Datatypes (as of FIX 5.0)

For each part there are 4 files:

• *.xml � The data itself

• *.xsd � The schema for the data

• *.xsl � A transform to display the data in IE

• *.htm � A page to invoke the transform and display the data in IE

Access to the FIX Protocol specification in a raw form that can reliably be accessed programmatically is
considered very valuable. FPL provides free access to the FIX Repository for all registered users of the website.
The FIX Repository is available in two versions: an Evaluation Version and the Full Version. Both versions
have the same structure and data formats, the only difference is that the Evaluation Version is restricted to
contain only the data used in the IOI and Advertisement messages. Thus an application developed to use the
FIX Repository can be developed and tested against the Evaluation Version.

The FIX Repository is subject to FPL Copyright and Database Intellectual Property rights.

FIX Functionality Matrix

FIX 4.0 FIX 4.1 FIX 4.2 FIX 4.3 FIX 4.4 FIX 5.0
Message Support [Jan [Apr [Mar [Aug [Apr [Oct
1996] 1998] 2000] 2001] 2003] 2006]
Equities
Basic Order flow
IOIs and Advertisements
Quotes
Market Data
 Allocations
Confirms / Affirms
Trade Reporting
Program Trading
Algorithmic Trading
FIX 4.0 FIX 4.1 FIX 4.2 FIX 4.3 FIX 4.4 FIX 5.0
Futures & Options [Jan [Apr [Mar [Aug [Apr [Oct
1996] 1998] 2000] 2001] 2003] 2006]
Basic Order flow
Multi-leg Order flow
IOIs and Advertisements
Quotes
Market Data
Allocations
Confirms / Affirms
Trade Reporting
Security and Position Reporting
Collateral Management (Listed derivatives)
FIX 4.0 FIX 4.1 FIX 4.2 FIX 4.3 FIX 4.4 FIX 5.0
Fixed Income [Jan [Apr [Mar [Aug [Apr [Oct
1996] 1998] 2000] 2001] 2003] 2006]
Basic Order flow
Multi-leg Order flow (Repos, swaps/switches/rolls)
IOIs (offerings)
Quotes
Allocations
Confirms / Affirms
Trade Reporting
Collateral Management
FIX 4.0 FIX 4.1 FIX 4.2 FIX 4.3 FIX 4.4 FIX 5.0
Foreign Exchange [Jan [Apr [Mar [Aug [Apr [Oct
1996] 1998] 2000] 2001] 2003] 2006]
Basic Order Flow (spots and forwards)
Basic Order Flow (swaps)
Quotes (spots, outright forwards, FX swaps)
Market Data (executable streaming prices)
Allocations
Confirms / Affirms
Trade Reporting
FIX 4.0 FIX 4.1 FIX 4.2 FIX 4.3 FIX 4.4 FIX 5.0
General [Jan [Apr [Mar [Aug [Apr [Oct
1996] 1998] 2000] 2001] 2003] 2006]
News
Email
Transport Independence Framework
Regulatory Compliance

Legend No Support Some Support Good Support Not Applicable

Equities Basic Order Flow

 As the original functional core of the FIX Protocol, basic order flow for cash Equities is well supported in all
versions of the protocol discussed here.

Having said that, the protocol continues to evolve in areas such as particular market support (for example: The
STEP 1.0 Extensions provides initial support for the use of FIX in Chinese equities markets.).

Back

Program Trading

There are two distinct ways to handle portfolio order flow over FIX:

• By sending a number of individual (New Order � Single) messages and using some mechanism to group them
in baskets.
• Or, by using List message functionality.

Although List Orders are available in version 4.0 of the protocol, they function in a different manner to later
versions. Version 4.2 of the protocol incorporated a complete re-working of portfolio trading support, with
particular changes to the List Order messages and workflow.

Back

Algorithmic Trading Extension

The Algorithmic Trading Extension provides a more complete and flexible way of specifying and identifying
strategies for order execution.
Back

Collective Investment Vehicles Basic Order flow

FIX messages can be used to support order initiation / confirmation and to issue settlement / Registration
Instructions for open-ended Collective Investment Vehicles (�CIVs�) � known variously as Mutual Funds, Unit
Trusts, Managed Investments. Open Ended Investment Companies (OEICs), Undertaking for Collective
Investment in Transferable Securities (UCITs) etc.

Back

Futures & Options Basic Order flow

Version 4.0 of the FIX Protocol is not suitable for Financial Futures & Options (FF&O) Trading but the other
versions all have varying levels of support for FF&O business.

Support for FF&O trading in version 4.1 of the protocol is rudimentary. Version 4.2 of the protocol builds on the
capabilities provided by 4.1, introducing additional fields that make support for give-up trades easier.

FIX 4.3 introduces further additional fields specifically to support FF&O, with specific improvements in the areas
of multi-leg instrument support and security identification.

Version 4.4 of the protocol includes specific actions to bring FIX in line with the standards of the Futures
industry committee and incorporates work done by the FIX Derivatives working group. It provides the most
complete implementation of the protocol yet by providing support for listed derivatives clearing from trade
reporting and allocations through positions maintenance and reporting.

FIX 5.0 contains a listed derivatives party role extension which provides additional party roles for carrying
session-level identifier in the parties block which are useful to clearing firms and other parties receiving trade
reports.
Back

Fixed Income Basic Order Flow

The first major version of the protocol with extensive support for Fixed Income is 4.3. Significant work was
undertaken to bring FIX usage in line with the guidelines established by the Bond Markets Association (BMA).

Workflows for Fixed Income trading are significantly different from those for Equities. However, gap analysis
determined that mappings were possible. For example, Offerings could be supported by the FIX IOI message,
whereas Inquiries and request for tradable Bids or Offers could be handled by the FIX Quote request/response
messages.

What we might call basic order flow, i.e. client sends either a New Order – Single or New Order – Multileg and
receives Notifications of Execution in return is well supported in versions 4.3 of the protocol onwards. The same
can be said for allocations (with both pre- and post-trade methods supported via the standard FIX allocation
fields/message respectively).

Back
Foreign Exchange Basic Order Flow

A standard means of using the protocol for FX instruments was described in FIX 4.2 and has subsequently been
carried forward into later versions.

In FIX 5.0, the FX Phase 1 Extension covers Spot, Forwards, FX Swaps and vanilla FX OTC Spot Options. The
functionality for each of the instruments covers Streaming prices for spots and outright forwards, Quotes for
spots, outright forwards and FX swaps, Orders, Executions and Trade Capture (FX OTC Spot Options only)

Back
Advertisements

Basic Advertisement functionality for cash equities is provided in all versions of the protocol discussed here.
Fields to support Futures & Options are not present until version 4.1 of the protocol. Support for Fixed Income
Advertising is added in version 4.2.

Back

IOIs

As with most other functionality IOI support for cash equity product is strong in all recent protocol versions.
Fields to support Futures & Options are not present until version 4.1. Fixed Income (High Grade and High Yield
Corporate Bond) IOI support was introduced in version 4.2.

Back

Quotes

Quotes can be requested/supplied on specific securities or forex rates. However, Futures & Options and Fixed
Income quotes are not supported until version 4.1. As with most other areas of functionality, Fixed Income
quotes only really receive rudimentary support from version 4.2 of the protocol onwards.

Mass Quoting, to address the needs of listed derivatives markets, was add in FIX 4.2, along with additional
messages for quote management. The concept of a tradable quote was first introduced.

Refinement and definition of indicative quoting, tradable quoting, and restricted tradeable quoting models are
added to FIX 4.3. The suite of quote messages was expanded to support Fixed Income pre-trade negotiation.

Back

Multi-leg Orders
The capability to transmit Multi-leg orders was introduced in version 4.3 of the protocol. Their use is
documented in Volumes 4 and 7 of the specification.

Back

News

Basic News message functionality is available from version 4.0 onwards, although specific fields for Futures &
Options were only added in versions 4.1 and 4.2 respectively.

Back

Email

Email functionality has developed in parallel with that of the News message, with additional fields added for
Futures &Options in 4.1/4.2. Although, due to its largely free-text bases functionality, this message type could
support any product type from version 4.0 onwards, the addition of these product-specific fields in later versions
greatly clarifies usage.

Back

Allocations

Allocations can be performed both pre- or post-trade. Post trade allocations are supported in the form of a
separate FIX message type, whilst pre-trade allocation is achieved by sending allocation details on the order
message itself.

Pre-allocation functionality was not introduced until FIX 4.2. Pre-trade allocation is much more commonplace in
the program trading community than it is in block trading hence the limited support indicated in the matrix.

For the purposes of pre-trade allocation, a repeating group covering account and number of shares was added
to the order message in 4.2.

Cross border allocations support was introduced in version 4.1, as was support for allocating Futures & Options
trades. Support for Fixed Income was introduced from version 4.3 of the protocol onwards.

FIX 4.4 saw the introduction of a common allocation model across multiple asset classes for both cash and listed
derivatives instruments. This work is on-going driven by the FIX Allocation Working Group and the FIA
Extensions for Clearing Working Group.

In FIX 5.0, the Allocations for Options Extension provides the ability to represent the open or close disposition of
a trade or position on both the give-up and carry firm side of the allocation.

Back

Confirmations / Affirmations

The capability to transmit Confirmations and Affirmations was introduced in version 4.4 of the protocol. Their
use is documented in Volumes 5 and 7 of the specification.

Back

Market Data

The capability to transmit market data via FIX was introduced in version 4.2 of the protocol. In FIX 5.0, the
Market Data Optimization Extension introduces changes to support book management best practices. The
market data specification has also been broadened to support a wider array of business practices and processes
in new markets. Changes to support Trading Session Status Reporting and Trading Timetables have also been
introduced. Finally, changes have been made to support Foreign Exchange requirements for streaming prices.
Back

Settlement Instructions

Used to transmit Investor�s payment details to the fund manager where the Intermediary does not settle
trades.

Back

Registration Instructions and Response

Used to transmit Investors� registration details to the Fund manager, allow compliance checks and opening of
the correct type of account.

Back

Trade Reporting

Two additional messages have been added in FIX 4.4 allowing sell-side firms provide details of completed trades
to an external entity not involved in execution of the trade. Further details of these two message types (Trade
Capture Report request and Trade Capture Report) can be found in Volume 5 of the FIX 4.4 specification. Trade
Reporting was further extended for use in reporting between clearing houses and clearing firms.

In FIX 5.0, the Trade Capture Reporting process has been substantially elaborated and now provides a detailed
accounting of a number of different trade reporting models that are common in the equities and listed
derivatives industry.

Back

Collateral Management

Five new messages types (Collateral Request, Collateral Assignment, Collateral Response, Collateral Report, and
Collateral Inquiry) were introduced in FIX 4.4 to comprehensively support 2-party and 3-party repo and, to an
extent, securities lending collateral management. Details of these message types and its usage can be found in
Volume 5 and the Fixed Income section of Volume 7 of the FIX 4.4 specification.

In FIX 5.0, the Collateral Reporting Extension provides support for a risk-based margining model as used in the
listed derivatives industry. The enhanced model allows collateral to be deposited at the clearing house in order
to satisfy clearing margin requirements.

Back

Security and Position Reporting

Five new messages types (Position Maintenance Request, Position Maintenance Report, Request For Position,
Position Report, and Assignment Report) were introduced in FIX 4.4 to comprehensively support listed
derivatives clearing and are their usage can be found in Volumes 5 and 7 of the FIX 4.4 specification.

In FIX 5.0, reporting of corporate actions and the need to adjust impacted positions and securities are
addressed in this extension. Additionally, multiple new messages for Security and Position Reporting have been
added in this extension.

Back

Transport Independence and Application Versioning

The Transport Independence Framework separates the FIX session layer from the application layer. This enables
firms to utilise the business functionality provided by later versions of the protocol with their existing
implementations. This significantly reduces the financial investment required to develop new releases while
 allowing FIX to be used by a wider audience, from the most demanding low latency users to those requiring
massive scalability. Additionally the Transport Independence framework will allow FIX application messages to
be carried over other session transports such as web services and MQSeries, providing the financial community
with even greater flexibility.

Back

Regulatory Compliance

Regulation NMS - includes provision for substantive new rules that are designed to modernize and strengthen the
regulatory structure of the U.S. equity markets.

OATS Phase III - makes provision for an SEC approved rule filing relating to the OATS rules

MiFID - scope of support for the MiFID requirements extends to Pre-trade transparency, Order handling and trading,
post-trade transparency and transaction reporting.