Algorithmic Trading

Part 1 frames the whole course. It defines algorithmic trading honestly, sets out the Indian legal reality a retail algo trader now operates under, sketches the architecture of an automated system, and establishes the rule the rest of the course obeys: everything is built and tested in a sandbox, never on real money, until it has earned trust.

• 1Execution is not analysisAlgorithmic trading is the automation of execution, turning a rule into live orders, and that is a different and harder thing than the analysis and backtesting you already know. This chapter separates the two, previews what the course builds, and sets the honest expectation that automation is a tool for discipline and scale, not an edge. 9 min
• 2The rules you trade underSince 2025 India has a SEBI framework for retail participation in algorithmic trading, and it governs what you may build and run. This chapter explains it plainly: what counts as an algo, the orders-per-second line, White Box versus Black Box, registration and the exchange order tag, the broker as the responsible principal, and the security rules such as static-IP whitelisting. 11 min
• 3The parts of an automated systemAn automated trading system is not one program but several cooperating parts: a data feed, a strategy, a risk gate, an order manager, a broker connection, and a logger. This chapter draws the map the rest of the course fills in, and shows how the parts pass control around a single loop. 9 min
• 4Never test with real moneyThe rule that keeps you solvent while learning is simple. Build and test everything against a simulated broker first, never a live one. This chapter sets up the workbench, states the sandbox-first rule, and introduces the small simulated broker that every runnable example in the course drives, so you learn order handling and live risk with real code and zero rupees at stake. 10 min

Part 2 is the API layer, the machinery by which a program reaches the market. It teaches the shape of a broker's programming interface generically, without naming a broker, and it teaches it read-only first: authenticate safely, read your account and market data, take in a live price stream, and only then place an order. Real broker calls are shown but never run; the paper broker mirrors each one so the code is tested.

• 5How a program reaches the marketA broker API is the set of endpoints a program uses to do what you would otherwise do by hand: log in, read prices, see positions, and send orders. This chapter explains the two shapes it comes in, request-response for actions and a streaming connection for live data, and the practicalities of access tokens and rate limits, using the broker's own official SDK as the preferred route. 10 min
• 6Logging in without getting hackedThe first thing your program does is prove who it is, and the first way beginners get hurt is by handling that badly. This chapter walks through the login and token flow, the static-IP whitelisting the framework requires, and the non-negotiable habits: never hardcode a key, never commit a secret, keep credentials out of the code. 10 min
• 7Asking the broker what is trueBefore placing a single order, a program should be able to read the account and the market: available funds, current positions and holdings, a live quote, and historical candles. This chapter covers the read endpoints, which are safe to call and the right place to start, and shows the simulated broker answering the same questions offline. 9 min
• 8The live tick feedA live strategy reacts to prices as they arrive, which means a streaming connection that pushes ticks rather than a request you repeat. This chapter explains subscribing to a data stream, handling the messages as they come, and the reality that streams drop and must be reconnected. The tested example replays a recorded tick stream through the simulated broker. 9 min
• 9Sending an order from codeThis is the line the whole course circles: placing, modifying, and cancelling an order from a program, and it is taught with the most caution. The chapter shows the real SDK call generically and does not run it, then runs the identical logic against the simulated broker so you learn order placement, modification, and cancellation safely, with every order tagged by a client-side identifier. 10 min

Placing an order is the easy half. The hard half is knowing what happened to it. Part 3 follows an order through its life, handles the messy reality of partial fills, builds a small order manager that keeps a reliable record of every order, and then reconciles that record against the broker, which is always the real source of truth.

• 10From click to fillAn order is not filled the instant you send it. It moves through states, sent, acknowledged, open, partially filled, filled, rejected, or cancelled, and a safe system tracks that state rather than assuming success. This chapter draws the order state machine and explains why every serious bug in an order manager is really a confusion about state. 9 min
• 11When one order is really manyA large order rarely fills all at once and at one price; it fills in pieces, and pushing too much size at once moves the price against you. This chapter explains partial fills and average fill price, and why traders slice a big order into smaller ones, with a tested example that fills an order in parts and measures the market impact. 9 min
• 12Keeping track of every orderAn order manager is the part of the system that remembers every order it has sent and what became of it, so the strategy never double-sends or loses track. This chapter builds a small one against the simulated broker, with client order ids, safe retries, and duplicate protection, and explains why idempotency, doing a thing at most once even if you ask twice, is the core idea. 10 min
• 13The broker is the source of truthYour program's idea of your positions and orders can drift from reality, through a missed message, a restart, or a manual trade, and trading on a wrong picture is how automated accounts blow up quietly. This chapter teaches reconciliation: on startup and periodically, compare your record against the broker's and trust the broker. A tested example detects and reports a mismatch. 9 min

Part 4 connects the two halves of the course: it turns the honest backtest from Python for Trading into a strategy that can run live, then insists on the careful path across the gap. A strategy becomes a running program, the same logic is shown to work as both a backtest and a live loop, and then the reader forward-tests in the sandbox, goes live at the smallest possible size, and learns to run the thing reliably on a schedule.

• 14A strategy that runs itselfIn a backtest the strategy reads a whole history at once; live, it must react to data as it arrives and decide to act or wait each time. This chapter defines a strategy as a small program with a clear interface, given the latest data return the orders you want, and runs one against the simulated broker so an idea becomes an actual running loop. 10 min
• 15Two ways to run a strategyThe vectorised backtest from Python for Trading is fast but cannot run live; an event-driven engine processes one bar at a time and can drive both a backtest and a live session with the same code. This chapter contrasts the two, explains why sharing one code path removes a class of bugs, and shows an event-driven backtest reproducing the vectorised result. 10 min
• 16Forward-testing before a rupeeBetween a backtest on old data and live trading with real money sits forward-testing, running the strategy on live or recent data through the sandbox, with no money at risk. This chapter explains why this step catches problems a backtest cannot, timing, data gaps, order rejections, and treats a clean forward test as a requirement before going live, not an optional nicety. 9 min
• 17The smallest possible first tradeGoing live is a threshold to cross slowly, not a button to press. This chapter gives the checklist for the transition, start at an absurdly small size, keep a human hand on a kill switch, watch every order by hand at first, and treat the first live weeks as a test of the plumbing, not a search for profit. It is the most cautious chapter in the course. 10 min
• 18Running on time, every timeA live strategy must start, run, and stop on the market's schedule, not yours, and survive your laptop closing. This chapter covers the trading calendar and session times, scheduling a program to run automatically, why people move a live system to an always-on machine, and how to restart safely so a crash does not leave a position unmanaged. 9 min

Part 5 is the reality check, and it is the heart of the course's honesty. A system that backtested beautifully will almost always do worse live, and this part explains exactly why, one cause at a time: slippage between the tested fill and the real one, the latency race retail cannot win, the costs automation multiplies, the overfitting that made the backtest lie, and the concrete ways a running bot blows up. Each cause is made real, several with tested code applied to the Python for Trading backtest.

• 19The fill you get is not the fill you testedA backtest assumes you trade at the price on the screen; live, you trade at a slightly worse one, and that gap, slippage, quietly eats returns. This chapter models slippage and shows a thin edge shrink or vanish once realistic fills are assumed. Slippage is why many strategies that look good in a backtest are not. 9 min
• 20Why retail cannot win on speedSome strategies live or die on being milliseconds faster than everyone else, and that is a race retail traders structurally cannot win, because professional firms co-locate their machines beside the exchange. This chapter explains latency and co-location honestly, and draws the practical conclusion: do not build strategies whose edge is speed. 8 min
• 21The costs automation multipliesAutomation makes it easy to trade often, and every trade pays the full cost stack from the Taxation course, so a strategy that trades a lot can lose to costs alone. This chapter recomputes the cost drag at automated frequency and introduces capacity, the size beyond which a strategy stops working because it moves the market itself. 9 min
• 22Why the backtest was too goodThe single most common reason a live strategy underperforms its backtest is that the backtest was overfitted, tuned to the past so well it captured noise. This chapter revisits curve-fitting from Python for Trading and adds the professional's defence, out-of-sample and walk-forward testing, with a tested example that shows an in-sample star decay out of sample. 10 min
• 23The ways a bot blows upA running program can lose money faster than any human, and this chapter catalogues how: the runaway loop that fires orders in a storm, the disconnect that strands an open position, the duplicate order from a careless retry, the stale-data trade, the reaction to a bad tick. Each failure is shown with the control that prevents it. 9 min

Part 6 is what keeps a live system from ruining you, and it is the payoff of the whole risk track. It builds the automated risk gate that stands between the strategy and the broker, the logging and monitoring that let you see what a sleepless system is doing, and the tests that let you trust code with money. It closes on the honest reality of automated retail trading and a final readiness checklist and practice bridge.

• 24The gate before every orderEvery order the strategy wants to send should pass through an automated gate that can say no: no order larger than a set size, no position beyond a limit, no trading once the day's loss cap is hit, no order at an obviously wrong price. This chapter builds that risk gate against the simulated broker and adds a kill switch that halts and can flatten. It is the Risk and Psychology rulebook turned into code. 10 min
• 25Watching a system that never sleepsYou cannot watch a live system every second, so it must tell you what it is doing and shout when something is wrong. This chapter covers logging every decision and order, monitoring live positions and profit and loss, and alerting on the anomalies that need a human now: a breached limit, a disconnect, an unexpected position. 9 min
• 26Trusting code with moneyCode that places orders deserves more testing than any other code you write, because its bugs cost money directly. This chapter applies plain software-testing habits to a trading system, unit tests for the risk gate and order manager, a dry-run mode, and reproducibility, and shows a test suite catching a risk-gate bug before it could reach the market. 9 min
• 27What algo trading can and cannot doThe honest close. Most automated retail strategies lose, for the same reasons most manual ones do, and automation changes the speed and the scale, not the odds. This chapter sets realistic expectations, revisits the SEBI framework and what registration and responsibility mean for a retail algo trader, and asks honestly whether algo trading is for you. 10 min
• 28The last checklist, and what is nextThe course closes by assembling everything into one go-live readiness checklist, from a passing forward test to a working kill switch to reconciliation and logging, and pointing beyond. The reader rehearses the full loop in the sandbox, and the course names the honest final word: code is a tool for testing and discipline, not a money machine. 9 min