Tracking: Linear project Desk management. Customer needs: TTG (A-4855), Blockhouse, Axtior.
Objective. A customer runs several traders and several trading accounts on AX. The customer adds and removes its own traders, opens accounts, and moves cash between its accounts. AX decides who may move money and which accounts may trade against each other.
Edition scope. Steps 1 to 8 apply to both editions. Steps 9 to 12 apply to the AX edition only. In the aiex edition a customer has at most one trading account, because Bitnomial clears one account per counterparty and fills are attributed from the clearing pair. See Customer account access, decision 12.
This SoW is the entry document for that work. It lists 12 steps in build order. Each step ships by itself and needs only the steps above it. A subordinate SoW holds the design of each step.
| Step | Outcome | Design | Linear |
|---|---|---|---|
| 1 | Operations and Compliance sign off the customer mapping and the funding-rights list. | Customer account access | A-5006 |
| 2 | Customer tables exist and hold today's data. | Customer account access, stage A | A-4890 |
| 3 | Deposit and withdraw are their own permissions. | Customer account access, stage B | A-4889 |
| 4 | AX staff create customers, assign accounts, and appoint managers. | Customer account access, stage C | A-4897 |
| 5 | A revoked user loses WebSocket cancel-all and account events at once. | Customer account access | A-4887 |
| 6 | A customer manager adds, changes, and removes traders through the API. | Customer account access, stage D | A-4892 |
| 7 | A customer manager does the same on a Team screen. TTG ships. | Customer account access, stage E | A-4896 |
| 8 | AX marks a set of accounts that may not trade against each other. Blockhouse ships. | Cross-account self-trade prevention | A-5032 |
| 9 | Deposit instructions and withdrawal requests name the selected account. | Accounts and transfers, W2 | A-4913, A-4914, A-4915 |
| 10 | Operations opens another account for a customer through a request that can be retried. Axtior ships. | Accounts and transfers, S1 and W5 | A-4916, A-4893, A-4898, A-4902, A-4921, A-4923, A-4924 |
| 11 | An authorized customer user requests a new account. | Accounts and transfers, W6 | A-4925, A-4926, A-4906, A-4909 |
| 12 | Cash moves between two accounts of one customer. | Accounts and transfers, cash holds, W10, and W11 | A-4934, A-4937, A-4904, A-4888, A-4891, A-4894, A-4895, A-4899, A-4900, A-4903, A-4907, A-4910 |
The stage letters and W numbers are the labels in the subordinate SoWs and in the Linear issue titles.
Read-only queries against production Postgres, in both editions,
produce the lists in the decision review:
each non-system account, its owner, and the customer name and type that
step 2 will give it; owners that are admin, staff, or QA users; in the
aiex edition, owners of more than one account; and each user and API key
that holds can_trade, because step 2 copies that bit to the
new deposit and withdraw bits.
Operations and Compliance review the lists and record decision D1 below. This step has no code.
The schema gains customers,
customer_members,
trading_accounts.customer_id, and the
can_deposit and can_withdraw columns on
account_permissions and api_keys. The customer
holds the approval and freeze state, the accepted business facts, and in
the aiex edition the clearing account.
trading_accounts.ubo_user_id and
users.is_onboarded go away. A backfilled customer takes its
applicant's user id, so the TRM ids, fiat deposit codes, default account
ids, and every onboarding table keep their values. Order entry gates on
the account's customer. Two data migrations fill the tables from the
lists approved in step 1: identity first, funding bits second. No
funding route reads the new bits yet.
Deposit routes check can_deposit. Withdraw routes check
can_withdraw. The trade bit no longer permits either. API
keys, the admin permission editor, GET /whoami, and the
customer Transfer panel carry the two bits.
AX staff get admin routes and admin CLI commands to create a customer, set an account's customer, add and remove members, and appoint managers. A recon check reports rows that break the customer invariants.
Order-gateway checks the permission replica on every REST request and on WebSocket place, cancel, and replace. Two WebSocket paths use the permission read at connect time: cancel-all and account event delivery. This step makes both use the current grant.
A manager lists members, adds a member by username, sets the five trading permissions on the customer's accounts, revokes them, and removes a member. One transaction removes a member and that member's grants on the customer's accounts. API-key sessions and non-managers get 403.
One screen under Account Settings in the customer app uses the step 6 routes.
An admin CLI probe finds which EP3 setting prevents a match between two participants. The schema gains a group table. Order-gateway sends the group's key to the venue. AX staff manage groups through admin routes, the admin CLI, and the admin GUI. This step also delivers ticket W5.5 of step 10.
The probe needs no schema. It can start before step 2.
USD deposit instructions identify the selected account, as USDC instructions already do. The withdrawal request shows the selected account. Tests fund and withdraw on two accounts with one owner and reconcile each account.
An account-opening request has one request key and one account ID. A retry after a timeout or a crash returns the same account. The account cannot trade until the readiness checks pass. The checks cover owner approval, restrictions, self-trade scope, and separate accounting for each account.
AX grants a creation mandate to a named customer user. That user submits an account name and the initial users. The request runs on the step 10 path. The server sets the owner, venue settings, and fees. Decision D4 states which requests Operations must review before the account opens.
This step has three parts, in order:
Each decision has an owner. The owner records the result, the evidence location, the approver, and the date in this table. A step does not activate while a decision that gates it is open.
| ID | Owner | Decides | Gates | Result |
|---|---|---|---|---|
| D1 | Operations and Compliance | The items in the customer-access decision review. | Steps 2 and 6 | Open |
| D2 | Operations and Compliance | Owner and account mapping, approval reuse, and the manual withdrawal procedure. The funding-screening identity and the bank reference are settled by decision 10 of the access SoW: both are keyed by the customer id, which equals the applicant's user id for every existing customer. | Steps 9, 10, and 12 | Open |
| D3 | Risk, Legal, and venue Operations | For each multi-account setup: position aggregation, self-trade scope, outflow rules, and shortfall coverage. Each is recorded as verified, not required, or unresolved. Step 8 supplies the self-trade evidence. AX edition only. | A second account for that customer | Open |
| D4 | Operations and Compliance | Creation mandates, the inputs a customer may set, initial grants, and the treatment of a pending request after authority changes. | Step 11 | Open |
| D5 | Risk and Operations | Cash eligibility evidence, the user, source, and destination mandates, the store that holds the paired posting, the hold protocol, and recovery of an uncertain transfer. | Step 12 | Open |
The definitions of D2 to D5 are in Accounts and transfers.
| SoW | Steps | Status |
|---|---|---|
| SoW: Desk management / Customer account access | 1 to 7 | Step 2 is in progress |
| SoW: Desk management / Cross-account self-trade prevention | 8 | Not started |
| SoW: Desk management / Accounts and transfers | 9 to 12 | Not started |
| SoW: Desk management / Account families | None | Not scheduled |
| SoW: Desk management / Margin groups | None | Not scheduled |