DEV Community: Pritesh

FIX Protocol in Real-World Trading Systems — Lessons from Bloomberg, Kraken, and 30+ Exchange Integrations

Pritesh — Thu, 21 May 2026 06:47:32 +0000

Sharing my experience as senior software engineer worked with 10 years in Bloomberg, Kraken and integrated most of the exchanges world wide

The Financial Information eXchange (FIX) protocol is one of the most widely used communication standards in global financial markets.

It powers:

Pre-trade communication
Trade execution
Post-trade workflows
Regulatory reporting
Order routing
Market data dissemination

According to QuickFIX, the open-source implementation of FIX:

“The Financial Information Exchange (FIX) Protocol is a message standard developed to facilitate the electronic exchange of information related to securities transactions.”

While that definition sounds straightforward, the scale at which FIX operates in modern electronic trading is massive.

Over the last 10 years working at Bloomberg and more than a year working with Kraken’s institutional trading infrastructure, I’ve worked extensively with FIX connectivity across more than 30 global exchanges and venues spanning:

Equities
Futures
Options
FX
Crypto
Multi-asset execution systems

This article explains:

Why FIX became the industry standard
How FIX messages are structured
How production trading systems actually parse FIX
How custom FIX tags are introduced
Lessons learned integrating dozens of exchanges
Why FIX still dominates despite newer protocols

The Pain Point FIX Solved

Before FIX became mainstream, trading workflows were heavily manual.

Orders were communicated through:

Phone calls
Emails
Proprietary terminals
Human brokers

This caused major operational problems:

Incorrect order routing
Traders placed on hold during volatile markets
Delayed executions
Human transcription errors
Lack of auditability

As electronic markets evolved, firms needed:

Standardized communication
Machine-readable protocols
Low-latency execution
Automated confirmations
Reliable session management

FIX solved this problem by creating a universal messaging standard between counterparties.

Today, almost every major financial institution supports FIX in some form.

Firms Driving FIX Adoption

The FIX Trading Community includes firms such as:

Bloomberg
Goldman Sachs
Citi
Bank of America
JP Morgan
Exchanges and ECNs globally

Initially designed for equities, FIX now powers:

Fixed income trading
FX trading
Derivatives
Crypto institutional execution
Clearing workflows

Even modern crypto venues expose FIX gateways for institutional clients because many hedge funds and execution algos already rely on FIX-native infrastructure.

At Kraken, for example, FIX connectivity is critical for institutional order flow where reliability and deterministic behavior matter more than retail-friendly APIs.

What Exactly Is a FIX Message?

At its core, FIX is just structured key-value messaging.

A FIX message consists of:

Header
Body
Trailer

Each field contains:

Tag
Value

Example:

8=FIX.4.4|35=D|55=AAPL|54=1|38=100|

Where:

8 → BeginString
35 → MsgType
55 → Symbol
54 → Side
38 → Quantity

In reality, the delimiter is a non-printable SOH character rather than "|".

Anatomy of a FIX Message

A typical FIX order message looks like this:

8=FIX.4.4
9=176
35=D
49=CLIENT1
56=EXCHANGE
34=215
52=20260521-12:01:01.001
11=ORD12345
55=BTCUSD
54=1
38=10
40=2
44=65000
59=0
10=128

Interpretation:

MsgType=D → New Order Single
Side=1 → Buy
OrdType=2 → Limit Order
Price=65000
Symbol=BTCUSD

The trailer checksum validates message integrity.

Real-World FIX Is Much More Complex

Most tutorials stop at simple examples.

Production FIX systems are significantly more complicated.

Over the years integrating 30+ exchanges, I encountered:

Exchange-specific FIX dialects
Vendor-specific extensions
Custom authentication flows
Proprietary risk tags
Non-standard sequencing behavior
Different heartbeat expectations
Unique session reset semantics

Even when two exchanges claim FIX 4.4 compliance, behavior can differ dramatically.

The protocol is standardized.
Implementations are not.

That is where most engineering complexity begins.

FIX Engines and Session Management

One of the most widely used FIX engines is QuickFIX.

A simplified Python FIX application interface looks like:

class Application(_object):
    def onCreate(self, sessionID): return
    def onLogon(self, sessionID): return
    def onLogout(self, sessionID): return
    def toAdmin(self, message, sessionID): return
    def toApp(self, message, sessionID): return
    def fromAdmin(self, message, sessionID): return
    def fromApp(self, message, sessionID): return

These callbacks handle:

Session lifecycle
Administrative messages
Application messages
Heartbeats
Resend requests
Sequence synchronization

FIX sessions are stateful.

This is one of the most important aspects new engineers often overlook.

Every session maintains:

Incoming sequence numbers
Outgoing sequence numbers
Heartbeat intervals
Replay state
Gap fills
Recovery flows

At Bloomberg, ensuring session resiliency during volatile market conditions was critical because even a temporary sequence mismatch could impact downstream order routing.

At Kraken, maintaining deterministic session behavior across crypto market volatility introduced another layer of operational complexity.

Why Low-Latency FIX Parsers Avoid String Splits

One major misconception is that FIX parsing is “simple”.

Technically yes.
Operationally no.

In high-frequency trading systems, performance matters enormously.

Naive implementations use:

message.split("|")

But low-latency trading systems avoid repeated string splitting because:

It creates allocations
Requires multiple passes
Increases CPU cache misses
Adds latency jitter

Instead, production-grade systems often use:

Single-pass byte parsers
Zero-copy parsing
Buffer reuse
SIMD optimizations
Custom memory pools

At Bloomberg, low-latency parsing became especially important during high market throughput events where millions of FIX messages could flow through systems in very short intervals.

Repeating Groups — Where FIX Gets Interesting

FIX supports repeating groups.

These allow nested structures inside messages.

Examples include:

Multi-leg option strategies
Basket orders
Allocation instructions
Multiple parties/accounts

Example conceptually:

NoLegs=2
LegSymbol=BTCUSD
LegSide=1

LegSymbol=ETHUSD
LegSide=2

Repeating groups are one reason why FIX parsers become non-trivial.

The parser must understand:

Group boundaries
Group counts
Nested tag hierarchies
Dynamic schemas

Many exchange-specific bugs emerge precisely from malformed repeating groups.

Custom FIX Tags in Real Trading Systems

One of the most practical aspects of FIX engineering is custom tags.

Although FIX defines standard tags, almost every exchange or broker introduces proprietary extensions.

Examples include:

Internal routing metadata
Risk checks
Account mappings
Algo instructions
Liquidity flags
Exchange-specific behaviors

Custom tags usually exist in higher numeric ranges:

5000+
9000+
User-defined namespaces

For example:

9001=InternalStrategyID
9100=SmartOrderFlag
9205=RiskProfile

Across Bloomberg integrations and later crypto exchange connectivity, I frequently worked with:

Adding custom tags
Extending FIX dictionaries
Supporting venue-specific semantics
Mapping internal OMS fields to external FIX schemas

This often required:

XML FIX dictionary modifications
Parser extensions
Validation rule updates
Backward compatibility handling

One challenge with custom tags is ensuring they do not break:

Counterparty parsers
Certification environments
Session-level validation

This becomes increasingly difficult when supporting dozens of venues simultaneously.

FIX Across Traditional Finance and Crypto

One interesting evolution over the past decade is how crypto markets adopted institutional FIX infrastructure.

Initially, crypto APIs were primarily REST and WebSocket based.

But institutional participants demanded:

Stable session protocols
Deterministic order workflows
Existing OMS compatibility
Standard execution semantics

As a result, many crypto exchanges introduced FIX gateways.

However, crypto FIX implementations sometimes differ significantly from traditional finance:

Different sequencing models
Exchange-specific order semantics
Non-standard market structures
Faster protocol evolution

Working across both TradFi and crypto FIX ecosystems highlighted how adaptable the protocol remains despite being decades old.

Sample Order Cancel Request Using QuickFIX

Example Python code:

from quickfix import *

def sendOrderCancelRequest():
    message = quickfix.Message()
    header = message.getHeader()

    header.setField(quickfix.BeginString("FIX.4.2"))
    header.setField(quickfix.SenderCompID("CLIENT"))
    header.setField(quickfix.TargetCompID("EXCHANGE"))
    header.setField(quickfix.MsgType("F"))

    message.setField(quickfix.OrigClOrdID("123"))
    message.setField(quickfix.ClOrdID("321"))
    message.setField(quickfix.Symbol("BTCUSD"))
    message.setField(quickfix.Side(Side_BUY))
    message.setField(quickfix.Text("Cancel My Order"))

    Session.sendToTarget(message)

Notice:

MsgType=F → Order Cancel Request
OrigClOrdID links the original order
Session.sendToTarget handles routing

In production systems, additional logic typically exists for:

Retry handling
Duplicate suppression
Session recovery
Risk validation
Audit logging

Why FIX Still Dominates

Despite newer protocols and APIs, FIX remains dominant because:

It is battle-tested
Institutions already use it
OMS/EMS systems depend on it
It supports extensibility
It works across asset classes
It has mature operational tooling

Even modern low-latency systems frequently use:

Binary protocols internally
FIX externally

FIX acts as the interoperability layer between institutions.

Final Thoughts

FIX may appear simple at first glance:

Tag=value pairs
SOH delimiters
Standard message types

But at scale, FIX engineering becomes deeply sophisticated.

After spending:

10 years at Bloomberg
More than a year working with Kraken connectivity
Integrating across 30+ exchanges globally

I’ve seen firsthand how much engineering effort goes into:

Reliable session management
Low-latency parsing
Exchange certification
Custom tag interoperability
Resiliency during volatile markets

The protocol has survived multiple generations of market evolution because it solved a fundamental problem exceptionally well:
standardized electronic communication between trading systems.

And despite its age, FIX continues to remain at the core of global electronic trading infrastructure.

Thanks for reading.
Pritesh Gaur

Claude Code is Gem

Pritesh — Tue, 28 Apr 2026 03:58:11 +0000

If you had asked me about AI a year ago, I would’ve said it’s mostly hype. Interesting, but not something you can rely on for real engineering work. That wasn’t entirely wrong at the time — but it was definitely incomplete.

I had tried LLMs back then. Used them for code, small utilities, even some writing. The results were inconsistent at best. Code would break in non-obvious ways, outputs looked fine on the surface but didn’t hold up, and overall it felt like more effort than value.

That perspective probably also came from the kind of work I’ve been doing for most of my career.

I’ve spent the last 10+ years working on trading systems and backend infrastructure — a big part of that at Bloomberg, and more recently working on production systems handling real financial workflows. This is the kind of environment where correctness matters a lot. You’re dealing with order routing, trade execution, reconciliation — things that can’t “mostly work.” They either work correctly, or they cause real problems.

So when early LLM outputs looked fragile, it was hard to take them seriously.

Things have changed since then.

Part of it is obvious — models and tooling have improved significantly. But the bigger shift, at least for me, was learning how to actually use them properly. That part doesn’t get enough attention. Using LLMs effectively is a skill, and in 2026, it’s becoming a pretty fundamental one.

One thing upfront — I don’t put my name on AI-generated content without being clear about it. This is written by me. I use LLMs as tools, not replacements.

How I Got Here

I generally like understanding how systems work — not just using them, but figuring out where they break and how to make them better. That’s been consistent across my work as well.

At Bloomberg, I worked on exchange connectivity and order routing systems, including handling protocols like FIX and building systems that operate across regions. Later, I moved into decision support and portfolio systems, working with both C++ and backend services to generate trade ideas and improve execution efficiency.

More recently, I’ve been working on Python-based distributed systems, building and maintaining services, optimizing databases, and dealing with batch processes that interact with exchanges and internal systems. A lot of this involves Kafka, RabbitMQ, CI/CD pipelines, and Kubernetes-based deployments.

Across all of this, one thing is consistent — systems need to be reliable, observable, and maintainable.

So naturally, I approached LLMs the same way.

Initial experience wasn’t great. Tried multiple tools — different models, coding assistants — none of it really worked for me. In hindsight, the issue wasn’t the tools. It was how I was using them.

Later, when I started working in an environment where LLM usage was encouraged, I gave it another serious shot. Picked up a subscription and started building something non-trivial — not just scripts, but a proper application.

Day one felt promising. Things were moving fast.

Day two was reality.

The system “worked,” but only superficially. No proper validation, no tests, no guarantees. That’s when my usual engineering instincts kicked in — if this were a trading system, I wouldn’t ship it like this.

I had to restart multiple times before I got into a workflow that was actually sustainable.

Over time, things improved. I was able to iterate faster, refactor with less friction, and even work in areas outside my usual stack more comfortably. That’s when it clicked — the value isn’t just in generation, it’s in how you structure the interaction.

The Core Lesson — Context Matters More Than Prompts

Earlier, there was a lot of focus on prompt engineering. It made sense — small wording changes used to have a big impact.

That’s less true now.

Modern models are much better at interpreting intent. What matters more is context — what information you give, how much of it, and how structured it is.

This became very obvious when I started using LLMs for systems that actually resembled real-world complexity.

For example, while working on services that involved event-driven architectures using Kafka and RabbitMQ, I tried feeding the model full architecture docs, feature plans, and code structure all at once.

The result? It lost focus.

It would try to do too much, or pick up the wrong signals from the context. In one case, I asked it to implement a small feature, and it started building parts of the system that weren’t even in scope yet.

That’s when I started limiting context intentionally — only what’s required for that specific task.

The difference was immediate.

It’s similar to how we design distributed systems — you don’t want every component to know everything. You want clear boundaries and well-defined responsibilities.

What Works Better in Practice

A few things that made a noticeable difference for me:

Treat context as a limited resource
Keep documentation structured and minimal
Separate high-level design from implementation details
Point to actual code instead of duplicating logic
Break work into smaller, well-defined steps

This is very similar to how we already think about system design — modularity, separation of concerns, clear interfaces.

Also, if you have specific expectations — testing practices, deployment patterns, coding standards — they need to be explicitly defined. Otherwise, the model will fill in the gaps, and not always in the way you want.

When Things Stop Working

One pattern I’ve seen repeatedly — people assume the model suddenly got worse.

In most cases, something changed:

Model behavior
Tooling
Context
Your own inputs

In distributed systems, we’re used to debugging issues by looking at changes in the system — deployments, configs, dependencies. The same thinking applies here.

These models are not deterministic. Same input can give different outputs.

Instead of reacting to bad output, it’s more useful to debug the process:

Was the context too large?
Were instructions ambiguous?
Was there conflicting information?

One useful shift — instead of asking “what went wrong,” ask “why did this happen and how do we fix the process.” That framing tends to produce much better results.

Practical Takeaways

A few things that consistently helped:

Context Management

Keep core docs small and focused
Avoid duplication
Regularly clean up outdated information

Execution

Use LLMs to generate reusable solutions, not repetitive work
Iterate in cycles — generate → review → refine
Reset quickly when something isn’t working instead of forcing it

Working with Larger Systems

Break problems into smaller units
Use separate contexts where possible
Don’t try to solve everything in one session
Final Thought

The biggest shift for me was realizing this isn’t about “better prompts.” It’s about designing better workflows.

Once you start treating LLMs like part of a system — with constraints, inputs, and feedback loops — they become far more useful.

And honestly, this fits quite naturally with how we already think about building reliable systems.

Claude Code is Gem

Pritesh — Tue, 28 Apr 2026 03:46:26 +0000