Specify automated trading workflows, data and order handling, deployment controls, monitoring, and operational risk procedures.
What it teaches
How a trading system is split into parts that can be reasoned about separately — strategy rules, signal generation, risk checks, order submission and execution — and how much authority to hand each level of automation. The inputs: historical and streaming data validated, deduplicated and normalized into one model, with late events handled rather than assumed away; and the clock — exchange calendars, time zones, session boundaries, event windows and schedulers that behave the same way twice. The decision itself: a signal engine with explicit state, which is what stops a system repeating, contradicting or acting on a stale signal; and a risk engine that holds cash, positions, exposure, open orders and limits, and is consulted before an order exists. The outside world: a broker adapter that submits, queries, cancels and reconciles while treating every status as asynchronous; order type selection, open-order management and fill quality measured against the decision price; and the whole system run on current data with no capital at risk. The controls: scanning and ranking with deduplicated alerts and decisions that expire; duplicate-safe commands, bounded retries, durable state and reconciliation after a timeout; metrics and traces and an immutable audit trail; scoped credentials, separated environments, rotation and a kill switch; reproducible artifacts, gradual rollout and rollback. AI-Assisted and Agentic Trading Workflows covers AI-assisted and agentic workflows, and Automated Trading System Specification and Production Readiness turns all of it into one versioned specification.
Who it is for
Anyone who has a rule set they trust and no idea what it takes to let it run unattended. It assumes you can read a chart, and that risk per trade, position sizing, expectancy and out-of-sample validation already mean something to you — Trading Risk Management and Backtesting and Trading Systems define them. It assumes nothing about distributed systems: idempotency, reconciliation, traces, secret rotation and rollback are introduced here, from the trading problem they solve rather than from the general engineering literature. It also suits the reader who has decided NOT to automate, and wants to know what they would be signing up for: most of this course is about failure — a timeout with unknown state, a duplicate order, a stale price, a credential with more permission than it needs — and none of that goes away because the strategy is good.
Concept dependencies
Architecture defines the boundaries across which market data and clock events travel. Strategy state and risk limits constrain what broker calls and order management may do. Reliability, observability and security work must account for order status arriving out of order. A missing response creates an uncertain state that the system must reconcile; a good strategy alone does not resolve it.
Where the definitions come from
The labs are simplified on purpose, so lessons close with an official reading link to a primary source rather than to a vendor selling an execution platform: FINRA's Regulatory Notice 15-09 on supervision, testing, controls and documentation for algorithmic trading strategies, and the SEC's own summary of Rule 15c3-5, the market-access rule that requires pre-trade financial and regulatory risk controls. Where the subject is engineering rather than regulation, the source is the project that defines the thing: OpenTelemetry on traces, metrics and logs; Kubernetes on liveness and readiness probes; Docker on build practice; the OWASP Secrets Management Cheat Sheet on storing and rotating credentials; and a broker's own published API documentation for paper trading, streaming market data and working with orders — cited as an example of what such an API looks like, not as a recommendation of that broker.
Every lesson still works with no network at all. Each page is entirely self-contained, and the reference links are the only things on it that point off the site.
Lessons
Explanations, examples, interactive tools, and practice questions.
16 lessons
Educational use only — nothing here is trading advice.
This course does not connect to a broker, ingest live market data, place
orders, provide trading signals, or claim that any automated strategy
will be profitable. It teaches how such a system is structured and
controlled; it is not one, and no page here can submit an order.
Data and results scope. All market paths, events,
orders, failures, and portfolio states in these lessons are
deterministic synthetic examples. The course uses stated conventions —
market data, strategy, risk, order and broker responsibilities stay
separate; a network timeout represents unknown state until
reconciliation; automatic execution is treated as the final level of
automation rather than the starting point; AI components produce
advisory proposals while deterministic services retain risk and
execution authority; and deployment begins with paper, shadow and
limited-scope rollout. Every lesson also separates what the market is
doing — buyers accepting higher prices, sellers accepting lower ones,
price balanced, volatility expanding — from what the system is doing,
because latency, a data gap, a risk rejection or an unknown order state
is a fact about your software and not about the market.
Lesson topics
Encoding the strategy
Before anything runs: what the parts of a trading system are, and how much authority each level of automation actually takes. A strategy that lives in your head produces a different trade every time; a strategy encoded as separate rules, signals, risk checks and orders produces the same decision from the same events — which is the minimum condition for everything that follows. These lessons draw the boundaries, then fill them in: the data model events arrive as, the calendar and scheduler that say when a decision is even allowed, and the signal engine whose state is explicit enough that a repeat or a stale value cannot slip through as a new trade.
Receive historical and streaming data, validate timestamps and symbols, remove duplicates, handle late events, and expose one normalized market-data model.
Use exchange calendars, time zones, session boundaries, event windows, and deterministic schedulers instead of assuming every day and minute is tradable.
Convert normalized events into deterministic strategy-state transitions while preventing repeated, contradictory, or stale signals.
Open lesson
Not marked
Lesson topics
Execution and infrastructure
The part that touches money. A risk engine that owns cash, positions, exposure, open orders and limits comes first, because it has to be consulted before an order exists rather than after one is rejected. Then the broker adapter, where the comfortable assumption breaks: a submitted order is not a filled order, a response is not a state, and a status update can arrive out of order or not at all. Then the execution decisions themselves — which order type, how long to leave it working, how much of the available liquidity to take, and what the fill actually cost against the price the decision was made at.
Select order types, manage open orders, control participation, and measure fill quality against the decision price and available liquidity.
Open lesson
Not marked
Lesson topics
Testing and risk controls
Whether the system may be trusted to run, and what happens when it is wrong. Paper trading runs the whole thing on current data with no capital at risk, which is the first place backtest assumptions meet real signal timing, real latency and real fills. Scanners, alerts and an explicit human approval step are the automation level below automatic, and they have failure modes of their own: duplicated alerts, a thesis the reader cannot reconstruct, a decision acted on an hour after it stopped being true. Then the uncomfortable one — a network that times out leaves you not knowing whether an order exists, and only duplicate-safe commands, durable state and reconciliation get you back to certainty.
Run the complete system on current market data without live capital, then compare backtest assumptions with observed signals, latency, and simulated fills.
Design duplicate-safe commands, bounded retries, durable state, reconciliation, and restart behavior for uncertain networks and asynchronous broker updates.
Open lesson
Not marked
Lesson topics
Deployment and monitoring
Running it accountably. Observability first, because a system you cannot measure is a system you are guessing about: data freshness, decision latency, broker latency, error rate, positions and risk, end-to-end traces, and an immutable record of why each decision was made. Then the credentials and the stop: scoped permissions, separated environments, rotation, audited access, and a mechanism that halts new trading immediately and does not depend on the thing it is stopping. Then getting changes into production without changing trading state by accident — reproducible artifacts, configuration separated from code, gradual rollout, and a rollback you have actually tried.
Protect broker credentials, restrict execution permissions, separate environments, audit access, rotate secrets, and provide immediate mechanisms to stop new trading.
Build reproducible artifacts, separate development, paper, and live configuration, validate changes, deploy gradually, and roll back without changing trading state unexpectedly.
Open lesson
Not marked
Lesson topics
AI and production readiness
AI workflows and system specifications. AI-Assisted and Agentic Trading Workflows explains where AI belongs in this system: research, extraction, classification and trade proposals — with market data, rules, risk, permissions and execution controls kept deterministic and auditable, so a proposal is an input to the risk engine and never a substitute for it. Automated Trading System Specification and Production Readiness collects the system components and controls — strategy, data, architecture, risk, broker, reliability, security, deployment, observability, approval and rollback — into one versioned specification, and puts a readiness gate in front of it. That specification documents the methods covered in this Course.
Use AI for research, extraction, classification, and trade proposals while keeping market data, rules, risk, permissions, and execution controls deterministic and auditable.
Combine strategy, data, architecture, risk, broker, reliability, security, deployment, observability, approval, and rollback requirements into one versioned production specification.
Open lesson
Not marked
Recommended background
Tested trading rules, risk management, and backtesting concepts. Software examples explain their trading context.
Interop
Automated Trading System Specification and Production Readiness exports a system specification
The specification lesson documents an automated trading system. It turns the whole course into one document — what the system trades, where its data comes from, what risk it may take, which broker it speaks to, how it was validated, how it is operated, and what AI is permitted to do — and hands that document back to you as a file, so it can outlive the browser tab it was written in.
Format: automated-trading-system-v1
What comes out of it
Automated Trading System Specification and Production Readiness takes the identity and version you gave the system, the
strategy section — type, timeframe, direction, and the automation
level, which is one of alert,
approval or
automatic — the market-data section with
its mode, its maximum acceptable age in seconds and whether it is
normalized, the risk section with its per-trade and gross-exposure
percentages, whether risk is evaluated independently and whether a
kill switch exists, the order section covering idempotency,
reconciliation and the broker adapter, the validation section with
its paper-trading days and shadow-mode flag, the operations section
with observability, security scope, rollout percentage and rollback,
and the AI section, and exports the whole thing as a JSON document
stamped automated-trading-system-v1.
The schema linked beside this is the contract for that shape. It is
worth reading if you would rather keep your systems in your own
notebook or repository: match the shape and the same fields carry
over. All nine top-level members are required, so a specification
that omits its risk section or its validation plan does not
validate — those are the two a hurried system leaves out first. Note
what the shape deliberately does contain: ai.mode
and ai.directExecution are separate fields,
because "an AI is involved" and "an AI can place an order" are
different claims and the specification is not allowed to blur them.
Note also what it does NOT contain: any realized or expected return.
A specification records what a system is permitted to do and what had
to be true before it was allowed to run — never what it earned.
Everything runs in your browser: nothing is uploaded, no broker is
contacted, and there is no account anywhere in this course.