Aggregation guide
Market data aggregation: choosing a rule, not just more sources.
Aggregation is a pricing policy for deciding which valid inputs shape a quote. The useful question is not how many sources you can add, but what role each source should have for each instrument.
- Define eligibility before combining prices.
- Choose a method that fits the instrument and business purpose.
- Keep fallback, protection, and commercial controls explicit.
Source roles first
Decide which inputs are primary, independent references, fallbacks, or client-owned prices.
Per-symbol policy
A liquid FX pair, a metal, and a crypto CFD do not need the same aggregation rule.
Explain the result
The live feed should show which policy is active and why an input no longer qualifies.
On this page
Market data aggregation means applying a defined rule to several eligible price sources. It does not mean averaging every number that arrives. A sound policy first decides which sources are valid and suitable, then combines or prioritizes them, applies the brokerage’s commercial controls, and protects the resulting quote.
What aggregation is meant to solve
Brokerages consider aggregation for different reasons:
- to reduce dependence on one input;
- to form a reference from several independent markets;
- to keep a preferred source while making a valid fallback ready;
- to combine institutional, exchange, reference, or proprietary prices;
- to apply one consistent pricing policy across several platforms; or
- to handle instruments whose useful source mix changes by session.
These are not the same requirement. “Use three sources” is incomplete until the role of each source and the expected result are clear.
A practical aggregation sequence
The client-level flow can be understood in five steps:
Swipe or scroll horizontally to see all columns
| Step | Decision | Example question |
|---|---|---|
| 1. Qualify inputs | Is the source authorized, available, fresh, and valid for this symbol? | Should a frozen or withdrawn quote still count? |
| 2. Apply the source policy | Combine eligible inputs or follow a priority order | Should this symbol use a median or a preferred source? |
| 3. Build a two-sided base quote | Preserve a sensible bid and ask result | Does the method still produce a valid spread? |
| 4. Apply commercial rules | Add markup, spread, precision, rounding, or schedule controls | What should the client-facing quote look like? |
| 5. Protect and deliver | Reject impossible output and send the accepted result | What happens during an abnormal jump or source loss? |
This sequence separates source selection from commercial pricing. It also makes failures easier to explain. The complete price-feed path connects these steps to delivery, backup, and monitoring.
Common ways to use several sources
No method is best for every market. These are useful policy patterns rather than promises about a specific instrument:
Swipe or scroll horizontally to see all columns
| Method | What it does | Often useful when | Important question |
|---|---|---|---|
| Median | Selects the middle view from a valid group | One outlier should not dominate a reference price | Are the sources sufficiently independent and comparable? |
| Average | Calculates a mean across eligible inputs | The client deliberately wants every selected input to influence the result | How much should an extreme but still valid input affect the output? |
| Conservative wide view | Uses a cautious bid-and-ask range across valid sources | The business prefers not to publish a tighter view than the selected markets support | Could one weak source make the result unnecessarily wide? |
| Priority with fallback | Uses the first suitable source and moves down a defined order when needed | A preferred source has a clear business role | What makes a backup eligible, and how does recovery work? |
| Client price plus references | Keeps a proprietary or platform price central while using other markets as context or alternatives | The brokerage already has an internal pricing view | Is the proprietary input authorized, timely, and mapped consistently? |
| Scheduled policy | Selects a different prepared rule by time or weekday | Source availability or commercial treatment changes by session | Which schedule wins at transitions, and how is it reviewed? |
CoinPriceFeeds can apply different patterns to different symbols in the same client feed. Detailed rules and thresholds are agreed privately for the specific use case.
Median and average are not interchangeable
A median reduces the influence of one unusually high or low member of a group. An average lets every eligible member affect the result.
That difference matters even when both methods use the same sources. A median may suit a reference view built from several comparable markets. An average may suit a policy where the contribution of every selected input is intentional.
Neither method decides whether a source is good enough to enter the group. Freshness, availability, instrument mapping, and contractual permission still come first.
Priority is also an aggregation policy
Aggregation does not have to blend prices.
A source-priority rule can keep one input preferred while another remains ready as a fallback. The backup should not qualify merely because the primary stopped; it still needs to be valid and fresh enough for the instrument.
The recovery decision matters too. Some policies can return to the preferred source as soon as it is suitable. Others may call for a more deliberate transition. That behaviour should be written down and tested rather than inferred during an incident.
Start with the source roles
Before choosing a formula, describe why each source is present.
Swipe or scroll horizontally to see all columns
| Source role | Plain-English purpose |
|---|---|
| Preferred pricing input | The normal basis for the client quote |
| Consensus member | One comparable input in a combined view |
| Independent reference | Context for validation, comparison, or a separate rule |
| Fallback | A defined alternative when an earlier choice is unsuitable |
| Proprietary input | A price supplied by the client’s own platform or calculation |
| Session-specific input | A source intended only for selected times or policies |
A single venue can have different roles for different symbols. Source identity therefore needs to remain visible inside the pricing flow rather than disappearing into one undifferentiated number.
Read more about supported market data source categories and symbol mapping .
Source count is not the same as resilience
Several sources can still share the same dependency, copy the same market, or become unavailable at the same time. More inputs can also add more instrument mapping, entitlement, monitoring, and incident work.
Useful diversity is about roles and failure boundaries, not a headline count. When reviewing a source group, ask:
- Are these prices genuinely relevant to the intended instrument?
- Does the brokerage have the right to use each one?
- Are their symbols, trading sessions, and quote conventions comparable?
- How does the feed recognize stale, withdrawn, or invalid data?
- Does one upstream event affect several apparent sources?
- What should happen when only part of the group remains?
The feed evaluation guide expands this into a broader vendor and operating review.
Bid and ask still matter
Two sources can have similar mid-prices but very different spreads. A policy built only around a midpoint can hide that difference.
A brokerage feed normally needs a valid two-sided output. The aggregation method, commercial spread rules, and rounding policy should work together so that the final bid and ask remain understandable and do not become crossed or otherwise impossible.
CoinPriceFeeds applies client-defined spread, markup, precision, and rounding controls after the base pricing decision. See the custom pricing engine for the business-level options.
Invalid and stale inputs should leave cleanly
A connected source is not automatically a valid source.
An instrument can stop updating while the connection remains open. A venue can explicitly withdraw a quote. An old update can arrive after a newer one. A price can also fail basic output checks or trigger a configured movement control.
The aggregation policy should define what happens to dependent symbols when an input no longer qualifies. That may mean recalculating from the valid members that remain, moving to a defined fallback, or marking the output unavailable when the policy no longer has enough evidence.
The quote protection overview explains these states without publishing client-specific thresholds.
Use different policies where the markets differ
One global rule is easy to describe but can be wrong for a mixed brokerage book.
For example:
Swipe or scroll horizontally to see all columns
| Instrument situation | Possible policy direction |
|---|---|
| Liquid FX pair with several comparable institutional inputs | A selected consensus or a preferred source with valid alternatives |
| Metal priced mainly from one commercial relationship | A clear primary source with an independent fallback or reference |
| Crypto CFD using several public markets | A carefully selected multi-venue reference with strict eligibility |
| Proprietary broker instrument | A client-owned price, a synthetic calculation, or a hybrid with external context |
| Weekend or closed-session pricing | A separately reviewed scheduled policy |
These are starting points for written review, not recommendations for a particular book. The right choice depends on client obligations, source rights, execution model, risk policy, and target platforms.
Make the live policy visible
People need to know more than the rule written in a document. They also need to confirm which rule is active and what the feed accepted.
A useful operating view should show the current quote, its age, the active pricing page, source relationships, and reasons for protected or invalid state. Primary and backup endpoints should also expose enough configuration identity to verify that they loaded the same intended policy.
The client dashboard and redundancy overview describe how CoinPriceFeeds makes that result reviewable.
Keep the public design useful, not sensitive
A public aggregation guide should help management, dealing, risk, and technology teams choose the right questions. It should not publish a client’s exact source order, protection thresholds, private mappings, venue credentials, or deployment arrangement.
Those details belong in the written scope and authorized onboarding channel. The onboarding path explains when they become necessary.
A feed shaped around your setup
Test an aggregation policy with real representative symbols.
Send the source roles, one normal symbol, one difficult symbol, and the output you expect. We’ll shape a written demo scope around them.