MT5 Grey Label Explained: A Technical Overview of the Entry Model
An MT5 grey label is an access model. Describing its actors, boundaries and integration points gives you the information you need to design around it.
Actors
The platform vendor, the provider holding the platform relationship, the broker operating the brand and the clients. Liquidity, payment and CRM vendors attach to the broker side.
Access boundaries
The broker typically has branded presentation, group configuration within limits and manager access for client accounts. The provider retains platform version, servers and core configuration. See the customization boundaries.
Configuration
Groups, account types, symbols, leverage and markups are configured within limits. Document current values and change procedures.
Integration points
CRM, payments, bridge and plugins connect through interfaces the setup allows. These are normally optional and quoted separately.
Capacity and cost
Listed setups support up to 500 clients, with one showing a larger Demo group, and run from $2,000 to $2,400 per month subject to confirmation. See our grey label page and the cost model.
Questions an architect would ask
- Which interfaces does my setup expose?
- What are the limits on groups, logins and symbols?
- How are updates communicated?
- What is the exit path and data export?
Capture the answers in your register.
Actors and boundaries
A grey label setup has four actors: the provider (platform environment), the broker (brand, clients, operations), vendors (CRM, payments, liquidity) and clients. Each has defined responsibilities and access boundaries. Write them as a responsibility matrix before engaging providers.
| Area | Provider | Broker | Vendor |
|---|---|---|---|
| Platform environment | Operates | Configures within limits | N/A |
| Client data | Platform records | CRM records | Processes per contract |
| Branding | Allows within limits | Owns assets | N/A |
| Integrations | Exposes interfaces | Owns workflows | Implements |
| Compliance | Own obligations | Own obligations | Own obligations |
Configuration and capacity
Configuration items include account types, groups, symbols, leverage, margin, pricing and manager permissions. Capacity items include client count, groups, logins, symbols and API usage. Capture each with its definition, limit and change process.
Use the list as the basis of the scope sheet and of acceptance tests.
Questions an architect would ask
- Which interfaces does the setup expose, and with what limits?
- How are updates communicated and tested?
- What is the exit path and the data export format?
- How are incidents classified and escalated?
Capture the answers in a register. See our architecture guide for the reference model.
Worked example: a first architecture sketch
On one page, draw the provider environment, your portal, CRM, payment provider and liquidity connection. Label the interfaces, owners and limits. Mark unknowns in red.
The sketch becomes the agenda for provider conversations, and each red item is a question to resolve before commitment.
Cost and capacity linkage
Link capacity limits to cost tiers in the sketch. If a registration funnel can exhaust the login allowance, note the control, such as demo expiry or rate limiting, and its cost.
Evaluating a provider’s technical maturity
Ask about environment segregation, release management, monitoring, incident communication, documentation quality and the support structure. Review the API documentation for clarity and completeness and ask for a sandbox.
A provider with disciplined engineering practice makes your integration work cheaper and more reliable.
Frequently asked questions
Who are the actors in a grey label?
Provider, broker, vendors and clients.
What should be in the scope sheet?
Configuration items, capacity limits, interfaces, support and exit terms.
How do I handle updates?
Agree notification, test windows and a regression suite.
What about regulation?
Each party has its own obligations. Take professional advice.