Build a requirement-to-evidence register
List the outcomes your brokerage needs and the evidence that would establish each one. Examples include supported client workflows, account models, instrument coverage, integration behaviour, operator access and recovery. Mark the owner of the evidence and the date it was reviewed.
Distinguish a provider statement, a live demonstration, a contract commitment and a production reference. They answer different questions. A demonstration can show a workflow; it does not establish the supplier's contractual responsibility or prove that your intended third-party arrangement is available.
Review the architecture for hidden dependencies
| Area | Evidence to inspect |
|---|---|
| Platform arrangement | Rights and access relevant to the exact proposed deployment |
| Connected services | Named suppliers, supported interfaces and ownership of failures |
| Operations | Monitoring, change control, escalation and administrator roles |
| Continuity | Backup scope, recovery assumptions and a restoration test result |
| Exit | Export formats, transition assistance and unresolved migration restrictions |
Ask who is accountable when two providers disagree about an incident. A system can be assembled from competent components and still have an unowned gap between them.
Use a short adversarial demonstration plan
In an authorised test environment, choose scenarios that expose boundaries: a repeated account-creation request, a stale price stream, a client access issue in another region and a partially completed integration workflow. Ask the operator to explain what happened using the evidence available to the support team.
Illustrative example: two proposals both mention CRM integration. One demonstrates initial account creation only. The other also shows error handling, status reconciliation and the owner of a failed update. The second supplies stronger evidence for that requirement; it does not automatically win unrelated categories.
Convert findings into a decision and conditions
Classify each finding by operational consequence and uncertainty. Some items can be closed before signature, others need an acceptance condition or a bounded exception. Name the decision owner and keep the reason for accepting a material dependency.
When evaluating an MT4 White Label provider, inspect existing-workflow and migration assumptions. For MT5 White Label, test the intended account and asset configuration. Request permission before using any client reference or logo, and verify certifications or licence statements with the issuing organisation where relevant. A prepared evidence register is more useful than a score assembled from unsupported brochure claims.
Distinguish evidence types
Can a client logo substitute for a technical reference?
A permitted logo may establish a relationship, but it does not explain the work performed or the relevance to your deployment. Request a reference or case with an appropriate scope and permission. Keep identity, delivery evidence and performance statements separate in the evaluation.
What should happen to an unverified supplier claim?
Mark it as unverified and identify the evidence needed to close it. Depending on importance, make it a pre-contract condition, an acceptance test or an explicitly accepted uncertainty. Do not convert a persuasive statement into a demonstrated capability by giving it a numerical score.