FIX Protocol Modernization: Binary FIX & SBE Architecture (2026)

This is an engineering deep dive into FIX protocol modernization with binary FIX — what FIXP and Simple Binary Encoding (SBE) actually do, how to redesign a FIX gateway around them, and how to migrate without breaking your existing counterparties. It is not trading advice. The audience is the platform engineer who already runs a tag-value FIX 4.4 or 5.0 SP2 estate and is asking whether to layer FIXP and SBE on top, replace the stack outright, or do nothing. We will walk the latency floor of classic FIX, the parsing cost that nobody budgets for, the brittle session semantics that haunt every operations team at 02:00 IST, and what a 2026-shaped gateway looks like end to end. Expect SBE schemas, an Aeron-flavoured reference diagram, hedged latency numbers, and an honest list of gotchas.

Disclaimer. This post discusses trading system engineering. Nothing here is investment, trading, regulatory or legal advice. Latency, throughput and capacity numbers are illustrative orders of magnitude and will vary substantially with your hardware, kernel, NIC, workload mix and counterparty geometry. Always benchmark on your own infrastructure.

Why FIX needs modernization (latency floor, parsing cost, session brittleness)

Classic FIX is a 1990s text protocol carrying 2026 workloads, and the cracks show in three places: a hard latency floor from string parsing, a CPU cost that scales linearly with message rate, and session semantics that were designed for dial-up reliability rather than always-on co-located servers. Modernization with binary FIX and FIXP attacks all three at once.

To make the problem concrete: a NewOrderSingle in FIX 4.4 is around 150–200 bytes of ASCII tag-value pairs separated by SOH (0x01) delimiters. To act on it, your gateway must (1) scan for delimiters, (2) split into tags and values, (3) convert numeric strings to integers and decimals, (4) look up tag semantics in a dictionary, and (5) validate ordering. That work is per-message and dominates a non-trivial fraction of your end-to-end latency before any business logic runs. In a well-tuned C++ engine you can park parse cost at a few hundred nanoseconds per message; in a Java engine without serious tuning you are often 1–3 microseconds per message — and these are medians, not tails.

The second pain is session brittleness. Classic FIX sessions are sequenced, persistent, single-flow, and married to TCP. Sequence resets, gap-fills, and ResendRequest storms are a daily reality. A counterparty reboots, your gateway re-sends two hours of orders, and your risk system spends the next hour explaining itself. The session protocol mixes transport concerns (heartbeats, gaps) with business concerns (order state) in a way that is hard to scale and harder to reason about.

The third pain is encoding rigidity. Tag-value FIX is variable length, position-independent, and self-describing — all useful properties in 1995, all expensive in 2026. Self-describing means you carry tag identifiers in every message. Variable length means you cannot memory-map a message and cast it to a struct. Position-independent means decoders branch on every field. None of this is a deal-breaker; all of it adds up.

Binary FIX with SBE removes the encoding cost. FIXP removes the session-layer cost and gives you flow types that actually fit modern order flow. Together they are what people usually mean when they say “FIX protocol modernization binary FIX” in a 2026 design review.

FIX 5.0 SP2 today: what you already have

FIX 5.0 SP2 is the current published baseline of classic FIX, and most exchanges and major brokers still speak it day to day in tag-value form. Knowing what 5.0 SP2 already gives you — and what it does not — is the starting point for any modernization plan, because you almost certainly are not on a greenfield.

FIX 5.0 SP2 split the protocol into two layers around 2009: the session layer, now called FIXT.1.1, and the application layer, FIX 5.0 SP2. That separation is the conceptual hook that later let FIXP slot in as an alternative session layer without disturbing the application messages. In practice, the dominant deployment is still FIXT.1.1 sessions carrying tag-value FIX 5.0 SP2 (or even FIX 4.4) application messages over TCP.

What 5.0 SP2 gave the industry that matters for modernization:

A versioned application layer independent of the session, so you can upgrade encodings without renegotiating the session model.
Cleaner extension via ApplVerID (tag 1128), so a single FIXT session can carry mixed application versions per message.
Standard component blocks (Parties, Instrument, OrderQtyData) that map cleanly onto SBE composite types later.
A larger application surface — algorithmic trading components, post-trade, securities reference — that you do not have to throw away when you move to binary.

What it did not solve:

Encoding is still tag-value ASCII unless you negotiate something else.
Session semantics are still TCP-coupled with sequenced flows and the same gap-fill mechanics as FIX 4.2.
There is no notion of idempotent or recoverable flows at the session layer.
Heartbeat-based liveness wastes round trips in modern data centres.

The right mental model is: FIX 5.0 SP2 is the application vocabulary you keep; FIXP and SBE are how you transport and encode that vocabulary on hot paths. Nothing in modernization forces you to redesign your business messages.

Binary FIX and SBE: what they actually do

Binary FIX is shorthand for “FIX application messages encoded with a binary wire format instead of tag-value ASCII”, and the dominant binary format in 2026 is Simple Binary Encoding (SBE). SBE is a schema-driven, fixed-offset binary encoding from the FIX Trading Community that targets zero-allocation, zero-copy decode and works equally well in C++, Java, Rust, and C#.

The key idea behind SBE is brutal but effective: every field has a known offset and length at compile time, so the decoder is a series of pointer arithmetic operations against the receive buffer. There is no dictionary lookup, no delimiter scan, no string-to-number conversion. A price field is an int64 mantissa at offset 24; you cast and you are done. The decoder is a generated view over the buffer, not an object graph.

A minimal SBE schema for a NewOrderSingle looks roughly like this:

<sbe:messageSchema package="trading.fix"
                   id="1" version="0"
                   semanticVersion="FIX5.0SP2"
                   byteOrder="littleEndian"
                   xmlns:sbe="http://fixprotocol.io/2016/sbe">

  <types>
    <composite name="messageHeader">
      <type name="blockLength" primitiveType="uint16"/>
      <type name="templateId"  primitiveType="uint16"/>
      <type name="schemaId"    primitiveType="uint16"/>
      <type name="version"     primitiveType="uint16"/>
    </composite>

    <composite name="DECIMAL">
      <type name="mantissa" primitiveType="int64"/>
      <type name="exponent" primitiveType="int8" presence="constant">-7</type>
    </composite>

    <enum name="SideEnum" encodingType="uint8">
      <validValue name="BUY">1</validValue>
      <validValue name="SELL">2</validValue>
    </enum>

    <enum name="OrdTypeEnum" encodingType="uint8">
      <validValue name="MARKET">1</validValue>
      <validValue name="LIMIT">2</validValue>
    </enum>
  </types>

  <sbe:message name="NewOrderSingle" id="11" blockLength="32">
    <field name="clOrdIDRef" id="11" type="uint64"/>
    <field name="account"    id="1"  type="uint32"/>
    <field name="orderQty"   id="38" type="uint32"/>
    <field name="price"      id="44" type="DECIMAL"/>
    <field name="side"       id="54" type="SideEnum"/>
    <field name="ordType"    id="40" type="OrdTypeEnum"/>
    <data  name="symbol"     id="55" type="varStringEncoding"/>
  </sbe:message>
</sbe:messageSchema>

That schema compiles via the Real-Logic simple-binary-encoding toolchain into Java, C++, Rust, and C# codecs that share the same wire layout. The block of fixed fields lives at the front; variable-length fields (here, symbol) follow in a defined order. Decoders simply walk the structure.

A second snippet — a market-data incremental refresh — shows how SBE handles repeating groups using a <group> element with its own block length:

<sbe:message name="MDIncRefresh" id="X" blockLength="8">
  <field name="securityId" id="48" type="uint64"/>
  <group name="entries" id="268" blockLength="24">
    <field name="updateAction" id="279" type="uint8"/>
    <field name="entryType"    id="269" type="uint8"/>
    <field name="price"        id="270" type="DECIMAL"/>
    <field name="size"         id="271" type="uint32"/>
  </group>
</sbe:message>

Each repeating group entry is fixed at 24 bytes, so a 10-level book update is 8 + 2 (group header) + 10×24 = 250 bytes, with deterministic offsets. The matching-engine and feed-handler designs we covered in /market-data-feed-handler-architecture-low-latency-2026/ and /itch-order-book-reconstruction-systems-architecture-2026/ both lean on this property.

See the side-by-side wire-format comparison below.

The concrete wins from SBE, in order of impact: smaller payloads (typically 3–4× smaller for an order message), order-of-magnitude faster decode (50–100 nanoseconds vs several hundred nanoseconds in well-tuned tag-value parsers), zero garbage on the JVM (the codec is a flyweight view), and a single schema that both sides own. The cost is loss of human readability on the wire — you no longer tcpdump and read.

FIXP: the session protocol classic FIX never had

FIXP (FIX Performance Session Layer) is the modern replacement for the FIXT session layer. Where FIXT mixes session and business state in one sequenced flow, FIXP cleanly separates session establishment, flow semantics, and recovery — and gives you four distinct flow types you can pick per direction.

A FIXP session moves through four observable phases: Negotiate (mutual auth, agree session id and flow types), Establish (agree starting sequence numbers and keepalive interval), Established (carry application messages), and Terminate (clean shutdown). Between Established and the terminal state, the session can dip into a Recovering phase when a gap is detected.

The flow types matter, because they are how FIXP gets out of the “every message is sequenced and recoverable” tax that classic FIX imposed:

Idempotent — sender attaches sequence numbers and may resend; receiver deduplicates. Best for orders.
Recoverable — like Idempotent, but the server can replay on request. Best for market data the client must catch up on.
Unsequenced — fire-and-forget. Best for telemetry, heartbeats, or quote streams where stale data is worthless.
None — the side sends nothing application-level. Useful for one-way pipes.

That four-way split is the conceptual leap from FIXT. In a classic FIX session, your post-trade ack stream and your high-frequency quote stream share the same ResendRequest plumbing, which means a slow ack consumer can stall quote recovery. In FIXP you put the order flow on Idempotent and the quote stream on Unsequenced, and they no longer share fate.

A second underrated FIXP feature is transport independence. FIXP defines the session as a state machine over any reliable or unreliable transport. The same session protocol runs over TCP, over Aeron over UDP, over WebSocket, or over a shared-memory IPC. The wire format for FIXP messages is itself usually SBE, which closes the loop.

For comparison shoppers, the short version of FIX 5.0 SP2 vs FIXP is: FIX 5.0 SP2 is the application vocabulary, FIXP is the session protocol, and they are designed to compose. You do not pick one or the other; you keep the 5.0 SP2 application messages, encode them with SBE, and carry them on FIXP.

Reference architecture for a modernized FIX gateway

A modernized FIX gateway is a pinned-core process that takes packets off a kernel-bypass NIC into a lock-free ring, decodes them as SBE views, validates them under a FIXP session state machine, and hands them to the matching engine over an SBE-typed in-process API. Everything else — drop copies, surveillance, persistence — leaves the hot path via an asynchronous bus.

Five components matter, in roughly the order a packet meets them:

NIC and PHY. A 10/25/100 GbE port with PTP hardware timestamping and receive-side scaling so traffic from a given counterparty pins to a known queue. Hardware timestamping is non-negotiable if you ever need to argue about latency with a regulator or a customer.
Kernel bypass. Solarflare ef_vi, DPDK, or io_uring in busy-poll mode. The goal is to keep the receive path out of the kernel TCP/IP stack on the hot core, which removes context switches and the bulk of the wire-to-app variance. For broker-grade gateways, ef_vi remains the pragmatic choice in 2026; for greenfield builds without a Solarflare investment, DPDK or AF_XDP are competitive.
Ring buffer and dispatch. A single-producer, multi-consumer lock-free ring — Disruptor pattern in Java, custom in C++, or Aeron IPC for cross-process — owns the boundary between the NIC poll thread and the gateway logic. The Disruptor’s mechanical-sympathy design (cache-line padding, lazy set, single writer principle) still defines the genre.
Gateway logic on a pinned core. One FIX gateway worker per pinned core, running four stages: FIXP session handler (sequence, keepalive, recovery), SBE decoder (zero-copy view), authz and pre-trade risk checks, and an optional translator that bridges legacy tag-value FIX 4.4 sessions to FIXP and SBE for downstream consumers.
Matching engine API and drop-copy bus. The matching engine exposes an SBE-typed API — same schema as the wire — so the gateway hands it a buffer pointer, not a deserialised object. Outbound execution events fan out on an Aeron multicast bus to OMS replicas, surveillance, TCA, and a tick warehouse landing Parquet in object storage.

The diagram below threads the whole pipeline.

A few non-obvious design choices show up in this picture.

Aeron vs Disruptor. They are not alternatives; they live at different layers. The Disruptor (or an equivalent ring) is the in-process boundary between the polling thread and the gateway logic; it is microseconds-fast but single-machine. Aeron is the cross-process and cross-host multicast bus that fans out execution events. A modernized gateway typically uses both: a Disruptor on the ingress hot path, Aeron for everything that leaves the process. Aeron’s reliable multicast over UDP with a transparent archive is what makes drop-copy and replay practical at low latency.

One worker per pinned core. Co-locating session, decode, and risk on a single pinned core minimises cross-core cache traffic. You scale by adding cores, not by adding threads to the same core. A 16-core gateway box typically pins 4–6 cores to gateway workers, 1–2 to NIC poll threads, 1–2 to Aeron, and leaves the rest for ops, monitoring, and the OS.

Drop-copy as a bus, not a database. A common mistake is to write every execution to Postgres synchronously. The modernized pattern is to publish on Aeron and let downstream consumers — OMS replicas, surveillance, the tick warehouse — persist asynchronously. The bus is the source of truth; the database is a materialised view. The real-time risk engine architecture we covered separately leans on the same idea for derivatives margin calculation.

Migration strategy: coexistence and cutover

The realistic migration path is not a flag day. It is a multi-quarter coexistence in which legacy FIX 4.4 / 5.0 SP2 tag-value sessions and modern FIXP+SBE sessions live behind the same gateway tier, and a translator bridges between them until the slowest counterparty has crossed over. Plan for at least 12–18 months of dual-stack operation.

A workable migration in four phases:

Phase 1 — Internal SBE. Adopt SBE internally first. Re-encode the matching-engine API, the drop-copy bus, and the internal order-event format in SBE, but keep all external sessions on tag-value FIX. This is the highest-leverage move: it improves your internal latency budget immediately and forces your team to learn SBE without taking on counterparty risk. The translator service is the only new external-facing component, and it sits between the legacy FIX engine and the internal SBE bus.

Phase 2 — FIXP on greenfield connections. Offer FIXP+SBE as a connection option for new counterparties only — typically HFT firms and prop shops who are already asking for it. Run them through the modern gateway directly; do not bother translating to legacy FIX internally. This is your validation phase: you find the gaps in your FIXP implementation against real counterparties before exposing them to your existing buy-side fleet.

Phase 3 — Counterparty-by-counterparty cutover. Reach out to existing counterparties with a published FIXP+SBE schema and a UAT environment. Migrate them one at a time, with a fallback window during which both sessions remain credentialled. The session router at the gateway edge directs each CompID to either the legacy FIX engine or the modern FIXP gateway based on a config flag.

Phase 4 — Legacy sunset. Once tag-value sessions drop below a configurable threshold (often 5% of order flow), declare a sunset date six to twelve months out. Maintain the translator only for any remaining low-volume counterparties who cannot move — and price that maintenance into their commercials.

The topology that holds across all four phases looks like this:

A few migration rules of thumb learned from real cutovers:

Never translate hot-path flows in both directions at once. If you bridge FIX 4.4 inbound to SBE and SBE outbound to FIX 4.4 in the same session, you pay the translation cost twice on every order. Pick a direction and keep it asymmetric — typically translate inbound to SBE and let the legacy client live with tag-value outbound until they migrate.
Pin the schema version. A FIXP session carries schemaId and version in every SBE message header. Treat schema upgrades like API upgrades: bump the version, run both side by side for a release, then deprecate.
Keep CompIDs stable across the cutover. Surveillance, post-trade, and reconciliation all key off CompID. Changing it because the session is now FIXP creates a 6-month cleanup project.
Drop-copy first, order flow second. If you must phase a single counterparty, start by sending them a FIXP+SBE drop copy in parallel with their FIX 4.4 session. Once their downstream consumes the new feed cleanly, swap the order flow.

Engineering trade-offs and gotchas

Modernizing FIX is not free, and most failures come from underestimating the second-order costs: tooling loss, schema governance, and the political work of negotiating a binary format with a counterparty whose ops team still reads tcpdump. The engineering wins are real; so are the trade-offs.

Loss of human readability. This is the most commonly underestimated cost. With tag-value FIX, an L3 engineer can tcpdump a session and read what happened. With SBE, the wire is opaque without a decoder and a schema. You must invest in a protocol viewer that joins captured packets with the active schema and renders human-readable output. Without it, your mean time to debug doubles.

Schema governance becomes a real job. Tag-value FIX is forgiving — adding a tag is a non-event, ignoring an unknown tag is the default. SBE is strict: every field has an offset, and changing offsets breaks every counterparty. Schema changes need a change-management process, a deprecation policy, and a backward-compatibility test suite. Plan for a part-time owner of the schema repository.

Tooling lag. QuickFIX-style engines (QuickFIX/J, QuickFIX/n, the Python simplefix family) have years of community polish for tag-value FIX. The SBE ecosystem is narrower: Real-Logic’s simple-binary-encoding and Artio, Chronicle’s commercial offerings, and a handful of vendor stacks. If your team’s strength is operations rather than C++ or Java codec hacking, the maturity gap is real. Budget for it.

Pre-trade risk is now harder to externalise. When messages are ASCII tag-value, you can pipe them through a separate risk box that parses, decides, and forwards. When they are SBE views over a buffer, the risk check is most naturally inside the gateway process. You either rebuild your risk engine inside the gateway (fast, but coupled) or accept a serialise/deserialise hop to an external risk box (loses much of the SBE win). There is no clean answer; pick consciously.

FIXP recovery semantics differ from FIX 4.4. Operations teams trained on ResendRequest and GapFill will get tripped up by FIXP’s NotApplied / RetransmitRequest model. Idempotent flows mean the sender owns dedup, which inverts a lot of muscle memory. Run a tabletop exercise before you go live.

Time synchronisation matters more, not less. SBE timestamps are often nanosecond-resolution uint64 UTC nanoseconds since epoch. If your PTP grandmaster wanders 5 microseconds, you will see it in your TCA and your surveillance reports. Modernization is a forcing function to clean up your time distribution. Treat it as a separate workstream.

Coexistence is the new normal. Most production estates will run dual-stack for years, not months. Build the translator service like a production component, not a migration tool — it will outlive the migration.

Performance expectations (hedged)

Performance improvements from FIX modernization are real but workload-dependent, and quoting a specific microsecond number without a benchmark is malpractice. The honest framing: expect parse cost to drop by roughly an order of magnitude, end-to-end median latency to fall into the low single-digit microsecond range on tuned hardware, and tail behaviour to become substantially more predictable.

A reasonable structure for thinking about the budget — hedged, because your numbers will differ — is shown below.

The diagram annotates each stage with a range, not a point estimate. Read it as: on the order of single-digit microseconds end to end after modernization, versus high single-digit to low double-digit microseconds before, on comparable hardware running comparable business logic. Your mileage will vary because:

NIC and kernel-bypass choice dominates wire-to-app. ef_vi, DPDK and io_uring are not interchangeable; differences of a microsecond at the receive boundary are normal.
Business logic depth is workload-specific. A simple pre-trade limit check is a few hundred nanoseconds; a full SOR decision with venue scoring is a different shape entirely.
Garbage collection still bites JVM-based gateways even with zero-allocation SBE codecs, if other parts of the path allocate. Profile aggressively.
Tail latency is what regulators and counterparties actually care about. A median of 2 microseconds with a 99.99th percentile of 200 microseconds is worse than a median of 4 microseconds with a 99.99th of 20.

Throughput is the secondary axis and usually moves with latency, but the dominant constraint at high message rates is allocation and GC, not the encoding. A well-tuned SBE-based gateway sustains millions of messages per second per core; a tag-value gateway typically tops out an order of magnitude lower at the same allocation budget.

Two numbers worth being explicit about, because they get misquoted everywhere:

Parse cost. Roughly 50–100 nanoseconds for an SBE NewOrderSingle decode in a tuned codec, versus a few hundred nanoseconds for an equivalent tag-value parse. This is the cleanest, most defensible win.
Payload size. Typically 3–4× smaller on the wire for SBE versus tag-value. That translates into more orders per packet, fewer packets per second, and less work for the NIC and switches.

What modernization does not do: it does not magically lower your matching-engine latency, your network round-trip time, or your exchange’s response time. Those are separate problems with separate fixes.

Practical recommendations

Before you commit to a modernization programme, run a one-week internal benchmark that captures your actual gateway profile under representative load. The decision to invest in FIXP+SBE should be data-driven, not aspirational, and the answer for many estates is “modernize internally first, defer the external switch”.

A pragmatic decision tree:

If your median end-to-end gateway latency is under 5 µs and tail is well-behaved, you probably do not need binary FIX yet. Spend the budget on observability and your tick warehouse — covered in /event-driven-backtesting-engine-architecture-2026/.
If your tail latency is the problem, not the median, modernize the internal bus and risk path first. A lot of tail comes from internal serialisation between gateway and matching engine, not from the wire.
If counterparties are asking for it (HFT, prop), build the modern gateway path even if your existing buy-side fleet stays on FIX 4.4. Run them in parallel.
If you are running on hosted infrastructure where you cannot pin cores or run kernel bypass, the SBE win is smaller than advertised. Be realistic about how much of the latency budget you can recapture.
If your domain is post-trade, allocations, or non-latency-sensitive workflows, SBE is still worth adopting for the schema governance and payload-size wins, but the urgency drops.

A second set of recommendations, on team and process:

Stand up a schema repository as a real artefact, with CI tests for backward compatibility.
Invest in a protocol viewer early — before your first production cutover, not after the first incident.
Pair every FIXP implementation engineer with someone who has carried a pager for a legacy FIX gateway. The institutional knowledge about session recovery is irreplaceable.
Treat the translator service as a first-class component with its own SLO and on-call rotation.
Publish your SBE schema externally and version it with semantic versioning. Counterparties will appreciate it; auditors will require it.

FAQ

Is binary FIX the same as FIXP?
No. Binary FIX usually means FIX application messages encoded with a binary wire format, most commonly Simple Binary Encoding (SBE). FIXP is the modern session-layer protocol that replaces the FIXT session layer. The two compose: SBE is the encoding, FIXP is the session, and FIX 5.0 SP2 is the application vocabulary. You can use SBE without FIXP (some exchanges do), but the combination is what people usually mean by “modernized FIX”.

Can I run FIXP and FIX 4.4 in the same gateway?
Yes, and you almost certainly will during a multi-quarter migration. The dominant pattern is a session router at the gateway edge that directs each CompID to either a legacy FIX engine or a modern FIXP gateway, with a translator bridging the two onto a single internal SBE bus. Plan for at least 12–18 months of dual-stack operation; budget operationally for the translator as a permanent component, not a migration scaffold.

How does SBE handle backwards compatibility?
SBE supports schema versioning via the message header (schemaId, version) and a strict set of evolution rules: you may append new fields to the end of a block, you may append new groups, and you may extend enums, but you cannot reorder, retype, or remove. The Real-Logic toolchain enforces these rules at code-gen time. Counterparties on older schema versions ignore new trailing fields automatically.

Does FIX modernization help if my matching engine is the bottleneck?
Only marginally. SBE and FIXP attack the gateway latency budget — parse cost, session bookkeeping, kernel hops. If your matching engine is the bottleneck (lock contention, GC pauses, single-threaded match loop), modernizing FIX speeds the wings of the airplane but not the engine. Profile honestly. A common pattern is to modernize FIX and re-architect the matching engine as separate workstreams, sequenced so the gateway is ready before the engine upgrade lands.

What about regulatory acceptance of binary protocols?
Major regulators — SEC, ESMA, FCA, SEBI — have no objection to binary protocols per se; what they care about is auditability, reconstructability, and accurate timestamping. SBE actually makes auditability easier because the schema is the single source of truth for the wire layout. You still need a protocol viewer for investigators, and you still need PTP-grade timestamps. Check your local rules — for example MiFID II RTS 25 timing requirements — and design backwards from them.

Should we use Aeron, Kafka, or both for the internal bus?
Both, for different jobs. Aeron is for the hot internal path between gateway, matching engine, and drop-copy consumers where microseconds count. Kafka is for the warm path — tick warehouse, analytics, replay, downstream applications where milliseconds are fine. A common pattern is Aeron-to-Kafka bridge processes that consume the hot Aeron stream and publish a durable Kafka topic for everything that does not need single-digit-microsecond delivery.

FIX Protocol Modernization: Binary FIX & SBE Architecture (2026)

FIX Protocol Modernization: Binary FIX & SBE Architecture (2026)

Why FIX needs modernization (latency floor, parsing cost, session brittleness)

FIX 5.0 SP2 today: what you already have

Binary FIX and SBE: what they actually do

FIXP: the session protocol classic FIX never had

Reference architecture for a modernized FIX gateway

Migration strategy: coexistence and cutover

Engineering trade-offs and gotchas

Performance expectations (hedged)

Practical recommendations

FAQ

Further reading

Related

Comments

Leave a Reply Cancel reply

Tag Cloud

Categories