BiTraDER set out to let flexible and non-flexible connections trade directly with each other, to work around network constraints on SP Electricity North West‘s network. Here’s what running that trial taught us, and what still needs to happen for it to become BAU.
How we adapted the new capabilities on ElectronConnect
ElectronConnect is our standard platform for UK flexibility markets. Normally, a distribution network or system operator (DNO/DSO) gives us a set of markets with rules defined by the industry standard, and we publish them.
BiTraDER needed something different: a trading algorithm that could match bids and offers against each other directly, rather than a DNO reviewing and accepting single-sided offers. To do that, we had to combine the trading rules designed for the project with the realities of SP ENW’s active network management (ANM) and merit order management (MOM) systems.
What made this particularly complex was the level of direct integration. We had to pull the existing merit order list straight from SP ENW’s ANM system, use it to build the live market, and then, once the bids and offers were matched, generate a brand-new merit order list to send right back into the ANM.
A big chunk of the first two years went on knowledge transfer with SP ENW, understanding how their ANM system behaved in practice. The build itself was iterative. We transferred unchanged merit order data first, then added simple trades, then more complex scenarios, and only then moved into live trials with real assets.
We built automated bilateral data transfers between the ANM and Electron, and a BiTraDER-specific audit trail to track every change to the merit order.
How BiTraDER worked in practice
For each constraint:
- Participants registered their assets in advance: demand or generation, capacity, response time.
- Day ahead of a constraint, the platform showed constraint and merit order information only to participants with assets in the right location.
- Participants saw their role (buyer or seller), the predicted constraint size, and their position in the merit order queue.
- Buyers priced to move down the curtailment queue. Sellers offered to be curtailed, in exchange for availability and utilisation payments.
- When the trading window closed, the platform matched trades. Participants only saw who they’d matched with, and at what price, after the match.
- Dispatchable sellers submitted baselines ahead of delivery. After delivery, they submitted meter readings and the platform measured performance minute by minute.
One change that came from trial feedback is a “trade full volume only” checkbox. Some sellers couldn’t do partial dispatch, but the original rules matched on price alone. A seller offering 10 megawatts could end up matched for five, which wasn’t workable for their asset.
Because there weren’t enough existing flexible connections on the network to run an ideal trading scenario, we connected assets virtually onto a test network to create an artificial constraint management zone.
The assets weren’t physically on the same part of the network, but trading behaviour stayed consistent, which was what mattered for testing whether the market itself worked.
Learnings to take forward
A few learnings and things to carry into BAU came up in the trials.
Price transparency
One of the most consistent pieces of feedback we got was that participants needed more market transparency to help them price effectively.
In the trial, they could only see prices after they’d matched. Overlapping both availability and utilisation prices in a low-liquidity market (as will always be the case in a trial) proved difficult.
We had planned to email out guide prices based on historical data from existing flexibility markets, and whilst this did help bids converge over time, it didn’t ensure consistent matching.
For business-as-usual, the fix is a fully transparent, anonymised order book, similar to some wholesale markets. Showing live bids and offers sorted by price before the match happens is the best way to help participants trust that the market can consistently provide revenue.
Buyer and seller commercial relationship
In BiTraDER, the contract sits between buyers and sellers, varying from a standard flex market, where the commercial relationship is between the DNO and the provider. However in the trial, sellers were paid by SP ENW, not by the buyers they’d matched with.
Therefore, the trial didn’t teach us how a dispute or non-delivery would be resolved between two trading parties in a live market. Participants told us that the admin and cost of signing contracts is already a major barrier to entry, so landing on a simple, fair framework with direct input from market participants will be essential before going live.
The real-time dispatch gap
We also uncovered a technical mismatch regarding real-time dispatch. BiTraDER was designed to dispatch assets in real time because network constraints shift constantly between the day-ahead forecast and the day of delivery, and we only want to dispatch sellers when it actually helps the network.
Because these sellers are on firm connections, they cannot be automatically curtailed by the ANM system; they must be actively instructed.
While ElectronConnect can send these dispatch instructions in real time, the participants did not have the systems to receive them and automatically change their assets’ behaviour.
For some, the assets were simply too old to easily retro-fit with the technology. For others, the tech was possible, but they needed guaranteed market revenue to justify the investment.
Given that most UK flexibility markets rely on comfortable, day-ahead schedules, BiTraDER’s requirement for real-time responsiveness introduces a much higher technical barrier to entry for sellers looking to join a business-as-usual market.
Who runs the market
Another open question is who actually takes responsibility for running BiTraDER in a business-as-usual environment. Because the DNO benefits directly from constraint mitigation, it is likely the responsibility would sit with them.
However, in an ideal scenario, the platform would operate almost entirely independently. It would take data from the ANM, build the markets, notify participants, match trades, and send the reordered merit order list back automatically.
The DNO would simply oversee the process and only intervene if the physical network requires it. Pinning down exactly how that operational oversight works in practice is something that would need to be finalised for a live market.
Where this leaves us
The trial proved that putting flexible and non-flexible connections into direct competition for the same capacity works, both technically and operationally. What’s left is the practical work any new market has to do before it goes live: make the market design attractive, design a clear responsibility framework, and design dispatch around what participants can realistically do.
