How to verify a broker price feed.

What price feed verification should prove

Verification should show that the feed is using the intended sources and rules, producing valid prices for the expected symbols, delivering them to the client connection, and behaving predictably when a source or endpoint fails.

No single measurement proves all of that. Server uptime does not prove quote validity. A configuration checksum does not prove that sources agree. A live quote does not prove that the backup is ready. The checks work together.

The verification layers

The client decides what “acceptable” means for its instruments and use case. Public pages do not prescribe one universal price-difference, latency, or inactivity threshold.

Begin with representative symbols

A useful test set is small enough to understand and broad enough to expose different behavior:

• one liquid symbol with a straightforward source path;
• one instrument built from several sources;
• one synthetic or calculated instrument if used;
• one symbol with a scheduled policy change;
• one less-active symbol where silence can be normal; and
• one symbol suitable for a controlled failure scenario.

For each symbol, record its expected inputs, pricing rule, precision, spread policy, protection behavior, and destinations. This makes a difference explainable instead of merely red.

Check configuration before comparing prices

Primary and backup prices can differ for legitimate timing reasons, but they should not silently use different intended rules.

CoinPriceFeeds exposes a compact fingerprint of the loaded pricing configuration. Check it on both endpoints before interpreting a quote difference. If the fingerprints disagree, resolve the configuration difference first. If they agree, the investigation can focus on source state, timing, or delivery.

The fingerprint represents rule content rather than the moment at which it was loaded. Two servers can therefore confirm the same intended policy even when their reload times differ.

Compare live behavior, not one snapshot

A single matching quote is weak evidence. Observe a representative period and record:

• final bid and ask;
• mid-price and spread difference;
• update count or activity rate;
• symbols moving on one endpoint but not the other;
• invalid or crossed output;
• last observed update time; and
• the configuration fingerprint.

The comparison period should include normal movement for the chosen instruments. A quiet market may require a different test window or an explicit keepalive check.

Exercise one controlled failure

Healthy-source testing proves only the easiest case. A demo or acceptance test should exercise a safe representative failure, such as an input becoming explicitly unavailable or stale.

The expected outcome should be written before the test:

1. the failed input stops qualifying;
2. dependent outputs are recalculated from valid alternatives, held, or marked unavailable according to policy;
3. the reason is visible;
4. unrelated symbols continue where possible;
5. monitoring records the event; and
6. recovery requires only the actions agreed for that condition.

Do not run destructive failure tests against an active client feed without an agreed maintenance and rollback plan.

Verify from both sides

Service-side monitoring explains what the pricing engine believes it sent. Client-side observation explains what crossed the client’s network edge and parser.

Useful acceptance evidence combines both:

• CoinPriceFeeds monitoring and dashboard state;
• the client bridge or FIX-session logs;
• a reference streaming client where appropriate;
• Feed Checker for a quick visual inspection;
• simultaneous primary/backup comparison; and
• a written result listing thresholds, exclusions, and unresolved differences.

The Feed Checker is useful for human inspection, while the monitoring overview describes broader operational signals.

Record the method with every result

A quotable number without context is not useful evidence. A verification result should identify:

• date, time zone, and observation period;
• client-side or service-side measurement point;
• endpoints and symbol set;
• configuration fingerprints;
• selected thresholds;
• source or market conditions;
• exclusions and known limitations; and
• who reviewed the result.

This prevents a short lab test, regional network measurement, or unusually active market period from being presented as a universal service guarantee.

Keep sensitive details private

Public methodology can explain what is checked. Actual credentials, hostnames, client symbol maps, network paths, alert destinations, protection thresholds, and incident records belong in the authorized client scope.