SRS: UC_6.1.2 — Margin Enforcement

---

UC_6.1.2 — Margin Enforcement

1. Overview

No wireframe — backend enforcement engine with no UI screen of its own. Its notification payloads feed the Market Status Widget (UC_4.1.3) and the Discord/Slack/Dashboard broadcast channels via Flow 24.

⚠️ Applies to both SIM and LIVE account types — this UC's overnight margin/exposure enforcement (Universal Drawdown Safety Gate, Pre-Close Lockout, Futures/Forex Required Margin compliance, Halt/Session Open handling) runs identically for SIM and LIVE accounts, with no environment branching in the logic itself. See BR_6.1.2.11.

---

2. Trigger

Event-driven — each of the milestones this UC owns (T-60min, T-30min, T-10min, T-3min, T-2min, Halt Start, Halt End, Session Open) is signaled as the per-asset-class clock reaches that timestamp. This UC is purely reactive to those signals. (T-30sec is signaled directly to UC_6.1.3, not to this UC — per CR-20260906-001, this UC no longer owns any T-30sec action.)

---

3. Pre-conditions

---

4. Post-conditions

T-60min / T-30min / T-10min (Market status warnings)

• A Warning_60 / Warning_30 / Warning_10 payload is broadcast to traders via Discord, Slack, and the Notification Center. No order-filter, margin, or exposure state changes.

T-3min (Pre-Close Lockout)

• The API gateway rejects any new-position or exposure-increasing order for the closing asset class's symbols; closing/reducing orders continue to be accepted.

T-2min — Universal Drawdown Safety Gate breached

• Global FLATTEN_ALL dispatched to the broker execution server for that user: all working orders cancelled, all open exposure cleared.

T-2min — Drawdown Gate passed (Futures or Forex)

• Futures: dispatched unconditionally to UC_6.1.3 — no shortfall pre-check and no pre-computed Target_Limit for the margin leg. UC_6.1.3 itself runs Check 1 (25% ES-Equivalent contract cap) then Check 2 (CME Overnight Margin vs. Available_Equity, the former MAX(CME Overnight Margin, 25% notional) math) and determines whether/what to trim. See BR_6.1.2.4.
• Forex (MT5 or TraderEvolution): still computed by this UC. If the 25% notional exposure sweep finds a shortfall, dispatched to UC_6.1.3 as a TRIM_TO_COMPLIANCE call with Target_Limit = Allowed_Notional — unconditionally, for both platforms alike. No native leverage-reduction/Stop-Out path is checked or relied upon first (CHR-102).

T-2min — all checks pass

• No action; the position(s) roll into the overnight session unmodified. No per-user execution notification/email is generated for this user — see "T-2min cycle complete" below.

T-2min — a liquidation or trim was actually executed on a specific trader's account (Drawdown Gate FLATTEN_ALL, or a Required Margin/notional shortfall dispatched to and executed by UC_6.1.3)

• The dashboard's POSITION_METRICS/ACCOUNT_METRICS WebSocket streams automatically detect and reflect the resulting flat/reduced position — this UC/the margin script does not publish or push these metrics itself; it relies entirely on the standard metrics pipeline already triggered by the live market order hitting the gateway. No Zapier involvement in this part. See BR_6.1.2.9.
• The margin script fires a NOTIFICATION WebSocket event, surfacing an explanatory entry in that trader's Notification Center describing the liquidation/trim that was executed.
• The margin script triggers the Zapier webhook for the post-execution Overnight_Auto_Liquidation_Alert email (SES-19) via AWS SES, sent to that specific trader only.
• See BR_6.1.2.9 for full detail.

T-2min cycle complete (every cycle, regardless of whether any user was actually acted on)

• The system broadcasts Enforcement_Complete once the entire T-2min cycle finishes evaluating all accounts. This is a flow-level broadcast — it fires every cycle, independent of whether any individual trader was flattened/trimmed this time. See BR_6.1.2.9.

Halt Start / Halt End (Futures only — see §5 Basic Flow steps 8-9)

• Order routing locked/unlocked for the symbol; Alert_Level = 'Halt_Active' / 'Halt_Cleared' payload dispatched.

Session Open

• Overnight margin weighting dropped, normal FCM intraday margins restored; Pre-Close Lockout filters released; Alert_Level = 'Session_Open' payload dispatched with Asset_Class and affected symbols.

---

5. Basic Flow

This flow follows RFQ V7's own point-by-point order ("Universal Drawdown Safety Gate" → "Asset-Specific Pre-Close Lockout" → "Futures Asset-Specific Margin Enforcement" → "Forex Specific Enforcement" → "Intraday Halt and New Session Open" → "Notification Routing Logic", lines 1689-1870), reordered slightly so the T-60/30/10 warnings and the T-3min lockout (which happen chronologically first) are presented before the T-2min checks.

1. T-60min / T-30min / T-10min — Market status warnings, no enforcement action. At each of these three timestamps, the middleware broadcasts a market-status warning to traders via Discord, Slack, and the Notification Center. The timestamp each milestone resolves to is asset-class-dependent, following the same per-asset-class timeline-thread model UC_6.1.1 already uses for T-3min/T-2min/T-30sec:

   • Futures: anchored to the same daily cron-derived timeline thread UC_6.1.1 computes once per day from Official_Close_UTC (committed by that UC's 01:00 UTC cron, BR_6.1.1.9). T-60min/T-30min/T-10min for Futures are Official_Close_UTC − 60min / − 30min / − 10min respectively — the same reference timestamp, and the same per-asset-class thread, that T-3min/T-2min/T-30sec already derive from. No separate timing source for Futures.
   • Forex (MT5 and TraderEvolution): anchored instead to the daily institutional rollover window (reset_time — the same rollover boundary BR_6.1.2.5's Forex notional sweep runs up to; value Ref: common_rules.md §22.1), since Forex has no CME-published Official_Close_UTC to derive from. T-60min/T-30min/T-10min for Forex are Rollover_UTC − 60min / − 30min / − 10min, where Rollover_UTC is the fixed daily institutional rollover timestamp already resolved to the correct UTC instant for that day, DST included — this UC consumes Rollover_UTC as a pre-resolved value; it does not run its own EST⇄EDT offset math (DST mechanism Ref: UC_4.1.3 BR_4.1.3.5). This is a separate timing source from Futures — Forex's warning milestones do not and cannot read CME_Instrument_Details.
   • Warning_60 / Warning_30 / Warning_10 — the three distinct Alert_Level payload values dispatched at each asset class's own T-60min, T-30min, and T-10min respectively (see step 12 below for the shared payload-construction mechanism). The payload itself is identical in shape across Futures and Forex; only the underlying timestamp source differs.
   • All of T-60min/T-30min/T-10min (and every other milestone offset in this UC) are per-broker configuration values, not hardcoded — see BR_6.1.2.8.

2. T-3min — Asset-Specific Pre-Close Lockout activates. At exactly Official_Close_UTC − 3min for the asset class (Forex: Rollover_UTC − 3min, per step 1 above — this 3-minute offset is itself a per-broker config value, see BR_6.1.2.8), two layers of enforcement apply, and which actor performs which layer must not be confused:

   • 🔧 Layer 1 — performed by the middleware itself (Node.js/API gateway, platform-agnostic): the API gateway updates the Lockout_Active state (Pre_Close_Lockout) for that asset class's symbols, then broadcasts the milestone notification — the same Discord/Slack/Notification Center + market-status broadcast pattern already used for T-60min/T-30min/T-10min, just with its own distinct payload:
     • State update: Lockout_Active is set for the closing asset class's symbols.
     • Notification: Widget_State = 'Lockout', Widget_Short_Text = 'Locked', Severity = 'CRITICAL', Copy: "Pre-Close Lockout", broadcast via Discord/Slack/Notification Center and the Market Status Widget.
   • 🏦 Layer 2 — performed by a native mechanism set up and executed at each platform/exchange itself (NOT the middleware): each broker/platform separately exposes its own native config that achieves the reduce-only effect at the exchange/server level, configured once ahead of time directly on that platform (not dispatched per-cycle by this UC's middleware). This is where the actual Order Filter Rule (reject any inbound order that would open a new position or increase net directional exposure within the closing asset class) and Authorized transactions (continue to permit closing/reducing transactions — partial fills, contract-size reductions, or fully flattening a position) are enforced:
     • TraderEvolution (Forex): the instrument-level "Liquidation Only" trading status, applied via a TE Scheduler task calling the TraderEvolution Admin API — blocks new/increasing orders at the TE server itself, still permits reduce-only/flatten.
     • MT5 (Forex): Close Only Trading Mode (IMTConSymbol/IMTConGroupSymbol::TradeMode = TRADE_CLOSEONLY) — the MT5 server rejects new/increasing orders with error code MT_RET_REQUEST_CLOSE_ONLY, still permits close/reduce orders.
     • Rithmic (Futures): the No Trading From / No Trading To window — a Rithmic-native configuration that permits only trades which move the account toward flat during the configured period; all other order types are rejected by the Rithmic gateway itself. ⚠️ Rithmic only — daily sync cronjob required (BR_6.1.2.13): unlike TraderEvolution/MT5 (configured once ahead of time, Ref: the Layer 2 intro above), Rithmic's No Trading From/To window must be re-pushed to the exchange side every day, because each symbol's close/open boundary shifts daily. A separate middleware cronjob — distinct from UC_6.1.1's own 01:00 UTC CME-ingestion cron — pushes that day's Official_Close_UTC/Session_Open_UTC for all ~31 whitelisted symbols to Rithmic, so the Adapter can set each symbol's No Trading From/To window for that day's T-3min boundary.
   • The T-3min offset, and each broker-native mechanism's own window/schedule config above, are per-broker configurable variables — see BR_6.1.2.8.
   • ⚠️ Trade Evolution sandbox testing note (Layer 2 only): when testing platform-native Layer 2 mechanisms above in the sandbox, only one currency pair is available for Forex — USD-TRY.

3. T-2min — Universal Drawdown Safety Gate runs first, ahead of any margin/volumetric calculation. Before any margin/exposure volumetric calculation runs, the Risk Engine computes:

   Total_Equity_Loss = Account_Starting_Equity - Current_Account_Equity

   • Account_Starting_Equity — the account's balance fixed at the start of the current challenge/level.
   • Current_Account_Equity — the account's real-time equity value at the moment of this T-2min check.
   • Total_Equity_Loss — the resulting dollar loss since the challenge/level began; this is the value tested against the 70% threshold below.

   IF Total_Equity_Loss ≥ 70% × Stop_Loss_Threshold (Table A/B) => FLATTEN_ALL
   IF Total_Equity_Loss < 70% × Stop_Loss_Threshold (Table A/B) => redirect to step 5 (Futures) and step 6 (Forex)

   • Stop_Loss_Threshold — the level's absolute stop-loss dollar figure, configured in Table A for Forex / Table B for Futures. This value is not a flow-time lookup against a single global constant — it is the specific dollar figure already configured per account, assigned at the moment that account was created, whether through a successful promotion (challenge/level-up) or through a successful checkout flow (new purchase). The account carries its own Stop_Loss_Threshold from that point forward; this step reads the value already attached to the account, it does not derive or recompute it at T-2min.
   • 70% × Stop_Loss_Threshold — the dollar boundary this gate tests against; reaching or crossing it revokes overnight holding privileges entirely, independently of whether margin/notional math would otherwise have passed.
   • Worked example — Futures account (gate passes): Account_Starting_Equity = $50,000, Current_Account_Equity = $47,000 → Total_Equity_Loss = $50,000 − $47,000 = $3,000. Table B Stop_Loss_Threshold = $5,000 → 70% × $5,000 = $3,500. Since $3,000 < $3,500, the gate passes — this account's Futures positions redirect to step 5 for the Required Margin audit.
   • Worked example — Forex account (gate breached): Account_Starting_Equity = $100,000, Current_Account_Equity = $92,500 → Total_Equity_Loss = $100,000 − $92,500 = $7,500. Table A Stop_Loss_Threshold = $10,000 → 70% × $10,000 = $7,000. Since $7,500 ≥ $7,000, the gate breaches — this account proceeds to step 4's global FLATTEN_ALL instead of step 7's Forex notional sweep.

4. T-2min — Gate breached → global FLATTEN_ALL, stop here. If the 70% boundary is breached, overnight holding privileges are revoked entirely: the system dispatches a global FLATTEN_ALL to the broker execution server, cancelling all working orders and clearing all open exposure for that user. Since this is a liquidation actually executed against this specific account, it triggers the per-user execution-alert mechanism — see step 12a below (NOTIFICATION WebSocket + Overnight_Auto_Liquidation_Alert email).

   • ⚠️ Race condition — when this gate and a real-time breach coincide for the same account at effectively the same instant, a priority order governs which action actually applies. See BR_6.1.2.3.

5. T-2min — Gate passed → dispatch to UC_6.1.3 for Futures, unconditionally. ** For each closing Futures asset class, once the Drawdown Gate (step 3-4) passes, this UC calls UC_6.1.3 — TRIM_TO_COMPLIANCE unconditionally — not only when a shortfall is found. UC_6.1.3 itself runs its two-check sequence for the closing-now asset class:

   • Check 1 — 25% ES-Equivalent Contract Cap (unchanged from CHR-100, already documented in UC_6.1.3): compares Total_Portfolio_ES_Equiv against Floor(Max_Contracts_ES_Equiv × Cap_Percent).
   • Check 2 — CME Overnight Margin Check (the calculation this step used to run inline here): once Check 1 is compliant, UC_6.1.3 computes Required_Margin = SUM(Open_Contracts × CME_Overnight_Margin_Rate) for the remaining open positions in the closing asset class and compares it to Available_Equity (Total_Equity − Margin_Already_Encumbered_By_Other_Closed_Asset_Classes).

   This UC's role for Futures is now limited to: running Gate 1 (steps 3-4) and triggering UC_6.1.3 once Gate 1 passes. This UC does not itself select which position to trim, compute Required_Margin/Available_Equity, or dispatch close orders for Futures — that is entirely UC_6.1.3's responsibility (Check 1 + Check 2, CHR-100). Once UC_6.1.3's margin script actually executes a market close order against this account (whether a full trim-loop resolution or a T-30s Active Failsafe FLATTEN_ALL), the per-user execution-alert mechanism fires for that account — see step 12a below. See BR_6.1.2.4.

6. T-2min through the institutional rollover (Ref: common_rules.md §22.1) — Forex-Specific Enforcement. Independently of the Futures check (both run off the same Drawdown-Gate-passed branch), open Forex notional exposure is swept against a shared cap. Unlike the other milestones, this is not a single-instant check — it runs continuously from T-2min through the institutional rollover:

   IF Total_Open_Forex_Notional > Forex_Overnight_Cap_Percent × Total_Account_Equity => trigger TRIM_TO_COMPLIANCE

   • Total_Open_Forex_Notional — the account's actual current open Forex notional exposure (all open Forex positions combined). Sourced differently per platform:

     • 🔧 TraderEvolution: this value can be read directly from TE's own API — GET /accountDetails returns a totalPositionsValue field, which is Total_Open_Forex_Notional for that account. No middleware-side aggregation is required on TE; the platform already computes and exposes the total.

     • 🔧 MT5: MT5 does not expose an equivalent single ready-made field, so the Adapter (the MT5 API layer) — not the middleware itself — must calculate it directly by summing each open position's own Position_Notional_Value, using these MT5 inputs:

       Input	MQL5 property	Python field
       Position size in lots	POSITION_VOLUME	position.volume
       Current position price	POSITION_PRICE_CURRENT	position.price_current
       Instrument	POSITION_SYMBOL	position.symbol
       Contract size	SYMBOL_TRADE_CONTRACT_SIZE	symbol.trade_contract_size
       Instrument calculation mode	SYMBOL_TRADE_CALC_MODE	symbol.trade_calc_mode
       Base currency	SYMBOL_CURRENCY_BASE	symbol.currency_base
       Profit currency	SYMBOL_CURRENCY_PROFIT	symbol.currency_profit

       Retrieved via positions_get() (open positions) and symbol_info() (per-symbol contract/currency metadata). Each position's own notional value is calculated using the same 3-case Position_Notional_Value formula UC_6.1.3's TRIM_TO_COMPLIANCE algorithm uses (BR_6.1.3.3) — the same formula, not a separate one, so the notional figure this UC sweeps against Allowed_Notional and the notional figure UC_6.1.3 later trims against are computed identically:

       IF Quote_Currency == USD (e.g. EURUSD):
         Position_Notional_Value = Lot_Size × Contract_Size_Per_Lot × Current_Price
       IF Base_Currency == USD (e.g. USDJPY):
         Position_Notional_Value = Lot_Size × Contract_Size_Per_Lot
       IF neither leg is USD (cross pair, e.g. EURGBP):
         Position_Notional_Value = Lot_Size × Contract_Size_Per_Lot × FX_Conversion_Rate(Base_Currency → USD)

       • Lot_Size — the position's size in lots (MT5 POSITION_VOLUME / position.volume).
       • Contract_Size_Per_Lot — the standard contract size for one lot (MT5 SYMBOL_TRADE_CONTRACT_SIZE / symbol.trade_contract_size; typically 100,000 units of the base currency for a standard lot).
       • Current_Price — the pair's current market price (MT5 POSITION_PRICE_CURRENT / position.price_current), quote currency per 1 unit of base currency.
       • FX_Conversion_Rate(Base_Currency → USD) — for a cross pair (neither leg is USD), the live conversion rate from the position's base currency directly to USD.
       • ⚠️ Live price requirement (same as UC_6.1.3): Current_Price and every FX_Conversion_Rate must be the real-time live market price from the MT5 Gateway API data stream at calculation time — never a cached, delayed, or stale rate.
       • Once each open Forex position's Position_Notional_Value is calculated this way, the Adapter sums them across all open Forex positions (converted to the account currency where needed, via SYMBOL_CURRENCY_BASE/SYMBOL_CURRENCY_PROFIT) to arrive at Total_Open_Forex_Notional — this aggregation happens inside the Adapter, not the middleware.
   • Forex_Overnight_Cap_Percent — the shared 25% cap-percent config value in Table C (A-26; Table_C_Cap_Percent). This is one config variable reused across three checks: this Forex exposure cap, the 25%-of-notional leg of the Futures Required Margin formula in step 5, and News Events' Notional_Cap_Percent — not three independently-set 25% constants.
   • Total_Account_Equity — the account's current total equity (all asset classes combined).
   • Forex_Overnight_Cap_Percent × Total_Account_Equity — the resulting dollar ceiling on total open Forex notional exposure the account may carry overnight (Allowed_Notional); this is what Total_Open_Forex_Notional is tested against.
   • Worked example: Total_Account_Equity = $100,000, Forex_Overnight_Cap_Percent = 25% (Table C) → Allowed_Notional = $100,000 × 0.25 = $25,000. The trader holds 0.5 lots EURUSD at Current_Price = 1.10 → Position_Notional_Value = 0.5 × 100,000 × 1.10 = $55,000 (quote currency is USD, per the 3-case formula above) — this is also Total_Open_Forex_Notional, since it's the only open Forex position. $55,000 > $25,000 (Allowed_Notional) → the sweep fails: dispatch to UC_6.1.3 as TRIM_TO_COMPLIANCE with Target_Limit = $25,000 — see step 8 below.

7. Forex shortfall — MT5 or TraderEvolution, unconditional dispatch. If Total_Open_Forex_Notional > Allowed_Notional, the middleware dispatches to UC_6.1.3 as a TRIM_TO_COMPLIANCE call with Target_Limit = Allowed_Notional — for both platforms alike, with no native leverage-reduction/Stop-Out check first (CHR-102). There is no reliable guarantee that either MT5 or TraderEvolution natively enforces this exact 25% threshold, so the Node.js middleware itself calculates the overage and dispatches market close orders directly via the respective platform API (MT5 Gateway API or TraderEvolution Admin API) to scale the open notional back to the 25% limit — the same algorithmic TRIM_TO_COMPLIANCE loop used for Futures/Rithmic (T-120s Primary Loop), not a platform-native leverage-reduction/Stop-Out mechanism. No native-capability check is performed first on either platform. As with the Futures dispatch (step 6), the per-user execution-alert mechanism fires once UC_6.1.3's margin script actually executes a close order against this account — see step 12a below.

8. Halt_Start_UTC — Maintenance Freeze. At the timestamp UC_6.1.1 signals for Halt Start, the gateway locks order routing for that symbol and dispatches Alert_Level = 'Halt_Active'.

   • ⚠️ Futures-only milestone. Halt_Start_UTC is sourced from the CME_Instrument_Details table (committed by UC_6.1.1 Step B) — a CME maintenance-window field that only exists for Futures instruments. Forex has no equivalent maintenance-halt window at present; MT5/TraderEvolution do not publish a comparable scheduled-halt timestamp this UC can read, so this step does not fire for Forex. It applies to Futures symbols only.

9. Halt_End_UTC — Maintenance Unfreeze. Order routing unlocks; the system dispatches Alert_Level = 'Halt_Cleared'.

   • ⚠️ Futures-only milestone — same reason as step 8 above: Halt_End_UTC is also sourced from CME_Instrument_Details, Futures-only data. This step does not fire for Forex.

10. Session_Open_UTC — Day Margin Restoration and lockout release. At the timestamp UC_6.1.1 signals for Session Open:

    1. The system drops the overnight CME margin weighting and returns to normal FCM intraday day-trading margins.
    2. The API gateway releases the Pre-Close Lockout filters (step 2), returning the account to standard active execution.
    3. The middleware fires an outbound webhook with Alert_Level = 'Session_Open', explicitly passing the affected Asset_Class and symbols — this is the same signal UC_4.10.1/UC_4.15.1 Soft Lock unfreeze should key off dynamically (see UC_6.1.1 A-18 note — those two UCs currently document a fixed wall-clock reset_time instead; tracked as a separate Update Flow, not fixed by this UC).

11. Every milestone — notification payload. At each milestone (Warning_60, Warning_30, Warning_10, Lockout_Active, Enforcement_Complete, Halt_Active, Halt_Cleared, Session_Open), the middleware publishes an outbound payload to the Flow 24 webhook catcher, mapping the specific symbol strings where applicable. This UC only constructs the payload — the 4-channel broadcast/routing logic itself is UC_4.1.3 BR_4.1.3.2's Alert Level matrix, reused not rewritten here. Enforcement_Complete specifically is broadcast once the entire T-2min cycle finishes evaluating all accounts for this asset class — a flow-level signal, dispatched every cycle regardless of how many (if any) individual accounts were actually flattened/trimmed during it. See BR_6.1.2.9.

    12a. Per-user execution alert — only for a trader actually flattened/trimmed this cycle (client-confirmed, 2026-10-12). At T-2min, the Risk Engine's margin calculation runs silently for every account — no notification is generated purely from running the check. A notification is generated only when the system actively executes a liquidation (step 4's Drawdown Gate FLATTEN_ALL) or a trim (steps 6/8's dispatch, once UC_6.1.3 actually fires a market close order) against that specific trader's account:

    1. Dashboard metrics refresh — no Zapier involved. Because the margin script's close order is a real, live market order sent to the gateway, the account's POSITION_METRICS and ACCOUNT_METRICS WebSocket streams automatically detect the resulting flat/reduced position and refresh the UI through the existing metrics pipeline (UC_4.12.2 and sibling UCs) — this UC/the margin script does not publish these metrics itself, and this leg of the notification does not go through Zapier at all.
    2. NOTIFICATION WebSocket — Notification Center entry. The margin script fires a NOTIFICATION WebSocket event explaining the liquidation/trim in that trader's Notification Center (same delivery mechanism as UC_4.7.1 BR_4.7.1.3's real-time push — no polling).
    3. Overnight_Auto_Liquidation_Alert email (SES-19).** The margin script separately fires the post-execution Overnight_Auto_Liquidation_Alert email via AWS SES to that specific trader, describing the automated action taken.

    See BR_6.1.2.9 for full detail.

---

6. Alternative Flows

• Alt-1 — Drawdown Gate and Futures/Forex checks both pass; no enforcement action taken.

  • Context: at T-2min, Total_Equity_Loss is below the 70% threshold, and both the Futures Required Margin check and the Forex exposure check are within limits.
  • The position(s) roll into the overnight session unmodified. No FLATTEN_ALL, no dispatch to UC_6.1.3, no leverage reduction. This is the expected common case, not an error path.

  ⚠️ Removed (CHR-102): the former "Alt-2 — Forex shortfall resolved via native leverage reduction, no trim dispatch" path no longer exists. Neither MT5's C++ Plugin nor TraderEvolution's native group leverage reduction is relied upon to clear a Forex overage — every Forex shortfall now dispatches unconditionally to UC_6.1.3 (see §5 step 7, BR_6.1.2.5).

---

7. Exceptional Flows

• Exc-1 — Universal Drawdown Safety Gate and a real-time Hard Breach (Level Stop) occur for the same account at effectively the same instant.

  • Full priority-order rule: BR_6.1.2.3.

• Exc-2 — Any failure in the margin/notional calculation itself at T-2min (missing CME overnight margin rate, a failed/unreachable notional lookup, a calculation exception, or any other error that prevents Required_Margin/Available_Equity/Total_Open_Forex_Notional from being computed with confidence) — universal fallback, not limited to the missing-CME-rate case.

  • ⚠️ Adam-confirmed universal fallback rule: "At any time if you encounter issues with margin calculation, all fallback plans are FLATTEN_ALL." This is a general standing rule, not scoped to any one failure mode — whatever specifically goes wrong inside the Required Margin (BR_6.1.2.4) or Forex notional-cap (BR_6.1.2.5) calculation, the system never proceeds on an uncertain/partial number, never silently lets an improperly-audited position roll overnight, and never substitutes a best-effort/default value in place of the missing input. The fallback is always the same: dispatch a global FLATTEN_ALL for the affected symbol/account and fire a Sev-1 alert to Slack #risk-ops.
  • The missing-CME-overnight-margin-rate case (CME_Instrument_Details has no committed Step B value for the current trading day, so MAX(CME_Overnight_Margin_Rate × Contract_Count, ...) cannot be evaluated with a null rate) is the first concretely identified instance of this rule, and mirrors UC_6.1.3's own missing-risk-data failsafe — BR_6.1.3.2, "Missing risk data → failsafe, never a best-effort sort" (CHR-100) — but Adam's rule is the broader, standing principle this UC must apply to any margin-calculation failure mode it encounters, not only this one example. See BR_6.1.2.12 for the full rule statement.

• Exc-3 — A Forex TRIM_TO_COMPLIANCE dispatch (MT5 or TraderEvolution) fails to resolve compliance in time (T-120s loop lags or fails).

  • Since CHR-102, this case is no longer conditioned on "no native leverage reduction available" — every Forex shortfall dispatches to UC_6.1.3 unconditionally, so this exception path applies universally. Ownership of the failure boundary passes to UC_6.1.3's own T-30s Node.js Active Failsafe (CR-20260906-001, universal per CHR-101) — this UC's responsibility ends at the dispatch call; it does not independently retry or escalate.

---

8. Business Rules

BR_6.1.2.1: Asset-Specific Pre-Close Lockout — Layer 1 state/notification only, Layer 2 owns the order filter rule

Full detail (Layer 1 state update/notification, Layer 2 per-platform native order-filter mechanisms, sandbox testing note) is specified in §5 Basic Flow step 2.

(Source: RFQ_ Stack Trading Prop Tech V7.pdf §Risk Enforcement Endpoints — "Asset-Specific Pre-Close Lockout Mechanism", lines 1716-1732)

---

BR_6.1.2.2: Universal Drawdown Safety Gate — 70% overnight equity check, runs before any margin math

Full formula and flatten/post-condition detail is specified in §5 Basic Flow steps 3-4. Account_Starting_Equity is not reset daily, and is distinct from the Daily Loss Limit's own Daily_Loss_Ratio-based formula (A-25).

---

BR_6.1.2.3: Priority order when the Drawdown Gate and a real-time breach coincide

When the Universal Drawdown Safety Gate (T-2min, overnight, scheduled) and a real-time Hard/Soft Breach (Daily Loss Limit / Max Drawdown, continuous) would both fire for the same account at effectively the same instant, the priority order is:

Hard Breach (Level Stop) > Universal Drawdown Safety Gate (70% overnight) > Daily Loss Limit soft breach

This extends BR_4.10.1.5 ("Hard Breach Supersedes Soft Breach") to also cover the Drawdown Gate. Only the highest-priority action's FLATTEN_ALL/status change is applied — the lower-priority path must not also fire a duplicate cancel/flatten or write a conflicting audit log entry for the same cycle.

(Source: QnA_init_docs.md A-20, extending BR_4.10.1.5)

---

BR_6.1.2.4: Required Margin — Futures dual-constraint calculation (canonical definition — ⚠️ calculation now owned by UC_6.1.3 Check 2)

⚠️ Moved. The full formula (Required_Margin = MAX(CME_Overnight_Margin, 25% × Notional) vs. Available_Equity), the multi-symbol CME_Overnight_Margin summing, the Rithmic Position_Notional_Value calculation, the Margin_Already_Encumbered_By_Other_Closed_Asset_Classes sub-procedure, and the asset-class scoping rules (already-closed / closing-now / not-yet-closing) are now specified in UC_6.1.3's Check 2 (CME Overnight Margin Check) — this UC no longer runs that calculation itself (see §5 Basic Flow step 5, which now dispatches to UC_6.1.3 unconditionally once Gate 1 passes). This anchor (BR_6.1.2.4) is kept as a pointer, not deleted, because the WBS deprecation note for the old UC_6.3 row (docs/BA/UC_6.1-6.3/index.md), UC_6.1.1 BR_6.1.1.5, and CHR-102's CR_summary.md all cite this exact anchor — they continue to resolve here, to the pointer, rather than breaking.

Per A-24 (BA decision, 2026-09-06), "Required Margin" still has a single canonical definition across the entire SRS — it just now lives in UC_6.1.3 instead of here. WBS's separate UC_6.3 ("Required margin") row remains deprecated and does not exist as a standalone UC; any future cross-reference to "Required Margin" logic should point to UC_6.1.3's Check 2, not here and not to a UC_6.3.

(Source: RFQ_ Stack Trading Prop Tech V7.pdf §Risk Enforcement Endpoints — "Futures Asset-Specific Margin Enforcement", lines 1733-1767; QnA_init_docs.md A-24; calculation relocated to UC_6.1.3 as Check 2 per user instruction (BA session), 2026-11-05)

---

BR_6.1.2.5: Forex 25% notional exposure cap — shared Table C config, universal Node.js dispatch (no native platform reliance)

Full formula, per-platform Total_Open_Forex_Notional sourcing (TraderEvolution direct field / MT5 calculated), and the unconditional dispatch enforcement path are specified in §5 Basic Flow steps 7-8.

Enforcement path change (CHR-102, client-confirmed 2026-09-15 — supersedes the former dual-path enforcement): the former "check native group leverage reduction, dispatch only if unavailable" branch (TraderEvolution) and the former "invoke the C++ MT5 Plugin to reduce leverage, no dispatch" branch (MT5) are both removed — both platforms now dispatch unconditionally.

(Source: CHR-102 — client-confirmed change, 2026-09-15; supersedes RFQ_ Stack Trading Prop Tech V7.pdf §Risk Enforcement Endpoints — "Forex Specific Enforcement", lines 1768-1794; QnA_init_docs.md A-26, A-27 — A-27's plugin-naming correction itself still stands, only its enforcement role changed)

---

BR_6.1.2.6: Halt/Session Open handling and notification payload construction

Full detail is specified in §5 Basic Flow steps 9-12 (Halt Start/End, Session Open restoration, and the shared payload-construction mechanism for every milestone).

(Source: RFQ_ Stack Trading Prop Tech V7.pdf §Risk Enforcement Endpoints — "Intraday Halt and New Session Open Operations" + "Notification Routing Logic", lines 1818-1870; QnA_init_docs.md Vòng 2 scope note)

---

BR_6.1.2.7: Native Broker Failsafe removed — no R|Admin dependency at T-30sec

Per CR-20260906-001, this UC does not own, configure, or depend on any T-30sec action. The former "Native Broker Failsafe Configuration" (Rithmic R|Admin "Time-Based Auto-Flatten" template) is fully removed from the architecture — R|Admin must not be configured with any Time-Based Auto-Flatten parameter for this purpose, and the Rithmic gateway does not auto-flatten on its own schedule. The T-30sec milestone UC_6.1.1 signals is consumed exclusively by UC_6.1.3's Node.js Active Failsafe. This closes A-22 (moot) and A-23 (reframed, no longer blocking) — no per-platform native failsafe (Rithmic, MT5, or TraderEvolution) is relied upon as the overnight-margin backstop; the Node.js middleware is universal across all three.

⚠️ Risk acceptance: removing the independent R|Admin hard failsafe means there is no backstop independent of the Node.js middleware itself — if the middleware crashes or hangs at T-30sec, nothing else runs. The client has accepted this tradeoff.

(Source: CR-20260906-001 — supersedes RFQ_ Stack Trading Prop Tech V7.pdf §"Native Broker Failsafe Configuration", lines 1795-1817; QnA_init_docs.md A-22, A-23)

---

BR_6.1.2.8: All enforcement timestamps are per-broker configurable variables, not hardcoded offsets

Every timestamp milestone this UC and UC_6.1.1 reference — T-60min, T-30min, T-10min, T-3min, T-2min, T-30sec, and (for Forex) Rollover_UTC itself — is a configuration value, not a value hardcoded into the enforcement logic. Each offset is stored as its own config variable (e.g. in a Table A/B/C-style config table, or an equivalent settings store), so that:

• Each offset can be changed independently (e.g. T-3min → T-5min for one asset class) without a code deployment.
• Each broker/platform (Rithmic, MT5, TraderEvolution) can carry its own value per milestone — the offsets are not required to be identical across platforms. For example, Rithmic's T-3min lockout offset and MT5's T-3min lockout offset are independently configurable, even though both currently default to the same 3-minute value.
• Any BA/Ops change to these values takes effect through config update, not a logic change to this UC or UC_6.1.1.

DST resolution is separate from this config layer — not a manual offset edit. Rollover_UTC's underlying wall-clock anchor (17:00 ET for Forex — common_rules.md §22.1) shifts between EST and EDT twice a year, but Ops/BA never edits a Rollover_UTC config value by hand to compensate — the EST⇄EDT transition is resolved automatically by the timezone-aware mechanism defined in UC_4.1.3 BR_4.1.3.5 (backend resolves the America/New_York IANA zone's local 17:00 every day, which natively yields the correct UTC instant in both EST and EDT). This UC and UC_6.1.1 only ever read the resulting pre-resolved Rollover_UTC/Official_Close_UTC timestamps — neither runs its own DST transition-date table or EST/EDT offset math. Futures' Official_Close_UTC is DST-resolved the same way but one layer further upstream — source-native at the CME Reference Data API itself (same BR_4.1.3.5), before UC_6.1.1's cron even writes it to CME_Instrument_Details.

(Source: user instruction, 2026-10-09; DST resolution per UC_4.1.3 BR_4.1.3.5, client-supplied verbatim, 2026-08-19)

---

BR_6.1.2.9: T-2min cycle completion broadcast + per-user execution alert

Full detail of the two mechanisms (Enforcement_Complete flow-level broadcast, and the 3-part per-user execution alert — POSITION_METRICS/ACCOUNT_METRICS auto-refresh, NOTIFICATION WebSocket, Overnight_Auto_Liquidation_Alert email) is specified in §5 Basic Flow step 12 and 12a.

⚠️ Not blocking: list_email.md's existing SES-19 trigger wording ("30 seconds prior to exchange lockout") describes only UC_6.1.3's T-30s failsafe case — it should be broadened to also cover this UC's own T-2min-driven liquidations/trims, since both use the same email.

---

BR_6.1.2.10: Client risk acceptance — imperfect overnight trim execution, firm capital prioritized over precision

The client has explicitly accepted that overnight margin/exposure enforcement cannot be dollar-perfect, and has set a standing priority rule for every case this UC dispatches into UC_6.1.3's TRIM_TO_COMPLIANCE loop (Required Margin shortfall, Forex notional shortfall, or any future trim dispatch from this UC):

The resulting hard 2000ms Re-Check snapshot-query timeout that implements this priority rule is specified in UC_6.1.3 BR_6.1.3.7 — this UC does not itself run the Re-Check loop (that is UC_6.1.3's exclusive responsibility, consistent with CR-20260906-001's existing division of ownership), so the mechanism itself is not specified here.

(Source: user instruction, 2026-10-26 — client-provided risk-acceptance and priority-rule language, applied to UC_6.1.3's Re-Check step)

---

BR_6.1.2.11: Applies to both SIM and LIVE account types — no environment branching

This UC's entire overnight margin/exposure enforcement logic — the T-60/30/10min market-status warnings, the T-3min Pre-Close Lockout (both Layer 1 state/notification and Layer 2 broker-native mechanisms), the T-2min Universal Drawdown Safety Gate, the Futures Required Margin dual-constraint audit, the Forex 25% notional exposure sweep, the Halt/Session Open handling, and the per-user execution-alert mechanism (BR_6.1.2.9) — runs identically for SIM and LIVE account types. There is no SIM-only or LIVE-only branch anywhere in this UC's milestones, formulas, or dispatch logic:

• The same Official_Close_UTC/Rollover_UTC timeline thread (UC_6.1.1) drives both account types' enforcement cycles.
• The same Required Margin formula (now UC_6.1.3's Check 2, BR_6.1.2.4) and Forex notional-cap formula (BR_6.1.2.5) apply regardless of whether the account is a SIM challenge/evaluation account or a funded LIVE account.
• Dispatch into UC_6.1.3's TRIM_TO_COMPLIANCE/FLATTEN_ALL mechanism, and the client risk-acceptance/priority rule governing it (BR_6.1.2.10), is the same for both — a SIM account's overnight position is trimmed/flattened through the exact same Rithmic/MT5/TraderEvolution gateway dispatch path as a LIVE account's.
• This is distinct from UI-layer concerns elsewhere in the SRS (e.g. UC_4.8.1 SIM / UC_4.12.2 LIVE having separate dashboard widgets that each surface this UC's broadcasts) — this UC's own backend enforcement logic has no such split.

(Source: user instruction, 2026-10-26 — BA note confirming this UC's enforcement scope covers both account types)

---

BR_6.1.2.12: Adam-confirmed universal fallback — any margin-calculation issue defaults to FLATTEN_ALL

The client (Adam) has set a standing, general-purpose fallback rule covering every margin/notional calculation this UC performs, not just the specific missing-CME-rate case already documented in Exc-2:

"At any time if you encounter issues with margin calculation, all fallback plans are FLATTEN_ALL."

Scope — applies to any calculation failure, not one enumerated list: this covers the Universal Drawdown Safety Gate's Total_Equity_Loss math (BR_6.1.2.2), the Futures Required Margin dual-constraint formula including the multi-symbol CME_Overnight_Margin sum and the Rithmic Position_Notional_Value calculation and the Margin_Already_Encumbered_By_Other_Closed_Asset_Classes sub-procedure (BR_6.1.2.4), and the Forex Total_Open_Forex_Notional sweep including its per-platform (TraderEvolution direct field / MT5 calculated) sourcing (BR_6.1.2.5) — any point in any of these where the required input is missing, unreachable, stale beyond a usable threshold, or the calculation itself throws/cannot complete. This is a standing principle this UC must apply going forward to failure modes not yet individually enumerated in this document, not a closed list limited to Exc-2's one worked case.

Why this matters distinctly from BR_6.1.2.10: BR_6.1.2.10's risk-acceptance/priority rule governs what happens once a shortfall has been correctly calculated and dispatched into UC_6.1.3's trim loop (imprecise trim execution, the Re-Check snapshot timeout). This rule (BR_6.1.2.12) governs the step before that — what happens when the Required Margin/notional figure itself cannot be reliably calculated in the first place. Both rules point to the same outcome (FLATTEN_ALL over any uncertain/partial action), from the client's same standing priority: firm capital protection over precision, applied at two different points in the pipeline.

(Source: user instruction, 2026-10-27 — Adam-confirmed requirement: "at any time if you encounter issues with margin calculation all fallback plans are FLATTEN ALL")

---

BR_6.1.2.13: Rithmic No Trading From/To daily sync cronjob — Rithmic only, separate from UC_6.1.1's CME-ingestion cron

[CR] Rithmic's Layer 2 No Trading From/To window (BR_6.1.2.1/§5 step 2's Rithmic bullet) cannot simply be configured once ahead of time the way TraderEvolution's "Liquidation Only" status or MT5's Close Only Trading Mode can — each whitelisted Futures symbol's close/open boundary shifts from day to day (different trading calendar per symbol, holidays, early closes), so the window itself must be re-pushed to Rithmic every day.

• A dedicated daily middleware cronjob pushes that trading day's close/open timestamps (Official_Close_UTC/Session_Open_UTC) for every one of the ~31 whitelisted Futures symbols (UC_6.1.1 CME_Whitelist) over to Rithmic, so the Adapter can set/refresh each symbol's own No Trading From/To window for that day's T-3min boundary.
• This is a separate cronjob from UC_6.1.1's own 01:00 UTC CME-ingestion cron. UC_6.1.1's cron is a pure ingestion job — it pulls the trading calendar from the CME Reference Data API into CME_Instrument_Details. This cronjob runs in the opposite direction — it pushes the already-ingested close/open timestamps from CME_Instrument_Details out to Rithmic — and is not itself a step of UC_6.1.1's flow.
• Rithmic only. Neither TraderEvolution nor MT5 needs an equivalent daily sync — their own Layer 2 lockout mechanisms (TE's instrument-level "Liquidation Only" status via a TE Scheduler task, MT5's TRADE_CLOSEONLY group-symbol setting) are configured once ahead of time and do not carry a daily, per-symbol close/open boundary the way Rithmic's No Trading From/To window does.
• Dependency, not a redundant data source. This cron consumes the same Official_Close_UTC/Session_Open_UTC values UC_6.1.1 already committed for the day — it does not independently query CME itself. If UC_6.1.1's own cron has not yet run or failed for a symbol that day (see UC_6.1.1 Exc-1/rolling 14-day backup), this cron pushes whatever CME_Instrument_Details currently holds for that symbol (fresh data or the rolling backup), rather than blocking on a fresh CME call of its own.
• Exact run time and failure-handling behavior (retry policy, alerting if a push to Rithmic fails) are not yet specified — flagged as an open implementation detail pending BA/Ops confirmation; this BR records only that the sync must happen daily, per-symbol, and ahead of each symbol's own T-3min.

(Source: user request, 2026-11-06 — "mốc T-3 với cơ chế được set up tại Rithmic 'No trading from/No trading to' thì hàng ngày middleware phải thực hiện chạy 1 cronjob để đẩy lại mốc thời gian giờ đóng/mở cửa của 31 symbol lại sang sàn để adapter thực hiện set lại mốc thời gian cho logic T-3. (Cron job này chỉ áp dụng với Rithmic không liên quan đến TE và MT5)")

---

9. Update History

---