MT5 White Label Setup: Technical, Licensing, and Launch Readiness Checklist
A white label launch fails more often from a missing piece than from a faulty platform. Use this checklist to confirm that your technical, licensing, commercial and operational pieces are ready before you go live. Tick each item with evidence, not memory.
Technical readiness
- Platform environment provisioned and accessible to the right people.
- Branding applied and reviewed on desktop, web and mobile.
- Trading groups, symbols, leverage and account types configured and documented.
- Hosting, backups, monitoring and access control in place.
- A staging environment for testing changes.
See server hosting for operational questions.
Company and licensing readiness
- Legal entity, ownership records and registered office confirmed.
- Bank account or alternative arrangement for operations.
- A clear view of which regulated activities you perform and in which markets.
- A licensing plan and timeline where authorisation is required.
See company formation and licence acquisition. Take qualified advice.
Integration readiness
- CRM connected and tested through the Manager API link.
- Payment providers approved and tested for deposits and withdrawals.
- Liquidity bridge connected, with routing rules agreed.
- Plugins tested on staging.
Compliance and risk readiness
- Client agreements, terms, privacy policy and risk warnings published.
- KYC, anti-money-laundering and complaints procedures written and assigned to owners.
- Risk limits and dealing policy defined.
- Records and audit trails switched on.
Operational readiness
- Support, operations and compliance staff trained.
- Escalation contacts for platform, bridge, payments and hosting recorded.
- Incident and rollback plans written.
- Reports your management needs are available.
Launch readiness
Run an end-to-end test with real flows: register, verify, fund, trade, withdraw. Hold a go or no-go meeting with named owners. Prepare client communications and a plan for the first week of monitoring. Follow with the dated roadmap in our launch timeline.
A readiness scorecard
Score each area as red, amber or green and record the evidence. The point is to see the weak area at a glance.
| Area | Status | Evidence | Owner |
|---|---|---|---|
| Technical | Configuration export and test report | Technical lead | |
| Company and licensing | Documents and approvals | Founder | |
| Integrations | Test transactions | Technical lead | |
| Compliance and risk | Policies and training records | Compliance lead | |
| Operations | Rota, runbooks, contact sheet | Operations lead | |
| Launch | Rehearsal results | Founder |
An amber or red item is not a failure; it is a decision about whether to proceed or delay. Agree who makes that decision before you start scoring.
A worked example of a go or no-go meeting
The team meets two days before the planned launch. The technical area is green. Company and licensing are green. Integrations are amber because a payment provider has approved cards but not bank transfers. Compliance is amber because two support staff have not finished training. Operations is green.
The team decides to proceed with cards only, to complete training before launch and to add bank transfers when approved. Each decision has an owner and a date. Because the meeting reviewed evidence rather than opinions, it takes thirty minutes and nobody is surprised afterwards.
Evidence beats reassurance
In readiness reviews, "done" is a weak answer. Ask for the artefact: a configuration export, a test record, a signed policy or a screenshot of a rota. If it does not exist, treat the item as not done.
Keep the evidence in one folder. It will help with audits, partner due diligence and later changes. See the setup checklist for the full list of tasks.
Common last-minute surprises
- A payment provider needs further documents.
- A domain or email setting blocks client emails.
- A permission lets the wrong person change a setting.
- Support staff do not know how to handle a withdrawal dispute.
- Reports differ between systems and nobody knows which is correct.
A readiness review run a week early gives time to fix them without panic.
How to run the review meeting
Keep the meeting short and structured. Start with the scorecard, ask each area owner for the status and the evidence, and record decisions with owners and dates. Do not discuss solutions at length in the meeting; assign them.
End with a clear statement: go, go with conditions or no-go. Write it in the notes. If the decision is conditional, list the conditions and who verifies them. The record protects the team and clarifies what everyone agreed.
Readiness for the first week of operations
Launch readiness is not only about the day itself. Check that the team can handle the first week: a rota for support, a plan for reviewing payments each morning, a route for escalating platform issues and a place to log problems. Make sure the people who will be on call know how to reach the provider.
Also check that dashboards and reports work for the first clients. It is much easier to fix a report before there are hundreds of accounts to explain.
Keeping the checklist alive
After launch, keep the checklist and use it for changes: a new payment method, a new account type or a platform update. Each change should pass a lighter version of the same review. Over time, the checklist becomes your institutional memory and makes onboarding new staff far easier.
Readiness questions for the leadership team
- Do we know what we will do if the platform has an outage on launch day?
- Who can approve an emergency change, and how quickly?
- Have we agreed how clients will be told about problems?
- Do we understand which third parties could delay us, and what is plan B?
- Are we comfortable with the level of risk we are accepting?
Leaders who can answer these in a few sentences usually have a team that is genuinely ready. Leaders who cannot should postpone the meeting and talk to the area owners first.
Frequently asked questions
What does a readiness checklist include?
Technical configuration, company and licensing, integrations, compliance and risk, operations and launch rehearsal, each with evidence.
Who should attend the go or no-go meeting?
The founder or business lead, and the owners of each area. Keep it short and focused on evidence.
What if an area is not ready?
Decide whether to delay, launch with a reduced scope or add mitigation. Record the decision and the date to revisit.
How early should I run the review?
About a week before launch, with a final check one or two days before.