Broker price feed guides for buyers and technical teams.

Start with the decision you need to make

Price feed evaluation crosses several roles. Management needs to understand fit, responsibility, and cost structure. Dealing and risk teams need to understand pricing control and failure behaviour. Technology staff need to confirm delivery, monitoring, and continuity.

These resources explain those decisions without turning public pages into an implementation manual. Detailed credentials, network addresses, FIX mappings, client identities, and production thresholds stay in private onboarding material.

Use one example across every review

A representative case makes written evaluation faster. Choose:

• one normal symbol with a straightforward source and pricing rule;
• one difficult symbol with a special source mix, schedule, or calculation;
• one bad, stale, or unavailable source case;
• one destination such as a bridge, an MT4 or MT5 server, or a FIX consumer; and
• the expected primary and backup behaviour.

Management can use that case to confirm scope. Dealing and risk staff can check the pricing policy and protection response. Technology can verify the delivery path, observable state, and recovery expectations.

For product-specific detail, review market data sources , the custom pricing engine , quote protection , and delivery options .

Questions worth answering before a demo

A useful written request does not need to be a finished specification. It should identify:

1. the instrument groups and source accounts already available;
2. who owns pricing rules and who may activate changes;
3. target platforms, protocol preference, and connection direction;
4. primary and backup expectations;
5. monitoring or acceptance checks required by the client; and
6. the level of integration and ongoing support needed.

Do not send credentials or confidential network details through the public form. The goal is to establish fit and prepare a relevant demo feed, not to complete technical onboarding in the first message.

Keep evaluation tied to evidence

Ask what the team can inspect when a source fails, a quote is protected, a consumer slows down, or primary and backup disagree. Useful evidence may include a current rules view, clear status reasons, simultaneous samples from both endpoints, and a deliberate disconnect and recovery check.

The resources below can be shared across teams and reviewed in writing. If a question is specific to your setup, start a demo request and include the question in your email reply.