MT5 Grey Label Customization Boundaries: Branding Layers, Groups and Access Rights
Customization on a grey label is a question of boundaries: which settings you own, which are shared and which belong to the provider. Documenting them as a capability register before you sign turns marketing language into something you can test.
Model the boundary as layers
Think of four layers: presentation (brand), commercial (groups and conditions), operational (access and tooling) and platform core (server, version, updates). A grey label typically gives you the first two, part of the third and not the fourth.
See the product in our MT5 gray label page.
Presentation layer
Record where your brand can appear: website, portal, emails and, where supported, terminal elements such as company or server name. For each location note: supported, unsupported or unknown. Resolve every unknown in writing.
Commercial layer
List the settings you can change: groups, account types, leverage, commissions or markups and visible symbols. Record the limits, such as maximum groups and the speed of change requests.
Operational layer
List the access you hold: manager logins, account actions, reports and any API access. Mark each as included, optional or unavailable. CRM integration and Manager API access are normally optional and quoted separately.
Platform core
Record what the provider controls: platform version, update schedule, server infrastructure and liquidity configuration. Ask how updates are communicated and tested.
Turn it into a register
Create a table with columns for capability, status, evidence and owner. Update it as the provider confirms items. If you outgrow the boundaries, compare with white label customization.
Example register rows
- Capability: show company name in terminal. Status: unknown. Evidence: none. Owner: provider contact.
- Capability: create trading group. Status: supported up to the listed limit. Evidence: written scope. Owner: broker.
- Capability: Manager API access. Status: optional, quoted separately. Evidence: quote. Owner: broker.
Turning every unknown into a confirmed or unsupported row is the goal.
Customization as layers with owners
Model customization as layers: presentation, commercial, operational and platform core. Each layer has a different change owner, a different change process and a different risk. Presentation changes (names, logos, messages) are low risk and owned by the broker. Commercial changes (groups, pricing) are shared. Operational changes (access, procedures) are broker-owned but need controls. Core changes belong to the provider.
For any requested change, first classify the layer, then determine the owner and the process.
A change classification table
| Change | Layer | Owner | Approval | Test |
|---|---|---|---|---|
| New logo in portal | Presentation | Broker | Brand lead | Visual check |
| New account type name | Presentation | Broker | Product lead | Statement and email check |
| New group with pricing | Commercial | Broker and provider | Product and risk | Pricing test |
| New manager role | Operational | Broker | Security lead | Negative tests |
| Platform update | Core | Provider | Provider notice | Regression suite |
Use the table in change requests so that the right people are consulted.
Configuration as a document
Keep the complete configuration in a controlled document or repository: groups, symbols, rules, branding assets, templates and integration settings, with change history. Where exports are possible, store them with a date. When behaviour surprises you, a version history shows what changed and when.
The document also supports migration: a clear record of configuration is the fastest route to rebuilding it elsewhere.
Regression checks
After any change, run a small regression suite: registration, provisioning, funding, trade, statement and report. Compare results with the baseline. For presentation changes, check rendering on desktop, web and mobile. For commercial changes, check pricing and report segmentation.
Automate what you can, and keep the rest as a checklist with evidence.
Worked example: a seemingly small request
A partner asks for a custom account type name and a lower commission. The name is a presentation change, but the commission is commercial and changes reports, partner statements and perhaps disclosures. The request is split into two changes, each classified, assessed and tested.
The lesson is to classify by effect, not by the wording of the request. A small-sounding change can touch several systems and several approvals.
Limits of customization and provider constraints
Record explicitly what is not available at any price, what requires a provider request and what you can change yourself. Include lead times for provider-executed changes.
This register of constraints prevents plans that depend on unavailable features and shows where a different model might be needed.
Documenting constraints for future teams
A configuration register records what is set; a constraints register records what cannot be set and why. Entries might include: terminal branding limited to server name, group count capped by plan, symbol list controlled by provider, API write access not included. Add the date, the source of the statement and the contact who confirmed it.
New team members and later vendor discussions benefit from this register. It stops repeated investigation of settled questions and records the points to revisit if circumstances or contracts change.
Frequently asked questions
What layers of customization exist?
Presentation, commercial, operational and platform core, each with different owners and risks.
Who owns platform core changes?
The provider. Plan around its release process.
Why keep configuration in a document?
For traceability, troubleshooting and migration.
What should a regression suite cover?
Registration, provisioning, funding, trading, statements and reports.