QuickFIX/Go implements FIX sessions for Go, and lets you generate your own dictionaries

A FIX engine, not a message parser

QuickFIX/Go is an open source FIX Protocol library implemented in Go, and it is a FIX Protocol Community implementation for the Go programming language.

The distinction between an engine and a parser is the whole design. A parser takes bytes and gives you fields. An engine runs a session, which means it negotiates a connection, exchanges logon and logout messages, sequences every message, detects gaps, resends what was missed, and keeps the state of a conversation with a counterparty over hours or days. That state machine is what the repository files show: an acceptor.go and an initiator.go, a logon_state.go, a logout_state.go, a latent_state.go and an in_session.go, alongside a connection.go and a dialer.go.

The feature list backs this up. Failover and high availability are listed, as is daily and weekly scheduling of session connections, and the storage options are given as SQL, MongoDB, on-disk or in-memory. Logging goes to file or screen. SSL communication is integrated, protocol customizations are supported, and there are automated unit and acceptance tests.

The library targets FIX versions 4.0 through 5.0 SP2. The README notes that it runs on any hardware and operating system supported by Go, and that Go 1.21 or later is required, while the module file itself declares go 1.23, so the effective floor for building from source is the newer of the two.

The audience is a firm writing a Go service that talks FIX to a broker or another institution. The repository also notes that commercial support is available through Connamara, the company that sponsors the CI.

Message validation is driven by the dictionary, not by hand

The claim that matters for correctness is spec driven run-time message validation. FIX messages are validated against a data dictionary that declares every field, its type, its position and the messages and components that use it. A message that violates the dictionary is rejected by the engine rather than by hand-written checks scattered through your application code.

The type-safe side of this comes from code generation. The README states that QuickFIX/Go maintains separate packages for tags, fields, enums, messages and message components, auto-generated from the FIX 4.0 to FIX 5.0 SP2 XML specifications. Each FIX version has its own package in the QuickFIX/Go organisation, from fix40 through fix42, fix43, fix44, fix50, fix50sp1, fix50sp2, plus fixt11 for the FIX Trading session layer, and separate tag, field and enum packages shared across them.

So there are two ways to get typed messages. For most FIX applications, the generated resources are sufficient, and you import the package for the FIX version your counterparty speaks. For a custom application, you can generate source specific to that application's FIX specification using the generate-fix tool included with the library.

That second path is the one that matters for firms that have negotiated custom tags with a counterparty, and it is also where the repository puts real effort. The generated code is identified by the .generated.go suffix, and the rule the README states is strict: any changes to generated code must be captured by changes to the code generator source in cmd/generate-fix, followed by regenerating. Editing a .generated.go file directly is not a supported workflow.

The generated packages live in separate repositories under the QuickFIX/Go organisation, with the source specifications in spec/, which means the dictionaries are versioned independently of the engine.

Installing it, and building the generated code

With Go module support, the install is an import line in your code:

import "github.com/quickfixgo/quickfix"

and then go build, go run or go test fetches the necessary dependencies automatically. The README also gives the older route for projects not on modules:

go get -u github.com/quickfixgo/quickfix

The generator is installed alongside the library, to $GOPATH/bin/generate-fix, and the README points at running $GOPATH/bin/generate-fix --help for the usage instructions. Because it lands on your GOPATH bin rather than being run through go run, a first-time user on a machine with an unusual GOPATH can end up looking in the wrong place for it.

For contributors the requirements are stated plainly: you need Docker and VS Code on your machine, you clone the repo and open it with VS Code with Docker running, and the repository comes with dev container configs in ./.devcontainer/. The pop-up offers to reopen the project in the dev container, which opens it in a container pre-configured with everything needed.

The build itself is a make target. The default target runs go vet and the unit tests:

make

and the README says that if this exits with status 0, then everything is working. There is a separate make generate for regenerating the source, and a make lint target that installs golangci-lint at a pinned version if it is not already present.

The acceptance tests are driven from the Makefile too, with per-version targets such as fix40 and fix41 that run a test configuration against a locally built echo server, and the store type and test set are selected through the STORE_TYPE and ACCEPTANCE_SET variables, defaulting to memory and server respectively.

What v0.9.0 broke, and why the version number matters

The README opens with an unusual priority: a link to the v0.9.0 release notes, placed there specifically for people looking for help with MessageStore syntax changes. A library that leads with its own breaking change is telling you something.

The MessageStore is the persistence interface for session state, and changing how it is configured or implemented is the kind of edit that touches every deployment at once. The project was careful enough about this to make it the first thing a reader sees.

The version history reinforces the point. The recent releases are v0.9.12 on 2026-09-30, v0.9.11 on 2026-09-14 and v0.9.10 on 2025-08-08, and the last push to the repository was on 2026-09-30, the same day as the newest patch. The library has been on the 0.9 line for a long time, with patch releases arriving in bursts, and v0.9.0 is the release that changed the MessageStore syntax under it.

For an adopter, that history sets expectations. A 0.x library is one where the maintainers do not consider breaking changes off limits, and the MessageStore change shows they exercise that freedom. The corollary is that upgrades need reading rather than automating, and the CHANGELOG.md in the repository root is the document to read.

The other operational note is about the acceptance tests. The Makefile's test target runs against a MongoDB connection string, MONGODB_TEST_CXN=mongodb://db:27017, which points at the container in the dev container setup. Running the full suite outside that environment means providing a reachable MongoDB or overriding the store type, and the default STORE is memory, so the common path is the one that does not need a database.

Where the library stops

The limits are structural and they follow from what a FIX session is.

The first is that QuickFIX/Go is a session engine, so you inherit session semantics whether you want them or not. It runs an acceptor or an initiator, it manages logon and logout, it sequences and resends, and it has a configuration file format that drives all of that. A service that only needs to decode an occasional message from a file or a socket has bought a great deal of machinery for the job, and the alternative of using the generated field and message packages on their own, without an engine, is a considerably lighter path.

The second limit is that the protocol is old and the market around it is conservative. FIX 4.0 to 5.0 SP2 and FIXT 1.1 cover the range, but a counterparty on a proprietary extension still needs custom dictionaries and a generation step, and that step is a build-time dependency you own.

The third is support. The README directs questions to the GitHub Discussions board, which it calls the preferred method of user support from the QuickFIX/Go team, and asks for configurations and code snippets with each question. It also asks people not to file questions in the issues list. For a library in the order-routing path of a trading firm, the commercial support option matters, and the README notes that Connamara offers it in ten-hour bundles with access to the team that created QuickFIX/Go and QuickFIX/n.

The fourth is quieter but real: there is no version 1.0. The library has been in place long enough to be trusted with a session and young enough that its API can still move under you.

Licence terms and the shape of the dependency tree

The licence field on the repository carries a custom classification that GitHub cannot map to a standard identifier, and the terms themselves are in the LICENSE file at the root. The README describes the project as free and open source with a liberal licence and links that file, so the practical route is to read the file rather than to rely on the field.

Whatever the exact terms turn out to be, they are worth reading carefully for a library that sits in a trading system's network path, because the dependency list tells you how much third-party code runs inside your process. The module file names a small set of direct dependencies: the SQLite driver mattn/go-sqlite3, a PROXY protocol library pires/go-proxyproto, the errors package pkg/errors, two decimal libraries, quagmt/udecimal and shopspring/decimal, the testify test framework, the official MongoDB driver, and golang.org/x/net. The indirect list brings in the MongoDB driver's own transitive dependencies, the compression library, the crypto and text packages and the YAML parser.

Two of those deserve a note. The presence of two decimal libraries is the result of a decision to offer a decimal type built on udecimal alongside the widely used shopspring/decimal, which the Makefile reflects with a second generate target that runs the generator with -use-udecimal=true. And the PROXY protocol library matters for a networking component, because a FIX engine behind a load balancer is exactly the deployment where PROXY protocol information is needed.

The dependency set is modest for what the library does, and the generated-code split keeps the bulk of the FIX vocabulary out of the core module. That is a sensible shape: the engine is small and reviewable, and the dictionaries are generated artefacts you can read but rarely need to change.

Editorial conclusion

QuickFIX/Go suits a Go team that has to speak FIX to a counterparty and wants session handling, message validation and type-safe generated messages rather than hand-rolled field encoding, and that is prepared to run its own dictionary generator. It is the wrong tool for a team that only needs to parse a few messages, because the session state machine, the acceptor and initiator roles and the configuration file are all part of the deal, and it is the wrong tool for a codebase that cannot absorb a 0.x library with a history of API breaks. Before you adopt it, read the v0.9.0 release notes about the MessageStore syntax change, generate your own dictionaries with the generate-fix tool if your counterparty uses custom tags, and read the LICENSE file at the repository root, since the licence field carries a custom classification.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. quickfixgo/quickfix on GitHub
4. README
5. Releases