The FIX Global Technical Committee (GTC) is proud to announce the update of Playlist to Version 1.2. If you are a FIX member, you can request access from the FIX Program Office. It can then be invoked either via its own URL or through the FIX website (“Playlist” in the dropdown menu “Tools” or from the Orchestra landing page). You have to be a FIX member and logged into the FIX website with your user account linked to your firm.

What is Playlist?

Playlist is the second tool related to the Orchestra Technical Standard. Playlist is a web-based tool available through the FIX website that allows the user to generate a base Orchestra XML file by selecting what they need from an Orchestra reference file.

Similar to Log2Orchestra, it is intended to be the starting point for someone who wants to benefit from Orchestra and use it to build the meta-data representation for one or more FIX interface(s). Log2Orchestra should be used if you wish to start with existing behavior of your implementation. Playlist should be used if you wish to start from standard FIX message definitions. The input file used by Playlist can be an officially published version of FIX Latest or also your own Orchestra file. You do not require any log files from an existing FIX interface to be able to use Playlist. Once an Orchestra XML file has been created with Playlist, you can use Tablature to convert it to and from markdown for maintenance and extensions. It is recommended to use Orchestra Server, a service offered by FIX Trading for the maintenance for your Orchestra XML files. Access to the Orchestra Server is complimentary for members of the FIX Trading Community. Orchestra Server provides the necessary tools to manage FIX and non-FIX specifications based on the Orchestra Technical Standard. You can also create, browse, and export your Rules of Engagement specifications easily.

The following basic steps are required to create an Orchestra XML file with Playlist.

1. Choose an Orchestra XML file as your input file that will be loaded only into your local browser
2. Select the messages, groups, components as well as their fields and values that you want to support
3. Choose a name for the new Orchestra XML file to output to and select “Create Orchestra file”
4. Select “Download File” and choose a directory to store the new output Orchestra XML file

What has changed with Playlist v1.2?

The latest version of Playlist now fully supports the display of union datatypes. Previously, they were only shown in the list of datatypes but never selected. Union datatypes are now shown wherever a field is displayed, including messages, groups and components. They are shown as selected in the list of datatypes as soon as at least one of the selected fields has a union datatype.

Repeating groups always start with a NumInGroup field to count the number of instances for tag=value encoding. This field is now displayed as part of the group and automatically selected as soon as at least one element of the group is selected. It is not necessary to manually select this field for a group. Additionally, the NumInGroup fields are displayed in the read-only list of fields.

More detailed information can be found in the Playlist User Guide.

Playlist v1.2 has fixed a few minor errors:

• In some cases, the removal of fields from messages also removed these fields from other messages if they had been selected there.
• In some cases, it was possible to deselect the last code of a code set (you need to remove the last field using the code set instead).

The FIX Global Technical Committee (GTC) has completed the transition of the FIXML schema files for FIX Latest from the Basic repository to the Orchestra repository. This change is effective as of EP277.

FIXML is the XML encoding used within FIX. FIXML is widely adopted for derivatives post trade clearing and settlement globally. Orchestra is the standard for machine readable Rules of Engagement and was developed by FIX. It is used for the third generation of XML representations of the FIX Protocol. The first generation was the Basic repository followed by the Unified repository. The XML representations are used by the GTC to generate artifacts such as FIXimate and the FIXML schema files.

The Orchestra Technical Standard was developed to significantly enhance the representation of meta-data for FIX and non-FIX electronic interfaces. Version 1.0 was published in February 2021 and has been used to provide an additional XML representation of FIX Latest since EP255. Currently, FIX Latest is still provided in all three repository formats (Basic, Unified, Orchestra).

The GTC has now completed the generation of all artifacts to the Orchestra repository. The Basic repository is no longer needed to generate the FIXML schema files and will eventually be discontinued.

The following sections describe the differences between the FIXML schema files created from Basic compared to Orchestra in detail.

Component Types

Components in the Basic repository have different types of components, identified with the element <ComponentType>. The component types, “ImplicitBlock” and “ImplicitBlockRepeating” had been used for the FIX Specification to identify (repeating) blocks embedded inside the message layout table. The need to make such a distinction was no longer needed as of FIX 5.0 but had not been removed from the Basic repository. The Orchestra repository no longer has component types. Blocks are distinguished from repeating blocks by being part of <fixr:components> or <fixr:groups> respectively.  The FIXML schema files created from the Orchestra repository continue to provide the component types “Block” and “BlockRepeating”. The component types “ImplicitBlock” and “ImplicitBlockRepeating” have been changed to “Block” and “BlockRepeating” respectively.

Namespaces

The new FIXML Schema files have an additional namespace for Orchestra:

xmlns:fixr="http://fixprotocol.io/2020/orchestra/repository

References to the legacy FIX Protocol specification

The new FIXML Schema files no longer contain references to Volumes 3-5 of the legacy FIX Protocol specification as that has been replaced with the new (online) version. This change only affects the <xs:documentation> elements inside the FIXML schema files.

Ordering of field values

XML elements do not have a specific sort order. This affects the file fixml-fields-base-Latest.xsd. In some cases, enumerations of fields in the new FIXML schema files are different in terms of the order they appear in. This affects the element <fm:EnumDoc> (inside element <xs:appinfo>) and the elements <xs:enumeration> or <xs:pattern> (inside element <xs:restriction>).

There are no differences regarding the individual values themselves and should hence have no impact on the validation of FIXML messages.

The FIX Global Technical Committee (GTC) is proud to announce the update of Playlist to Version 1.1. If you are a FIX member, you can request access from the FIX Program Office. It can then be invoked either via its own URL or through the FIX website (“Playlist” in the dropdown menu “Tools” or from the Orchestra landing page). You have to be a FIX member and logged into the FIX website with your user account linked to your firm.

What is Playlist?

Playlist is the second tool related to the FIX Orchestra Technical Standard. Playlist is a web-based tool available through the FIX website that allows the user to generate a base Orchestra XML file by selecting what they need from an Orchestra reference file.

Similar to Log2Orchestra, it is intended to be the starting point for someone who wants to benefit from FIX Orchestra and use it to build the meta-data representation for one or more FIX interface(s). Log2Orchestra should be used if you wish to start with existing behavior of your implementation. Playlist should be used if you wish to start from standard FIX message definitions. The input file used by Playlist can be an officially published version of FIX Latest or also your own Orchestra file. You do not require any log files from an existing FIX interface to be able to use Playlist. Once an Orchestra XML file has been created with Playlist, you can use Tablature to convert it to and from markdown for maintenance and extensions. It is possible but not recommended to use an XML editor to maintain the Orchestra XML file directly. However, firms can create scripts or applications that read and manipulate the XML or markdown representation programmatically.

The following basic steps are required to create an Orchestra XML file with Playlist.

1. Choose an Orchestra XML file as your input file that will be loaded only into your local browser
2. Select the messages, groups, components as well as their fields and values that you want to support
3. Choose a name for the new Orchestra XML file to output to and select “Create Orchestra file”
4. Select “Download File” and choose a directory to store the new output Orchestra XML file

What has changed with Playlist v1.1?

A major enhancement has been provided for minor extensions of an existing Orchestra XML file. A selector file can be used to preselect a subset of a larger input file, followed by the manual selection of additional elements and the creation of a new Orchestra XML file. This had been a known limitation in v1.0 that has now been removed.

Playlist was primarily designed to extract a subset of the FIX standard to develop a firm’s rules of engagement. You can select the relevant messages, and within a message select the fields to include, and select codes from a codeset that apply. However, in version 1.0, there was no way to add something back in if you simply forgot to check it before outputting a new Orchestra file. In the new version 1.1, you can reintroduce the original reference file and use your subset to pre-select all the items you selected on the first pass. Now you have the opportunity to select a forgotten field, and then rewrite the intended output.

Playlist is now able to directly access standard FIX Orchestra XML files from GitHub (e.g. FIX Latest) in the same way as supported by Log2Orchestra.

More detailed information can be found in the Playlist User Guide.

Playlist v1.1 has fixed a number of minor errors:

• It was possible to deselect an entire code set if it only has one code to begin with.
• It was possible to select entire sections if the first input file did not have it at all.
• A code set with duplicate values in the input file caused Playlist to hang.
• An empty category in the input file caused Playlist to hang.
• Invalid XML in the input file now triggers a popup with specific error information.

The FIX Global Technical Committee (GTC) is proud to announce the availability of Playlist Version 1.0. If you are a FIX member, you can request access from the FIX Program Office. It can then be invoked either via its own URL or through the FIX website (“Playlist” in the dropdown menu “Tools” or from the Orchestra landing page). You have to be a FIX member and logged into the FIX website with your user account linked to your firm.

What is Playlist?

Playlist is the second tool related to the FIX Orchestra Technical Standard. Playlist is a web-based tool available through the FIX website that allows the user to generate a base Orchestra XML file by selecting what they need from an input Orchestra reference file.

Similar to Log2Orchestra, it is intended to be the starting point for someone who wants to benefit from FIX Orchestra and use it to build the meta-data representation for one or more FIX interface(s). The reference input file used by Playlist can be an officially published version of FIX Latest or also your own Orchestra file. You do not require any log files from an existing FIX interface to be able to use Playlist. Once an Orchestra XML file has been created with Playlist, you can use Tablature to convert it to and from markdown for maintenance and extensions. It is possible but not recommended to use an XML editor to maintain the Orchestra XML file directly. However, firms can create scripts or applications that read and manipulate the XML or markdown representation programmatically.

The following basic steps are required to create an Orchestra XML file with Playlist.

1. Choose an Orchestra XML file as your input reference file that will be loaded only into your local browser
2. Select the messages, groups, components as well as their fields and values that you want to support
3. Choose a name for the new Orchestra XML file to output to and select “Create Orchestra file”
4. Select “Download File” and choose a directory to store the new Orchestra XML file

More detailed information can be found in the Playlist User Guide.

The FIX Global Technical Committee (GTC) announces the successful transition of the FIX application layer from FIX 5.0 SP2 to FIX Latest. Extension Pack EP260 introduced an  application version identifier for FIX Latest by adding a new value 10="FIXLatest" (note that there is no space in the value) to ApplVerID(1128). FIX Latest is the term used to describe the latest version of the FIX application layer. FIX Latest is updated with each approved Extension Pack. FIX Latest is cumulative, containing all Extension Packs that have been approved prior. Please also see this video on FIX Latest – A Complete Service Package.

FIX Versions

FIX versions were used in the past to bundle a large number of incremental changes and triggered an update and publication of the FIX specification documents (aka Volume 1-7), now available as an online specification.

Extension Packs were introduced after the release of FIX 4.4 and have made changes to the latest version as follows:

• FIX 4.4 was enhanced with Extension Packs EP1 – EP40
• FIX 5.0 was enhanced with Extension Packs EP41 – EP75
• FIX 5.0 SP1 was enhanced with Extension Packs EP76 – EP97
• FIX 5.0 SP2 was enhanced with Extension Packs EP98 – EP259
• FIX Latest is being enhanced with Extension Packs as of EP260

A FIX version covers the previous version together with the Extension Packs enhancing it, e.g. FIX 5.0 represents FIX 4.4 together with EP1-EP40. Hence, FIX Latest represents FIX 5.0 SP2 together with EP98 – EP259 and will be continuously enhanced with Extension Packs. There are no plans to issue another version of FIX beyond FIX Latest.

The concept of FIX versions has more or less lost its relevance since the publication of Extension Packs started with EP98 after the release of FIX 5.0 SP2. Further to that, the refactoring of the FIX Session Layer introduced so-called session profiles, especially for the legacy versions FIX 4.2 (session profile “FIX.4.2”) and FIX 4.4 (session profile “FIX4”). The session profiles mandate specific values of BeginString(8), i.e. “FIX.4.2” and “FIX.4.4”, to maintain full backward compatibility of the FIX Session Layer.

A FIX version can be enhanced with any messages, fields, and values from FIX Latest and this is common practice in the industry, e.g. to fulfill regulatory requirements that are only covered with fields from a higher version. Only FIX 4.2 has a few deviations on the semantic level, e.g. the use of ExecTransType(20) in the ExecutionReport(35=8) message. Apart from having less messages, fields, and values, FIX 4.4 only has very few minor application layer differences compared to FIX Latest, e.g. Currency(15) was moved from the side level to the main level of the TradeCaptureReport(35=AE) message with FIX 5.0 SP1. As of FIX 5.0 SP2, the GTC is ensuring full backward compatibility of the application layer changes.

In summary, the refactoring of the FIX Session Layer made no changes on the technical level but allowed characterizing a FIX interface as running a FIX application layer version over a specific session profile, for example:

• FIX 4.2 with extensions over the FIX.4.2 session profile (BeginString(8)=”FIX.4.2”) or
• FIX Latest over the FIX4 session profile (BeginString(8)=”FIX.4.4”) or
• FIX Latest over the FIXT session profile (BeginString(8)=”FIXT.1.1”).

The transition to FIX Latest has now also been applied to the different representations of the FIX Repository (Orchestra, Unified, Basic). The following sections shows the changes that have been made to each of them as well as the changes made to the FIXML Schema files.

FIX Orchestra

FIX Orchestra is the main repository format based on the FIX Orchestra Technical Standard. It consists of a single file Orchestra.xml and attributes of its root element “fixr:repository” were changed as follows as of EP260.

• name=”FIX.5.0SP2″ was changed to name=”FIX.Latest”
• version=”FIX.5.0SP2_EPxxx” was changed to version=”FIX.Latest_EPxxx” (“xxx” stands for the EP number)

This file further contains the pedigree of its elements, i.e. the FIX version (and possibly EP number) when an element was added (attributes added and addedEP), last updated (attributes updated and updatedEP) or deprecated (attributes deprecated and deprecatedEP). There is no change to the values of the attributes identifying the number of an EP. However, whenever these attributes have a value of 260 or higher, the version information was changed to FIX Latest as of EP260.

• added=”FIX.5.0SP2″ was changed to added=”FIX.Latest” if addedEP=”260″ or higher
• updated=”FIX.5.0SP2″ was changed to updated=”FIX.Latest” if updatedEP=”260″ or higher
• deprecated=”FIX.5.0SP2″ was changed to deprecated=”FIX.Latest” if deprecatedEP=”260″ or higher

FIXimate provides the pedigree information from the Orchestra.xml file.

FIX Unified Repository

The FIX Unified Repository is the legacy repository format (aka Repository 2010 edition). It basically consists of two XML files, one of which contains all language specific text (aka “phrases file”). The objective at the time was to support different languages by means of separate phrases files. The root element “phrases” has a version attribute that was changed from version=”FIX.5.0SP2_EPxxx” to version=”FIX.Latest_EPxxx” as of EP260 (“xxx” stands for the EP number). The other file (FixRepository.xml) contains all elements in a single file. Its root element “fixRepository” has an element “fix” that has a version attribute that was changed from version=”FIX.5.0SP2″ to version=”FIX.Latest” as of EP260. Only FixRepository.xml contains pedigree information for the elements. The names of the pedigree attributes are the same as for FIX Orchestra and their values change as described above.

FIX Basic Repository

The FIX Basic Repository is the oldest repository format and is currently still provided for backward compatibility. It consists of separate XML files for each of the various elements of FIX, e.g. Messages.xml, Fields.xml, Enums.xml. The root element is different for every file but always has a version attribute that was changed from version=”FIX.5.0SP2″ to version=”FIX.Latest” as of EP260. Note that the attribute latestEP of the root element reflects the last EP that changed any of the elements contained in the given file. It does not reflect the last overall EP and may hence continue to have an EP number lower than EP260 even if version=”FIX.Latest”. Each file contains pedigree information for its elements. The names of the pedigree attributes are the same as for FIX Orchestra and their values change as described above.

FIXML Schema Files

FIXML is the XML encoding for the FIX application layer and its meta-data is provided with every EP in the form of XSD files. These FIXML schema files contain information about the FIX version they are based on, and the FIX version is also part of the filename.

As of EP260, the suffix of every FIXML schema filename changes from “fixml-<content>-5-0-SP2.xsd” to “fixml-[content]-latest.xsd”. The FIXML schema files use an <xs:include> element to reference the name of one or more other FIXML schema files. Accordingly, as of EP260, the FIX version in the filename being referenced changes from “5-0-SP2” to “Latest”.

Each file contains <xs:schema> as root level element with a number of attributes. Some of the attribute values contain the FIX version and change as follows:

The FIX Global Technical Committee (GTC) is proud to announce the addition of all 258 Extension Packs to the FIX Latest online specification. FIX Latest is the first official release of FIX since FIX Version 5.0 Service Pack 2 (FIX 5.0 SP2) was released in 2010. FIX Latest makes available the use of all application layer messages over the FIX4 and FIXT session profiles of the FIX Session Layer standard. For the first time, the entire integrated FIX specification is available as an online format.

The transformation of the normative specification of the FIX application layer into an online format was started a few years ago, prompted by a contribution from Jim Kaye of Bank of America Merrill Lynch of an initial refactoring of the document based on the seven volume FIX specification. The FIX organization then worked to enhance the repository, which is the machine-readable version of the specification, which became FIX Orchestra. At the same time a replacement FIX website and discussion forum was developed and released that supports single sign on. The availability of FIX Orchestra and the new website infrastructure provided a platform upon which Hanno Klein, GTC Co-chair, could lead the continued refactoring and integration of the 160 Extension Packs created since the release of FIX 5.0 SP2 into an integrated online specification that is generated from a combination of markdown and FIX Orchestra, moving away from a manually edited word processing document format. This represents an incredible amount of work that has produced a considerable amount of value for the FIX user community.

Part of the restructuring included the creation of infrastructure that can automatically update the online specification, MSWord, and PDF formats of the specification with each new Extension Pack. This approach makes each enhancement to FIX Latest available to the FIX Community immediately after approval. Firms that adopt the FIX Latest branding can immediately use any of the new functionality without requiring a version change.

The first publication of the online specification (aka baseline) was made in December 2019. It was limited to the specification as defined by FIX 5.0 SP2 back in 2009, which included the first 97 Extension Packs. Whilst the content had not changed much compared to the original Volumes 3 (Pre-Trade), 4 (Trade), and 5 (Post-Trade), the generation and presentation of it had been fundamentally changed. The key difference was that a single source format (markdown) was used, from which multiple other formats (e.g. docx, html) are automatically generated with minimal manual handling effort (see below for further details). This allowed to post the specification in an interactive format to the FIX website and also provide documents for download.

The second publication in February of this year was an update to the baseline in terms of the presentation of the content, i.e. it still only provided the first 97 Extension Packs. However, the update contained component descriptions previously only available in FIXimate. It also provided images for the message structure, i.e. visualizing each message with its first level components. Navigational capabilities were enhanced to make it easier to move around across sections of the specification, both for the online format as well as for the downloadable documents.

The primary objective of this third publication has been the addition of the remaining content from the 160 Extension Packs released after FIX 5.0 SP2. This includes almost 50 new FIX messages across all areas, for example:

• Parties Reference Data
• Entitlements
• Risk Limits
• Position Transfers
• Margin Requirements
• Market Data Statistics
• Mass Orders
• Pay Management

The number of FIX fields has quadrupled from around 1500 to now almost 6000 fields. More than 3000 of these fields were added to the instrument components (includes instrument legs and underlyings) to support OTC derivative instruments, driven by the need for regulatory reporting to the CFTC in the US. The CFTC accepts FIX application messages using the FIXML encoding.

FIX Latest

FIX Latest is the most current version of FIX that supports multiple asset classes and a wide range of trading life cycle business processes. It includes all extensions and hence mitigates versioning complexities that have slowed the adoption of years of innovation and standardization of electronic trading flows.

With the introduction of FIX Latest, firms no longer need to be tied to a specific version of FIX. The FIX Community  is encouraged to adopt the FIX Latest application layer messages for use over the primary FIX session layer profiles FIX4 (8=FIX.4.4) and  FIXT(8=FIXT.1.1)). When an Extension Pack is approved for inclusion in the FIX standard, it can be integrated into the firm’s existing infrastructure readily, as it becomes the new FIX Latest application version. The FIX Trading Community has invested member funds into the creation of infrastructure to update and publish the online and document versions of the FIX application standard immediately following the approval of an Extension Pack. The standard is available online, as a machine-readable repository, and as a traditional downloadable document.

Behind the scenes…

The following is for those of you that are interested to know a little bit more about the approach taken by the GTC and the technologies used to automate the generation of the online spec. The approach has proven to be highly efficient and can also be applied by the FIX Trading Community to their environments whenever there are specification documents, for example rules of engagement documents for FIX interfaces. The GTC would welcome an increase in the degree of automation throughout the industry.

A fundamental design issue was to separate content from its rendering and we decided to use markdown as input format. There are many flavors of markdown and we tried to be as simple and “standard” as possible by choosing GitHub Flavored Markdown. This also has the advantage of GitHub being able to natively render repository content that is written in markdown.

This leads to the second fundamental decision, i.e. to treat the specification like source code and use a repository with all of its great features for collaboration and keeping track of who changed what, when and why. It allows to use tags to create releases of a specification, starting with a version for internal review all the way to the version for publication.

The third major decision was to use open source tools to the extent possible and to develop our own tools only where absolutely necessary. The main tool used for the transformation of the markdown content to other formats is Pandoc, a universal document converter. Pandoc was initially used to transform the existing FIX 5.0 SP2 specification from Microsoft Word (docx) to a markdown format.

Pandoc is able to use a so-called reference file (a.k.a. style file) when generating a Microsoft Word (docx) file from markdown. This reference file is a Microsoft Word (docx) file containing the styles to be used to format the markdown content. It is key to the look and feel of the resulting document and represents an important asset developed by the GTC for the FIX Trading Community. It guarantees a consistent formatting throughout the document, including the title page, table of contents and page headers and footers. The same style file is used for all application layer specification documents. The look and feel of the corresponding online versions is defined by the standard CSS (Cascading Style Sheet) of the main FIX website. It was slightly enhanced, for example to support syntax highlighting for code snippets.

Another important tool is PlantUML, an extremely powerful tool we will be using more and more for various kinds of images. It is currently being used to visualize the structure of global components in the introduction area. We have previously used it extensively for the sequence diagrams in the refactored version of the FIX Session Layer standard.

We are also using the stream editor SED, for example to replace document-internal references with URLs for the online version. We had to develop our own tool orchestra2doc to extract FIX messages, components, and fields from FIX Orchestra and generate html files for the specification appendices containing the detailed message and component layouts. Pandoc is used to transform the html files into markdown in order to use them as input for the document version of the specification, ultimately offered as a set of PDF files for download.

What’s next?

The current version of the online specification contains detailed information related to messages and components. Some of the business areas already contain more general and conceptual information specific to a business process. This will be further extended with the concepts introduced by some of the Extension Packs. There is also more refactoring work to do, for example to extract the concept of message fragmentation that is currently described more than once in the context of different messages. It is planned to introduce dedicated chapters for concepts at the beginning of each business area (pre-trade, trade, post-trade) that will only make references to messages and/or components.

The new approach for technical specifications will also be taken for the documentation of the FIX Technical Standards, i.e. to transition to markdown and to offer an online version in addition to a document for download. There is already a separate style file that will be used for the formatting and layout of all FIX Technical Standards, i.e. they will be provided in an online version later this year. The first refactoring of the FIX Technical Standards was completed for the FIX TagValue Encoding and the FIX Session Layer standard. Migration of the remaining standards is underway.

FIX Orchestra is quickly becoming the key component of any FIX infrastructure. It can be used to generate not only documentation but also encoding schemas (e.g. FIXML, SBE, JSON) or dictionaries such as QuickFIX. The GTC has created a number of public repositories in GitHub related to the development of tools for FIX Orchestra. One of them is Tablature that contains tools to convert between markdown and FIX Orchestra XML files (and vice versa). The GTC plans to use it to automatically update content stored in FIX Orchestra. We see Tablature as a key enabling approach for creating rules of engagement in a simple usable manner for the entire industry.

The tools are part of the activities of the FIX Orchestra Working Group, discussing requirements and proposals.  For example, the markdown format of Tablature serves as an easy authoring format shielding from the complexities of FIX Orchestra. On the other hand, the powerful and rich feature set of the FIX Orchestra standard (scenarios, workflows, state changes etc.) is a huge benefit for the automation of software development and testing related to interfaces (not just FIX). The working group is always looking for volunteers to drive forward the development of useful tools around FIX Orchestra.

We welcome any feedback from the FIX Trading Community and have added a thread to the FIX discussion forum to engage with you on your thoughts and ideas.

Hanno Klein, GTC Co-chair EMEA
Jim Northey, GTC Co-chair Americas
Daniel Shek, GTC Co-chair Asia Pacific

London, New York, Hong Kong March 13, 2018: FIX Trading Community, the non-profit, industry-driven standards body at the heart of global financial trading, today announced the publication of Release Candidate 3 for FIX Orchestra for public review, to help the industry move further towards standardisation and automation of rules of engagement and deliver major efficiencies to the counterparty onboarding process. This enables firms to define their service offerings in an entirely systematic way, allowing them to certify their flows faster and with greater accuracy, while significantly reducing the need for manual intervention.

FIX Orchestra was conceived as machine readable rules of engagement between counterparties. As such, it is a standard for the exchange of metadata about the behaviour of FIX applications that will allow adopters of not only FIX, but any messaging protocol, to describe their service offering. The ultimate goal of FIX Orchestra is to bring the capability of “Plug and Play” into the FIX ecosystem following the evolution of computer systems over the past twenty years in order to greatly improve operational efficiency and reduce the time to trading for the FIX Community. The simplest use of FIX Orchestra will be to create an unambiguous specification for a service offering, replacing the ubiquitous PDF and Word documents that are not actionable. In its most extreme adoption level, FIX Orchestra can be used to automate the entire process of onboarding, normalizing, and validating disparate counterparty implementations.

As of Release Candidate 3, FIX Orchestra will be used as the basis for the re-engineering of the FIX Repository maintenance and publication system in 2018. By the end of 2018, all best practice documents will include a FIX Orchestra service definition. Independent Software Vendors, managed network providers, and bespoke implementations are encouraged to enhance their systems to consume FIX Orchestra service definitions.

Nirav Shah, Senior Vice President, Testing Tools Engineering, Itiviti, noted, “At Itiviti, we are closely involved in the area of standardisation and automation of Rules of Engagement. We are closely observing the progress of FIX Orchestra and evaluating how our platforms can consume FIX Orchestra files for automation of testing using an unambiguous specification of a service offering.”  
Damian Bierman, “Head of Asia-Pacific, Portfolio Management & Trading Solutions, FactSet,  Co-chair Global Technical Committee, FIX Trading Community, commented, “FIX Orchestra delivers major efficiencies to the counterparty onboarding process, and promises to bring benefits to the entire industry. Firms who adopt Orchestra will, for the first time, be able to define their service offerings in an entirely systematic way, allowing them to certify their flows faster and with greater accuracy, while significantly reducing the need for manual intervention. Ultimately, firms on Orchestra will be able to start trading faster, with greater ease and at lower cost than ever before. In that regard, FIX Orchestra represents one of the most exciting initiatives coming out of the FIX Trading Community today and proves yet again that the spirit of innovation within the community is alive and well, and focused, now as ever, on delivering solutions which are highly relevant to the challenges of the industry.”

The next steps with this initiative will be to work with firms to get early adoption to drive and mature the standard.

– ENDS –

About FIX Trading Community
FIX Trading Community is the non-profit, industry-driven standards body at the heart of global trading.
The organisation is independent and neutral, dedicated to addressing real business and regulatory issues impacting multi-asset trading in global markets through standardisation, delivering operational efficiency, increased transparency, and reduced costs and risks for all market participants. Central to FIX Trading Community’s work is the continuous development and promotion of the FIX family of standards, including the core FIX Protocol messaging language, which has revolutionised the trading environment and has successfully become the way the world trades.  Visit www.fixtradingcommunity.org for more information.

Contact:
Tim Healy
FIX Trading Community
Tel: +44 (0)203 440 5962
Tim.Healy@fixtrading.org

Courtney Doyle McGuinn
FIX Trading Community
Tel: + 1 212 655 2944
courtney.mcguinn@fixtrading.org

Media contacts:
Abby Munson/Lindsay Clarke
Streets Consulting
Tel: +44 20 7959 2235
Email: Abby.Munson@Streetsconsulting.com
Email: Lindsay.Clarke@Streetsconsulting.com

Anyone that has worked with the FIX Protocol will appreciate that, whilst it is a technical protocol, the human interaction in configuration, testing and certification of a FIX connection is absolutely vital. The protocol itself was borne out of a business need over 20 years ago by traders and technologists with an explicit requirement to make communication between investment firms more efficient, thus reducing errors. Over 20 years later the FIX Protocol is the de-facto messaging protocol for the way the world trades today across all asset classes.

There are many thousands of FIX connections between buyside, sellside, vendors and exchanges. For each FIX connection between these counterparties, there is a time and a cost to market involving people, potentially across different time zones, exchanging FIX specifications. Once exchanged, calls will be scheduled between parties to run through different scenarios, and based on these calls and interpretation of these specifications, configuration work will be effected. 20 years on from the original FIX connections and the same onboarding processes are still being used.
FIX Trading Community has always looked at ways to create more efficient processes across a number of workflows, and FIX Orchestra is the latest of these important initiatives. As John Greenan, CEO Alignment Systems and one of the creators of Orchestra describes it: “Orchestra is the full stop at the end of FIX. Risks and costs can be cut and time to market and efficiency improved.”

What is FIX Orchestra?
Put simply, FIX Orchestra is a standard for implementing machine-readable rules of engagement. Counterparties can exchange their Orchestra files, either statically or dynamically through network interfaces, then automatically compare their files and discover where there are differences and restrictions. Following this process, configuration of FIX engines, generation of application configuration and code, test case creation and sample messages can be created without human intervention. In effect, a whole testing lifecycle can be undertaken quickly and in an efficient, cost-effective manner. This will resonate with the original demands behind the FIX Protocol itself and the continued need to be cost conscious in a tight margin environment.

What is the business case?
How can a firm take advantage of this? A CTO is charged with effectively holding, developing, articulating and continually to evolve the company’s strategic technical direction. The CTO is responsible for making sure a company continues to have the best technology offering in a dynamically-evolving highly-competitive space. A space where FIX is an integral and vital component. It’s a challenging role. Well, it’s important to note that, for a business, no changes will need to be made to a company’s FIX engine which will lessen the financial impact. FIX Orchestra is metadata about a specific implementation of FIX. The benefits for a business will be derived from the cost-savings and efficiencies that allow your company to set up FIX connections promptly and with less manual human intervention – a quicker set-up and with significantly reduced opportunities for errors.

Eugene Budovsky, Director, Autobahn Equity, Deutsche Bank AG, Australia & New Zealand, commented, “A key challenge for my business is rolling out new capabilities to client front-ends, in particular the upgrading of algo tickets. My clients use a large variety of vendor systems, and while the FIX Algorithmic Trading Definition Language (FIXatdl), for specifying algorithmic trading user interfaces, goes some way towards simplifying the process, there is invariably a large number of people (and associated cost) involved in the process. The task can be so daunting that sales people are often discouraged from offering ticket upgrades to clients, and multi-vendor global ticket upgrades are a massive undertaking. FIX Orchestra has the potential to automate these types of processes, and I am eager to see it deliver as it would significantly improve my ability to roll new offerings out to clients.”

Jim Northey of Itiviti, and one of FIX’s Global Technical Committee Co-chairs observes that “The strength of FIX is its flexibility and versatility, which was vital to its success and widespread adoption. The weakness of FIX is the variance across usage. Let’s face it, as one of the most successful industry standards in finance, FIX has some of the worst written specifications. What FIX Orchestra does is to create a formal specification mechanism for FIX. As the FIX community begins to enhance their systems to automatically consume FIX Orchestra files, and as we in the FIX Global Technical Committee start to publish FIX Orchestra files for each best practice, we will start to see the main drawback, variability across service offering, become one of our strengths and values.”
Brandon DeCoster of FIX Flyer commented: “Today, we write PDF documents. Then humans read them, (mis)interpret them, implement them, and test them: all by hand. The future is defining Rules of Engagement. Period. Technology will generate the PDFs, the translations, the integrations, the tests, the certifications. The Rules of Engagement will be the authoritative source, the PDF an artifact.”

Diving into the details
FIX Orchestra Release Candidate 1 is available today. FIX Orchestra is not so much something new as it is a significant evolution of the FIX Unified Repository, that has been adopted by a few major market participants to manage their specifications, in addition to being the basis for automated generation of FIXimate and the FIX specification. Release Candidate 1 permits much more than the definition of the fields, messages, components, and enumeration (code values). If this were all that Orchestra provided, there would be little value over what is available today. FIX Orchestra moves beyond just message definition, to permit specification of scenarios, which is a specific usage of a message. A single FIX message is used for many purposes. The Execution Report is an Ord Ack, Fill notification, Partial-Fill, done for day, order status. With Orchestra, you can define each of these scenarios and define the context in which each scenario will occur via FIX Orchestra’s ability to model, in a formal way, system state. For instance, you can model the state of an OMS or an execution venue and specify the response to various states.

Not just for tag-value FIX
Adopters of FIX Orchestra can do as little as create a machine-readable inventory of their message formats. Or ambitious service providers, who see the full value of automation, can integrate FIX Orchestra within the core of their gateways, order routers, order management systems, and execution management systems. As we live in a world where most venues now provide proprietary interfaces in addition to FIX, and as FIX now has seven different message encoding formats, and multiple FIX session layers, it was important that FIX Orchestra did not support FIX tag-value only. In fact, an early version of FIX Orchestra was used within the Association of National Numbering Agencies (ANNA) Derivative Service Bureau project and used to generate Javascript Object Notation (JSON) Schemas.

Next steps
The development of Release Candidate 2 is underway. Included in Release Candidate 2 is an expression language for specifying context and conditional rules. The use of a domain specific language was selected to improve readability and usability versus arcane and difficult to read XML based rule languages. The grammar for the FIX Orchestra expression language is maintained by the FIX Trading Community and is available under Apache 2.0 license via GitHub. Release Candidate 2 will also include support for FIXatdl to address a common issue faced by broker-dealers and their customers, the inability to manage FIXatdl definitions with their service offerings.

Integration with global standards
Members of the FIX community are participating in creating the next version of the ISO 20022 standard. The capabilities being defined within FIX Orchestra are being included in the work for ISO 20022. This integration is essential for the future of the FIX Protocol.

Getting involved
Sufficient functionality exists now within Release Candidate 1 that vendors and bespoke implementers should be adopting and using the standard now. What is needed now are early adopters who will be rewarded by being able to drive and mature the standard. Please join us.