How to evaluate a brokerage price feed.

Begin with the price, not the vendor list

The first question is not “How many sources are supported?” It is “How should the price for this symbol be built?”

Choose a few representative cases:

• a straightforward instrument from one institutional source;
• a symbol that needs a multi-source consensus;
• an instrument with a strict fallback order;
• a synthetic cross;
• a symbol with special weekend or session pricing; and
• a market where one bad tick would be costly.

For each case, write down the intended result in plain language. That becomes a far better evaluation than ticking boxes on a broad connector list.

1. Evaluate the inputs

Ask which source categories can enter the same feed:

• institutional FIX liquidity;
• direct exchange data;
• independent reference markets;
• prices from your own platform or bridge; and
• proprietary or client-side sources.

Then ask how source identity is preserved. Can one symbol use a median while another uses a named primary and backup? Can the same venue instrument map to the symbol names your systems already use?

Confirm who is responsible for venue accounts, credentials, market-data entitlements, and instrument availability. A connector does not create permission to use a venue’s data.

See market data sources for the CoinPriceFeeds approach.

2. Evaluate pricing control

Ask who can change:

• source priority or aggregation;
• markups;
• minimum and maximum spreads;
• precision and rounding;
• the list of published symbols;
• weekday or session schedules; and
• movement or gap controls.

Find out whether every change requires a support ticket or software deployment. If the client can make changes, check how invalid input is handled and whether the previous working configuration stays active.

Also ask how a team confirms which rules are live on each server. A revision in a spreadsheet is not useful evidence if the production feed loaded something else.

Read about the client-controlled pricing engine.

3. Test failure behaviour

A demo with healthy sources proves only the easiest case.

Ask the provider to explain:

1. What happens when a source publishes a large abnormal jump?
2. What happens when a venue explicitly withdraws a quote?
3. What happens when a connection stays open but prices stop?
4. What happens when an old update arrives after a newer one?
5. What happens to synthetic or aggregated symbols that depend on the failed input?
6. Can a zero, negative, non-finite, or crossed quote leave the system?
7. How does an authorized client operator see and recover a protected state?

The answer should distinguish those cases. “We have failover” is too broad.

Review quote protection before designing the test.

4. Evaluate the delivery path

Choose the smallest protocol that fits the downstream system.

A simple line-based stream may be ideal for a bridge under your control. FIX may be a better match for a platform or liquidity workflow that already uses market-data sessions.

Confirm:

• who initiates the connection;
• how authentication and credential rotation work;
• whether subscriptions are per consumer;
• how keepalive is represented;
• whether one slow consumer can block others;
• what happens after reconnect;
• how many concurrent consumers are expected; and
• whether primary and backup endpoints behave the same way.

Do not rely on a claim of “platform support” alone. Ask whether the provider supplies a native plug-in, connects to your existing bridge, or provides a protocol for your team to integrate.

See delivery and integration options.

5. Make redundancy testable

A second hostname is not enough.

Ask whether primary and backup:

• run at the same time;
• consume the same effective inputs;
• expose the pricing version they have loaded;
• can be compared symbol by symbol;
• preserve pricing state through routine restarts;
• use sufficiently independent network and DNS paths; and
• are tested before a production failover.

Decide who performs failover and how it is rehearsed. The provider may keep both links ready while the client bridge decides when to switch.

Read redundant feed design.

6. Look beyond “up”

Useful feed monitoring should answer:

• Are source quotes arriving?
• Are client prices being produced?
• When was the last delivery for each feed?
• Are consumers connected?
• Is delay upstream, inside processing, or at the send path?
• Are sources being invalidated?
• Do primary and backup agree?
• Is activity unusually low for this time of week?

Ask which signals can enter your own monitoring and which remain visible only to the provider.

See monitoring and verification.

7. Review client access and change boundaries

Identify everyone who needs to inspect the feed and everyone who should be allowed to change it.

A sensible model separates readers from writers, protects browser actions against unauthorized requests, records privileged changes, and lets the client remove access when staff changes.

Ask whether a third-party permissions outage can lock every existing user out, and whether private sources are isolated between client accounts.

Read the security and access overview.

8. Agree the operating model

Clarify the work on both sides:

Avoid treating an unqualified uptime percentage as a substitute for these answers.

9. Ask for evidence

Useful evidence includes:

• a representative rules view;
• a dashboard view with a protected or invalid source;
• a primary/backup configuration comparison;
• simultaneous quote samples from both endpoints;
• a reference client completing the real handshake;
• a deliberate disconnect and recovery;
• an example validation failure that leaves the old rules active; and
• a clear change log after a privileged action.

A high-quality provider should be able to explain what the evidence means, not only show a green screen.

10. Scope with enough detail—then stop

The evaluation stage should establish that the product fits. Detailed thresholds, FIX mappings, connection settings, credentials, and deployment arrangements are agreed during technical onboarding.

That boundary protects both sides: the client receives the details needed to integrate, while sensitive operational and client-specific information does not become a public implementation guide.