MT5 White Label Platform Customization: Mapping the Configuration Surface
A white label exposes a larger configuration surface than a grey label. Map it, assign owners and put change control around it, because every setting is also a way to break something.
Branding surface
Identify supported branding points: server and company identity, branded installers, web and mobile clients where available and your client-facing properties. Record the process and lead time to change each.
Trading condition surface
List configurable items: account types, groups, leverage, commissions, markups, swaps and symbols. Document current values, the rationale and who approves changes.
Integration surface
Document the interfaces you use: management interfaces, gateways and bridges, and data feeds. Record the version, owner and test status of each. See the integration specification.
Operations surface
Define who applies updates, patches and plugin changes, and how they are tested. Keep a staging environment that mirrors production. See our hosting guide.
Change control
Require a change request, impact assessment, test evidence, approval and rollback plan for production changes. Log every change. Compare with the lighter model in grey label customization boundaries.
Change log template
For each production change record: date, requester, description, reason, impact assessment, test evidence, approver, rollback plan and result.
A consistent log makes incident analysis faster and shows regulators and partners that changes are controlled.
Surfaces and their change processes
Customization surfaces differ in who can change them and how safely. Branding surface: assets and wording, low risk. Trading condition surface: groups, symbols, leverage, spreads and commissions, with direct financial impact. Integration surface: CRM, payments and bridge, with operational risk. Operations surface: roles, procedures and monitoring. Platform surface: versions and server configuration, usually provider-controlled.
Assign each surface an owner, an approval path and a test set. This turns customization from ad hoc requests into a managed process.
Change control record
| Field | Content |
|---|---|
| Request ID and date | |
| Surface and layer | |
| Description and reason | |
| Impact assessment | Clients, reports, integrations |
| Approver | |
| Test evidence | |
| Rollback plan | |
| Result and date |
A complete record is the fastest way to diagnose a regression and the best evidence of control for partners and regulators.
Environment strategy
Use at least a staging environment that mirrors production configuration. Promote changes from staging after tests, with a defined release window. Keep configuration exports for each release. Where staging is unavailable, define a controlled pilot with test accounts and a restricted group before general use.
Track configuration drift between environments and reconcile it deliberately.
Version and update management
Platform updates can alter behaviour. Subscribe to provider notices, review release notes against your customizations and run the regression suite in staging before production. Maintain a compatibility list of integrations and plugin versions.
See our grey label customization guide for the layered model applied to a lighter setup.
Worked example: adding a payment method
The request touches the integration surface and the presentation surface. Impact assessment lists the CRM workflow, the funding page, reconciliation, reports and support scripts. Test cases cover success, failure, duplicate callback and refund. Release is staged: staging, a small production group, then all clients.
The record documents each step and the evidence, and the rollback plan is to disable the method in routing rules.
Access to configuration
Limit who can change production configuration, require two-person review for commercial changes and keep a read-only role for auditors. Export configuration nightly to a controlled store to detect unauthorised drift.
Documentation standards
Keep concise but complete documentation: a configuration baseline, interface descriptions, operating procedures, a change log and a decision log. Version everything and mark the effective date. Use templates so that new entries are consistent.
Review documentation as part of each release, and treat missing or outdated documentation as a defect with an owner and a due date.
Frequently asked questions
Why classify customizations by surface?
Because each has different owners, risks and test needs.
What belongs in a change record?
Reason, impact, approver, test evidence, rollback plan and result.
Do I need a staging environment?
It is strongly recommended for any non-trivial change.
How do I handle platform updates?
Review notes, test in staging and schedule a release window.