MT5 Grey Label Groups: Design the Configuration Map
A group allowance should support a configuration plan, not become the plan itself. For an MT5 grey label setup, give every intended trading group a documented purpose and relate it to the account journey. That makes both onboarding and later changes easier to discuss.
Map groups to real account categories
Write down the account categories your operation needs and explain why each requires a separate configuration. Ask the provider what the selected setup can support. The listings describe up to six trading groups; that is a boundary to confirm, not a reason to create six groups without an operating need.
Keep demo requirements explicit
The Prop Ready offer describes up to 7000 clients for its Demo group. Preserve that qualifier in diagrams, requirements, and acceptance checks. Do not use the demo number as a live-capacity figure. If your plan includes several account categories, request their allowances and configuration details separately.
Connect the group map to other systems
Explain how an approved CRM request identifies the intended account category and how staff verify the resulting platform group. Decide where the mapping is documented and who approves a change. Avoid scattering the same decision across a website form, a spreadsheet, and an integration rule without an agreed owner.
Control changes after handover
Record the reason for a proposed change, the affected workflows, and the checks required before it is accepted. Ask whether the provider must perform or approve the configuration. The map should remain understandable when a new operator joins the team. A few well-documented groups are more useful than a larger set whose purpose and dependencies are no longer clear.
From account categories to groups
Start with the categories you serve: standard retail, low-spread with commission, partner-introduced, staff or test, demo. Map each to exactly one group or a small family of groups, and write the purpose, the pricing rules and the entry criteria for each. A group with no clear purpose is a candidate for deletion.
Because groups are usually limited in number and are referenced by other systems, a short, well-named list is easier to operate and cheaper to maintain.
A group specification table
| Group | Purpose | Leverage and margin | Pricing | Entry rule | Owner |
|---|---|---|---|---|---|
| Standard | Default retail | Defined | Spread plus markup | Approved retail client | Operations |
| Active | Frequent traders | Defined | Lower markup plus commission | Meets activity criteria | Operations |
| Partner | Introduced clients | Defined | Partner pricing | Partner code | Partner manager |
| Demo | Practice | Fixed | Fixed | On request | Support |
| Test | Staff testing | Fixed | None | Staff only | Operations |
Keep the table in version control or a controlled document. Every change to a group should be a change to this table first.
Demo requirements and capacity
Demo accounts often share group allowances and login limits with live accounts, depending on the provider. Confirm the rules, and decide whether to use a dedicated demo group, cap demo account creation or expire inactive demos. Without limits, a successful marketing campaign can consume the allowance with accounts that will never fund.
Model the number of demo, live, partner and test accounts you expect each quarter and compare with the limit.
Cross-system consistency
The group map must be reflected in the CRM (so provisioning chooses the right group), reporting (so segments are comparable) and partner configuration (so commissions use the right basis). Maintain a single mapping table from CRM account type to platform group, and test that provisioning and reports use it.
When a group is renamed or retired, update the mapping and run the acceptance cases for provisioning and reporting.
Change control after handover
Post-handover changes to groups affect live clients. Use a simple process: request, impact assessment (clients affected, reports affected), approval, test in staging if possible, change window, verification and log entry. Notify clients when conditions change.
See our customization guide for the layered view of what can be configured.
Worked example: introducing a partner group
A partner requests different pricing for introduced clients. The team writes a group specification row, checks the group allowance, drafts the CRM mapping (partner code to group) and updates reporting segments. In staging, a test registration with the partner code is provisioned to the new group and a report shows the segment. The change is approved, applied in a window and verified in production with a test account.
Clients already provisioned remain in their groups unless a migration is approved separately, which is its own change with its own impact assessment.
Naming and documentation
Adopt a naming convention that encodes purpose, region or channel and version where needed, and document it. Avoid names that become misleading after pricing changes.
Keep the specification table, mapping table and reporting segment definitions in one place and review them quarterly to remove unused groups and correct drift.
Reporting and risk consequences of group design
Group design affects reporting and risk more than it first appears. Reports that segment by group inherit the design: if one group mixes retail and partner clients, partner performance cannot be separated without extra tagging. Risk limits and monitoring may also be configured per group, so a group that mixes behaviours forces compromise.
Before finalising the group list, write the reports and risk views you expect to need and check that each can be produced from group membership or from explicit tags. Where groups cannot carry the distinction, add a CRM attribute and document that it is the source for the segment.
Frequently asked questions
How many groups should I create?
As few as the account categories require. Each needs a purpose, pricing and entry rule.
Do demo accounts count toward limits?
It depends on the provider. Confirm and design controls such as caps or expiry.
How do I keep groups consistent with the CRM?
Maintain a single mapping table and test provisioning and reports against it.
How should group changes be controlled?
Through a request, impact assessment, approval, test, window and log.