Launching a retail brokerage is less a single product decision than the assembly of four interlocking systems: a trading platform, a CRM and back office, a dealing and risk layer, and a payments stack — all sitting behind a regulatory posture you choose before writing a line of marketing copy. Founders who treat the platform as the whole project tend to stall at the first withdrawal request or compliance question, because the platform is only where trades happen. The business lives in everything around it.
This playbook walks through the decisions in roughly the order you'll face them, from licensing posture to the launch sequence. It is not legal advice, and nothing here substitutes for qualified counsel in the jurisdictions you intend to serve.
Start with regulatory posture, not the platform
Where and how you're licensed shapes every downstream choice — which clients you can accept, what capital you must hold, how you must segregate funds, what you can advertise, and which payment providers will work with you. Brokerages tend to fall along a spectrum:
- Regulated in a major jurisdiction. Tier-one and tier-two regulators impose capital requirements, client-money segregation, reporting, leverage caps, and conduct rules. Higher cost and longer timelines, but broader market access and stronger client trust.
- Regulated in a lighter-touch jurisdiction. Several offshore regimes offer faster, cheaper licensing with fewer ongoing obligations — a lower barrier to entry, but narrower banking and PSP access and tighter limits on which markets you can solicit.
- Offshore / unregulated structures. Operating without a securities license constrains payments, exposes the business to enforcement risk, and limits credibility with serious clients.
Your choice cascades into product. Leverage caps determine what you can offer; negative-balance-protection rules affect your dealing model; client-money segregation dictates how your back office handles deposits. Decide posture first, then build the stack to fit it. Engage counsel and a compliance advisor early; restructuring after launch costs far more than getting the structure right up front.
The four-system stack
Every functioning brokerage runs on the same four pillars. You can buy them as a bundle, assemble best-of-breed components, or build in-house, but you can't skip one.
| System | What it does | Why it's load-bearing |
|---|---|---|
| Trading platform | Executes orders, streams prices, runs charts and the client terminal | The product clients touch; sets which assets and order types you support |
| CRM & back office | Client records, KYC, IB/affiliate tracking, deposit/withdrawal ledger | Where the business is actually run and audited |
| Dealing & risk | Trader classification, A/B-book routing, exposure and hedge monitoring | Determines your revenue model and protects the book |
| Payments / PSP | Card, e-wallet, and wire rails into and out of client accounts | No deposits, no business; often the hardest piece to secure |
PropHub's broker offering maps onto these four pillars — a trading platform, CRM and back office, dealing-desk risk tooling, and payments — one way to keep the integrations coherent rather than stitched together from separate vendors. The brokers overview covers how the pieces fit.
Choosing a trading platform
The platform is the most visible decision and the one founders over-index on. The practical question is not "which platform is best" but "which fits my clients, my assets, and my time-to-launch."
- MetaTrader 5 (MT5) white-label. The default for forex and CFD brokers: deep trader familiarity, a large ecosystem of EAs and tools, and broad broker-services support. You license a white-label from a primary license holder, configure server groups and the symbol catalogue, and deploy under your brand.
- cTrader. Favored for transparent ECN-style execution and a cleaner API, with strong appeal to more sophisticated traders.
- Match-Trader. A newer, web-first platform with built-in CRM-adjacent tooling and a modern UI, chosen by brokers who want less legacy baggage.
- DXtrade. Flexible, multi-asset, and popular with brokers wanting a configurable, vendor-supported terminal.
A white-label arrangement means you operate under another entity's primary platform license rather than running your own server infrastructure. It compresses time-to-launch and removes operational burden, at the cost of some control and a recurring fee. The comparison comes down to client expectations, asset coverage, customization, and how fast you need to be live. PropHub supports MT5 white-label and alternatives like Match-Trader and cTrader, including server-group configuration, the symbol catalogue, bridge setup, and branded deployment. For a side-by-side, see MT5 white-label vs alternatives.
Liquidity and bridges
A platform without prices is inert. Liquidity reaches it through a bridge — middleware that connects your server to one or more liquidity providers (LPs) or a prime-of-prime, aggregating feeds and routing order flow. Key decisions:
- How many LPs to aggregate, and whether a prime-of-prime gives you one relationship rather than negotiating each LP yourself.
- How the bridge handles markup, last-look, and slippage, since these affect both client execution quality and your margins.
- Which symbols you actually need pricing for, so you don't pay for breadth you won't trade.
The CRM and back office
If the platform is the storefront, the CRM and back office is the operation behind it. This is where you manage client records, run onboarding and KYC, track introducing-broker and affiliate relationships, approve withdrawals, and reconcile the ledger. Underbuilding here creates operational debt that surfaces as delayed withdrawals and compliance gaps.
A capable broker back office should cover:
- Client management — a single record per client linking KYC status, accounts, balances, and trading history.
- KYC onboarding — identity verification and document collection, tied to account opening so a client can't fund before they clear.
- IB and affiliate modules — commission tracking, multi-tier referral structures, and reporting for the partners who bring you flow.
- Deposit and withdrawal automation — a reconciled money trail integrated with both the platform and your PSP, so terminal balances match the ledger without manual intervention.
The integration between CRM, platform, and payments is what makes the back office trustworthy. When a deposit clears the PSP, it should credit the trading account and write to the ledger as one flow, not three steps a human reconciles by hand.
The dealing model: A-Book, B-Book, and hybrid
How you handle client orders determines both your risk profile and your revenue. There are three broad models:
- A-Book. You pass client orders through to a liquidity provider and earn from spread markup or commission. You carry no market risk; the client's profit is the LP's loss, not yours. Predictable, lower-margin, lower-risk.
- B-Book. You take the other side of client orders internally. The client's loss is your revenue and their profit is your cost. Higher potential margin, but you now hold market risk and must manage it actively.
- Hybrid. You classify traders and route accordingly — sending consistently profitable or high-risk flow to the A-Book and internalizing the rest — while monitoring net exposure and hedging when it crosses thresholds. Most established brokers run some version of this.
The hybrid model only works if you can classify traders accurately and watch exposure in real time. That is the job of a dealing-desk risk layer: trader classification, exposure monitoring, and protection against latency arbitrage and deposit-hunting — patterns where clients exploit stale prices or bonus mechanics rather than trading on genuine views. Choosing a dealing model is also a conduct decision: B-Booking creates a structural position against your client, and jurisdictions differ on disclosure expectations. The model is explored in depth in A-Book vs B-Book dealing models.
Payments and onboarding
Payments are frequently the hardest part of a launch. Whether a payment service provider will work with you depends on your license, jurisdiction, and risk category — another reason regulatory posture comes first.
A working payments setup needs:
- Multiple rails. Cards, e-wallets, bank wire, and increasingly crypto, because no single method covers every market and any one can fail or get throttled.
- Redundancy. More than one PSP per method, so a single provider outage doesn't halt deposits.
- Automation. Deposits and withdrawals that reconcile against the trading account and back-office ledger automatically.
A dedicated payments layer handles PSP integration across cards, e-wallets, and wire with deposit and withdrawal automation. The mechanics of routing, redundancy, and reconciliation are covered in PSP integration for brokers.
Onboarding ties payments and compliance together. The sequence that keeps you clean is: register, complete KYC, clear verification, then fund — never funding before verification clears. Building this as one gated flow, rather than bolting KYC on later, prevents the compliance headaches that come from money entering ahead of identity checks.
A launch sequence and build-vs-buy
Sequencing matters because some decisions block others. A workable order:
- Regulatory posture and entity. Choose jurisdiction and structure with counsel; this gates banking, PSPs, and what you can offer.
- Banking and PSP relationships. Secure these early; they take the longest and can disqualify a structure outright.
- Platform and liquidity. Pick the platform, line up an LP or prime-of-prime, and configure the bridge and symbol catalogue.
- CRM, back office, and KYC. Stand up client management, onboarding, and the deposit/withdrawal ledger, integrated with the platform.
- Dealing model and risk. Decide A/B/hybrid and configure trader classification and exposure monitoring.
- Integration, testing, and soft launch. Run end-to-end tests — registration to KYC to deposit to trade to withdrawal — with a small cohort before scaling marketing.
On build vs. buy: building in-house gives maximum control and no per-seat fees, but demands a sizable engineering team, a long timeline, and maintenance of systems that are not your differentiator. Buying — via white-label platforms and integrated back-office vendors — gets you live faster and shifts maintenance to specialists, at the cost of recurring fees and less control over the roadmap. Most new brokerages buy the commodity layers (platform, payments rails, KYC) and reserve building for where they actually differentiate. Where you do extend the stack, a clean integration surface helps: a typed REST and WebSocket API with idempotency, webhooks, and a sandbox lets you build against the platform, with paper trading against live market data to test flows before real money moves.
A brokerage succeeds or fails on the coherence of these systems, not the brilliance of any one. A great platform with a broken withdrawal flow loses clients; a clean back office with no payment redundancy stalls at the first PSP outage; a clever dealing model with poor trader classification bleeds money quietly. Treat the launch as the integration of four dependent systems under a regulatory structure you chose deliberately, move the long-lead items first, and buy the commodity layers so your time goes to whatever sets you apart.