Nghiên cứu đã kiểm chứng nguồn: Exchange Subaccount KYC API

Decision Matrix

Source Map

• Binance Developer Docs: CAAS FAQ (binance-caas-faq)
• OKX Help: Subaccounts, Account Mode, and API Connections FAQ (okx-subaccounts-api)
• Kraken Support: API keys in Organizations (kraken-org-api-keys)
• Kraken Support: Roles, profiles, and permissions in Organizations (kraken-org-permissions)

Control Notes

1. Account object

Account object is the part of the decision where the reader must turn a public source into an operating rule. In this package, it means main account, subaccount, organization account or portfolio. The useful action is to identify the object before writing controls. The unresolved edge is hidden account hierarchy, so this article does not convert that uncertainty into a promise, ranking, reward, approval, safety claim or future-availability claim.

For an operator, account object should be recorded before funds, account access, wallet recovery, API order flow, whitelist changes, cross-chain transfers or tokenized-asset decisions become material. The record can stay simple: the official source URL, the date checked, the product or network under review, and a non-secret note describing why the next step is acceptable. Screenshots should avoid balances, identity documents, API keys, recovery phrases, private keys, passphrases, verification codes and support-ticket private data.

2. KYC gate

KYC gate is the part of the decision where the reader must turn a public source into an operating rule. In this package, it means whether verification changes feature access. The useful action is to record KYC state without personal data. The unresolved edge is manual review result, so this article does not convert that uncertainty into a promise, ranking, reward, approval, safety claim or future-availability claim.

For an operator, kyc gate should be recorded before funds, account access, wallet recovery, API order flow, whitelist changes, cross-chain transfers or tokenized-asset decisions become material.

3. Entity gate

Entity gate is the part of the decision where the reader must turn a public source into an operating rule. In this package, it means jurisdiction or venue entity behind the account. The useful action is to map route before transfer. The unresolved edge is entity migration, so this article does not convert that uncertainty into a promise, ranking, reward, approval, safety claim or future-availability claim.

For an operator, entity gate should be recorded before funds, account access, wallet recovery, API order flow, whitelist changes, cross-chain transfers or tokenized-asset decisions become material.

4. Permission class

Permission class is the part of the decision where the reader must turn a public source into an operating rule. In this package, it means read, trade, withdraw, address, transfer or admin. The useful action is to separate every class. The unresolved edge is bundled vendor permissions, so this article does not convert that uncertainty into a promise, ranking, reward, approval, safety claim or future-availability claim.

For an operator, permission class should be recorded before funds, account access, wallet recovery, API order flow, whitelist changes, cross-chain transfers or tokenized-asset decisions become material.

5. Automation boundary

Automation boundary is the part of the decision where the reader must turn a public source into an operating rule. In this package, it means whether a key completes an action or creates a request. The useful action is to test request state before scale. The unresolved edge is approval policy drift, so this article does not convert that uncertainty into a promise, ranking, reward, approval, safety claim or future-availability claim.

For an operator, automation boundary should be recorded before funds, account access, wallet recovery, API order flow, whitelist changes, cross-chain transfers or tokenized-asset decisions become material.

6. Human approval

Human approval is the part of the decision where the reader must turn a public source into an operating rule. In this package, it means whether humans must approve fund movement. The useful action is to record approver role not private identity. The unresolved edge is emergency bypass, so this article does not convert that uncertainty into a promise, ranking, reward, approval, safety claim or future-availability claim.

For an operator, human approval should be recorded before funds, account access, wallet recovery, API order flow, whitelist changes, cross-chain transfers or tokenized-asset decisions become material.

7. Secret recovery

Secret recovery is the part of the decision where the reader must turn a public source into an operating rule. In this package, it means whether key secret or passphrase can be retrieved. The useful action is to store once and rotate when lost. The unresolved edge is shared vault process, so this article does not convert that uncertainty into a promise, ranking, reward, approval, safety claim or future-availability claim.

For an operator, secret recovery should be recorded before funds, account access, wallet recovery, API order flow, whitelist changes, cross-chain transfers or tokenized-asset decisions become material.

8. IP restriction

IP restriction is the part of the decision where the reader must turn a public source into an operating rule. In this package, it means network allowlist or CIDR control. The useful action is to bind stable infrastructure IPs. The unresolved edge is mobile or dynamic IP, so this article does not convert that uncertainty into a promise, ranking, reward, approval, safety claim or future-availability claim.

For an operator, ip restriction should be recorded before funds, account access, wallet recovery, API order flow, whitelist changes, cross-chain transfers or tokenized-asset decisions become material.

9. Evidence packet

Evidence packet is the part of the decision where the reader must turn a public source into an operating rule. In this package, it means source URL, date, non-secret screenshots and config summary. The useful action is to retain proof without credentials. The unresolved edge is private account facts, so this article does not convert that uncertainty into a promise, ranking, reward, approval, safety claim or future-availability claim.

10. Stop rule

Stop rule is the part of the decision where the reader must turn a public source into an operating rule. In this package, it means when a radar claim is too broad. The useful action is to stop if one venue's model is generalized to all. The unresolved edge is future product changes, so this article does not convert that uncertainty into a promise, ranking, reward, approval, safety claim or future-availability claim.

Known Unknowns

• hidden account hierarchy
• manual review result
• entity migration
• bundled vendor permissions
• approval policy drift
• emergency bypass
• shared vault process
• mobile or dynamic IP
• private account facts
• future product changes

Practical Takeaway

The safest version of this article is the one that stays boring and exact. NexuAlpha's subaccount radar treats KYC state, API scope and governance as separate evidence fields. Binance's CAAS FAQ makes KYC and entity tagging material to deposit addresses, API-key creation, Travel Rule routing and transfers. OKX Help makes subaccount setup, account mode, API permissions, passphrase and trusted-IP restriction material to bot or external-platform use. Kraken Organizations adds a different layer: API keys are not members, governed operations create requests, keys cannot approve, and the key secret is shown once. A useful disclosure radar must therefore ask four questions for every venue: what account object is being controlled, what KYC or entity gate applies, which permission can move value, and whether automation can complete the action or only start a human-governed request. The user outcome is a clearer next inspection step, not a promise that a platform, API, transfer route or tokenized asset will work under every future condition.