by Lisa Taikitsadaporn and Hanno Klein | December 15, 2010 |

For the first time, there is actual proof of the long promised commitment from standards bodies and the industry to work together under the ISO 20022 umbrella. The Standards Coordination Group, the guardian of the recently updated Securities Investment Roadmap, is steering this collaboration. It is becoming the voice of open standards, promoting it up to law makers and regulators in Washington DC and Brussels.

Because the financial community is a vast one, encompassing institutions across the globe that deal with diverse asset classes at different points in the securities trading life cycle, different organizations have traditionally been responsible for developing their own messaging schemes. Today, financial firms often combine a great range of trading activities; therefore, the messaging standards from different organizations often intersect, but remain incompatible.

Within the financial services industry, there are multiple standards being used, hence the desire to ensure some level of interoperability. It is clear to many market participants that the FIX Protocol is the de facto standard for pre-trade and trade, that FpML is the de facto standard for OTC Derivatives, that ISO is the de facto standard for settlement and payments, and that XBRL is the de facto standard for business reporting. The Industry would benefit from an approach that leverages and includes these standards into a broader framework without reinventing and creating redundant messages that increase implementation costs and cause confusion for the industry.

The Standards Coordination Group began collaborating on the Securities Investment Roadmap in 2006, publishing the first version of the Roadmap in 2008 and the latest version in October 2010. The Investment Roadmap provides market participants with consistent direction when using financial services messaging standards by visually mapping the protocols to their appropriate business processes across asset classes and it also lays the groundwork for moving towards a common business model, ISO 20022, for the securities industry.

How far have we come and what is being done to expand the role and increase the value of FIX as the basis for a full trading cycle messaging standard for listed derivatives markets?

A FIX Report Card

The listed futures and options markets have standardized around the use of the tag=value based FIX 4.2 version of FIX for order routing. Internationally, the past year has seen some very encouraging news in terms of FIX adoption. Eurex released its Xentric FIX Gateway. Meff released its FIX 4.4 Gateway, which is arguably the most comprehensive and standard implementation of FIX for derivatives markets released to date. Even with the additional FIX adoptions, however, there are still several marketplaces that do not support a FIX interface. And even among the marketplaces that have adopted FIX, there is significant disparity in how the standard has been implemented, greatly minimizing, though not eliminating, the value that can be achieved via FIX adoption. Order routing applications are increasingly being required to be intelligent enough to make routing decisions based upon
market data. Even overlooking the lack of standardization in the use of FIX, the greater problem is that every market has a different proprietary market data interface, which further lessens the value of FIX to the user.

With regard to market making, technological issues arise in terms of being able to use FIX for ultra high volume applications that are required to consume market data events and then automatically generate market quotations in response. The sheer volume and rate required to quote listed option series pushes the tag=value version of FIX to its limits. For order-only markets, the necessity to perform order chaining when canceling orders to refresh markets creates considerable overhead. Order-only markets must look to the FIX quoting models as provided in FIX 4.3 and FIX 4.4 as a means to provide a common market making model across markets. Until FIX can provide a clear solution for high volume market making, the dominant market making APIs will continue to be proprietary.

The good news in standardization is clearly found in the clearing/back office space for listed derivatives markets. There has been an incredible degree of cooperation between the U.S. listed markets, clearing organizations, vendors and FCMs in developing the FIA Extensions to FIXML 4.4 for Listed Derivatives Clearing. This initiative started by Chicago Mercantile Exchange and the FIA
Standards Working Group is now paying off with production applications being implemented and released by the major exchanges and vendors.

by Robert Stowsky | March 8, 2004 |

The recent announcement by FIX Protocol Ltd. (FPL) on its certification program for fixed income highlights an ongoing debate not isolated to the financial services industry. On one side of the debate are those who see standards as a way to promote common industry practices. On the other side are those who think standards can dampen innovation. Somewhere in the middle are the people who participate in industry organizations to create these standards. They must walk a fine line between the two sides to build standards that are both usable and flexible in order to be adopted by their intended target communities. How stringent, or how flexible, a standard should be depends on both what is being standardized
and who will use the standard.

As the FIX protocol expanded to include support for fixedincome trading, participants in the market, whether from the buy-side, sell-side, trading platform, or product vendor segments of the industry, began to take sides in the debate. Surprisingly, what side is taken is not a reflection of a participant’s particular role. In separate conversations with two leading buy-side firms, I was given two very different points of view. The head fixed-income trader of the first firm welcomed the addition of the expanded support of fixed income to the FIX protocol with a caveat: He did not want to see the amount of variation in how the protocol was implemented that he had witnessed on the equity side of the business. The second firm also welcomed the FIX protocol’s support for fixed income, but it had quite a different caveat: Its fixed-income trading department wanted the protocol to allow them to add information to certain messages that they felt was necessary for how they traded with their counterparties.

On the other side of the trade, both sell-side firms and trading platforms are equally split in their desire for a strictly adhered to standard versus one open to creative modification. By having a strictly enforced protocol, firms only have to develop a single implementation for all of their clients. However, a flexible protocol allows firms to differentiate themselves from competitors by enriching the contents of the messages. For vendors of order management systems that need to both generate and consume messages, a single flavor would ease both product development and support. Most of the major FIX engine vendors support the ability to add user-defined fields without the need to modify the FIX engine itself, making them the few agnostics in the debate.

Business Process Dictates Flexibility

Other protocol standards for the investment industry face similar dilemmas. Where they fall in their requirements for strict adherence and malleability is often a reflection of the processes they are supporting. The Financial product Markup Language (FpML) is designed to support the OTC derivative market. This is a market that is driven by innovation and flexibility. While FpML offers a prescribed format for describing various OTC deals that corresponds to the master agreements provided by the International Swaps and Derivatives Association (ISDA), users can make extensions and deletions as they see fit to correspond to their particular business needs.

The Market Data Definition Language

(MDDL) provides a standard format for describing listed financial instruments, indices and events, such as corporate actions. MDDL describes both the static data, such as who issued a particular bond, as well as the dynamic data, such as the current price for a stock. As the basic content for this type of information is fairly well agreed upon by both the producers and consumers of market and pricing data, MDDL can provide a standard more rigid than others. Yet MDDL also is extensible enough to accommodate additional data that an exchange may want to provide as well as enrichment from data vendors.

Likewise RIXML, the Research Information Exchange Markup Language for the distribution of market research, provides a solid framework while allowing users to add or delete information. By providing a combination of design rules and data definitions, ISO 15022 is looking to provide a repository flexible enough to build messages for any financial related process.

Enforcement Evolves Over Time

At some point one would expect that these standards’ flexibility would interfere with the goal of providing a common method of exchanging and storing information. If we make enough modifications can we actually say that we are using a particular standard? To put it another way: Is there a point where we can no longer say we are compliant to a particular standard whether it be FIX, FpML, MDDL, or RIXML?

How a standard is enforced falls into the two categories of user enforcement and organizational enforcement. User enforcement can further be divided into accepted practice and best practice. Organizational enforcement can be split into validation and certification. How a standard is enforced is often a reflection of its acceptance and maturity. In its early stages, a standard will usually have a specification that is open to interpretation. During this period we begin to see accepted practices that are agreed to between specific counterparties.

As the standard is adopted, a trial and error phase usually points to areas requiring more rigorous definition. A tighter definition of a standard combined with a larger base of users commonly results in community recommended best practices. When a standard has reached both a broad level of acceptance and a high level of complexity the user community will often call upon the organization overseeing the standard to provide some method of arbitrating differences of interpretation that still may arise.

Certification Vs. Validation

Standards organizations have a number of choices in how they can enforce the standards they oversee. The FIX and FpML standards each provide an example of how to promote common implementation of their protocols by using a different approach respectively. FPL has embarked on a somewhat centralized certification program to assure conformance to the FIX protocol for fixed-income users. ISDA, which oversees the FpML standard, has taken a more distributed approach by providing its users with a set of rules for validating the proper use of the standard.

FPL has selected vendors who will be recognized certification agents for the protocol. These agents will each implement a set of test scripts to be provided by FPL. In order for a firm to say it is FPL certified, it will need to run through a series of tests with a certification agent that covers the various asset classes and message dialogues for which it wishes to claim certification.

For FpML, its Validation Working Group has created a set of rules for users to implement on their own. The Validation Working Group offers a reference implementation of the validation rules and test cases for users to model their own implementations on. A user would send an FpML document to a counterparty that contains a field that would reference the set of rules for which the document
is claimed to be valid. The counterparty would then be able to validate the document against the stated set of rules and accept, or reject, the document. Counterparties could also agree between themselves on customized subsets or supersets of rules to determine validation.

The choice of certification versus validation reflects the respective environments in which these standards are used. By definition, certification is focused on the operational aspects of a protocol. From an operational point of view it is not enough to only know that the message contents are correct, but also that it is the right message being sent. If I request a quote and you respond with an execution, we have a problem, regardless of whether the messages themselves are formatted correctly. Certification makes sense
when you have an ongoing dialogue between parties as you do when using the FIX protocol. Validation is focused on the content itself. FpML provides an electronic representation of an agreement between parties. Validation ensures that all the necessary data is there and in the right place. Both certification and validation provide a method for testing and verifying that a minimum set of requirements is met in order to claim compliance to a standard.

by Lisa Taikitsadaporn and Martin Koopman | Q1 2004 |

What is STP in fixed income?

Using the web interface provided by your fixed income ATS is not STP. Even if it can communicate electronically with your systems, it is only one small piece of the puzzle. An ATS’s web interface may provide your traders with the means to execute a trade with the broker/dealer and have that confirmed trade information pop up on the web GUI, but that’s not STP. Why not? Because your traders (or their support staff) will still have to manually re-key that confirmed trade information into their trading application/blotter system so that post-trade processing can occur. However, with a little bit of integration work, that manual re-keying can be eliminated. How? Have the ATS send the trade information electronically into your system so the traders can view it on their application/blotter. That transfer of trade information from the ATS into your system can be done using FIX. Unless there is an error in the trade information, your post-trade workflow can begin with your traders sending the block allocations to the broker dealer electronically using FIX. The broker dealer in turn can confirm the block using FIX. This is the start of fixed income STP, albeit a small step. By removing the need to re-enter trade data, FIX is a tool that aids in any firm’s STP initiative. The front-office automation provided by FIX reduces errors in the trade information needed for middle and back-office operations.

What are the challenges of implementing FIX for fixed income?

Scoping the project

The decision of ‘where to start’ is the first challenge you are likely to face. Which aspect of the trade life cycle you decide to FIX-enable first, as your ‘getting to know FIX project’, will depend on what your firm is ready to do. In the past one to two years, we’ve seen two main approaches: go after the area of trading operations where there is the most‘pain’, or experiment with a small step that does not cause too much disruption. Which approach you take will depend largely on how you’ve sold the idea to your traders and your firm’s tolerance to change. Some of the first implementations of FIX in the fixed income space started with receiving FIX Execution Report messages as trade confirmations from ATSs. By taking in FIX Execution Report messages you’ve enabled the possibility for two things to happen: 1) eliminate the need for traders to re-key trade confirmations into your trading system, or 2) add the ability to match your counterparty’s view of the trade with your trader’s view of the trade. Whether you gain one, or both, of these results depends on your internal architecture and trading system capabilities. This is a manageable first step to get your feet wet with FIX. The next logical step could be streamlining block allocation and confirmation or sending FIX orders. Eliminating the need to use means such as fax, phone or email to confirm trades and communicate allocations eliminates re-keying errors on both the buy and sell sides. The main objective is to take incremental steps that show results as to what FIX can do to lead you to reduce trade errors and breaks in your downstream operations.

Security identification

As you continue along this journey, other challenges will surface, some of which you may have anticipated, others you may not have thought of. One of the first issues you are most likely to run into is security identification – a big challenge with fixed income trading in general. Liquid securities, such as Treasuries and agencies, are easily identified through ‘live’ CUSIPs. The challenge lies with primary issues for securities such as TBAs, CPs and corporates that may not have ‘live’ CUSIPs even when the issue is initially being traded. How do you know that you and your counterparty are talking about the same security if there is no ‘live’ CUSIP? You’ll need several identifying parameters in order to help you ‘match’. Possible data includes the issuer’s six-digit CUSIP that could be used as a preliminary identifier, descriptive information on the security, such as maturity date, coupon rate, issuer’s name, security type, etc. Even then, this isn’t perfect. Your traders are likely to have to be involved to confirm that it is the correct security when your system is not able to ascertain an exact ‘match’. Security identification, especially for primary issues, in fixed income is a topic unto itself, but it will affect your electronic trading efforts today. This is a problem that will require co-ordinated industry efforts to address.

Real-time trading environment

Further along this road, you will notice that you are increasingly dealing with a real-time trading environment. A real-time trading environment requires you to think differently about how your architecture is designed in order to deliver real-time trade information to your traders. It means a real-time messaging environment, a real-time trading blotter that can handle state management of orders and allocations, an infrastructure that can support this, software solutions with more business rules and intelligence ‘built in’, and additional levels of systems and trading operations support. However, you need not be alone on your journey. Real-time trading environments have been a reality on the equity side for many years now. It is an opportunity to learn from your colleagues on the equity side of the business and to talk seriously about leveraging some of the common infrastructure, a cost containment move, that can be shared across your firm.

Q: How has your involvement with FIX Protocol developed?

A: I first became involved with FIX as a user in 1994 when I was at Thomson Financial, working on its equity order routing network product, TradeRoute. I left Thomson in 2000 around the time that the first draft of FIX 4.3 was just being put out for public comment. Via email, I provided detailed comments on all of the drafts through the FIX 4.3 release process to the Technical Committee (the predecessor to the Global Technical Committee).

Towards the fall of 2000 I responded to the call for participation on the FIX ISO XML Working Group. During that same timeframe I had the opportunity to meet Dean Kauffman through my involvement on a project implementing FIX for fixed income. Almost immediately, he asked me to join his fixed income working group that was a result of the BMA/FPL joint initiative.

It was over that short period of time that I went from being a peripheral contributor to an active contributor on the Technical Committee and various working groups. In a nutshell, FIX has been my niche for 10 years and it will continue to be a big part of my work.

Q: You helped write the extension of FIX to fixed income using the “gap analysis” from the Bond Market Association. Do you feel that FIX mirrors “best practices” for fixed income trading or were compromises made to accommodate peculiarities of the Protocol?

A: Actually I was a primary author of the “gap analysis” document, together with Dean Kauffman. When Dean asked me to participate in his fixed income working group the “gap analysis” document did not exist. I was provided with the Plain English documents that were available at the time and started to do my own analysis, based on the goals of the working group. That analysis work became the foundation of the “gap analysis” document. Dean had also done some of his own analysis work, so we combined our work to create a single “master” document.

The Plain English documents definitely helped the gap-analysis process. Without those documents I do not believe that FIX 4.4 would be providing the level of support for fixed income securities processing that it does today. Dean and I also had the benefit of actually being in the process of implementing FIX for fixed income trading between two counterparties as we were trying to nail down the contents of the gap analysis document.

FIX 4.3 itself provided us with a well developed foundation on which to work. Much of the transactional dialog was already there in FIX 4.3, especially for orders/execution and allocations. What we needed to beef up was the negotiation dialog. There were some message types that we had to “reframe” in terms of how they were to be used in the fixed income space as opposed to the equity space.

Q: In your professional work of helping firms implement FIX into their trading and processing systems, what are the largest hurdles you have encountered?

A: In nearly three years of consulting on FIX implementations since co-founding Brook Path Partners, Inc., I have not come across hurdles that cannot be overcome. Firms that have decided to embrace FIX engage in the initiative knowing what is involved. It takes commitment, and changes will need to occur that affect trading systems and workflow processes, as well as also requiring the traders to modify their behavior. I have been fortunate so far to be involved in projects where I didn’t have to “sell” the merits of electronic trading and FIX because by the time I’m brought in the project has already been “sold” and approved.

Q: What benefits have you seen develop for firms that implement FIX?

A: The main benefit I’ve seen is an increase in the traders’ efficiency in doing their jobs. They are now able to focus more on looking for trading opportunities than on doing clerical work. This is true for both buy-side and sell-side traders. By removing the need to re-enter trade data, FIX is a tool that aids any firm’s STP initiative. The front office automation provided by FIX reduces errors in the trade information needed for middle and back office operations.

Q: Does Version 4.4 adequately support the entire trade cycle through allocations and confirmations or do you see additional work being done to support the backend of the trade cycle?

A: From the trade cycle of an institution through to the sell-side flow, 4.4 facilitates the communication of the data needed for the entire transactional dialog including allocations and confirmations. The entire volume on post trade messaging went through a major revision as a result of the “gap analysis” and the work output from the Allocations Working Group led by Jim Kaye of Goldman Sachs in London. However, Dean Kauffman and I made sure that fixed income’s requirements were also met by the changes proposed by the Allocations Working Group.

Q: In firms that are implementing FIX across multi-asset classes, are they generally building fixed income capability on top of equity systems or new and separate FIX systems?

A: What I’ve seen so far is that the efforts are separate across asset classes, although some firms are trying to coordinate the FIX infrastructure aspects. Many middle and back office systems are already shared across the different asset classes that a firm may trade. On the front office side, the trading systems supporting the equity desk and the fixed income desk are still separate. However, the firms that are progressive will eventually build a common FIX infrastructure and provide a messaging component as a common service to all of their different trading desks.

Q: What resources can be shared across asset classes in a firm easily, e.g., the FIX engine?

A: The FIX engine, the network to communicate with counterparties external to the firm, and, as I mentioned above, a common messaging component can be shared internally. These are systems and infrastructure resources that can be shared within a firm. In terms of human resources, I foresee firms with a large FIX infrastructure also forming a group of people who will support this infrastructure across the firm – regardless of the asset types being traded. From a support perspective it is all the same no matter what asset type is being traded.

Q: You also helped write the new FIX Implementation Guide – any recommendations for our readers on its use?

A: The Implementation Guide is a starting point. It is a high level document aimed at key decision makers to educate them as to what is involved in taking on such an initiative. I think it is best to look at it as your high level project checklist. The nuts and bolts of implementing FIX are going to be different for each firm, but the key chapters of the guide can easily be the major line items in an implementation project plan.

Q: What is your background and what does your firm do?

A: As mentioned earlier, I have been involved with FIX implementations for 10 years. The majority of my experience has been in equity. For me the transition to implementing FIX in the fixed income space was a matter of learning and understanding the business of fixed income. Without a solid understanding of the business processes being supported, it is difficult to fully exploit the benefits of any technology. FIX is no exception.

My background, educationally, was in computer science and MIS. One of my first jobs out of college was as a software quality assurance engineer for a software firm. I later earned a Masters of Science degree in finance. While with Thomson my role required that I work directly with both clients’ technical and business staff. So I am a techie who later transitioned into this “business technologist” role.

Brook Path Partners, Inc., is a financial technology consulting firm. We are not a systems integration firm nor do we sell any software products. Our guiding principle is to be vendor and technology neutral so that we can deliver unbiased advice to our clients. The types of services we provide include business analysis, strategic planning, project management, high level architectural design, vendor evaluation, test strategy and planning, and education and training around the implementation of technology supporting the entire trade lifecycle. FIX-related projects we’ve been involved in include implementation for fixed income, retooling of internal infrastructure, implementation training, and giving general advice and guidance to firms on their FIX implementations. Our work has covered buy-side, sell-side, vendors, and ECNs, in both the fixed income and equity spaces. A major objective of Brook Path Partners is the transfer of knowledge to our clients’ staff during an engagement. We feel that firms do best when their staff members are given the opportunity to learn new things that are directly related to their jobs. Our mode of operation is also different from other consulting firms in that our principals’ time is shared across multiple projects for different clients at once. This requires our clients to dedicate their own people to work with us. It is through this arrangement that the knowledge is transferred to the firm’s staff. It becomes a win-win situation for all involved.

Lisa Taikitsadaporn is co-founder of Brook Path Partners.  She has worked with the FIX Protocol for over ten years, first as a user at Thomson Financial and then as a consultant.