Energy & Utilities
Energy Price Risk API
Your exposure is not the average price. It is the handful of hours where price and your consumption happen to peak together, and that intersection is what a risk score should measure.
- Industrial energy buyers
- Energy procurement consultancies
- Treasury and risk teams
- Energy management software vendors
- Flexibility aggregators
What your customers would see
example interfaceMockupIllustrative mockup of the interface we would build. Figures shown are examples, not results from a live deployment.
The problem this solves
Industrial energy buyers sit in an awkward position. They are large enough that price risk materially affects margin, and usually too small to run a trading desk. The result is procurement decided on a broker's recommendation and a forward curve screenshot, with no quantified view of what the downside actually looks like or when it would arrive.
The exposure is also specific to the buyer. A continuous process plant and a single-shift factory face the same market and completely different risks, because one consumes through the scarcity hours and the other does not. An aggregate volatility measure tells neither of them much. What matters is the distribution of cost given their own load shape and their own hedged position.
This is a well-defined quantitative problem that is rarely packaged for the people who need it. Spike probability, imbalance tightness, volatility regime and forward curve risk are all computable from market and operator data. The work is combining them into a cost-at-risk figure against a specific consumption profile, and being clear that the tails are where the model is least certain and most consequential.
Who buys this
Industrial energy buyers, Energy procurement consultancies, Treasury and risk teams, Energy management software vendors, Flexibility aggregators
What the API returns
What comes back
- Cost-at-risk over a chosen horizon against your own load profile
- Spike probability by settlement period and threshold
- Volatility regime classification with change detection
- Supply-demand tightness and reserve margin indicators
- Hedge coverage analysis showing unhedged exposure by period
- Scenario costs under cold-snap, low-wind and outage assumptions
- Forward curve risk measures including basis and shape risk
- Alerts when tightness or spike probability crosses your thresholds
Endpoints
| Method | Path | Returns |
|---|---|---|
| POST | /v1/risk/cost-at-risk | Cost-at-risk for a load profile and hedge position |
| GET | /v1/risk/tightness/{market} | Current and forecast supply-demand tightness |
| GET | /v1/risk/spikes/{market} | Spike probabilities by period and threshold |
| POST | /v1/risk/scenario | Cost under supplied weather, outage or demand scenarios |
| POST | /v1/hedging/coverage | Unhedged exposure analysis by period |
| WS | /v1/stream | Push tightness and spike threshold alerts |
Request and response
illustrativeRequest
{
"market": "DE-LU",
"load_profile_id": "plant_werk_3",
"hedges": [
{ "product": "Q1-2027_baseload", "volume_mw": 18.0, "price_eur_mwh": 94.50 }
],
"horizon": "2027-Q1",
"confidence_levels": [0.95, 0.99]
}Response
{
"market": "DE-LU",
"horizon": "2027-Q1",
"currency": "EUR",
"expected_cost": 4182000,
"cost_at_risk": {
"p95": 5240000,
"p99": 6918000,
"driver_at_p99": "cold_still_period_with_nuclear_outage"
},
"hedge_coverage": {
"coverage_pct": 71.4,
"unhedged_mwh": 12680,
"worst_exposed_window": "weekday_evenings_jan"
},
"tightness": {
"current_band": "normal",
"forecast_tight_days": ["2027-01-14", "2027-01-15"],
"reserve_margin_pct_p10": 4.8
},
"volatility": { "regime": "elevated", "changed_on": "2026-10-09",
"realised_30d_annualised": 0.84 },
"caveat": "Tail estimates rest on few historical analogues and are the least certain output here."
}Where the data comes from
| Market settlement and forward prices | Spot history and forward curves for the relevant market. Forward curve data is almost always licensed with strict no-redistribution terms, which shapes what can be shown to end clients |
| Your consumption data | Half-hourly or finer load for your sites. The whole point is measuring risk against your shape rather than a baseload assumption |
| Your hedge positions | Contracted volumes, prices and periods, so exposure is net rather than gross |
| Operator transparency data | Load, generation, reserve margin and outage notifications, used for tightness and spike features. Generally publishable with attribution |
| Weather forecasts and climatology | Both the forward outlook and the historical distribution, since tail scenarios are weather scenarios |
| Fuel and carbon prices | Gas, coal and emissions, which set marginal cost. Licensed, and the licence terms usually prohibit passing values through |
The intelligence layer
The difference between a demo and a service is mostly in this section. These are the parts that keep the answer trustworthy once real traffic is hitting it.
- Monte Carlo cost simulation over joint price and load paths, rather than applying a volatility figure to an average price — the correlation between your consumption and the price is most of the risk
- Weather-driven scenario generation using historical analogue years plus perturbed variants, so cold-still periods appear with realistic frequency and persistence
- Fat-tailed price distributions fitted explicitly, because a Gaussian assumption understates scarcity pricing by a wide margin and produces comfortable, wrong numbers
- Spike models separate from central price models, with their own features: reserve margin, outage volume, interconnector availability and ramp requirement
- Load profile modelling that respects the buyer's operational constraints — a continuous process cannot shift consumption and a model that assumes it can understates exposure
- Hedge position netting at the correct granularity, including shape and basis mismatch between a baseload hedge and a non-flat profile
- Backtesting of cost-at-risk coverage against realised outcomes, which is the only honest test of a risk model
- Regime monitoring, since a market that has changed structurally invalidates the historical distribution the tails were fitted on
What it changes for the business
Procurement timing
A quantified downside changes when and how much a buyer hedges, rather than hedging on broker sentiment.
Budget defensibility
Cost-at-risk at stated confidence is a figure a finance director can take to a board.
Shape risk visibility
Exposure concentrated in specific windows is identifiable and therefore hedgeable.
Flexibility business case
Quantified tail exposure is what justifies investment in on-site flexibility or load shifting.
How it fits into your product
How it embeds
- Consumption ingestion from your metering, energy management system or data warehouse
- Hedge positions uploaded or synchronised from your contract management system
- Scenario endpoint so treasury can run its own assumptions through the same engine
- Webhooks on tightness and spike alerts into procurement workflows
- Report generation for board and audit packs, with method and assumptions stated
- White-label delivery for consultancies and energy management vendors serving industrial clients
Included in every build
- Authentication, scoped API keys and per-customer rate limiting
- Input validation with predictable, documented error responses
- Versioned endpoints so your integration never breaks without notice
- Request and response logging for audit and dispute resolution
- Latency, error-rate and usage monitoring with alerting
- OpenAPI specification, sandbox environment and client examples
- Backups, failover design and a documented recovery procedure
- An agreed support arrangement once the service is live
How we would build it
about 20 weeksDiscovery and feasibility
Weeks 1–3
This one depends heavily on data access, so we start by proving the sources exist, can be licensed for your use, and actually carry the signal the model needs. If they do not, you find out here.
Architecture and baseline model
Weeks 4–6
A written architecture and a baseline model measured against a holdout period, so you know what accuracy you are buying before the full build starts.
Production build
Weeks 7–16
Data pipelines, model training and serving, historical archive, validation harness, API, security, monitoring and documentation.
Validation and integration
Weeks 17–20
Backtesting against held-out history, accuracy reporting your team can audit, integration support and an agreed retraining cadence.
Commercial models
There is no fixed price list, because the cost is driven by data complexity, integration count, model requirements, request volume and the support level you need. Scope is agreed in writing before development starts.
Fixed-scope prototype
A defined slice of the service, built and priced as one piece of work. The usual first step when the business case needs proving internally.
Fixed-price build
An agreed scope against a written architecture, delivered for an agreed price. Best when the requirements are already clear.
Build then retainer
We build the service, then operate and improve it under a monthly agreement covering monitoring, updates and model maintenance.
White-label product
The service runs under your brand, your domain and your pricing, with MLPivot invisible to your customers.
Questions buyers ask
How much should we trust the tail numbers?
Less than the central estimate, and the API says so in the response rather than burying it. A p99 figure rests on few historical analogues, and the extreme European price periods of recent years were driven by circumstances with almost no precedent. The number is a disciplined scenario, not a probability you can bank. We would present it as a range and show which scenario drives it.
Is this hedging advice?
No. The API quantifies exposure and the cost of scenarios. It does not recommend buying a particular product at a particular time, and in most jurisdictions doing so would be a regulated activity. How your procurement team or your consultancy uses the output is their decision, and we build to whatever framing your compliance function requires.
Can we show the forward curve to our clients?
Usually not, and this is a real constraint on energy software. Forward curve licences from brokers and exchanges typically forbid redistribution and often restrict derived display as well. Derived risk measures computed from the curve are generally acceptable; re-serving the curve itself is not. We design the response schema around the specific licence you hold.
What if our consumption data is poor quality?
Then the risk numbers inherit that quality, and we would rather fix the input than model around it. Sites with estimated rather than metered consumption, or long gaps, produce exposure figures that look precise and are not. During the prototype we would report data quality per site so you can see which parts of the answer are load-bearing.
Does this work for gas as well as power?
Yes, and the structure is similar, though gas has different tail dynamics — storage levels and supply disruption rather than instantaneous scarcity pricing. The spike models are market-specific and we would build them separately rather than reusing power features on a gas curve.
Related blueprints
Electricity Price Forecasting API
Wholesale electricity price forecasts and spike alerts by market and delivery hour, embedded in energy trading and retail software.
Energy Demand Forecasting API
Electricity and gas load forecasts by region, network segment and customer group, for utilities, retailers and network planners.
Solar Production Forecast API
Generation forecasts for solar assets with uncertainty bands and performance anomaly detection, embedded in monitoring and asset management platforms.
Want this built for your platform?
Tell us what your product does today and what you want another system to be able to ask it. We will come back with an approach, a scope and a price.