# Data Sharing, Marketplaces, and Ecosystems
In 2021, a mid-sized European insurer discovered that its most valuable asset wasn't its actuarial models—it was fifteen years of granular claims data on residential water damage. A reinsurance analytics firm offered seven figures for access. The CDO said yes to the revenue, then spent eighteen months untangling the consequences: a competitor reconstructed the insurer's underwriting logic from aggregate patterns, and a regulator asked pointed questions about consent scope. The deal wasn't wrong. The *decision architecture* behind it was missing.
That is the gap this lesson closes. You already understand monetization as a concept. What you need now is the operational judgment to decide where you sit in a data ecosystem—buyer, seller, or operator—and how to build the machinery that makes each role safe and profitable.
Every data ecosystem transaction puts you in one of three postures, and most CDOs drift into them by accident rather than choosing them by strategy.
As a buyer, you acquire external data to enrich internal decisions—demographic overlays, weather feeds, transaction panels, firmographics. The trap here is not cost; it's *dependency and attributionattributionA framework for assigning credit to the touchpoints that contributed to a conversion, so you can measure which channels and interactions actually drive results.*. When a bought signal becomes load-bearing in a production model, you've created a supplier who now prices against your switching cost. Snowflake's Data Marketplace and AWS Data Exchange have made acquisition frictionless, which is precisely the danger: frictionless procurement produces ungoverned sprawl. A retailer I worked with had 34 external data subscriptions across five teams, three of which were duplicative and one of which was legally indefensible.
As a seller, you package and license your own dataown dataData collected directly from your own customers and prospects through your own channels: your most reliable and privacy-compliant source.Voir la définition complète →. The insurer above was a seller. The core discipline is understanding what you're actually selling—raw records, derived features, or *insights*. These are three different businesses with three different risk profiles. Selling raw records maximizes buyer flexibility and your exposure. Selling insights (e.g., "propensity scores" rather than the underlying behavior) protects your competitive moatmoatA lasting edge over competitors: a resource, capability or position they cannot easily replicate, letting a firm earn above-average returns over time.Voir la définition complète → but requires you to build and maintain a product.
As an operator, you build the marketplace or clean room where others transact—the posture Bloomberg took decades ago and that companies like Snowflake, Databricks, and specialized players like Habu/LiveRamp occupy now. This is a platform business with platform economics: enormous upside, brutal cold-start dynamics, and a governance burden that dwarfs the other two roles.
The decision test is not "which is most profitable" but which posture matches your data's structural position:
Most CDOs are buyers who occasionally sell. Very few should be operators, and the ones who try without the aggregation-point advantage burn capital spectacularly.
The defining technical shift of the last five years is that you no longer have to move data to combine it. This changes everything about the seller and operator postures.
The old model was "ship a file, hope for the best." The current model is the data clean room: a governed environment where two or more parties can run approved computations across their combined data without either party seeing the other's raw records. This is how advertisers match audiences with publishers post-cookie, and how the insurer *should* have structured its reinsurance deal.
The mechanics you need to understand as a CDO are three layers:
1. The privacy layer — techniques that make outputs safe: aggregation thresholds (no result released for fewer than N individuals), differential privacy (calibrated noise injection), and query auditing. This is what prevents a buyer from reconstructing individual records or, as in our opening case, reverse-engineering your model.
2. The governance layer — who can run which queries against which columns, with what allowlist of operations. This is where most implementations fail, because teams treat it as an afterthought.
3. The commercial layer — metering, entitlements, and billing tied to consumption.
Here's the shape of a clean-room policy that separates a defensible deal from the insurer's mistake—restricting operations to aggregates above a threshold rather than exposing joinable rows:
clean_room_policy:
dataset: residential_claims
allowed_operations: [count, sum, avg, join_on_hashed_key]
blocked_operations: [select_raw, export_rows]
aggregation_threshold: 50 # suppress any result covering <50 records
join_keys:
- property_id_hashed
output_review: automated_plus_manual_sample
differential_privacy:
epsilon: 1.0The insurer sold raw joinable records. Had they sold *only aggregated query results above a threshold of 50 with the join key hashed*, the reinsurer would have gotten legitimate risk signal and been unable to reconstruct proprietary underwriting logic. Same revenue, radically different risk. The contract terms and the technical controls must encode the same intent—if your legal agreement says "aggregate only" but your platform allows row export, the platform wins.
On the buyer side, the parallel discipline is a data acquisition gate: no external dataset enters production without answering four questions—What decision does this improve, and by how much? What is our switching cost if the supplier changes terms? Is the provenance and consent chain contractually warranted? What happens to our model if this feed goes stale or dies? The retailer's 34 subscriptions collapsed to 11 once these questions were enforced.
The question that stalls most data-sharing initiatives is pricing, and the reason is that CDOs price data like a product when they should price it like *access to a decision*.
Three pricing models dominate, and each signals a different relationship:
The practical answer for a seller is usually a hybrid: a subscription floor for access plus consumption for volume, with the floor set to cover your governance and support cost. Never price below your *cost to serve safely*—which includes the ongoing cost of monitoring for misuse, not just the infrastructure.
For value capture, the sharpest CDO framing is the value-migration question: when you sell data, does value flow *to* your buyer's product in a way that eventually competes with you? The insurer sold to a reinsurer—adjacent, not directly competing. Selling the same claims data to an insurtech startup would have been feeding a future competitor. The data is identical; the strategic consequence is opposite. This is judgment no contract template captures for you.
The operator posture deserves a hard warning on economics. Marketplaces are two-sided networks, and two-sided networks have a cold-start problem: buyers won't come without sellers, sellers won't come without buyers. The operators who won—Bloomberg, Snowflake—either seeded one side with an existing captive audience or subsidized one side heavily for years. If you're considering operating an ecosystem, the diagnostic question is brutal: *do you already own one side of the market?* A logistics firm that already connects 10,000 shippers and carriers can credibly operate a data exchange between them. A firm without that existing gravity is proposing to fund a network-effects flywheel from zero, and that is a venture bet, not a data strategy.
Vérification des acquis
1. The lesson argues that the insurer's data-sale problem was not the decision to sell, but rather the absence of a 'decision architecture.' What does this distinction most fundamentally imply for a CDO?
2. According to the lesson, why is 'frictionless procurement' on marketplaces like Snowflake or AWS Data Exchange framed as a danger rather than a benefit?
3. The lesson warns that a bought signal becoming 'load-bearing' in a production model creates a specific strategic risk. What is that risk?
4. Select ALL correct answers about the three ecosystem postures (buyer, seller, operator) as presented in the lesson.
Sélectionnez toutes les réponses correctes.
5. Select ALL correct answers about the consequences the insurer's CDO had to 'untangle' and what they teach about seller-side risk.
Sélectionnez toutes les réponses correctes.
Let's convert all of this into a sequence you can actually run.
Step 1: Inventory your data's structural position, not its volume. For each significant dataset, mark it on two axes: *replicability* (how easily can others obtain equivalent data?) and *aggregation value* (how much more valuable is it combined with others' data?). High-uniqueness, high-combination-value assets are your seller and operator candidates. Everything else, you're a buyer or you leave it alone.
Step 2: Run the value-migration and dependency screens. For each seller candidate, mapmapUsing software to automate repetitive marketing tasks and campaigns, enabling personalisation at scale across channels like email, web, and social.Voir la définition complète → who the buyers are and whether any sits in your competitive future. For each buyer need, run the acquisition gate. This is where you say no to revenue that costs you strategic ground and no to subscriptions that create hidden model dependencies.
Step 3: Choose the minimum-viable technical posture. You do not need to build a clean room to start selling. The maturity ladder is: (a) governed file delivery with strong contracts, (b) APIAPIApplication Programming Interface: a standardised interface that lets applications communicate and exchange data without knowing each other's internal workings.Voir la définition complète →-based access with metering, (c) query access in a marketplace, (d) full multi-party clean room. Start one rung above where your risk demands, not at the top. The insurer needed rung (c); they operated at rung (a).
Step 4: Instrument misuse detection before the first transaction, not after. The single most common failure is discovering a violation through a news story or a regulator's letter. Query logging, anomaly detection on access patterns, and periodic output audits are not optional overhead—they are the thing that lets you sell at all. Budget for the *ongoing* cost of safe serving in your pricing.
Step 5: Decide operator posture only with the network-gravity test. If you don't own one side of the market, participate in someone else's ecosystem as a buyer or seller and revisit the operator question in eighteen months. Operating is the highest-ceiling, highest-failure posture, and it's rarely the right first move.
A useful reframe throughout: you are not deciding whether to share data; you are deciding how much of your data's optionality to convert into revenue, and at what strategic cost. The insurer converted too much optionality (raw records) for the revenue they captured. A disciplined CDO converts the *least* data necessary to capture the value—selling insights before features, features before records, and aggregates before raw.