Tradeoffs in Implementing a FAST Protocol Engine from Scratch

Summary

The document considers whether a developer with an existing FIX engine should implement a FAST protocol engine from scratch. The only answer advises against building a custom implementation, arguing that established commercial libraries have been tested and that development effort is compounded by ongoing maintenance and testing costs. It also raises FPGA adoption as a possible factor affecting the long-term value of software libraries.

This is a brief opinion rather than a technical guide. It does not explain FAST’s encoding, its relationship to FIX, or how to implement or validate a decoder. The recommendation is based on the respondent’s personal preference, with no comparison of library performance, costs, or failure rates. It is useful as a reminder to account for maintenance and testing when evaluating protocol infrastructure, but readers must seek other sources for protocol details and should assess their own latency, hardware, and licensing requirements.

Key ideas

• A custom FAST implementation entails ongoing testing and maintenance in addition to initial development.
• The answer recommends considering established commercial libraries instead of building a protocol engine from scratch.
• It offers no technical explanation of FAST encoding or its relationship to FIX.
• The recommendation is personal and does not compare specific implementations or costs.

Tags

# Where can I find a guide to implement the FAST protocol from scratch having already a FIX implementation ready?


# Where can I find a guide to implement the FAST protocol from scratch having already a FIX implementation ready?












I need to implement a FAST engine from scratch without using any open source or commercial FAST implementations. The FAST spec does not help much so I am not sure from where to start. Have anyone done the same and would be able to point me in the right direction in order to successfully tackle this project?

I already have a FIX engine ready. Is FAST really just a compression scheme on top of regular fix messages?

Thanks!

## Answer by Ariel Silahian (score 1)

https://quant.stackexchange.com/a/29866

I wouldn't go that way at all. There are very good commercial libraries that are well tested. Personally I don't justify the effort and cost that will take you to do it from scratch. More over, think on the maintenance of that code, testing, etc.

And as final note, everybody is moving towards fpga... So that libraries will be worthless on that.

That's my personal preference. Hope helps

Shown in full with attribution under the source's licence. Licence: CC BY-SA 4.0 (Stack Exchange)

This summary was written by Stratmill's research agent from the original; it is not a copy of the source.