Why Trading Technology Is a Systems Problem

Ask someone to picture trading software and they will usually describe the screen: a price chart, an order ticket, perhaps a table of positions with numbers turning green and red. That is the part users see, and it matters. It is also a small fraction of what makes such a system work, and very little of what makes it hard.

The difficult parts are underneath. Prices arrive from one place, orders go to another, confirmations come back from a third, and all of them can be delayed, reordered, duplicated or lost. The platform must maintain an accurate picture of the world from those fragments, act on it within limits, and be able to explain afterwards exactly what it did and why. That is less a finance problem than a distributed systems problem with money attached.

An order is a state machine you do not fully control

In most software, when you save a record, it is saved. In trading, when you place an order, you have made a request to a system you do not own, and you will learn what happened to it later, in pieces.

An order passes through a sequence of states. It is created inside your system, checked against rules, sent to the broker, acknowledged by the broker, forwarded to the exchange, and then filled, partly filled, rejected, cancelled or expired. Some of those transitions are yours. Most are not. Each one arrives as a message, and the messages do not always arrive in order, or at all.

The most dangerous state is the one between sending and acknowledgement. The order has left your system; you do not yet know whether it reached its destination. If the connection drops at that moment, the platform faces a genuinely hard question. Resending risks a duplicate order. Not resending risks a missing one. The correct answer is neither: it is to query the broker for the order's actual status before doing anything else, and to design the system so that every outbound order carries an identifier that makes that query possible.

Getting this right is not glamorous. It involves careful handling of timeouts, idempotent request identifiers, and a clear rule that the platform never assumes an outcome it has not confirmed. It is also the difference between a system that behaves sensibly on a bad network day and one that quietly doubles a position.

Two sources of truth, and a reconciliation

A trading platform keeps its own record of orders and positions, because it needs one to make decisions quickly. The broker keeps its own record too, and the broker's is authoritative. Most of the time the two agree. The interesting engineering is in the moments they don't.

A fill notification might be missed during a reconnection. A position might be changed outside the platform, by the account holder placing a manual trade or by a corporate action. An order might be cancelled by the broker at the end of a session. In each case, the platform's internal picture has drifted from reality.

Well-built systems treat this as normal. They reconcile regularly, comparing internal state with the broker's and resolving differences in the broker's favour. They surface discrepancies to the user rather than hiding them. And they refuse to act on a position they are not confident about, because an automated system trading on a wrong belief about its own holdings is one of the more expensive failure modes in this field.

The platform should never assume an outcome it has not confirmed. Most of the hard engineering follows from that one rule.

Latency is mostly about knowing how old things are

Latency gets a great deal of attention in trading technology, and for some participants, such as those operating at exchange-colocated speeds, microseconds genuinely matter. For most systematic and retail workflows, the more useful question is different. It is not "how fast is this price?" but "how old is this price, and do I know?"

A price that is two seconds old is fine for some decisions and dangerous for others. What matters is that the system knows its age. That means timestamping data when it arrives, tracking the gap between the exchange's time and your own, and detecting when a feed has gone quiet. A feed that stops updating does not announce itself: the last price simply stays on the screen, looking perfectly current. Systems that do not watch for staleness will happily make decisions on a market that has moved on.

Consistency matters as much as speed. A system with predictable, moderate latency is often easier to reason about, and to test, than one that is usually fast and occasionally very slow.

Every broker is a little different

Connecting to one broker is an integration project. Connecting to several is an exercise in managing difference. Order types that look identical have different names, parameters and validation rules. Error responses vary in format and meaning. Sessions expire on different schedules. Rate limits differ, and so does their enforcement.

The architectural answer is to contain the difference. In AlphaSync, which routes orders through the official APIs of five Indian brokers, each broker has its own adapter that translates between the broker's conventions and a single internal model. Strategies speak one language. Adapters absorb the variation. When a broker changes its API, the change is confined to one component.

This is a general pattern for any system with multiple external dependencies, but trading makes its value unusually clear, because the cost of a misinterpreted response can be an order that does something nobody intended.

Risk belongs in the path, not beside it

A common early design places risk checks alongside the strategy: the strategy decides what to do, and also checks whether it is allowed. This works until it doesn't. A bug in the strategy is now also a bug in the controls meant to contain it.

A sturdier arrangement puts a separate risk layer in the path between every decision and every order. No strategy can talk to a broker directly. Every intended order passes through checks that the strategy cannot bypass: position size, per-trade loss limits, daily loss limits, margin utilisation, and an emergency stop that halts activity entirely. The risk layer has one job and a simple, auditable set of rules. It does not need to be clever. It needs to be reliable and impossible to route around.

This is the architecture AlphaSync is built on, and it reflects a broader principle: controls are most trustworthy when they are structurally separate from the thing they control. The case study describes the pipeline in more detail.

Designing for the bad day

Trading systems meet failure constantly, in small forms. A connection drops and reconnects. A broker rejects an order for a reason that was not anticipated. An exchange halts an instrument. A session ends while an order is still working. Each of these needs a defined response, decided in advance and tested.

The general principles are familiar from other critical systems. Fail safe rather than fail open: when in doubt, stop placing new orders and alert a person. Make the emergency stop simple, fast and always available. Recover by re-establishing facts before resuming activity: reconnect, reconcile, confirm state, then continue. And test failure paths as deliberately as success paths, because in production they will be exercised far more often than anyone expects.

If you cannot reconstruct it, you cannot explain it

When something unexpected happens in a trading system, someone will ask why. The account holder will want to know why an order was placed. A compliance reviewer may want to know what rules were in force. The engineering team will want to know whether the behaviour was a bug.

Answering requires an audit trail that records not just what happened, but what the system knew at the time: the market data it saw, the rule that fired, the risk checks that passed, the order sent, and every response received, each with a reliable timestamp. With that record, most questions can be answered precisely. Without it, they become arguments.

Auditability also shapes monitoring. The most useful alerts in a trading system are rarely about prices. They are about the system's own health: an order that has been pending too long, a position that disagrees with the broker, a feed that has gone stale, a strategy that has hit its daily limit.

The interface should tell the truth about state

All of this eventually reaches the screen, and the screen has an obligation: to represent the system's actual state honestly. An order that has been sent but not acknowledged should look different from one that has been filled. A price that is stale should look stale. A position that has not been reconciled should say so.

Interfaces that smooth over uncertainty to look cleaner do users a disservice. In trading, the worst moments are the ones where a user believes something that isn't true, such as that an order was cancelled when it was filled, or that a strategy was paused when it was still running. Good interface design here is less about visual polish than about making the system's knowledge, and the limits of that knowledge, legible.

A systems problem with consequences

Seen as a whole, trading software is a set of cooperating components, most of them talking to systems outside your control, all of them maintaining state that must be kept consistent under failure. The strategy logic that gets most of the attention is one component among several, and arguably not the hardest.

That is not an argument that technology determines outcomes in markets. It does not, and claims to the contrary deserve scepticism. It is an argument that the technology should do exactly what its users intend, enforce the limits they set, and be able to show its work. Those are engineering properties, and they are achievable. They are what we mean when we describe FinTech as systems work.