Integration models

An integration model defines which account holds end users’ funds — a sub-account the partner operates, the end user’s own WhiteBIT account, or the partner’s own account — and who performs end-user identity verification (KYC). WhiteBIT partner programs offer more than one model because partners differ: some operate accounts on behalf of customers, others connect customers who already hold personal WhiteBIT accounts, and others keep end users on the partner’s own books. The chosen model sets the account structure and where compliance responsibility sits. Program overviews and integration guides link to the models below rather than restating the trade-off.

​

Model A — partner-operated sub-accounts

Model A places each end user in a dedicated sub-account under the partner’s main account. WhiteBIT provides per-customer isolation, per-customer API keys, and fee-free internal transfers between the main account and the sub-accounts. By default, WhiteBIT verifies (KYC) each end user. Model A suits partners operating accounts for customers: Embedded Trading partners, Wallet-as-a-Service partners — where the default-KYC variant is called managed sub-accounts — and platforms managing customer funds. A gated variant, KYC reliance, lets an eligible partner perform end-user verification instead, subject to a WhiteBIT Compliance assessment. The eligibility conditions are documented on the Embedded Trading overview and the WaaS overview. Build Model A with Sub-Accounts; the Embedded Trading integration guide covers per-customer setup end to end. A third variant, shared-KYC sub-accounts, creates each sub-account with the main account’s verification. WhiteBIT verifies the partner (KYB) and does not verify the end users; the partner verifies its end users, as on the partner’s own account, and still gets a separate WhiteBIT balance per end user.

​

Model B — customers’ own accounts (Fast API Key)

Model B connects end users who each hold a personal WhiteBIT account. WhiteBIT holds custody and performs KYC. The partner acts on the account through an OAuth-issued API key granted by the user on the WhiteBIT consent screen — see Fast API Key via OAuth for the flow and OAuth 2.0 for the concept. The user selects the key’s permission scope, so partner access is bounded by the granted permissions. Attribution and any fee-share are arranged separately from the account relationship. Model B fits more partner types than embedded trading alone — a long tail of applications where the end user keeps a personal account. Model B partner types group by the permission scope required:

• Read-only — portfolio trackers and aggregators, tax and accounting tools, and referral apps reading a user’s own activity. No fund movement.
• Trade-execute — trading bots and signal execution, copy and social trading, charting and analytics with on-chart execution, algorithmic and quant platforms, and education platforms with in-app execution. Order placement only; withdrawal remains a separate, user-controlled grant.

Compliance review scales with the permission scope, not the partner label.

​

Partner’s own account

In this model the end users hold no WhiteBIT account and no sub-account. The partner holds one WhiteBIT account and issues a deposit address per end user with Create new address for deposit. The partner maps each address — plus its memo on memo networks — to the end user in its own database, keeps the end-user ledger, credits each end user from deposit events reconciled against the account history, and pays out from the account (see Unique address per user). The partner verifies its own end users; WhiteBIT verifies the partner during institutional onboarding. In the European Union, a separate onboarding process and separate rules apply. The trade-off: holds and the withdrawable balance are reported for the whole account, not for each end user (see Withdrawable balance), so per-end-user balances exist only in the partner’s ledger, and reconciling that ledger against the account history is the partner’s task. The model suits a bank, fintech, or other business that offers crypto to its own end users under its own brand. Build it with the Crypto-as-a-Service integration guide.

​

Comparison

​

Sub-accounts or the partner’s own account

Both Model A and the partner’s own account suit a business that offers crypto to its own end users. The deciding question is which side keeps each end user’s balance: WhiteBIT, on a sub-account, or the partner, in its own ledger.

• Balance per end user. Model A keeps and reports a separate balance for each sub-account. Moving value to or from an end user is a fee-free transfer between the main account and the sub-account, one API call per operation. On the partner’s own account, the same step is an entry in the partner’s ledger with no WhiteBIT call, and WhiteBIT reports one balance for the whole account.
• Keys and addresses. Model A needs an API key per sub-account for deposits, and each sub-account keeps one address per currency and network. On the partner’s own account, the partner uses its own keys and gets a new address on every successful call, within a per-currency address limit.
• Verification. In Model A, WhiteBIT verifies each end user by default through a WhiteBIT-branded flow; KYC reliance is a gated variant, and with shared-KYC sub-accounts WhiteBIT verifies only the partner. On the partner’s own account, the partner verifies its end users, and WhiteBIT verifies the partner.
• Controls per end user. Model A lets the partner block a sub-account, set its trading permission, and approve each sub-account withdrawal from the main account. On the partner’s own account, these controls sit in the partner’s own systems, and payouts leave from the one account.

​

What’s next