UC_4.17.1: Settings — Market Data Management (LIVE)

---

Document References

---

1. Overview

Wireframe: References/Wireframe/Stage 2/Settings/Market Data Management/[BA Wireframe] Stack Trading Design/Account (Market Data Management).png and the other frames in the same folder.

2. Trigger

• Trader: opens Settings → clicks the Market Data Management tab.
• Trader: clicks the CTA in a Flow 22 dashboard notification or email — both land on this tab (Ref: BR_4.17.1.20).
• Trader logs in while the Rithmic exchange agreement is still unsigned → the Action Required: Exchange Agreements Pending modal opens by itself on the Command tab (Ref: §6.11).
• System — Flow 12: daily cron at 02:00 AM Central scans for traders who have not traded in 30 days (Ref: §6.9).
• System — Flow 22: monthly cron at EOM−7 (Path A) or EOM−3 (Path B), plus the End of Month Hard Check on the last day of the month (Ref: §6.10).

3. Pre-conditions

• The trader is logged in and is in the LIVE environment (Ref: BR_4.17.1.1).
• The trader's asset class is Futures. Forex traders do not get this tab — their feeds come from MT5 / TraderEvolution, which carry no separate exchange data fee.
• users.status is not Terminated (hard breach or resignation) — Ref: BR_4.17.1.1.
• Table C holds all four price variables. Without them GET /market-data-products cannot return a price and the Subscribe modal cannot open (Ref: BR_4.17.1.2).

4. Post-conditions

• The trader sees the true state of all four feeds, reconciled between the database and Rithmic.
• After a successful Subscribe: the new feed is added to market_data_flags, market_data_paid_until is set to the last day of the current calendar month, and the feed is provisioned on Rithmic.
• After an Unsubscribe: the feed stays active until market_data_paid_until, then switches off and drops out of Flow 22's next invoice run.
• After a payment-method change: is_default moves to the new card and every later Flow 22 charge uses it.

5. Basic Flow — Viewing the data feed list

1. The trader opens Settings → clicks the Market Data Management tab.
2. The frontend calls three endpoints in parallel:
   • GET /market-data-status → [{feed_name, status, paid_until_date}] — entitlement state held in the database.
   • GET /check-market-data-status → {db_entitlements, rithmic_status: {CME, CBOT, NYMEX, COMEX}} — signature status read live from the Rithmic API. The frontend must never infer signature status from the database (Ref: BR_4.17.1.14).
   • GET /market-data-products → the price of each feed, read from Table C.
3. The frontend calls Get Saved Cards to list saved cards and identify the is_default one, and reads customer_vault_id to decide whether the trader is on Path A or Path B (Ref: BR_4.17.1.10).
4. The frontend renders:
   • The billing bar at the top of the panel — Path B shows All feeds billed to [brand] Ending in [last4]; Path A shows All feeds billed to Alternative Payment Method. Both carry a Change link.
   • Four feed cards in a fixed order: CME Level 2 → CBOT → NYMEX → COMEX.
   • Each card: feed name + status badge + info chip (if any) + description line + action button. Full matrices in BR_4.17.1.3, BR_4.17.1.4, BR_4.17.1.5.
5. If the trader has not signed the exchange agreement, the Command tab shows the reminder banner (Ref: BR_4.17.1.15).

6. Alternative Flow

6.1 Subscribe — buying a new feed

1. The trader clicks Subscribe on a feed they do not own yet.
2. The Subscribe to Market Data modal opens. There is no signature gate at this step — a trader who has not signed the exchange agreement can still buy and pay; they simply will not see data flowing until they sign (Ref: BR_4.17.1.14). The modal shows: the product line ([FEED] + sub-text Full depth-of-book + price), a Tax ([state]) line, a Total line, the payment selector, and the disclosure block (Ref: §9.2).
3. The trader picks one of two payment mechanisms. Each has its own CTA — they are never merged into one generic button (Ref: BR_4.17.1.24):
   • Charged Automatically — use a saved card. This is auto-pull: the system charges the vault token on schedule. CTA: Subscribe via Credit Card. If no card is saved, the radio also reads (No payment card yet) and offers an Add New link.
   • Alternative Payment Method — pick one APM tile (Pix / UPI / Bank Transfer…). This is manual push: the trader pays each time themselves. CTA: Pay via APM. The tile list is rendered dynamically from GET /system/status based on the trader's country (Ref: BR_4.17.1.13).
4. The trader clicks the CTA → the frontend calls POST /execute-checkout with {product_id: "MARKET_DATA", addon_ids: [feed_id], payment_method, user_id}.
5. The backend charges through NMI (card path) or redirects to the APM gateway (APM path).
6. On success the Process Payment Webhook writes, in one transaction: the new feed into market_data_flags, market_data_paid_until = last day of the current calendar month, and market_data_billable according to level (Ref: BR_4.17.1.6, BR_4.17.1.7). The middleware then calls the Rithmic API to provision the feed.
7. The frontend shows the Subscription Confirmed modal (Ref: §9.5). Clicking Back to Market Data returns to the tab, where the card is now Active with an Unsubscribe button.

6.2 Unsubscribe — cancelling an active feed

1. The trader clicks Unsubscribe on an Active feed card. This button never appears on the CME card (Ref: BR_4.17.1.5).
2. A confirmation modal Unsubscribe from [FEED]? opens, stating that the feed keeps running until the end of the calendar month already paid for, that no refund is issued, and the earliest date they can subscribe again.
3. The trader clicks Unsubscribe → the frontend calls Cancel Subscription {user_id, product_id}.
4. The backend looks up the gateway behind that subscription:
   • NMI → tell NMI to terminate the recurring billing profile.
   • APM → set an internal flag that blocks any automatic renewal.
   • Either way → work out the end of the paid cycle, leave the feed active at the broker until that date, and return access_valid_until.
5. The frontend shows Subscription Cancelled. The card then switches to an Active until [MMM DD] badge with the Subscribe button disabled until the cycle ends (Ref: BR_4.17.1.8).
6. Flow 22 drops this feed from its next invoice run.

6.3 Resubscribe — a feed paused by Flow 12

Applies when a feed is Inactive with the info chip Paused after 30 days without trading, i.e. status = Inactive_Hold set by Flow 12.

Flow 12 only pauses the data feed after 30 days without trading; it does not cancel the subscription. But data is billed by calendar month (BR_4.17.1.7), so whether the trader pays anything to switch it back on depends on which month they are in when they do it.

Case 1 — Switching back on inside the month already paid for (no charge)

Condition: market_data_paid_until >= TODAY — the paid cycle is still valid.

Why this is free. CME charges a flat fee per User ID, per calendar month. Turning the same User ID off and back on within one month costs nothing extra — the firm can toggle as often as it likes without exceeding that month's cap. That is exactly why Case 1 needs no checkout (Source: QnA_STAGE2_FAILURE_AND_RECOVERY.md FR-62).

1. The trader clicks Resubscribe.
2. The frontend calls POST /toggle-market-data {user_id, enable_data: true}.
3. The middleware calls the Rithmic API to switch the feed back on. No checkout modal, no charge.
4. A Success toast appears, the card returns to Active, and the Paused after 30 days without trading chip disappears.

Case 2 — Switching back on in a new month (payment required)

Condition: market_data_paid_until < TODAY — the paid cycle has expired and a new calendar month has started.

1. The trader clicks Resubscribe.
2. The frontend opens the Subscribe to Market Data modal — the new cycle has not been paid for.
3. The rest follows §6.1.

Exception — CME for Level 3+ traders

A trader at Level 3 or above switching CME back on always follows Case 1 (free, no checkout) whatever the month, because the firm pays for base CME and the trader never paid for it in the first place (Ref: BR_4.17.1.6).

This exception does not cover:

• Level 1–2 traders — they pay for CME themselves, so Case 1 / Case 2 applies normally.
• The CBOT / NYMEX / COMEX add-ons at any level.

Exchange agreement

Switching a feed back on after Flow 12 does not require signing again — Rithmic ties signatures to the User ID, and Flow 12 never hard-deletes the User ID.

6.4 Resubscribe — a feed switched off after a failed payment

Applies when a feed is Inactive with the info chip Suspended on [MMM DD, YYYY] – Payment couldn't be completed, i.e. the feed was downgraded by Flow 22's End of Month Hard Check.

1. The trader clicks Resubscribe.
2. The frontend opens the Subscribe to Market Data modal — the new cycle is unpaid.
3. The rest follows §6.1.
4. If a broken card caused the failure, the trader should change it first through the Change link on the billing bar or the Change link inside the modal.

6.4a Where Flow 12 and Flow 22 meet — edge cases

The two background jobs run independently but act on the same feed, so a few situations are easy to get wrong:

6.5 Changing the payment method

1. The trader clicks the Change link on the tab's billing bar.
2. The Change Payment Method modal opens (Ref: §9.3) — methods listed on the left, details of the selected one on the right.
3. The trader picks a different card under Charged Automatically → the right column shows that card's details (brand, last four digits, expiry, billing address, Delete button).
4. The trader clicks Done → the frontend calls Update Subscription Payment {user_id, subscription_id, new_billing_id} for every active market data subscription and sets the new card as is_default.
5. The billing bar on the tab updates to the new card.

Changing the payment method is an account-wide action that applies to every feed at once — there is no per-feed payment method (Ref: BR_4.17.1.9).

6.6 Adding a new card

1. Inside Change Payment Method, the trader clicks Add new payment method.
2. The right column becomes the add-card form: the wallet button (Apple Pay or Google Pay depending on device — Ref: BR_4.17.1.12), an or divider, then Name on card / Card number / Expiration (MM/YY) / CVC plus the Billing address is the same as the address checkbox.
3. The trader fills it in and clicks Add Payment Method → the frontend tokenizes the card and calls Add Saved Card {user_id, payment_token}.
4. NMI stores the card against the trader's customer_vault_id and returns {billing_id, brand, last4, exp_month, exp_year}.
5. A Payment method added successfully toast appears; the new card shows up in the left list and is pre-selected.
6. The trader clicks Done to apply the new card to their subscriptions (step 4 of §6.5).

6.7 Deleting a card

1. The trader selects a card on the left → clicks Delete on the right.
2. If that card funds at least one market data subscription → the deletion is blocked and the Card In Use modal lists the subscriptions using it (Ref: §9.5, BR_4.17.1.19). The trader can pick Change Payment Method to assign a different card first, or Close.
3. If the card funds nothing → call Delete Saved Card {user_id, billing_id}; NMI deletes the token permanently and the card disappears from the list.

6.8 Switching from card to Alternative Payment Method

1. Inside Change Payment Method, the trader selects the Alternative Payment Method radio under You Pay Each Month.
2. The right column switches to the How It Works block (3 steps) — Ref: §9.3.
3. The trader clicks Done → the Switch to Manual Billing? warning modal opens, spelling out that they must actively pay the invoice before the end of each month or lose their feeds.
4. The trader clicks Confirm Switch → the system moves them to Path A: the NMI recurring profile is cancelled and the trader is flagged to receive a manual invoice from Flow 22 at EOM−7.
5. The billing bar changes to All feeds billed to Alternative Payment Method. The Remaining Extension Period chip and Extend ([n] Feeds) button only appear once the last 7 days of the month begin (Ref: §9.1 row 3).
6. Clicking Keep Automatic closes the modal and keeps the card.

6.9 Flow 12 — The "Zombie" Protocol (background job)

Purpose: stop paying for data feeds on dormant accounts. This is purely a cost-control tool, not an account-termination flow.

1. Trigger: daily cron at 02:00 AM Central.
2. Scan: SELECT * FROM traders WHERE last_trade_date < (Today − 30).
   • The counter uses the raw last_trade_date and does not subtract approved time off. A trader on Flow 13 DTO / hiatus is still caught by Flow 12 (Ref: BR_4.17.1.21).
3. Batch Push: the database sends a webhook with the list of inactive traders to Zapier.
4. Action: call the Rithmic / MT5 / TraderEvolution API to Disable Market Data — this switches off all of that trader's feeds, base CME included.
5. Pod Impact: if the trader belongs to a Pod → decrement the Pod Leader's Current_Count (freeing the slot) and set the trader's Pod Status to Inactive_Hold.
6. Notify: send the Zombie_Account_Pause email — it explains that data is paused, lists what is untouched (credentials, evaluation status, layouts, journals, trade history), notes that the Pod seat went back to the waitlist, and carries a reactivation CTA. Full copy: Ref: SES-30.
7. Reactivation: the trader clicks the reactivation_url in the email or the Resubscribe button on the tab → runs §6.3.

What gets switched off versus what gets switched back on. Flow 12 switches every feed off in one go, but the UI puts a Resubscribe button on each card:

• After Flow 12 runs, every feed the trader owns becomes Inactive with the Paused after 30 days without trading chip, each with its own Resubscribe button.
• On the tab the trader reactivates one feed at a time — switching NYMEX on does not switch CBOT on.
• The reactivation_url in the email is the exception: it is a bulk action that switches on every feed eligible for Case 1 at once, then drops the trader on the Market Data Management tab. Feeds that fall under Case 2 (new month, payment required) are not switched on and keep their Resubscribe button so the trader can check out (Ref: §6.3).

Loop protection — required. The cron scans last_trade_date < (Today − 30). A trader who reactivates a feed but does not trade leaves last_trade_date unchanged, so the next day's cron switches the feed off again, and again, until they place an order. To prevent that, Flow 12 must skip traders who have just reactivated but not yet traded:

• Record the reactivation timestamp (for example market_data_reactivated_at) during POST /toggle-market-data.
• Extra scan condition: only switch off when last_trade_date < (Today − 30) AND (market_data_reactivated_at IS NULL OR last_trade_date > market_data_reactivated_at).
• In plain terms: once a trader reactivates, leave them alone until they actually place an order; the 30-day counter restarts from that order.
• Without this rule, a trader returning from a long break loses their feed again the next morning with no idea why.

What Flow 12 does NOT do (Ref: BR_4.17.1.22):

• It does not delete trade history, performance ledgers or account balances.
• It does not touch positions or working orders — the Risk Engine is what flattens positions that breach overnight margin, and working orders are cancelled by the exchange itself. In practice a trader cannot sit idle for 30 days and still hold an open position.
• It does not hard-delete the Rithmic User ID, so exchange-agreement signatures stay valid.
• It does not reset virtual_equity and does not create a new account. Reactivating means resuming with the same balance and history.

6.10 Flow 22 — Monthly Data Fee Billing (background job)

The Flow 22 cron reads each trader's customer_vault_id to decide which schedule and action applies.

Path A — Manual APM Workflow (customer_vault_id IS NULL)

Path B — Automated NMI Workflow (customer_vault_id IS NOT NULL)

Day 0 sweep (Path B / NMI only, last day of the month)

For traders who bought an add-on after the EOM−3 cron had already run. Their purchase payment only covers the current month, so a final sweep is needed to collect for the next one.

• This group gets no 3-day warning. They bought after the EOM−3 cron ran, so they were never in that batch — no Urgent_Data_Payment_Required email and no WARN dashboard notification at EOM−3. Their first contact is the outcome of the Day 0 charge itself.
• The number of charge attempts differs between the two groups (Ref: BR_4.17.1.23):

• 🔴 Ordering constraint the backend must respect: the End of Month Hard Check queries the database for Last_Data_Payment_Status == Failed; it does not receive a list from the sweep. So the Day 0 sweep must finish writing Last_Data_Payment_Status for every trader in the batch before the Hard Check runs. If that flag is written asynchronously (waiting on the NMI webhook) after the Hard Check has already scanned, a failed trader slips through — their feed stays on for the whole next month unpaid, while Stack Trading is still billed by CME for them.
• Worked example: a trader buys NYMEX on Aug 29. That payment only covers August (market_data_paid_until = Aug 31). The EOM−3 cron ran on Aug 28, before the purchase, so they were not in it. The Day 0 sweep on Aug 31 catches them because market_data_paid_until == TODAY and charges for September. If that charge fails, the End of Month Hard Check runs straight afterwards the same day and switches the feed off, with no grace period.

End of Month Hard Check (both paths, last day of the month)

Runs after the Day 0 sweep on the same day, so it also catches traders who just failed in that sweep.

1. Query traders with Market_Data_Billable == True AND Last_Data_Payment_Status == Failed.
2. Call the Broker API (Rithmic) to downgrade the feeds. How much is switched off depends on level (Ref: BR_4.17.1.6):
   • LIVE Level 1–2: switch off every feed, base CME included.
   • LIVE Level 3+: switch off the add-ons only (NYMEX / CBOT / COMEX); base CME keeps running because the firm pays for it.
3. Set Market_Data_Billable = False.
4. Send the Data_Feed_Downgraded email through AWS SES (Ref: SES-17) plus a CRITICAL dashboard notification.
5. No grace period. Feeds go off at the moment of the hard check.
6. On the tab, the downgraded feeds switch to the Inactive badge with the Suspended on [MMM DD, YYYY] – Payment couldn't be completed chip and a Resubscribe button (§6.4).

6.11 Exchange-agreement reminder modal (R|Trader Pro)

Rithmic locks the price feed at the exchange gateway until the trader logs into the R|Trader Pro desktop terminal and digitally signs the CME exchange agreements. This is a mandatory administrative step that happens outside the web app — the system can only remind and resend instructions; it cannot sign on the trader's behalf.

1. The trader logs into the dashboard.
2. The frontend calls GET /check-market-data-status once and reads the signature status.
3. If the trader has not signed with Rithmic, the Action Required: Exchange Agreements Pending modal opens immediately on the Command tab (Ref: §9.6).
4. The trader has two options:
   • Resend Instructions → POST /resend-rtrader-instructions {user_id} → triggers Zapier Flow 39, which emails step-by-step instructions for logging into R|Trader Pro and signing the CME, COMEX, CBOT and NYMEX agreements.
   • Cancel → closes the modal. The trader carries on using the dashboard normally — navigating any tab, buying other packages and checking out add-ons are all unaffected (Ref: BR_4.17.1.14).
5. While the agreement is unsigned, the modal reopens at every subsequent login.
6. Once the trader signs in R|Trader Pro, the next login's GET /check-market-data-status reports it as signed → the modal stops appearing and the reminder banner disappears (Ref: BR_4.17.1.15).

This modal does NOT block add-on purchases. An unsigned trader can still subscribe and pay — Rithmic gates at the data-stream layer, so the only consequence is that no data flows until they sign. Ref: BR_4.17.1.14.

7. Exceptional Flow

8. Business Rules

BR_4.17.1.1: When the tab is visible

• The Market Data Management tab is shown to LIVE traders only. Traders still in the SIM phase do not see it (Ref: BR_4.6.2.1).
• The tab is hidden entirely from the Account tab list in either of these states:
  • Hard breach — users.status = 'Terminated' after a Level Stop (Ref: UC_4.15.2).
  • Resignation — users.status = 'Terminated' after the trader resigns (Ref: UC_4.17.2).
• Hidden, not disabled — the tab is absent from the list and cannot be reached by deep link. In both states gateway access is already revoked and data fees have stopped, so there is nothing left to manage.

BR_4.17.1.2: Feed list, order and price source

• The panel always renders all four feeds in a fixed order, whatever the trader owns: CME Level 2 → CBOT → NYMEX → COMEX.
• The CME Level 2 card carries a Popular ribbon. The other three do not.
• Package sub-text: Full depth-of-book. This string appears only on the product line inside the Subscribe modal, never on the feed cards on the tab.
  • It is one shared string across all four feeds — not written per feed, and it does not change with status.
  • It is kept on every feed even though the wording is identical, so that it can later distinguish these packages from a future "Level 1" quotes product, which would not include full depth-of-book.
  • The frontend owns this string; it does not need to become a field on GET /market-data-products yet.
• Asset-class description line — a different string per feed, shown on the feed cards on the tab. Each card carries only this line, without the package sub-text:

• Prices come from Table C through GET /market-data-products. Hardcoding prices is forbidden on both backend and frontend. The four variables Price_Data_CME, Price_Data_CBOT, Price_Data_NYMEX and Price_Data_COMEX are all 137.50 per month today. The figures in the wireframe are dummy data and must not be used.
• GET /market-data-products automatically filters out products the trader already owns.

BR_4.17.1.3: Status badge matrix

Badges apply to any feed — none of them is tied to a specific one. The legend in the top right of the panel explains the three groups: Active · Inactive · Expiring.

BR_4.17.1.4: Info chip matrix

The info chip sits right after the status badge and explains why the feed is in that state. Apart from the first one, every chip applies to any feed.

• Two chips can appear on the same card at the same time. The typical case: a Level 3+ trader who has been idle for 30 days sees the CME card carrying both Covered by Stack Trading · No charge to you and Paused after 30 days without trading.
• When both show, the who-pays chip (Covered by Stack Trading…) comes first and the status-reason chip (Paused… / Suspended…) second.

BR_4.17.1.5: Action button matrix

Each card carries exactly one button. Three action labels: Subscribe · Unsubscribe · Resubscribe. A fourth, Subscribed, is a status label rather than an action and appears only on an active CME card.

• Subscribed is always disabled and never clickable. CME is the mandatory base feed for every futures trader, so there is no cancel action for it.
• CME can still show Resubscribe when its feed has been switched off — either because Flow 12 switched everything off, or because a Level 1–2 trader did not pay and the Hard Check took CME down too.
• Resubscribe does not always mean a charge. Whether payment is required is decided by market_data_paid_until, not by the label. Full two-case matrix plus the Level 3+ CME exception: Ref: §6.3.

BR_4.17.1.6: Who pays — split by level

• Display consequence: the Covered by Stack Trading · No charge to you chip only appears from Level 3 up (Ref: BR_4.17.1.4).
• Downgrade consequence: a Level 1–2 non-payer loses every feed including CME; a Level 3+ non-payer loses only the add-ons (Ref: §6.10).
• Level 3 reimbursement perk: on reaching Level 3, GET /financial/calculate-data-refund totals every MARKET_DATA_BASE charge the trader paid at Levels 1–2 and refunds it in full. Add-ons (MARKET_DATA_ADDON) are not refunded.
• The invoices table records both line types: fee_type = 'MARKET_DATA_BASE' (Levels 1–2) and fee_type = 'MARKET_DATA_ADDON' (any level). Both appear on the Billing tab (Ref: UC_4.6.3).

BR_4.17.1.7: Billing cycle — calendar month, prepaid, never prorated

• CME bills by calendar month: the 1st through the last day. It is not a 30-day cycle starting from the subscription date.
• Whatever day of the month the trader subscribes, they pay 100% of that month's fee. There is no daily proration and no partial refund.
• After a successful payment the database is written as: market_data_paid_until = LAST DAY OF THE CURRENT CALENDAR MONTH
• Stack Trading pays CME directly, so the trader must be charged before CME's billing period starts (prepay). A card failure at prepay time means the feed is not provisioned.
• In the first month the trader is charged twice, and this is deliberate. Example: subscribing on Aug 13, 2026 → first charge on Aug 13 (opening the feed for the rest of August), second charge a few days before Sep 1 (prepaying September). The Subscribe modal must say so plainly (Ref: §9.2 row 6).
• A trader who does not want the double charge has two options: wait until the 1st to buy, or skip add-ons altogether.

BR_4.17.1.8: Mid-cycle unsubscribe — a soft cancel

• Cancelling does not switch the feed off straight away. It runs until the last day of the last calendar month paid for, which is the access_valid_until returned by Cancel Subscription.
• During that window the card shows the Active until [MMM DD] badge, and the Subscribe / Resubscribe button must be disabled to prevent a duplicate charge at the gateway.
• The current month is never refunded, in any circumstance.
• After access_valid_until the feed is switched off at the broker and dropped from Flow 22's next invoice run. The card returns to the not-subscribed state (no badge, Subscribe enabled).

BR_4.17.1.9: One payment method for every feed

• Aggregated invoicing: Flow 22 produces a single Invoice_Amount per trader covering every feed. Feeds are never charged separately.
• Single default vault token: the combined invoice is charged to the token flagged is_default in the NMI Customer Vault.
• All-or-nothing: the combined charge succeeds or fails as one block. There is no state where one feed survives and another is switched off for payment reasons.
• The UI must never imply per-feed payment control — no Change link or button on individual cards. There is exactly one shared billing bar at the top of the panel.
• Flow 12 is not an unsubscribe. It only toggles the feed off at the broker; the subscription remains and Flow 22 keeps charging for the next cycle. Whether reactivation costs money is decided by market_data_paid_until (Ref: §6.3).

BR_4.17.1.10: Path A and Path B — one flag decides

• Whether a trader has a card on file is determined solely by users.customer_vault_id:
  • Checking out with Credit Card / Apple Pay / Google Pay → the middleware charges through NMI and creates a customer_vault_id → Path B.
  • Paying with an APM (T365, Dusupay, PayRetailers…) → no vault is created → customer_vault_id IS NULL → Path A.
• The vault id is created at the very first checkout (Checkout Step 6), not when an add-on is bought. Path A traders are identifiable from day one.
• Why APMs cannot be auto-charged: Pix / UPI / Mobile Money style APMs are push payments — the user must authenticate and authorise every single transaction on their own device. This is a structural limit of that rail, and no aggregator can work around it.
• Path A ⇒ the EOM−7 schedule with a manual invoice the trader pushes themselves. No Day 0 sweep.
• Path B ⇒ the EOM−3 schedule with an automatic vault charge, plus the Day 0 sweep on the last day of the month for traders who bought late. Day 0 applies to NMI only. Ref: §6.10.
• Moving from Path A to Path B: a Path A trader who later pays by card creates a customer_vault_id, but they only move to Path B from the next cycle, never mid-cycle — this avoids a double charge (already prepaid at EOM−7, then auto-charged again at EOM−3). The billing bar and the Change Payment Method modal must nevertheless show the new method immediately, so the trader knows the next charge will go through the card.

BR_4.17.1.11: Card expiry and warning badges

Every saved card row must show its expiry date and a status badge. Three states:

Formula:

• Card_Expiry_Date = the last day of the MM/YY month printed on the card, at 23:59. A card printed 09/28 is valid until 23:59 on Sep 30, 2028.
• Anchor on the end of the month, not the 1st of the printed month. Getting this wrong warns up to 30 days early and marks still-valid cards as expired.
• 60 days is used because data is billed by calendar month, so 60 days is roughly two billing cycles of warning before a hard failure.

The badge warns; it does not block. The trader can still select an Expired card as the funding source and can still leave it as is_default — the system does not swap cards on their behalf. The consequence is that Flow 22 fails at the next charge, and if nothing is collected by the End of Month Hard Check the feed is switched off (§6.10). Moving to a valid card is the trader's own responsibility — the Expires soon / Expired badges exist precisely to prompt that before it is too late.

BR_4.17.1.12: Apple Pay / Google Pay shown by device

• Apple Pay and Google Pay are never shown together. Render exactly one wallet button, chosen by the device in use:
  • Apple devices (iPhone, iPad, Mac) or the Safari browser → only Apple Pay.
  • Everything else (Android, Windows, Chrome…) → only Google Pay.
• Once a wallet is added, its row in the list shows the static label Apple Pay / Google Pay whenever the wallet API returns no underlying card details. It must never be blank and must never show an error.

BR_4.17.1.13: Payment methods rendered dynamically from GET /system/status

• Prices come from GET /market-data-products. Payment methods come from GET /system/status. Two endpoints, two purposes — both must be called.
• GET /system/status is the localization engine: it reads the Cloudflare IP header to infer the trader's country, looks up the Payment_Method_Config table to see which gateways are active there (NMI, T365, PayRetailers, Dusupay…), and returns an array of {label, explanatory_text, cta_text, icon_tags}.
• The frontend must not hardcode the payment method list, labels, icons or explanatory copy — every button is drawn from this payload.
• Country is inferred from the Cloudflare IP header, not from the billing address the trader typed in.
• This tab reuses the Checkout payment-method component rather than building its own.

BR_4.17.1.14: Exchange-agreement reminder modal (R|Trader Pro)

• The trader signs once with Rithmic for all exchange agreements — not four separate signatures for four feeds.
• The only source of truth for signature status is GET /check-market-data-status, where the middleware pings the Rithmic API in real time. The frontend must not infer it from the database or from GET /market-data-status.
• That endpoint is called once, at login — no polling. The trader can dismiss the modal and keep using the dashboard, so calling again mid-session would change nothing.

No purchase block. An unsigned trader can still subscribe to and pay for any add-on. Rithmic gates at the data-stream layer — it releases no market data to the terminal until the trader signs on their side. So the trader can buy and pay; they simply see no data flowing. GET /check-market-data-status therefore acts as the condition for showing the reminder, not as a purchase gate.

Trigger: on login. The Action Required: Exchange Agreements Pending modal opens as soon as the trader logs in, on the dashboard's Command tab. While unsigned, it reopens at every later session. It stops once the trader has signed with Rithmic.

Modal content:

• Header: Action Required: Exchange Agreements Pending
• Body: You must log into the R|Trader Pro desktop terminal to digitally sign your CME exchange agreements. Your data feeds cannot activate until this step is complete.
• Two controls: a Cancel button (closes the modal) and a Resend Instructions button → POST /resend-rtrader-instructions {user_id} → triggers Flow 39.

The modal is dismissible. After closing it the trader can still navigate to every dashboard tab and can still check out other packages. No freeze, no lock-out, no overlay blocking navigation.

After signing: switching feeds back on after Flow 12 needs no new signature — Rithmic ties signatures to the User ID, and Flow 12 never hard-deletes it.

BR_4.17.1.15: Exchange-agreement reminder banner

• Rithmic locks the price feed at the exchange gateway until the trader logs into R|Trader Pro and signs the mandatory digital agreements. The web application does not track that signing process in real time.
• When GET /check-market-data-status reports the trader as unsigned, the dashboard shows a reminder banner on the Command tab telling them to log into R|Trader Pro and sign.
• The banner appears every time the trader logs in, under the same condition as the modal in §9.6.
• It disappears on its own once the backend confirms the agreement is signed.
• Ref: CR-20260727-005. The banner belongs to this tab, not to Connections & Credentials (Ref: UC_4.6.1).

BR_4.17.1.16: No promo codes

The Subscribe modal has no promo code field. Market data add-ons carry no discounts.

BR_4.17.1.17: Refund policy

Two things that sound alike but are not:

• Mechanism — owned elsewhere. Flow 7 (fail / resign) runs its Refund Check (Market Data) step. This UC does not own that step and does not restate it: the full logic — including the branch for gateways that cannot reverse a payment automatically — is specified in UC_4.15.2 §5 Basic Flow, Step 2.
• Risk window: 3 days on Path B (charged at EOM−3); 7 days on Path A (invoiced at EOM−7).
• Premium add-ons (MARKET_DATA_ADDON) are outside the Level 3 reimbursement of BR_4.17.1.6 — only MARKET_DATA_BASE is reimbursed.

BR_4.17.1.18: Date display format

• Every date shown to the trader on this screen uses the US format — Month Day, Year:
  • With the year: MMM DD, YYYY — e.g. Mar 31, 2026.
  • Without the year: MMM DD — e.g. Active until Mar 31.
• This governs the display layer only. Data sent over the API and stored in the database still follows ISO 8601 UTC — Ref: CR-08.

BR_4.17.1.19: Blocking deletion of a card that funds a subscription

• A card that funds any active market data subscription cannot be deleted.
• The blocking Card In Use modal lists each subscription that card funds, one per line.
• The trader must assign a different method to those subscriptions first, then delete the card.

BR_4.17.1.20: Notification channels for payment failure and downgrade

Channel rule: the trader gets email plus a dashboard notification. Ops gets Slack. The trader never gets Slack.

Ops Slack alert — one event only. The only Slack alert this screen raises is the INVOICE_PAYMENT_FAILED notice when a Path B card charge is declined (§6.10). It goes to #ops-general (Prod C0BR8LRC5MK · Test #test-ops-general C0BR6UXRR8D) — the channel that already carries Dispute/Chargeback, MID capacity and negative balance alerts, i.e. per-trader financial exceptions. Ref: slack_channel_usage.md §14.

The end-of-month downgrade raises no Slack alert — the client only confirmed Slack for the payment-failure event, and nothing beyond that is added here.

Three dashboard notifications — one at each Flow 22 milestone, not only at downgrade. All three belong to the sixth Notification Center category, Billing & Subscriptions, and every CTA lands on this tab:

WebSocket payload for all three: { severity, message, timestamp: "ISO8601", target_timestamp: "ISO8601" }.

Four emails — all copy lives in the shared registry and is referenced by ID here. All four are sent through AWS SES from support@stacktrading.com:

SES-31 and SES-16 both concern unpaid money but do very different jobs. SES-31 is an invoice sent to an APM trader at EOM−7 (nobody has charged anything; the trader must pay). SES-16 is a failure notice sent to a card trader (the system charged and was declined). They are not interchangeable.

• SES-16 branches on market_data_billable (i.e. on level), because non-payment means different things per tier: Levels 1–2 lose every feed including base CME; Level 3+ lose only the add-ons. The branch reads the flag already introduced in BR_4.17.1.6 — no new property.
• SES-17 uses one body for both tiers. It only reports which feeds just went off and how to resubscribe — a Level 1–2 trader who loses base CME understands they must buy it back to trade, so no separate copy is needed.
• [Feed List] in SES-16 lists only the feeds that will be switched off, not every feed on the invoice. For Level 3+ traders, base CME is on the invoice but is not switched off, so it must not appear in that list.
• SES-16 renders the line Your {card_brand} ending in {card_last_4} was declined. Path A traders have no vault, so both variables are null and the fallback line is used: Your most recent payment via {APM_name} was unsuccessful.
• Email copy must never promise daily retries — the system attempts at most twice (Ref: BR_4.17.1.23).
• No dedicated dashboard payment button is built for Path A traders. They pay through the link in the email or the Extend button on the billing bar during the last 7 days of the month (§9.1 row 3). Process Payment Webhook catches the success payload and updates market_data_paid_until.

BR_4.17.1.21: Flow 12 does not deduct approved time off

• The Flow 12 cron uses the raw last_trade_date. It does not join the DTO table and does not subtract Flow 13 approved leave.
• A trader who takes 10 days off and then does not trade for another 20 is still caught by Flow 12 on day 30.
• The reason: Flow 12 is a billing cost-control tool, not a termination flow. What protects a trader from losing their account is Flow 19 (Stagnation Monitor), and Flow 13 already adds DTO days to Stagnation_Deadline for that purpose.
• The boundary: Stagnation_Deadline (plus DTO) applies only to Flow 19. Flow 12 uses the raw last_trade_date.
• A trader returning from a long break simply clicks Resubscribe to switch their feeds back on (§6.3).

BR_4.17.1.22: Flow 12 does not touch trading data

• Flow 12 only toggles the real-time market data feed to Off at the broker. It does not wipe trade history, performance ledgers or account balances.
• It does not handle positions or working orders: the Risk Engine enforces overnight margin rules and flattens non-compliant positions at session end, and working orders are cancelled by the exchange. That belongs to the Command tab / risk engine, not to this UC.
• Reactivation is a resume: the trader carries on with the same balance and trade history, not from scratch.
• Contrast with Flow 7 (fail / resign): Flow 7 does hard-delete the broker sub-account; Flow 12 does not.

BR_4.17.1.23: Flow 22 retry policy

• The system attempts the charge at most twice, never more: at EOM−3 and at Day 0 (the last day of the month).
• How many attempts a trader actually gets depends on when they bought: before EOM−3 → the full 2; in the last 3 days of the month → only 1, at Day 0 (Ref: §6.10 — Day 0 sweep).
• No daily retries. Retrying against a card the trader has not updated achieves nothing — what is needed is for the trader to fix it and pay.
• The INVOICE_PAYMENT_FAILED webhook must carry card_brand and card_last_4 from the NMI vault, so the email can name which card was declined instead of speaking in generalities.

BR_4.17.1.24: Separate CTAs per payment mechanism

Cards and APMs work in opposite directions, so the UI must not merge them into one generic "pay" button:

• The reason: one shared label would let APM traders assume they are auto-renewed, and they would lose their feeds because nobody told them to pay.
• The CTA label changes the moment the trader switches radio, inside the same modal — the two buttons are never shown side by side.
• Consistent with BR_4.17.1.10 (Path A vs Path B) and with the disclosure block at §9.2 row 6, which already explains both mechanisms in words.

---

9. Screen Description

9.1 Market Data Management tab

Wireframe: [BA Wireframe] Stack Trading Design/Account (Market Data Management).png · -1.png · -2.png

9.2 Subscribe to Market Data modal

Wireframe: Subscribe to Market Data.png · Payment card added.png · No payment card.png · 2.1.png

9.3 Change Payment Method modal

Wireframe: Change Payment Method.png · Change Payment Method-1.png · Change Payment Card.png · Payment Method Added.png

A two-column modal: the method list on the left, and a right column whose content follows the selection on the left.

9.4 Add new payment method panel

Wireframe: Add Payment Method.png

This panel occupies the right column of the Change Payment Method modal once the trader clicks Add new payment method.

9.5 Confirmation and result modals

9.6 Action Required: Exchange Agreements Pending modal

Wireframe: Phần ngoài/-.png

This modal opens on the Command tab as soon as the trader logs in. It does not live in Settings, but it belongs to this UC because it is a direct consequence of data feed state. Ref: §6.11, BR_4.17.1.14.

---

10. Open Items

Points the client has not yet confirmed, also logged in QnA_init_docs.md. This document follows the BA's proposed handling and will be updated once answers arrive.

---

Changelog