Notes · For bot operators · June 2026

Intraday margin: the regime that replaced PDT, and why your bot meets it first.

The framework that replaced the pattern day trader rule is margin-based, varies by broker until late 2027, and fires after the loss instead of before the order. Automated strategies hit all three properties harder than humans do.

TITAN DIAGNOSTIC SYSTEMS · CHICAGO · JUNE 2026
§ 1 · The new mechanism, in one paragraph

Since June 4, 2026 (FINRA Regulatory Notice 26-10), there is no day-trade count and no $25,000 floor. Instead, brokers compute an intraday margin deficit: whether your intraday exposure exceeded what your equity supports. Real-time monitoring is optional for brokers — end-of-day calculation is allowed. Deficits must be met promptly, and repeated failures trigger a 90-day restriction. Alpaca’s implementation switched on the same day the rule died.

Read that mechanism as a control system and one property jumps out: nothing in it pauses an order before it goes out. It measures the damage afterward and bills you for it, possibly with a 90-day freeze attached.

§ 2 · Why bots hit the wall first

A discretionary trader produces intraday exposure at human speed and usually notices, around the sixth trade of a bad morning, that something is wrong. An automated strategy produces a day’s worth of exposure in minutes, and a buggy one produces it in seconds.

The failure I’d worry about first is the retry loop: a webhook retry, or error handling that re-submits entries, quietly multiplies your intended position. Each fill adds intraday exposure, and the margin engine doesn’t care that it was accidental. A close second is the sizing bug — a misplaced decimal in quantity logic clears any equity-based threshold instantly. Under PDT you ran out of day trades; now you accrue a deficit at machine speed.

And there is a quieter trap in the rollout itself. Brokers phase in their frameworks until October 2027, so the same order can be accepted at one broker and rejected at another for the next sixteen months. If your error handling assumes rejections are deterministic (same order, same answer), it is now wrong.

§ 3 · What you can check before submitting

Titan’s public API includes a preflight that evaluates an order intent against the broker state you supply — positions, open orders, buying power, recent fills — and returns a reason-coded receipt before you submit. It does not need your broker keys; you push the evidence, it evaluates what you pushed. This is a real call and a real response from June 12, 2026 (abridged):

curl -s -X POST https://www.titandiagnostics.io/api/public/v1/preflight/intraday-margin \
  -H "X-Titan-Agent-Key: $TITAN_AGENT_KEY" \
  -H "Content-Type: application/json" \
  -d '{"broker": "alpaca", "environment": "paper",
       "order": {"symbol": "AAPL", "side": "BUY", "qty": 50, "type": "market"},
       "account": {"buying_power": 8400.0, "captured_at": "..."},
       "positions": [], "open_orders": [],
       "market_data": {"bid": 198.40, "ask": 198.45, "captured_at": "..."},
       "recent_fills": []}'
{
  "receipt_type": "intraday_margin_preflight",
  "decision": "refuse",
  "decision_scope": "titan_policy_not_broker_guarantee",
  "reason_codes": [
    "EXPOSURE_INCREASING_ORDER",
    "IMD_UNKNOWN",
    "BUYING_POWER_INSUFFICIENT"
  ],
  "next_action_hint": "do_not_send_order",
  "evidence": { "estimated_notional": 9922.5, "buying_power": 8400.0,
                "intraday_margin_requirement": null },
  "known_limits": [
    "Titan does not calculate broker-authoritative margin.",
    "Titan does not guarantee order acceptance.",
    "Titan does not require broker keys.",
    "Titan evaluates the submitted order intent against the supplied
     state snapshot and returns a reason-coded diagnostic receipt."
  ]
}

The catch is plain arithmetic: 50 shares at the ask is $9,922 of notional against $8,400 of buying power, an obvious conflict, refused from evidence before the broker ever saw it. What I’d actually point you at, though, is IMD_UNKNOWN. Titan does not know your broker’s intraday margin requirement, says so in the receipt, and lists every limit of its own analysis under known_limits. When the evidence isn’t there at all (no recent fills pushed, no account state), the verdict comes back unknown rather than a confident guess. A preflight that guesses confidently would be worse than none.

§ 4 · The standing guardrail

The preflight is a point check. The standing version of the same idea is a pre-trade gate: every signal your strategy emits passes through 26 safety checks — position caps, daily-loss cutoffs, cooldowns, duplicate detection, quantity sanity — on Titan’s infrastructure, outside your bot’s code, before your broker sees an order. The retry loop, the sizing bug, and the revenge re-entry are exactly the failure shapes those checks exist to stop. Every decision — forwarded or blocked — gets a receipt that is hash-chained and anchored to Bitcoin.

The PDT rule’s accidental speed bump and how to rebuild it deliberately is the companion piece: The PDT rule is gone. Your speed bump doesn’t have to be.

What Titan does not claim

Titan proves what your strategy said, when it said it, and what the safety checks decided. It does not prove you made money.

Titan does not calculate broker-authoritative margin and does not guarantee any broker will accept any order — the preflight is an evidence-based estimate with its limits disclosed in every receipt. Titan does not manage open-position risk after a fill, does not hold funds, does not store broker credentials, and does not submit orders — execution stays in your hands, on your machine. Works with Alpaca today.