Picking Your Venue: Exchanges, Brokers & Market Structure
Where your agent trades is not a deployment detail — it determines your liquidation math, your reconciliation burden, and whether a strategy tuned on one asset class will survive on another.
The decision that happens before the first line of code
Most agent builders treat venue selection as an ops detail — you pick an exchange, you get API credentials, you deploy. The architecture is already written; the venue just hosts it.
This is exactly backwards.
The venue you choose determines your agent's liquidation math, your margin model, your reconciliation burden, and whether a strategy proven on one asset class will survive on another without significant rework. Picking the wrong venue for a strategy — or porting a strategy to a new venue without understanding the differences — is one of the most reliable ways to lose money with a system that was working.
This lesson covers how to evaluate venues systematically before committing to them, and what each venue type changes about your agent design.
Asset class first, venue second
The first branch in venue selection is not "which exchange" — it is "which asset class." That choice dictates which category of venue you need, and each category comes with a set of constraints that flow through to the entire agent design.
Perpetual futures on a centralized exchange (CEX) are the most common venue for autonomous agents. The defining characteristic is the margin model: isolated or cross. Isolated margin caps your loss on a given position to the margin you allocated to it. Cross margin uses your total account balance as collateral, which allows your winning positions to subsidize a losing one — but also means a single bad position can draw down the entire account. For an agent running unattended, isolated margin is almost always the safer default.
The other defining characteristic of perpetual futures is liquidation price. The exchange will force-close your position before your stop-loss fires if the mark price reaches your liquidation price. A risk sizer that ignores this can set a stop-loss that appears conservative but sits above the actual liquidation level. The agent intends to stop out at -2%; the exchange liquidates at -1.8% because the maintenance margin eats the remaining buffer. This class of bug costs real money and has no fix other than computing the real liquidation price per symbol and ensuring the stop-loss is always below it.
Spot and DEX venues remove the liquidation concern but also remove leverage. Position size equals capital at risk, directly. Decentralized exchanges add gas fees and MEV (maximal extractable value) risk — bots front-running your order — which must be factored into the cost model.
Equities and options introduce the constraint that makes the reconciler design fundamentally different: positions change without a trade. Options expire, are assigned, or go worthless. Stocks split, pay dividends, get halted. A long call that was in the money yesterday might be assigned today, converting it to an equity position overnight. A futures-style agent that only runs the reconciler after its own orders will miss all of these changes and act on stale state.
This is not a minor implementation detail. It means the reconciler for an equities agent must run on a schedule, not just in response to execution events — and it must compare against the broker's complete position list, not just the orders the agent itself placed.
Evaluating venues on the axes that matter
Once you know the asset class, evaluate specific venues on the axes that affect agent design, not just the ones that affect a human trader.
Fees (maker/taker) affect the required edge per trade. A maker fee of 0.01% (for a limit order that adds liquidity) versus a taker fee of 0.06% (for a market order that removes liquidity) is a 6x difference in cost per trade. An agent strategy that is profitable at 0.01% maker fees may not be profitable at 0.06% taker fees. Know which order types your agent uses and which fee tier applies.
API quality and idempotency is the axis most critical to execution integrity. Can you assign a client-defined order ID so that a retry of a failed order is not a duplicate? Does the exchange provide a reliable WebSocket for order status updates, or must you poll? A venue with poor idempotency support forces your execution layer to implement complex deduplication logic — and any gap in that logic risks double-entry.
Reconciliation burden is the axis that most often surprises builders who migrate a strategy between asset classes. For perpetual futures, reconciliation burden is relatively low: positions change only when you trade, and the exchange's order status endpoint is the source of record. For equities, reconciliation burden is high and mandatory: positions change from corporate actions, assignments, and expiry even on days with zero agent orders. An agent that was designed for low-burden reconciliation will need a significantly different reconciler design when moved to a high-burden venue.
The porting trap: when strategies do not transfer
The most expensive venue mistake is assuming that a profitable strategy on one venue will transfer to another with only a few configuration changes.
Some things transfer cleanly: signal logic based on price and volume patterns is largely venue-agnostic, and execution patterns like bracket orders exist on most perpetuals and equity platforms.
Some things do not transfer:
Risk sizing that uses a flat margin percentage assumes the same margin math on every symbol. Perpetuals exchanges have per-symbol maintenance margin rates. A risk sizer tuned on BTC perpetuals (typically low maintenance rate) will misbehave on a newly listed token with a higher rate, or on an equities broker where margin rules are set by regulation and change quarterly.
A reconciler that only runs on execution events is correct for perpetuals and wrong for equities or options. Porting the reconciler design without adapting it to the new venue's event model is the silent bug that surfaces weeks later during a corporate action.
PnL math tuned for funding-rate venues (perpetuals charge/pay a funding rate every 8 hours) breaks on rollover venues (futures that charge swap fees nightly) and on options (which have theta decay). The agent's internal PnL model must match the venue's actual cost structure, or realized PnL will silently diverge from the agent's expectations.
Funding and carrying cost as an annualized drag. Perpetual funding, forex swap, and options theta are recurring venue-specific costs that compound over the life of a trade. On a CEX perpetual, funding settles roughly every eight hours; a venue where the 90-day average funding rate is +0.12%/day charges you 43.8% annualized for a long position — even before fees. A forex broker charges an overnight swap on every position held at the daily rollover. Options positions bleed theta every day. A strategy that shows a positive gross edge on paper can be marginally positive or outright negative once these carrying costs are netted. Funding cost belongs on the venue scorecard as its own axis, not in a footnote: a venue with chronically elevated funding can erase a positive-R edge just as reliably as wide spreads, and unlike fees, it scales with how long you hold.
The pattern to internalize: every time you move a strategy to a new venue, audit the risk sizer, the reconciler, and the PnL math independently. Do not assume that a working agent is a transferable agent.
Build it: implement a weighted venue scorecard
You are going to build scoreVenue() — a function that takes a VenueSpec (the axes discussed in this lesson) and axis weights, normalizes each axis to a 0–1 value where 1 is always better for the agent, applies the weights, and returns a 0–100 score. Then implement rankVenues() to sort multiple venues and return the ranked recommendations. Pay attention to the axes where higher raw values are worse (fees, reconciliation burden): invert those before weighting.
What is next
You now know what a trading agent is, what its five subsystems are, and how to choose the right venue for the strategy. The next set of lessons goes deeper into two of the five subsystems: how signal engines score market state reliably, and how to calculate edge per trade — the math that tells you whether a strategy is worth running before you deploy it live.