Data Source Risk

SportsPerp’s OBV Index is computed from event-level football data licensed from an institutional data partner — the same kind of feed used by professional clubs and national teams. The vendor’s identity is not disclosed publicly for competitive reasons. Anchoring the index on a single vendor is a deliberate choice, but it is a dependency worth documenting.

The dependency

Three distinct products from the data partner feed the protocol:

Product	Used for	Failure mode
Post-match REST data feed	Post-match OBV + season aggregates	No post-match settlement; index drifts off canonical value
Live event feed (GraphQL subscriptions)	In-match event stream	No live overlay; index becomes post-match-only
Underlying OBV methodology	The definition of OBV itself	We can’t redefine what “OBV” means

All three are accessed via a single data-client module in the engine. Credentials live on the Hetzner server in a systemd EnvironmentFile and are never embedded in the repo or transmitted out-of-band.

Risk scenarios

1. Data partner service outage

Likelihood: low. Our partner operates enterprise-grade infrastructure that supports top-flight football clubs needing real-time data during matches — their reliability bar is already very high.

Impact: short outages (< 2 hours) are absorbed by the oracle staleness window — markets pause but no positions are affected. Longer outages (2–72 hours) leave markets in a no-new-trades state; existing positions can still close at the last known mark. Outages > 72 hours allow permissionless sunset_market calls.

Mitigation: the tiered fallback chain degrades gracefully — authoritative → aggregated → heuristic. Even a complete data blackout results in frozen prices, not bad prices.

2. Data corruption

Likelihood: low but non-zero. Any pipeline can have bad days — a misattributed event, a scoring mistake, a data-entry error.

Impact: the live overlay has per-event sanity checks (OBV deltas outside ±0.5 are rejected). Post-match season aggregates are cross-checked against the previous cycle; a market that suddenly jumps 20% in a post-match update triggers a monitoring alert.

Mitigation: the internal PV-GF/PV-GA models in the obv-engine sidecar provide an independent OBV estimate that can diverge from the vendor’s published values. Persistent divergence flags data quality issues for investigation.

3. Pricing / licensing changes

Likelihood: plausible on a multi-year horizon. Data providers adjust pricing as their customers’ usage profiles change.

Impact: at current traffic levels, data costs are a small line item. 10× growth in SportsPerp usage doesn’t materially change data costs (the partner’s licensing isn’t per-query at our tier). A 10× price increase would be absorbed but noticed; a change in terms (e.g., restrictions on retail-facing use) would be a harder conversation.

Mitigation: the partner’s license for SportsPerp use is negotiated commercially. Any terms change requires advance notice. For long-term resilience, secondary providers exist and their data can be mapped to the same OBV framework with engineering effort.

4. Discontinuation of a specific league’s coverage

Likelihood: very low for EPL (our partner’s flagship coverage). Possible for lesser-covered leagues if SportsPerp expands.

Impact: any league without coverage cannot be indexed.

Mitigation: the partner’s coverage map is stable and expanding. A league losing coverage is rare; a league gaining coverage is common.

5. OBV framework evolution

The underlying OBV methodology has been revised once in recent years. A future framework update could change the numeric scale of OBV, requiring SportsPerp to recalibrate the composite index or risk continuity.

Mitigation: framework updates are rare (every few years at most) and are announced in advance. The composite index recalibration is mechanical — z-scoring normalizes away any constant scale factor. A one-time discontinuity in live indices during the migration would be possible but manageable with appropriate advance notice to users.

Why not diversify data sources today

Three reasons:

Our partner has the strongest dataset. Their data quality is the reason many clubs switched to them. An inferior second source would dilute the index’s signal without materially reducing the dependency.
Mixing two OBV-style frameworks complicates the composite. Each provider’s framework has its own assumptions and scale. Blending them requires a calibration layer that introduces its own risks.
The oracle dependency, not the data dependency, is the single-point-of-failure. The multi-source oracle (built, pending deploy) lets us add a second independent pricing source — our own Python XGBoost models — as the second leg of the 2-of-N consensus. This addresses the “single-provider compromise” risk directly, without requiring a full second data contract.

What diversification looks like long-term

For multi-year resilience, the plan includes:

Secondary data contract with another institutional provider. Their data doesn’t need to flow into the index continuously — it exists as a canary to detect anomalies in the primary feed.
Internal PV-GF/PV-GA models becoming production-grade enough to function as a standalone backup composite. The obv-engine sidecar today serves primarily the live overlay; a long-term goal is using it as a true secondary index.
Community-contributed data attestations via decentralized oracles (Switchboard, Pyth) for real-time match state (goals, minutes, red cards) as a third-party cross-check.

None of these are mainnet blockers. They’re post-launch resilience upgrades.

Trader implications

Practically, a trader should:

Expect 1–5 minute gaps in live OBV during a match when the live event feed has a blip. These are normal and the fallback chain handles them.
Expect occasional post-match index revisions within the first 4 hours of the EMA blend. This is the live → official reconciliation, not an error.
Not panic on confidence-widening events. Wider confidence automatically lowers max leverage and may temporarily pause trading. This is the system correctly de-risking, not a problem.
Check the monitoring dashboard for any extended outage — if the data source is down for > 10 minutes, it’s a general market pause, not position-specific.