Wallet-as-a-Service

Wallet-as-a-Service (WaaS) gives each of a partner’s end users a sub-account under the partner’s main account, and the partner builds a wallet product on these sub-accounts. This overview covers fit and the verification variants. For the technical integration, see the Developer guide.

​

What WaaS provides

• A sub-account per end user, with independent balances and API keys.
• A crypto deposit address for each sub-account, once the account manager enables crypto deposits to sub-accounts for the account.
• Crypto withdrawals from each sub-account, each approved by the main account through sub-account withdrawal approval.
• Conversion with Convert on each sub-account.
• Spot trading, including market orders, on every sub-account with no enablement request to the account manager; the partner controls trading through the sub-account’s spot permission (see Account architecture).
• Fee-free transfers between the main account and each sub-account.
• Fiat payouts from the main account.

​

Architecture

Each end user gets a sub-account under the partner’s main account, with its own balances, API key, and deposit addresses. The partner’s backend signs the main account’s requests with the main-account key and each sub-account’s requests with that sub-account’s own key.

​

Choose a verification variant

The three variants share one sub-account architecture and differ in who verifies the end users. With managed sub-accounts, WhiteBIT verifies each end user. With KYC reliance, the partner verifies, and WhiteBIT relies on that verification under an agreement. With shared-KYC sub-accounts, each sub-account carries the main account’s verification: WhiteBIT verifies the partner during institutional onboarding (KYB), and the partner verifies its own end users. The final choice and any compliance gate are confirmed with WhiteBIT. For end users with personal WhiteBIT accounts, the partner integrates through App Builders instead. A partner that keeps each end user’s balance in the partner’s own ledger, with one WhiteBIT account and a deposit address per end user, uses Crypto-as-a-Service; see Partner Solutions. Integration models compares sub-accounts with the partner’s own account and with customers’ own accounts. KYC reliance — WhiteBIT relying on the partner’s own customer verification — may be available, but is not enabled by default. It is never automatic, and operates as a delegation: responsibility for customer verification is never transferred. Eligibility is assessed case by case. Reliance is available only to partners that are supervised AML-obligated entities (for example EMI, PI, VASP, or MiCA-CASP license holders) in an adequate jurisdiction, applying broadly equivalent customer due diligence, under a written agreement and an individual WhiteBIT Compliance assessment. A confirmed entry on the relevant public register establishes the licensing basis; a confirmed EU/MiCA entity is additionally required when EU users are in scope. Licensing regimes and entity structures vary, and the examples above may not capture every case. Describe your licence(s), jurisdiction, and customer due-diligence approach in full in your application so the WhiteBIT Compliance team can review your specific situation and make a determination.

​

Program terms

Pricing is agreed per contract during onboarding — negotiated per partner rather than a published rate card, and distinct from Embedded Trading’s revenue-share model. WaaS uses bundled pricing with no per-stage charges. Eligibility for the gated KYC-reliance variant is assessed case by case per the conditions above.

​

Compliance at a glance

• Travel Rule (EEA and Turkey): transfers must carry sender/recipient data. Inbound deposits for EEA/Turkey accounts are held until verification completes; withdrawals carry a travel-rule payload. See Travel Rule.
• MiCA (EEA): some stablecoin operations are restricted for EEA users, which affects the assets available to those users. See Regulatory Compliance.

​

How to apply

1. Complete KYB as part of Institutional Onboarding. Fiat access is a separate second phase, not automatic after KYB.
2. Create API keys and configure webhooks in the WhiteBIT dashboard.
3. Request the enablements the product needs through the account manager — sub-accounts, crypto deposits to sub-accounts, and the sub-account withdrawal endpoints. See Sub-Accounts.
4. Work through the Go-Live Checklist before real volume.

To get started or discuss a verification variant, contact institutional@whitebit.com or the account manager.

​

What’s next