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

# Embedded Trading Integration Guide

> Integration guide for WhiteBIT Embedded Trading: eligibility and approval, per-customer sub-account setup, per-customer API keys, and revenue reconciliation.

export const RegionBaseUrl = ({className = "", showBaseUrl = true, protocol = "https"}) => {
  const {useState, useEffect, useRef} = React;
  const EU_ENABLED = false;
  const [region, setRegionState] = useState(() => {
    if (!EU_ENABLED) return "com";
    if (typeof window !== 'undefined') {
      return localStorage.getItem("api-region-preference") || "com";
    }
    return "com";
  });
  const [mounted, setMounted] = useState(false);
  const observerRef = useRef(null);
  const isSyncingRef = useRef(false);
  const updateAllContentOnPage = targetRegion => {
    try {
      const domainFrom = targetRegion === "eu" ? "whitebit.com" : "whitebit.eu";
      const domainTo = targetRegion === "eu" ? "whitebit.eu" : "whitebit.com";
      const links = document.querySelectorAll('a');
      links.forEach(link => {
        let href = link.getAttribute('href');
        if (href && href.includes(domainFrom)) {
          link.setAttribute('href', href.replace(domainFrom, domainTo));
        }
      });
      const walker = document.createTreeWalker(document.body, NodeFilter.SHOW_TEXT, {
        acceptNode: node => {
          if (node.parentElement?.closest('.region-toggle-component')) {
            return NodeFilter.FILTER_REJECT;
          }
          return node.textContent.includes(domainFrom) ? NodeFilter.FILTER_ACCEPT : NodeFilter.FILTER_REJECT;
        }
      });
      let currentNode;
      while (currentNode = walker.nextNode()) {
        currentNode.textContent = currentNode.textContent.replace(new RegExp(domainFrom, 'g'), domainTo);
      }
      console.log(`[RegionSync] Global content updated to ${domainTo}`);
    } catch (e) {
      console.error("[RegionSync] Error updating content:", e);
    }
  };
  const updateRegion = (newRegion, source) => {
    if (region === newRegion) return;
    console.log(`[RegionBaseUrl] Updating to "${newRegion}" (Source: ${source})`);
    if (source === 'observer') {
      isSyncingRef.current = true;
      setTimeout(() => isSyncingRef.current = false, 1000);
    }
    setRegionState(newRegion);
    localStorage.setItem("api-region-preference", newRegion);
    updateAllContentOnPage(newRegion);
    if (source === 'user-click') {
      window.dispatchEvent(new CustomEvent("regionChange", {
        detail: newRegion
      }));
      attemptToUpdateNativeDropdown(newRegion, 0);
      setTimeout(() => attemptToUpdateNativeDropdown(newRegion, 1), 500);
      setTimeout(() => attemptToUpdateNativeDropdown(newRegion, 2), 1500);
    }
  };
  const attemptToUpdateNativeDropdown = (targetRegion, attempt) => {
    if (isSyncingRef.current) return;
    try {
      const targetUrl = targetRegion === "eu" ? "https://whitebit.eu" : "https://whitebit.com";
      const targetDesc = targetRegion === "eu" ? "EU Server" : "Production Server";
      const selects = document.querySelectorAll('select');
      for (const select of selects) {
        if (select.innerHTML.includes('whitebit.com') || select.innerHTML.includes('whitebit.eu')) {
          select.value = targetUrl;
          select.dispatchEvent(new Event('change', {
            bubbles: true
          }));
          return;
        }
      }
      const buttons = Array.from(document.querySelectorAll('button, [role="combobox"]'));
      const serverSelector = buttons.find(btn => {
        if (btn.closest('a') || btn.closest('[class*="card"]') || btn.closest('nav')) {
          return false;
        }
        const txt = btn.textContent || "";
        const isServerDropdown = (txt.includes('Production Server') || txt.includes('EU Server') || txt.includes('WhiteBIT Global Server') || txt.includes('WhiteBIT EU Server')) && !txt.includes('Run') && !txt.includes('Send') || btn.getAttribute('role') === 'combobox';
        return isServerDropdown;
      });
      if (serverSelector) {
        const currentText = serverSelector.textContent || "";
        if (currentText.includes(targetDesc)) return;
        serverSelector.click();
        setTimeout(() => {
          const options = document.querySelectorAll('[role="option"], li, button');
          for (const opt of options) {
            const optText = opt.textContent || "";
            if (optText.includes(targetDesc) || optText.includes(targetUrl)) {
              opt.click();
              return;
            }
          }
        }, 100);
      }
    } catch (e) {
      console.error("[Sync] Error:", e);
    }
  };
  useEffect(() => {
    if (!EU_ENABLED) return;
    setMounted(true);
    updateAllContentOnPage(region);
    const handleStorageChange = e => {
      if (e.key === "api-region-preference" && e.newValue) {
        updateRegion(e.newValue, 'storage');
      }
    };
    const handleRegionChange = e => {
      if (e.detail !== region) {
        updateRegion(e.detail, 'event');
      }
    };
    window.addEventListener("storage", handleStorageChange);
    window.addEventListener("regionChange", handleRegionChange);
    observerRef.current = new MutationObserver(mutations => {
      if (isSyncingRef.current) return;
      updateAllContentOnPage(region);
      for (const mutation of mutations) {
        if (mutation.type !== 'childList' && mutation.type !== 'characterData') continue;
        const target = mutation.target;
        const el = target.nodeType === Node.TEXT_NODE ? target.parentElement : target;
        if (el && (el.getAttribute('role') === 'option' || el.closest('[role="listbox"]'))) continue;
        const text = target.textContent || "";
        if (text.includes('WhiteBIT EU Server') || text.includes('https://whitebit.eu') && text.includes('Server')) {
          if (el && el.tagName !== 'A' && !el.closest('.region-toggle-component')) {
            if (region !== 'eu') updateRegion('eu', 'observer');
          }
        } else if (text.includes('WhiteBIT Global Server') || text.includes('https://whitebit.com') && text.includes('Server')) {
          if (el && el.tagName !== 'A' && !el.closest('.region-toggle-component')) {
            if (region !== 'com') updateRegion('com', 'observer');
          }
        }
      }
    });
    observerRef.current.observe(document.body, {
      childList: true,
      subtree: true,
      characterData: true
    });
    if (typeof window !== 'undefined') {
      const current = localStorage.getItem("api-region-preference");
      if (current) attemptToUpdateNativeDropdown(current, 'init');
    }
    return () => {
      window.removeEventListener("storage", handleStorageChange);
      window.removeEventListener("regionChange", handleRegionChange);
      if (observerRef.current) observerRef.current.disconnect();
    };
  }, [region]);
  const apiBaseUrl = protocol === "wss" ? region === "eu" ? "wss://api.whitebit.eu/ws" : "wss://api.whitebit.com/ws" : region === "eu" ? "https://whitebit.eu" : "https://whitebit.com";
  const baseUrlLabel = protocol === "wss" ? "WebSocket URL" : "Base URL";
  if (!EU_ENABLED) {
    if (!showBaseUrl) return null;
    return <div className={`flex items-center gap-2 flex-wrap my-4 region-toggle-component ${className}`}>
                <span className="text-sm text-gray-500 dark:text-gray-400 font-mono">
                    {baseUrlLabel}
                </span>
                <span className="text-sm text-gray-400">:</span>
                {protocol === "wss" ? <code className="text-sm font-mono text-primary dark:text-primary-light">
                        {apiBaseUrl}
                    </code> : <a href={apiBaseUrl} target="_blank" rel="noopener noreferrer" className="text-sm font-mono text-primary dark:text-primary-light hover:underline">
                        {apiBaseUrl}
                    </a>}
            </div>;
  }
  if (!mounted) return null;
  return <div className={`flex items-center gap-2 flex-wrap my-4 region-toggle-component ${className}`}>
            <span className="text-sm text-gray-500 dark:text-gray-400 font-mono">
                {baseUrlLabel}
            </span>
            <span className="text-sm text-gray-400">(</span>
            <div className="inline-flex bg-gray-100 dark:bg-gray-800 rounded-lg p-0.5 border border-gray-200 dark:border-gray-700">
                <button onClick={() => updateRegion("com", "user-click")} className={`px-2 py-0.5 text-xs font-medium rounded-md transition-all ${region === "com" ? "bg-white dark:bg-gray-700 text-gray-900 dark:text-gray-100 shadow-sm" : "text-gray-500 dark:text-gray-400 hover:text-gray-900 dark:hover:text-gray-200"}`}>
                    .com
                </button>
                <button onClick={() => updateRegion("eu", "user-click")} className={`px-2 py-0.5 text-xs font-medium rounded-md transition-all ${region === "eu" ? "bg-white dark:bg-gray-700 text-gray-900 dark:text-gray-100 shadow-sm" : "text-gray-500 dark:text-gray-400 hover:text-gray-900 dark:hover:text-gray-200"}`}>
                    .eu
                </button>
            </div>
            <span className="text-sm text-gray-400">)</span>
            {showBaseUrl && <>
                    <span className="text-sm text-gray-400">:</span>
                    {protocol === "wss" ? <code className="text-sm font-mono text-primary dark:text-primary-light">
                            {apiBaseUrl}
                        </code> : <a href={apiBaseUrl} target="_blank" rel="noopener noreferrer" className="text-sm font-mono text-primary dark:text-primary-light hover:underline">
                            {apiBaseUrl}
                        </a>}
                </>}
        </div>;
};

<RegionBaseUrl />

WhiteBIT Embedded Trading serves partners that operate a dedicated [sub-account](/glossary#sub-account) for each end customer under a partner master account. The program provides per-customer account isolation, per-customer API keys, fee-free internal transfers between the master account and sub-accounts, and a revenue share of up to **40%** of the trading fees generated by referred customers.

Embedded Trading is one of several integration paths. Other partner types route to separate guides:

* End customers keep personal WhiteBIT accounts and the partner holds a user-scoped API key (trading bots, [copy trading](/guides/copy-trading), portfolio apps) — see [Fast API Key via OAuth](/guides/fast-api-key-integration).
* The choice between backend models (managed sub-accounts, attribution, KYC reliance) is still open — see [Wallet-as-a-Service](/guides/waas-overview).
* The integration centers on deposits, withdrawals, payouts, or merchant flows — see [Payment Integration](/guides/payment-integration). Corporate fiat ↔ crypto conversion on the partner's own account is covered by the [On/Off-Ramp Guide](/guides/on-off-ramp-integration).
* For the full partner-type map, see [Partner Solutions](/guides/partner-solutions).

## Prerequisites

Before building the sub-account integration:

* **Approved Embedded Trading enrollment** — the program is approval-gated (see [Eligibility and approval](#eligibility-and-approval)); apply via `institutional@whitebit.com`.
* **Master-account KYB** — completed through [Institutional Onboarding](/institutional/onboarding).
* **API access** — [HMAC-signed requests](/api-reference/authentication) on the master account; store the secret per [Security Best Practices](/best-practices/security).
* **Model fit** — this is Model A (partner-operated sub-accounts); confirm against the [integration models](/concepts/integration-models) concept.

## Eligibility and approval

Embedded Trading enrollment is approval-gated. Every application is individually reviewed before sub-account provisioning is enabled.

**How to apply:** email `institutional@whitebit.com` with a description of the service. Include the registered legal entity (name, registration number, jurisdiction), licenses or registrations held (with the regulator and register reference), the intended account structure, who performs end-customer KYC, crypto-only or fiat scope, and the countries where the service is offered or marketed. The full application question list is on the [Partner Solutions](/guides/partner-solutions#how-to-apply) page. Master-account KYB via [Institutional Onboarding](/institutional/onboarding) is part of enrollment.

<Note>
  The end-customer KYC verification flow is WhiteBIT-branded and cannot be white-labeled.
</Note>

**KYC reliance eligibility:**

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.

Partners without a qualifying license integrate on the standard track: WhiteBIT verifies each end customer directly through the WhiteBIT-branded KYC flow described below.

## Program terms

The revenue share is up to **40%** of the trading fees generated by referred customers. Whether the share covers spot trading fees only or extends to other products is part of the commercial terms; the reconciliation walkthrough below computes on spot executed-history. The applicable rate and any additional commercial terms are agreed individually during enrollment; the canonical program terms are published on the [Embedded Trading program page](https://institutional.whitebit.com/broker-program).
&#x20;Joint marketing activities — social media co-posts, blog posts, targeted email newsletters, AMA sessions, and trading competitions — are scheduled with WhiteBIT during onboarding.

Referral-based earning without operating customer accounts is covered by the separate WhiteBIT Affiliate Program, which has its own terms.

## Account architecture

Each end customer trades from a dedicated sub-account under the partner's master account:

* **Independent balances**, scoped at creation via `permissions.spotEnabled` and `permissions.collateralEnabled`. Trades on one sub-account do not affect another.
* **Up to 50 API keys per sub-account**, independent from the main account and from other sub-accounts, each with an IP whitelist and permission scope.
* **Sub-account count per master** — the number of sub-accounts a master account can create is not a fixed published limit; confirm the ceiling that applies to the account with WhiteBIT during enrollment.

- **Withdrawal control at the master account** — sub-account withdrawals surface on the master account for confirmation via the [unconfirmed-withdrawals list](/api-reference/sub-accounts/list-unconfirmed-sub-account-withdrawals) and [confirm](/api-reference/sub-accounts/confirm-sub-account-withdrawal) endpoints. The sub-account withdrawal endpoints are not available by default — request access via `institutional@whitebit.com`; a `404` response indicates the endpoints are not yet enabled for the account.
- **Crypto deposits are disabled by default.** Once deposits are enabled for the account (request via the assigned account manager or `institutional@whitebit.com`), the capability applies to the account and its sub-accounts; a sub-account then generates deposit addresses through the standard [deposit address endpoint](/api-reference/account-wallet/get-cryptocurrency-deposit-address) using its own API key with deposit permission.

**Endpoint map:**

| Operation       | Endpoint                                                                                       | Reference                                                                                                           |
| --------------- | ---------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------- |
| Create          | `POST /api/v4/sub-account/create`                                                              | [Create Sub-Account](/api-reference/sub-accounts/create-sub-account)                                                |
| Edit            | `POST /api/v4/sub-account/edit`                                                                | [Edit Sub-Account](/api-reference/sub-accounts/edit-sub-account)                                                    |
| Delete          | `POST /api/v4/sub-account/delete`                                                              | [Delete Sub-Account](/api-reference/sub-accounts/delete-sub-account)                                                |
| List            | `POST /api/v4/sub-account/list`                                                                | [List of Sub-Accounts](/api-reference/sub-accounts/list-of-sub-accounts)                                            |
| Block / Unblock | `POST /api/v4/sub-account/block` · `/unblock`                                                  | [Block](/api-reference/sub-accounts/block-sub-account) · [Unblock](/api-reference/sub-accounts/unblock-sub-account) |
| Transfer        | `POST /api/v4/sub-account/transfer`                                                            | [Sub-Account Transfer](/api-reference/sub-accounts/sub-account-transfer)                                            |
| Balances        | `POST /api/v4/sub-account/balances`                                                            | [Sub-Account Balances](/api-reference/sub-accounts/sub-account-balances)                                            |
| KYC URL         | `POST /api/v4/sub-account/kyc-url`                                                             | [Get Sub-Account KYC URL](/api-reference/sub-accounts/kyc-url)                                                      |
| API keys        | `POST /api/v4/sub-account/api-key/create` (+ edit, delete, list, reset, IP-address management) | [Create Sub-Account API Key](/api-reference/sub-accounts/create-sub-account-api-key)                                |

The sub-account endpoints in the table above share a rate limit of 1000 requests per 10 seconds; `POST /api/v4/trade-account/executed-history` allows 12000 requests per 10 seconds — see [Rate limits](/api-reference/rate-limits).

Transfers between the master account and any sub-account are fee-free in both directions — master-to-sub for funding a customer account, sub-to-master for revenue collection. See the [Sub-Accounts Overview](/products/sub-accounts/overview) for the full product reference.

## Customer onboarding flow

The KYC branch is selected at creation via the `shareKyc` parameter: with `shareKyc: true` the sub-account shares the master account's verification and no separate customer KYC applies; with `shareKyc: false` (or omitted) the `email` field is required and the end customer completes verification individually.

<Note>
  Steps 2–3 apply to the dedicated-KYC branch (`shareKyc: false` or omitted). With `shareKyc: true`, the sub-account shares the master account's verification — skip directly to Step 4 (Fund the account and enable trading) once the sub-account is created.
</Note>

<Steps>
  <Step title="Create the sub-account">
    Call `POST /api/v4/sub-account/create` with `alias` and the `permissions` object (`spotEnabled`, `collateralEnabled`), plus `email` when `shareKyc` is `false` or omitted — [API Reference](/api-reference/sub-accounts/create-sub-account).
  </Step>

  <Step title="Wait for activation (dedicated-KYC branch)">
    A KYC URL can be generated only for a sub-account that is activated (has an associated user), active, and does not use shared KYC. Poll `POST /api/v4/sub-account/list` and read the `status` and `userId` fields for the new sub-account — [API Reference](/api-reference/sub-accounts/list-of-sub-accounts). Calling `kyc-url` before activation returns `400 "Account is not confirmed"`.
  </Step>

  <Step title="Generate the KYC URL and pass it to the customer">
    Call `POST /api/v4/sub-account/kyc-url` with the sub-account `id` — [API Reference](/api-reference/sub-accounts/kyc-url). The end customer opens the temporary link and completes the WhiteBIT-branded identity verification. Track the sub-account state via the list endpoint.
  </Step>

  <Step title="Fund the account and enable trading">
    Transfer initial funds fee-free via `POST /api/v4/sub-account/transfer`, and create a dedicated API key via `POST /api/v4/sub-account/api-key/create` for customers needing direct API access.
  </Step>

  <Step title="Handle deposits and withdrawals">
    Once crypto deposits are enabled for the account, the sub-account generates its own deposit address via the [deposit address endpoint](/api-reference/account-wallet/get-cryptocurrency-deposit-address) using its own API key with deposit permission. Sub-account withdrawals require master-account confirmation — see [Account architecture](#account-architecture) above for the unconfirmed-withdrawals list and confirm endpoints.
  </Step>
</Steps>

Critical-path call — create a sub-account with dedicated KYC:

<Tabs>
  <Tab title="curl">
    ```bash theme={"theme":{"light":"github-light","dark":"github-dark"}}
    curl -X POST "https://whitebit.com/api/v4/sub-account/create" \
      -H "Content-Type: application/json" \
      -H "X-TXC-APIKEY: YOUR_API_KEY" \
      -H "X-TXC-PAYLOAD: YOUR_PAYLOAD" \
      -H "X-TXC-SIGNATURE: YOUR_SIGNATURE" \
      -d '{
        "alias": "customer-001",
        "email": "customer@example.com",
        "shareKyc": false,
        "permissions": {"spotEnabled": true, "collateralEnabled": false},
        "request": "/api/v4/sub-account/create",
        "nonce": 1594297865000
      }'
    ```
  </Tab>

  <Tab title="Python">
    ```python theme={"theme":{"light":"github-light","dark":"github-dark"}}
    import base64, hashlib, hmac, json, time, requests

    API_KEY, API_SECRET = "YOUR_API_KEY", "YOUR_SECRET"
    endpoint = "/api/v4/sub-account/create"
    body = json.dumps({
        "alias": "customer-001",
        "email": "customer@example.com",
        "shareKyc": False,
        "permissions": {"spotEnabled": True, "collateralEnabled": False},
        "request": endpoint,
        "nonce": int(time.time() * 1000),
    })
    payload = base64.b64encode(body.encode()).decode()
    signature = hmac.new(API_SECRET.encode(), payload.encode(), hashlib.sha512).hexdigest()
    response = requests.post(
        "https://whitebit.com" + endpoint,
        headers={"Content-Type": "application/json", "X-TXC-APIKEY": API_KEY,
                 "X-TXC-PAYLOAD": payload, "X-TXC-SIGNATURE": signature},
        data=body,
    )
    print(response.json())  # id, alias, userId, email, status
    ```
  </Tab>
</Tabs>

For Go and PHP examples, see [SDKs](/sdks). The signing process is documented in [Private HTTP API authentication](/api-reference/authentication).

## Per-customer API keys

Each sub-account supports up to **50 API keys**, managed via the [sub-account API key endpoints](/api-reference/sub-accounts/create-sub-account-api-key) (create, edit, delete, list, reset) with dedicated [IP-address management](/api-reference/sub-accounts/create-sub-account-api-key-ip-address).

* Assign the minimum permission set per key (`Info + Trading` for trading-only customers; deposit and withdrawal permissions only where funds movement is required) — see [Security Best Practices](/best-practices/security) for the permission model and key-handling rules.
* Configure the IP whitelist per key to match the customer's infrastructure.

<Warning>
  Create separate API keys for each customer sub-account. Never share the master account's API keys with customers.
</Warning>

For structured order tracking across customer sub-accounts, use `clientOrderId` naming conventions — see [Client Order ID: account-operator implementation](/guides/client-order-id#example-account-operator-implementation).

## Revenue monitoring

Embedded Trading does not expose a dedicated fee-share endpoint. Earnings are reported through the WhiteBIT [Analytical Dashboard](https://help.whitebit.com/hc/en-gb/articles/19885341884573-How-to-Use-WhiteBIT-Analytical-Dashboard), which tracks referral statistics and trading volumes. Payout mechanics and settlement schedule are agreed during enrollment.

**Programmatic reconciliation:**

1. List sub-accounts via `POST /api/v4/sub-account/list`.
2. For each sub-account, query trade history via `POST /api/v4/trade-account/executed-history` using the sub-account's own API key — [API Reference](/api-reference/spot-trading/query-executed-order-history).
3. For each executed deal, multiply the fee charged by the agreed fee-share percentage.
4. Sum across all sub-accounts to produce earnings for the reporting window.

Reconcile the locally computed totals against the dashboard for each settlement period, and track per-customer volume separately for per-customer reconciliation.

## Fiat operations

Fiat deposits and withdrawals (EUR/SEPA) operate at the partner's master-account level and require institutional fiat access — the second phase of [Institutional Onboarding](/institutional/onboarding), completed through a fiat processing partner review. Sub-accounts support crypto operations; sub-account balances are funded and collected through fee-free internal transfers with the master account. See [Payment Integration](/guides/payment-integration) for fiat endpoint details.

## Testing

WhiteBIT has no public testnet or sandbox. Validate the full flow — sub-account creation, KYC, per-customer keys, funding, and a first trade — on the live API using a test sub-account and minimum order sizes. Activate Demo Tokens (`DBTC`/`DUSDT`) for risk-free spot practice on the `DBTC_DUSDT` pair, and check per-asset minimums via the [Asset Status](/api-reference/market-data/asset-status-list) endpoint before placing orders. Sub-account creation, KYC, fee-free transfers, and revenue reconciliation can all be exercised on this test cohort before real customers are onboarded. Work through the [Go-Live Checklist](/best-practices/go-live-checklist) first.

## Integration checklist

* [ ] **Application** — application sent to `institutional@whitebit.com` with the [intake details](/guides/partner-solutions#how-to-apply) and approved.
* [ ] **Master account KYB** — KYB verification completed for the partner entity.
* [ ] **Master API key** — master account API key created with appropriate permissions.
* [ ] **Sub-account creation** — test sub-account created with the intended `permissions` scope and KYC branch.
* [ ] **Activation and KYC** — sub-account activation observed via `sub-account/list`; KYC URL generated and completed (dedicated-KYC branch).
* [ ] **Deposit enablement** (if per-customer deposits apply) — crypto-deposit enablement requested via the account manager or `institutional@whitebit.com`.
* [ ] **Fund transfer** — fee-free transfer between master and sub-account verified in both directions.
* [ ] **Per-customer API key** — API key created for a sub-account with IP whitelist configured.
* [ ] **Balance monitoring** — `sub-account/balances` query working across all sub-accounts.
* [ ] **Revenue reconciliation** — per-sub-account trade-history collection and fee-share computation in place.
* [ ] **Fiat access** (if applicable) — institutional onboarding Phase 2 completed for SEPA access on the master account.
* [ ] **Security review** — IP whitelists, key permissions, and secret storage reviewed per [Security Best Practices](/best-practices/security).
* [ ] **Go-live review** — all items on the [Go-Live Checklist](/best-practices/go-live-checklist) verified.

## What's next

<CardGroup cols={3}>
  <Card title="Sub-Accounts" icon="users" href="/products/sub-accounts/overview">
    Sub-account isolation model, transfer mechanics, and per-key permission scopes.
  </Card>

  <Card title="Institutional Onboarding" icon="building" href="/institutional/onboarding">
    Step-by-step KYB and fiat onboarding process.
  </Card>

  <Card title="Go-Live Checklist" icon="clipboard-check" href="/best-practices/go-live-checklist">
    Pre-production readiness verification.
  </Card>
</CardGroup>