It is 2.47 on a Tuesday morning when Sarah’s phone lights up. Sarah is the CIO of a mid-sized European energy and commodities trader, and the email is from her head of risk: “Overnight valuation run failed again. Traders will open blind.” Eighteen months earlier, the board had approved a new ETRM platform to replace an ageing, heavily customised system and the spreadsheets that had grown around it. Now the programme was six months late, the budget had been revised twice, and she was starting to wonder whether it would ever go live.
Sarah is a composite, drawn from patterns we have seen across many ETRM and CTRM programmes. But if you are a CIO or IT director responsible for trading systems, her worries will probably feel familiar. Here is her story, the risks that kept her awake at night and, more importantly, how each of them can be managed.
Chapter 1: “Are we buying the right system?”
The programme began with a vendor demonstration that impressed everyone. The trading screens were fast, the risk reports looked elegant and the sales team promised the platform could handle every commodity the business traded. What nobody tested was how it handled their actual deals: the shaped power contracts, the gas storage, the metals with quotational periods.
The risk: choosing a platform on the strength of a polished demo rather than evidence, and discovering the gaps during implementation, when they are most expensive to fix.
How to manage it:
- Document how the business really trades before speaking to vendors, with an as-is assessment of processes, systems and pain points.
- Write requirements as testable business scenarios, not feature lists.
- Run scripted demonstrations using your own deals and edge cases.
- Use an independent adviser with no software to sell during vendor selection.
Chapter 2: “Why does the scope keep growing?”
Three months in, the change requests began. Front office wanted an extra report. Operations needed a new workflow. Finance asked for a different accounting treatment. Each request was reasonable on its own; together they added months.
The risk: scope creep, the single most common cause of ETRM and CTRM budget and schedule overruns.
How to manage it:
- Agree a clear scope baseline covering commodities, processes, interfaces and reports.
- Put every change through a governance process that weighs cost, time and value.
- Distinguish must-haves for go-live from improvements for later phases.
Our article on why ETRM implementations overrun covers the seven decisions that keep programmes on track.
Chapter 3: “The data is worse than we thought”
When the team began migrating historical positions and long-term contracts, they found duplicate counterparties, inconsistent reference data and trades that only one person understood, held in a spreadsheet on a shared drive.
The risk: data migration, routinely underestimated and often the real driver of delay.
How to manage it:
- Start data profiling and cleansing on day one, not at the end.
- Assign business owners for each data domain: counterparties, products, curves, contracts.
- Plan several trial migrations, reconciled against the legacy system, before cut-over.
Chapter 4: “Everything connects to everything”
The new ETRM had to talk to the finance system, the scheduling platform, market data feeds, exchanges, the credit system and a forecasting model owned by another team. Nobody had mapped all of these interfaces at the start, and each one revealed new questions about ownership and timing.
The risk: integration complexity, which turns a system project into an enterprise architecture project.
How to manage it:
- Build an interface inventory during requirements and design, with a named owner for each side of every interface.
- Test integrations end to end with realistic business scenarios, long before go-live.
- Prefer APIs and a shared data layer over point-to-point file transfers where your platforms support them.
Chapter 5: “Are we rebuilding the old system?”
Halfway through, Sarah noticed something uncomfortable. The new platform was being configured to behave exactly like the old one, workarounds included. Dozens of customisations had been requested to replicate familiar screens and reports.
The risk: customisation debt. Every bespoke change adds build, test and upgrade cost for the life of the system, and it is the main reason firms end up stuck on old versions.
How to manage it:
- Adopt an “out of the box unless there is a compelling business case” principle.
- Inventory existing customisations and classify them: still needed, now standard, or obsolete.
- Change processes where standard functionality is good enough. It is usually cheaper than changing software.
Chapter 6: “Where are the business people?”
The project team was strong, but the traders, schedulers and risk analysts who needed to make decisions and test the system were also running the business. Sign-offs slipped. Testing was squeezed into evenings.
The risk: treating an ETRM or CTRM programme as an IT project, when it is really a business transformation.
How to manage it:
- Secure named business owners with dedicated time, and back-fill key roles where needed.
- Give the steering committee real authority, including the business heads whose teams depend on the system.
- Report progress honestly, in business terms, not just milestones.
Chapter 7: “Who is on our side?”
When disagreements arose about what had been promised, Sarah realised that the vendor’s implementation team and her own had different incentives. The vendor wanted to deliver what was in the contract. Her business wanted what it needed.
The risk: vendor dependency, with nobody independent to challenge scope, quality and cost on the client’s behalf.
How to manage it:
- Negotiate implementation scope, assumptions, support and upgrade terms as carefully as the licence.
- Keep an independent voice in governance who represents only your interests.
- Build in-house knowledge throughout, so your team owns the system after go-live.
Chapter 8: “What if go-live goes wrong?”
As go-live approached, the fear shifted. What if the new system produced different valuations? What if month-end could not close? What if the regulatory reports failed?
The risk: disruption to trading, risk, settlement or regulatory reporting such as REMIT and EMIR at cut-over.
How to manage it:
- Plan cut-over around the trading calendar, avoiding month-end and seasonal peaks.
- Run critical processes in parallel and reconcile valuations, positions and reports before switching off the old system.
- Rehearse cut-over, agree go and no-go criteria, and keep a tested fallback plan.
- Put enhanced support in place for the weeks after go-live.
Chapter 9: “And after all that, we have to upgrade again”
Even after go-live, the worry does not end. Vendors release new versions, cloud services evolve and end-of-support dates arrive. A system that was heavily customised becomes harder to upgrade each year, until the business is forced into another expensive programme.
The risk: the upgrade treadmill, and the temptation to defer upgrades until they become crises.
How to manage it:
- Keep customisation low so upgrades stay routine.
- Maintain an automated regression test library based on business scenarios.
- Plan upgrades on a regular cycle, and assess options early when a platform nears end of life. Our guide to choosing between upgrade, cloud or replacement sets out the decision.
Chapter 10: “What about cloud, security and AI?”
Sarah’s board had new questions too. Should the system move to the cloud? Was it secure? And what was the plan for AI, which every vendor now mentioned?
The risk: making technology decisions under pressure without a clear view of security, data, integration and governance.
How to manage it:
- Assess cloud and SaaS options on fit, security, data residency, integration and exit terms, not just cost.
- Treat AI as a set of specific, governed use cases, such as document intake, reconciliation and natural-language reporting, with human approval for decisions. Read our view on how AI is reshaping ETRM and CTRM platforms.
- Fix the data foundation first, because AI is only as reliable as the data beneath it.
The ending Sarah wanted
Sarah’s programme did go live, later than planned but cleanly. What changed was not the software. It was the approach: a reset of scope with the business, a firm line on customisation, a dedicated data workstream, independent challenge in governance and a rehearsed cut-over. Six months after go-live, the overnight batch runs on time, traders open with trusted positions and month-end closes days faster.
That outcome is achievable. In one enterprise-wide programme Orivyn supported for a European metals trader, producer and smelter, the client achieved 50% less manual reconciliation and a 35% faster month-end close. You can read the full case study.
A CIO’s ETRM and CTRM risk checklist
- Have we documented how the business really trades before choosing a platform?
- Are requirements written as testable business scenarios?
- Is there a scope baseline and a change process with real authority?
- Has data migration started, with business owners for each domain?
- Do we have a complete interface inventory with named owners?
- Is there a clear principle limiting customisation?
- Do business teams have dedicated time for decisions and testing?
- Is there an independent voice in governance?
- Is cut-over planned around the trading calendar, with parallel running and fallback?
- Do we have a regression test library and a regular upgrade cycle?
How Orivyn can help
Orivyn is an independent ETRM and CTRM consultancy. We do not sell software, so we sit firmly on your side of the table, from assessment and selection to requirements, implementation, upgrades and programme recovery. Our consultants have hands-on experience across platforms including Endur, Allegro, Aspect, TriplePoint and Quoreka. If your programme is about to start, or is already keeping you awake at night, book a 30-minute review with a senior consultant.
Frequently asked questions
Why do ETRM and CTRM implementations fail?
Most failures trace back to early decisions rather than the software itself: vague scope, underestimated data migration, integrations designed too late, heavy customisation, too little business involvement and weak governance. Each of these can be managed if it is addressed before the build begins.
What are the biggest risks in an ETRM upgrade?
The main risks are customisation that breaks or must be rebuilt, interfaces that stop working, regression in reports and valuations, data issues and disruption to trading at cut-over. A customisation inventory, scenario-based regression testing and a carefully timed cut-over reduce these risks.
What is customisation debt in a CTRM or ETRM system?
Customisation debt is the accumulated cost of bespoke code and configuration added over the years. It makes every upgrade slower, riskier and more expensive, and often traps firms on old versions. Retiring customisation in favour of standard functionality is one of the most effective ways to lower long-term risk.
How long does an ETRM or CTRM implementation take?
A focused deployment for a single commodity can take a few months, while an enterprise, multi-commodity programme with many integrations commonly runs for a year or more. A proper assessment and requirements phase is the best way to set a realistic plan.
Should we move our ETRM or CTRM to the cloud?
Cloud and SaaS platforms can reduce infrastructure burden and make upgrades routine, but usually require less customisation and a clear view of security, data residency, integration and exit terms. The right answer depends on your fit, risk appetite and operating model.
What does an independent ETRM consultant do?
An independent consultant does not sell software. They help you define requirements, select the right platform, challenge the vendor on scope and quality, plan data and integration, govern testing and go-live, and transfer knowledge to your team, representing only your interests.
Sarah is a composite character based on common patterns across ETRM and CTRM programmes and does not represent any individual or organisation.
