Give each mapping an explicit identity
Keep a register containing an internal contract reference, source provider, source identifier, platform symbol, reporting identifier and applicable account groups. Record the intended instrument specification and its effective date separately from the display name.
Names alone are not reliable matching keys. Similar labels can refer to different contract definitions, and the same contract may use different suffixes across systems. Record why a match is valid and who approved it. Ambiguous mappings should remain unresolved rather than being guessed from a familiar abbreviation.
Record transformations as configuration, not memory
| Mapping field | Review question |
|---|---|
| Name and suffix | Will every downstream consumer recognise the intended contract? |
| Precision and units | Are displayed values and quantities interpreted consistently? |
| Currency context | Do platform and reporting definitions agree? |
| Session and calendar | Is expected availability consistent across the delivery chain? |
| Lifecycle | How are replacements, retirements and historical records handled? |
If an adapter applies a conversion or normalisation, document the rule and supported configuration location. Do not apply an ad hoc correction to a production contract without verifying its commercial and operational consequences.
Validate joins across all consumers
- Compare source and platform records for a representative set of contracts.
- Verify how the client interface displays names and specifications.
- Follow the same instrument into CRM and operational reporting.
- Check history, renamed contracts and any required legacy identifiers.
- Capture a mismatch case and demonstrate the authorised correction process.
Include instruments that are easy to confuse, not only those with obvious one-to-one names. For a provider transition, compare the old and new mapping registers side by side and flag changed assumptions.
Keep a dated mapping baseline and review route
Illustrative example: two sources use a similar label for instruments with different session arrangements. A name-only match looks successful during overlapping hours, then produces a missing-price report later. The mapping register makes session assumptions part of acceptance instead of treating them as a network fault.
Assign an owner to additions and amendments, retain approved previous mappings and update downstream teams when an identifier changes. Include this register in the MT4 configuration handover or the MT5 instrument scope. A small, verified mapping catalogue is safer to operate than a large catalogue assembled through unreviewed automatic name matching.
Resolve ambiguous identifiers
Can contracts be matched by the nearest name?
Use name matching only to identify candidates for review. Confirm contract identity and the relevant specification before approval. A similar label can hide a different session, unit or currency relationship, and an automated guess should not become a production mapping without validation.
What happens when a source identifier is retired?
Record the effective date, intended replacement and effect on every consumer. Preserve the relationship needed to interpret historical records. Test the update through platform and reporting views, then retain the previous approved mapping as part of the change record.