Modern trading architecture

A modern trading architecture has four properties that reinforce one another: a single governed data model, API-first access, event-driven processing, and an analytical layer built on the same data. They are not independent features to check off; their combination is what changes the economics of running a desk.

At the centre is one authoritative representation of each business fact, the trade, the position, the curve, that every function reads from and writes to. A trade captured once is the same trade valuation prices, risk aggregates, and settlement invoices. History is retained bitemporally so any past state reproduces exactly.

Events tie the modules together in real time. A booked trade emits one event to a durable log; valuation, position, risk, and analytics each consume it and update within seconds. No polling, no batch, no copies.

python@subscribe("TRADE_BOOKED")
def on_trade(event):
    position = positions.apply(event)          # one governed position
    npv, greeks = pricer.value(position, market.snapshot())
    risk.update(event.book, npv, greeks)       # live risk, no overnight batch

Every capability is exposed as a governed interface, REST, GraphQL, webhooks, streaming, and the platform’s own UI is just another consumer of the same APIs. That is what makes the platform integrate cleanly and compose into an existing landscape rather than becoming a silo.

Rather than exporting nightly and reconciling before anyone trusts a number, the architecture materialises governed star-schema marts over the trading model, with conformed dimensions and a semantic layer, so business intelligence runs on trusted data with lineage back to the trade. See the BI & OLAP layer.

The same design runs as a managed service, in a private cloud, or on-premises, because it is defined as reproducible infrastructure rather than a hand-built environment. That portability is also a disaster-recovery property: the environment can be recreated, not just restored.