Specify what each source is expected to supply
| Item | Required record |
|---|---|
| Coverage | Source instruments, access conditions and intended platform symbols. |
| Interpretation | Decimals, contract context, sessions and any transformations. |
| Delivery | Connection method, environment and the provider responsible for it. |
| Health | Freshness expectations, missing-data signals and escalation. |
Availability and rights should be confirmed for the proposed use. A successful technical subscription does not replace confirmation of the relevant commercial permission.
Validate an instrument set, not only the connection
Start with representative instruments that cover the different session and contract behaviours the brokerage needs. Compare received values and timing with the agreed source, then examine the result in the intended platform configuration. Record exceptions, aliases and transformations in a versioned mapping document.
Discuss how the integration behaves when a source stops publishing or an instrument is unavailable. Any fallback requires its own validated mapping and operating procedure; the design should not assume that two instruments with similar names are interchangeable.
Handover source coverage and support ownership
The final scope should include a source-to-symbol map, tested cases, monitoring signals, configuration ownership and the external support route. State which source fees, rights and platform work remain separate. Keep the live mapping aligned with the configuration operators actually use.
For a new brokerage, include market data in the MT5 White Label deployment brief. For an existing environment, prepare the current mapping and a bounded list of desired changes. Use the feed troubleshooting guide when the immediate requirement is diagnosis rather than a new connection.