SRS: Stage 3 KYC & Live Onboarding — UC_5.6: Flow 3F Market Data Setup

---

UC Index

---

Changelog

---

Glossary

For all shared project terminology, refer to: Project Glossary.

---

UC_5.6 — Flow 3F: Market Data Setup (Futures Only)

1. Overview

Scope note — Futures only: This UC applies exclusively to Futures (Asset_Class = 'Futures') traders. Forex traders have setup_status = 'N/A' (set by Flow 3D) and skip Flow 3F entirely.

Scope note — live phase vs evaluation phase: At Step 4 checkout (evaluation phase), all four exchange bundles (CME, NYMEX, CBOT, COMEX) were displayed at $0.00 — fully firm-paid. In the live phase governed by this UC, only the base CME feed (1 Level 2 feed, cost $140/month per Base_CME_Data_Cost in Table C) is covered by the firm. Additional exchange feeds (NYMEX, CBOT, COMEX) are billed to the trader at Standard Exchange Professional Data rates. is_professional = True is already set at contract signing (Flow 3E / UC_5.5), so professional rates apply immediately.

Scope note — form platform (STAGE3-042 confirmed 2026-08-12): The "Level 1 Setup Form" is hosted natively on the Stack Trading frontend dashboard — NOT Typeform or Zapier forms. The Flow 3D email contains a standard dashboard login link ("Action Required: Complete Market Data Setup"). On login, the dashboard forces the trader to the Market Data selection screen. Webhook fires on form submission from the native dashboard. This resolves Q2 (previously [MISSING]).

---

2. Trigger

Flow 3F fires from two paths:

Path 1 — Form webhook (standard): Inbound webhook from "Level 1 Setup Form" submission on the native Stack Trading dashboard. Trader accesses the dashboard via login link from Flow 3D email ("Action Required: Complete Market Data Setup").

Path 2 — DB-state forced screen (STAGE3-048 confirmed 2026-08-12): When Flow 3E completes (contract_status = 'Signed'), the DB state update is detected on next trader login. Dashboard reads contract_status = 'Signed' AND setup_status = 'Pending' → forces trader to the native Market Data selection screen directly (no additional email). This ensures traders who log in after signing the contract without going through the Flow 3D email are still routed to Flow 3F.

(Source: STAGE3-042 confirmed 2026-08-12; STAGE3-048 confirmed 2026-08-12)

Confirmed webhook payload fields (Source: QnA Q1 — confirmed 2026-08-10; supplemented 2026-08-10):

Option A vs Option B determination (confirmed): Zapier filter evaluates addon_ids array content and size:

• Option A (Standard — firm-paid): Form submitted with no premium add-ons selected. addon_ids contains only the 1 baseline CME feed (count == 1). Zapier writes setup_status = 'Complete', market_data_billable = False directly. If contract_status == 'Signed', Flow 3H is triggered in the same Zap execution.
• Option B (Premium — trader-paid): Form submitted with additional premium exchange feeds beyond the firm-covered CME base. Condition: presence of premium product codes in addon_ids (i.e. count > 1). Zapier calls POST /initiate-checkout with product_id = "LIVE_DATA_UPGRADE" and the full addon_ids array. setup_status = 'Pending_Payment' is set only after successful API response.

The "Level 1 Setup Form" was emailed to the trader by Flow 3D (UC_5.5) when setup_status was set to 'Pending' after the three-way aggregation gate fired.

Platform note (STAGE3-042 confirmed 2026-08-12): The "Level 1 Setup Form" is hosted natively on the Stack Trading frontend dashboard. Q2 resolved — platform is no longer [MISSING].

---

3. Pre-conditions

• Asset_Class = 'Futures' for user_id.
• Flow 3D (UC_5.5) has already executed: setup_status = 'Pending' in Users table.
• The "Level 1 Setup Form" email has been received by the trader (Path 1), OR contract_status = 'Signed' detected on login (Path 2 — STAGE3-048).
• Trader has completed and submitted the Level 1 Setup Form on the native dashboard.
• Webhook from the native dashboard has been received by Zapier.

Input validation rules (confirmed — Source: QnA Q5 2026-08-10):

• user_id must be a valid, active UUID in the PostgreSQL Users table.
• platform_selection must match an active system in Zapier Table I.
• All addon_ids must map to valid product codes in Table C (Global Variables).
• If any validation fails → Zap halts immediately, writes validation error to audit log, notifies trader to re-submit.

---

4. Post-conditions

Option A — Standard (firm-paid):

• setup_status = 'Complete' in Users table.
• market_data_billable = False in Users table.
• Gate evaluated: if contract_status = 'Signed' → Flow 3H (UC_5.8) triggered via internal webhook.
• If contract_status ≠ 'Signed': Zap terminates; Flow 3H will be triggered by Flow 3E when contract signing completes.

Option B — Premium add-ons (trader-paid):

• POST /initiate-checkout called on Middleware Hub with product_id = 'LIVE_DATA_UPGRADE' and addon_ids = [selected exchanges].
• Payment link emailed to trader by Middleware via the active payment processor. REMOVED (STAGE3-042 / UC_5.5 v1.8 2026-08-14): Option B payment is completed entirely on the Stack Trading dashboard. Frontend calls POST /calculate-cart + POST /execute-checkout inline — no payment link email sent.
• setup_status = 'Pending_Payment' in Users table.
• Zap terminates; payment confirmation handled by Flow 3G (UC_5.7).

---

5. Basic Flow

1. Webhook received from Level 1 Setup Form: payload contains user_id and selected market data packages.

2. Zapier evaluates option selected:

   Option A — Standard (firm-paid, includes 1 Level 2 CME Feed only):

   • Condition: addon_ids array contains only the baseline CME feed (count = 1).
   • UPDATE Users table WHERE user_id = webhook.user_id:
     • setup_status = 'Complete'
     • market_data_billable = False
   • Aggregation gate check: query contract_status for user_id.
     • IF contract_status = 'Signed' → dispatch internal Webhook to trigger Flow 3H (UC_5.8); Flow 3F Zap terminates.
     • ELSE → Zap terminates; wait for contract (Flow 3E will re-evaluate the gate).

   Option B — Premium add-ons (trader-paid, feeds beyond firm-covered CME):

   • Condition: addon_ids array contains CME + at least one premium bundle (count > 1).
   • Call Middleware Hub POST /initiate-checkout:
     • product_id = 'LIVE_DATA_UPGRADE'
     • addon_ids = [list of selected exchange bundles]
   • Middleware evaluates ACTIVE_PAYMENT_PROCESSOR config and emails trader a payment link. REMOVED (STAGE3-042 / UC_5.5 v1.8 2026-08-14): Payment is completed on dashboard via POST /calculate-cart + POST /execute-checkout inline — no email sent.
   • Payment execution on dashboard (two sub-paths):
     • Sub-path B1 — Trader has saved card (customer_vault_id IS NOT NULL):
       • Frontend renders 1-Click Confirmation Modal: displays "Total: $[Amount]" and "Pay with vaulted card [last 4 digits]".
       • Trader confirms → frontend calls POST /execute-checkout.
       • Backend executes charge against stored customer_vault_id — no re-entry of card details.
       • On success → payment processor sends payment_success webhook → Flow 3G (UC_5.7) fires.
     • Sub-path B2 — Trader has no saved card (customer_vault_id IS NULL):
       • See BR_5.6.10: Secure Checkout Screen opens for card capture via NMI Collect.js.
       • After successful vault registration → checkout proceeds as Sub-path B1.
   • DB update is executed ONLY after successful POST /initiate-checkout response:
     • UPDATE Users WHERE user_id: setup_status = 'Pending_Payment'
   • Zap terminates.

   (Source: Zapier Integration V7.pdf Flow 3F lines 1229–1249; QnA Q1 confirmed 2026-08-10; STAGE3-042 confirmed 2026-08-12)

---

6. Alternative Flow

• [Contract already signed before form submission (Option A)]

  • Trader submits Level 1 Setup Form after Flow 3E has already set contract_status = 'Signed'.
  • Option A path: gate is immediately satisfied → Flow 3H triggered in this Zap execution.

• [Contract already signed before form submission (Option B)]

  • Trader submits Level 1 Setup Form and selects premium add-ons after Flow 3E has already set contract_status = 'Signed'.
  • setup_status = 'Pending_Payment'; Flow 3H deferred until Flow 3G confirms payment.
  • When Flow 3G sets setup_status = 'Complete' and market_data_billable = True, gate check in Flow 3G finds contract_status = 'Signed' and triggers Flow 3H immediately.

• [Trader selects only CME (Option A) having originally selected NYMEX/CBOT/COMEX at evaluation]

  • Live-phase selection is independent of evaluation-phase selection. The trader may choose to not carry premium feeds into live phase.
  • Result: market_data_billable = False; firm covers only the standard CME feed.

---

7. Exceptional Flow

• [Level 1 Setup Form webhook never received (stagnation)] (Confirmed — client 2026-08-25)

  • No separate stagnation timeout exists for this form. Controlled by the global Flow 19 Stagnation Monitor: after contract signing, stagnation_deadline = contract_signed_date + 90 days. Reminder emails fire at D-14, D-7, D-2, D-1 before the deadline. If setup_status = 'Pending' at deadline, Stagnation Termination activates.
  • Additionally, a background cron job scans setup_status = 'Pending' every 72 hours and dispatches a reminder email to prompt the trader to complete the form.
  • No Ops escalation path short of the Stagnation Monitor (no Freshdesk ticket, no Slack alert for this specific gap).
  • (Source: Flow 19 Stagnation Monitor confirmed; client confirmed 2026-08-25)

• [Webhook received with unknown user_id] (Confirmed — client 2026-08-25)

  • Middleware returns HTTP 404 Not Found with error detail. A SEV-1 alert is fired to Slack #risk-ops immediately for manual Ops investigation.
  • Do NOT silently drop — an orphaned webhook may indicate form misconfiguration or a spoofed submission.
  • (Source: client confirmed 2026-08-25)

• [Webhook payload does not include market data selection] (Confirmed — client 2026-08-25)

  • Two cases:
    • Case 1 — Payload valid but addon_ids empty or absent: Treat as Option A (no premium feeds selected). Set market_data_billable = False, continue onboarding.
    • Case 2 — Payload malformed (invalid JSON or structural error): Reject — log error to bps_audit_logs, fire Ops Slack alert. Do NOT default to Option A silently — risk of wrong Rithmic permissions.
  • (Source: client confirmed 2026-08-25)

• [Middleware Hub POST /initiate-checkout fails (Option B)] (Updated — Source: STAGE3-027 confirmed 2026-08-11; supersedes Q4 2026-08-10 on retry behavior)

  • setup_status naturally stays 'Pending' — the DB UPDATE to 'Pending_Payment' is only executed AFTER a successful API response. If the call fails → Zap halts immediately → DB update is never reached. No rollback required.
  • Retry: No automated retry or fallback is natively documented. POST /initiate-checkout is a synchronous dependency (must check ACTIVE_PAYMENT_PROCESSOR config and dynamically generate a payment link). Manual recovery required.
  • Ops alert: AWS CloudWatch alarm (SEV-1 — "Middleware Hub Unresponsive") triggers on 5xx or unresponsive endpoint → pushes immediate alert to designated Ops Slack channel. Per Production Readiness Checklist §6.0: centralized monitoring and alerting mandated for all Zapier failures, task quota thresholds, and middleware endpoint errors.
  • Recovery path: Admin or developer must manually replay the failed Zapier run, OR assist the trader via the authenticated admin panel once the endpoint is restored. Trader remains stuck at setup_status = 'Pending', blocking Flow 3H, until manual recovery is executed. (Source: STAGE3-027 confirmed 2026-08-11 — Zapier Integration V7 blueprint + Production Readiness Checklist §6.0)

• [Duplicate webhook delivery (idempotency)] (Confirmed — client 2026-08-25)

  • Idempotency guard REQUIRED. Before executing Option A or Option B logic, Middleware checks current setup_status:
    • If setup_status IN ('Pending_Payment', 'Complete') → return HTTP 200 OK immediately (no-op). No checkout call, no Flow 3H re-trigger.
  • Guard uses provider_event_id / event_id from the webhook payload for dedup tracking.
  • (Source: client confirmed 2026-08-25)

• [Option B — trader has no saved card / customer_vault_id IS NULL (STAGE3-075 / M-16)] (Confirmed — Source: STAGE3-075 confirmed 2026-08-15)

  • When the trader proceeds to pay for Option B premium feeds and no customer_vault_id exists for the trader in PostgreSQL, the system does not error out.
  • Middleware Hub detects customer_vault_id IS NULL and opens the Secure Checkout Screen (Stack Trading-owned card entry screen that embeds NMI Collect.js / Hosted Fields) so the trader can enter card details securely.
  • NMI Collect.js tokenises the card client-side → a payment_token is returned to the frontend → frontend POSTs payment_token to backend → backend submits token to NMI Customer Vault API → NMI creates vault entry and returns customer_vault_id → backend saves customer_vault_id in PostgreSQL Users table → redirects to Screen 1 (Manage Add-ons) → calls GET /user/saved-cards to refresh the saved-card list.
  • After successful card save, the Option B checkout flow proceeds as normal.
  • (Source: STAGE3-075 confirmed 2026-08-15; STAGE3-059 confirmed 2026-08-15)

• [Option B — NMI card capture failure] (Confirmed — Source: STAGE3-059 / H-11 confirmed 2026-08-15)

  • If NMI Collect.js returns an error (tokenisation failure, network timeout, or NMI API non-200), the payment_token is invalid.
  • Backend does NOT submit the invalid token to NMI Customer Vault; customer_vault_id is not written.
  • Checkout is NOT initiated; setup_status remains 'Pending'.
  • Frontend displays an error on the Secure Checkout Screen and prompts the trader to retry card entry.
  • PCI-DSS constraint: raw card data NEVER reaches the Stack Trading backend — Collect.js/Hosted Fields iframe performs all card capture client-side. (Source: STAGE3-059 / H-11 confirmed 2026-08-15)

• [Eval-to-Live transition — NYMEX/CBOT/COMEX feeds deactivated on entry] (Confirmed — client 2026-08-25)

  • When a Futures trader transitions from eval (SIM) to live phase, ALL premium feeds active during evaluation (NYMEX, CBOT, COMEX) are automatically deactivated.
  • System uses Bifurcated Gateways: eval runs on Rithmic Paper Trading (demo server); live runs on Live FCM Rithmic (separate server). On live entry, eval sub-account is disconnected — no feed carry-over.
  • On Live FCM Gateway, only standard CME feed is active by default (Option A). Premium feeds remain inactive until Option B payment confirmed via Flow 3G.
  • No explicit deactivation API call required — the gateway separation handles it structurally.
  • (Source: client confirmed 2026-08-25)

• [CASE-RE-PASS-01 — Trader re-enters Live in same calendar month, exact feed match: bypass payment] (Confirmed — Source: CR-20260824-001 client confirmed 2026-08-24)

  • Scope: Futures only (asset_class = 'Futures'). Forex traders skip this check entirely (see BR_5.6.13).
  • Trigger: Trader passed SIM challenge and Flow 3F fires again for the same user_id in the same calendar month as a prior Live Pro Data payment. Middleware detects re-entry context by checking market_data_paid_until OR the invoices table for status = 'paid' rows within billing_period_month + year matching the current calendar month.
  • Condition: new_feed_selection ⊆ already_paid_feeds[] for the current billing month — the trader selected the same or a subset of the Pro feeds already paid this month.
  • Hành động:
    1. Skip payment screen entirely — do NOT call POST /initiate-checkout.
    2. Call Rithmic API to re-enable the previously paid Pro feeds on the trader's User ID.
    3. Set setup_status = 'Complete', update market_data_billable per selection.
    4. Write audit log: reactivation_reason = 'INTRA_MONTH_NO_CHARGE'.
  • Rationale: Pro Market Data fees and CME subscriber agreements are bound to Rithmic User ID (not Sub-Account). On Reset/Rebuy only the Sub-Account is cycled — the User ID is preserved with all intra-month entitlements intact. Double-charging for the same calendar month is incorrect. (Source: CR-20260824-001 client confirmed 2026-08-24)

• [CASE-RE-PASS-02 — Trader re-enters Live in same calendar month, selects delta (new) feeds: charge delta only] (Confirmed — Source: CR-20260824-001 client confirmed 2026-08-24)

  • Scope: Futures only (asset_class = 'Futures'). Forex traders skip this check entirely (see BR_5.6.13).
  • Trigger: Same re-entry context as CASE-RE-PASS-01, but the trader selects ≥1 feed not present in already_paid_feeds[] for the current billing month.
  • Condition: delta_feeds = new_feed_selection − already_paid_feeds[] is non-empty.
  • Hành động:
    1. Split selection into two groups:
       • reactivation_feeds = intersection with already_paid_feeds[] → re-enable free (no charge).
       • delta_feeds = new feeds not in already_paid_feeds[] → require payment.
    2. Call POST /initiate-checkout only for delta_feeds (e.g. trader adds NYMEX not previously paid → charge NYMEX rate only, not full CME+NYMEX bundle).
    3. After delta payment confirmation:
       • Rithmic API re-enables reactivation_feeds (free).
       • Rithmic API activates delta_feeds (paid).
    4. Set setup_status = 'Complete', market_data_billable = True.
    5. Write audit log: reactivation_reason = 'INTRA_MONTH_DELTA', delta_feeds = [...]. (Source: CR-20260824-001 client confirmed 2026-08-24)

---

8. Business Rules

BR_5.6.1: Futures-Only Scope

Flow 3F is only executed for Asset_Class = 'Futures' traders. Forex traders skip this flow entirely; their setup_status is set to 'N/A' by Flow 3D.

(Source: Zapier Integration V7.pdf Flow 3D lines 1202–1205; Flow 3F line 1229)

BR_5.6.2: Four Exchange Bundles — CME Pre-selected, Others Optional

The Level 1 Setup Form presents four exchange data packages:

CME is pre-selected; NYMEX, CBOT, and COMEX are optional add-ons.

YM/MYM source conflict resolved (STAGE3-030 2026-08-11): The User Journey description groups YM under a "CME" description ("Currency futures, indices (ES, NQ, YM)"). This is a legacy documentation error. The CME_Whitelist SQL initialization script is the authoritative operational source: YM and MYM are registered under Exchange = 'CBOT', not CME. CME_Whitelist DB supersedes User Journey grouping. YM/MYM are therefore trader-paid Option B instruments.

The tradeable symbols within each bundle are governed by the CME_Whitelist table. Symbols not in CME_Whitelist.Enabled = TRUE are blocked by the Middleware Hub at order routing.

Note: CBOT Grains (ZC, ZW, ZS, ZM, ZL) and CME Livestock (HE, LE, GF) are deferred to a future release and NOT available in the current form.

(Source: Zapier Integration V7.pdf CME_Whitelist table lines 586–654; RFQ_ Website and Dashboard Implementation V7.pdf Step 4 Market Data Selection lines 230–242; STAGE3-030 confirmed 2026-08-11)

BR_5.6.3: Option A — Firm-Paid Standard Feed

Option A (standard) includes exactly 1 Level 2 CME Feed covered by the firm. The monthly cost absorbed by the firm is Base_CME_Data_Cost = $137.50 (client-confirmed 2026-08-24). Selecting Option A sets:

• setup_status = 'Complete'
• market_data_billable = False

No charge to the trader. Flow 22 Monthly Data Fee Billing excludes this trader (Market_Data_Billable = False).

Source conflict (client override): Zapier Integration V7.pdf Table C line 201 states Base_CME_Data_Cost = $140. Client has confirmed the operative value is $137.50 (2026-08-24). Client-confirmed value supersedes Table C per priority chain (client supplement > Customer supplies v7). All UC references to CME base cost use $137.50.

(Source: Zapier Integration V7.pdf Flow 3F lines 1235–1239; Table C line 201 — overridden by client confirmation 2026-08-24)

BR_5.6.4: Option B — Trader-Paid Premium Add-ons

Option B applies when the trader selects any exchange bundle beyond the firm-covered CME feed. The system calls POST /initiate-checkout on the Middleware Hub with:

• product_id = 'LIVE_DATA_UPGRADE'
• addon_ids = [list of selected exchange bundles]

Middleware determines the active payment processor via ACTIVE_PAYMENT_PROCESSOR config (not hardcoded). emails the trader a payment link. REMOVED (STAGE3-042 / UC_5.5 v1.8 2026-08-14): Payment is completed on the Stack Trading dashboard — frontend calls POST /calculate-cart + POST /execute-checkout inline.

Payment execution paths:

• customer_vault_id IS NOT NULL (saved card on file): Frontend renders 1-Click Confirmation Modal ("Total: $[Amount]", "Pay with vaulted card [last 4 digits]"). Trader confirms → POST /execute-checkout → backend charges stored vault — no re-entry of card details.
• customer_vault_id IS NULL (no saved card): Secure Checkout Screen opens (BR_5.6.10) → NMI Collect.js card capture → vault registered → checkout proceeds as above.

setup_status = 'Pending_Payment' until payment is confirmed by Flow 3G.

(Source: Zapier Integration V7.pdf Flow 3F lines 1241–1249)

BR_5.6.5: Billing Distinction — Live Phase vs Evaluation Phase

This UC governs the live phase market data setup. The billing model is fundamentally different from the evaluation phase (Step 4 checkout):

is_professional = True is already set by Flow 3E (contract signing), so professional-tier exchange rates apply in the live phase.

(Source: RFQ_ Website and Dashboard Implementation V7.pdf §Market Data Lifecycle Disclosure; [Internal Stacktrading] User journey - EN_v6.md lines 255, 840)

BR_5.6.6: Dual Aggregation Gate — Both Legs Required for Flow 3H

Flow 3H (live provisioning, UC_5.8) can only be triggered when BOTH of the following are true:

• contract_status = 'Signed'
• setup_status IN ('Complete', 'N/A')

Flow 3F (this UC) is one of three paths that can set setup_status = 'Complete': Option A sets it directly; Option B defers to Flow 3G. If the contract is not yet signed when the form is submitted (Option A), this Zap terminates and Flow 3E will re-check the gate when the contract is signed.

(Source: Zapier Integration V7.pdf Flow 3F lines 1238–1239; Flow 3E lines 1223–1227)

BR_5.6.7: Market Data Billable Flag and Monthly Invoice Formula

market_data_billable determines whether Flow 22 (Monthly Data Fee Billing) includes this trader in the monthly invoice cycle:

• market_data_billable = False (Option A): firm absorbs the CME base cost; trader receives no monthly bill for data.
• market_data_billable = True (set by Flow 3G after Option B payment): Middleware generates a monthly invoice using the tiered formula below.

Cost allocation by career phase (client-confirmed 2026-08-24):

Tiered billing formula (confirmed — Source: QnA STAGE3-013 2026-08-10; Base_CME value updated client 2026-08-24):

market_data_billable initialization at Onboarding (client-confirmed 2026-08-24):

For Level 1 & Level 2 traders entering live via Flow 3F: market_data_billable = True is set from Day 1 for Option B selections. Stripe/Triple-A payment card is updated at onboarding to enable monthly invoice scanning by Flow 22. Level 1 & Level 2 traders bear full Total_Market_Data_Cost each month until Level 3 promotion.

For Level 5 direct-entry traders: see BR_5.6.11 — firm-pay applies immediately at onboarding.

Consistent with GET /financial/calculate-data-refund endpoint: at Level 3 promotion, backend refunds only MARKET_DATA_BASE fees paid during Level 1 & 2 — confirming those were trader-paid at Level 1 & 2.

Source resolution: Zapier Integration V7.pdf Flow 22 lines 2186–2187 summary showed only Total − Base_CME (shorthand, Level 3+ formula). The detailed spec at "Perks & Batch Process Endpoints" in the same Zapier V7 document explicitly defines the tiered logic (Level 1 & 2 = no deduction; Level 3+ = deduct base). Both Zapier V7 detailed spec and RFQ_ Stack Trading Prop Tech V7.pdf lines 1585–1590 are now in agreement. Conflict resolved — no client follow-up needed.

(Source: Zapier Integration V7.pdf §Perks & Batch Process Endpoints — tiered billing logic; RFQ_ Stack Trading Prop Tech V7.pdf lines 1585–1590; QnA STAGE3-013 confirmed 2026-08-10; client billing protocol confirmed 2026-08-24)

---

BR_5.6.8: Level 1 & 2 — Micros Only Instrument Restriction (Table B)

Per the Futures Configuration Matrix (Table B), Level 1 and Level 2 traders are strictly restricted to micro-contract instruments only:

Interaction with Option B (CBOT add-on): A Level 1 or Level 2 trader may technically purchase the CBOT data add-on (Option B). However, even with the CBOT feed active, the order routing gateway will block trade execution natively at the platform level for YM and MYM — the platform constraint is enforced independently of the billing/selection logic. The data subscription and the trading permission are separate controls.

Implication for QA: AC-5.6-10 covers this scenario. Test that CBOT data subscription can be purchased by Level 1/2 trader, but YM/MYM orders are still blocked at execution.

(Source: Futures Configuration Matrix Table B — Level 1 & 2 Micros Only; STAGE3-030 confirmed 2026-08-11)

---

BR_5.6.9: Option B Payment Card Capture — NMI Collect.js / Hosted Fields (PCI-DSS) (H-11 / STAGE3-059)

When a trader pays for Option B (premium market data add-ons), card capture for the payment is handled via NMI Collect.js / Hosted Fields embedded client-side in the Stack Trading frontend. This is the PCI-DSS compliant mechanism:

1. NMI Collect.js iframe renders the card input fields — raw card numbers are captured entirely within the NMI iframe, never in Stack Trading DOM or backend.
2. On submission, NMI Collect.js returns a payment_token (one-time tokenised card reference) to the frontend.
3. Frontend POSTs payment_token to Stack Trading backend API.
4. Backend submits payment_token to NMI Customer Vault API (POST /customer-vault).
5. NMI creates a vault entry and returns a customer_vault_id.
6. Backend saves customer_vault_id in PostgreSQL Users table (field: customer_vault_id).
7. Frontend redirects to Screen 1 (Manage Add-ons dashboard screen).
8. Frontend calls GET /user/saved-cards to load the updated saved card list.

PCI-DSS constraint: Raw card numbers NEVER transit the Stack Trading backend. Only payment_token (short-lived) and customer_vault_id (persistent) are handled server-side.

(Source: STAGE3-059 / H-11 confirmed 2026-08-15)

---

BR_5.6.10: No Saved Card on File — Secure Checkout Screen Opens (M-16 / STAGE3-075)

When a trader with customer_vault_id IS NULL in PostgreSQL attempts to pay for Option B:

• Middleware Hub detects no vault ID on file for the trader.
• Instead of erroring, the system opens the Secure Checkout Screen — a Stack Trading-owned screen that embeds NMI Collect.js/Hosted Fields for card entry.
• After successful card tokenisation and vault registration (per BR_5.6.9), customer_vault_id is written to PostgreSQL and the Option B checkout proceeds.

This screen also covers the "Change Payment Method" action from Manage Add-ons (Screen 1) where a trader has an expired or invalid card on file.

(Source: STAGE3-075 / M-16 confirmed 2026-08-15; STAGE3-059 / H-11 confirmed 2026-08-15)

---

BR_5.6.11: Level 5 Direct-Entry — Immediate Firm-Pay at Onboarding (client-confirmed 2026-08-24)

Traders entering the live phase directly at Level 5 (from the highest Advanced Track tier) are classified as Senior Live from Day 1. The firm's co-pay policy applies immediately at onboarding — there is no Provisional self-pay phase.

Behavior at Flow 3 (Market Data Setup) for Level 5 direct-entry traders:

Contrast with Level 1 & Level 2 Provisional traders:

• Level 1 & 2: market_data_billable = True from Day 1 — trader pays 100% of Total_Market_Data_Cost each month. Firm refunds MARKET_DATA_BASE retroactively at Level 3 promotion via GET /financial/calculate-data-refund.
• Level 5: firm covers CME base immediately — no pay-then-refund cycle. The Provisional self-pay → Level 3 refund pathway does NOT apply.

System implementation: At Flow 3F onboarding, the system must detect the trader's Current_Level. If Current_Level = 5, apply the $137.50 firm subsidy pre-calculated before calling POST /initiate-checkout:

1. Call POST /calculate-cart — Middleware reads Current_Level; if Level ≥ 3 (including Level 5), applies formula Invoice_Amount = Total_Market_Data_Cost − $137.50 and returns discounted total to frontend.
2. Frontend displays discounted total.
3. Call POST /execute-checkout with the pre-discounted amount — no separate deduction step at checkout.

For Option A at Level 5: Total_Market_Data_Cost = $137.50, Invoice_Amount = $0.00 — no card charge required.

Level 5 re-entry after Hard Breach (confirmed — client 2026-08-25): When a Level 5 trader Hard Breaches and uses Re-Buy, they revert to SIM (Level 0 — Associate Track) on Rithmic Paper Trading. Firm covers 100% of demo data during SIM phase. Trader returns to Senior Live status only after re-passing the SIM challenge and completing full Live Onboarding again — NOT from Day 1 of the Re-Buy. The Provisional self-pay → Level 3 refund pathway does not apply on Level 5 re-entry.

(Source: client confirmed 2026-08-24; subsidy sequence confirmed client 2026-08-25)

---

BR_5.6.12: Intra-Month Pro Data Delta Assessment — Futures Only (CR-20260824-001)

When a Futures trader (asset_class = 'Futures') re-enters the Live path (Flow 3F fires again for the same user_id) within the same calendar month as a prior Live Pro Data payment, Middleware MUST perform an Intra-Month Delta Assessment before invoking any payment flow.

Check: Query market_data_paid_until OR invoices table (status = 'paid', billing_period_month + year = current month) for the trader's user_id to determine already_paid_feeds[].

Rationale: Pro Market Data fees and CME subscriber agreements are bound to the Rithmic User ID (not Sub-Account). On Reset/Rebuy, only the Sub-Account is cycled — the User ID and its intra-month entitlements are preserved. Charging the full fee again within the same billing month is incorrect.

This rule does NOT apply to:

• Forex traders (see BR_5.6.13).
• First-time Live entry in a month (no prior paid record in already_paid_feeds[] → standard billing applies per BR_5.6.4/BR_5.6.7).

(Source: CR-20260824-001 client confirmed 2026-08-24)

---

BR_5.6.13: Forex Exclusion from Intra-Month Reconciliation Protocol (CR-20260824-002)

The Intra-Month Delta Assessment (BR_5.6.12) and CASE-RE-PASS-01/02 logic do NOT apply to Forex traders (asset_class IN ('Forex_MT5', 'Forex_TE')).

Rationale: Stack Trading pays a flat monthly server cost for the MT5 and TraderEvolution white-label platforms. There are no per-user variable fees tied to individual Forex sub-accounts — creating, deleting, or re-provisioning a Forex sub-account within a month generates no incremental billing. Therefore there is no risk of double-charging, and no reconciliation step is needed.

Forex traders are already excluded from Flow 3F entirely (setup_status = 'N/A' per BR_5.6.1). This BR explicitly confirms that even in future contexts where Forex billing logic is added, CR-20260824-001 intra-month protocol remains Futures-only until explicitly extended by a new CR.

(Source: CR-20260824-002 client confirmed 2026-08-24)

---

The primary flow (Option A and Option B form submission) has no Stack Trading-owned screens — all processing is automated via Zapier. However, Option B payment introduces two Stack Trading-owned screens:

• "Level 1 Setup Form" — hosted natively on the Stack Trading frontend dashboard (STAGE3-042). Form submission fires a webhook to Zapier.
• Screen 1 — Manage Add-ons — the dashboard screen the trader lands on after card registration completes. The frontend calls GET /user/saved-cards to populate the saved card list after redirect. (STAGE3-059)
• Screen 2 — Secure Checkout Screen (NMI Collect.js / Hosted Fields) — a Stack Trading-owned checkout screen that embeds NMI Collect.js/Hosted Fields iframe for PCI-DSS compliant card capture. Opens when customer_vault_id IS NULL (no card on file) or when the trader selects "Change Payment Method". (STAGE3-059 / H-11; STAGE3-075 / M-16)
• Option B payment widget — embedded in the Market Data selection screen on the Stack Trading dashboard. Frontend calls POST /calculate-cart + POST /execute-checkout inline. No payment link emailed (STAGE3-042 / UC_5.5 v1.8).

Wireframe references:

• Market Data Setup Screen (full flow): References/Wireframe/Stage 3/Stage 3: Total wireframe/Flow 3F: Market data setup.png
• See Wireframe Index for screen inventory.

---

10. Screen Description and Business Rules

Screen 2 — Secure Checkout Screen (NMI Collect.js / Hosted Fields)

(Source: STAGE3-059 / H-11 confirmed 2026-08-15; STAGE3-075 / M-16 confirmed 2026-08-15)

---

11. Acceptance Criteria

(Confirmed by client 2026-08-10 — Source: QnA Q5)

Input validation ACs (confirmed):

• If user_id is not a valid, active UUID in PostgreSQL Users table → Zap halts, writes validation error to audit log, notifies trader to re-submit.
• If platform_selection does not match an active system in Zapier Table I → Zap halts.
• If any value in addon_ids does not map to a valid product code in Table C → Zap halts.

---

END OF UC_5.6