Balancing markets, explained for software builders

tl;dr. If you are building anything that touches the grid, you will run into FCR, aFRR, mFRR, BRPs, and BSPs within your first three meetings with a utility. The terminology sounds like it was designed to keep software people out, but the underlying mechanics are simpler than a Stripe webhook flow. Here is the whole thing in plain language, where the money actually moves, and why Poland's 2024 reform made this market suddenly interesting for software teams.

The grid runs on a market. The market has rules, prices, and settlement. Most software people have just never been told, because the people who know it write in regulatory prose and the people who write readable prose do not know it.

This is my attempt to fix that, in one post, with the Polish market as the worked example, because it is the one I operate in and because its 2024 reform makes it one of the more instructive markets in Europe right now.

Why the grid needs balancing at all

Electricity has one property that shapes everything else: at every instant, generation must equal consumption. Not daily, not hourly, at every instant. Storage helps at the edges, but the grid itself stores essentially nothing. When consumption exceeds generation, the frequency of the entire synchronized system drops below 50 Hz. When generation exceeds consumption, it rises. Drift too far in either direction and equipment starts disconnecting to protect itself, which makes the imbalance worse, which is how blackouts cascade.

So someone has to stand at the wheel and continuously correct the balance. That someone is the transmission system operator, in Poland's case PSE, and the tool it uses is the balancing market: a standing arrangement where the operator buys the ability to push the system up or down at short notice, from anyone certified to deliver it.

That is the entire concept. Everything else, the acronyms, the products, the settlement rules, is implementation detail. Useful implementation detail, though, because the detail is where the money is.

The three reserve products are latency tiers

The operator buys correction at three speeds, and the cleanest way for a software person to hold them in mind is as latency tiers, like cache layers.

FCR, frequency containment reserve, is the L1 cache. It responds within seconds, automatically, triggered by the frequency deviation itself rather than by a dispatch signal. Its job is not to fix the imbalance but to stop the fall, holding the frequency while slower reserves wake up. Assets here need fast, precise, automatic response, which is why batteries dominate this product across Europe.

aFRR, automatic frequency restoration reserve, is the L2 cache. It responds within minutes to a continuous automatic signal from the operator, and its job is to actually restore the frequency to 50 Hz and free up the FCR. This is the workhorse product, activated constantly, and increasingly coordinated across borders: PSE has joined PICASSO, the European platform for cross-border aFRR activation.

mFRR, manual frequency restoration reserve, is the L3 tier. It responds within around a quarter of an hour to discrete activation requests, relieving the aFRR during longer imbalances. The bar for response speed is lower, which opens the product to slower assets, including aggregated demand-side portfolios. European coordination here runs through the MARI platform, which PSE is on the path to joining.

If you remember nothing else: FCR holds, aFRR restores, mFRR relieves. Seconds, minutes, quarter-hours.

Who pays whom: the BRP and the BSP

There are two roles in this market, and confusing them is the most common mistake in early conversations.

A BRP, balancing responsible party, is on the cost side. Every unit of energy flowing through the grid belongs to some BRP's portfolio, and the BRP has promised the operator a schedule: this much generation, this much consumption, in each settlement period. Deviate from the schedule and you pay the imbalance price for the difference. Every retailer, every large generator, every trader either is a BRP or pays one to carry this responsibility. A retailer like Pstryk lives with imbalance exposure as a structural fact of the business: forecast your customers' consumption well and the cost is small, forecast badly and it eats your margin.

A BSP, balancing service provider, is on the revenue side. A BSP is certified to sell the operator those FCR, aFRR, and mFRR products, getting paid for availability, for activation, or both. This is the role aggregators and VPPs are trying to win, because it is where flexible assets earn money beyond simple tariff arbitrage.

The flow of money is then simple. BRPs that miss their schedules pay imbalance charges. The operator uses balancing services, bought from BSPs, to physically correct those misses. The imbalance charges fund the correction. Badly forecast portfolios subsidize flexible ones, which is exactly the incentive the system intends.

The software framing: the BRP role is a forecasting problem, and the BSP role is a dispatch problem. They are different products, different teams, and often different companies, even when one logo does both.

The Polish worked example

Poland reformed its balancing market on June 14, 2024, and the reform is what makes the market worth a software person's attention.

The headline change was settlement granularity: imbalances are now tracked and settled in 15-minute intervals, 96 periods a day, where the old regime settled hourly. Each interval gets its own imbalance price, the CEN. The reform also introduced single pricing, meaning every party in a given interval settles at the same CEN whether they were long or short, and it created formal certification paths for BSPs and, notably, for independent aggregators, the legal wrapper that lets a company bid other people's devices into the market.

One structural quirk matters for anyone arriving with assumptions formed in Germany or Great Britain: Poland runs central dispatch. In self-dispatch markets, assets decide their own running and trade against prices. In Poland, PSE itself schedules units through its integrated scheduling process, the ZPG, selecting submitted offers in merit order. Your asset does not freelance against the imbalance price; it offers, and PSE decides. This changes the shape of the software you build, because the intelligence moves from real-time trading into offer construction and forecasting.

The early data from the reformed market shows meaningful spreads in those 15-minute prices and a market that is still maturing, which is the polite way of saying that sophistication is scarce and early movers are being paid for showing up. The 2025 extension of 15-minute settlement to the day-ahead market pushes the same granularity upstream, and the whole Polish wholesale stack now moves in quarter-hour steps.

Why this matters beyond Poland: the reform is EU harmonization in action, the same balancing guideline, the same platform accessions, the same direction of travel as everywhere else in the union. Learn the mechanics in one reformed market and you have learned most of the next one.

What the software actually does

Strip away the market language and there are four software problems, one per stage of the pipeline.

Forecasting is the foundation. For a BRP, forecasting consumption per 15-minute interval is the difference between imbalance costs being noise or being fatal. For a BSP, forecasting how much flexibility the fleet will actually have at 17:15 next Tuesday is what determines what you dare to offer. Both are classic ML territory with an unforgiving deadline structure.

Offer construction is the second problem, and in a central dispatch market it is the strategic one. You are deciding, ahead of each delivery day, what capability to promise at what price across 96 intervals, knowing that an accepted offer is an obligation. Too conservative and you leave money on the table. Too aggressive and you fail an activation, which costs penalties and, worse, certification standing.

Dispatch is the third. When the activation signal arrives, your platform has minutes or less to translate one market-level instruction into commands across thousands of heterogeneous devices, respecting every local constraint, the EV that must be charged by 7am, the heat pump that must not let the living room drop, and confirm delivery. This is the layer where the IoT engineering and the market engineering meet, and it is the layer that separates real aggregators from pitch decks.

Settlement is the fourth and least glamorous. Metering data per interval, baseline calculations, reconciliation against what the operator says you delivered, invoicing. Boring, mandatory, and a surprising source of margin leakage when done badly.

If your team can run a low-latency event pipeline, operate an ML forecasting service, and keep a device fleet honest, you already have the skill set. The domain knowledge is learnable in months. The fleet, the certifications, and the trust take years, which is precisely why starting matters.

Where a small team can compete

The honest map of where a small software company can win, against incumbents with trading floors and decades of relationships, has three regions.

You can win where the assets are small and many. Incumbent balancing portfolios are built on power plants and industrial loads. The coming flexibility is in residential devices, and incumbents have neither the consumer products nor the device integrations to reach them. The aggregation of small assets is a genuinely different business, and it is the one software teams are built for.

You can win where granularity rewards precision. A 15-minute market with per-interval prices pays for forecasting accuracy and fast reaction in a way an hourly market never did. That is a software advantage by construction.

And you can win where the market is young. Poland's reformed market is under two years old, the aggregator certification path is fresh, and the sophisticated capital is only starting to arrive. The same will be true, country by country, as the EU harmonization wave lands. There is a repeatable playbook in being the software-native entrant in each newly reformed market, and the window in each one is measured in a few years, not decades.

The grid runs on a market, the market is opening to aggregated small assets, and the mechanics, as I hope this post shows, are not the hard part. The hard part is the fleet and the trust, and those compound from the day you start.

If you are a founder or an investor trying to locate a company on this map, balancing market strategy and the software architecture underneath it is core territory for my advisory work. Details on the consulting page.