MT5 White Label Setup: A Technical Readiness and Acceptance Checklist
Readiness is evidence, not opinion. Each item below should have an artefact: a configuration export, a test report or a signed approval.
Environment
- Platform environment provisioned; access list reviewed.
- Branding applied and screenshots archived.
- Groups, symbols, leverage and account types exported and compared with the plan.
- Hosting, backups and monitoring tested.
Integrations
- CRM workflows tested on staging, including failure cases.
- Payment flows tested for success, failure and reversal.
- Bridge passes prices and orders correctly; failover tested.
- Plugins tested on staging.
See the integration specification.
Security
- Role-based access in place and reviewed.
- Credentials stored securely and rotation scheduled.
- Audit logs enabled.
- Backup restore tested.
Operations
- Runbooks written for restart, failover and restore.
- Escalation contacts verified.
- Monitoring alerts reach a person.
- Change control process in place.
Compliance inputs
- Entity and licence plan confirmed with advisers.
- Client agreements and risk warnings published.
- KYC and AML procedures assigned.
See company formation.
Sign-off
Hold a go or no-go review with evidence for every item and named approvers. See the schedule in the launch critical path.
Evidence register
Maintain a register mapping each checklist item to its artefact, location, date and approver. At the go or no-go meeting, review the register rather than asking people whether things are done.
Missing evidence is treated as not done until it exists.
Readiness domains and gate criteria
Group readiness into domains with measurable gate criteria: environment (configuration matches specification, backups and monitoring active), integrations (all workflows pass acceptance), security (roles tested, secrets rotated, logging verified), operations (runbooks, rota and contacts), compliance inputs (policies, records and retention) and sign-off.
Each criterion should reference an artefact. A readiness review then becomes an inspection of evidence.
Evidence register
| Criterion | Artefact | Location | Verified by | Date |
|---|---|---|---|---|
| Config matches spec | Export and diff | Repo path | Technical lead | |
| Backups restorable | Restore test report | Folder | Operations | |
| Roles tested | Negative test results | Folder | Security | |
| Integrations pass | Test report | Folder | Technical lead | |
| Runbooks delivered | Documents | Wiki | Operations | |
| Policies approved | Signed documents | Folder | Compliance |
At the review, walk the register row by row. Missing evidence means not ready.
Go and no-go criteria
Define in advance which failures are blocking (money movement defects, access control gaps, no restore capability) and which are tolerable with mitigation (cosmetic issues, non-critical reports). Record exceptions with owner and date.
Hold the review with all domain owners and record the decision, conditions and verifier for each condition.
Post-launch verification
Define verification for the first day, week and month: reconciliation results, error rates, ticket volumes, time to verify, payment success. Review against thresholds and decide whether to widen the audience or fix first.
See our setup walkthrough for the preceding stages.
Worked example: a blocked gate
During review, the restore test shows recovery in nine hours against a four-hour target, and the role test finds that support can export full client lists. Both are blocking. The team assigns owners, fixes backup configuration and tightens the role, repeats both tests and attaches the new evidence.
The launch date moves by a week, which was cheaper than an incident after launch. The record shows why.
Operational readiness drills
Run drills: failover of a component, credential rotation, backup restore, incident communication. Time each and record issues. Drills convert paper procedures into practised ones.
Continuous readiness
Readiness does not end at launch. Maintain a lighter version of the checklist for changes: new payment methods, new account types, platform updates and new markets. Each change passes the relevant gates with evidence.
Over time the checklist becomes the organisation’s change standard, reducing the risk that growth outpaces control.
Frequently asked questions
What is an evidence register?
A table mapping each readiness criterion to its artefact, location, verifier and date.
What failures should block launch?
Money movement defects, access control gaps and lack of restore capability.
How should exceptions be handled?
Recorded with owner, mitigation and date.
What should be verified after launch?
Reconciliation, error rates, tickets, verification time and payment success.