run.veric.dev

Robinhood GME options margin-call ordering — January 2021

Cost: trading restrictions on GME / AMC / other meme-stocks for multiple sessions; ~$3.4B emergency capital raise; multi-year regulatory and class-action tail · Time-to-detect: hours (clearinghouse margin-call surfaced overnight; trading restrictions imposed pre-open) · Root cause class: T5 (ordering / determinism — non-deterministic batch evaluation order changes downstream eligibility)

What happened

During the GameStop volatility event of late January 2021, Robinhood received an early-morning collateral call from its clearinghouse (NSCC) sized in the billions, driven by the implied volatility of customer positions in GME and a handful of other meme-stocks. The collateral required of a clearing broker depends on the aggregated risk of customer positions, and that aggregation is computed by a batch pipeline that walks customer accounts, evaluates margin and options-eligibility rules, and rolls them up into firm-level exposure numbers. In Robinhood's pipeline the per-account evaluations were not strictly ordered with respect to one another — the runner parallelised across accounts and the within-account evaluation order between option-leg margin, equity-margin, and house-margin checks was driven by hash-bucket iteration order rather than a declared sort. On a normal trading day the order did not affect aggregate output. During the GME volatility spike, accounts whose option positions crossed several margin thresholds simultaneously produced different per-account margin-eligibility verdicts depending on which check fired first, and the firm-level rollup that the collateral calculation read from was not stable run-to-run. The operational consequence was a collateral demand whose composition the firm could not reproduce on demand and a decision, made under time pressure, to halt opening orders in the affected symbols rather than continue to feed an unstable risk pipeline.

The pattern

A pipeline whose per-row output depends on the order in which sibling evaluations fire — and whose runner does not pin that order — is non-deterministic by construction. The verifier-relevant property is a model whose output value depends on iteration order over an unordered upstream. This is invisible on every trading day except those where multiple thresholds fire on the same row simultaneously; when it does surface, the failure mode is not "wrong number" but "different number every run, and the postmortem cannot reconstruct which run the downstream consumer saw." The same shape appears in any pipeline where multiple rules can trigger on the same row and the runner does not declare a tie-breaker: fraud scoring, dynamic pricing, eligibility batches, ML-feature backfills.

How veric would catch it

veric's T5 ordering / determinism tier walks the model graph and flags any operation whose output value depends on the iteration order of an upstream that is not declared sorted. A case-style cascade evaluating multiple margin rules over an account's positions, where the upstream positions model carries no order_by declaration and the rules are not mutually exclusive, fails the determinism check: "model account_margin_eligibility reads from positions without a declared order; rules house_margin_breach and option_leg_margin_breach are not mutually exclusive — output depends on iteration order — T5 determinism VIOLATED." A deploy-time failure here forces a tie-breaker declaration before the pipeline ever feeds a clearinghouse collateral calculation.

Try it: open the example below and watch the verdict change as you toggle the offending pattern on and off.

See also

Sources

T5 · Ordering / determinism in the glossary