Affiliate marketing and introducing broker (IB) programs are one of the most capital-efficient growth channels for a centralized crypto exchange (CEX). Unlike paid ads, commissions are tied directly to trading fees, so CAC and LTV move together. But a production-grade CEX affiliate system is much more than a referral code and a 20% rebate. It has to define fee bases (gross vs net, spot vs perpetual, funding and liquidation fees), multi-tier and differential rebate structures, attribution windows, sub-account binding, real-time vs T+1 settlement, frozen balances and clawbacks, anti-wash-trading and anti-self-trading controls, campaign stacking, back-office reconciliation, multi-tenant white label support and regulatory guardrails. This article walks through the full product and engineering architecture of a CEX affiliate and IB commission system, and how SoonTech delivers it across Southeast Asia, the Middle East and Latin America.

1. Why IBs Are the Second Growth Engine of a CEX

In the cold-start phase, a new exchange usually has neither brand nor liquidity. Market makers can solve liquidity, but real users still have to be acquired. Direct buys on Google, Meta and TikTok face three problems: crypto ads are heavily restricted, CPI is high with weak retention, and acquired users have no service relationship. An affiliate/IB network redistributes the marketing budget to KOLs, community leaders, local agents and institutional brokers who bring trust, onboarding and ongoing support. The exchange only pays when real fee revenue is generated.

As the exchange scales, the channel base stratifies. Retail referrers want a simple link and a dashboard. Professional IBs want multi-tier downlines, tiered bonuses, marketing assets, sub-account views and dedicated managers. Institutional brokers want custom rebate plans, white label cooperation, API-based commission feeds and monthly invoicing. A mature commission system must serve all three segments simultaneously.

Because commissions are a share of fee revenue, the commission system is tightly coupled with the matching engine, fee module, accounts, wallet and risk engine. Every trade triggers downstream commission calculation, marketing adjustments and risk screening, ideally via an event bus rather than cross-database joins.

2. Rebate Models From Single Rate to Multi-Tier

The first design question is the rebate base. Gross fee is what the user actually paid. Net fee is what remains after market-maker discounts, VIP tiers, point cards and platform coupons. Weighted fee assigns different weights by pair or user class. Many early exchanges promise "50% of fees" without specifying the base, causing disputes when users pay with point cards. The back office should expose four columns—gross fee, deductions, net fee and final commission—and the contract should specify which base applies.

For perpetuals, funding fees are pass-through between longs and shorts and should generally not be counted, but any platform settlement fee can be. Liquidation fees are usually much higher than taker fees and fully captured by the platform; they can be included but should have a separate rate to avoid abuse.

Single-tier rebates are the simplest: A invites B, and A earns a share of B's fees. Multi-tier extends the chain. Key parameters are depth (most compliant exchanges cap at two or three tiers), per-tier rates, and the allocation method—fixed rates, step rates, or a differential (level-to-level) scheme common with institutional brokers. Differential schemes reward IBs for upgrading their own level and their team's, but require per-node settlement logic and careful handling of cross-level, same-level and demotion cases.

Tiered rebates tie next period's rate to current performance, measured by team volume, active users, net deposits or fee contribution. Designs should avoid cliffs—jumping from 20% to 40% at a threshold triggers month-end wash trading. Progressive steps and buffers work better.

Different business lines need different rates. Spot fees are small but high percentage; perpetuals generate high turnover and require maker/taker differentiation; copy trading splits performance fees between lead and follower separately; earn products pay from interest margin; OTC and block trades pay in basis points on notional. A "Rebate Plan" entity should encapsulate per-business-line rules and be bindable to each IB contract.

3. Attribution, Binding and Lifecycle

Users often click multiple referral links before signing up. Common models are forced-code binding, cookie/device attribution with a 7–30 day window, last-click and first-click. A pragmatic default is binding-wins with first-click fallback: if a code is present at registration it wins; otherwise the system looks back N days and binds the first touch. This protects content-driven KOLs while preventing late-click hijacking.

Institutional brokers often create sub-accounts via API and bind them to their master at creation. Sub-accounts trade independently but roll up to the master's team volume. Internal transfers between master and sub stay on the books. Whether sub-accounts can themselves build downlines must be a contract-level switch.

Binding changes should never be self-service. A back-office ticket signed off by both IBs and operations, with full audit logs, is the safest path. Banned IBs freeze future rebates while keeping settled ones; historical rebates are not reassigned to new IBs because retroactive re-bookings create accounting chaos.

Lifecycle rules vary. Some platforms use permanent binding with violation-based termination; others add a 12-month expiry or inactivity timeout. Start simple and add windows once scale justifies it.

4. Settlement Engine: Real-Time, Near-Real-Time and T+N

Settlement timing is a core risk-reward trade-off. Trade-by-trade real-time settlement pleases IBs but is a gift to wash traders—commissions can be withdrawn before risk control catches up. Near-real-time (one to five minute rolls) balances experience and load. T+0/T+1 batch settlement is simplest for reconciliation and clawback.

A robust pipeline is: the matching engine broadcasts TradeEvent over Kafka; the settlement service loads the user's upline tree, rebate plan and active campaigns; it computes per-tier CommissionItems; the risk engine pre-screens and tags suspicious items; clean items land in a pending balance and frozen items in a frozen balance; a nightly batch matures pending balances and re-reviews frozen ones; withdrawal flows through the normal wallet; finance reconciles match, fee, commission and wallet reports daily.

Multi-currency settlement is another issue. Fees accrue in the quote or base currency of each pair, but IBs usually want USDT or USDC. Best practice is accrue in-kind, snapshot convert at day-end using an index price, and offer optional auto-conversion with explicit slippage controls.

Reversals are first-class records. Never delete a CommissionItem; append a ReversalItem with negative amount linked to the original ID and recompute balances as the sum of all items. This keeps an auditable trail when trades are busted, wash trading is clawed back or fee bugs are corrected.

5. Anti-Fraud and Anti-Wash-Trading

Common attacks include self-trading between controlled accounts, wash trading to hit tiers, multi-account farming via synthetic KYC, high-frequency API scalping, fake identities, rebate pass-through that undermines pricing, and organized farming studios.

Defense is layered. Pre-trade uses device fingerprinting, IP/ASN checks including VPN/Tor detection, KYC similarity (face match, OCR reuse, phone/email reuse) and behavioral biometrics. At trade time, the engine detects self-trades within UID trees or device clusters, order-book manipulation like repeat cancel-near-touch, abnormal fixed-size patterns, and graph-based account clusters built from deposit addresses, withdrawals, devices, invites and IPs. Post-trade, withdrawal address clustering, fund round-tripping and Chainalysis/TRM Labs on-chain screening identify laundering paths.

Actions should be gradable: observe-with-tag, freeze commissions, downgrade rebate rate, revoke IB status, or ban the account. Every action needs a reason code and an appeal path. Head IBs deserve dedicated risk operators to avoid false positives on large clients.

Economic design matters as much as rules. Define active users by KYC plus first deposit above a threshold plus a real (non-self) trade. Use net deposits rather than gross volume for tier qualification. Cap per-user daily fee that counts toward rebates. Strip flagged accounts from team totals and retroactively adjust tiers. Add a 7–14 day cooling-off period for new users. If washing is not profitable, most of it disappears.

6. Campaign Stacking and Back Offices

On top of base rebates, operations run limited-time boosts, new-IB startup bonuses, trading competitions, referrer-referee double-sided rewards, and point-card or platform-coin multipliers. A promotion rules engine with conditions (time, user, pair, tier), actions (boost, fixed bonus, prize distribution) and budget caps keeps temporary rules out of the core settlement code.

The IB portal needs an overview dashboard, downline management, commission detail ledger, settlement and withdrawal views, marketing assets, sub-account tools and a message center. The operations back office needs IB review and grading, plan management, campaign designer, risk case workbench, finance reconciliation, and role-based audit. Executive dashboards track channel contribution, channel cost ratio (total commission divided by net fee revenue, healthy at 30–50%), active user funnel, IB retention, risk interception and ROI by channel and campaign.

7. Engineering, Compliance and Launch

Idempotency is non-negotiable: each trade is processed once using a unique key of trade ID plus direction plus tier, enforced by a database unique index. Settlement updates and balance updates belong in one transaction, with Saga and reconciliation jobs for cross-service cases. Kafka consumer groups, multi-AZ deployment, database replicas and backups support availability. Tracing on every commission calculation and Prometheus/Grafana alerts on settlement lag and freeze rate keep operations honest.

Shard by UID, archive historical details, cache the upline tree and plans in Redis, and keep hot/cold storage separated. For white label deployments, every table carries tenant_id with enforced filters, and plans, campaigns and rules are per-tenant.

Regulatory red lines matter. Keep rebate depth to three tiers, base commissions on real trading fees, never charge an IB entry fee, and avoid lock-up purchases of platform tokens. Malaysia, Singapore, Indonesia, Dubai and other jurisdictions have different multi-level marketing rules; local counsel must sign off. IBs themselves require KYC/KYB, and due diligence on high-risk geographies is mandatory. Tax withholding, invoicing for institutional IBs, cross-border payment restrictions and crypto commission tax treatment should be designed with finance and tax advisors from day one.

8. SoonTech Implementation

SoonTech's CEX affiliate suite covers channel onboarding, a rebate plan center, a Kafka-based settlement engine supporting real-time and T+1 modes, a risk engine with device fingerprint and graph analytics, a campaign center, IB web and app portals, an operations console and a data warehouse with ROI dashboards. A typical deployment takes five weeks from kickoff to launch: one week for discovery, one for plan and contract design, one for end-to-end integration, one for risk tuning and UAT, and one for production cutover with 24/7 support.

We have deployed the system for a Southeast Asian emerging exchange where IB channels contributed 65% of signups within three months at 70% lower CAC than paid ads; for a Middle Eastern family office white label using sub-accounts, differential rebates and Chainalysis monitoring under VARA expectations; and for a Latin American derivatives exchange that cut channel cost ratio from 75% to 42% while growing real volume 35% after replacing gross-volume tiers with net deposits and active users.

9. Roadmap and Future

On-chain referral attestations will extend affiliate logic into DEX and wallet contexts, but CEX programs will remain centralized because compliance and customer service require a responsible entity. AI models, especially graph neural networks and sequence models, are replacing rule-only risk stacks. Embedded broker APIs will let wallets, portfolio trackers and asset managers embed trading and earn rebates, turning "referral link" programs into broader partnership infrastructure. As MiCA, VARA, SC Malaysia and MAS tighten frameworks, licensed broker-dealers and family offices will displace individual IBs, and vendors offering compliant end-to-end systems will win the next wave.

🌐 Build secure and scalable Web3 platforms with SoonTech.

Explore our solutions for White Label Crypto Exchanges, Prediction Markets, MPC Wallets, Matching Engines, Liquidity Integration, and Compliance.