Trading

Most trading systems have a dirty secret: they are held together by instrument identifiers that were never designed for the volumes, venues, and regulatory requirements they serve today. Proprietary symbologies — the internal ticker codes, Bloomberg open tickets, Reuters RICs — each served their original purpose well. But as firms trade across more venues, asset classes, and jurisdictions, the cost of translating between proprietary identifier systems at every integration point has become a significant operational burden and source of settlement risk. The Financial Instrument Global Identifier (FIGI) — an OMG/ISO open standard — is the emerging solution. And regulatory mandates are accelerating its adoption. ...

Financial systems break differently from everything else. A web service goes down — users see an error page. A trading system’s FIX session stays alive but stops receiving fills — the pricing engine keeps trading on stale data for the next thirty seconds. Market data flows for some symbols but not others. A trade capture failure at 2 PM creates a settlement issue at 6 AM the next day. And downtime is measured in regulatory penalties and market exposure. Chaos engineering — the intentional, controlled injection of failures — was built for exactly these scenarios. Unlike most infrastructure practices, it has published financial services references you can point your compliance team to. ...

Real-time risk engines are the unsung heroes of trading platforms. They sit between order entry and execution, making split-second decisions about whether trades are safe to execute. Building risk systems that process millions of calculations per second is a common challenge — the key isn’t just getting the math right, but building systems that make decisions within microseconds while remaining accurate, scalable, and operationally sane. For high-frequency trading environments, sub-100 microsecond completion is the target. Most risk engines need to complete all calculations within 1-10ms to avoid impacting execution speed. This constraint drives every architectural decision. ...

If you run a trading system that cares about microseconds, you cannot afford the overhead of traditional observability. Sidecars consume CPU. Log shippers add latency. Metrics exporters create failure dependencies. And yet you still need to know when your exchange connections are dropping packets, when a syscall is running long, and when your TCP handshake to the venue is stalling. eBPF — extended Berkeley Packet Filter — solves this. It runs sandboxed programs inside the Linux kernel without modifying kernel source, loading modules, or touching application code. The kernel verifier rejects unsafe programs at load time. Goldman Sachs requires eBPF experience for production engineering roles. Their low-level systems engineering listing specifically asks for “experience with eBPF and tracing for observability in production” and “knowledge of RDMA or kernel networking internals beyond the socket API.” This is not a conference talk about future potential. It is a job requirement at one of the world’s largest financial institutions. ...

If you are comparing Aeron vs Kafka vs Chronicle Queue for your capital markets messaging layer, the choice determines whether your trading desk operates at microsecond or millisecond latency. Pick the right one and you get predictable sub-10μs market data delivery. Pick the wrong one and you will spend years fighting GC pauses, backpressure, and missed trades. We have deployed all three in production at tier-one banks — Aeron for exchange gateway connectivity, Kafka for settlement and risk workflows, and Chronicle Queue for deterministic journaling on the trading floor. Here is the real-world comparison based on those deployments, including the aeron vs kafka latency gap and where chronicle queue fits in. ...

The conventional wisdom in capital markets has been that trading systems stay on-premise. Low latency, deterministic performance, and regulatory comfort with physical infrastructure have kept trading floors running on bare metal for decades. That is changing. We have led cloud migration programmes for tier-one banks and hedge funds, moving trading workloads to Google Cloud in under six months and passing regulatory audits on first attempt. Here is how we did it. ...

If you have ever operated a FIX engine in production, you know that the standard is not standard. Every exchange speaks a slightly different dialect of FIX 4.4. The same tag can mean different things on different venues. Session disconnect recovery differs between CME and LSEG. Drop copy behaviour varies between brokers. We have certified and deployed FIX engines across ICE, CME, LSEG, Eurex, and crypto venues. Here are the patterns that work in production and the ones that cause the most incidents. ...