Why We Built ClauseHub

The Problem

There are over 73 licensed energy suppliers in the UK. Each one publishes tariff data — unit rates, standing charges, exit fees, payment methods, contract lengths — but they each do it differently. Some email CSV files. Others upload Excel spreadsheets to an FTP server. A few maintain internal APIs that speak bespoke formats. Many simply update a PDF on their website and expect interested parties to notice.

For anyone trying to build a whole-of-market view — a comparison site, a switching service, a regulatory dashboard, an AI-powered energy advisor — this creates what we call the N×M problem. If there are N suppliers and M consumers of tariff data, you need N×M bilateral agreements. Each agreement comes with its own data format, its own update cadence, its own authentication mechanism, and its own support contact when things break.

At 73 suppliers and 11 major comparison sites alone, that is over 800 bilateral relationships. In practice, most comparison sites cover only a fraction of the market because the overhead of onboarding each new supplier is so high. The result is that consumers see an incomplete picture, suppliers struggle to reach all channels, and the market is less competitive than it should be.

The UK energy market does not have a data problem. It has a data plumbing problem. The information exists — it is just locked inside incompatible formats and bilateral agreements.

The Current Landscape

Today, the dominant intermediaries in UK energy data are the comparison sites themselves: Uswitch, Compare the Market, GoCompare, MoneySuperMarket, and others. These platforms aggregate tariff data from suppliers, present it to consumers, and earn revenue through switching commissions — typically between £30 and £70 per switch.

This commission model creates several problems:

• Misaligned incentives. Comparison sites are incentivised to promote tariffs that pay higher commissions, not necessarily the tariffs that are best for the consumer. Ofgem has repeatedly raised concerns about this.
• Incomplete coverage. Smaller suppliers who cannot afford high commissions are often excluded, reducing market visibility for consumers and disadvantaging new entrants.
• No raw data access. There is no neutral, commission-free API where a developer, regulator, or researcher can simply query the current state of UK energy tariffs in a structured format. The data is locked behind proprietary integrations.
• Fragmented formats. Even the data that is shared between suppliers and comparison sites arrives in an assortment of formats: CSV over SFTP, XML feeds, JSON blobs with inconsistent schemas, and manual email updates.

The comparison sites have no commercial incentive to solve this problem. Their competitive moat is precisely the difficulty of aggregating this data. Making it easy and open would commoditise their core asset.

What Ofgem Requires

Here is the irony: the data already exists in a standardised disclosure format. Ofgem mandates that every licensed energy supplier produce a Tariff Information Label (TIL) for each tariff they offer. This requirement comes from Standard Licence Condition 31 (SLC 31), which specifies exactly what information a TIL must contain:

• Supplier name and tariff name
• Tariff type (fixed or variable)
• Payment method (direct debit, prepayment, standard credit)
• Unit rates and standing charges by region
• Contract length and exit fees
• Any additional charges or discounts
• Estimated annual cost based on typical consumption

The regulator has done the hard work of defining what should be disclosed. The problem is how it is shared. SLC 31 mandates the content of the disclosure but says nothing about the data format or delivery mechanism. So suppliers comply by publishing PDF documents on their websites, emailing spreadsheets to comparison sites, or uploading flat files to shared servers.

Ofgem standardised the semantics. Nobody standardised the transport.

This means the structured data is there — it is just trapped inside unstructured delivery mechanisms. Every comparison site, every switching service, and every energy app has to write bespoke extraction and normalisation code for each supplier. The cost is enormous, the error rate is high, and the result is a market where data freshness is measured in days rather than seconds.

Our Solution

ClauseHub sits between suppliers and consumers as a neutral intermediary. The model is simple:

1. Suppliers publish once. They push their tariff data to the ClauseHub API in a standardised JSON:API format. We provide client libraries, validation tools, and a sandbox environment to make this straightforward.
2. Consumers query once. Comparison sites, switching services, researchers, regulators, and developers all query the same API. They get whole-of-market data in a consistent, well-documented format.
3. ClauseHub charges for access, not for switching. We are a data infrastructure company, not a comparison site. We have no switching commissions, no affiliate fees, and no incentive to promote one tariff over another.

Under the hood, the platform is built on several principles that matter for regulated data:

• Immutable versioning. Every tariff record is versioned. When a supplier updates a tariff, the old version remains available. This means regulators can audit historical pricing, and consumers can see how tariffs have changed over time.
• JSON:API format. We follow the JSON:API specification for consistent resource relationships, pagination, filtering, and error handling. If you have consumed any modern API, the interface will feel familiar.
• Role-based access. Suppliers can only write their own data. Consumers can only read. Regulators get audit-level access. Each role has scoped permissions enforced at the API layer.

The analogy we often use internally is that ClauseHub is to regulated disclosure data what Plaid is to bank account data or what Stripe is to payment processing: a neutral layer that turns a messy, bilateral integration problem into a single API call.

GET /v1/tariffs?filter[fuel_type]=electricity&filter[payment_method]=direct_debit

{
  "data": [
    {
      "type": "tariffs",
      "id": "trf_2026_sse_fix12_dd",
      "attributes": {
        "supplier": "SSE Energy",
        "tariff_name": "SSE Fixed 12M",
        "fuel_type": "electricity",
        "payment_method": "direct_debit",
        "unit_rate_pence": 24.50,
        "standing_charge_pence": 46.36,
        "contract_length_months": 12,
        "exit_fee_pounds": 30.00
      }
    }
  ]
}

Why Now

We are not the first people to notice that UK energy data is fragmented. So why build this now?

The regulatory environment is shifting. Ofgem has been increasing pressure on the market to become more transparent. The introduction of the Energy Price Cap, the push for smart meter rollout, and the ongoing review of comparison site regulation all point in the same direction: more data, more transparency, more standardisation. A neutral data API is the infrastructure that makes this possible.

Open Banking proved the model. When the Competition and Markets Authority (CMA) mandated Open Banking in 2018, it created a standardised API layer for UK bank account data. The result was an explosion of innovation: budgeting apps, lending platforms, accounting integrations, and payment services that simply could not have existed before. The energy market is ripe for the same transformation. The regulatory disclosure data already exists — it just needs a standardised API layer.

AI agents need structured data. The rise of large language models and autonomous AI agents is creating a new category of data consumer. These systems cannot scrape PDFs, parse inconsistent CSVs, or navigate bilateral FTP agreements. They need clean, well-structured API endpoints that return predictable JSON. As AI-powered energy advisors become mainstream, the demand for machine-readable tariff data will grow exponentially.

Market reform is accelerating. The UK government's Review of Electricity Market Arrangements (REMA) is the most significant structural reform of the energy market in a generation. As the market evolves, the need for transparent, accessible, and auditable tariff data becomes more urgent, not less.

What's Next

Energy is our first market, but the pattern repeats across UK regulated industries. Wherever a regulator mandates standardised disclosure but does not mandate a standardised data transport, the same N×M problem emerges.

We have identified two additional markets where ClauseHub can apply the same model:

• Telecoms. Ofcom requires providers to produce Contract Summaries for every mobile, broadband, and bundled tariff. Like Ofgem's TILs, these summaries have standardised content but no standardised delivery mechanism. The ClauseHub Telecoms API will do for broadband and mobile tariffs what the Energy API does for gas and electricity.
• Banking. The FCA mandates Summary Boxes for savings accounts, credit cards, and personal loans. While Open Banking covers transactional data, it does not cover product disclosure data. The ClauseHub Banking API will fill that gap, providing structured access to product terms across UK financial institutions.

The thesis is straightforward: one platform, three regulated markets, one API pattern. Suppliers publish, consumers query, regulators audit. The same role-based access model, the same immutable versioning, the same JSON:API format — applied to energy, telecoms, and banking.

We believe that standardised, neutral access to regulated disclosure data is infrastructure that should exist. Not behind switching commissions. Not locked inside proprietary integrations. Just clean, well-documented APIs that anyone can build on.