MT5 Grey Label Setup: A Technical Runbook From Requirements to Acceptance
Treat the setup as a runbook: ordered steps with inputs, outputs and verification. This version covers a grey label from requirements to acceptance.
Step 1: requirements
Document target markets, account types, expected clients, required integrations and constraints. Output: a requirements document. Verification: reviewed by the people who will operate the system.
Step 2: scope confirmation
Obtain the provider’s written scope: access, groups, logins, symbols, support hours and exit terms. Output: a capability register. See the customization boundaries.
Step 3: configuration
Define groups, account types, symbols, leverage and branding assets. Output: a configuration document. Verification: compared line by line with the requirements.
Step 4: integrations
Connect CRM, payments and any other tools in the minimum viable order. Output: connection diagrams and test results. See our setup guide.
Step 5: acceptance testing
Run test cases for registration, funding, trading, withdrawal and failure scenarios. Output: signed test report. Reference: the setup checklist.
Step 6: controlled launch
Open to a limited group, monitor, review daily and fix defects before expanding. Record lessons in the runbook.
Verification checklist per step
For each runbook step define the verification: who checks, what artefact proves it and where the artefact is stored. Examples: configuration export, test report, signed approval.
A step without verification is only a plan. Keep the artefacts together for audits and later changes.
Setup as a gated pipeline
Treat setup as a pipeline with gates: requirements gate, scope gate, configuration gate, integration gate, acceptance gate and launch gate. Each gate has entry criteria, artefacts and an approver. Work moves forward only when the artefacts exist.
Gated setups are slower to start and faster to finish, because rework from skipped steps is the main source of delay.
Artefact and verification table
| Step | Artefact | Verification | Stored where |
|---|---|---|---|
| Requirements | Requirements document | Reviewed and signed | Project folder |
| Scope | Signed scope sheet | Matches quote and contract | Project folder |
| Configuration | Config export or screenshots | Compared with requirements | Config repository |
| Integrations | Test records per workflow | All cases pass | Test folder |
| Acceptance | Test report | Signed by owners | Project folder |
| Launch | Go-live checklist | Evidence reviewed | Project folder |
A step without an artefact and a verification is only a plan.
Integration and acceptance testing
Test each integration workflow with defined cases, including failures: timeouts, duplicates, invalid inputs and permission denials. Execute the full client journey from registration to withdrawal in staging, then with a pilot group in production.
Record results and defects, retest after fixes and keep the evidence for audits.
Controlled launch
Launch to a restricted group with monitoring and a defined rollback or pause procedure. Define launch metrics and thresholds: error rates, time to verify, funding success. Review daily for the first week. Widen only when thresholds are met.
See our readiness checklist for gate criteria.
Worked example: a configuration gate
At the configuration gate, the technical lead exports groups and symbols and diffs them against the requirements table. Two differences are found: a leverage value that differs and a symbol category missing. Each is corrected by the provider, the export is repeated and the gate is passed with the second export attached.
The gate prevented a pricing error from reaching clients and left an artefact that proves what was configured on the date.
Handover and documentation
Produce a handover pack: architecture diagram, configuration record, runbooks, contact sheet, test report and open items list. Assign an owner for each document and a review cadence.
Treat the pack as part of the deliverable, and include it in the acceptance criteria.
Lessons-learned and baseline update
After launch, hold a review comparing plan and actual for each step: duration, effort, defects and decisions. Update the setup template with improved estimates, additional checks and clarified responsibilities.
A setup process that learns from each project becomes faster and more reliable, and it provides a defensible basis when the next market, brand or platform change is planned.
Frequently asked questions
Why use gates in setup?
They prevent skipped steps and rework by requiring artefacts and approval.
What should acceptance testing include?
Normal and failure cases across the full client journey with recorded evidence.
How do I run a controlled launch?
Restrict the group, monitor thresholds, define a pause procedure and widen gradually.
Where should evidence be stored?
In a shared, versioned project folder.