UC_4.15.3: Scenario B — Live Failure (In-App Re-Buy)

Architecture note: LIVE Re-Buy is the direct counterpart of UC_4.10.3 (SIM Reset) — same gate architecture (Status → Sanctions → Vaulted card) and the same payment/promo-code mechanics. Sections identical to UC_4.10.3 reference it directly rather than repeating content. Five confirmed divergences are written out in full for LIVE:

1. No "Reset — reuse sub-account" branch. LIVE's trading sub-account is provisioned fresh on every Re-Buy, regardless of whether it was cleaned up before or after archive_date.
2. Founder pricing has no window split. is_founder == TRUE always resolves to locked_rebuy_price, regardless of the archive_date window.
3. Archival/Day 0 lifecycle differs from SIM's timing. Dashboard freezes at exact breach metrics until archive_date, not reset immediately.

Document References

1. Overview

2. Trigger

This UC has three entry points that all land on the same Re-Buy purchase modal (§9.3):

• Entry Point 1 — Dashboard (Failure Modal): Status = 'Terminated' after Hard Breach (UC_4.15.2) → the Dashboard renders the permanent Frosted Glass overlay. On top of it, the Failure Modal (§10.1/§10.2 — "Trading Authority Revoked") appears and persists on every Dashboard visit until purchase → user clicks CTA "Start Associate Track" → system begins pricing calculation (§5 Step 1).
• Entry Point 2 — Account Actions screen ("Re-Buy" button): the terminated trader's Settings → Account Actions screen exposes a "Re-Buy" CTA that bypasses the Failure Modal and goes straight into pricing calculation (§5 Step 1).
• Entry Point 3 — Founding Mentor overlay acknowledgement: per UC_4.15.2 §6 Alternative Flow, after the Founding Mentor-specific overlay is acknowledged, the Re-Buy Modal opens directly at locked_rebuy_price — skipping the Failure Modal and the tax-loading step (pricing is already resolved via POST /calculate-cart during the overlay flow).

3. Pre-conditions

• Trader's account Status = 'Terminated'

4. Post-conditions

Payment successful:

• trade_history (the failed live ledger) auto-archived → user_account_history.
• Live sub-account permanently dropped via the execution gateway — broker-specific per UC_4.15.2 BR_4.15.2.7.
• User profile reset back to an evaluation track at the trader's current tier (Level 1, 2, or 5) — Status = 'Active_SIM'.
• POST /provision-sim-user called → brand-new SIM sub-account provisioned with new credentials on the isolated simulation gateway. [CHR-61]
• Fields that remain intact (on going-live again, users can bypass Rippling, Dots and Veriff): identity_status, contract_status, institution_approval_status, payout_status, dots_payee_id, veriff_failed_flag, veriff_attempts.
• setup_status reset to NULL for Futures traders (Rithmic only). [CHR-62]
• Rithmic Futures only: Market Data re-select screen (§10.6) is displayed immediately after payment succeeds — non-dismissible. Trader cannot access the dashboard until selection is submitted. After submission → Success screen "Track Started" (§10.5) → "Return to Dashboard" → Dashboard Day 0.
• All other brokers (MT5, TraderEvolution): Success screen "Track Started" (§10.5) displayed immediately after payment succeeds → "Return to Dashboard" → Frosted Glass removed → Dashboard Day 0 with new SIM credentials.
• User can find new SIM credentials in Dashboard Settings.

Archival lifecycle (if user has not yet purchased):

• From T+0 to archive_date (broker-specific — see UC_4.15.2 BR_4.15.2.7): Dashboard stays frozen at the exact breach metrics (equity, balance, closed trades) — not reset to Day 0. This is the window during which Re-Buy is priced at the discounted/founder rate.
• After archive_date: historical ledger purged from the active dashboard view (data remains in user_account_history); dashboard resets to a blank Day 0 state. Re-Buy after this point is priced at the full/expired rate — see BR_4.15.3.1.
• Re-Buy Exception: if the trader purchases before archive_date passes, the backend's atomic reset immediately wipes the failed state and resets the dashboard to Day 0 for the new SIM challenge — the archival window is short-circuited, not waited out.

5. Basic Flow

Step 0 — Failure Modal displayed:

• After Hard Breach, Dashboard shows the permanent Frosted Glass overlay.
• Failure Modal (§10.1 or §10.2) is rendered on top, showing the CTA "Start Associate Track" and the archive countdown banner (same display logic as UC_4.10.3 §10.1 item 4, computed off archive_date).
• This modal persists on every Dashboard visit until the trader completes a purchase.

Step 1 — User clicks CTA → system loads pricing:

1. Compare NOW against failure_timestamp + Discount_Code_Duration_Days (Table C) → determines whether the pricing window is still open. At the same time, check user.is_founder to determine pricing tier. Ref: BR_4.15.3.1 for pricing routing.
2. Modal transitions to a loading state — spinner + "Calculating regional taxes..." (identical UX to UC_4.10.3 §5.1 Step 1). The frontend calls POST /calculate-cart with the full payload.
3. Final_Charge = Price + tax_amount, where Discounted_Price is resolved per BR_4.15.3.1.
4. Once POST /calculate-cart returns HTTP 200: loading state closes → Re-Buy Modal (§10.3) opens with calculated pricing. The promo code entry point ("Have a promo code?") is available on this modal — Ref: UC_4.10.3 §6 (identical flow).
5. The base price displayed in the Re-Buy Modal is the amount that will be charged — it does not change between modal open and pay click. Tax is recalculated at the moment the user clicks pay and may differ slightly from the estimate shown in the modal. Ref: UC_4.10.3 §6.

Step 2 — User clicks CTA "Start Associate Track ($X)" on Re-Buy Modal → POST /initiate-rebuy:

The endpoint performs the full sequence below in order:

1. Gate 1 — Status validation: Check Status == 'Terminated' on the Live DMA account profile. If not → modal closes immediately, Ref: TE-DASH-01 toast displayed (same pattern as UC_4.10.3 §7 Gate 1).
2. Pricing: resolve Price per BR_4.15.3.1 (Founder → locked_rebuy_price; Standard within window → Challenge_Price × (1 − Retry_Discount); Standard expired → Full Challenge Price).
3. Gate 2 — Sanctions: query billing_country/billing_region from the Users table → check against Compliance_geo_restrictions (with regional exemptions such as Canada/Ukraine evaluated on the region parameter). If a match is found → return HTTP 403 immediately with the restricted Country/Region in the payload → frontend displays Ref: FP-02.
4. Tax Engine: ping Quaderno API with billing_country and Discounted_Price to calculate tax.
5. Math: Final_Charge = Price + Tax.
6. Gate 3 — Execution / UI fallback: check the Users table for customer_vault_id (NMI):
   • Present → Path A (1-Click): execute NMI server-to-server charge for Final_Charge. Same behaviour as UC_4.10.3 §5.1 Path A
   • Not present → Path B (Secure Checkout Fallback): return a payload directing the frontend to the standard Secure Checkout screen, presenting the region-based options matching GET /system/status. Same behaviour as UC_4.10.3 §5.1 Path B.
7. Provisioning (on successful transaction only — execution order is strict per UC_4.15.2 BR_4.15.2.7): [CHR-61]
   • 7a. Data Integrity Sync (Case A only — pre-deletion gate): Verify all final trade data and P&L snapshots for the failed LIVE account are successfully synced to both PostgreSQL and AWS S3 Glacier (immutable system of record, independent of execution platforms). Sub-steps 7b and 7c may not proceed until this sync is confirmed.
   • 7b. Provision new SIM sub-account: Broker-specific per UC_4.15.2 BR_4.15.2.7:
     • Case A (Re-Buy before archive_date — Failsafe not yet fired): Rithmic: revoke Live Pro Market Data → provision brand-new SIM sub-account on Paper Trading Gateway → assign to existing User ID. MT5 / TraderEvolution: provision brand-new SIM sub-account.
     • Case B (Re-Buy after archive_date — Failsafe already fired): Rithmic: re-enable User ID (disabled by Failsafe) → provision brand-new SIM sub-account → assign to existing User ID. MT5 / TraderEvolution: provision brand-new SIM sub-account only.
   • 7c. Delete/unassign old LIVE sub-account (Case A only): Broker-specific per UC_4.15.2 BR_4.15.2.7: Rithmic: set LIVE sub-account status to "unassigned". MT5 / TraderEvolution: hard-delete locked LIVE sub-account.

Path A — 1-Click Purchase (vaulted card present):

Identical to UC_4.10.3 §5.1 Path A

• Rithmic Futures traders: Market Data re-select screen (§10.6) displayed immediately — non-dismissible — before any navigation to dashboard. After submission → Success screen "Track Started" (§10.5).
• All other brokers: Success screen "Track Started" (§10.5) displayed directly.

Path B — Secure Checkout Fallback (no vaulted card):

Identical to UC_4.10.3 §5.2 Path B — REF'd, not duplicated.

Path C — Change Payment Method:

Identical to UC_4.10.3 §5.1 Path C — REF'd, not duplicated.

6. Promo Code Flow

Identical to UC_4.10.3 §6 Promo Code Flow, including the Apply-click product-ID mismatch check added by [CHR-55] — this UC's flow sends product_id="REBUY".

6a. Payment Flow — All Standard Cases

Identical to UC_4.10.3 §6a Payment Flow — All Standard Cases.

7. Exceptional Flow

• [Gate 1 fails — Status no longer 'Failed'/'Terminated' at pay click]

  • Re-Buy Modal closes immediately → Ref: TE-DASH-01 toast displayed.

• [Gate 2 fails — Sanctions]

  • Compliance_geo_restrictions match → HTTP 403 → Ref: FP-02 displayed.

• [Payment fails — Secure Checkout Path B/C]

  Identical to UC_4.10.3 §7 Exceptional Flow — Secure Checkout Path B/C table.

• [SIM provisioning failure — after payment already succeeded]

  • Applies to §5 Step 2 sub-step 7, where POST /provision-sim-user is called after the charge has already cleared. Handled with the same classify → retry → escalate pattern, Freshdesk ticket, SES-23 email, and Success Screen replacement described in UC_4.10.3 §7 Exceptional Flow — SIM provisioning failure

8. Business Rules

BR_4.15.3.1: Re-Buy Pricing — Founder vs. Standard (No Window Split for Founder)

LIVE Re-Buy pricing has three routes. The pricing window is determined solely by Discount_Code_Duration_Days (Table C): failure_timestamp + Discount_Code_Duration_Days.

• CTA label is always "Start Associate Track" regardless of route — LIVE has no separate "Reset" CTA text, since there is no reuse-sub-account path.

BR_4.15.3.2: Re-Buy Always Provisions a New Sub-Account [CHR-61]

• POST /initiate-rebuy always provisions a new sub-account via POST /provision-sim-user.
• Execution order within provisioning is strict: (1) Sync PostgreSQL + S3 Glacier → (2) Provision new SIM sub-account → (3) Delete/unassign old LIVE sub-account (broker-specific).
• Rithmic Server Separation & Gateway Transition Rule: A Re-Buy moves a trader from Live back to Simulation. Rithmic separated environments are: (1) Paper Trading Server (SIM), and (2) Live Trading Server (Ironbeam). The existing Rithmic User ID is preserved throughout — only the sub-account changes. The system does not just unassign the live sub-account and create a new one on the same server. The backend must provision the new sub-account on the Rithmic Paper Trading Gateway.

BR_4.15.3.3: Futures Market Data Re-Select — Forward Dependency

• For Futures traders, setup_status resets to NULL on Re-Buy — the trader must re-select Market Data packages and pay any applicable add-on fee before a later POST /provision-live-user call, once they pass the new SIM challenge and re-enter Live promotion.
• This step exists outside this UC's scope — REF UC_5.6 (Flow 3F — Market Data Setup, live phase) for the full flow.

BR_4.15.3.4: Archival / Day 0 Lifecycle

• Breach freezes the Dashboard at the exact breach metrics (equity, balance, closed trades) — no immediate reset to Day 0.
• archive_date = broker-specific per UC_4.15.2 BR_4.15.2.7
• Only when archive_date passes does the frontend reset to a blank Day 0 state, purging the historical ledger from the active UI view (data remains in user_account_history).
• Re-Buy Exception: a successful Re-Buy before archive_date immediately triggers the atomic reset to Day 0 for the new SIM challenge, regardless of how much of the window remains.

9. Wireframe / UI

9.1 Overall Flow — Popup Sequence

[Entry Point 1: Dashboard]              [Entry Point 2: Account Actions]      [Entry Point 3: Founding Mentor]
        |                                        |                                       |
        v                                        |                                       |
[1. Failure Modal]                               |                                       |
   <- persists on every                          |                                       |
      Dashboard visit until purchase             |                                       |
        |                                         |                                       |
        | CTA "Start Associate Track"            | "Re-Buy" button                      | Overlay acknowledged
        |                                         | (Failure Modal bypassed)              | (pricing already resolved)
        v                                         v                                       v
        `----------------->  [Loading: "Calculating regional taxes..."]  <----------------'
                               POST /calculate-cart -> price calculated
                                            |
                                            v
                              [2. Re-Buy Modal]  <- single variant (no Reset/Start-New split like SIM)
                                 |- vaulted card present  -> 1-Click                [§10.4]
                                 `- no vaulted card       -> Secure Checkout        [UC_4.10.3 §10.4]
                                            |
                                            | User clicks CTA (Pay) -> POST /initiate-rebuy
                                            v
                              [3. Processing Payment popup]  <- 1-Click path only
                                            |
                                       |- Success (Rithmic Futures) -> [§10.6 Market Data re-select screen] -> Submit -> [§10.5 Success screen "Track Started"] -> "Return to Dashboard" -> Dashboard Day 0
                                       |- Success (all other brokers) -> [§10.5 Success screen "Track Started"] -> "Return to Dashboard" -> Dashboard Day 0 (new SIM)
                                       `- Failure -> Back to modal (2) with inline banner error

9.2 Failure Modal — Wireframe Variants

Wireframe source: References/Wireframe/Stage 2.2/Failure and recovery/

All variants share:

• Countdown banner: "Data will be archived in X days" (dynamic)
• CTA button: "Start Associate Track"

Variant B (Level 1-8 with severance) additionally inserts a Severance notice box (amber-toned highlighted text) between the body copy and the countdown banner.

Variant E (Level 9-24, defense exhausted, with severance) additionally inserts a Next Steps box between the body copy and the countdown banner.

9.3 Re-Buy Modal

Single modal variant (no Reset/Start-New-Track split like SIM). Varies only on vaulted card presence: 1-Click (§10.4) or Secure Checkout fallback (UC_4.10.3 §10.4).

10. Screen Description and Business Rules

10.1 Failure Modal — Variant A: Level 1-8 (No Severance)

Wireframe: Level 1 - 8_ Failure modal, no severance, no defense.png

10.2 Failure Modal — Variant B: Level 1-8 (With Severance Notice)

Wireframe: Level 1 - 8_Failure modal with Severance notice. No defense.png

Extends Variant A (§10.1) with one additional element (#3 below); elements #1, #2, #4, #5 are identical to §10.1:

10.3 Failure Modal — Variant D: Level 9-24 (Defense Exhausted, No Severance)

Wireframe: Level 9 - 24 Failure modal with no severance, no defense.png

10.4 Failure Modal — Variant E: Level 9-24 (Defense Exhausted, With Severance)

Wireframe: Level 9 - 24_ Failure modal with Severance notice. Defense exhausted.png

Scope note: Applies only when defense_used == TRUE AND Severance_Pay > 0 — trader previously activated the Defense Protocol (UC_4.15.4) and has now breached again with a severance entitlement. For the defense-exhausted + no severance case, see §10.3.

10.5 Re-Buy Modal (1-Click)

Wireframe: References/Wireframe/Stage 2/Failure and Recovery/Start a new track modal (1).png (default + error state), Start a new track modal + Promo code.png (promo applied state).

10.6 Success Screen ("Track Started")

Wireframe: Payment succeed - Start a new track.png

Display order: For Rithmic Futures traders, this screen appears after the Market Data re-select screen (§10.6) is submitted — not immediately after payment. For all other brokers, it appears immediately after payment succeeds.

10.7 Market Data Re-Select Screen (Rithmic Futures Re-Buy only)

Wireframe: References/Wireframe/Stage 2.2/Failure and recovery/Rebuy -_ User must choose market data again for Non-pro feed.png Ref: UC_4.15.2 BR_4.15.2.8 — feed pricing logic, reuse rules, cap enforcement.

Condition: Displayed immediately after Re-Buy payment succeeds, for Rithmic Futures traders only. Non-dismissible — re-displays on every page reload or re-login until the trader submits. Trader cannot access the dashboard before completing this step.

Changelog