Spend Controls for AI Trading Bots

What a pre-trade firewall does

sipi.bot sits in front of your order-placement logic. Every order the bot wants to place is first evaluated against your risk rules; the firewall returns APPROVED, BLOCKED, or FLAGGED in under 5ms. Only APPROVED orders reach your broker or exchange API.

def place_order(amount, venue, side, symbol):
    # ask the firewall first
    decision = sipibot.evaluate(
        amount=amount,
        merchant=venue,      # "binance", "interactive-brokers", etc.
        category=f"{side}:{symbol}",
    )
    if decision["decision"] != "APPROVED":
        log_block(decision["reason"])
        return None
    # only now actually place the order
    return broker.submit(amount, venue, side, symbol)

The risk rules that matter for trading bots

1. Per-trade size cap

Block any single order over a hard ceiling. This is the floor — the catastrophic single-trade protection that catches a misformatted order (extra zero, wrong unit) before it reaches the venue.

{"rule_type": "per_transaction", "params": {"max_amount": 10000}, "action": "BLOCKED"}

2. Daily loss / volume cap

A rolling cap across all trades in a day. Once aggregate notional crosses the threshold, all further trades are blocked. This is your daily-risk-circuit-breaker.

{"rule_type": "daily_total", "params": {"max_amount": 100000}, "action": "BLOCKED"}

3. Velocity limit (the runaway-killer)

The rule that stops the 40-retry-in-90-seconds pattern. Cap the number of trades per window; the Nth attempt is blocked. Velocity rules catch bugs, stale signals, and compromised feeds far faster than amount-based rules, because the pattern of repeated orders is detectable before the amount becomes dangerous.

{"rule_type": "velocity", "params": {"max_count": 20, "window_minutes": 60}, "action": "BLOCKED"}

4. Venue allowlist

Block orders to any venue you haven't explicitly approved — your defense against prompt-injection (in LLM-driven bots) or logic bugs that route orders to the wrong destination.

{"rule_type": "merchant_allow", "params": {"allowed": ["binance.com", "interactivebrokers.com"]}, "action": "BLOCKED"}

5. Time windows

Block or flag trades outside market hours, during known high-volatility windows, or overnight when no human is watching.

{"rule_type": "time_window", "params": {"allowed_hours": "9:30-16:00"}, "action": "FLAGGED"}

Why existing risk controls aren't enough

Most trading systems have some risk controls — broker-side limits, exchange circuit breakers, internal position-size checks. The gaps that sipi.bot fills:

• Cross-venue. Broker-side limits only protect that broker. A bot that trades across 5 venues has 5 independent limits and no aggregate cap. sipi.bot governs all venues through one policy.
• Velocity-aware. Broker limits are usually amount-based, not count-based. They catch the big single order but not the 40 small ones in 90 seconds.
• Pre-trade, not post-trade. Many internal risk systems reconcile after the fact. sipi.bot blocks before the order reaches the venue.
• Agent-aware. If your trading logic is LLM-driven (a growing category), prompt injection can instruct the bot to route trades to attacker-controlled venues. The merchant allowlist stops this.

Crypto trading bots and agent-commerce rails

For crypto bots that settle via agent-payment protocols — x402 (Coinbase), AP2 (Google), AgentKit — sipi.bot is the compliance layer in front of the wallet. The protocol moves the funds; the firewall decides whether the move is allowed.