Operating model guide
Managed custom feed, raw source, or in-house stack?
The right model depends on what your brokerage wants to own. A raw source supplies data, an LP relationship supplies prices and possibly liquidity, an in-house stack gives your team full operating responsibility, and a managed custom feed provides a client-specific pricing and delivery layer.
- Compare operating responsibility, not only the connection fee.
- Separate source data from pricing policy and platform delivery.
- Treat hybrid designs as normal when they fit the business.
No false choice
A managed or in-house feed can use raw APIs, LP prices, and client-owned sources as inputs.
Ownership is the difference
Decide who builds, monitors, protects, changes, and verifies the full path.
Fit before features
The best model follows your pricing policy, staff, platforms, source rights, and continuity needs.
On this page
A managed custom feed is most useful when a brokerage wants to control its pricing policy without building and operating every source connector, calculation, protection, delivery, backup, and monitoring component itself. A raw API, an LP feed, or an in-house stack can be the better choice when the requirement is narrower or the brokerage deliberately wants to own more of that work.
These options are different layers
The choices are often presented as competing data products, but they do not sit at the same level.
- A raw venue or reference API is an input interface.
- A liquidity-provider feed is part of a commercial pricing and possibly execution relationship.
- An in-house stack is an operating model in which the brokerage builds and runs the pricing path.
- A managed custom feed is an operating model in which a specialist runs an agreed client-specific pricing and delivery layer.
A managed or in-house stack can consume raw APIs and LP feeds. A brokerage can also keep a proprietary source or calculation at the centre of either model. The decision is therefore about boundaries and ownership, not about declaring one source type universally better.
A neutral comparison
Swipe or scroll horizontally to see all columns
| Model | Strong fit when | Brokerage normally owns | Main point to examine |
|---|---|---|---|
| Direct raw API or exchange feed | One or a few sources need to enter an existing technical stack | Connector, normalization, pricing rules, protection, delivery, monitoring, and continuity | Whether the internal system already covers the rest of the path |
| Direct LP feed | The brokerage wants the LP’s prices and possibly executable liquidity within that relationship | Commercial selection, platform integration, any cross-source policy, downstream controls, and backup decisions | Whether one LP view is the intended client-pricing basis |
| In-house pricing stack | The brokerage wants full design and operating control and can staff it over time | Software, infrastructure, source integrations, changes, incident response, verification, and documentation | Total long-term ownership, including routine and exceptional work |
| Managed custom feed | The brokerage wants client-specific rules and multiple delivery capabilities without owning the whole service | Business policy, source rights, approvals, platform side, and internal escalation | Provider fit, transparency, change boundaries, integration, and agreed support |
| Hybrid | Existing internal or provider components are valuable but do not cover the complete requirement | The boundary selected for each component | Whether ownership and failure behaviour remain clear between systems |
None of these rows guarantees quality. Each model still needs evidence that its sources, pricing, protection, delivery, and operating process meet the brokerage’s requirement.
When a raw API is enough
A direct API can be a clean answer when the brokerage already has a service that:
- connects and reconnects safely;
- maps instruments and source state;
- decides which quotes are eligible;
- builds the intended client price;
- applies commercial and protection rules;
- distributes the result to every target platform;
- provides monitoring and backup; and
- has people responsible for changes and incidents.
It can also suit a narrow reference-data need where the client does not need a managed output feed.
The API itself does not normally settle those surrounding decisions. It describes how to receive data. The brokerage still needs the contractual right to use that data for its intended purpose.
When a liquidity-provider feed is enough
An LP feed can be the natural primary price when the brokerage wants that provider’s market view and, where agreed, its executable liquidity.
Using it directly may be appropriate when:
- the LP relationship is intended to define the price;
- the platform already integrates it well;
- the required symbols and sessions are covered;
- the commercial spread policy is handled in the existing stack; and
- the brokerage has an acceptable backup and incident model.
An LP feed can also be one source in a broader policy. For example, it may remain the preferred input while independent reference or fallback sources provide another role. The market data aggregation guide explains those patterns.
CoinPriceFeeds does not replace the client’s venue or liquidity relationships and does not create market-data entitlements.
When an in-house stack makes sense
Building internally can be the right strategic choice when pricing technology is a core capability the brokerage wants to own.
The case is strongest when the organization has:
- engineers with market-data and platform-integration experience;
- operational coverage for source, pricing, delivery, and infrastructure incidents;
- a controlled way for dealing and risk staff to review pricing changes;
- time to maintain venue changes and new platform requirements;
- independent primary and backup design;
- testing, monitoring, and release verification; and
- a clear reason to prefer full ownership over a managed boundary.
An in-house stack can provide deep control and close alignment with proprietary systems. It also makes the brokerage responsible for ordinary maintenance, staff continuity, documentation, security updates, and rare failure cases—not only the first successful connection.
That responsibility is not automatically a disadvantage. It is simply part of the investment being chosen.
When a managed custom feed fits
A managed custom feed fits between an inflexible source feed and a fully internal platform.
With CoinPriceFeeds, the brokerage can define a client-specific source and pricing policy while CoinPriceFeeds operates the agreed feed-side connection, calculation, protection, delivery, dashboard, and verification capabilities.
This model can be useful when the brokerage needs:
- several institutional, exchange, reference, or client-owned inputs;
- different source policies for different symbols;
- markups, spread controls, precision, and scheduled policies;
- quote protection with visible reasons;
- delivery to more than one consumer over streaming or FIX;
- concurrent primary and backup endpoints; or
- a shared operating view for dealing, risk, and technical staff.
The brokerage still owns its business decisions, source rights, authorized approvals, downstream platform, and internal escalation. The managed service does not become the client’s dealer, risk function, execution venue, or regulatory decision-maker.
See how CoinPriceFeeds works for the connected product flow.
Compare total operating work
The visible subscription or infrastructure charge is only one part of the comparison.
Swipe or scroll horizontally to see all columns
| Work area | Questions to include in the decision |
|---|---|
| Source access | Who contracts with venues, manages entitlements, rotates credentials, and responds to source changes? |
| Engineering | Who builds connectors, mappings, calculations, platform delivery, tests, and upgrades? |
| Pricing changes | Can dealing and risk staff review and change policy safely without editing application code? |
| Protection | Who defines, implements, explains, and resets abnormal or invalid quote states? |
| Continuity | Are primary and backup genuinely independent enough, and how are they compared? |
| Monitoring | Who can distinguish source delay, calculation state, and downstream delivery trouble? |
| Operations | Who receives alerts, investigates incidents, and communicates evidence across teams? |
| Staff continuity | Is the knowledge documented and available when the original developer or dealer is absent? |
| Change risk | How does a proposed rule or release prove that it did not replace a working feed with an invalid one? |
For an in-house stack, these costs appear in engineering, infrastructure, operations, and management time. For a managed feed, some move into the service fee and provider relationship. A fair comparison uses the same scope on both sides.
Decide what control means
“We need control” can refer to several different things:
Swipe or scroll horizontally to see all columns
| Type of control | Possible way to provide it |
|---|---|
| Business control | The brokerage defines source roles, pricing intent, spreads, schedules, and approval rights |
| Technical control | The brokerage owns the software and deployment |
| Operational control | The brokerage chooses who can change state, trigger failover, or receive alerts |
| Data control | Source rights, private inputs, access boundaries, and permitted use are explicit |
| Evidence | Teams can see which policy is active, why a quote is protected, and whether backup agrees |
A managed model can provide strong business and evidence control without giving the client ownership of every internal service component. An in-house model can provide technical ownership but still needs a usable control surface for dealing and risk teams.
The right balance depends on why the control is needed.
Ask the same evidence questions in every model
Whether the feed is managed or internal, test:
- what happens when a source cancels or silently freezes;
- whether a late update can replace a newer one;
- how impossible or abnormal output is handled;
- which pricing rule is active now;
- how a proposed change is validated;
- whether one slow consumer affects others;
- whether primary and backup loaded the same policy;
- how failover is triggered and rehearsed; and
- which team owns each recovery action.
The price-feed evaluation guide gives a complete checklist that works for vendor selection and internal design.
A hybrid can preserve good existing work
A brokerage does not need to replace every existing component to use a managed feed.
Possible boundaries include:
- keeping an established LP relationship as the preferred input;
- publishing a proprietary client price into the managed flow;
- using the brokerage’s existing bridge for platform-specific delivery;
- sending the same managed output to a risk or reconciliation consumer;
- retaining client-side failover logic while the provider keeps both endpoints ready; or
- using a direct API for one separate purpose and a managed feed for client pricing.
The important part is to write down the boundary. Each connection should have an owner, an expected failure response, and a way to verify the result.
Choose from a real requirement
A feature matrix can hide the decision. Start instead with one representative feed:
- Which inputs should shape EURUSD, XAUUSD, or another important symbol?
- Who should be able to change its commercial pricing?
- What should happen when the preferred source becomes unsuitable?
- Which platforms and internal consumers need the output?
- What evidence is required before failover?
- Which parts does your team genuinely want to operate?
Those answers make the appropriate boundary much clearer. If a managed custom feed looks relevant, the written-first onboarding path explains how to test the fit without preparing a finished specification.
A feed shaped around your setup
Compare the models against one real feed requirement.
Send your sources, pricing ownership, target systems, and current operating constraints. We’ll explain in writing where a managed custom feed fits—and where it may not.