Algo trading infrastructure: what a production system needs

The parts

• A market data feed that delivers prices, and knows when it has stopped delivering them.
• A strategy engine that turns prices into decisions.
• An order manager that sends, modifies and cancels orders and tracks each one to its end.
• A state store that survives a restart: what is held, what is working, what has been done today.
• A risk layer that can refuse any order and close any position, whatever the strategy thinks.
• Monitoring that tells a person when something is wrong, and a check on the monitoring itself.

Where it runs

For anything that is not high-frequency, a cloud server in Mumbai is the usual choice: close to the exchanges and the brokers, and reliable.

SEBI's framework requires API orders to come from a static IP address registered with the broker, and one address cannot serve unrelated clients. A design for several accounts therefore starts from one address per client. SEBI's algo trading rules has the detail.

Co-location at the exchange matters only to firms competing on microseconds, and is available through trading members.

Data: the feed that goes quiet

The most dangerous failure is silent. A websocket stays connected and stops sending. The system sees no error, and trades on prices that are minutes old.

A production feed handler measures the age of its last tick, treats silence during market hours as a fault, reconnects and resubscribes, and tells the strategy to stand down until prices are fresh. A strategy should never act on a price it cannot date.

Orders: what the system believes against what is true

An order can be in more states than filled or not. A request can time out with the order live at the exchange. A cancel can cross a fill. A partial fill can be read as none.

So a system must reconcile: at intervals, and before any decision that depends on a position, it asks the broker what is actually open and held, and corrects itself. When the answer is uncertain, the safe action is to find out, not to assume.

Sending an order should also be safe to repeat. If a retry can create a second order, sooner or later it will.

Risk: controls that do not trust the strategy

• A daily loss limit that stops new trading when it is reached.
• Limits on position size and on the number of orders, so a bug cannot send a thousand.
• Price checks on every order: a market order with no protection is an open cheque.
• A kill switch that cancels everything and flattens, tested regularly.
• A defined behaviour for every abnormal day: a sudden holiday, an exchange halt, a broker outage, an expiry.

These belong outside the strategy's own code. The day they are needed is the day the strategy is wrong.

Monitoring: an alert nobody reads is not an alert

Logs are for afterwards. During the session a problem has to reach a person: on their phone, with enough said to act on.

The monitor needs a monitor. If the machine that sends alerts dies, silence looks like health. A dead-man's switch, running somewhere else and expecting a regular heartbeat, turns silence into an alarm.

Security

• API keys and secrets kept out of code and out of chat, readable only by the process that needs them.
• Servers with no open ports beyond what is required, administered through an audited channel.
• Two-factor authentication on the broker and cloud accounts, and no shared logins.
• Every order logged with its time, source and reason.

Testing before money

A system should run in paper mode against live prices, then with the smallest possible size, before it runs for real. Each stage finds a different class of fault: paper trading finds logic errors, small size finds everything the paper broker did not imitate.

It should also be able to replay a past day. When something goes wrong in production, the fastest way to understand it is to run that day again.

Aurevian builds and runs systems of this kind. If you are planning one, write to Aurevian.

Keep reading