Platform Platform overview Modules Solutions Industries Commodities Roles Quant More Pricing Customers Knowledge Center Blog Company Request Demo
Power

Why AI, Data Centers, and Grid Congestion Are Reshaping ETRM Software in 2026

AI-driven electricity demand, grid congestion, and battery storage are reshaping power markets faster than legacy ETRM systems can follow. Why 2026 is the biggest technology shift in energy trading since deregulation.

Executive summary

The energy transition used to be a story about generation, more wind, more solar, fewer fossil plants. In 2026 it has become a story about complexity. Artificial intelligence has turned data centers into some of the largest and fastest-growing electricity consumers on the grid, and their appetite is colliding with a transmission network that was never designed for it. The result is grid congestion, extreme intraday price volatility, and a power market that moves faster and swings harder than at any time since deregulation.

For the technology that energy companies use to trade and manage risk, the ETRM platform, this is an inflection point. Systems built for a slower, more predictable market are visibly straining: overnight batch valuation, manually maintained positions, spreadsheet risk, and disconnected market data struggle to keep pace with a market that can reprice several times before lunch. The desks that thrive over the next few years will be the ones running on platforms designed for event-driven, near-real-time, AI-assisted, multi-asset trading on a single governed data model.

This article looks at what is actually driving the change, why legacy ETRM architectures cannot follow, how AI is reshaping the trading workflow from forecasting through execution to settlement, and what a trading stack built for 2026 looks like. It is written for the people making the decision, heads of trading and risk, CIOs and CTOs, power traders, and ETRM implementation leads, and it is candid about where the value is real and where it is hype. Throughout, it returns to a single conviction: in a market this complex, the quality of every trading decision depends on the integrity, unity, and timeliness of the data underneath it.

The new reality: AI demand, grid congestion, and intraday volatility

Three forces have combined to reshape power markets, and each one amplifies the others.

AI data centers are a new class of load. Training and serving large AI models consumes electricity at a scale and density that is genuinely new. A single large data-center campus can draw as much power as a small city, and unlike traditional industrial load it can be concentrated, fast-ramping, and sited wherever fiber and land are cheap, which is rarely where the grid has spare capacity. The scale is documented: the International Energy Agency projects that global data-center electricity consumption will roughly double from about 415 TWh in 2024 to around 945 TWh by 2030, with AI workloads driving most of that growth [1], and the U.S. Department of Energy’s 2024 study, produced by Lawrence Berkeley National Laboratory, found that data centers already consumed about 4.4% of U.S. electricity in 2023 and could reach roughly 6.7% to 12% by 2028 [2]. Industry bodies including the Electric Power Research Institute have raised similar concerns about localized grid impact [3], and market operators such as PJM, ERCOT, and CAISO, together with analyses of FERC-jurisdictional interconnection queues, point to rising queue volumes and localized capacity pressure [4]. The strain concentrates in specific geographic pockets rather than spreading evenly across the network.

Grid congestion is the direct consequence. When demand concentrates faster than transmission can be built, and transmission planning and construction typically take years, the network becomes congested, and the price of power at one node can diverge sharply from the price a few nodes away. Locational marginal pricing was always a feature of organized power markets, but congestion makes those locational differences larger, more frequent, and more tradable, whether expressed through nodal spreads, Financial Transmission Rights (FTRs), or Congestion Revenue Rights (CRRs). A desk that cannot see and act on nodal and congestion dynamics is leaving both risk and opportunity on the table.

Renewables, batteries, and grid-edge resources make the shape volatile. A grid with heavy wind and solar has a supply curve that swings with the weather and the time of day, with curtailment risk when generation exceeds what the network can absorb. Midday solar can push prices toward zero or negative; a still evening after sunset can spike them. Battery storage sits in the middle of this, charging when power is abundant and cheap and discharging when it is scarce and dear, while demand response, virtual power plants, and other distributed energy resources (DERs) add flexible load and dispatchable capacity at the grid edge. The net effect is intraday volatility that would have been extraordinary a decade ago and is now routine.

Put together, these forces produce a market that is more granular, more locational, more volatile, and faster than the one most ETRM systems were designed for. The trading day is no longer a position taken in the morning and settled at night; it is a continuously changing book that has to be revalued, re-risked, and rebalanced in something close to real time. That is the reality the technology now has to meet.

AI data centernew dense loadTransmission gridcongestionISO / RTOLMP, FTR, dispatchETRM platformprice, risk, settle
How AI data-center load flows through the grid and market operators into the ETRM platform

The chain above is the through-line of this article: new AI-driven load stresses the grid, the grid’s congestion is priced by the market operator, and the ETRM platform is where a desk turns those prices, risks, and physical positions into decisions and settled trades. Each link in that chain is now faster and more granular than legacy systems assume.

Why legacy ETRM platforms cannot keep up

The established ETRM platforms are not bad software. They were engineered carefully for the market that existed when they were built, a market of daily and monthly positions, overnight risk runs, and comparatively stable price relationships. The problem is that their core architecture assumes a pace and a structure the market no longer has.

Overnight batch valuation means managing yesterday. A platform that marks the book in a nightly batch starts every day managing yesterday’s position at yesterday’s prices. In a market that reprices intraday, that is not a minor lag, it is trading on instruments that are hours out of date. Real-time valuation is not a feature these systems can bolt on, because their whole processing model is built around the batch.

Static positions cannot express a fast-moving book. When the current position has to be assembled by gathering and reconciling data from several systems, it is always slightly stale and always provisional. Intraday, when a battery is cycling and a congestion event is unfolding, a position that updates on a schedule rather than continuously is a liability.

Manual scheduling breaks under granularity. Power is scheduled and settled at hourly or sub-hourly granularity, and as flexibility markets and batteries proliferate, the number of distinct scheduling decisions explodes. Manual or semi-manual nomination processes that worked for block products cannot keep up with a book that has to be balanced interval by interval.

Spreadsheet risk is invisible risk. Many desks still run meaningful parts of their risk in spreadsheets bolted onto the edges of the ETRM. In a calm market that is merely fragile; in a volatile one it is dangerous, because the risk numbers lag the book and break exactly when the market moves hardest, which is when they matter most.

Disconnected market data guarantees drift. When prices, curves, and forecasts live in different systems than the trades they value, the two drift apart, and every number becomes a candidate for reconciliation. In a fast market, the time spent reconciling is time the desk does not have.

These limitations share a root cause that is architectural rather than cosmetic. They are not gaps that a patch or a new module closes; they are consequences of a design built for a different market. The answer is therefore not another bolt-on but a platform whose foundation, one governed data model, cloud-native and event-driven, matches the market as it is now.

How AI actually changes trading

AI is the most over-claimed word in trading technology, so it is worth being precise about where it genuinely changes the workflow. On a modern power desk, AI shows up in five concrete places, and in each it augments human judgment rather than replacing it.

Demand forecasting. Predicting load has always been central to power trading, and machine learning models that ingest weather, calendar, economic, and increasingly data-center-specific signals can sharpen those forecasts. The new wrinkle is that AI-driven data-center load is itself hard to forecast, so the models have to learn a demand pattern that is still forming.

Generation forecasting. With heavy renewables, forecasting supply is now as important as forecasting demand. Wind and solar output predictions feed directly into price expectations and into the shape a desk expects the day to take.

Congestion prediction. Anticipating where and when the grid will be constrained is a genuine edge in a nodal market. Models that learn the relationship between load, generation, outages, and historical congestion patterns help a desk position for locational spreads before they blow out.

Price forecasting. Bringing demand, generation, and congestion together into a price view is where the forecasting stack pays off, provided the output is treated as an input to judgment, not an oracle. A confident price forecast on bad data is worse than no forecast at all.

Portfolio optimization. Given a set of positions, forecasts, and constraints, optimization can suggest how to rebalance a book, how to charge and discharge a battery, how to hedge an exposure, how to position for an expected congestion event. Again, the suggestion is only as trustworthy as the governed data and positions it runs on.

The unifying requirement across all five is data. Every one of these models is a function of the same trading reality, the same positions, prices, curves, and reference data, and if that reality is fragmented across systems that disagree, the models inherit the disagreement. This is why grounded, governed AI matters more than clever models: the foundation decides whether the intelligence is reliable or confidently wrong. It is also why the marts and lineage of a governed analytical layer are the unglamorous prerequisite for any serious AI on the desk.

The new trading stack

What does a power trading architecture built for this market actually look like? It is a pipeline that runs from the market operator all the way through to analytics and an AI assistant, with a single governed model in the middle so that every stage reads the same truth.

At the top sit the ISO/RTO and market data: nodal prices and locational marginal prices, load, generation, outages, ancillary-service and capacity-market signals, and the forward curves that price everything downstream, sourced from operators such as PJM, ERCOT, CAISO, and, in Europe, National Grid ESO and the ENTSO-E members. That data flows into a forecast engine, the demand, generation, congestion, and price models described above, whose output informs, but does not dictate, trading decisions.

From there the workflow is the trade lifecycle itself: trade capture records each deal once on the governed model; a position engine keeps the live book current; a risk engine computes VaR, Greeks, scenarios, and limits on that live book; scheduling turns positions into nominated, delivered energy; and settlement turns delivery into cash. Because every stage reads and writes the same record, internal reconciliation is dramatically reduced, valuation, positions, scheduling, and risk operate on the same governed trading model, and there is no overnight batch to fall behind. External reconciliations with exchanges, ISOs and RTOs, ERP, settlement systems, and counterparties remain essential, and a good platform is built to support them rather than pretend they disappear.

Over the top of that operational spine sits the analytics layer , governed, BI-ready marts materialized directly over the trading model, and finally an AI copilot that reads the same governed data to answer questions and surface insight. The crucial point is that the copilot is not a separate brain with its own copy of the data; it is a view onto the one governed model, which is exactly what makes its answers trustworthy.

The difference between this and a legacy stack is not the boxes, since most ETRM diagrams share similar boxes, but what connects them. In a legacy landscape the boxes are separate systems exchanging files and reconciling differences. In a modern one they are functions over a single governed model, which is what allows the whole pipeline to run in an event-driven, near-real-time fashion rather than in nightly stages.

Real-time risk in a volatile market

When the market reprices intraday, risk has to keep up, and that means the whole risk toolkit has to run on the live book rather than an overnight snapshot.

Value at Risk tells a desk where the edge of a normal day lies, but only if it is computed on current positions marked on the same model as valuation. A VaR figure on yesterday’s book is managing yesterday’s risk. In a volatile market, VaR should be paired with Expected Shortfall to see the tail, because the days that matter are precisely the ones VaR excludes.

The Greeks, delta, gamma, vega, theta, quantify how the book’s value responds to moves in price, volatility, and time, and they change continuously as the market moves and as batteries and options reshape the position. Cross-gamma between correlated legs matters especially for spread and storage books.

Scenario and stress testing ask the questions VaR cannot: what would a specific congestion event, a heat wave, or a generation outage do to the whole book, revalued in full? In a market defined by fat-tailed events, this is not an occasional exercise but a routine part of managing the day, alongside the basis, shape, and volume risk that are specific to power. Basis risk arises when a hedge and the position it protects settle at different nodes or hubs; shape risk arises when an hourly profile diverges from the block used to hedge it; and volume risk arises when delivered quantities differ from forecast, all of which a power desk has to see and manage explicitly.

Intraday P&L and intraday VaR become actionable only with real-time valuation. When value updates continuously against known curve moves, a trader can see the effect of a decision immediately and attribute the day’s P&L cleanly to price, curve, time, and new trades rather than reconstructing it after the close.

Position limits that check against a stale book are of little use; enforceable limits require real-time monitoring of the live position, aggregated across the portfolio. And credit and counterparty exposure, including wrong-way risk where exposure rises just as a counterparty weakens, and liquidity risk in thin intraday markets, are themselves live numbers that move with the market. They belong on the same governed model as market risk rather than in a separate system that reconciles after the fact.

Battery trading: optimization at interval granularity

Battery energy storage is the clearest example of why the new market demands new technology. A battery is a trading position that changes state every interval, and extracting its value is a continuous optimization problem.

Charge and discharge optimization is the core: buy and store energy when it is cheap and abundant, release it when it is scarce and expensive. The value depends on the intraday price shape, the battery’s state of charge, its round-trip efficiency losses, its cycle limits, and the degradation that each cycle imposes on the asset, all of which a trading system has to model natively, at interval granularity, rather than as a monthly average. A battery that is dispatched without accounting for degradation and cycle limits can earn revenue today while quietly destroying asset value.

Ancillary services add another dimension. A battery can earn revenue by providing frequency regulation, operating reserves, and other grid services, and the desk has to decide, continuously, whether each interval and each megawatt is worth more in the energy market, in a reserve or frequency-response product, or held against a capacity-market commitment. That co-optimization across energy, ancillary, and capacity revenue streams only works if all the relevant markets sit on one model and are optimized together rather than in sequence.

Locational arbitrage and congestion tie the battery back to the wider market. A battery sited behind a transmission constraint can capture locational spreads that a battery elsewhere cannot, and modelling that requires the same nodal, congestion-aware view the rest of the desk needs. The same logic extends to fleets of distributed batteries aggregated into a virtual power plant, where dispatch has to respect both the physics of each unit and the locational value of where it sits.

None of this is expressible in a system that thinks in monthly blocks. Battery trading is where granularity, state, optionality, and real-time optimization all meet, and where a platform built on a native, granular power model separates cleanly from one retrofitting shape onto a coarser design.

Congestiontransmission limitLMP spreadnodal price gapFTR / CRRhedge congestionBatteryarbitrage spreadSettlementone governed book
Congestion becomes a tradable LMP spread, hedged with FTRs or captured by a battery, and settled on one governed book

The figure shows why congestion, FTRs, and batteries belong on one book: the same nodal price gap that a financial transmission right hedges is the gap a battery arbitrages, and both have to settle against the same governed positions. Split them across systems and the desk loses the consistent view that makes the congestion opportunity tradable in the first place.

Physical and financial, on one book

A modern energy desk does not trade power in isolation. It trades physical power against financial hedges, and increasingly against gas, LNG, carbon, and renewable certificates, and the value and risk only make sense when all of it nets on one book.

Physical power and its financial hedges must net into one exposure, or the desk carries a phantom position whenever the two systems disagree. Gas is joined to power through the spark spread, and a desk trading both needs a consistent view of the two legs to see the real cross-commodity position. LNG links regional gas markets globally through cargoes with index-linked pricing and destination optionality.

Carbon is now a first-class price and risk in many markets, and it belongs on the same book as the energy it prices, not in a bolt-on. Renewable energy certificates trade alongside the clean power they certify. As the environmental and energy markets converge, the ability to hold all of them on one governed model, physical and financial, energy and environmental, becomes a structural advantage rather than a nice-to-have.

This is the multi-asset argument, and it is the same one that runs through everything else here: positions net and risk aggregates correctly only when the whole book lives on one model. Bolt the commodities together from separate systems and the netting becomes a reconciliation exercise that never quite ties out.

Modern reference data: the hierarchy underneath everything

Behind every trade is reference data, and in a complex nodal, multi-asset market the reference-data model is not a background detail, it is the connective tissue that makes everything else possible.

A modern platform models a clean hierarchy: the commodity (power, gas, carbon), the product (a peak block, a nodal contract, an ancillary service), the instrument (the specific tradable with its full contract specification), the location and delivery point (which node, hub, zone, or transmission path), the calendars that govern delivery (ISO and market calendars, delivery and holiday calendars, peak and off-peak definitions), and the curve and benchmark hierarchy that prices it. Get this hierarchy right and the system can represent the full granularity of a nodal market faithfully; get it wrong and the desk is forever working around gaps.

Nodal pricing in particular lives or dies on the location model. A power position is meaningless without knowing precisely which node, hub, or zone it delivers at, and along which transmission path, because that is what determines its exposure to congestion. A reference-data model that treats location, calendars, and curve hierarchies as first-class, hierarchical dimensions is what lets the platform value and risk locational and shape spreads correctly, and lets the forecasting and AI layers reason about congestion at all.

This is unglamorous infrastructure, and it is exactly the sort of thing legacy systems handle awkwardly because it was bolted on as markets grew more granular. A platform designed for today’s market treats governed, hierarchical reference data as a foundation, which is what makes the rest of the stack, valuation, risk, scheduling, analytics, AI, trustworthy.

The AI copilot for traders

The most visible face of AI on a modern desk is the copilot: a natural-language assistant that a trader can ask questions and that answers from the governed trading data. Its value is not novelty, it is speed of insight over data that would otherwise take minutes or hours to assemble.

Consider the kinds of question a copilot grounded in a governed model can answer directly: “Show today’s largest exposure.” “What changed in the book since yesterday?” “Explain today’s P&L.” “What is my exposure if this node congests this evening?” “Suggest a hedge for this position.” Each of these is a query over the live, governed book, and each returns an answer a trader can act on, because the copilot reads the same single model that valuation and risk use.

The critical design principle is that the copilot assists rather than decides. It surfaces, summarizes, explains, and suggests; it does not autonomously move the book, and consequential actions require human approval. Pricing models, risk calculations, and recommendations should remain transparent, explainable, and fully auditable, with a human accountable (see the quant engine), because in trading and risk, a confident but unexplainable answer is a hazard, not a help. That is why grounded AI depends on explainability, data lineage, model monitoring, and prompt governance as much as on the model itself: the copilot must be able to show which governed data a given answer came from, and its behaviour has to be observable and controlled. A copilot grounded in governed data and honest about its role is a genuine productivity multiplier; one bolted onto ungoverned data is a liability with a friendly interface.

Why Gravitas was designed for this future

Gravitas was built from the start on the assumptions this market now demands, rather than retrofitted toward them. That shows up in a set of architectural choices that map directly onto the pressures described in this article.

It is cloud-native, so it scales with volatile intraday volume rather than straining against it. It is API-first, so every capability is a governed service that composes into the rest of the landscape, market data, forecasting, ERP, instead of becoming a silo. It runs on a single governed data model, so capture, valuation, risk, scheduling, settlement, and analytics all read the same truth, and event-driven, near-real-time processing becomes the default operating model rather than an expensive exception.

It is multi-asset and handles physical and financial on one book, so power, gas, LNG, carbon, and certificates net and aggregate correctly. It delivers real-time risk and intraday P&L on the live position. It is AI-ready because it is data-governed first, the governed model and lineage-tracked marts are exactly what make AI reliable. And because it is configuration-driven, new commodities, nodes, products, and reports are configured rather than built, so the platform keeps up as the market keeps changing.

Crucially, all of this is delivered at economics that fit desks the incumbents priced out. The firms feeling this market shift most acutely, mid-size power traders, multi-commodity desks on spreadsheets, teams that evaluated Endur or Allegro and walked away on cost, are exactly who Gravitas is built for. See who Gravitas is for and how it is priced.

Gravitas vs legacy ETRM: a capability comparison

The differences are easiest to see side by side. The table below contrasts a typical legacy ETRM with the Gravitas approach across the capabilities that matter most in an AI-shaped, congestion-driven market.

CapabilityLegacy ETRMGravitas
Cloud-nativeOften on-prem or retrofitted to cloudCloud-native by design
Single governed data modelFrequently fragmented across systemsOne governed model
Real-time valuation & riskOften batch-oriented; varies by moduleReal-time on the live book
Intraday P&LVaries; often periodic rather than liveLive, intraday
Battery / storage tradingVaries by implementation; often coarseNative, interval-level
Nodal & congestion modellingSupported but often added onFirst-class reference data
Carbon & certificatesCommonly a separate add-on moduleOn the same book
REST APIsOften available, but not API-firstAPI-first throughout
Event-driven processingVaries; frequently batch-centricEvent-driven
AI-ready (governed data)Limited; typically needs extra data integrationGoverned foundation for AI
Configuration over codeOften development-heavyConfigured, not custom-built
Fit for mid-size desksOften priced and scoped for the largestRight-sized economics

The comparison is drawn in broad strokes, and the legacy landscape is not uniform: some incumbent platforms do offer cloud deployment, APIs, or battery support, and the specifics vary considerably by vendor, version, and how a given firm has implemented and customised the system over the years. The pattern that holds is structural rather than a matter of any one feature: legacy platforms tend toward fragmentation and batch because their core architecture predates this market, while the Gravitas column follows from a single foundation, one governed, cloud-native, real-time model, which is the recurring theme of this entire piece. Buyers should validate any specific capability against their own shortlist rather than assume the general pattern holds in every case.

An illustrative case: reducing intraday risk on a mid-size power desk

To make this concrete, consider an illustrative mid-size power trader, the kind of desk squarely in the path of these market changes. (This is a representative scenario drawn from the common pattern, not a named customer account.)

The challenge. The desk traded physical and financial power across several nodes, with a growing battery position, and ran its risk in a mix of a legacy system and spreadsheets. Positions updated a few times a day; risk was effectively an overnight number. As intraday volatility rose with renewables and congestion, the desk found itself repeatedly managing yesterday’s risk into today’s market, and the battery’s value was being estimated rather than optimized.

The approach. Moving to a single governed model put capture, valuation, risk, and scheduling on the same live book. Battery charge and discharge were modelled at interval granularity with state of charge and cycle limits. Nodal positions carried their delivery points as first-class reference data, so congestion exposure became visible and risk-managed rather than implicit.

The outcome. The most important change was not a single metric but a shift in posture: the desk moved from managing a stale book to managing the live one. Intraday risk that had previously been invisible between overnight runs became continuously visible, so exposures could be trimmed as they built rather than discovered the next morning. The battery moved from rough estimation to genuine interval-level optimization, capturing spread and congestion value it had been leaving on the table. And reconciliation effort, the hours previously spent making the legacy system and the spreadsheets agree, largely disappeared, because there was one book instead of several.

The indicative outcomes below make the shift concrete. These figures are illustrative, drawn from the common pattern rather than from a single named customer, and are shown to convey the shape and direction of the gains, not as guaranteed or audited results. Actual outcomes vary by desk, market, and starting point.

DimensionBefore (legacy + spreadsheets)After (one governed model)Indicative shift
Intraday risk visibilityEffectively an overnight numberContinuous, near real-timeFrom hours to minutes
Manual reconciliation effortHours daily across systemsLargely eliminatedRoughly 70 to 80% less
Battery dispatchEstimated, spread left on the tableInterval-level optimizationMore captured spread & congestion value
Risk reporting latencyNext-morningOn demand, intradayFaster, more timely hedge adjustments
Congestion exposureImplicit, often unseenFirst-class, risk-managedNodal risk made visible

Read the table as direction and magnitude rather than precise promises: the pattern is a move from periodic, fragmented, after-the-fact numbers to continuous, unified, actionable ones, and the reclaimed time and captured value follow from that. A desk evaluating the change should expect to validate these effects on its own data during a trial rather than take them as given.

The lesson. The gains did not come from a single clever feature. They came from the foundation: one governed model, real-time by construction, granular enough for batteries and nodes. Everything else, the risk visibility, the optimization, the reclaimed reconciliation time, followed from that.

What CIOs and heads of trading should do next

For technology and trading leaders weighing how to respond, the practical takeaways reduce to a short list of priorities. None of them is about a single feature; each is about the foundation that determines whether a platform can keep pace with an AI-shaped, congestion-driven market.

PriorityWhat it means in practice
Assess architecture, not featuresJudge platforms on whether they are cloud-native, real-time, and unified, not on the length of a feature list.
Prioritize unified, governed dataInsist on one governed model as the source of truth, so trading, risk, and settlement reconcile by construction.
Adopt event-driven processingRequire real-time, event-driven position and risk, not overnight batch, so the desk manages the live book.
Integrate forecasting with workflowsValue forecasting that feeds operational decisions and stays grounded in the governed model, not bolt-on analytics.
Evaluate AI on governanceAssess AI by its explainability, data lineage, human oversight, and auditability, not by demo polish.

The unifying test is simple: does the platform give the desk one governed, real-time, granular view of its book that both people and AI can act on and audit? A leader who evaluates against that question, rather than against feature checklists, is far more likely to choose a platform that still fits the business in five years. For a fuller treatment, see selecting the right ETRM platform and the ultimate buyer’s guide.

Implementation realities

Adopting a modern platform is a change program, not a switch that is flipped, and a credible plan acknowledges the practical work involved. The good news is that a clean, unified architecture makes each of these steps more manageable than migrating onto another legacy system, but none of them should be underestimated.

ConsiderationWhat it involves
Parallel runsRunning the new platform alongside the existing one to confirm they agree before cutover.
Incremental rolloutPhasing adoption by commodity, desk, or function to reduce risk rather than switching everything at once.
Data migrationMapping, migrating, validating, and reconciling trades, positions, and reference data against the source.
Historical position reconciliationConfirming that migrated positions and history tie out to the legacy book before relying on the new one.
User adoption & change managementInvolving traders and risk staff early, training them, and supporting the transition so the platform is used well.

A migration handled this way, parallel-run, phased, with rigorous data reconciliation and genuine change management, is a controlled transition rather than a leap of faith. The detail is covered in how to migrate to a new ETRM platform and implementation best practices. The point here is simply that a realistic view of the work, and a platform whose architecture eases it, matter as much as the destination.

The architectural conclusion

The energy transition is no longer only about renewable generation. It is about managing unprecedented market complexity driven by AI-powered electricity demand, distributed energy resources, battery storage, demand response, and increasingly volatile, congested power markets that co-optimize energy, ancillary, and capacity value at interval granularity. That complexity is now the defining challenge of the trading desk, and it is rising faster than legacy technology can follow.

Organizations that continue to rely on ETRM systems built for a slower, simpler market will struggle to respond at the speed modern markets demand, not because their people are less capable, but because their tools were designed for a world that no longer exists. The desks that thrive will be the ones running on a foundation built for this reality: cloud-native, real-time, multi-asset, AI-grounded, and unified on a single governed data model.

That is the platform Gravitas was designed to be. If your desk is feeling the strain of this market, stale positions, overnight risk, spreadsheet fragility, batteries you are estimating rather than optimizing , the fastest way to see the difference is to see it on your own trades. Request a demo and we will map a real-time, AI-ready workflow to the commodities and nodes your desk actually trades.

Sources and further reading

The market context in this article draws on public analysis from energy agencies, national laboratories, and industry bodies. The figures cited are as reported by those sources at the time of writing; readers should consult the originals for the latest data and full methodology.

[1] International Energy Agency, Electricity 2026 and Energy and AI (iea.org/reports/electricity-2026; iea.org/reports/energy-and-ai), on data-center electricity demand roughly doubling toward 2030 with AI as a leading driver.

[2] U.S. Department of Energy / Lawrence Berkeley National Laboratory, 2024 United States Data Center Energy Usage Report (LBNL-2001637) (eta.lbl.gov), on U.S. data-center electricity use reaching about 4.4% of the national total in 2023 and a projected 6.7% to 12% by 2028.

[3] Electric Power Research Institute (EPRI), research and initiatives on data-center load growth and grid impact (epri.com).

[4] U.S. Federal Energy Regulatory Commission (FERC) and independent system operators / regional transmission organizations (PJM, ERCOT, CAISO), on interconnection-queue volumes and locational capacity pressure (ferc.gov).

These references support the market backdrop; the platform and architecture views in this article are Gravitas’s own. Citations are provided for transparency and do not imply endorsement by the cited organizations.

Frequently asked questions

What is AI in ETRM?

AI in an ETRM context means applying machine learning and related techniques to concrete trading and risk problems, demand and generation forecasting, congestion and price prediction, anomaly detection, portfolio optimization, and natural-language assistance, grounded in the platform’s governed trading data. It augments human judgment rather than replacing it, and it is only as reliable as the data underneath it.

How does AI improve energy trading?

It sharpens forecasts of load, generation, congestion, and price; surfaces unusual trades and exposures; helps optimize positions such as battery charge and discharge; and lets traders query the live book in natural language. The value depends entirely on running on unified, governed data, a model on inconsistent data produces confident but wrong output.

Can an ETRM platform support battery storage trading?

Yes, if it models power at interval granularity and tracks state of charge, round-trip efficiency, and cycle limits natively. Battery trading is a continuous optimization problem, buy low, store, sell high, and co-optimize against ancillary markets, which cannot be expressed in a system that thinks in monthly blocks.

What is grid congestion and why does it matter for trading?

Congestion occurs when transmission cannot carry all the power the market wants to move, so prices diverge between locations (nodes). It matters because those locational differences are large, frequent, and tradable, and because AI data-center load is concentrating demand faster than transmission can be built, making congestion a central feature of power markets.

What is nodal pricing?

Nodal (locational marginal) pricing sets a distinct power price at each node on the grid, reflecting local supply, demand, and congestion. Trading a nodal market requires modelling each position’s exact delivery point as first-class reference data, because that is what determines its exposure to congestion.

Why can’t legacy ETRM systems keep up?

Their architecture assumes a slower market: overnight batch valuation, positions assembled from multiple systems, manual scheduling, and spreadsheet risk. In a market that reprices intraday, these produce stale numbers exactly when speed matters most. The limits are architectural, not gaps a patch can close.

What is real-time risk management?

It means computing position, P&L, VaR, Greeks, scenarios, and limits continuously on the live book rather than in an overnight batch. It requires risk to run on the same governed model as valuation, so the risk you see is the risk you actually hold right now.

How is real-time risk different from overnight risk?

Overnight risk describes yesterday’s book at yesterday’s prices; by the time you act on it, the market has moved. Real-time risk updates as trades and prices change, so intraday limits are enforceable and P&L attribution is actionable while it still matters.

What is intraday P&L and why does it need real-time valuation?

Intraday P&L is the running profit and loss of the book during the trading day. It is only meaningful with continuous, real-time valuation; a batch system can only tell you the P&L after the close, by which point it is history rather than a decision input.

How do APIs help an ETRM platform?

An API-first platform exposes every capability as a governed service, so it integrates cleanly with market data, forecasting, ERP, and analytics, and can be extended without reinventing the trade lifecycle. Closed legacy systems, by contrast, become silos that everything else must work around.

Is a cloud-native ETRM secure?

Yes, cloud-native platforms can offer strong authentication, role-based authorization, encryption in transit and at rest, and deployment options (managed, private cloud, or on-premises) that meet data-residency requirements. Security and residency should shape the deployment model, not force a compromise on capability.

What does "single governed data model" mean?

It means trades, positions, reference data, and market data live in one authoritative, validated, versioned store that every function shares. There is no second copy to reconcile and no batch to fall behind, so netting, aggregation, real-time risk, and reliable AI all follow naturally.

How does AI data-center demand affect power markets?

AI training and inference consume electricity at large scale and high density, often concentrated geographically. This has restarted demand growth and strained local transmission, driving congestion and volatility, which in turn raise the bar for the trading technology that has to manage the resulting complexity.

Can a modern ETRM handle physical and financial together?

Yes, and it must. Physical power and its financial hedges only net into a true exposure on one model; the same applies across gas, LNG, carbon, and certificates. Holding them on separate systems turns netting into a reconciliation exercise that never quite ties out.

How does scheduling work in a power ETRM?

Scheduling turns traded positions into nominated, delivered energy, nomination to the ISO or grid, load and generation profiles, and reconciling scheduled against actual, with imbalance flowing into settlement. It has to read the same trades the desk booked, at interval granularity, to keep up with modern markets.

Can an ETRM integrate with SAP, Oracle, or other ERP systems?

An API-first platform integrates with ERP, accounting, and downstream systems through governed interfaces, posting settled results without becoming a silo. Ease of integration is a major driver of total cost of ownership.

What is congestion trading?

Congestion trading takes positions on the price differences between grid locations that arise when transmission is constrained, for example via financial transmission rights or nodal spreads. It requires a platform that models locations and congestion as first-class concepts.

Does AI replace traders?

No. On a well-designed desk AI assists, forecasting, surfacing, explaining, suggesting, while pricing, risk limits, and consequential decisions rest on transparent, auditable methods with a human accountable. A confident but unexplainable answer is a hazard in trading and risk.

What kind of desk benefits most from a modern ETRM?

Mid-size power traders, multi-commodity desks running on spreadsheets, and teams priced out of or slowed down by legacy incumbents benefit most, exactly the firms feeling the AI-and-congestion market shift while lacking enterprise-scale technology budgets.

How disruptive is moving to a cloud-native ETRM?

Far less than legacy implementations are known for. Because a configuration-driven platform is configured rather than custom-built, onboarding maps it to your commodities, nodes, and workflows and connects your data sources without a multi-year project.

What is nodal congestion?

Nodal congestion occurs when the transmission network cannot deliver all the power the market wants to move between locations, so the grid operator dispatches more expensive local generation and prices diverge between nodes. The price gap between two nodes reflects the cost of the constraint between them.

What is locational marginal pricing (LMP)?

LMP is the price of electricity at a specific node, reflecting the marginal cost of supplying the next increment of load there, including energy, congestion, and losses components. Because it varies node by node, trading and risk must be modelled at the nodal level rather than as a single zonal price.

What are FTRs and CRRs?

Financial Transmission Rights (FTRs) and Congestion Revenue Rights (CRRs) are instruments that let a holder hedge or take a position on the congestion price difference between two points on the grid. They are how desks manage, or trade, the locational risk that nodal congestion creates.

Can AI forecast grid congestion?

AI models can help anticipate where and when congestion is likely by learning from load, generation, outage, weather, and historical congestion patterns. The forecasts inform positioning but are treated as decision support, not certainty, and their quality depends entirely on governed, consistent input data.

What is battery optimization?

Battery optimization is deciding, interval by interval, when to charge, discharge, or hold, and whether each megawatt is worth more in the energy, ancillary, or capacity market, subject to state of charge, round-trip efficiency, cycle limits, and degradation. It is a continuous co-optimization problem across revenue streams and locations.

What is interval scheduling?

Interval scheduling means planning and nominating delivery at the hourly or sub-hourly granularity at which power is actually scheduled and settled, rather than in coarse blocks. As batteries and flexible resources proliferate, the number of distinct interval decisions grows sharply, which manual processes struggle to handle.

How does a cloud-native ETRM differ from a legacy platform?

A cloud-native ETRM is designed for elastic scale, event-driven near-real-time processing, and API-first integration on a single governed data model, whereas legacy platforms are typically monolithic, batch-oriented, and hard to integrate. The difference is architectural, not a matter of adding features to an older core.

How does an ETRM integrate with ISO and RTO systems?

Through governed interfaces and APIs that ingest market data (LMPs, load, generation, outages) and submit schedules, nominations, and bids to operators such as PJM, ERCOT, and CAISO, then reconcile settlement statements. External reconciliation with these operators remains essential even when internal reconciliation is minimized.

What is co-optimization in power trading?

Co-optimization is deciding across multiple markets and constraints at once, for example allocating a battery’s capacity between energy, reserves, and frequency regulation to maximize total value, rather than optimizing each market in isolation. It requires all the relevant markets and constraints to sit on one model.

What is an event-driven trading architecture?

An event-driven architecture reacts to each trade, price, or market event as it happens, updating positions, valuation, and risk incrementally, rather than recomputing everything in a nightly batch. It is what makes near-real-time position keeping and intraday risk practical in a fast, volatile market.

Take it with you

Download this article as a PDF

Get a clean, branded PDF of this article to read offline or share with your team. Enter your name and corporate email and we’ll send the download link to your inbox.

Explore further
power  ·  who Gravitas is for  ·  the Gravitas platform  ·  the Knowledge Center
See Gravitas on your own trades

Request a demo

A working walkthrough of trade capture, real-time risk and valuation, and the full lifecycle mapped to the commodities your desk trades.