Hi,
Apologies for what may seem a naive question, but I’m seeking very basic general guidance.
We provide implementations of FIX versions from 4.0 up to 5.0 SP2.
We recently received a request to “implement EP118”.
We have not previously paid much attention to Extension Packs as we had been given to understand they represented specialised extensions for specific usage not necessarily employed by all parties.
However a re-reading of some of the materials here suggests they are in fact cumulative additions to the base standard.
So I’m looking for a definitive statement of how EPs should be treated.
Are they mandated as part of the ‘core’ standard, or are they optional?
If mandated, how is one expected to manage situations where party A is on, say 5.0 SP2 extension pack X, and party B is on 5.0 SP2 extension pack Y - or will there always be compatibility?
Is the latest EP de facto the definitive latest version of the standard?
All guidance gratefully received.
Many thanks
Steve
I’ve always regarded them as cumulative, so the latest version is latest FIX version plus all the extension packs.
Thanks for raising the question as there seems to be a misunderstanding of the role of Extension Packs aka EPs. After FIX 4.4 FIX internally used EPs for incremental updates. These EPs were bundled into newer versions from time to time, resulting in FIX 5.0, FIX 5.0 Service Pack 1 (aka SP1) and FIX 5.0 SP2. FIX then moved to external/public EPs. That is why the EP page (https://www.fixtrading.org/extension-packs/) starts with EP98 and not with EP1. The FIX community should no longer have to wait for an extension to get bundled into the next FIX version before officially being able to use it.
Not too long ago FIX decided to avoid the notion of versions going forward and to limit the supported versions to FIX 4.2, FIX 4.4 and FIX 5.0 SP2 with EPs. It is common practice for counterparties to agree on a specific subset of the available FIX messages, fields and valid values. Even if two parties were to use FIX 4.2, they would not support its entirety but focus on the business requirements and document the supported subset in a Rules of Engagement document. So there was never a mandate to support all or nothing on the application layer. The session layer is a different story but I don’t think that is what you are concerned with.
EPs are cumulative as you say, i.e. the latest EP includes all previous EPs and FIX does not break backward compatibility. The FIX Repository published with each EP is complete and not limited to the actual extensions made with the EP. Hence FIX has adopted the term “FIX Latest” as the most recent “version” if you will. Obviously and intentionally, it is a moving target.
If you do not use FIX Latest but a legacy version, you are still allowed to use FIX messages, fields and valid values from higher versions or EPs. This is subject to bilateral agreement and was done to avoid usage of user-defined fields wherever possible as it reduces the degree of standardisation. FIX recommends to always use FIX Latest in order to have the richest feature set available to express a given functionality.
1 Like
Thank you for a very detailed and useful answer. That makes the situation I am currently looking at much clearer, and is extremely useful.
1 Like
Forgot to comment on the fact that you are requested to implement EP118. I was personally involved in its development back in 2011 and it is a fairly complex but powerful extension. Feel free to open up additional threads to seek clarification on the underlying concepts of the allocation workflows.