FIX has grown rapidly from the historic base of cash equity product, and pre-trade and trade business process support, to a point where it now supports a broad range of product types; Fixed Income, Foreign Exchange, Equities and Derivatives. This organic growth has been driven by the business benefits of FIX, and a dynamic user and vendor community. JP Morgan’s Andrew Parry explores the technical aspects that will take FIX to the next level, in particular in relation to global derivatives.The success of FIX, to date, is supported by a simple premise. It is useful, provides valued business outcomes, and has an active user, vendor, and consultancy community, rather than trying to be the most beautiful possible technical solution.
To expand FIX further we need to continue the lines of work opened up in FIX 5.0 so that we can continue to provide valued business outcomes with what is, by now, a far larger model in terms of data and function support than when FIX began.
These lines of work such as correctness, machine readable business rules and process rules – discussed below – should improve the core of the FIX model, and increase the ease of use, both for software tool makers, and our end users.
Companies such as Google and Apple provide a good example of this approach. The end user of Google maps does not have to understand the technology behind it, whereas application developers are provided with a Google Maps API. We should approach the FIX model in the same spirit.
An analysis: Service Packs
FIX 5.0 onwards supports a service pack model, which supports the addition of minor changes within a matter of months’. This approach has particular value for the derivatives industry, which has a high rate of business driven change, and increasing regulatory requirements.
By adopting the service pack model, we promote standardised additions, instead of customised user extensions, which are commonly required in the absence of a timely way to make contributions. We will go on to look at how the service pack model has been used to a wide range of features to support derivatives in FIX 5.0 onwards.
Building Blocks
The service pack approach has been used to provide business correct building blocks, which can be re used. Taking an example from FIX 5.0-SP2( Service Pack 2), which has provided timely support for the business requirements and regulator demands of credit derivative contract specification standardisation and central clearing in America and Europe.
EP83 – Enhancements for Credit Default Swaps Clearing. “The following new fields were added to the Instrument Block … AttachmentPoint (1457), DetachmentPoint ( 1458 )”.
These fields are in support of CDS index tranches, which give investors the opportunity to take on exposures to specific segments of the CDS index default loss distribution. For example the “0% to 3% tranche” with attachment (0% ) and detachment (3%) is the lowest tranche, known as the equity tranche, and absorbs the first 3% of the losses on the index due to defaults.
Correctness
The percentage data type used for AttachmentPoint and ExhaustionPoint should only allow values between 0% and 100% (inclusive) to be business correct. The attachment and exhaustion points are always between 0% and 100% of the notional amount. This is data type correctness.
Where a tranche is being modelled, both AttachmentPoint and ExhaustionPoint should be used, otherwise the tranche is unbounded. This is model structure correctness.
AttachmentPoint should always be less than ExhaustionPoint, otherwise the Tranche would have zero or negative width. This is business rule correctness.
Where we have standardised tranches, such as “0% to 3%” we should have a way of tying back to a reference data source to confirm that this is indeed one of the standard tranches. This is reference data correctness.
The purpose of considering all these degrees of correctness is so that the FIX model is business correct, easy to use for automation, and enjoys good software tool support.
Business Rules
The business rules within FIX are not currently machine readable. They exist only as text descriptions in the specification. This requires users to understand and implement them all correctly, or places the burden on software tool vendors and consultants to do the same. Several examples of conditional presence being described in text only form are provided by the ExecutionReport message.
These conditional presence requirements are always true of the ExecutionReport message. In many other cases the set of business rules will vary. The content of an exchange traded derivative should be that which is found in the contract specification, for example:
CBOE BINARY OPTIONS ON THE S&P 500 INDEX (SPX)
“CBOE Binary Options are contracts that have an “all-or-nothing” payout depending on the settlement price of the underlying broad-based index relative to the strike price of the binary option.
Binary Call Options pay either 1) a fixed cash settlement amount, if the underlying index settles at or above the strike price at expiration; or 2) nothing at all, if the underlying index settles below the strike price at expiration. Binary Put Options pay either 1) a fixed cash settlement amount, if the underlying index settles below the strike price at expiration; or 2) nothing at all, if the underlying index settles at or above the strike price at expiration.
So we know that transactions under this contract specification will always have a binary payoff, and always cash settle. The same arguments apply for the rest of the contract specification, such as Multiplier ($100), and Exercise Style (European).
The goal is that FIX business rules should be machine and human readable, both for rules which are always true, and for those which are context sensitive.
The FIX Model
The FIX model contains both data (business things) and functions (business processes). In the examples above we have looked at both data (a CDS tranche) and functions (an execution report).
The data model within FIX contains a high degree of optionality – both AttachmentPoint and ExhaustionPoint are independently optional – and weak typing (both AttachmentPoint and exhaustion point use an unbounded Percentage type).
The function model within FIX is expressed as diagrams, which are not machine readable. The diagram, below, shows how to use the message ExecutionReport with the response ExecutionReport – Ack.
From the text specification – Execution Report Ack – is an optional message, and from the diagram above you will note “optional” and “optional, however recommended”. Such text is not machine readable, and every integration project needs to arrive at implementation decisions to ensure the correct execution of the business process. For example we could decide that every outbound message will solicit a response.
Appreciating the end users
A guiding principle for ease of use should be what is a “reasonable ask” for the skills and motivation of each section of our user community, and what should we deliver to maximise FIX adoption and growth. Continuing the Credit Default Swaps example, consider the roles involved in a hypothetical CDS clearing project.
Project Manager: May be a generalist project manager, with limited understanding of CDS contract specification and processing. Needs to be assured that FIX is not a technology risk, and understand how it serves business requirements, and fits into the delivery plan.
Business Analyst: Should have a good understanding of CDS contract specification and processing. May have limited prior exposure to FIX. Needs tools both to communicate to management, understand the FIX specification, and provide clear specifications, tied back to business requirements.
Developer: May have limited business knowledge, and little prior exposure to FIX. Needs good software tools to implement from a clear specification, ideally an executable specification.
Software Tools
The web browser screen shots featured in this article are all from FIXimate, a read-only window onto the FIX repository. It is driven by software which has been contributed by many leading members of the FIX community over several years. The structure and content of the FIX repository continues to be developed and improved.
To promote a healthy range of software tools that support FIX it is important to arrive at a common, open repository format, which holds the FIX model, and allows users to operate on it. A user, for example, may take a public version of FIX as a base, add their own custom tags to support new requirements, then choose to release the custom tags as a public domain FIX expansion pack.
As well as being able to write into the repository, the ability to export out of the repository into other applications is vitally important. To consider the end user profiles, the Business Analyst would wish to export out to a document or spreadsheet format, and the Developer would wish to export out directly to a FIX engine, to avoid any errors in translation, and allow multiple FIX engines to be identically configured.
Such software tools provide a great benefit to users even if they are not using customised versions of FIX. We saw in the process example above that the use of the ExecutionReportAck message is optional. Good software tools provide support for “capability profiles” which allow a group of systems to share capabilities and behaviour, for example they all choose not to use the optional message. They reduce integration cost, and improve time to market.
Stick to Business
FIX has grown because the technology and organisation have delivered business value, grown organically, with the network effort of a high number of adopters delivering great value.
As we continue to grow in both product and process coverage, we should learn from past experience, apply the best of current technology, and engage with the FIX community to continue business driven standardisation.
