Approve a concise deployment brief
Write down the required account types, account currencies, instruments, asset classes, operating regions and client interfaces. Identify the expected peak workload in meaningful terms: concurrent sessions, quote activity, integration traffic and reporting tasks. Treat forecasts as assumptions to validate rather than guaranteed platform capacity.
Assign an owner to licensing and branding arrangements, hosting, data rights, execution connectivity and business systems. Record the approval required from each party. A component being technically possible does not mean that its commercial or operational prerequisites have been satisfied.
Test configuration across representative accounts
- Confirm the intended position-accounting configuration for each account type.
- Check account/group assignment, currency and permitted actions.
- Inspect instrument specifications, sessions and price availability for each required asset class.
- Run representative order and account-history checks in the permitted test environment.
- Compare platform outcomes with the CRM, client area and operational report.
Use a test matrix with an expected result and a clear pass condition for each case. Differences across account models should be visible in the test plan, not discovered only after client onboarding.
Exercise regional access and dependency failures
MT5 infrastructure can involve multiple server roles. Review the proposed topology and distinguish client access from administration, connected services and recovery paths. Test from the client regions you intend to serve; an office connection close to the hosting location is not a representative regional test.
Agree controlled tests for a stale price source, an unavailable CRM connection and a disconnected client session. Observe detection, escalation and recovery. These tests should be staged with the responsible providers; they are not instructions to disrupt production dependencies. Keep application-level results alongside network measurements.
Require a complete operating handover
| Workstream | Handover evidence |
|---|---|
| Configuration | Dated group and instrument baseline with approved exceptions |
| Integrations | Ownership register, authentication boundary and reconciliation method |
| Operations | Monitoring coverage, incident route and controlled-change procedure |
| Recovery | Agreed recovery objectives and evidence from a restoration rehearsal |
Illustrative example: the terminal works in the primary region, but a regional client cannot complete the same login-and-history test. The issue remains an access-path acceptance item even if the main server is healthy. Bring unresolved items to the MT5 White Label deployment review before approving the release.
Set the launch decision boundary
Does a demo account prove the intended production configuration?
Only if its relevant configuration and connected services represent the intended setup. Record the differences between demonstration and production, including permissions, account models, data dependencies and regional paths. Make the remaining production checks explicit rather than treating an available demo as a universal acceptance result.
Who signs off a technical exception?
The person responsible for its operational effect should understand and accept it, with technical input from the relevant provider. Record the impact, compensating measure and review date. An exception with no owner should remain an unresolved launch dependency.