Integration models

An integration model defines who holds each end user’s WhiteBIT 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, and others connect customers who already hold personal WhiteBIT accounts. The chosen model sets the account structure, the counterparty relationship, 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 master account. WhiteBIT provides per-customer isolation, per-customer API keys, and fee-free internal transfers between the master account and the sub-accounts. WhiteBIT is the end user’s counterparty and, by default, verifies (KYC) each end user. Model A suits partners operating accounts for customers: Embedded Trading partners, Wallet-as-a-Service backends — where the model 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.

​

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. In Wallet-as-a-Service terms, Model B is attribution: the end user is a direct WhiteBIT customer, and attribution or fee-share is arranged separately. 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.

​

Comparison

​

Why not a pooled account

A single pooled (omnibus) account holding all end users’ funds together — sometimes called Model C — is not offered. Pooled custody conflicts with MiCA client-fund segregation and with Travel Rule requirements, both of which depend on funds and transfers being attributable to an identified end user. Segregated sub-accounts (Model A) and customers’ own accounts (Model B) preserve attribution, while a master account acts only as a settlement hub. Client-fund segregation also became the market baseline after the 2022 collapse of FTX, where customer funds were commingled. See Regulatory Compliance for the MiCA specifics.

​

What’s next