UC_4.6.1: Settings — Connections & Credentials

Document References

Design asset note — not an open item (settled 2026-08-27). The frames are not yet committed to References/Wireframe/Stage 2/Settings/, so this document cites the Figma node instead. The BA will commit them when convenient; this is internal housekeeping, not a pending question and not a dependency, and it must not be carried in any open-item list, raised with the client, or chased again.

✅ Design conflict closed 2026-08-20: the external-link glyph (↗) on the [Password Reset] action is now correct and must be kept — after the trader confirms in the modal, the flow leads out to the gateway's own reset screen, so the control genuinely navigates away (Ref: BR_4.6.1.5). The v1.4 instruction to remove the glyph is withdrawn. The confirmation modal now has a frame (supplied 2026-08-20 — title "Password Reset", the verbatim warning copy, [Confirm] / [Cancel]); it is still not committed to References/Wireframe/Stage 2/Settings/.

1. Overview

Design: Figma — Connections & Credentials, node 7878-116828

2. Trigger

• The trader clicks the user chip in the sidebar footer (displaying their initials + level, e.g. SD / Lvl 5) and selects Settings from the dropdown (Ref: UC_4.1.2 §2 Screen Description, row 6). The Account screen opens with Connections & Credentials already active (Ref: BR_4.6.1.1).
• The trader is already inside the Account screen on another tab and selects the Connections & Credentials tab.

3. Pre-conditions

• The trader is authenticated and inside the Dashboard shell (Ref: UC_4.1.1 §1 Overview). Authentication is a hard pre-condition for this screen — the client stated explicitly that the trader "must already be authenticated to get to this page" and that "the user must complete the Auth0 setup before they can access their credentials" (Ref: BR_4.6.1.13). This is the only way a trader can obtain their assigned platform password, since no vendor emails it (Ref: BR_4.6.1.7).
• The trader's account status permits access to the Account screen (Ref: BR_4.6.1.9).
• A Users record exists with a platform_selection value written at checkout (Ref: UC_2.8.2).

4. Post-conditions

• The trader has read the connection variables required by their gateway, and has optionally revealed and/or copied the Username, Assigned Password and License Key to the clipboard.
• No state is changed on the StackTrading side by viewing, revealing or copying — those are client-side only (Ref: BR_4.6.1.4).
• If the trader confirmed [Password Reset] in the modal, they have been led to the third-party platform's own reset screen, where the reset is performed and owned end-to-end. On the StackTrading side nothing has changed: platform_password_ciphertext and credentials_last_rotated_at are not rewritten, no new password is stored or displayed, and the Assigned Password row keeps rendering the originally provisioned credential (Ref: BR_4.6.1.5, BR_4.6.1.7).

5. Basic Flow

1. The trader opens the Account screen per §2. The Connections & Credentials tab is active by default.
2. The frontend calls GET /credentials with the trader's user_id.
3. The middleware reads the Users record, resolves platform_selection against Table I to determine the owning Gateway_Router, decrypts platform_password_ciphertext and license_key_ciphertext on the fly using the AWS-KMS-managed key (Ref: BR_4.6.1.15), and returns {Platform, Credentials: {Username, Password, License_Key}, Connection_String, Connection_Guide_URL} (Ref: BR_4.6.1.3).
4. The frontend renders exactly one credential card (Ref: BR_4.6.1.6), headed by the gateway name. It renders only the credential rows present in the response; any field absent or null has its entire row hidden — for MT5 and TraderEvolution that always hides the License Key row (Ref: BR_4.6.1.3).
5. The Username row displays Credentials.Username in plain text with a [Copy] control. The Assigned Password row displays Credentials.Password masked with a reveal (eye) toggle, a [Password Reset] action and a [Copy] control (Ref: BR_4.6.1.2). The License Key row, when present, displays the decrypted key in plain text with its own [Copy] control.
6. The trader clicks the eye toggle on the Assigned Password row → the plaintext value is shown in place of the mask; clicking again re-masks it. This is a purely client-side state change — the value was already in the GET /credentials response (Ref: BR_4.6.1.2).
7. The trader clicks [Copy] on any credential row → the full stored value is written to the clipboard and the control's label changes to Copied for 3 seconds, then reverts (Ref: BR_4.6.1.4).
8. The trader clicks [Connection Guide] → the platform-specific guide opens in a new browser tab. The URL is resolved from platform_selection, not from the gateway — the five Futures platforms share the Rithmic gateway but each has its own guide. On TradingView and MetaTrader 5 no guide URL exists, so the button is not rendered at all and this step does not occur (Ref: BR_4.6.1.11).
9. The trader clicks [Password Reset] → the internal confirmation modal Ref: CF-02 opens with the warning copy. Nothing is called and nothing is opened yet (Ref: BR_4.6.1.5).
10. The trader confirms in the modal → the frontend calls the new POST /reset-platform-password → the middleware resolves the trader's gateway and returns the destination of that gateway's own reset-password screen → the frontend leads the trader there in a new browser tab and the modal closes. No StackTrading record is written: platform_password_ciphertext and credentials_last_rotated_at are untouched, and the Assigned Password row still renders the originally provisioned value when the trader comes back (Ref: BR_4.6.1.5, BR_4.6.1.7). ⚠️ The reset destinations themselves do not exist yet — the client has not supplied a reset URL for any of the three gateways, so this step cannot be built until they arrive (Ref: BR_4.6.1.5 open item 1).

6. Alternative Flow

🔴 Withdrawn 2026-08-21 (BA/client answer). Up to v1.6 this section specified a Credentials Not Yet Provisioned branch that rendered an empty state carrying the string "Your platform credentials are being provisioned. Please check your email". The client removed it: "giờ không có empty state này nữa, không còn 'Please check your email' nữa". The copy had already been flagged as contradicting Ref: BR_4.6.1.13 — no vendor emails the trader, and no StackTrading email carries a password — so there is no email for the trader to check.

This UC has no alternative flow. By the time the trader can reach this screen they are authenticated and provisioned, so the credential rows always render. A null credential is therefore not a normal branch of this screen — it is a provisioning defect, handled as an error in Ref: §7 Exceptional Flow and owned upstream by Ref: UC_2.8.4 §6 / Ref: BN-06 at checkout Phase 3.

Ref: BR_4.6.1.8 is retired with this section; its ID is retained and marked withdrawn so existing cross-references do not break.

7. Exceptional Flow

• [If GET /credentials fails — HTTP 5xx, timeout, or no network]

  • The system displays Ref: TE-SYS-01 and keeps the card frame in its loading placeholder.
  • The system does not auto-retry. The trader reloads the page or re-enters the tab to trigger a fresh call.

• [If GET /credentials returns HTTP 200 but Credentials.Username or Credentials.Password is null]

  • Context: gateway provisioning did not complete, or failed after the backend's auto-retry. Since 2026-08-21 this is an error, not a normal state — the not-yet-provisioned empty state was withdrawn (Ref: §6, BR_4.6.1.8).
  • The system displays Ref: TE-SYS-01 and keeps the card frame in its loading placeholder — identical to the 5xx branch above. No credential row and no action is rendered, so the trader is never offered a control that cannot succeed.
  • The system does not poll and does not auto-retry. Recovery is owned upstream by provisioning — Ref: BN-06 / Ref: UC_2.8.4 §6. This screen only reports the failure.

• [If the session / access token has expired — HTTP 401]

  • The system displays Ref: TE-AUTH-01 and redirects to the Auth0 login. Credentials are never rendered to an unauthenticated session.

• [If POST /reset-platform-password fails — timeout, 5xx, or no reset destination resolvable for the trader's gateway]

  • No hand-off happens: the trader is not navigated anywhere and no browser tab is opened.
  • The modal closes and the system displays Ref: TE-SYS-01. The trader may trigger the reset again.
  • No partial-write risk exists on the StackTrading side, because this endpoint writes nothing. The v1.4 reconciliation question (gateway accepted the overwrite but the DB write failed) no longer applies — Ref: BR_4.6.1.5.

• [If the trader completes the reset at the third party]

  • StackTrading receives no webhook and runs no polling, so the Assigned Password row keeps showing the originally provisioned credential, which is now historical (Ref: BR_4.6.1.7).
  • This is expected behaviour, not an error state — the screen renders no warning, no stale badge and no notification. The Assigned Password label is what sets the trader's expectation.

• [If the browser blocks the clipboard write]

  • Context: the Clipboard API is unavailable (non-secure context) or the browser denies the permission.
  • The control's label stays at Copy — it does not change to Copied, so the trader is never told a copy succeeded when it did not.
  • The system displays Ref: TE-SYS-01. The value remains selectable on screen so the trader can copy it manually.

• [If the trader has resigned]

  • ✅ The tab renders normally. A resignation does not clear the session and, in SIM, no longer produces a distinct Resigned status at all — the account is simply Failed with failure_reason = 'VOLUNTARY_RESIGNATION', which this table already grants full access to (Ref: BR_4.6.1.9, CR-65).
  • The connection credentials shown are those of the sub-account, which stays assigned and connected in a read-only state until archive_date — Ref: UC_4.11.2 BR_4.11.2.4, BR_4.10.2.7. After the purge the credentials no longer resolve on the gateway.

8. Business Rules

BR_4.6.1.1: Screen Entry Point and Tab Context

The Account screen is reached only through the sidebar footer user chip → dropdown → Settings (Ref: UC_4.1.2 §2 Screen Description, row 6). The chip is not a direct link to this screen — the dropdown step is retained (BA decision, 2026-08-11 — Ref: QnA_init_docs.md B-01).

Connections & Credentials is the first tab in the list and the default active tab on entry. The full tab list and its owning UCs are defined once, in Ref: BR_4.6.2.1 — this UC does not restate it.

This screen holds no editable field, so it has no dirty state, no [Save Changes] action, and no unsaved-changes interception when the trader switches tabs.

BR_4.6.1.2: Credentials Are Displayed Natively — Assigned Password Reveal and Copy

🔴 This rule was reversed on 2026-08-17. Up to v1.3 the password was never displayed, never revealable and never copyable, and the client's stated direction was a zero-knowledge architecture in which StackTrading would not persist the password at all. The client has now confirmed the opposite model: "Disabling the TraderEvolution email and displaying the credentials natively in our dashboard is cleaner unified customer experience." The zero-knowledge direction is withdrawn — Ref: Changelog v1.4, QnA Settings [CC-DEF-05], [CC-DEF-06], which supersede [CC-DEF-02] and [CC-DEF-04].

The Dashboard is the single delivery channel. With zero emails coming from the execution vendors, StackTrading retains complete control over the onboarding experience. The trader has no other route to their platform password, so this screen must render it.

Row-level display rules.

• The reveal toggle is client-side only: the plaintext password is already present in the GET /credentials response, so revealing calls no API and writes nothing.
• Masking is therefore a presentation default, not a security boundary. The security boundary is the endpoint itself (Ref: BR_4.6.1.14) plus the authenticated session.
• Only one row may be in the Copied state at a time (Ref: BR_4.6.1.4). There is no restriction on the reveal state — it is independent of Copy.
• Exactly one password row exists, on every gateway. MT5 issues four distinct passwords, but only the Main one is in scope, so the row set above needs no MT5 variant — Ref: BR_4.6.1.16.

Label is Assigned Password, not Password. The client mandated the rename: "Rename the 'Password' label to 'Assigned Password'. This manages the user's expectations that this was their starting credential only." The wording matters because StackTrading cannot see a password the trader later changes — neither one changed natively at the vendor, nor one produced by this screen's own [Password Reset], which since 2026-08-20 is executed by the third party and never written back (Ref: BR_4.6.1.5, BR_4.6.1.7).

Storage and decryption — both secrets are persisted, encrypted. Client-confirmed: "they are stored already in scope, but not in plaintext… both the password and the license key must be stored as KMS-envelope encrypted ciphertext (platform_password_ciphertext and license_key_ciphertext) in the PostgreSQL database. The Node.js middleware decrypts them on the fly only when the authenticated user accesses the dashboard." The cipher, the key-management requirement and the component split that implements this are specified once in Ref: BR_4.6.1.15. Binding consequences:

• 🔴 Only the provisioning-time password is stored, and it is stored once (client instruction, 2026-08-20). platform_password_ciphertext is written by the provisioning write-back and is never rewritten by a password reset — resets are performed by the third-party platform and are not reported back to StackTrading. The field is therefore literally the assigned password, not the password currently in force (Ref: BR_4.6.1.5, BR_4.6.1.7).
• The ciphertext itself is never returned to the frontend, and plaintext is never returned to Zapier (Source: Zapier Integration V7.pdf Flow 1 Step 4 — "Middleware must never return plaintext platform passwords or license keys to Zapier").
• The License_Key must be decrypted before display — "Licensing will need to be displayed on the users profile page so you will need to decrypt it" (Adam Culver) / "showing an encrypted value would be useless for the trader" (Adrian Stack). A ciphertext rendered on screen is a defect, not a masked value.
• StackTrading emails still carry no plaintext password — that has not changed (Ref: SES-02 §Security, BR_4.6.1.13).

Rationale — two separate authentication mechanisms. Dashboard authentication is Auth0 passwordless (email link / OTP, no password at all); the password on this screen belongs to the trading gateway (Rithmic / TraderEvolution / MT5), not to StackTrading (Source: QnA from clients — Settings, Connections & Credentials Business logic row: "this is related to their Rithmic / TraderEvolution (TV) / MT5 password and not the passwordless dashboard"). Resetting one has no effect on the other.

BR_4.6.1.3: Gateway-Dependent Credential Card — Identity and Field Set

Card identity. The credential card is headed by the gateway (e.g. Rithmic), never by Platform_Name. The five Futures platforms — Quantower, ATAS, MotiveWave, Sierra Chart and TradeSea — all route to the same Rithmic gateway and share one credential set, so naming the card after the platform would misrepresent whose account the credentials belong to. The design currently shows only Rithmic; MetaTrader 5 and TraderEvolution are the other two values that will appear (BA decision, 2026-08-11 — Ref: QnA_init_docs.md B-02).

✅ [CC-EP-02] closed 2026-08-21 — the header reads the gateway out of Connection_String. BA answer: "Gateway_Router được trả về thông qua Connection_string của API Platform Credentials". Three binding consequences: (a) the Platform field stays a Platform_Name and is not what the header renders; (b) the frontend does not resolve Platform → Gateway_Router against Table I; (c) the middleware adds no extra gateway field to the response. The gateway travels inside the connection string that the middleware already returns for the resolved Gateway_Router (Table I).

✅ Residual null case closed 2026-08-21 — Connection_String is always populated. BA answer: "Thường thì không bao giờ null được, vì sẽ dựa vào platform thì sẽ luôn có connection_string" — the value is resolved from the trader's platform, so every in-scope platform yields one. This settles the first of the two readings offered in v1.6: the field is always present in the payload, and only its display row is conditional (point 5 below). The header therefore always has a source, and the v1.6 working rule "if null, fall back to Platform" is withdrawn — no fallback is specified, because no null is expected.

A null arriving anyway is a BE contract violation, not a display case: the frontend renders the card header from Connection_String and has no second source for it.

Field set is data-driven, never hardcoded on the frontend. The client confirmed the governing principle: "License keys are platform-dependent. The dashboard only displays connection variables required by the specific platform selected." The middleware therefore returns exactly the variables the resolved gateway requires, and the frontend renders one row per returned field. Any field that is absent from the response or null has its entire row hidden — no empty label, no placeholder value.

The mapping of gateway to credential rows — confirmed 2026-08-17 (QnA Settings [CC-BIZ-07]):

When the resolved gateway is MT5 or TraderEvolution, Credentials.License_Key is null and the entire row and its [Copy] control are hidden — not rendered empty, not rendered disabled. Re-confirmed 2026-08-27: the licence key exists for Rithmic alone, and hiding is the only correct treatment — a blank row or a greyed-out control would tell an MT5 trader that a licence key exists and is merely unavailable to them, which is false. This closes the BA's pending determination of 2026-08-11 and the earlier open question about TradeSea ("this also should be a question for Rithmic, I don't know if a license key is needed"): TradeSea routes to Rithmic, so it inherits the Rithmic row set.

Where the license key comes from. The value already exists end-to-end and needs no new data source. It is returned by the gateway at provisioning time — "Return: Credentials (username, password, license_key)" (Source: RFQ_ Stack Trading Prop Tech V7.pdf §Page 29) — persisted by Flow 1 Step 3–4 and Flow 3 as license_key_ciphertext on the Users record, KMS-envelope encrypted, decryptable only by the Middleware and "never emailed" (Source: Zapier Integration V7.pdf §3.1.6 Table: Users).

Response shape — now fixed by the client (2026-08-17). The v1.2/v1.3 position that the shape was a free backend decision is superseded. The documented output of the Platform Credentials endpoint (RFQ_ Stack Trading Prop Tech V7.pdf §Page 18 — {Platform, Login, Connection_String, Connection_Guide_URL}) is replaced by a nested structure, because the flat Login string was explicitly rejected: "do not cram the username, password, and license key into a single Login string. That is messy and will cause parsing issues on the frontend. You need to structure the Platform Credentials JSON object using nested fields so the frontend can easily map each value to its specific copy to clipboard button."

{
  "Platform": "TradingView",
  "Credentials": {
    "Username": "Trader_12345",
    "Password": "decrypted_password_here",
    "License_Key": "optional_key_here_or_null"
  },
  "Connection_String": "server_address_here_or_null",
  "Connection_Guide_URL": "link_here"
}

Binding points of this contract:

1. Login no longer exists — the username lives at Credentials.Username. Every reference to Login in earlier versions of this document reads as Credentials.Username.
2. Each credential variable is individually addressable so it can map 1:1 onto its own Copy control (Ref: BR_4.6.1.4).
3. Credentials.Password carries the decrypted plaintext, not a mask and not ciphertext — masking is the frontend's default presentation state (Ref: BR_4.6.1.2). This inverts constraint (2) of v1.2, which required the value to arrive already masked. The value is always the assigned (provisioning-time) password — the endpoint has no other password to return, since resets are never written back (Ref: BR_4.6.1.7).
4. Credentials.License_Key is nullable — null for every gateway except Rithmic (see the mapping table above).
5. Connection_String is always populated in the payload; only its display row is conditional (clarified 2026-08-21). The client's 2026-08-17 statement — "Depending on the platform, the server routing may be pre-configured in the downloaded terminal, so we will not always need to display a manual connection string" — governs whether the row is shown to the trader, not whether the field is sent. The field is always sent because it is resolved from the platform and because the card header reads the gateway out of it (see the [CC-EP-02] block above). Where the terminal ships with routing pre-configured, the display row is hidden while the field still travels in the response.
6. Connection_Guide_URL drives the [Connection Guide] button (Ref: BR_4.6.1.11).

The endpoint that may serve this payload is constrained separately — Ref: BR_4.6.1.14.

Copyability principle. Every connection variable rendered on this screen is copyable, so the trader can paste it into their terminal — the client stated this directly: "if there is a platform that requires a key that we get ourselves… that field should be copyable to make it easy for the trader to paste in their platform". As of 2026-08-17 there is no exception: the Assigned Password row is copyable too (Ref: BR_4.6.1.2).

Platform roster. NinjaTrader 8 is out of scope and must not appear as a supported platform, superseded by TradeSea (Ref: CR-20260720-001); the client independently confirmed "Ninjatrader is out of scope - technically people can bring their own license". Table I in Zapier Integration V7.pdf §3.6 still lists it and is superseded on this point.

BR_4.6.1.4: Copy Control Behaviour and Credential Field Overflow

Copy behaviour. Copying is a pure client-side action: it calls no API, writes nothing to the database, and changes no account state.

• On click, the control writes the full stored value to the clipboard — never a visually truncated version of it.
• The control's label changes to Copied for 3 seconds, then reverts to Copy on its own.
• At most one control may be in the Copied state at a time. Copying a second field reverts the first control immediately.
• No toast is raised on success. The inline label change is the only feedback, so that copying several fields in a row does not stack notifications.
• Failure handling: Ref: §7 Exceptional Flow.

Overflow. Username, License Key and Connection String are gateway-generated values with no frontend length limit. All truncate with tooltip when the value exceeds the available width — the full value is available on hover and is what the Copy control writes. No field wraps, so the card height stays fixed regardless of value length. The Assigned Password row truncates the revealed value the same way; its masked state is a constant-length string and never overflows.

BR_4.6.1.5: Password Reset — Hand-Off to the Third-Party Platform via POST /reset-platform-password

🔴 Rewritten 2026-08-20 — the storage half of the v1.4 rule is reversed. v1.4 specified a one-way brute-force overwrite: the middleware would call the gateway's admin API, rewrite platform_password_ciphertext + credentials_last_rotated_at, and return the new password for immediate display. The client has now removed that responsibility from the Dashboard entirely — "Khi reset password trader sẽ được xử lý ở bên thứ 3, và dashboard sẽ không phụ trách trong việc lưu password mới hay gì" and "Không overwrite gì password cũ trên dashboard nữa". POST /reset-platform-password survives as the endpoint name, but its job changes from overwrite the password to lead the trader to the right reset screen. Ref: Client instruction 2026-08-20 (Document References row 9), which supersedes the reset half of QnA Settings [CC-BIZ-06].

Responsibility split.

Behaviour.

1. The action is labelled [Password Reset], sits on the Assigned Password row, and is available only to an authenticated trader already inside this screen.

2. On click it opens the internal confirmation modal Ref: CF-02. No API is called at this point.

   ✅ Approved copy, reinstated 2026-08-28 ([CC-UI-02] closed): "This will instantly overwrite your current platform password and generate a new one. You will be logged out of active sessions."

   The withdrawal recorded in v1.7 and the BA-drafted replacement carried through v1.12 are both withdrawn in turn — this string is what ships. See the note under the responsibility split above for the one word ("instantly") that is knowingly imprecise under the redirect model.

   The modal is still required — it warns the trader that they are about to leave the Dashboard and that the value on screen will stop being accurate.

3. Cancel closes the modal and changes nothing.

4. Confirm calls POST /reset-platform-password — a new backend endpoint. The middleware resolves the trader's platform_selection → Gateway_Router (Table I) and returns the reset destination for that gateway; the frontend then leads the trader to that screen in a new browser tab. Because the flow does leave the Dashboard, the external-link glyph (↗) already drawn on this control is correct and stays (Ref: §9.1 row 11).

5. No write occurs on the StackTrading side. platform_password_ciphertext and credentials_last_rotated_at are not touched, no new password is returned in the response, nothing is persisted, and the Assigned Password row is not re-rendered — it keeps showing the originally provisioned value (Ref: BR_4.6.1.7).

6. There is no webhook, no polling and no callback from the vendor. Once the trader is handed off, StackTrading has no visibility of the outcome — by design.

7. Failure handling: Ref: §7 Exceptional Flow.

Scope boundary. The password being reset is the trading-gateway password (Rithmic / TraderEvolution / MT5), never the Dashboard login, which is passwordless (Ref: BR_4.6.1.2). On MT5, where four passwords exist, the reset targets the Main password and no other — client-confirmed 2026-08-21 (Ref: BR_4.6.1.16).

Closed 2026-08-21 — three v1.5 open items answered, and one no longer applies:

✅ Re-tested and reaffirmed 2026-08-27 — the redirect model stands. A BA answer on this date restated the flow in terms of the old overwrite model ("API này sẽ gọi đến Admin API của từng ISV… để thực hiện ép ghi đè mật khẩu cưỡng bức") while simultaneously stating the storage rule of the redirect model ("Hệ thống sẽ không cập nhật/lưu trữ/đồng bộ bất cứ update password nào… Chỉ lưu trữ và hiển thị assign password"). The two are not compatible: an admin-API overwrite that is never stored and never returned would destroy the trader's working password and hand them nothing in its place — no gateway emails the trader ([CC-DEF-08]), so there would be no channel at all through which they could learn the new one, and they would lose terminal access outright.

Resolved 2026-08-27 in favour of the redirect model — "Dashboard sử dụng URL bên thứ ba để người dùng tự reset", which is the half of that answer consistent with both the storage rule above and the client instruction of 2026-08-20. No gateway admin API is called by this screen. The MT5 Manager API stays out of this UC's dependency set.

✅ Modal copy settled 2026-08-28 — the client string is reinstated, [CC-UI-02] closed. After being queried twice, the same string has been approved a third time and is now the copy to build:

"This will instantly overwrite your current platform password and generate a new one. You will be logged out of active sessions."

The BA draft that stood in v1.7–v1.12 is withdrawn. Read it as a trader-facing warning about the end state, not as a description of what the Confirm button executes — the trader who follows the hand-off through does end up with a new password and does get dropped from live terminal sessions, which is what they need to be warned about before leaving a screen mid-session.

⚠️ One word is at odds with the flow, and QC should not raise it as a defect. "instantly" is inaccurate under the redirect model: nothing happens at the moment of Confirm — the overwrite and the session termination occur at the third party, only if and when the trader completes the reset there. A trader who confirms and then closes the vendor tab keeps their existing password and stays logged in. The copy is approved with that known imprecision; do not file it as a bug against BR_4.6.1.5, and do not silently "fix" it during build.

Still open — must be added when answered:

RACI for the missing destinations — corrected 2026-08-24. The three reset URLs are not Stack Trading ops content, as v1.7 assumed. They are an output of the dev team's platform integration ("Đợi bên phía team dev triển khai xong về platform mới có link"): Sotatek builds the integration, the URL resolution and the hand-off, and the URLs become available when that integration lands; the third party owns the reset page and the transaction behind it. Stack Trading's only role is confirming the destination is the right one once it exists.

BR_4.6.1.6: Exactly One Credential Card Per Trader

This screen renders one credential card, never a list and never a history.

GET /credentials is keyed on user_id alone — it takes no account identifier — so a trader has exactly one active credential set at any moment. A trader cannot hold a SIM and a LIVE credential set simultaneously: promotion to LIVE restarts the trader on a newly provisioned account, and Flow 3 — Database Write-Back (Credentials) overwrites platform_username, license_key_ciphertext, cipher_version and credentials_last_rotated_at on the same Users record. The previous credential set is not retained and is not viewable anywhere in the Dashboard (BA decision, 2026-08-11 — Ref: QnA_init_docs.md B-12).

BR_4.6.1.7: The Database Is the Master Record of the Assigned Password Only

🔴 Narrowed 2026-08-20. v1.4 asserted that the database was the master record of the password currently in force, with POST /reset-platform-password as the mechanism that restored that truth after drift. That assertion is withdrawn: the reset is executed by the third party and never written back, so the database is the master record of the assigned (provisioning-time) credential and of nothing beyond it.

The values on this screen are read fresh from GET /credentials on every entry to the tab and are never cached across visits. The password now changes through exactly one write path:

1. Provisioning write-back — Flow 1 Step 3–4 (SIM) and Flow 3 (Go-Live), which write platform_password_ciphertext and credentials_last_rotated_at on the Users record. On MT5 the value written is the Main password only; the Investor, Trader and Money passwords are never provisioned into StackTrading storage (Ref: BR_4.6.1.16).

There is no second path. POST /reset-platform-password writes nothing at all (Ref: BR_4.6.1.5). credentials_last_rotated_at therefore only ever reflects a provisioning event, never a trader-initiated reset — any consumer of that column must read it that way.

There is no synchronisation with the vendor. The execution platforms send no webhook when a password changes on their side, and StackTrading will not build polling to detect it (client-confirmed 2026-08-17). Three consequences follow, all deliberate:

• A trader whose password has been reset — natively at the vendor, or through this screen's [Password Reset] hand-off — leaves this screen showing a stale value. The platform has no way to know, and is not expected to.
• The row is labelled Assigned Password precisely to set that expectation: it is the credential StackTrading issued at provisioning, not necessarily the one currently in force (Ref: BR_4.6.1.2).
• There is no recovery path back to accuracy. Under v1.4 the recovery path was to run [Password Reset], which overwrote the vendor and made the database correct again; that no longer exists. A trader who forgets their current password resets it again at the vendor, and the Dashboard value never catches up.

No proactive notification — confirmed 2026-08-27, closing B-08. When a gateway rotates a credential on its own side, StackTrading stays silent: no in-app notification, no dashboard banner, no stale badge on the row, and no StackTrading-sent email. The trader is never told, by any channel.

• The reason this is acceptable rather than negligent: the database is the master record of the assigned password and of nothing else, so there is no "correct" value StackTrading could notify the trader about. A notification would announce a change the platform cannot describe.
• The only moment the trader sees a value at all is when they open this tab, and what they see is whatever the database currently holds — read fresh on every entry, never cached across visits.
• Adding any notification would be a change request against this rule. Ref: QnA_init_docs.md B-08, QnA Settings [CC-TRIG-01] — both now closed.

BR_4.6.1.8: Credentials Not Yet Provisioned — Empty State — 🔴 WITHDRAWN 2026-08-21

🔴 This rule no longer applies. It specified an empty state rendered inside the card frame with the exact text Your platform credentials are being provisioned. Please check your email, hiding every action while Credentials.Username was null. The client removed the state entirely: "giờ không có empty state này nữa, không còn 'Please check your email' nữa".

Why it went: the copy told the trader to check an email that no longer exists. Ref: BR_4.6.1.13 establishes that no execution vendor emails the trader and that no StackTrading email carries a password, so the instruction was unactionable. Rather than re-word it, the client removed the state — the Dashboard does not present "credentials pending" as a normal condition.

What replaces it. A null credential is now an error, not a state: Ref: §7 Exceptional Flow renders Ref: TE-SYS-01 over the loading placeholder, with no credential rows and no actions. Recovery is owned upstream at checkout Phase 3 — Ref: BN-06, Ref: UC_2.8.4 §6.

The ID is retained, not reused. BR_4.6.1.8 must not be assigned to a new rule — the later BR IDs in this UC are unchanged so that cross-references from Ref: §9.1 and from other UCs keep resolving.

BR_4.6.1.9: Account-Status Gating

A breach suspends trading, not access to the trader's own connection details, so Soft Breach and Hard Breach leave this screen untouched (BA decision, 2026-08-11 — Ref: QnA_init_docs.md B-11). This is consistent with a failed account remaining able to log in and view its own state.

A resigned SIM trader is no longer an exception — this row was wrong on two counts and both are now corrected:

1. The session is not cleared. The client reversed the "logs them out" instruction on 2026-08-12 ([RES-BIZ-01] — "Do not clear the session tokens or log the user out… so they can instantly purchase a new challenge without the friction of logging back in."). The Auth0 session survives a resignation — Ref: UC_4.11.2 BR_4.11.2.7.
2. Flow 20 does not run in SIM. Since 2026-08-25 a SIM resignation is handled natively by the middleware and writes status = 'Failed'; Flow 20 → Flow 7 are LIVE-only — Ref: UC_4.11.2 BR_4.11.2.8, CR-65.

Consequently a resigned SIM trader stays logged in and reaches this tab exactly like any other Failed trader — which is also what UC_4.10.2 §4 already states for the Failed state: "All other screens (Account, Settings, etc.) render completely normally." The Frosted Glass treatment is Dashboard-only and never reaches this screen.

Resigned is not a status value. It is a colloquial label for status = 'Failed' plus failure_reason = 'VOLUNTARY_RESIGNATION' in SIM, and for status = 'Terminated' in LIVE. Any gate keying on a literal 'Resigned' is stale — Ref: UC_4.11.2 BR_4.11.2.10.

BR_4.6.1.10: Out of Scope — Controls Panel and Data-Feed Lock Banner

Two elements render on or near this screen but are not owned by this UC:

• Controls panel (Desk Manager — renamed from AI Chat per QnA Settings [CTRL-UI-01], both frames of 2026-08-17 already show the new label — and Reduce Motion toggles), rendered beside the tab list on every Settings tab including this one. Owned by UC_4.6.4; each toggle commits immediately on flip and does not interact with this screen — Desk Manager through POST /ai-preference, Reduce Motion entirely on the frontend with no backend API (client answer 2026-08-24, Ref: BR_4.6.4.2). Ref: BR_4.6.2.11.
• Rithmic data-feed lock banner — Rithmic locks the price feed at the exchange gateway level until the trader logs into R|Trader Pro and signs the mandatory CME digital agreements (Ref: CR-20260727-005). This concerns market-data feed status, not connection credentials, and therefore belongs to the Market Data Management tab, which has its own Data Feed Status indicator (Source: RFQ_ Website and Dashboard Implementation V7.pdf §Market Data Management). That tab has no UC_ID assigned in the UC_4.6.x range of the WBS, so the CR remains unassigned; this UC records the boundary and does not describe the banner.

BR_4.6.1.11: Connection Guide Is Per-Platform, Not Per-Gateway

🔴 Retitled and made concrete 2026-08-21. v1.6 titled this rule "Connection Guide Is Per-Gateway" and expected placeholder guides authored by the client. Both are superseded: the guide is keyed on the platform, and the client has supplied live third-party URLs. The v1.4 note "Unique, use placeholders please. One per platform we can edit later" is withdrawn as the launch plan.

🔴 The button is never hidden — dummy URLs cover the gaps (client answer, 2026-08-24). The v1.7 rule that a missing URL hides the [Connection Guide] button is withdrawn. The client's instruction: "không ẩn nút đâu nhé, cứ để đấy, hiện tại là không có link và dùng tạm link dummy data thôi, sẽ bổ sung sau" — and for Sierra Chart: "bỏ cái link cũ đi chứ không dùng link hiện tại nữa, tạm thời dùng link dummy data". So: Connection_Guide_URL is never null and the button renders for all seven platforms. Three of them — Sierra Chart, TradingView, MetaTrader 5 — carry a dummy placeholder URL today, to be swapped for the real link as pure configuration when the client supplies it. The Sierra Chart entry supplied on 2026-08-21 (https://www.rithmic.com/platforms/guides) is explicitly withdrawn and must not be used.

[Connection Guide] opens the setup guide in a new browser tab (target="_blank") at the Connection_Guide_URL returned by GET /credentials. The middleware evaluates platform_selection and returns that platform's link (Source: RFQ_ Stack Trading Prop Tech V7.pdf §Page 18).

The resolution key is platform_selection, never Gateway_Router. This is the one place in this UC where platform and gateway diverge in the UI: the card header names the gateway (Ref: BR_4.6.1.3) while this button resolves per platform. Five Futures platforms share the Rithmic gateway and all render the header Rithmic, yet each opens a different guide. Resolving the guide from the gateway would send four of the five traders to the wrong document.

URL set (4 real vendor URLs client-supplied 2026-08-21 · 3 dummy placeholders per client answer 2026-08-24):

All seven in-scope platforms are mapped; four carry a real vendor URL, three carry a dummy placeholder. The roster matches Ref: BR_4.6.1.3, with NinjaTrader 8 out of scope. Every trader sees the same control in the same place on every platform — the asymmetry raised in v1.7 (Futures gets a guide, Forex does not) is closed by the dummy-URL decision, not by hiding anything. What remains is content, not behaviour: Stack Trading owes real URLs for Sierra Chart, TradingView and MetaTrader 5, and swapping them in is configuration with no code change (see RACI below).

Dummy URL — form confirmed by the client, 2026-08-24. The placeholder takes the same form as the four real vendor links: an ordinary, syntactically valid external URL that target="_blank" opens normally — never an empty string, never #. The client's words: "Có thể làm giống các link real kia, hoặc PDF (cái này khách chưa chốt, nếu chốt sẽ bổ sung sau)".

One placeholder per platform, never a shared one — confirmed 2026-08-27. Each of the three unresolved platforms gets its own independent placeholder (a provisional link or a temporary PDF link), so that swapping in a real Sierra Chart guide does not touch the TradingView or MetaTrader 5 entries. A single shared placeholder across the three is not acceptable: it would make the three swaps interdependent and would hide which platforms are still unresolved. The button is not hidden under any circumstance whatsoever — restated verbatim for the third time (2026-08-24, and again 2026-08-27: "Không ẩn nút này trong bất kỳ trường hợp nào").

The delivery format of the real guides is still open — and it changes nothing structurally. A guide may eventually arrive as a web page or as a PDF; the client has not decided. Connection_Guide_URL is a URL either way, so the frontend contract is identical and no branch is needed — the destination is opened in a new tab regardless of what it points at.

One behaviour, no download — client answer 2026-08-24 (đợt 3). "Nếu là PDF thì cũng sẽ là dạng click vào button Connection guide, và mở ra tab mới có link PDF đó. Nói chung là sẽ không có download gì Connection Guide hết nhé, đều là click vào button và mở ra tab mới." This is a hard rule: [Connection Guide] has exactly one behaviour — open the destination in a new tab. There is no download action, no download attribute, no "Save guide" affordance, no PDF-specific variant of the control, and no second control anywhere on this screen for obtaining a guide. A PDF is opened in the new tab the same way a web page is. The v1.9 note that a PDF "may be downloaded rather than rendered" is withdrawn — see the hosting requirement below.

Hosting requirement that makes the no-download rule true for PDFs. A PDF served with Content-Disposition: attachment makes the browser download the file instead of displaying it, which would break the rule above. Any PDF guide must therefore be served inline (Content-Disposition: inline, correct Content-Type: application/pdf) so it renders in the new tab. This is a hosting/ops requirement on whoever serves the file, not a frontend branch — the frontend does the same thing either way.

• If PDFs are chosen, the files become StackTrading-hosted content rather than third-party vendor pages, which moves hosting and versioning — and the inline-serving requirement above — into Stack Trading's ops scope (see RACI below). The four existing Futures links stay third-party either way.

Storage — hardcoded in the backend, confirmed 2026-08-27. Not Table I. The guide map lives in backend code: "link này hiện tại sẽ là hardcode, không sửa link trực tiếp qua table nào cả." The Connection_Guide_URL column on Table I proposed in v1.7–v1.9 is withdrawn and must not be created; GET /credentials resolves platform_selection against the hardcoded map and returns the URL in the payload exactly as before — the response contract is unchanged, only the source behind it.

• 🔴 Consequence the client must accept: every guide URL change is a code change and a deploy. Ops cannot self-serve. This applies to all three routine cases — swapping a dummy for a real guide, sourcing the Sierra Chart deep link, and repairing a vendor page that moved. Each is a dev ticket and a release, not a data edit.
• This narrows the earlier expectation that placeholders exist "để Ops có thể cập nhật sau". Ops still own the URL values as content; they simply cannot apply them without dev. If that turns out to be unworkable in operation, moving the map to Table I is a change request against this rule — the endpoint contract would not change, so the cost is confined to storage and a migration.
• The three dummy placeholders are hardcoded alongside the four real vendor links, one entry per platform.

Placeholder value — resolved 2026-08-28: a StackTrading holding page. The answer offered two options — "tạm thời để trống hoặc dùng link giữ chỗ của hệ thống" — and only the second is compatible with the rules above.

• 🔴 Leaving Connection_Guide_URL empty is not viable and must not be built. The button is never hidden and never disabled, so an empty value produces a control that opens a blank tab — a visible defect on three of seven platforms. The system holding page is therefore the placeholder, and Connection_Guide_URL stays non-null for all seven platforms exactly as BR_4.6.1.11 requires.
• The real guides for these three will be StackTrading-authored PDFs, not vendor pages — "sẽ bổ sung các link guide chính thức sau khi BA chuẩn bị xong tài liệu hướng dẫn (PDF)". This settles the web-page-vs-PDF question left open on 2026-08-24 for these three platforms: they are PDFs, authored by the BA. The four live Futures links stay third-party web pages.
• Consequence — the inline-serving requirement below is now live, not hypothetical. Those PDFs must be served with Content-Disposition: inline so they render in the new tab instead of downloading, which would break the no-download rule. Hosting and versioning them sits with Stack Trading (see RACI).

❓ BE/FE to agree the concrete URL of the holding page.

These are third-party pages, not StackTrading content. Every URL points at the vendor's own documentation site. Three consequences the client should be aware of:

• StackTrading cannot edit any of these pages, and a vendor that moves or retires an article silently breaks the link. There is no in-app detection of a dead guide.
• Keeping the set current is content maintenance, not a code change — provided the mapping is stored as configuration rather than compiled into the frontend (see RACI below).
• The Sierra Chart entry is no longer Rithmic's generic platform-guides index — the client withdrew that link on 2026-08-24 ("bỏ cái link cũ đi chứ không dùng link hiện tại nữa") because it dropped the trader on a list rather than a Sierra Chart article. It carries a dummy placeholder until a real Sierra Chart guide is supplied.
• 🟡 Sierra Chart — old link dropped, replacement pending (2026-08-27 → 2026-08-28). 2026-08-27 said a real deep link must be sourced. 2026-08-28 settles the interim: "Tạm thời bỏ link cũ đi, sẽ bổ sung link mới khi có update." The generic Rithmic index is gone and must not be reinstated; Sierra Chart carries the same placeholder as the other two until a real guide arrives. It is an outstanding content task with no behaviour attached.

RACI.

There is no null branch — this is the one field the row-hiding rule does not reach. Superseding v1.7: Connection_Guide_URL is always populated for all seven platforms, with a dummy placeholder standing in wherever a real guide has not been supplied (client answer 2026-08-24, restated 2026-08-27). The [Connection Guide] button therefore always renders — never hidden, never disabled — and the field-hiding rule of Ref: BR_4.6.1.3 (which governs License_Key and the Connection_String display row) does not apply here. Swapping a dummy for a real URL introduces no rendering branch — but under the hardcoded model confirmed 2026-08-27 it is a code change and a deploy, not a configuration edit (see the storage note and RACI above). The v1.8–v1.9 claim that the swap is "pure configuration, no code change" is withdrawn.

BR_4.6.1.12: Identical for SIM and LIVE — No Environment Branching

This screen behaves identically for SIM (Evaluation) and LIVE (funded) accounts: same tab, same fields, same masking, same actions, same endpoints. The client's answer for every one of the eight Criteria rows in the LIVE column is "(same as SIM)".

The underlying credentials differ between environments — a SIM account is provisioned against a simulation gateway using the Sim_Rithmic_Default / Sim_MT5_Default risk templates in Table I, while a LIVE account is provisioned against the live FCM sub-account with per-level risk parameters — but that difference lives entirely in the provisioning flows and never surfaces as a rule on this screen. No rule in this UC is gated on account type, level, or environment.

BR_4.6.1.13: Provisioning and Delivery Order — Flow 1 Unchanged, Zero Vendor Emails

The client confirmed the order of operations explicitly and left Flow 1 unchanged: "we provision the execution accounts immediately upon payment success. This ensures the API calls to the gateways process in the background." The sequence this screen depends on is:

Zero emails from the execution vendors — confirmed 2026-08-21 ([CC-DEF-08] closed). TraderEvolution's provisioning email is deliberately switched off, and the remaining two are now settled: "Không Gateway Router nào gửi" — no gateway emails the trader. The v1.4 caveat that this was "believed" but unconfirmed is withdrawn; the Dashboard is confirmed as the sole delivery channel. The rationale is operational, not cosmetic: "if the vendors email the traders directly, we have to change the order or freeze new accounts, likely slowing down the onboarding." If a vendor turns out to email credentials, the delivery model — not this screen — is what must change, and it becomes a change request against this rule.

BR_4.6.1.14: Endpoint Boundary — Platform Credentials Only, Never Current Level Detail

Credentials may be served only by the dedicated Platform Credentials endpoint (GET /credentials) — the single route authorised to decrypt them. Client-confirmed 2026-08-17 (Ref: QnA Settings [CC-EP-01]): "Do not use Current Level Detail for this. The architecture dictates that passwords are stored as encrypted ciphertext and must not be exposed via general user profile endpoints. The Platform Credentials endpoint is the dedicated secure route authorized to decrypt and return the specific login credentials and connection string for the user's chosen execution platform."

Consequence for the Current Level Detail contract. RFQ_ Stack Trading Prop Tech V7.pdf §Reference Data Endpoints documents Current Level Detail as returning platform_username, platform_password and license_key alongside the level fields. That part of the documented response is overridden — those three fields must be removed from the Current Level Detail contract, which is a general user-profile endpoint. No screen may read credentials from it.

Connection_Guide_URL is returned by the same Platform Credentials endpoint and is what makes the [Connection Guide] button platform-specific (Ref: BR_4.6.1.11).

BR_4.6.1.15: Initial Password — Generation, Cipher and Key Management

Added 2026-08-21 after the dev team proposed a hardened storage workflow and the client confirmed it was already mandated, not a new requirement: "Your team's intuition on security is correct, but this is not a new proposal. This exact workflow is already a mandate in the V7 specification." Client verdict: "Yes, I'm supportive!" This rule states the standard once; Ref: BR_4.6.1.2 and Ref: BR_4.6.1.13 point here rather than restating it.

1. The ISV generates the initial password — Path B, confirmed 2026-08-27 for all three gateways. The v1.7 branch is closed: the earlier conditional answer ("Depends if supported, the ISV may generate the initial password") resolves to Path B everywhere, and Path A — StackTrading generating a password and pushing it to the gateway — is not built for any gateway.

Confirmed provisioning sequence (Flow 1 Step 3):

Consequence for this screen: none. Points 2–4 below and every rule in this UC already applied identically under either path, because both end with the middleware holding a plaintext password it must immediately encrypt. Closing the branch removes an open item; it changes no behaviour.

2. Cipher — AES-256-GCM, two-way. The password must be encrypted with AES-256-GCM and stored as ciphertext in platform_password_ciphertext; the same standard applies to license_key_ciphertext. Two-way encryption is required precisely because the value must be decryptable for display — hashing is not an option on this screen (Ref: BR_4.6.1.2).

3. Key management — AWS KMS or AWS Secrets Manager, never a hardcoded secret. The client's instruction is binding and specific: "please ensure that the 'secret key' you mentioned is securely generated and managed via AWS KMS (Key Management Service) or AWS Secrets Manager as defined in our infrastructure spec, rather than simply hardcoding a shared secret string into the application environment variables."

• A shared secret string in an application environment variable is an explicit non-conformance, not an acceptable interim.
• cipher_version on the Users record records which key generation produced each ciphertext, so a key rotation does not orphan records written under the previous key.

4. Component split — only the read path may decrypt.

This is the concrete implementation of the "the Node.js middleware decrypts them on the fly" wording quoted in Ref: BR_4.6.1.2 — the decrypt capability belongs to api-core alone, and the endpoint boundary in Ref: BR_4.6.1.14 is what confines it.

RACI. Sotatek builds generation, encryption, storage and the decrypt path; Stack Trading owns the AWS account, the KMS key policy and the Secrets Manager configuration as infrastructure ops; the third party owns the credential itself once issued.

Scope note. This rule governs the initial / assigned password only. StackTrading never sees, generates or stores a password produced by a later reset — that transaction belongs to the gateway (Ref: BR_4.6.1.5, BR_4.6.1.7).

BR_4.6.1.16: MT5 Issues Four Passwords — Only the Main Password Is In Scope

Raised by the dev team and confirmed by the client on 2026-08-21. MetaTrader 5 issues up to four distinct passwords per account, each with a different privilege level:

Client answers, verbatim. "Will we store all 4 of these MT5 passwords on the dashboard?" → "No, just the main and the initial." · "If all 4 passwords are saved on the dashboard, when a trader clicks 'Password Reset', which password will it lead to resetting?" → "Main."

Binding consequences:

1. Storage. platform_password_ciphertext on an MT5 account holds the Main password and nothing else. The Investor, Trader and Money passwords are not requested at provisioning, not stored, and not tracked — Ref: BR_4.6.1.15, Ref: BR_4.6.1.7.
2. Display. Credentials.Password for an MT5 account is the Main password. The Assigned Password row stays a single row on every gateway — there is no MT5-specific multi-password UI, no password-type selector and no extra card. Ref: BR_4.6.1.2, Ref: BR_4.6.1.3.
3. Reset. [Password Reset] on an MT5 account targets the Main password. The modal needs no MT5 variant, because the trader is never offered a choice of which password to reset — Ref: BR_4.6.1.5.
4. "the main and the initial" reinforces Ref: BR_4.6.1.7: the stored value is the Main password as issued at provisioning. A Main password the trader later changes at MT5 is not captured, exactly as on the other two gateways.
5. Rithmic and TraderEvolution are unaffected — each issues a single password, so this rule changes nothing for them and adds no branching to Ref: BR_4.6.1.3's field-set mapping.

❓ Not raised by the client, flagged by BA. The Investor (read-only) password is what a trader hands to a third-party analytics, copy-trading or verification service. If Stack Trading later wants traders to obtain one, it is not available anywhere in this product — no screen exposes it and no flow provisions it. Out of scope until asked; adding it would be a change request against this rule, not a defect.

9. Screen Description

9.1 Account screen — Connections & Credentials tab

Changelog