> ## Documentation Index
> Fetch the complete documentation index at: https://docs.whitebit.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Wallet-as-a-Service

> Put WhiteBIT behind a partner's product as the exchange, custody, and settlement backend. What WaaS provides, the integration models, and how to get started.

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](/guides/waas-integration).

<Tip>
  Adding wallets and payouts to an existing product fits WaaS. Launching a full branded exchange
  instead fits [Crypto-as-a-Service](/guides/caas-overview), which composes the WaaS wallet
  building block for its end-customer wallets.
</Tip>

<Tip>
  The [WaaS Recipes](/guides/waas-recipes) show runnable examples of deposit addresses,
  reconciliation, payouts, and settlement.
</Tip>

## 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

<CardGroup cols={2}>
  <Card title="Managed sub-accounts" icon="sitemap">
    Each end user gets a sub-account under the partner's master account. **WhiteBIT verifies (KYC)
    each user** and is the user's counterparty.
  </Card>

  <Card title="Attribution" icon="tag">
    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.
  </Card>

  <Card title="Sub-accounts with KYC reliance" icon="handshake" href="/guides/waas-integration#kyc-reliance-eligibility">
    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.
  </Card>
</CardGroup>

<Note>
  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.
</Note>

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](/concepts/travel-rule).
* **MiCA (EEA):** some stablecoin operations are restricted for EEA users, which affects the
  assets available to those users. See [Regulatory Compliance](/institutional/compliance).

## How to apply

1. Complete KYB as part of [Institutional Onboarding](/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](mailto:institutional@whitebit.com).
4. Work through the [Go-Live Checklist](/best-practices/go-live-checklist) before real volume.

To get started or discuss a model, contact [institutional@whitebit.com](mailto:institutional@whitebit.com) or the account manager.

## What's next

<CardGroup cols={2}>
  <Card title="Developer guide" icon="code" href="/guides/waas-integration">
    The technical integration: models, payment flows, compliance, and testing.
  </Card>

  <Card title="WaaS Recipes" icon="sparkles" href="/guides/waas-recipes">
    Runnable examples with a starter repo.
  </Card>

  <Card title="FAQ" icon="circle-question" href="/guides/waas-faq">
    Scope, integration models, onboarding, and compliance questions.
  </Card>
</CardGroup>