Every reasonably technical person with a strong hunch about a market has, at some point, thought: "I should write a bot for this." Most of them start. Most of them lose money. The ones that work share a set of structural properties that have very little to do with the trading strategy itself.
This post is those properties.
It's written for founders, technical operators, and the engineers they hire. It's not a "get rich with algo trading" post โ there are a hundred of those. It's an engineering post about how to build the thing so that when the inevitable bad day arrives, you survive it.
The uncomfortable starting point
Most trading bots lose money. This isn't because the developers are stupid. It's because the markets reflect the collective intelligence of everyone else who's already tried, and your edge has to be genuinely novel or genuinely patient to survive.
A good trading bot architecture doesn't guarantee profitability. What it guarantees is that:
- You'll know within weeks whether your strategy works.
- You won't blow up the account while finding out.
- When the market does something unusual, the bot won't do something stupid.
- When a bug fires, the blast radius is contained.
- You can debug post-hoc and learn from losses.
That's the actual deliverable of good engineering. Profitability comes from the strategy โ but bad engineering turns a winning strategy into a losing one.
The seven layers of a production trading bot
A bot that survives contact with live markets has seven distinct concerns, usually as separate modules:
1. Market data ingestion
You need clean, timestamped, gap-aware market data. "Clean" means deduplicated, corrected for late ticks, handling exchange outages gracefully.
Common failure mode: treating a gap in your data feed as "no movement" instead of "no data." The bot sits there not trading during the most volatile hour of the day because the WebSocket disconnected and nobody noticed.
What to build: redundant data feeds (primary + fallback), heartbeat monitoring with alerts when either feed stalls for more than a defined threshold, explicit stale-data gating that refuses to trade if the last tick is older than N milliseconds.
2. State management
Every bot has state: current positions, pending orders, unfilled orders, cash balance, PnL. This state lives in two places โ on the exchange and in your bot's memory โ and they can disagree.
Common failure mode: the bot thinks it has no position, the exchange thinks it has five. Next time the bot tries to "open" a position it opens another five. Now the bot has ten. It's not supposed to have any.
What to build: the exchange is always the source of truth. On every decision cycle, reconcile your local state with the exchange's state before deciding. If the bot has been down for more than a few seconds, re-fetch everything. Log every reconciliation and alert on unexpected deltas.
3. Strategy engine
The actual trading logic โ the part people think is the hard bit. It isn't. It's 20% of the work.
What it should do: take in market data + current state, emit a set of intended orders. Nothing else. No side effects. No network calls. No database writes.
Why pure: because this is the layer you backtest, unit-test, and replay. If the strategy layer is deterministic given its inputs, you can replay historical data and know exactly what it would have done. Any impurity here destroys your ability to test.
4. Risk layer
This is where most amateur bots skip a step and subsequently blow up.
The risk layer sits between the strategy engine (which says "I want to buy 10 BTC") and the order manager (which actually places the order). Its job is to say "no" when the request violates risk rules.
Every bot should have, at minimum:
- Position size limits. No single position larger than X% of account equity.
- Total exposure limits. No more than Y% of account in active positions simultaneously.
- Rate limits. No more than Z orders per minute (protection against runaway loops).
- Loss caps. If total daily PnL is down more than W%, the bot flattens all positions and halts for the day.
- Correlation awareness. If you're trading multiple symbols, check that you're not "diversified" into five things that all move together.
- Sanity checks on every order. Price within N% of current market. Side matches inventory (not selling what you don't have, unless margin is intentional). Timestamps fresh.
The risk layer should log every rejected order with the reason. Reviewing rejections weekly catches strategy bugs before they cost you.
5. Order manager
Converts approved orders into actual exchange API calls. Handles retries, partial fills, rejection codes, rate limiting from the exchange side.
Common failure mode: the exchange returns an error, the bot's error handler catches it and retries silently. The first attempt actually went through and the retry placed a second order. Now the bot has double the intended position.
What to build: idempotency keys on every order, acknowledgement-before-retry logic, distinct handling for "definitely failed" vs "unknown state" errors. When in doubt, treat it as "unknown" โ don't retry; reconcile.
6. Observability
Metrics, logs, alerts. The difference between a bot you can operate and one you can't.
Minimum viable observability:
- Every order (intended, risk-rejected, placed, filled, failed) logged with timestamp, reason, and full context
- Real-time PnL dashboard
- Exchange-connection health dashboard
- Heartbeat alert: if the bot hasn't logged a decision cycle in the last N seconds, page you
- Daily digest email with trades, PnL, risk rejections, and notable events
- Per-strategy performance metrics (win rate, Sharpe, max drawdown)
You will look at these every day for the first month. After that, you'll look when the alert fires. The alert is what matters.
7. Kill switch
A button (actually, an API endpoint) that halts all trading and flattens all positions immediately. Should work even if most of the bot's normal pathways are broken.
How to build: separate process (or at least separate thread) that only reads exchange state and only places "close everything" orders. No dependencies on the strategy engine or risk layer. You want to be able to hit this in an airport lounge from your phone.
The common patterns that cause account blow-ups
Over the last year we've seen these patterns repeatedly, both in client work and in analysis of public post-mortems:
"Fat finger" deployments. Developer deploys a new version with a bug in the strategy. Bot places wildly wrong orders for three minutes before someone notices. Fix: all strategy changes ship behind a feature flag with shadow mode (running alongside production but not placing orders) for at least 24 hours before going live.
Leverage compounding. Bot holds a position, strategy thinks it's flat, enters another position, now holds 2ร. Does this again. Blows up at 4ร or 8ร. Fix: the risk layer should compute current exposure from exchange state, not from the bot's internal model.
Exchange rate-limiting causing order floods. Order fails due to rate limit, bot retries aggressively, more rate limits, exponential queue of orders waiting, market moves, queue fires all at once at terrible prices. Fix: exponential backoff with a hard cap, and when the cap is hit, flatten and halt.
Timezone / daylight-savings bugs. Backtest looks great, live trading doesn't match. Hours-offset bug. Fix: store everything in UTC, test against DST transitions explicitly.
Illiquid symbols. Strategy that works on BTC/USDT blows up on obscure altcoin pairs because a single order moves the market. Fix: size orders relative to the symbol's observed volume, not as a fixed unit.
Exchange API version changes. Exchange deprecates an endpoint, your bot keeps calling the old one, silently fails, stops trading. Fix: integration tests that hit the exchange's test environment nightly and alert on schema drift.
Missing slippage models. Backtest assumes you can fill at the mid. Live, your orders move the market. Fix: realistic slippage assumptions in the backtest, walk-forward validation on unseen data.
How to actually test a trading bot
Three stages, each non-skippable:
- Backtest against historical data. Prove the strategy has an edge if you can execute. Look for Sharpe, max drawdown, win rate, edge under different market regimes. Most amateur bots skip directly to step 3 and learn this the expensive way.
- Paper trade against live data. Run the bot against live market data but with a simulated order book. Proves the bot's infrastructure is working end-to-end and exposes issues invisible in backtest (feed stalls, rate limits, reconciliation bugs). Minimum one month.
- Live trade with tiny position sizes. Deploy with position sizes 1/100th of your target. Keep them there for at least one month with realistic market exposure. Scale up only when you've seen the bot handle an adverse day without breaking.
Most blow-ups happen because step 3 gets skipped or compressed.
Specific Australian considerations
If you're operating an automated trading system from Australia, a few local things to know:
- ASIC regulation. Most personal-use bots trading on public exchanges with your own capital aren't financial services by definition. The moment you run money for anyone else, you almost certainly need an AFSL or to operate under an authorised representative. Get proper legal advice โ not general blog advice.
- Tax treatment. The ATO treats crypto trading as assessable income for active traders; capital gains for investors. The line between the two is fuzzy and moves based on your behaviour. Talk to an accountant who specialises in crypto.
- Exchange choices. AUSTRAC-registered exchanges (Independent Reserve, BTC Markets, Swyftx, CoinJar among others) matter if you want banks not to close your accounts. Some offshore exchanges are legal to use but create banking friction.
- Data retention. Keep trade logs, strategy versions, and decision artefacts for at least 7 years for tax and, if you're running anyone else's money, for compliance.
What it costs to build one properly
Rough ranges, based on what we've quoted for client engagements:
- Personal / single-strategy / single-exchange bot โ $24Kโ$48K fixed-scope Rapid MVP. Covers all seven layers, backtest framework, monitoring. You bring the strategy.
- Multi-strategy / multi-exchange platform โ $80Kโ$180K. Adds portfolio-level risk, strategy orchestration, heavier observability.
- Production-grade arbitrage or market-making system โ $180Kโ$500K+. Adds low-latency infrastructure, advanced order types, co-location considerations.
You can write a weekend bot on your laptop that makes money for a month. Building one that survives a year of live trading is a different project.
The questions worth asking before you build
- What's the edge? If you can't articulate it in one sentence, you probably don't have one.
- How big does the edge have to be to survive transaction costs + slippage? Often the edge disappears under realistic execution.
- What happens when everyone else discovers the same edge? Most edges decay; plan for it.
- How much can you afford to lose? Not "expect to lose" โ afford. That's your real risk budget.
- What does the operations model look like? A bot is a 24/7 system. You need monitoring, on-call, runbooks. Ignore this and the bot will go down exactly when it matters.
If you're honest about those five, you'll either proceed with clear eyes or recognise that the idea needs more work before building.
How we think about trading bot engagements
We take them on case-by-case and honestly โ we say no often. The ones we accept usually have:
- A specific, defensible edge (arbitrage, market-making, a real private signal, a strategy that requires 24/7 execution that a human can't match)
- Capital behind the project (budget for build + runway to paper trade + seed capital to prove out)
- Realistic expectations about timeline (6 months from kickoff to any real capital at risk)
- Someone on the client side who understands markets deeply
If that's you, email <hello@amoradigital.com.au> with a one-paragraph description of the strategy, your timeline, and your budget range. We'll come back within one business day with an honest read on whether it's something we can help with.
Not financial advice. Not engineering advice specific to your situation. Get proper professional help for both.
Amora Digital builds trading infrastructure, AI SaaS and marketing systems for Australian founders and operators. Pitch us your crazy idea.
