QuickFIX Support

Connamara is a co-originator of the open-source project QuickFIX and an official maintainer of the project. We offer a broad range of support and integration services around QuickFIX and all flavors of FIX. Connamara Systems has been involved with QuickFIX since the earliest days of the original C++ project in late 2001 — learn more about our history with QuickFIX.

Connamara provides services to enhance the core QuickFIX project to include new functionality. We also provide design and implementation services for applications that embed the QuickFIX library. These applications fall into five distinct categories:

As a maintainer, contributor, and host to QuickFIX we are well aware of the power of a ‘free’ open source product – but some implementations require more support and assurance than what the open source community can offer. To provide for this need, Connamara offers professional development and commercial support which allows our clients to benefit from this great library but also have the confidence that comes with an enterprise package.

Below are our descriptions of various support Tiers.  Please contact us for more information.

All services include support for:

  • General questions regarding QuickFIX development
  • QuickFIX best practices
  • General questions about FIX Protocol
  • Sample code
  • Code reviews
  • Problem investigation and identification

Silver

Response Time

Regular Business Hours

Developer Question: 1 Business Day

Minor Prod Issue: 4 hours

Major Prod Issue: 2 hours

Non-Regular Business Hours

Developer Question: 1 Business Day

Minor Prod Issue: Next Business Day

Major Prod Issue: 6 hours

Gold

Response Time

Regular Business Hours

Developer Question: 1 Business Day

Minor Prod Issue: 1 hours

Major Prod Issue: 30 minutes

Non-Regular Business Hours

Developer Question: 1 Business Day

Minor Prod Issue: Next Business Day

Major Prod Issue: 4 hours

Platinum

Response Time

Regular Business Hours

Developer Question: 1 Business Day

Minor Prod Issue: 1 hours

Major Prod Issue: 30 minutes

Non-Regular Business Hours

Developer Question: 1 Business Day

Minor Prod Issue: 2 hours

Major Prod Issue: 1 hours

 

Contact us for support or fix development pricing

  • QuickFIX Functionality Enhancements

 Clients can engage Connamara to enhance the core QuickFIX project to include  new functionality. Connamara will evaluate these requests to determine if the  enhancement should be included in the core QuickFIX project or if it is better  maintained outside of the project. If the enhancement is eligible for inclusion in  the core QuickFIX project, Connamara will always recommend that the client  contribute the enhancement. This ensures that the QuickFIX Community will maintain the enhancement possibly improve the enhanced functionality going  forward.  

  • QuickFIX Application Development

 Connamara provides design and implementation services of applications that embed  the QuickFIX library. Typically, these applications fall into five distinct categories.

    1. Dropcopy Adapters

  A FIX Dropcopy Adapter is used to connect a client system to an exchange or counterparty for the purpose of receiving details of trades that have been executed  on the exchange in the name of the client. Typically, the client system will use the  trade reports for some downstream process like post-trade risk management or  position reconciliation.  The primary function of a Dropcopy Adapter is to translate the exchange trade  reports  from the FIX protocol to the internal messaging format of the client system. The Dropcopy Adapter may also provide instrument symbology and price format  translation services.

The FIX application message set that a Dropcopy Adapter needs to handle is typically limited to only either FIX Execution Reports or Trade Capture Report messages. The Dropcopy Adapter will also need to handle the typical FIX messages associated with FIX session management; logon/logoff, gap fill, business reject, heartbeat, etc. There may be the occasion where the Dropcopy Adapter will need to support Security Definition Request workflows. This, however, would be an atypical implementation.

 The client may require the Dropcopy Adapter to be highly available and have the ability to failover to a backup instance. Performance requirements for a Dropcopy adapter are typically not an issue since the message flow is that of trades and not orders. However, there are exchanges, e.g. CME that send all state changes for an order over the dropcopy feed. In this case, performance and scale will need to be considered. The other performance consideration would be the number of accounts that the Dropcopy Session would be covering. For example, the number of trades for the entire customer base of an FCM would be much greater than for that of a small proprietary trading firm.

    1. Market Data Adapters

A FIX Market Data Adapter manages the connection to a market data service (exchange or third party market data provider), subscribes to a set of instruments on the exchange for the purpose of receiving real-time updates of market data. The market data received by the adapter may be top-of-book, trades, depth-of-market, or market status updates. Or possibly all four. It translates and normalizes those messages so that the market data information can be consumed by the client system. On the surface this seems very straightforward. The complexity and risk occurs in three areas; symbology and price format normalization, message throughput considerations, and subscription management. Depending on the client system there may be availability and recoverability requirements. Depending on the market data service implementation, there may be a requirement for out of band recovery of missed messages in the case of a message gap.

    1. Order Routing Adapters

A FIX Order Routing Adapter connects a client order source (OMS, EMS, Algo Trading Platform)  to an execution venue or broker for the purpose of submitting orders to buy or sell a tradable instrument. A FIX order routing adapter will translate the order messages from the client order source protocol to the venue/counterparty specific version/flavor of FIX. A FIX order adapter will comply with the venue/counterparty’s rules of engagement and expect to receive from the venue/counterparty order state changes. The order state changes will include order statuses and reports of fills against the submitted orders.

There is probably a requirement to translate/normalize symbology and price formats on the messages to and from the venue/counterparty. Additionally, there may be account number mappings, order ID format considerations, and trader identification requirements to consider. Depending upon the specific use case for the adapter, there may be availability and throughput requirements for the adapter.

When considering the FIX message set to be supported, it is important to look at the functionality that the client system wants to access at the venue/counterparty. For example, if the client is not going use a certain functionality (user defined spreads), then the project scope may be able to be limited to only the the functionality that the client needs; thus, reducing the cost and time to market for the client.

Most likely, there will be a “certification” requirement imposed by the venue/counterparty. This requires that the adapter must demonstrate compliance to the exchange/venue FIX specification.

    1. FIX to Storage Application

A FIX to Storage project connects a target system to a data store at the client site. 

This project is similar to a FIX Dropcopy project and the FIX to FIX projects. Inbound FIX messages from the target system are translated and normalized; however, in this case the outbound information is stored in a client database rather than being translated to another version of FIX or converted to another serialization protocol.

Similar to the FIX to FIX project, there may be a symbology and price format translation. And, similar to the FIX Dropcopy project the message flow is one direction; from target system to client system.

Scalability and throughput may be a consideration of this type of project and is dependent upon the types of messages to be saved. In the case where a client would like to save market data (prices) from and exchange for replay or analysis, then scale and throughput must be considered. If the client is only storing their own trade reports or possibility order flow, then scale and throughput requirements will not be as stringent.

    1. FIX to FIX Translators

A FIX to FIX project connects a client system to another system via a FIX interface. Typically there is translation between FIX versions and “flavors”.

This project is similar to a FIX Dropcopy project. Inbound FIX messages are translated and normalized; however, in this case the outbound message is another version/flavor of FIX.

A FIX to FIX project will almost always be a requirement for symbology and price translation/normalization. There may be an added requirement for other mappings like account numbers and order IDs . While on the surface a FIX to FIX project may seem straightforward, e.g. FIX 4.2 in and FIX 4.4 out, the requirement for other mappings and translations where the complexity and risk lie.

Another difference from FIX Dropcopy or FIX to Storage applications is that the message flow is typically bidirectional between the systems and many more FIX message types will be required to be supported.

QuickFIX was created in 2001 by Oren Miller while working at Thoughtworks as an open source implementation of the FIX Protocol as specified by the FIX Trading Community (formerly FIX Protocol Organization). The original version was written in C++. The acceptance was so pervasive from the FIX community that Java, .NET, and golang implementations followed.
Connamara Systems has been involved with QuickFIX since the earliest days of the original C++ project in late 2001. Since that time Connamara has continued to be involved with the project as a maintainer and contributor, and as of 2010, the host of the cross-platform build servers and automated build platform. Connamara is also a contributor to the Java version QuickFIX/J.

In November of 2011, Connamara released a version of QuickFIX, QuickFIX/N, written using C# and the Microsoft .NET Framework. With this release, Connamara has made available to the QuickFIX community the option to implement a FIX solution in the three main languages used in the financial systems development.
In August of 2014,the FIX Trading Community, awarded Connamara Systems and founder, Jim Downs, recognition for the QuickFix Open Source Project’s positive impact in the global trading community and FIX standard adaptation on the FIX Trading Community’s 20th Anniversary. Since QuickFIX’s launch in 2002 it is estimated that there have been just shy of 1 Million downloads. This number includes QuickFIX’s other FIX versions for Java and for .NET.
Connamara offers clients support and integration services around all flavors of QuickFIX.

Created By Oren Miller – Support By Connamara