Start with the MT4 workflows you must preserve
Write a short inventory before requesting proposals. Include account groups, instrument names and suffixes, reporting, Expert Advisors, manager workflows and every bridge or CRM dependency. Separate a new brand launch from a change to an existing installation: those projects have different continuity requirements.
For an existing brokerage, identify which data and configurations you can export and which changes require the incumbent provider. A promise to migrate is incomplete until the relevant parties confirm access, formats and responsibilities. Do not assume that a familiar terminal appearance means the backend arrangement is interchangeable.
Ask for a demonstration with your own test script
- Create a test account in the intended group and verify its permissions.
- Open the required instruments and inspect contract details, trading sessions and displayed prices.
- Submit representative permitted orders in a test environment and compare the resulting account and operational records.
- Walk through the CRM account-creation and account-status workflow.
- Ask the provider to demonstrate the support route for a failed connection or an incorrect configuration.
Keep a result sheet with expected behaviour, observed behaviour and unresolved questions. A recorded answer is more useful than a generic presentation that never touches your dependencies.
Compare access and commercial scope on one page
| Decision | Evidence to request |
|---|---|
| Platform and branding arrangement | Written rights, interfaces and restrictions for the proposed project |
| Administrative control | Role matrix showing permitted changes and escalation owners |
| Connected services | Named CRM, bridge, data and hosting components, with exclusions |
| Ongoing operation | Support window, incident route, backups and restoration responsibilities |
| Exit | Export formats, assistance boundaries and migration dependencies |
Separate implementation work, recurring services and third-party charges. An attractive headline is difficult to compare if market data, integration changes or migration assistance are left undefined.
Use unresolved dependencies as the final selection test
Illustrative example: a brokerage needs to preserve an MT4 CRM connection and several instrument suffixes. Provider A demonstrates a terminal but cannot identify the CRM adapter owner. Provider B identifies the adapter, stages account creation and records the symbol mapping. The useful distinction is demonstrated compatibility, not the number of features in a brochure.
Before selecting a provider, assign an owner and due date to every open item. Review the TSG MT4 White Label deployment scope against that list. Agree the acceptance record and handover documents before making the production environment dependent on the new service.
Questions to settle before the proposal
Is a working MT4 terminal enough to approve the provider?
No. It establishes only part of the client interface. Your approval should also cover the intended account groups, required integrations, operating permissions and incident process. Keep a separate result for each requirement so an attractive demonstration cannot conceal an unresolved dependency.
How should an incumbent-provider dependency be handled?
Record the required access or export, the party controlling it and the confirmation needed. Make the project conditional on that evidence where necessary. A new supplier cannot reliably promise continuity for data, credentials or settings controlled by another organisation without checking the arrangement.