It’s not malicious. It’s not even a bug. Your ETRM is lying to you because it’s modeling the wrong market.

The trader says the position is worth one number.

Risk says another.

Settlement insists its calculation is the only one that’s right.

Three smart people, one trade, three different answers. I’ve sat in that meeting more times than I can count. And almost every time, nobody was actually wrong — the system was.

ETRM Architecture Diagram

It wasn’t a coding error. It wasn’t a bad feed. It was something quieter and far more expensive: the software was calculating the wrong thing correctly. It valued a Gas Daily position with the monthly forward curve. It treated Chicago Citygate as one price instead of what it really is — Henry Hub plus Basis. It used BalMo after the month had already expired. Each calculation ran clean. Each one was computing a market that doesn’t exist.

That’s what I mean by lying. Not fraud. Not failure. A system that runs perfectly and still tells you a number nobody can defend.

After three decades in Energy Trading and Risk Management, I’ve come to believe there is one truth that matters more than any feature list, vendor demo, or architecture diagram:

“
An ETRM is only as good as its understanding of the business it is trying to model.

When that understanding is wrong, the software doesn’t stutter — it produces confident, consistent, completely misleading numbers. The trader stops trusting it and goes back to a spreadsheet. Risk builds a shadow book. Settlement reconciles by hand. And everyone is right, in their own file, while the system everyone paid for sits in the middle, lying politely.

I’ve worked on projects where traders questioned the numbers, risk teams challenged valuations, accounting struggled with reconciliations, and IT spent countless hours explaining why the software behaved the way it did. In almost every case, the software wasn’t failing because of poor programming—it was failing because the business concepts hadn’t been translated into the system correctly.

That realization has shaped the way I think about ETRM systems.

Throughout my career, I’ve had the privilege of working with traders, schedulers, risk managers, accountants, developers, architects, project managers, and executives across the energy industry. Every project reinforced the same lesson: technology alone never solves business problems. Understanding the business does.

Natural gas is one of the most fascinating commodities in the world.

Its price isn’t determined by a single market. It is influenced by geography, pipeline constraints, weather, storage, transportation, regulation, financial markets, and human behavior. Every day, thousands of commercial decisions ripple through a complex network of physical assets and financial instruments.

An ETRM has one job: represent that reality accurately.

When it succeeds, traders trust the numbers, risk managers understand their exposure, accounting closes the books with confidence, and executives make better decisions.

When it fails, everyone creates their own spreadsheets.

I’ve seen both outcomes.

This series was born from a simple idea.

Over the years, I have accumulated notebooks filled with implementation lessons, architecture sketches, design decisions, production issues, valuation discussions, and conversations with some exceptionally talented people across the industry. Many of those lessons were learned the hard way—during implementations, production support, market disruptions, and difficult project meetings where the answer wasn’t obvious.

Rather than letting those lessons remain scattered across old project documents and personal notes, I decided to organize them into a practical knowledge series.

This is not a product manual. It is not a software tutorial. It is not an academic textbook. It is a collection of practical lessons from the field—written for people who build, support, use, or depend on Energy Trading and Risk Management systems.

Whether you are:

my goal is the same: to explain not only how natural gas markets work, but why successful ETRM systems are designed the way they are.

Along the way, we’ll explore topics such as:

Every chapter builds on the previous one, but each can also stand on its own.

My objective isn’t to convince you that one vendor is better than another or that one architecture is universally correct. Every organization has different priorities, constraints, and business models. Instead, I want to share the principles that remain true regardless of which ETRM platform you use. Those principles are the foundation of systems that traders trust.

Throughout the series, I’ll also share experiences from real projects—moments where a seemingly small design decision had a significant business impact. Some stories will describe successes. Others will describe mistakes. Both are equally valuable because they teach us how complex trading businesses really operate.

If even one chapter helps a business analyst ask a better question, a developer write better software, a trader better understand market behavior, or a project team avoid an expensive implementation mistake, then this series will have achieved its purpose.

Knowledge grows when it is shared. I hope you’ll challenge my ideas, share your own experiences, and contribute to the conversation. The energy industry has always evolved through collaboration, and I believe the next generation of trading systems will be built the same way.

So, welcome to the journey.

Let’s start with one of the simplest statements in natural gas trading—one that quietly influences almost every valuation model, hedge strategy, and ETRM design decision:

Every North American natural gas price is really Henry Hub plus Basis.

💡 Lessons from the Field

I started as a software developer in the early 1990s, but I really got my first taste of an ETRM in the late ’90s — a system called TransEnergy, while I was working for PG&E Energy Trading in Houston, Texas. I was impressed by the intricacies of the trading system, and I soon moved from developing it to understanding how the business of molecules actually works.

That transition — and my curiosity to understand the end-to-end life cycle of a trade — is what brought me to a point where I can sit with a trader, a risk manager, or someone running settlement and genuinely understand each of their perspectives. It was far more rewarding to grasp the business from trade capture all the way through to settlement, and everything in between.

The light-bulb moment came on a day I’ll always remember. I was working on my quarterly performance review, looking back at the major issues we’d resolved and the achievements we’d scored — and I noticed I’d worked on the same problem three different times, with different numbers and different outcomes. When I pieced it all together, I realized why: a trader, a risk manager, and settlement were all showing different reports with different numbers — and I had agreed with each of them, every time. None of them were wrong. The system wasn’t at fault. We had simply fed the system back what it was showing us. Three reports, three perspectives, three numbers.

The real issue was that three different requirements had each served only one group of users, with nobody talking to the others across the company — so they’d baked in different assumptions and different calculations. The developers were right with their code. The architect built what was requested. So this was no longer a software problem. It was a communication problem: the various users had each designed systems to serve themselves, in isolation.

That was the shift for me. I stopped building systems just to complete the development, and started making sure the system represented what the business — across every business line — could confirm to.

Then a consulting project, years later, told me I had to write this down. It was a company that isn’t a typical energy trader — and neither is its IT team. There was no real structure inside the company to handle energy trading. It was a mature company with a very immature ETRM. The business wasn’t fully equipped to run the end-to-end process, and IT had no ETRM expertise at all — their understanding of MTM, P&L, or VaR was built on ChatGPT definitions.

While mentoring this raw but talented pool of developers, I realized I needed to document what I was teaching. I kept explaining the same concept, over and over, at different times. The truth is, new people enter the ETRM field constantly — and there isn’t a single place where anyone can learn what an ETRM system is, what it entails, and how things actually move inside one. I remember the first time a scheduler told me he was “moving molecules from point A to point B” — I didn’t understand a word of it. It took me years to realize what scheduling is and how molecules really move.

What finally set off the alarm bell was a simple question from a developer. I was defining forward curves for the settle curves so that MTM and P&L could be calculated. I mapped the curves and asked the team to use the mappings. One developer asked me, “Why should I map Curve A to Curve B?” I explained that one was a Gas Daily settle curve and the other was a forward curve. He pushed back: “But how do you know that?“

I took it casually at first and tried to give him the rationale — how we map futures and forwards based on location. Then he insisted: “How are you so sure? Where is it written that I have to use these two curves only?”

That question — where is it written? — stayed with me. Because it isn’t written anywhere. Thirty years of hard-won mapping lives in people’s heads, and it’s about time it lived somewhere the next developer, the next architect, and the next business analyst could actually find it.

Why now? There are two shifts happening in this industry, and together they’re going to redefine how we look at these systems in the years ahead.

The first is AI. It’s reckoning through almost every industry, and energy trading won’t be isolated from the revolution it’s bringing. There is a lot to unpack — how AI will let us define new markets and reshape how we do business — and the legacy ETRMs we rely on are going to have to change with it.

The second is, in a way, both older and newer: the rise of renewable certificate trading. Different commodities generate different certificates, and each comes with its own rules and working process. No ETRM can handle that end-to-end trade lifecycle today. The clearest example is Renewable Natural Gas — a relatively new product that’s found both love and a new revenue stream for companies that earlier used to flare it away. So there’s a real gap, and it’s widening: new commodities and new processes, with systems that weren’t built for them.

That widening gap is why now. Because the same mistakes that taught me how ETRMs lie — the wrong assumption, the unshared requirement, the curve nobody bothers to map — are about to get baked into a whole new generation of systems, for commodities we’re only just learning to trade. The flare that became a revenue stream deserves a system that models it correctly, not one that pretends it’s just more gas. And the people building these systems — a new pool of developers and analysts whose understanding of MTM or VaR may begin and end with a chatbot’s answer — deserve a single place where this knowledge actually lives.

That’s the job of this series: not to sell anyone on what comes next, but to write down — before it’s lost again — the business knowledge every future ETRM is going to depend on.

☕ Coffee with Aziz

I almost called this “Author’s Note.” But the best lessons I’ve learned didn’t come from slide decks — they came from conversations. Over coffee, in war rooms, on the walk back from a meeting that didn’t go the way anyone expected.

So that’s what this is, at the end of every chapter. The part of the meeting where the laptops close and someone finally says what they’ve been thinking.

For this first one: the developer who asked me “Where is it written?” was right to ask. That thirty years of knowledge lived only in my head — and a few colleagues’ — is the reason you’re reading this. I don’t have all the answers. I have hard-won lessons, and they’re worth more shared than hoarded.

The software will always be confident. Your job is to be curious.

Grab a coffee. The real work starts in the next chapter. I’m glad you’re here.