Skip to main content
Wallet-as-a-Service (WaaS) lets a partner put WhiteBIT behind its own product as the exchange, custody, and settlement backend. This overview covers fit and model selection. For the technical integration, see the Developer guide.
Adding wallets and payouts to an existing product fits WaaS. Launching a full branded exchange instead fits Crypto-as-a-Service, which composes the WaaS wallet building block for its end-customer wallets.
The WaaS Recipes show runnable examples of deposit addresses, reconciliation, payouts, and settlement.

​
What WaaS provides

  • A unique crypto deposit address per end user, with incoming funds reconciled by webhook.
  • Crypto and fiat payouts, including withdrawal with on-the-fly currency conversion.
  • Fee-free settlement between accounts with WhiteBIT Codes, or one-tap charges with Express Withdraw.
  • Fireblocks connectivity and built-in AML controls on deposit and withdrawal flows.

​
Choose an integration model

Managed sub-accounts

Each end user gets a sub-account under the partner’s master account. WhiteBIT verifies (KYC) each user and is the user’s counterparty.

Attribution

Each end user opens a separate WhiteBIT account; the partner connects via an OAuth-issued key. WhiteBIT does the KYC. Attribution / fee-share is arranged separately.

Sub-accounts with KYC reliance

Managed sub-accounts, but WhiteBIT relies on the partner’s KYC of the end user. Requires a compliance assessment and agreement — see the eligibility conditions.
A single pooled (omnibus) account for all users is not offered: pooled custody conflicts with MiCA client-fund segregation and Travel Rule requirements. Each model above keeps segregated sub-accounts, with a master account acting only as a settlement hub.
Two questions place a partner: (1) does the end user hold a separate WhiteBIT account, or does the partner manage accounts on the end user’s behalf? (2) who runs KYC, WhiteBIT or the partner? The practical difference between the two sub-account models is who verifies the end users: with managed sub-accounts WhiteBIT does; with KYC reliance the partner does. The final choice and any compliance gate are confirmed with WhiteBIT. 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 enablement the model needs (sub-account and crypto-deposit enablement, per-user deposit addresses) via the account manager or institutional@whitebit.com.
  4. Work through the Go-Live Checklist before real volume.
To get started or discuss a model, contact institutional@whitebit.com or the account manager.

​
What’s next

Developer guide

The technical integration: models, payment flows, compliance, and testing.

WaaS Recipes

Runnable examples with a starter repo.

FAQ

Scope, integration models, onboarding, and compliance questions.