How to Build a White Label MT5 Broker Platform: Architecture Guide

To build a white label MT5 broker platform you need a multi-tenant core where each broker brand is a tenant with its own branding, users and settings; a trader-facing terminal with charts, order tickets and account views; an admin application for approving tenants, managing accounts and monitoring; a bridge that executes orders on MetaTrader 5 and reports fills back; and a message bus between those services so each can scale and fail independently. Around that core sit the things that decide whether the platform is trustworthy: exact money arithmetic, a licence-compliant charting layer, and a test suite that exercises the full loop from tenant approval to a filled trade.

The architecture is not exotic. The difficulty is in the details that only matter when real money flows: rounding that never drifts, a bridge that cannot accidentally hit a live server, and documentation that cannot fall out of sync with the code. This post walks through the design decisions in the order I made them when building AstraTrade, a v1 white label broker platform built around one specific end-to-end demonstration.

What does "white label" mean in the MT5 context?

MetaTrader 5 itself has a white label programme in which a broker runs under a larger broker's server with its own branding, and MetaQuotes documents the server side at https://www.metatrader5.com/en/brokers. A white label platform in the sense of this post is the layer a technology provider builds on top: the web terminal, client portal, admin console and back office that a new broker brand can launch without building software. MT5 remains the execution venue; the platform is everything the broker's customers and staff touch.

That distinction tells you where the boundaries are. Your platform owns identity, tenancy, presentation, risk display and reporting. MT5 owns matching, margin and the account of record. The bridge is where they meet, and it must be designed so the platform never pretends to know something only MT5 knows.

How should tenants, traders and admins be separated?

1. Tenant is the broker brand: name, theme, allowed instruments, default leverage display, and an approval state. Tenants are created in the admin app and nothing works for a tenant until it is approved.
2. Trader belongs to exactly one tenant and sees only that tenant's branding and instruments. Authentication is scoped so a trader token cannot address another tenant's data even by guessing identifiers.
3. Admin is platform-level, with roles for approving tenants, viewing cross-tenant monitoring and operating the bridge.

Keep these as separate applications sharing a service layer rather than one application with role checks sprinkled through it. A monorepo with a trader app, an admin app and shared packages makes the boundary visible in the file tree, and a mistake that leaks admin behaviour into the trader app becomes a build error rather than a runtime surprise.

How do services talk, and why use a message bus?

Order placement, bridge execution, fill confirmation, engine mirroring and reporting are separate concerns with different latency and reliability needs. Connecting them over a message bus such as NATS means the terminal publishes an order request and moves on, the bridge consumes it and publishes a fill, and any number of consumers (engine, ledger, notifications) react to the fill without the bridge knowing they exist. If the reporting service is down, orders still execute; when it comes back, it catches up. For local development, an embedded Postgres and a local bus instance let the whole system run on one machine, which is essential for the end-to-end tests described below.

How do I store money and prices without rounding drift?

Never in floating point. The platform stores money as integers in micro-units, prices as integer points at the symbol's precision, and volume as fixed integer units per lot. Every arithmetic operation is integer arithmetic until the last moment of display. This sounds pedantic until the first divergence report shows the engine and MT5 disagreeing by a fraction of a cent on every trade and you cannot tell whether the bridge or the rounding is at fault. With integers, the only possible source of divergence is the data, which is the point.

Why have an internal engine mirror and a divergence report?

Because the platform must be able to say, for every trade, what it believes happened and what MT5 says happened, and show the difference. An internal engine consumes the same order requests and fills and maintains its own view of positions, margin and P&L. A divergence report compares the engine's view with the bridge's view from MT5 per trade and per account. In normal operation it is empty; when a fill is missed, a price is mis-scaled or a rounding rule differs, the report names the trade. It is the platform's audit trail and its best debugging tool, and building it in v1 is far cheaper than retrofitting it after the first dispute.

What about charts and indicators?

A broker terminal needs charts traders recognise. The obvious choice, TradingView's Charting Library, has licence terms that exclude white label use, which I verified before committing; the platform uses KLineCharts instead. Indicators are the other expectation. Rather than hard-coding a handful, the platform includes a small custom indicator language runtime that executes indicator scripts and plots them on the chart, with a read-only browser probe so end-to-end tests can assert on what was drawn. Expert Advisor attachment, meaning scripts that place orders, is deliberately disabled in the live terminal and limited to a tester, because an EA runtime in a broker's web terminal is a liability until it has a full risk and permission model around it.

How do I make sure the whole loop actually works?

Quality gates on every change, run in this order: unit tests, typecheck, an encoding check that catches stray non-UTF-8 bytes before they corrupt a build, the production build, and Playwright end-to-end tests that need the message bus and services running. The end-to-end suite replays the headline scenario: approve a tenant, log a trader in, place an order, see the bridge execute on MT5, see the engine mirror it, and read an empty divergence report.

Two gates were added after specific failures. A status document is rewritten on every run as the single current truth, because stale status files had misled me once. And a test fails if the documentation mentions a command that does not exist in the package scripts, added after a broken instruction shipped.

How I built this: AstraTrade: White-Label Broker Trading Platform (MT6)

AstraTrade is the v1 of a white label trading platform for brokers, built as a TypeScript monorepo around one demonstrable loop. The build order:

1. Monorepo scaffold. A trader terminal, an admin app and shared service packages, with NATS for messaging and embedded Postgres for local development so the whole platform starts on one machine.
2. Tenant approval flow. The admin app creates and approves tenants; traders are scoped to their tenant from login onward.
3. Integer money model. Money as bigint micros, prices as points, volume in fixed units per lot, so rounding never drifts between services.
4. MT5 bridge, demo-guarded. The bridge executes on MetaTrader 5 and publishes fills over NATS. A hard guard restricts it to demo servers, so no configuration mistake can route an order to a live account. One real demo trade was verified end to end through this path.
5. Engine mirror and divergence report. The internal engine mirrors every trade and a report compares it with the bridge's view.
6. Charts and indicator runtime. KLineCharts after confirming the TradingView library licence excludes white label use, plus a custom MQL6 indicator runtime that executes and plots on the chart, probed read-only by the tests; EA attachment limited to the tester.
7. Quality gates. 114 unit tests, typecheck, encoding check, build, and 11 Playwright end-to-end tests covering the full loop, with the status document rewritten each run and the docs-versus-scripts test guarding against stale instructions.

The design decisions that matter most for a broker platform: integer arithmetic from day one, a bridge that physically cannot reach live, a divergence report as a first-class feature, and licence verification before choosing the charting layer. The outcome is a v1 that proves the loop with a real demo trade and a green end-to-end suite, which is the foundation a broker brand can be built on. The MT5 execution side connects to the same family of bridge work I describe in connecting TradingView alerts to MT5, with the broker platform adding tenancy and reconciliation on top.

FAQ

Do I need an MT5 white label licence from MetaQuotes to build this?

To run real accounts, the broker needs an MT5 server arrangement, either its own licence or a white label under a larger broker. The platform software can be built and fully tested against demo servers before that arrangement exists, which is how AstraTrade's v1 was developed.

Why not just use MT5's own web terminal?

A broker can, and many do. A custom platform exists to own the client experience: branding, onboarding, portals, reporting and features MT5's terminal does not offer. The trade-off is that you now own the reconciliation problem, which is why the engine mirror and divergence report exist.

How long does a v1 like this take?

Months rather than weeks for a single engineer, with most of the time in the bridge, the money model and the test infrastructure rather than the screens. Screens are quick; a demo-guarded bridge with an empty divergence report is not.

Can the same architecture serve a crypto or Indian-broker back end?

Yes. The tenant model, money arithmetic, bus and divergence report are venue-independent; the bridge is the venue-specific part. Swapping MT5 for an exchange API or a Kite-style broker API changes the bridge and the instrument master, not the platform.

If you are a broker or technology provider planning a platform like this, describe what you need to launch on the contact page.