White Label vs Grey Label: A Capability and Trade-off Matrix
The decision between the models is a trade-off between control and operational load. A matrix makes the trade-offs visible and the decision explicit.
Capabilities to compare
Rows: platform configuration control, trading condition control, integration access, client and group limits, independence from provider, infrastructure responsibility, entry cost, ongoing cost and time to launch.
Typical profile: grey label
Lower entry cost, faster launch and less to operate, with tighter limits and more dependence on the provider. See the customization boundaries.
Typical profile: white label
Deeper control, wider integration access and more independence, with higher cost, more components and more operational responsibility. See the configuration surface.
Score against requirements
Weight each row by importance and score both models. Check that must-have requirements are met without workaround.
Plan the transition
If you start light, plan the move in the migration plan. Explore grey label, white label or send us your requirements.
Re-evaluation triggers
Define the triggers that would reopen the decision: reaching a percentage of the client limit, a requirement the current model cannot meet, or a change in provider terms.
Review them quarterly. A model chosen for today may not suit next year.
Capabilities to compare
| Capability | Grey label (typical) | White label (typical) |
|---|---|---|
| Platform control | Within provider limits | Broader |
| Branding depth | Client-facing, some terminal | Deeper |
| Integration access | Per setup | Broader |
| Operational burden | Lower | Higher |
| Growth headroom | Plan limits | Greater |
| Exit complexity | Moderate | Higher |
Treat the table as hypotheses to verify with each provider in writing.
Score against requirements
List requirements with weights, score each model on evidence and compute totals. Run a sensitivity check on the two most uncertain weights. If the ranking flips, gather more evidence before deciding.
Document the result with assumptions and approvers.
Transition planning and triggers
Plan the transition path in advance: data export, integration portability and notice terms. Define re-evaluation triggers such as client limit share, unmet requirements and cost per client. Review quarterly.
See our migration roadmap for the move.
Worked example: a scoring run
Requirements and weights: control 20, cost 25, speed 15, growth headroom 20, operational burden 20. Grey label scores 3, 5, 5, 3, 4 and white label scores 5, 3, 3, 5, 3 on a five-point scale. Weighted totals are close. A sensitivity check on cost and control weights shows the ranking flips within a ten-point change, so more evidence is gathered on cost and control constraints.
The record shows the data, the check and the decision.
Operating model implications
Choosing white label implies roles for platform administration, integration maintenance, incident response and compliance reporting. List the roles, staffing and training required and include them in cost and timeline.
Capacity planning for the operating model
Estimate the people and skills required for each model: platform administration, integration engineering, monitoring, support, compliance and finance operations. Compare with current capacity and identify hires or outsourcing.
The operating model often decides the outcome more than licence fees do, and it should be part of the scoring.
Frequently asked questions
How do I choose between models?
Score requirements with weights and evidence, then check sensitivity.
What are re-evaluation triggers?
Predefined conditions that reopen the decision, such as a share of client limit.
Why plan transition early?
To keep exit costs and risks known and manageable.
Are the typical profiles guaranteed?
No. Verify each provider’s actual terms in writing.