Distinguish available prices from executable capacity
Record what each source supplies and what its interface permits. Instrument identifiers, quantities, sessions and access conditions must be mapped consistently. A displayed price and an accepted execution instruction are separate observations and may follow different service paths.
The brokerage and its counterparties determine the commercial and execution arrangements. The technology review should preserve those boundaries and avoid inferring an entitlement or outcome from a live connection.
Define how sources remain identifiable
| Area | Review requirement |
|---|---|
| Normalisation | Map names, units, timestamps and session conventions before comparison |
| Decision record | Identify the source and configuration used for an approved decision |
| Instruction lifecycle | Trace accepted, rejected and unresolved states by source |
| Dependency loss | Define handling when one source is stale, unavailable or restricted |
| Reconciliation | Compare final records and route discrepancies to an operating owner |
If the proposed system applies selection or routing rules, request the actual supported controls and their change history. Do not substitute a general aggregation diagram for a demonstrated product configuration.
Test sources independently as well as together
Illustrative aggregation test: one test source stops publishing an instrument while another remains active. The review checks whether the system identifies the stale source, applies the approved response and retains enough evidence to explain the result.
Include a rejected instruction and a mismatched instrument case in the agreed test pack. Confirm that operators can distinguish a source limitation from an adapter, configuration or reconciliation problem. Acceptance should record the tested source set and any exclusions, so adding another provider is treated as a reviewed change.