White Label Trading Platform Guide: Architecture and Launch
A white label trading platform is trading software that a business supplies under agreed branding and access rights, so another company can offer trading under its own name. Buying one means agreeing what the package includes, who operates each system and which records each system controls. A licence fee alone does not settle those questions.
Last updated: 7 November 2026. Reviewed by the FxTrusts editorial team.
Published by FxTrusts, a supplier of brokerage and prop firm technology and an official ORRNN partner for RTX5 implementation. This article includes our commercial perspective. Confirm prices in a written order form before you budget, and see our pricing page for the published figures.
This guide is for operators and implementation teams. It shows what connects to what and what to test before launch. For FxTrusts' offer in this model, see the forex white label page.
Key takeaways
- A white label trading platform is a bundle of systems: terminal, trading server, client portal and connections to CRM, payments and liquidity. Each system needs a named owner.
- Vendor-managed, hosted and direct-licence arrangements grant different rights. Get those rights in writing before you compare prices.
- Published prices cover named scopes. Check exclusions such as platform licences, API charges and setup costs.
- Write acceptance tests for account creation, funding, permissions and recovery before integration starts.
- A platform does not give your business a regulatory permission.
What a white label trading platform includes
The trading terminal is what a trader sees: charts, orders, positions and account information. A trading server applies the configured account and trading rules. A client portal handles registration, documents and funding requests.
Vendors describe these connections differently. Match-Trader's white-label page describes a branded app, a Client Office, CRM integration with single sign-on and a Manager API. That shows one design, not every supplier's interfaces. Ask for the architecture of the exact package you are buying. MetaQuotes' brokerage setup guide likewise lists the platform, hosting, liquidity, CRM, payment providers and staffing as separate steps. For the FxTrusts platform scope, see the platform overview.
A practical map of the technology stack
Give each layer a record it controls and a boundary your contract must describe.
| Layer | Main job | Records or controls to identify | Boundary to document |
|---|---|---|---|
| Website and identity | Present the offer and start registration or login. | Client identifier, consent, authentication and session records. | Which system issues identity and revokes access? |
| CRM and back office | Manage onboarding, support, account requests and operator workflows. | Client profile, review decisions, account links and request history. | Which actions need approval before a platform API call? |
| Trading platform | Accept permitted orders and maintain the trading account. | Orders, positions, account groups and trading balances. | Which administrators may change settings or post balance operations? |
| Execution connectivity | Connect to external execution where the model requires it. | Routing rules, identifiers, fills, rejects and exposure. | Who resolves a difference with the counterparty's records? |
| Payment connections | Submit payment requests and receive provider status. | Provider transaction IDs, settlement references, fees and reversals. | When is funding eligible for credit, and who reconciles it? |
| Ledger and reporting | Track money movements and explain differences between systems. | Posted entries, pending movements, adjustments and reconciliation results. | Which record governs each balance? |
| Monitoring and recovery | Detect interruption and restore an accepted operating state. | Alerts, backups, recovery logs and incident evidence. | Who acts, how quickly and with what access? |
This is a procurement map, not a universal vendor diagram. Combining screens does not remove the need to define records and permissions.
Follow one deposit through every system
Illustrative workflow: a verified client requests a deposit in the trader's room. The payment integration creates a provider reference, and the provider later returns an authenticated status. Your funding policy decides whether the movement can be credited, and a connector requests the platform balance operation. Finance then matches the transaction with settlement evidence. For how FxTrusts approaches settlement, see the payment infrastructure scope.
A browser returning to a success page does not prove the process completed. The payment may stay pending, a notification may arrive late or the platform call may time out. Give the workflow a correlation identifier linking the client request, provider transaction, ledger entry and platform operation, and keep each external identifier too.
Test the difficult branch. The platform applies a credit, the connector loses the response, and a blind retry creates a second credit. Require proof of duplicate protection. The acceptance requirement is one confirmed movement, one intended credit.
Keep the order path separate from the money path
An order can be validated, accepted, routed, partly filled, cancelled or rejected. A payment passes through different providers and settlement records. Each needs its own status model and escalation route. For an externally executed trade, trace a test order from the client interface through the platform and any connector to the counterparty, recording timestamp source, symbol mapping and volume units at each step.
Document a simulated or internally handled account as that model. A price feed alone is not evidence of external execution, and a demo account should not be presented as a live brokerage account because its screens look similar. Trading involves a risk of loss, and a platform does not change that.
Choose an access model and name its limits
| Arrangement | Question that defines it | What it does not establish |
|---|---|---|
| Vendor-managed white label | What branding, configuration and operational access does the contract grant? | Ownership of platform source code or unrestricted administrator rights. |
| Hosted access through another contracting party | Who holds the underlying rights, and who has authorised your entity and use? | A direct licence from the platform developer. |
| Direct platform licence | What may you deploy and operate under the vendor agreement? | Permission to offer regulated services. |
| Custom-developed system | Which code, documentation and deployment rights transfer? | Completed integrations, production resilience or market permissions. |
MetaQuotes' direct purchase page says the buyer deploys the software on its own hardware. It states that MetaQuotes offers no SaaS or similar solution that permits even partial external management or third-party control, and has no access to the buyer's servers, accounts or trading history. A hosted proposal from another business needs its own examination; compare it with our hosted platform access scope. Do not call it a MetaQuotes subscription, or assume public product features prove the host's right to grant access. "Grey label" is used loosely in sales talk, so replace it in your specification with named account groups, manager permissions, branding scope, support duties and termination terms.
Build a responsibility matrix before integration starts
For each component, record the operational owner, change approver, incident contact and supplier dependency. Keep the team that detects a problem separate from the team allowed to fix it. Name who may create administrators, rotate credentials and approve money movements, and state how access is removed when staff or supplier engineers leave. An incident ticket should carry the account identifier, timestamps with time zone, observed and expected state, and external references.
Pricing: what each published price covers
The FxTrusts prices are as published on our pricing page; the RTX5 prices are from the ORRNN RTX5 public matrix, checked on 7 November 2026. They exclude taxes and many one-time costs, so read the order form rather than the headline figure. The ORRNN page calls its Entry and Standard figures approved commercial planning inputs, not an executed sales contract, and marks support, SLA, hosting and tax terms as still to be specified.
| Offer | Published price | What it covers | What it does not cover |
|---|---|---|---|
| Hosted MT5 Manager Access (FxTrusts) | US$3,500 per month | Role-scoped Manager/API access to a contracted host, with a proposed allowance of 500 real-account and 10,000 demo-account slots. | A direct MetaQuotes licence. It needs written platform and host authorisation for your entity. CRM is a separate subscription unless a signed bundle says otherwise. |
| Setup coordination (FxTrusts) | 10% of approved one-time third-party setup costs | Coordination supported by supplier quotes and a milestone schedule. | Recurring subscriptions, refundable regulatory capital, client funds, broker or liquidity deposits, fines and taxes. |
| RTX5 Entry (ORRNN matrix) | US$3,500 per month (planning input) | Up to 1,000 real accounts. CRM is included at no extra licence charge. | Bridge/gateway, optional at US$2,000 per month, and FIX, from US$600 per month for FIX 4.4. |
| RTX5 Standard (ORRNN matrix) | US$5,000 per month (planning input) | Up to 25,000 real accounts. Bridge and FIX are included for the agreed scope. | CRM, a standalone add-on at US$1,500 per month. Setup, infrastructure and taxes. |
The RTX5 rows are a commercial reference, not an independent review. FxTrusts previously confirmed a recurring discount on the older Starter and Growth plans, which ORRNN no longer publishes. Any discount on the current Entry or Standard plans must be confirmed in writing; none is assumed here.
Turn the architecture into an itemised proposal
Place each application, CRM function and connector from your map into a proposal row marked included, separately priced, supplied by your team, or awaiting confirmation. Choose the tier only after applications and environments are agreed. Review the RTX5 service scope alongside the architecture, and define operator workflows in your CRM specification.
Launch tests: a three-test acceptance brief
| Test in the agreed environment | Evidence to request | Decision it supports |
|---|---|---|
| Create an account after an approved onboarding decision, then repeat the request. | One intended account, a stable client mapping and an audit entry for the repeat. | Whether onboarding and provisioning share reliable identifiers. |
| Interrupt a funding connector after the platform accepts the operation. | A recoverable status and reconciliation evidence, with no second credit. | Whether finance can resolve a timeout safely. |
| Remove an operator permission and attempt the restricted action. | The action is denied by the responsible system, and the attempt is recorded. | Whether permissions hold beyond what a screen displays. |
These are proposed tests, not production results. Agree expected outcomes and a named reviewer beforehand. If a provider will not expose a backend, ask for other verifying evidence.
Launch through evidence gates, not a promised number of days
- Scope accepted: products, entity, account model and responsibilities are documented.
- Configuration accepted: branding, account groups, permissions and business rules match a versioned specification.
- Integration accepted: normal and failed account, funding, order and withdrawal journeys produce traceable results.
- Recovery accepted: backup restoration, connector restart and incident escalation are demonstrated.
- Operations accepted: staff can investigate exceptions, reconcile records and explain client-facing statuses.
- Cutover accepted: a reconciled starting state, monitoring, a rollback decision point and a named go-live approval.
Plan the exit while selecting the platform
Before you sign, confirm you can export client mappings, financial movements, orders, rule versions and audit records, and check retrieval fees. Agree how open positions and pending orders move at cutover.
Sources
Vendor pages describe public claims, not your contract rights. The ORRNN matrix was re-checked on 7 November 2026.
Frequently Asked Questions
Is a white label trading platform the same as a MetaQuotes licence?
No. A direct licence means you deploy the software on your own infrastructure. A white label or hosted arrangement is a separate contract, so check its rights in writing.
Does the RTX5 Entry price include CRM?
The ORRNN matrix includes CRM in Entry at no extra licence charge, and lists it as a US$1,500 monthly add-on on Standard. Confirm the tier and scope in the signed order form.
Does a white label platform make my business licensed?
No. The platform supplies software and, in some models, hosting. Permission to offer regulated services depends on your legal entity's regulator and planned activities.
How long does a launch take?
This guide gives no fixed number of days. Timing depends on approvals, configuration and integrations in the agreed scope.
What should I test before go-live?
Test account creation with a repeated request, a funding connector that fails after the platform accepts an operation, and a restricted action after permission removal. Then reconcile sample client balances across the platform, ledger and provider records.
Can I move clients to another platform later?
Sometimes. It depends on whether the contract allows export of client mappings, financial movements, orders and audit records. Confirm those rights before you sign.
