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 a list; their combination is what changes the economics of running a desk. Each property makes the others more valuable, and the absence of any one undermines the rest. This handbook describes the reference shape and the patterns that implement each property, so that a buyer can recognise the architecture beneath the marketing and an architect can design toward it.

The test of an architecture is not whether it can do a thing but how cleanly the things join. A platform can have excellent valuation and excellent risk and still be poorly architected if the two run on separate copies of the position that must be reconciled. The four properties below are precisely the ones that determine how cleanly the pieces join, which is why they matter more than any individual capability.

The reinforcement between the four properties is worth making concrete, because it is the heart of why architecture is a system rather than a checklist. The governed model gives the events something authoritative to update; the events give the APIs something real-time to expose; the APIs give the analytics a governed path to the data; the analytics close the loop by making the governed data useful to the whole organisation. Remove any one and the others lose their force: events without a governed model propagate between copies, APIs without events cannot offer real-time, analytics without the governed model has nothing consistent to draw on.

This systemic quality is why a buyer cannot evaluate a modern architecture property by property in isolation and sum the results. A platform might score adequately on each property considered alone and still fail as an architecture, because the properties do not connect: a governed model that events do not update in real time, an API that does not expose events, an analytics layer fed by an export rather than the governed model. The evaluation must ask not only whether each property is present but whether they reinforce one another, which is a question about how the platform is built as a whole.

As you evaluate any platform, hold the four properties together in mind and ask not only whether each is present but whether they reinforce one another: does the governed model get updated by the events, do the APIs expose those events, does analytics draw on the same governed model? A platform where the properties interlock has a coherent architecture; one where they are present but disconnected is a collection of features that will not deliver the architecture’s economics. The reinforcement is the point, and it is what the maturity assessment is built to test.

The central difficulty of evaluating architecture is that it does not appear in a demonstration. A demonstration shows what a platform does: it books a trade, values it, shows risk, produces a report. Every serious platform does these things, so every serious platform demonstrates well. What a demonstration cannot show is how the platform does them, whether the trade flows through one model or several copies, whether the risk is the same data as the position or a reconciled copy, and it is the how, invisible in the demonstration, that determines the decade of consequences.

This invisibility is why buyers so often choose on features and regret it later. The features are visible and comparable, so they dominate the evaluation, while the architecture, which actually determines cost, speed, and trust, is hard to see and easy to defer. The purpose of a reference architecture is to make the invisible visible: to give the buyer a set of specific properties to look for and specific questions to ask, so that the architecture can be evaluated deliberately rather than assumed from the polish of the demonstration.

The invisibility of architecture creates a specific hazard in procurement: the evaluation naturally gravitates toward what can be seen and compared, which is features, and away from what cannot, which is architecture. A structured evaluation counteracts this gravity deliberately, by making architecture an explicit category with its own questions and its own weight, rather than letting it be crowded out by the feature comparison. Without this deliberate counterweight, the architecture, which determines the decade of consequences, loses the evaluation to the features, which determine the demonstration.

The remedy is to translate each invisible architectural property into a visible, testable question, which is what this handbook and its assessment do. Instead of asking whether the architecture is modern, which invites a marketing answer, ask whether a booked trade updates risk in seconds, whether the UI uses the public API, whether analytics run on the governed model, whether the environment can be recreated from code. Each of these is concrete and demonstrable, and together they make the invisible architecture visible enough to evaluate on evidence rather than on faith.

Counteract the gravity of the feature comparison by making architecture an explicit, weighted category in your evaluation, with its own concrete questions: does a booked trade update risk in seconds, does the UI use the public API, does analytics run on the governed model, can the environment be recreated from code? Turning each invisible property into a visible, testable question is what lets you evaluate architecture on evidence rather than on the polish of the demonstration, and it is exactly what the maturity assessment structures.

At the centre of the architecture is one authoritative representation of each business fact, the trade, the position, the curve, the counterparty, that every function reads from and writes to. A trade captured once is the same trade that valuation prices, that risk aggregates, and that settlement invoices. Because there is one version of each fact, the numbers agree by construction, and the reconciliation that consumes so much of a legacy operation’s effort simply does not exist. The governed model is the foundation on which every other property of the architecture stands.

History is retained bitemporally, so any past state reproduces exactly: the position on the day of a dispute, the book’s value at the moment of a default, on the curve that was live then. This is invisible in a demonstration and decisive in an audit, a dispute, or a regulatory examination, and it is extremely hard to add to a platform not designed for it. The governed model also carries lineage, so any reported number can be traced to the exact inputs that produced it, turning an assertion into a demonstration.

The governed model is worth dwelling on because it is the property from which the others draw their value, and because vendors claim it loosely. A genuine governed model means there is one place where each fact lives, owned and quality-controlled, that every function reads and writes. It is not a data warehouse that copies data together for reporting, nor a canonical format that modules map to and from; those are reconciliation in other clothes. The test is whether a change made in one function is immediately the same change everywhere, because there is one record, not a synchronised set of copies.

Lineage is the governed model’s quiet superpower, and it is what turns compliance from an argument into a demonstration. When every number carries its lineage, the path from a reported figure back to the trades and inputs that produced it, a question from an auditor or regulator is answered by tracing rather than by reconstructing. The organisation can show, not assert, how a number was derived. This is invisible in normal operation and invaluable under examination, and it is a property of the governed model that a many-model system, where lineage is broken by every copy and reconciliation, structurally cannot match.

Test the governed model concretely: amend a fact in one function and verify it is immediately the same everywhere, because there is one record, not synchronised copies. Then ask the platform to trace a reported number back to the trades and inputs that produced it, to see whether lineage is a property of the model or an aspiration. A genuine governed model passes both tests directly; a many-model system dressed as one reveals itself in the lag of the first test or the difficulty of the second.

A single model is only as trustworthy as its governance. A governed model has defined ownership for each domain of data, so someone is responsible for its quality; it has quality rules enforced as data is written, so invalid records are rejected at the source rather than discovered downstream; and it has master data, golden sources for reference data like counterparties, instruments, and calendars, so that every function means the same thing by the same term. Without these disciplines, a single store can degrade into a single mess, which is trustworthy in neither the way a governed model is nor even the way a reconciled many-model system is.

Master data deserves particular attention because it is where consistency is won or lost. When every function draws its counterparties, instruments, and calendars from one governed source, aggregations are correct by construction: total exposure to a counterparty means the same counterparty everywhere. When reference data is duplicated and drifts, aggregations become unreliable, because the same counterparty may appear under different identities in different places. Master-data governance is therefore not a back-office nicety but a foundation of trustworthy risk and reporting, and a modern architecture treats it as such.

Data governance is where a single model is kept trustworthy over time, and its absence is how a single model quietly decays. Ownership matters because unowned data has no one responsible for its quality, so problems accumulate unaddressed. Quality rules enforced on write matter because they reject bad data at the source, where it is cheap to fix, rather than letting it flow downstream where it corrupts everything built on it. These disciplines are not bureaucracy; they are what keeps the governed model a source of truth rather than a single large repository of accumulated error.

Master data is the specific governance that determines whether aggregations can be trusted, and it repays particular attention in evaluation. Ask how a platform manages reference data, counterparties, instruments, calendars: is there one golden source that every function uses, or does each function keep its own list that can drift? The answer determines whether total exposure to a counterparty means the same counterparty everywhere, which is the difference between a risk aggregation you can rely on and one you must check. Master-data governance is foundational, and a platform that treats it casually cannot be trusted for aggregate risk.

Probe data governance and master data explicitly, because they are what keep a single model trustworthy: ask who owns each data domain, how quality rules are enforced on write, and above all whether there is one golden source of reference data that every function uses. The master-data answer determines whether aggregate risk can be trusted, because it decides whether the same counterparty means the same counterparty everywhere. A platform casual about master data cannot be relied on for aggregate exposure, however good its other properties.

A governed model that holds only the current state cannot answer the questions a trading business is most often asked under pressure, which are about the past. What was the position on the day of the dispute? What was the book worth at the moment of the default, on the curve that was live then? What did the report say when it was filed? Answering these requires bitemporality: tracking both when a fact was true in the world and when the system recorded it, so any past state can be reproduced exactly. This is the property that lets a business reconstruct history precisely rather than approximately.

Reproducibility is hard to retrofit because it touches how every fact is stored. A platform that recorded only current state overwrote its history, and no later engineering can recover what was not kept. This is why bitemporality must be a property of the architecture from the start, and why it should be tested during evaluation rather than assumed: ask the platform to reproduce a valuation as of a past date on the data that was live then, and the ease or difficulty of the answer reveals whether reproducibility is designed in or hoped for.

Reproducibility is one of those properties whose value is entirely invisible until the moment it is needed, at which point it is decisive. In normal operation, no one asks the platform to reconstruct the book as of a past date; the current state suffices. But when a dispute, a default, or an examination arises, the ability to reproduce a past state exactly, on the data that was live then, is the difference between answering confidently and reconstructing history by hand under pressure. Because these moments are adversarial and high-stakes, the property that serves them should be verified in advance, not discovered wanting when it matters.

The reason reproducibility must be architectural rather than added later is worth understanding precisely: it depends on never discarding history, which is a choice made in how every fact is stored. A platform that overwrites a value when it changes has lost the previous value forever; no later feature can recover what was not kept. Bitemporality, keeping both when a fact was true and when it was recorded, must therefore be designed into the storage from the start. This is why reproducibility is a good test of whether an architecture is genuinely modern: it cannot be faked or retrofitted, so its presence indicates real architectural depth.

Verify reproducibility rather than assuming it: ask the platform to reproduce a specific valuation as of a past date on the market data that was live then, and watch whether it does so directly from retained history or reconstructs it through effort. Reproducibility cannot be faked or retrofitted, because it depends on never discarding history, so its presence indicates real architectural depth and its absence is decisive in the audits, disputes, and examinations where it is most needed. Test it while you can, not when you need it.

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. There is no polling, no nightly batch, and no copying, because every consumer reacts to the same event and updates the same governed model. This is what makes intraday risk possible: the risk view reflects the positions that exist right now, because it was updated by the same event that created them.

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

The durable event log is also an audit trail and a recovery mechanism. Because every consequential change is an event on the log, the system’s state can be reconstructed by replaying the log, and the log itself records who did what and when. The event-driven core thus delivers three things at once: real-time propagation, auditability, and recoverability, all from the same mechanism.

The event-driven core is the mechanism that makes the governed model dynamic, turning it from a shared store into a living system that propagates change in real time. Without events, a governed model would still remove reconciliation, but updates would have to be pulled by each function on some schedule, reintroducing delay. With events, a change to the model is pushed to every interested function immediately, so the whole system stays current with the trade. This is what elevates the architecture from consistent-but-slow to consistent-and-real-time, which is the property a trading desk most needs.

The elegance of the event-driven core is that one mechanism delivers three properties that legacy architectures provide, if at all, through three separate and imperfect systems. Real-time propagation, which legacy platforms attempt through synchronisation; auditability, which they build as a separate audit system; and recoverability, which they provide through backups, are all consequences of a single durable event log in a modern architecture. Getting three critical properties from one well-designed mechanism, rather than three bolted-on systems that must themselves be maintained and reconciled, is a hallmark of good architecture and a source of its economy.

When you evaluate the event-driven core, confirm that it is a genuine core and not a message queue bolted onto a batch system: does a booked trade actually update the governed model and propagate to risk in seconds by event, and is the same durable log the audit trail and recovery mechanism? A real event-driven core delivers real-time propagation, auditability, and recoverability from one mechanism; a simulated one delivers a fast screen over data that still reconciles in batch beneath it.

There is a deeper way to understand the event-driven core: the log of events is itself the system of record, and the current state of every function is a projection of that log. A position is the result of applying every trade event in order; a risk figure is the result of processing those positions. Because the state is derived from the log, it can always be rederived, which is what gives the architecture its auditability and recoverability. The log is the truth, and everything else is a view of it.

This model, in which state is a projection of an immutable event log, is what lets the architecture answer questions that a state-only system cannot. It can show not only the current position but how it came to be, event by event. It can reconstruct the state as of any past moment by replaying the log to that point. And it can recover from a failure by replaying the log rather than restoring a backup that may be stale. These are not separate features bolted on; they are consequences of treating events as the system of record, which is a defining choice of a modern architecture.

Treating the event log as the system of record is a profound design choice with far-reaching consequences, and it is worth understanding why it is so powerful. When the log is the truth and state is a projection, the system gains a kind of time travel: any past state can be reconstructed by replaying the log to a point, any current state can be rederived if it is lost, and the full history of how the present came to be is always available. These are not features that had to be built; they fall out of the design, which is what makes event-sourced architectures so capable in exactly the areas, audit, reproducibility, recovery, where trading businesses are most tested.

The event-log design also changes how the system handles change and error. Because state is derived from the log, a correction is a new event rather than an overwrite, so the history of what was believed and when is preserved, which is exactly what an audit requires. A mistake can be understood by examining the events that led to it, and corrected by appending events that fix it, without destroying the record of the error. This append-only, derive-state model is more honest about history than a system that overwrites, and that honesty is precisely what makes it trustworthy under scrutiny.

Ask whether the platform treats its event log as the system of record, with state as a projection that can be rederived, because that design is what gives the architecture its time-travel: reconstruct any past state, rederive any lost state, and see the full history of how the present came to be. A platform built this way handles audit, reproducibility, and recovery as consequences of its design; one that overwrites state and keeps a separate audit log provides these, if at all, through bolted-on systems that must themselves be reconciled.

An event-driven architecture does not abolish batch processing; it puts it where it belongs. Some computations are genuinely periodic and portfolio-wide, value-at-risk across the whole book, counterparty exposure, regulatory reports as of a cutoff, and these are naturally scheduled rather than triggered by each event. The point of the event-driven core is not that nothing is ever batched but that the real-time propagation of individual changes is handled by events, while the heavy periodic computations are scheduled, and crucially both run on the same governed positions.

This is the two-speed rhythm: frequent, lightweight event-driven updates for the intraday view, and scheduled heavy runs for the portfolio measures. Because both operate on the same governed model, the intraday view and the batch view never disagree about what the book contains, which is exactly the property a legacy batch architecture cannot provide, because there the intraday copy and the batch copy are different data. A modern architecture uses events and batch together, each for what it suits, on one shared foundation.

Putting batch where it belongs is a mark of architectural maturity, because it resists two opposite errors. One error is the legacy assumption that everything is batch, which forces even individual changes through an overnight cycle and produces the batch-window tyranny. The opposite error is an over-reaction that tries to make everything real-time, including portfolio-wide computations that are naturally periodic, which wastes effort making instantaneous things that no one needs instantaneously. The mature architecture uses events for propagation and schedule for portfolio runs, each for what it suits.

The crucial property is that the scheduled runs and the real-time views operate on the same governed positions, which is what a legacy batch architecture cannot achieve. In a legacy system, the intraday view and the overnight batch run on different copies, so they can disagree, and reconciling them is another chore. In a modern architecture, both draw on the one governed model, so the overnight value-at-risk is computed on exactly the positions the desk saw intraday. The two speeds are two views of one truth, not two truths to reconcile, and that unity is what makes the two-speed rhythm trustworthy.

Check that the platform puts batch where it belongs, scheduling the genuinely periodic portfolio runs while propagating individual changes by event, and crucially that both run on the same governed positions. The revealing question is whether the overnight value-at-risk is computed on exactly the positions the desk saw intraday, or on a separate copy that must be reconciled. A modern architecture makes the two speeds two views of one truth; a legacy one makes them two truths to reconcile.

Every capability is exposed as a governed interface, REST, GraphQL, webhooks, streaming, and the platform’s own user interface is just another consumer of the same APIs. This is what API-first means: not that an API exists alongside the product, but that the API is the product and everything else is built on it. That property is what makes the platform integrate cleanly into an existing landscape rather than becoming a silo, and it is what lets you build your own edge on top of the bought lifecycle.

API-first access must be disciplined to be useful over a decade. The interfaces must be versioned, so that integrations built once keep working; breaking changes must be communicated and old versions supported for a stated period; and the same access model must govern both human users and the machine identities that integrations use. An API that exists but breaks with every upgrade is worse than useless, because it invites integrations that then shatter. The discipline of versioning is what turns an API surface from a liability into the durable foundation of the architecture.

API-first is the property that determines how a platform lives in the world, and it is frequently claimed and rarely delivered in full. The distinction that matters is between a platform that has an API and a platform that is its API. The former added an interface as a feature, exposing some capabilities while keeping the product’s real workings private; the latter built the product on the interface, so everything the product does is reachable through the same governed API a customer uses. Only the latter is genuinely API-first, and only the latter can be composed with rather than merely connected to.

The discipline of versioning is what separates an API you can build a business on from one that will betray you. An unversioned API that changes with each release turns every integration into a maintenance liability, because your code breaks whenever the platform changes. A properly versioned API, with breaking changes managed and old versions supported for a stated period, lets you build integrations and edge that endure across the platform’s evolution. When the strategy is to build on the platform, the API’s versioning policy is not a technical detail but a determinant of whether your investment in building on it will survive.

Weight the API’s depth and versioning discipline heavily when you evaluate, because for any strategy that involves building on the platform they determine whether your investment endures. Ask what the API exposes, whether it covers the full lifecycle, and what the versioning policy and history of breaking changes are. A genuinely API-first platform, where the API is the product rather than a feature, with disciplined versioning, is one you can build a lasting edge on; a thin or unstable API confines you to fragile integrations.

A revealing test of whether a platform is genuinely API-first is whether its own user interface is built on the same public APIs that customers use, or on a private back door. If the platform’s screens use the same interfaces you would use to integrate, then those interfaces are necessarily complete, because the platform itself depends on them, and they are necessarily maintained, because breaking them would break the platform’s own UI. If the UI uses a private path, the public API may be a thin afterthought, incomplete and neglected, whatever the marketing claims.

This principle, that the UI is just another API consumer, is what guarantees the depth and durability of the API surface. It aligns the vendor’s incentives with the customer’s: the vendor must keep the API complete and stable because its own product depends on it, so the customer building on that API benefits from the same care the vendor takes for itself. When evaluating a platform’s API-first credentials, ask directly whether the UI is built on the public API, because the answer distinguishes a genuinely API-first platform from one that added an API as a feature.

The UI-as-API-consumer test is valuable precisely because it is hard to fake: either the platform’s screens genuinely use the public API, or they do not, and the answer is verifiable. A vendor whose UI uses the public API has committed to keeping that API complete and stable, because its own product depends on it, so the customer building on the API inherits that commitment. A vendor whose UI uses a private path has no such incentive, and the public API can be neglected, incomplete, and unstable, whatever the marketing says about openness.

This alignment of incentives is the deeper reason the test matters. In software, an interface used only by outsiders tends to decay, because breaking it inconveniences only outsiders; an interface the provider depends on stays healthy, because breaking it hurts the provider. A platform whose UI is an API consumer has made the API an interface it depends on, which is the strongest possible guarantee of the API’s health. When evaluating for the both option, where you intend to build on the API, this guarantee is worth more than any promise, because it is enforced by the vendor’s own dependence.

Apply the UI-as-API-consumer test directly: ask whether the platform’s own screens are built on the same public APIs you would use to integrate. A yes guarantees the API is complete and maintained, because the vendor’s own product depends on it, aligning the vendor’s incentives with yours. A no is a warning that the public API may be a neglected afterthought however open the marketing sounds. This one question distinguishes genuine API-first from an API added as a feature more reliably than any brochure.

API-first access is what makes a platform composable rather than merely connectable. A composable platform can participate in an event-driven estate: it emits events other systems can react to, consumes events they emit, and exposes its capabilities for other systems and your own code to build on. A merely connectable platform can exchange data through files and interfaces but sits in the estate as an island, something data is shipped to and from rather than composed with. The difference determines how freely the platform fits into and evolves with the landscape around it.

Composability matters increasingly as trading businesses want to build their own edge on top of their platforms, as the build-versus-buy handbook describes. A composable, API-first platform is a foundation you can build on; a connectable one is a destination you can only send data to. When the strategy is to buy the lifecycle and build the differentiation, the composability of the platform is not a secondary technical property but the very thing that makes the strategy possible, and it should be evaluated as carefully as the lifecycle itself.

Composability is becoming the property that most distinguishes platforms as trading businesses grow more sophisticated in what they build. A connectable platform, one you can send data to and receive data from, was sufficient when the goal was integration. A composable platform, one whose capabilities you can build on and whose events you can react to, is what the goal now requires, because businesses increasingly want to build their edge on top of a bought lifecycle rather than accept the platform as delivered. The shift from connectable to composable is the shift from a platform as a destination to a platform as a foundation.

The practical implication is that composability should be evaluated against your intention to build, not in the abstract. If you intend to buy the lifecycle and build your edge on top, as the build-versus-buy handbook recommends, then the platform’s composability is the very thing that makes your strategy possible, and a merely connectable platform will frustrate it. Ask specifically what you would be able to build on the platform: can you react to its events, extend its behaviour, compose your logic with its lifecycle? The answer determines whether the platform is a foundation for your edge or a wall around it.

Evaluate composability against your intention to build, not in the abstract: ask specifically what you would be able to build on the platform, whether you can react to its events, extend its behaviour, and compose your logic with its lifecycle. If your strategy is to buy the lifecycle and build your edge on top, composability is the very thing that makes it possible, and a merely connectable platform, one you can only send data to and from, will frustrate the strategy however well it integrates.

Rather than exporting nightly to a separate warehouse and reconciling before anyone trusts a number, the architecture materialises governed analytical marts over the same data the operation runs on, with conformed dimensions and a semantic layer, so business intelligence runs on trusted data with lineage back to the trade. The analytical layer is not a separate system fed by an export; it is a governed projection of the same model, which is why its numbers match the operation by construction. See the BI & OLAP layer for the implementation.

This matters because the alternative, a nightly export to a separate warehouse, reintroduces exactly the problem the governed model solved: two copies of the data that can disagree. A report built on last night’s export can differ from the live operation, and the organisation is back to reconciling and to distrusting its own numbers. Keeping analytics on the same governed data, materialised for query performance but never diverging from the operational truth, preserves the single-version-of-the-truth property all the way through to the boardroom report.

Analytics on the same data is the property that carries the single-version-of-the-truth all the way to the people who make strategy, and its absence is where many otherwise-modern operations quietly fail. A firm can have a governed operational model and still export nightly to a separate warehouse for analytics, reintroducing the copy-and-reconcile problem exactly where it most misleads, in the management information that shapes decisions. Keeping analytics on the governed data is what ensures that the numbers the board sees are the numbers the desk trades against, traceable to the same trades.

The productivity benefit of shared analytics is as important as the trust benefit, though it is less often noticed. When analytics run on the governed model, a new analysis is a query against trusted, defined data; when they run on an export, every new analysis must first navigate the export and reconciliation and establish its trustworthiness before anyone relies on it. The shared-analytics architecture therefore does not only make the numbers trustworthy but makes producing new analysis faster, because the trust is inherited from the governed data rather than re-earned for each report, which compounds into a real difference in how quickly the organisation can answer new questions.

Confirm that analytics run on the same governed data as the operation, not on a nightly export, because the export reintroduces the copy-and-reconcile problem exactly where it most misleads, in the management information that shapes decisions. Ask whether a new analysis queries the governed model directly or must navigate an export and establish its trustworthiness first. Shared analytics make the board’s numbers match the desk’s by construction, and make new analysis faster because trust is inherited from the governed data rather than re-earned.

A modern analytical architecture includes a semantic layer: a governed definition of business terms, metrics, and dimensions that sits between the raw data and the people querying it. When everyone’s report draws its definition of exposure, profit, or position from one governed semantic layer, those terms mean the same thing across every report, and numbers reconcile because they are computed from the same definitions. Without a semantic layer, each report defines its terms afresh, and the same word comes to mean subtly different things in different reports, which is how organisations end up arguing about whose number is right.

The semantic layer is the analytical counterpart of the governed model: just as the governed model gives one authoritative version of each fact, the semantic layer gives one authoritative definition of each metric. Together they mean that a number in a boardroom report can be traced not only to the trades beneath it but to the agreed definition that computed it. This is what makes management information trustworthy: not only that the data is right but that everyone means the same thing by the terms, which is a discipline the semantic layer enforces and its absence quietly erodes.

The semantic layer is the discipline that stops an organisation arguing about whose number is right, which is a more common and more corrosive problem than it first appears. When each report defines its own terms, exposure computed one way here and another way there, the same word means different things in different places, and reconciling reports becomes a recurring argument about definitions rather than data. The semantic layer ends this by giving one governed definition of each metric that every report draws on, so the same word means the same thing everywhere and numbers reconcile because they share a definition.

The semantic layer completes the architecture’s single-version-of-the-truth by extending it from data to meaning. The governed model ensures one version of each fact; the semantic layer ensures one definition of each metric computed from those facts. Together they mean a number is trustworthy in two senses: the data beneath it is right, and the definition that computed it is agreed. This is what lets an organisation trust its own management information without the recurring reconciliation of definitions that plagues operations where every analyst defines the metrics afresh, and it is a property worth looking for explicitly in a platform’s analytical layer.

Look for a semantic layer in the analytical architecture: one governed definition of each business term and metric that every report draws on, so the same word means the same thing everywhere and numbers reconcile because they share a definition. Its absence is why organisations argue about whose number is right, each report having defined its terms afresh. The semantic layer completes the single-version-of-the-truth by extending it from data to meaning, and it is worth confirming explicitly rather than assuming.

Trading workloads are spiky. Intraday valuation is light and continuous; the overnight value-at-risk, counterparty exposure, and scenario runs are heavy and periodic. A modern architecture meets this with elastic compute: it borrows capacity for the heavy runs and releases it afterward, so the business pays for the peak only while it needs it rather than owning a permanent peak that sits idle most of the time. This is both an economic property, it converts a large fixed cost into a smaller variable one, and a capability property, it lets the whole book be stressed within the operational window rather than sampled because the hardware cannot cope.

The two-speed rhythm of a modern platform depends on elastic compute to be affordable. On fixed on-premises hardware, the heavy runs must be sized for and the capacity owned year-round; on elastic compute they draw capacity on demand. The architectural point is that the same governed positions feed both the light and the heavy runs, so the intraday and the batch views never disagree, and elastic compute is what makes running both economical. It is the mechanism that lets a modern architecture offer both real-time responsiveness and heavy periodic analysis without owning a permanent peak.

Elastic compute is the property that makes the economics of a modern architecture work, because it aligns the cost of capacity with the need for it. Trading’s spiky workload, light and continuous intraday, heavy and periodic overnight, is exactly the shape that punishes fixed capacity, because fixed capacity must be sized for the peak and sits idle the rest of the time. Elastic compute matches capacity to the workload’s shape, summoning it for the heavy runs and releasing it after, so the business pays for the peak only while it uses it. This alignment is what makes running both the light and heavy workloads affordable.

Beyond economics, elastic compute lifts a ceiling on risk management that fixed capacity imposes. On owned hardware, the overnight risk suite is constrained by the capacity that can be afforded and the time available, so the number of scenarios, the granularity, and the frequency are all compromises. Elastic compute loosens these constraints, because capacity can be summoned for the run, letting the firm run more scenarios at finer granularity more often. Better risk measurement is a direct consequence, so elastic compute is not only a cost property but a capability one, improving how well the firm can see its risk.

Assess how the platform handles the spiky trading workload: does it use elastic compute to summon capacity for the heavy overnight runs and release it after, or does it own a fixed peak that sits idle most of the time? Then ask what better risk measurement elastic capacity would enable, more scenarios, finer granularity, more frequent runs, because elastic compute is not only cheaper than a fixed peak but lifts a ceiling on how well you can see your risk. Both the economic and capability gains are worth naming.

A modern architecture scales differently from a legacy one, and the difference matters as a business grows. A legacy platform scales by buying bigger hardware, a planned, capitalised step change that must be sized for a future guessed in advance. A modern platform scales by using more of an elastic resource, smoothly and on demand, so growth does not require a hardware project. This means a modern platform can absorb growth in volume, in the number of scenarios, in the frequency of runs, without the disruptive capacity planning that a legacy platform requires.

Performance in a modern architecture is also a matter of design rather than only of hardware. Because the architecture separates the real-time event-driven path from the heavy scheduled path, each can be optimised for its purpose: the event path for low latency, the scheduled path for throughput. And because compute is elastic, the heavy path can be given more capacity when it needs it rather than being constrained by a fixed allocation. The result is a platform that stays responsive intraday and completes its heavy runs within the window, at a scale that follows the business rather than being fixed ahead of it.

Scalability in a modern architecture is qualitatively different from the legacy kind, and the difference compounds as a business grows. Legacy scaling is a series of discrete, disruptive hardware projects, each sized for a guessed future and each a planned capital event. Modern scaling is continuous and automatic, capacity following demand without a project, so growth is absorbed rather than provisioned for. For a business whose volumes grow or fluctuate, this is the difference between a platform that keeps pace effortlessly and one that requires periodic, disruptive, guess-based expansion.

Performance in a modern architecture benefits from the separation of the real-time and scheduled paths, which lets each be optimised for its purpose rather than compromised to serve both. The event-driven path is tuned for low latency, so changes propagate in seconds; the scheduled path is tuned for throughput, so the heavy runs complete within the window; and elastic compute gives the scheduled path more capacity when it needs it. This separation, impossible in a monolithic batch architecture where everything shares one path, is part of why a modern platform can be both responsive intraday and capable of heavy overnight analysis at scale.

Ask how the platform scales as your volumes grow: smoothly and on demand through elastic resources, or through planned, disruptive hardware projects sized for a guessed future? And confirm that the real-time and scheduled paths are separated, so each is optimised for its purpose rather than compromised to serve both. A platform that scales continuously and separates its paths keeps pace with growth effortlessly and stays both responsive intraday and capable of heavy overnight analysis, which fixed-capacity monolithic architectures cannot.

Security in a modern architecture is a property of the design rather than a layer added afterward. Access is governed centrally and consistently, so the same model controls what every user and every machine identity can do; every consequential action is logged, because it is an event on the durable log; and the platform’s controls are documented and, in a managed service, independently certified against standards like SOC 2 and ISO 27001. This is a stronger and more demonstrable posture than a legacy platform assembles from access controls spread across modules and assurance gathered by hand.

The event-driven core contributes directly to the security posture, because the same log that provides auditability provides a complete, tamper-evident record of who did what and when. There is no separate audit system to maintain and reconcile; the audit trail is a property of how the architecture works. For a regulated trading business, this means compliance can be evidenced from the architecture rather than demonstrated by effort, which is a recurring saving in time, cost, and regulatory risk, and a reason the architecture matters for compliance as much as for operations.

Security as a property of the design, rather than a layer added afterward, is one of the clearest advantages of a modern architecture, and it is worth understanding why the design produces it. Centralised access control follows from having one governed model with one access model, rather than access controls scattered across modules. Comprehensive logging follows from the event-driven core, where every consequential action is already an event on the durable log. Certified controls follow from the managed-service delivery, where the provider certifies the platform for all customers. Each security property is a consequence of the architecture, not an addition to it.

The compliance advantage that follows is substantial for a regulated trading business. When the audit trail is a property of how the system works, the event log, rather than a separate system to maintain, and when access is governed centrally and controls are certified, compliance can be evidenced from the architecture rather than assembled under the pressure of an examination. This turns each regulatory interaction from a project into a demonstration, which is a recurring saving in time, cost, and risk, and a reason the architecture matters as much to the compliance function as to the trading desk.

Evaluate security as a property of the design, not a layer added on: is access governed centrally through one model, is every consequential action logged as an event on the durable log, and are the controls independently certified against standards like SOC 2 and ISO 27001? Then ask how the platform makes compliance demonstrable, because a modern architecture evidences compliance from the event log and certified controls rather than assembling it under examination, which is a recurring saving for any regulated trading business.

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 a commercial property, it lets an organisation meet data-residency or sovereignty requirements without abandoning the architecture, and it is also a disaster-recovery property: an environment defined as code can be recreated, not merely restored, which shortens recovery and makes recovery testing routine rather than heroic.

Reproducible infrastructure also changes how the platform is operated and upgraded. Environments for development, testing, user acceptance, and disaster recovery can be stood up identically from the same definition, so testing happens against a true copy of production rather than an approximation. Upgrades become continuous and low-risk rather than big-bang events, because the infrastructure and the deployment are versioned and repeatable. The deploy-anywhere property, in other words, is not only about where the platform runs but about how safely and cheaply it can be changed.

The deploy-anywhere property resolves what looks like a conflict between modern architecture and requirements like data residency, and understanding the resolution is valuable. It might seem that residency rules, which require data to stay in a jurisdiction, favour a legacy on-premises platform pinned to one data centre. But a modern architecture defined as reproducible infrastructure can be deployed in whichever region the law requires, keeping the data local while preserving every architectural property. Residency becomes a deployment choice rather than an architectural sacrifice, which is a genuine advantage of the reproducible-infrastructure approach.

The disaster-recovery dimension of deploy-anywhere is equally important and often underappreciated. Because the environment is defined as code, recovery means recreating the environment from its definition, which is faster and more reliable than restoring a hand-built environment from backups, and it can be tested routinely because recreating an environment is a repeatable operation rather than a heroic one. The same property that lets the architecture run anywhere lets it be recovered anywhere, which is why deploy-anywhere is both a commercial property, meeting residency and deployment preferences, and a resilience property, making recovery a recreate rather than a restore.

If you have residency or deployment constraints, ask how the platform’s reproducible infrastructure meets them: can the same architecture be deployed in the region the law requires, keeping data local while preserving every property? And ask how recovery works, because an environment defined as code is recreated rather than restored, which is faster and testable routinely. Deploy-anywhere resolves the apparent conflict between modern architecture and residency, turning it into a deployment choice rather than an architectural sacrifice.

The deploy-anywhere property rests on defining infrastructure as code: the servers, networks, and configuration that make up an environment are described in versioned definitions from which the environment can be created reliably and repeatably. This is what lets the same architecture run in different places, because the environment is a definition to be instantiated rather than a hand-built artefact tied to one location. It is also what makes environments consistent, because development, test, and production are created from the same definition rather than assembled separately and hoped to match.

Reproducible infrastructure enables continuous delivery, the practice of deploying small, frequent, low-risk changes rather than large, infrequent, high-risk ones. Because the infrastructure and the deployment are versioned and repeatable, a change can be deployed, verified, and if necessary reversed, with confidence and without ceremony. This is the opposite of the legacy big-bang upgrade, and it means a modern platform stays current continuously rather than ageing between perilous upgrades. Reproducible infrastructure and continuous delivery are the mechanisms behind the deploy-anywhere and always-current properties that distinguish a modern architecture.

Reproducible infrastructure is the technical foundation beneath several of the architecture’s most valuable properties, and it is worth making the connection explicit. Deploy-anywhere depends on it, because the environment must be a definition to be instantiated in different places. Consistent environments depend on it, because development, test, and production must be created from the same definition to match. Continuous delivery depends on it, because low-risk frequent deployment requires that infrastructure and deployment be versioned and repeatable. Reproducible infrastructure is thus not a separate feature but the substrate that makes portability, consistency, and continuous delivery possible.

Continuous delivery, which reproducible infrastructure enables, is the property that keeps a modern platform perpetually current rather than ageing between upgrades. Because changes are small, frequent, and low-risk, the platform improves continuously and never accumulates the backlog of unadopted change that makes legacy upgrades so perilous. The customer is always on a current version, always receiving improvements and security fixes, and never facing the big-bang upgrade project that legacy platforms impose. This always-current property is a direct consequence of reproducible infrastructure and continuous delivery, and it removes one of the largest recurring costs and risks of the legacy model.

Confirm that the platform is defined as reproducible infrastructure and delivered continuously, because these underpin portability, consistent environments, and always-current software. Ask whether development, test, and production are created from the same definition, so testing reflects production, and whether upgrades are continuous and low-risk or periodic and big-bang. A platform built on reproducible infrastructure with continuous delivery stays perpetually current and avoids the perilous, expensive upgrade projects that ageing legacy platforms impose.

The four properties of a modern architecture are not a checklist of independent features but a mutually reinforcing whole, and understanding how they reinforce one another is the key to the architecture. The governed model makes the event-driven core meaningful, because the events update one authoritative model rather than propagating between copies. The event-driven core makes API-first access powerful, because the platform can emit events for consumers to react to. API-first access makes shared analytics possible, because the analytical layer draws on the same governed data through the same interfaces. Each property depends on and amplifies the others.

This is why a platform cannot have a little of each property and be modern; the properties must be present together to reinforce one another. A governed model without an event-driven core cannot propagate changes in real time. An event-driven core without a governed model propagates changes between copies that still reconcile. API-first access without a governed model exposes fragmented data. Shared analytics without the other three has nothing consistent to analyse. The architecture is a system, and its value comes from the combination, which is why the buyer must evaluate all four properties together rather than any one alone.

The mutual reinforcement of the four properties is the single most important idea in this handbook, because it is what makes architecture a system rather than a feature list, and it is what a superficial evaluation misses. A buyer who checks each property independently and finds all four present may still be buying a platform that is not well architected, if the properties do not connect: a governed model the events do not update in real time, an API that does not expose those events, analytics fed by an export rather than the model. The properties must not only be present but interlock, and the interlocking is the architecture.

This is why the deepest evaluation question is not is each property present but do the properties reinforce one another. Ask whether the events update the governed model directly, whether the API exposes the events, whether the analytics draw on the governed model through the API, whether the whole is defined as reproducible infrastructure. A platform where the properties interlock has a coherent architecture whose value exceeds the sum of its properties; one where they are present but disconnected has a collection of features that will not deliver the economics the architecture promises. The reinforcement is the point, and it is what the buyer must verify.

Ask the deepest architectural question of any platform: do the four properties reinforce one another, or are they merely present? Verify that the events update the governed model, that the API exposes those events, that analytics draw on the governed model through the API, and that the whole is reproducible infrastructure. A platform where the properties interlock has a coherent architecture worth more than the sum of its properties; one where they are present but disconnected will not deliver the economics the architecture promises, however each property scores alone.

The value of a reference architecture is as a yardstick. When a vendor says modern architecture, the four properties give you the questions that reveal whether the word means anything: does every function read and write one governed model, or are there copies that reconcile? Does a booked trade propagate to risk in seconds by event, or in a batch? Is the platform’s own screen just another API consumer, and are the APIs versioned? Does analytics run on the same governed data or on a nightly export? Can the environment be recreated from code? A platform that answers these well is well architected; one that deflects them is not, whatever the brochure says.

The architecture-maturity assessment accompanying this handbook turns these questions into a scored evaluation across the four properties, so that architecture, the least visible and most consequential property of a platform, can be judged deliberately rather than taken on faith. Use it to hold every platform, including any you might build, to the same standard, and to make the architecture of your trading operation a decision rather than an accident. The assessment does not replace judgement, but it structures it, ensuring every property is examined and none is assumed.

Judging an architecture deliberately, with a structured assessment, is what turns architecture from the thing a buyer hopes is sound into the thing a buyer has verified is sound. The temptation is to take architecture on faith, because it is hard to see and the vendor is confident, but faith is a poor basis for a decision that will shape the operation for a decade. The four properties, turned into specific questions and scored, make architecture examinable, so the buyer can hold every platform to the same standard and choose on evidence rather than on the impression the demonstration left.

The assessment’s value is as much in the discipline it imposes as in the score it produces. By requiring each property to be examined and scored, it prevents the evaluation from skipping the hard, invisible architectural questions in favour of the easy, visible feature ones. It ensures that the governed model, the event-driven core, the API-first access, and the shared analytics are each probed with concrete questions, and that a platform strong on features but weak on architecture is revealed rather than flattered. The score matters, but the discipline of the examination matters more, because it is what makes the invisible architecture visible enough to weigh.

Use a structured maturity assessment to judge architecture deliberately rather than on faith, scoring each of the four properties with concrete questions so the invisible, decisive architecture becomes examinable. The discipline the assessment imposes, forcing each property to be probed rather than assumed, is as valuable as the score, because it prevents the evaluation from skipping the hard architectural questions for the easy feature ones. Hold every platform, including any you might build, to the same standard, and choose on evidence.

Certain architectural anti-patterns recur, and recognising them helps a buyer see past a modern surface to a legacy reality. The reconciling suite presents several modules as one product but reconciles between them internally, so it has the seams of a many-model system beneath a unified interface. The batch platform with a real-time screen shows fast-updating numbers that are front-office estimates reconciled later against authoritative batch figures, so its real-time is cosmetic. The API-as-afterthought exposes a thin, incomplete interface alongside a product built on a private path, so it is connectable but not composable.

Another anti-pattern is the export-and-reconcile analytics layer, which ships data nightly to a separate warehouse and reconciles it, reintroducing the copy problem in the analytical layer however modern the operational platform appears. And the customisation-dependent platform meets specific needs by modifying its own code, creating a bespoke version that cannot be upgraded and deepens lock-in. Each anti-pattern is a way a platform can appear modern while lacking one of the four properties, and each has a diagnostic question, about the data path, the reconciliation, the API, or the change mechanism, that reveals it.

Recognising the anti-patterns is a practical skill that lets a buyer see through a modern presentation to the architecture beneath, and each anti-pattern has a diagnostic question that exposes it. For the reconciling suite, ask whether the modules share one model or reconcile between copies. For the batch platform with a real-time screen, ask whether the fast number is the trusted number or an estimate reconciled later. For the API-as-afterthought, ask whether the UI uses the public API. For the export-and-reconcile analytics, ask whether analytics run on the governed model or a nightly export. Each question cuts through the presentation to the reality.

The value of naming the anti-patterns is that they are the specific ways a platform can appear modern while lacking the substance, and a buyer who knows them is much harder to mislead. A platform exhibiting an anti-pattern is not necessarily dishonest; it may genuinely believe its unified interface makes it single-model, or its fast screen makes it real-time. But the buyer’s job is to see past the appearance to the architecture, and knowing the anti-patterns, and their diagnostic questions, is what makes that possible. The anti-patterns are, in effect, a checklist of the ways the four properties can be simulated rather than delivered.

Learn the anti-patterns and their diagnostic questions, because they are the specific ways a platform can appear modern while lacking the substance: the reconciling suite, the batch platform with a real-time screen, the API-as-afterthought, the export-and-reconcile analytics, the customisation-dependent platform. For each, one concrete question, about the data path, the reconciliation, the API, or the change mechanism, cuts through the presentation to the reality. Knowing them makes you much harder to mislead about whether an architecture is genuinely modern.

For the reader who is not only buying but shaping a platform, whether influencing a vendor’s roadmap, building on top of a bought platform, or architecting in-house, the reference gives a direction to design toward. Put a governed model at the centre and make every function read and write it. Propagate change by events on a durable log, and treat that log as the system of record. Expose every capability through versioned APIs, and build even your own interfaces on them. Run analytics on the same governed data through a semantic layer. Define infrastructure as code so the whole is portable and continuously deliverable.

These are design principles, not a product, and they apply whether the architecture is bought, built, or composed. A firm building its edge on a bought platform should ensure its own components honour the same principles, reading the governed model, reacting to events, exposing versioned interfaces, so that the built and bought parts form a coherent whole rather than a modern platform with a legacy extension. Designing toward the architecture, consistently across bought and built, is what produces an operation whose technology has the properties this handbook describes, by intention rather than by accident.

Designing toward the architecture is the constructive counterpart to judging one, and it matters because many readers will not only buy but shape a platform, whether by influencing a vendor, building on a bought platform, or architecting in-house. The reference gives these readers a direction: a governed model at the centre, change propagated by events on a durable log, capabilities exposed through versioned APIs, analytics on the governed data through a semantic layer, infrastructure as code. These principles apply regardless of whether the architecture is bought, built, or composed, because they describe properties any trading platform benefits from.

The consistency of applying these principles across the bought and built parts is what produces a coherent operation rather than a modern platform with a legacy extension. A firm building its edge on a bought platform should honour the same principles in its own components, reading the governed model, reacting to events, exposing versioned interfaces, so the whole forms one coherent architecture rather than a sound platform undermined by an incoherent addition. Designing toward the architecture, consistently, is how a firm ends up with technology that has the properties this handbook describes by intention rather than by accident, which is the difference between an operation that reconciles and one that does not.

If you are shaping a platform, whether influencing a vendor, building on a bought one, or architecting in-house, design toward the reference: a governed model at the centre, change propagated by events on a durable log, capabilities exposed through versioned APIs, analytics on the governed data through a semantic layer, infrastructure as code. Apply the same principles to your own built components as to the bought platform, so the whole forms one coherent architecture rather than a sound platform undermined by an incoherent extension. Consistency is what produces the properties by intention.