Describe each contract and its account context
Create a contract record covering its platform name, source identifier, asset class, currency relationships, trading sessions, volume rules and approved commercial settings. Identify the groups and account types that will expose it. Record effective dates for scheduled changes.
MT5 supports netting and hedging arrangements. Confirm the configuration used by the account under test before interpreting order, deal or position results. A test written for one accounting arrangement should not silently be reused for another and then treated as a platform failure.
Check pricing and execution as separate paths
Identify where the displayed price originates and where a permitted order is routed. These dependencies may involve different services and owners. Match the source identifier to the configured contract, then verify what happens when prices are stale or a route is unavailable in an agreed test environment.
- Compare timestamps and price freshness through the permitted observation points.
- Inspect session boundaries and instrument-specific availability.
- Check how rejected or incomplete requests appear to operations staff.
- Verify that the reporting and CRM layers retain the intended instrument identity.
Do not infer execution performance from a chart update or a network ping. Keep evidence for each path separate.
Build tests around the trading model
| Scenario | Expected evidence |
|---|---|
| Representative account and contract | Correct visibility, specification and permitted actions |
| Account-model behaviour | Order/deal/position records interpreted against the configured model |
| Currency and reporting | Consistent currency labels and values across authorised views |
| Session transition | Agreed behaviour around market availability and scheduled boundaries |
| Dependency interruption | Detection, operator explanation and controlled recovery |
Use the actual proposed configuration and approved test data. The purpose is to discover disagreements between layers, not to assume one universal setting for every market.
Keep contract changes traceable
Illustrative example: a broker introduces a new asset class. The terminal displays prices, but the downstream report treats its identifier as an existing contract. The fix belongs to the integration and reporting mapping as well as the instrument definition; changing only a terminal label would hide the mismatch.
Retain the previous specification, approval, test results and release time. Update the instrument register and notify the owners of connected systems. Bring this record into the MT5 White Label implementation scope, particularly when the launch includes more than one account model or asset class.
Questions that prevent false acceptance
Why include the account model in an instrument test?
The same user action can produce records interpreted differently under the configured accounting arrangement. Capture that configuration with the test so reviewers know what behaviour was expected. A symbol-only worksheet cannot explain every account, order and position outcome.
Can we activate a new instrument after prices appear?
Price visibility is one prerequisite. Also review the approved specification, account permissions, intended execution connection and downstream reporting. Decide whether any launch-critical test remains outstanding. Availability in a source catalogue does not establish the terms of your deployment.