Make source data comparable first
Map instrument identity, quote fields, precision, quantity conventions and timestamp meaning. Identify session differences and any source-specific flags. Comparing unnormalised fields can create apparent price differences that are really configuration differences.
The output use case determines which processing rules are appropriate. A display stream, an operational reference and an execution-connected workflow can have different requirements. Data-use rights and permitted publication remain separate from the processing method.
Write the selection and exception rules
| Rule area | Question to answer |
|---|---|
| Eligible sources | Which sources and instruments are permitted for this output? |
| Freshness | How are expected sessions, stale input and gaps recognised? |
| Selection | Which documented method produces the downstream value? |
| Traceability | Can a result be related to its inputs and configuration version? |
| Unavailable output | What is published or signalled when no eligible source remains? |
Rules should be explainable and testable. Do not describe an output as the “best price” without defining the selection method, available source set and intended meaning.
Use controlled input examples
Illustrative processing test: two authorised test sources publish the same instrument using different names and timestamp conventions. After normalisation, one source becomes stale. The reviewer checks the approved selection result and the diagnostic record.
The test pack should also include missing fields and an unknown instrument so that rejected data cannot silently enter a default output. Retain the mapping, processing configuration, input samples and expected outcomes in the handover. For multi-provider execution requirements, review liquidity aggregation separately; producing a combined quote does not establish executable capacity.