The audit-trail problem hiding in your FIX connectivity layer

Gato Systems — Mon, 27 Jul 2026 19:01:48 +0000

If you route orders over FIX, your audit trail is only as good as two things: what your connectivity layer actually captures, and whether anyone can later prove that record wasn't changed. Most trading teams underrate both — right up until an incident review or a regulator asks them to reconstruct exactly what happened, in what order, and when.

This post is about that gap, why it lives in the connectivity layer specifically, and how to think about designing (or buying) around it.

The order lifecycle you have to be able to replay

A single order over FIX isn't one message — it's a conversation. A NewOrderSingle (35=D) goes out; the venue or broker answers with a stream of ExecutionReport messages (35=8) covering acknowledgement, partial fills, full fills, and done-for-day; OrderCancelRequest and OrderCancelReplaceRequest mutate it mid-flight, each with their own acks and rejects. A parent order may fan out into child orders across venues.

To reconstruct that later, you need every message in the exchange, correctly linked (ClOrdID, OrigClOrdID, OrderID, ExecID), with trustworthy timestamps. Miss a leg — or lose the linkage — and you can't answer the questions that matter after a bad print, a fat-finger, or a market-maker dispute.

Why the OMS log isn't enough

The instinct is to log all of this inside the OMS/EMS. That's necessary but fragile as a system of record: it's the same system making the trading decisions, so a bug, a crash, or a desync can corrupt or lose exactly the evidence you'll want. It's also a single vantage point.

This is why DropCopy exists. A DropCopy session is an independent, read-only copy of the execution flow, delivered in parallel to a separate consumer. Capturing it at the connectivity layer — the thing that already sees every message going to and from every counterparty — gives you a full-lifecycle record (including notices of execution) that doesn't depend on the trading application behaving perfectly. If you only remember one design point from this post: capture the audit stream where the messages actually cross the wire, not only where decisions are made.

Completeness is half the job. Tamper-evidence is the other half.

Having every message isn't the same as being able to prove no one edited it afterward. "Tamper-evident" has a specific meaning worth being precise about:

Append-only storage. Records are written once; there's no in-place update or delete path in the hot log.
Hash-linking. Each record (or batch) carries a hash of its contents, and often of the previous record — so altering an old entry breaks the chain in a detectable way.
Independent verification. You can re-run the hashing over the stored data and confirm it matches, ideally against a value recorded elsewhere.

You don't need a blockchain for this, and most trading shops shouldn't reach for one. A disciplined append-only store with content hashing and periodic anchoring gets you the property that matters: if the record changed, you can tell.

Where regulation forces the issue (US markets)

In the US, this stops being optional. The Consolidated Audit Trail (SEC Rule 613, implemented via the FINRA 6800 series) requires broker-dealers to report the order lifecycle end-to-end with accurate linkage across origination, routing, modification, and execution — on a T+1 cadence with a correction window. CAIS adds customer- and account-information reporting, which drags sensitive identifiers (SSNs, TINs, EINs) into scope. Large-trader obligations (SEC Rule 13h-1) add another layer of tracking. And T+1 settlement compresses the time you have to get clean, linked data out the door.

The through-line: the data your connectivity layer captures is the raw material for all of it. If capture is incomplete, un-linked, or un-provable, every downstream report inherits the problem.

A short design checklist

If you're building or evaluating this, the questions worth asking:

Independent capture. Is there a DropCopy (or equivalent) stream separate from the OMS decision path, covering the full lifecycle including NOEs?
Linkage. Are related events (parent/child, cancel/replace, fills) precisely linked, not just time-ordered?
Immutability. Is the store append-only, with content hashing so alteration is detectable?
Timestamps. Are they from a disciplined, synchronized clock source?
PII handling. For CAIS-adjacent data, are raw identifiers kept out of general logs and encrypted at rest? (Logging a raw SSN into an application log is a classic own-goal.)
Normalization. If counterparties speak different dialects (FIX 4.2/4.4) or you ingest JSON/CSV, is the stored record normalized so it's consistent and queryable?

How Gato approaches it

For transparency, since I work on this at Gato Systems: our FIX connectivity and order-routing network, gHub, captures full-lifecycle DropCopy (including notices of execution) at the connectivity layer, and normalizes across FIX 4.2/4.4, JSON, and CSV so the record is consistent regardless of counterparty. On the reporting side, gReg-CAT handles the end-to-end CAT lifecycle reporting, and gReg-CAIS uses audit-ready immutable logging plus a SHA-256-encrypted vault for sensitive identifiers, so raw PII isn't transmitted to CAT/CAIS. It's modular — you can take connectivity, reporting, or both.

I'm not going to pretend a specific architecture is the only right answer; the point of this post is the property, not the product. If the record is complete, linked, and provably unaltered, you'll be glad you invested when someone asks you to prove what happened.

If you're evaluating this more broadly — latency, multi-venue reach, compliance, onboarding, build-vs-buy — I wrote a longer, vendor-neutral buyer's guide on choosing a FIX connectivity network in 2026. (Link in the canonical post above.)