Launch an enterprise white-label crypto exchange with institutional liquidity and 200k TPS.

A white-label exchange is not a reskinnable script — it is a multi-tenant platform where each tenant believes they are operating their own exchange.

White-label crypto exchanges have a specific architecture requirement: multi-tenancy. Each IB or regional operator gets their own branded interface, their own user base, their own fee configuration and their own commission structure — but they all run on shared matching engine infrastructure and liquidity. The technical challenge is isolation: tenant A cannot see tenant B users, orders, or financial data — but they share the same order books, the same wallet infrastructure, and the same liquidity providers. PROPELOO designs white-label exchanges with proper tenant isolation at every layer: data segregation, branded front-ends served from custom domains, per-tenant fee and spread configuration, IB commission accounting that settles correctly across shared liquidity, and a superadmin panel that gives the platform operator visibility across all tenants.

What a white-label exchange platform contains.

Multi-tenant infrastructure with the appearance of dedicated instances.

System Layers

• Multi-Tenant Core: Tenant provisioning, data isolation, shared vs isolated configuration per module, tenant lifecycle management
• Trading Infrastructure: Shared matching engine with per-tenant order book views, or isolated order books per tenant, liquidity routing
• Branding & Configuration: Custom domain per tenant, logo/colour theme configuration, trading pair selection, fee schedule configuration
• IB & Commission Engine: Multi-tier IB structure, commission on spread/volume, real-time commission accrual, monthly settlement
• Superadmin Panel: Tenant management, global liquidity management, cross-tenant reporting, fee override, KYC provider configuration

Core Technical Capabilities

• Multi-Tenant Architecture

  Row-level security or schema-per-tenant data isolation. Shared infrastructure (matching engine, blockchain nodes) with logical tenant boundaries. New tenant provisioning via admin API — no code deployment required for new tenant onboarding.

• Tenant Branding & Config

  Custom domain via DNS CNAME, per-tenant logo and brand colours applied via theme engine, trading pair selection, fee schedule, spread markup over base liquidity, language/locale configuration.

• IB Commission Engine

  Multi-tier IB structure (master IB → sub-IB → client). Commission calculated on volume, spread markup, or trading fee. Real-time accrual, monthly settlement, IB portal for commission reporting.

• Liquidity Architecture

  Option 1: Shared order books — all tenants trade against the same order book. Option 2: Isolated order books with shared LP liquidity seeding. Option 3: Per-tenant LP connections for fully independent liquidity.

• Superadmin Panel

  Global view: all tenants, all users (anonymised per tenant), total volume, total commission, LP exposure. Tenant management: suspend, configure, view metrics. KYC override for compliance-flagged users.

• Wallet & Custody

  Shared blockchain nodes with per-tenant wallet namespacing. User funds isolated per tenant with clear attribution. Hot/cold split managed at platform level.

How we approach white-label exchange architecture.

The hardest problem in white-label platforms is isolation — making shared infrastructure behave as if it were dedicated.

• Isolation must be enforced at the data layer, not just the API

  An API that correctly filters tenant data can still have a bug that leaks cross-tenant data. Row-level security at the database layer enforces isolation independently of the application — a query from tenant A context physically cannot return tenant B rows. This defence-in-depth approach prevents the most dangerous class of multi-tenancy failures.

  Axiom: DATABASE-LEVEL ISOLATION

• Commission settlement must be exact, not approximate

  IB commission disputes destroy partnerships. The commission engine must track every trade, every fee, and every rebate from the moment it accrues — not reconstruct it from logs at settlement time. Event-sourced commission accounting with real-time IB portal visibility eliminates disputes.

  Axiom: REAL-TIME COMMISSION ACCRUAL

• New tenant onboarding must not require an engineering deploy

  A white-label platform that requires a code deployment for each new tenant does not scale. Tenant provisioning — custom domain, branding, fee configuration, trading pairs — must be entirely configuration-driven via the superadmin API.

  Axiom: ZERO-DEPLOY TENANT ONBOARDING

Key decisions in white-label exchange architecture.

These choices define scalability, isolation strength and operational complexity.

• Shared order books vs isolated order books?

  Impact: Shared order book with per-tenant spread markup is the standard for most white-label exchange operators. Isolated order books are only appropriate when tenants serve different asset classes or require complete liquidity independence.

  • Shared — all tenants see the same depth, best liquidity, one tenant large order affects all
  • Isolated — each tenant has independent order book, no cross-tenant market impact, lower liquidity per tenant
  • Hybrid — shared order book with per-tenant spread markup layer

• Data isolation: row-level security vs schema-per-tenant?

  Impact: Row-level security for most platforms. Schema-per-tenant when tenant count is low and individual tenant data volumes are high. Database-per-tenant only for enterprise white-label agreements with contractual data separation requirements.

  • Row-level security (RLS) — all tenants in one schema, tenant_id filter enforced by DB
  • Schema-per-tenant — separate PostgreSQL schema, stronger isolation, harder to query cross-tenant
  • Database-per-tenant — maximum isolation, highest operational overhead, justified for large enterprise tenants

• Custom domain: wildcard subdomain vs custom domain per tenant?

  Impact: Support both. Wildcard subdomain for rapid onboarding. Custom domain option for tenants with branding requirements — automate SSL provisioning via Lets Encrypt or Cloudflare.

  • Wildcard subdomain (tenant.platform.com) — simple SSL, no DNS configuration from tenant
  • Custom domain (exchange.clientbrand.com) — professional appearance, requires tenant to configure CNAME

• Tenant branding: runtime theme injection vs pre-compiled asset bundles?

  Impact: Runtime CSS custom properties with edge caching. Allows instant styling updates from superadmin without triggering build pipelines.

  • Runtime CSS variables — instant styling changes without code builds, supports per-tenant live theming
  • Pre-compiled bundles — static per tenant, requires CI rebuild per branding update

What PROPELOO builds.

• Full White-Label Exchange Platform

  Multi-tenant exchange with shared liquidity, per-tenant branding, IB commission engine, superadmin panel.

• IB Network Platform

  Platform for IB network management — multi-tier commission structure, IB portals, volume reporting, automated monthly settlement.

• Regional Operator Platform

  White-label platform for regional operators with jurisdiction-specific KYC, local fiat currencies, local payment gateways.

• B2B Exchange API

  Exchange infrastructure as a service — REST API and WebSocket, order routing to shared liquidity, per-API-key fee configuration.

The white-label exchange stack.

Multi-tenancy at every layer.

• Multi-Tenancy

  Stack: PostgreSQL RLS, Tenant config store, Theme engine (CSS variables), CNAME automation, Tenant provisioning API

• Trading Core

  Stack: Shared matching engine, Per-tenant spread layer, LP connectivity, WebSocket per-tenant feeds, Order isolation middleware

• IB & Commission

  Stack: Commission accrual engine, Multi-tier IB hierarchy, Real-time IB portal, Monthly settlement export, Commission dispute log

• Admin

  Stack: Superadmin dashboard, Tenant management, Cross-tenant analytics, KYC override tools, Global fee management

White-label platform security: tenant data isolation is a contractual and legal obligation.

A cross-tenant data leak is not an engineering bug — it is a breach that affects every tenant users.

• Cross-tenant data isolation

  Database RLS enforced on every query. Application-level tenant context validated on every request. Regular penetration testing specifically targeting cross-tenant data access.

• Tenant admin access

  Tenant admins can only access their own tenant data. Actions that could affect other tenants (global fee changes, liquidity configuration) are superadmin-only.

• Commission data integrity

  Commission accrual records are append-only. Any correction requires a reversal entry, not an update. Full audit trail for every commission payment.

From architecture to live multi-tenant platform.

1. 01. Architecture

   Multi-tenancy model, isolation approach, commission structure, liquidity design.

2. 02. Core Platform

   Tenant provisioning, data isolation, shared matching engine, wallet infrastructure.

3. 03. Branding Engine

   Theme system, custom domain automation, trading pair configuration.

4. 04. IB Commission Engine

   Multi-tier IB hierarchy, real-time accrual, settlement, IB portal.

5. 05. Admin Panels

   Superadmin dashboard, tenant admin, IB admin, compliance tools.

6. 06. Tenant Onboarding Flow

   Self-service or admin-assisted tenant provisioning, KYC setup, fee configuration.

7. 07. Launch & Scale

   First tenant live, monitoring, onboarding playbook for subsequent tenants.

Built. Shipped. Proven.

Engineering cases from PROPELOO white-label exchange projects — architecture decisions, trade-offs and outcomes from real production deployments.

• Multi-Tenant IB Exchange Platform — 28 Active Tenants

  Challenge: An Asian exchange operator needed to expand to 30 IB networks across 8 countries without deploying separate infrastructure per tenant. Their existing approach required 2 weeks of engineering per new IB onboard.

  Architecture: Built a multi-tenant exchange with PostgreSQL row-level security enforcing strict tenant data isolation. Theme engine with CSS variable injection served branded frontends per custom CNAME domain. Shared matching engine with per-tenant spread markup applied at the WebSocket feed layer. Tenant provisioning API reduced new onboarding to a 4-minute admin operation.

  Outcome: Onboarded 28 tenants within 5 months of launch. New tenant provisioning time reduced from 2 engineering weeks to 4 minutes. Zero cross-tenant data incidents in 14 months of operation.

• IB Commission Settlement Engine — $2.1M Monthly Payout

  Challenge: An existing white-label exchange was settling IB commissions from reconstructed trade logs, causing regular disputes and 72-hour reconciliation delays. Three IBs threatened to leave over commission accuracy.

  Architecture: Replaced log-reconstruction with event-sourced commission accrual — every trade emits a commission event immediately, recorded immutably. Multi-tier IB hierarchy (master IB → sub-IB → client) with configurable commission split at each tier. Real-time IB portal showing live commission balance. Monthly settlement generated as auditable PDF with event-level drill-down.

  Outcome: Commission disputes dropped to zero within 60 days. Monthly settlement cycle reduced from 72 hours to 4 hours. IB portal adoption reached 94% of active IBs within first month.

• Zero-Deploy Tenant Configuration System

  Challenge: White-label platforms typically require engineering deployments to onboard each new tenant — blocking growth and creating dependency on engineering availability.

  Architecture: Built a configuration-driven tenant provisioning system: custom domain via automated Cloudflare CNAME + Let's Encrypt SSL provisioning, theme injection via CSS custom properties stored per-tenant, trading pair and fee schedule via admin API. No code deploys required. Tenant goes live within 4 minutes of admin form submission.

  Outcome: Reduced tenant onboarding from engineering-gated (2 weeks) to self-service (4 minutes). Enabled the platform to scale from 8 to 35 tenants without additional engineering headcount.

Frequently Asked Questions