Define the data product you actually need
List the instruments, intended use, required delivery interface, account or group coverage and operating sessions. Confirm source rights and redistribution conditions with the relevant data provider. A technically reachable stream does not by itself establish permission to use it in your proposed brokerage service.
Record whether the source supplies indicative prices, a particular market view or another agreed data product. Define who confirms the instrument specification and which parties own changes. Do not assume that connecting prices also supplies liquidity or determines the execution arrangement.
Map and validate the complete price path
- Identify the source instrument and the platform contract it should populate.
- Confirm naming, precision, currency and session assumptions.
- Observe the permitted timestamps or freshness indicators through the delivery path.
- Check representative client accounts for instrument visibility and updates.
- Compare the platform view with the authorised source observation point.
- Record how stale, missing or unexpected data is detected and escalated.
Keep the observation interval and market conditions with the result. A screenshot of one valid tick is weak evidence for session transitions or an intermittent source interruption.
Separate common symptoms before investigating
| Symptom | Initial investigation |
|---|---|
| One instrument has no updates | Source availability, mapping, session and platform permissions |
| A group of instruments is stale | Shared upstream source or connection and its monitoring |
| Source current, client view delayed | Ingestion, downstream distribution and client access path |
| Unexpected contract behaviour | Specification and mapping, not only price values |
Preserve evidence before changing several settings at once. An unexplained replacement feed can conceal the initial problem and introduce new contract or entitlement differences.
Test resilience without assuming automatic continuity
Illustrative example: a second source is intended as a fallback, but its instrument names and session schedule differ. The fallback connection works while the client-facing catalogue becomes inconsistent. Rehearsing the source-to-contract mapping exposes the gap before an actual interruption.
Agree how a switch is authorised, which source properties may change and how the operator knows the new path is acceptable. Include monitoring and escalation ownership in the market-data integration scope. For MT4 and MT5, validate the configured environment and connected adapter rather than assuming identical delivery behaviour.
Set sensible feed acceptance boundaries
Is a quiet instrument always a broken feed?
No. Check the intended session, source product and expected activity before diagnosing a fault. Compare the permitted source observation point and related instruments. An alert should distinguish expected inactivity from an unexpected interruption using the agreed data-product assumptions.
Does a second data source guarantee continuity?
Not by itself. Confirm rights, contract identity, mapping, sessions and the controlled switching procedure. Test the resulting platform view and monitoring. A reachable replacement stream can still be unsuitable for the client-facing contracts it is expected to populate.