Energy Trading and Risk Management Software: Why the Tolling Deal Ends Up in a Spreadsheet Next to the Book It Should Be Inside

The deal that is not in the book

A generator and marketer runs physical power at several nodes, gas with transport and storage, financial transmission rights, environmental certificates, and one tolling agreement that represents a meaningful share of the portfolio's optionality. The ETRM captures the forwards and the swaps cleanly. The tolling deal is entered as a placeholder with a notional and a comment, because the vendor's template has no structure for a contract where you pay a capacity charge, supply fuel at your own cost and take the power at a contractual heat rate with availability conditions attached.

So the real valuation lives in a workbook maintained by one analyst. It is rebuilt weekly rather than daily. It uses a curve pulled by hand. When the risk report goes to the committee, the position with the most convexity in the entire portfolio is represented by a number that is four days old and cannot be traced to a source.

Nobody planned this. It is what happens when the system covers 85 percent of the trades and the remaining 15 percent contain most of the risk. The gap is not a reporting inconvenience, it is the part of the book nobody can see moving.

Problem one: structured deals do not fit templates, by definition

Vendor deal templates are built around instruments that repeat across many clients: fixed for floating swaps, physical forwards at a hub, options with standard exercise. That is the right design decision for a product, and it is why the vanilla book is usually fine.

Where it breaks is the contracts that were negotiated rather than traded. Tolling agreements with availability tests and outage provisions. Storage deals with injection and withdrawal ratchets, cycling limits and park and loan features. Transport capacity with fuel retention that varies by path. Load following supply with a shaping obligation and a bandwidth penalty. Heat rate call options with a strike expressed against two commodities. Each of these is genuinely a different valuation problem, and shoehorning them into a user defined field means they sit inside the system without participating in it.

What a build should do is model the deal economics as a first class structure with its own valuation function, then feed the result into the same position, exposure and profit and loss machinery as everything else. The point is not to replicate the vendor's forwards handling. It is to stop having a second book.

Problem two: your curves are your intellectual property and vendors give you a container

Every ETRM ships a curve manager. What it manages is curves someone else builds. The construction, meaning how you blend broker quotes with ISO settlement history, how you derive basis at an illiquid node, how you shape a monthly block into hourly, how you handle the gap between the liquid horizon and the tenor of a twelve year deal, is the firm's own methodology and often the reason the firm makes money.

That methodology tends to live in a mix of Python scripts, a market data subscription and a senior analyst's judgement. The risk is concentration: one person can rebuild it, the process runs on a laptop, and the audit trail for how the mark on a given day was produced is thin.

Bringing curve construction into an engineered service with versioned methodology, stored inputs, a four eyes approval on any change to a production curve, and full reproducibility of any historical mark is one of the highest value builds in this space. It is also usually the first thing an auditor or an acquirer asks to see, and the first thing that cannot be produced.

Problem three: credit exposure is calculated late and by hand

Counterparty exposure in energy trading is not a single number. It is current exposure netted under the agreement in force with that counterparty, plus potential future exposure over the remaining tenor, adjusted for collateral held or posted, guarantees, thresholds and independent amounts, and it changes with every curve move.

Most mid sized firms produce it monthly in a spreadsheet built by the credit analyst. The failure mode is not the arithmetic, it is timing. A counterparty's exposure moves through a threshold during a price spike and nobody calls for collateral for three weeks, or a trader books a deal that pushes a counterparty past a limit that existed only in a document.

A credit engine that recalculates on every curve publication, applies your actual netting and collateral terms per counterparty, and enforces limits at the point of deal capture is a contained piece of engineering with an unusually direct payoff.

Problem four: nobody can explain the profit and loss move

The daily question in every trading operation is why the number changed. A useful answer decomposes it: how much came from curve movement on existing positions, how much from new deals, how much from actualisation as scheduled volumes became metered volumes, how much from settlement adjustments, and how much is unexplained.

That last bucket is the one that matters. When the unexplained residual is consistently small, the risk committee trusts the book. When it is large or lumpy, every conversation becomes an argument about the data instead of about the position. Attribution is not a reporting feature bolted on at the end, it is a design requirement that determines how positions and valuations are stored, and it is far cheaper to build in than to retrofit.

Where Endur, Allegro, Molecule and the mid market sit

ION Openlink Endur is the enterprise standard and it earns that in breadth. It will handle almost anything, and for a large multi commodity trading house it remains the default. The honest caveats are cost and pace: implementations routinely run over a year, extension happens through the vendor's own scripting and specialist consultants at high rates, and small changes take longer than the business expects.

Allegro, now inside the same group, has a similar profile with particular depth in gas and power. The same weight considerations apply.

Molecule has genuinely changed the mid market. It deploys fast, it is cloud native, the interface is modern and for a straightforward power and gas book it is a strong purchase that many firms should make instead of anything custom. Its strength is that it is opinionated. That is also the constraint: heavily structured portfolios with negotiated physical contracts push against the model rather than fitting inside it.

Amphora and Enuit are credible mid market options with real capability and smaller ecosystems, which matters mostly when you need people who already know the system.

Aspect Enterprise Solutions has its deepest heritage in oil and refined products. For a power and gas portfolio it is a less natural fit than the alternatives above.

The build that usually makes sense

Our position is that full custom ETRM is the wrong answer for most firms, and we will say that before quoting anything. Trade capture for vanilla instruments, confirmations, basic settlement and the general plumbing are commodity capability. Rebuilding them is expensive and gains you nothing.

What is worth owning is the layer where your firm is actually different: curve construction with reproducibility, valuation for the structured deals your business negotiates, credit exposure under your specific agreements, and attribution reporting shaped to how your risk committee thinks. Built as a service alongside the packaged system, reading its positions and writing back valuations, that layer typically costs a fraction of a platform replacement and removes the second book entirely.

Full custom becomes defensible in a narrow set of cases: when your business is a single unusual asset class that no vendor models, when you are a small firm whose entire portfolio is structured deals, or when a packaged implementation has already failed twice and the requirements turned out to be genuinely non standard rather than badly specified.

What this costs and how long it takes

Across the quantitative and financial systems Digital Heroes has delivered, the bands run as follows. A structured deal valuation and risk layer with curve construction, credit exposure and attribution reporting runs $150,000 to $350,000 and reaches production in 16 to 24 weeks. A full custom trading and risk platform covering capture, valuation, scheduling and actualisation, settlement and regulatory reporting runs $500,000 to $1,200,000 across 12 to 24 months.

Cost drivers particular to energy trading: the number of distinct structured deal types, since each is its own valuation model plus test suite. Market coverage, because each ISO and each pipeline brings its own data feeds, settlement formats and scheduling interfaces. Whether you need scheduling and actualisation integrated or only valuation. Regulatory reporting obligations, which add a separate workflow with its own deadlines. And model validation, which for anything touching board level risk reporting should be an independent exercise you budget for rather than an afterthought.

How to choose a developer for trading and risk work

Ask them to explain how they would value one of your structured deals before discussing anything else. You are testing whether they can hold the economics in their head, not whether they can write a service. A developer who has never modelled optionality will produce a system that stores your deal and cannot price it.

Ask how a historical mark gets reproduced. The answer must include versioned methodology, stored inputs and an immutable record of published curves. Anything less means you cannot answer an auditor's question about a valuation from last March.

Ask what controls they will build around production curve changes and deal amendments. Four eyes approval, immutable amendment history and separation between who can capture a deal and who can publish a curve are not features, they are the reason anyone will trust the output.

Ask about model validation and whether they expect to be validated by someone else. A team that welcomes independent validation is telling you something useful about their confidence.

Ask who owns the repository and the infrastructure accounts, and get it written before kickoff. At Digital Heroes the client owns the code from the first commit. Your next step is a two hour exercise: list every deal in the portfolio whose valuation currently lives outside the system, and total the notional and the optionality sitting in that list. If that total surprises anyone in the room, you already have your answer.