Record the fields needed to explain the match
| Field | Reason to record it |
|---|---|
| Identifiers | Source, platform and destination names, including aliases or suffixes. |
| Contract context | The instrument and the relevant specifications that must correspond. |
| Representation | Decimals, units and any approved transformation. |
| Sessions | Expected availability and time-related assumptions. |
| Ownership | Who approves, implements and verifies a mapping change. |
The exact fields depend on the supported systems and workflow. Mark unsupported or unknown items instead of assuming every connector exposes the same configuration controls.
Validate pricing and execution separately
For the data path, compare representative received values with the source and examine transformations. For an execution connection, verify the intended destination instrument and available request/result evidence in an authorised test arrangement. Passing one path does not automatically validate the other.
Include instruments with different sessions or representations where they are part of the required product set. Check the approved record against the actual environment and keep the tested configuration version with the result.
Make changes reviewable
Propose mapping changes with their reason, affected systems, validation steps and rollback decision. Review any downstream reporting or CRM dependencies before applying them. An alias that fixes a display issue can still affect a connector or reconciliation workflow.
Use the detailed mapping checklist and the platform-specific MT4 or MT5 configuration guide. For a wider implementation, attach the instrument map to the corresponding MT4 or MT5 deployment brief.