Selecting an ETRM platform: the enterprise buyer’s handbook

This handbook exists to help an organisation make one of the largest and most consequential technology decisions it will take: the selection of an Energy or Commodity Trading and Risk Management platform. An ETRM sits at the centre of a trading business. It touches the front office, the middle office, and the back office; it holds the record of every deal; it produces the numbers that drive profit and loss, risk, collateral, and regulatory reporting. A good choice compounds in value for a decade. A poor choice becomes a decade-long tax on the business, paid in reconciliation effort, change lead time, integration friction, and missed opportunity. The stakes justify a disciplined, evidence-based selection, and that is what this handbook is built to support.

It is written to be vendor-neutral and practitioner-focused. It does not tell you which platform to buy. It gives you the frameworks, the questions, the models, and the checklists to reach your own well-founded decision, and to defend that decision to a board, a steering committee, and a procurement function. It is deliberately comprehensive, because the failure mode of ETRM selection is not usually a single bad call; it is a series of small omissions, an unexamined assumption about integration, a skipped question about disaster recovery, an underestimated migration, that compound into a troubled implementation.

Who this handbook is for

This handbook is written for the people who own, sponsor, or execute an ETRM selection. The Chief Information Officer and Chief Technology Officer, who are accountable for the architecture and its fit with the enterprise estate. The Head of Trading and the Head of Risk, whose desks live in the platform every day. The Programme Director, who must deliver the implementation on time and on budget. The procurement and vendor-management teams, who run the commercial process. And the enterprise architects, data leaders, and security officers whose sign-off the decision requires. Each of these readers will find chapters aimed squarely at their concerns, and each will benefit from understanding the others' concerns, because the best selections are made by teams that see the whole picture rather than defending a single vantage point.

How to use the handbook

The handbook is organised as a journey, from framing the decision, through assessing your current and future state, into the detailed evaluation of functional, technical, security, and operational fit, and out the other side through commercials, implementation, and governance. You do not have to read it cover to cover in order, but the sequence reflects the natural order of a selection, and skipping the early framing chapters to jump straight to feature comparison is one of the most common and costly mistakes buyers make.

Throughout, the handbook is paired with downloadable working tools: a total-cost-of-ownership calculator, a request-for-proposal question bank of more than three hundred questions, and a weighted vendor scorecard. These are not illustrations; they are the actual instruments you will use to run the process. The prose explains the thinking; the tools let you execute it.

The central principle: evaluate the lifecycle, not the feature list

If this handbook has a single organising idea, it is this: evaluate platforms against the trade lifecycle and your operating model, not against a checklist of features. Feature checklists are seductive because they are easy to produce and easy to score, but they mislead. Every serious platform will tick almost every box on a feature list, because the boxes describe capabilities that the whole market has had for years. What a checklist cannot capture is how those capabilities fit together, whether they operate on one governed model or several disconnected ones, whether a number produced in the front office reconciles with the same number in the back office by construction or only after a nightly batch, and whether adding a new commodity is a configuration change or a development project.

These questions, of coherence, of architecture, of how the pieces join, are what actually determine whether a platform will serve you well, and they are invisible to a feature checklist. This handbook therefore evaluates platforms by walking a trade through its entire life, from capture through valuation, risk, physical operations, settlement, and reporting, and asking at each step how well the platform serves that step and how cleanly it hands off to the next. That lifecycle lens is the thread that runs through every evaluation chapter.

What a Tier-1 selection process looks like

A disciplined selection has a recognisable shape. It begins with a business case that states, in terms a board will accept, why the organisation is investing and what it expects in return. It assesses the current state honestly, naming the pain that justifies the change. It defines the future operating model the organisation wants, so that the platform is chosen to enable a destination rather than to pave the current cow paths. It runs a structured evaluation across functional, technical, security, and operational dimensions, using a weighted scorecard so that the loudest voice does not win by volume. It performs genuine due diligence on the vendors, including references and financial stability. It models the total cost of ownership over five and ten years, not just the first-year licence. It negotiates from a position of knowledge. And it plans the implementation and the data migration before signing, so that the go-live is a controlled event and not a leap of faith. Each of these stages has a chapter in this handbook and, where useful, a downloadable tool.

The remainder of this chapter is a map. The chapters that follow move from framing (business case, current state, future operating model) into evaluation (functional, technical, data, integration, performance, cloud, security, identity, disaster recovery, AI, reporting, risk, physical, financial, regulatory, master data), then into execution (migration, implementation, due diligence, negotiation, total cost, return on investment), and finally into the artefacts you will use to run and communicate the process (RFP templates, the scorecard, the executive presentation, and the appendices). Read on with a pen in hand; this is a working document.

A note on how to read the evaluation chapters

The evaluation chapters that form the core of this handbook (functional, technical, data, integration, performance, cloud, security, identity, disaster recovery, AI, reporting, risk, physical, financial, regulatory, and master data) each follow the same shape. They explain what to assess and why it matters, they surface the architectural questions that a feature list hides, and they connect back to the total cost of ownership and the scorecard. Read each chapter with your own operation in mind, marking which criteria are must-haves for you and which are merely desirable, because that prioritisation is what you will carry into the request for proposal and the weighted scorecard. The handbook is deliberately broad so that no dimension is missed; your job as you read is to make it specific to your operation.

No ETRM selection survives contact with a board without a business case, and a weak business case produces a weak selection. The purpose of the business case is not merely to secure funding; it is to force the organisation to articulate, before it spends a cent, why it is investing, what specifically it expects to change, and how it will know whether the investment succeeded. A business case built only to unlock budget, and then filed away, is a missed opportunity. A business case used as the north star of the programme, revisited at every gate, keeps the selection honest.

Start with the problem, not the solution

The most common error in an ETRM business case is to begin with the solution, we need a new platform, and work backwards to justify it. This produces a case that lists features and asserts benefits. A strong case begins with the problem: what specifically is the current state costing the business, in money, in risk, in lost opportunity, and in the daily experience of the people who use the systems? Only once the problem is quantified does the case turn to the solution, and then it can show, credibly, how the solution addresses the named problem.

Quantifying the problem is uncomfortable work, because it requires the organisation to admit the cost of its current state. How many people spend how many hours reconciling positions across disconnected systems? How long does it take to add a new commodity, and what business was declined or delayed because the system could not support it in time? How often do numbers disagree between the front and back office, and what does resolving those disagreements cost? What is the expected annual cost of a data or pricing error, weighted by its probability? These figures are rarely tracked, which is precisely why the current state feels tolerable: its cost is diffuse and invisible. The business case makes it visible.

The categories of benefit

ETRM benefits fall into recognisable categories, and a credible case addresses each explicitly rather than asserting a single headline number.

• Efficiency benefits come from removing manual effort: reconciliation, re-keying, manual report production, and the workarounds that accumulate around a system that no longer fits. These are the easiest to quantify and the easiest for a board to believe, because they map to hours and headcount.
• Risk-reduction benefits come from fewer errors, better controls, faster and more accurate risk numbers, and the ability to see and act on exposures intraday rather than a day late. These are harder to quantify but often larger, because a single avoided loss can dwarf years of efficiency savings.
• Agility benefits come from the ability to change faster: to add a commodity, launch a product, enter a market, or produce a new report as a configuration rather than a project. These are the hardest to quantify and the most strategically important, because they determine whether technology enables or constrains the business.
• Compliance benefits come from meeting regulatory obligations more reliably and more cheaply, and from being able to evidence controls to auditors and regulators without a fire drill each time.

Building the financial case

The financial case rests on two models that this handbook provides as working tools: the total cost of ownership model, which captures what the platform will cost over five and ten years, and the return on investment model, which weighs those costs against the quantified benefits. The discipline of building both forces realism. A benefits case with no cost model is a wish; a cost model with no benefits case is a threat. Together they produce a net present value and a payback period that a board can weigh against other uses of the same capital.

Be conservative with benefits and complete with costs. The credibility of the whole case depends on the board believing the numbers, and boards have seen many technology cases that promised transformational benefits and delivered overruns. A case that claims modest, well-evidenced benefits and a complete, honest cost, including the internal effort and the change costs that optimistic cases omit, will win more trust than a case that promises the world. Under-promise in the case so that the programme can over-deliver in reality.

Framing the investment against alternatives

A board does not evaluate an investment in isolation; it evaluates it against alternatives, including the alternative of doing nothing. The business case should therefore frame the decision as a choice between defined options: retain and extend the current platform, replace it with a modern platform, or some staged path between the two. For each option, the case should show the cost, the benefit, the risk, and the strategic implication. Crucially, the do-nothing option is not free: it carries the ongoing cost of the current state, which the case has already quantified, plus the rising cost of a platform falling further behind the market. Making the true cost of inaction explicit is often the single most persuasive element of the case.

The output of this chapter, a quantified problem, a categorised benefit case, a financial model, and a framed choice among alternatives, is the foundation everything else rests on. With it, the selection has a purpose against which every later decision can be tested. Without it, the selection drifts toward whichever platform demonstrates best, which is not the same as whichever platform serves the business best.

A minimum viable business case

If time is short and a full business case is not yet feasible, a minimum viable case still needs four things: a quantified statement of what the current state costs, a categorised statement of the benefits expected, a cost model over at least five years, and a framed comparison against doing nothing. Even in outline, these four elements force the discipline that separates a real case from a wish, and they can be deepened as the selection proceeds. What a case must never do is assert benefits without quantifying the problem they solve, because that is the pattern boards have learned to distrust.

You cannot choose where to go without knowing where you stand. The current-state assessment is the honest inventory of the systems, processes, data, and pain that make up your trading operation today. It serves two purposes: it grounds the business case in fact, and it defines the baseline against which any new platform must demonstrate improvement. Skipping it, or doing it superficially, is how organisations end up selecting a platform that solves problems they do not have while missing the ones they do.

Map the system landscape

Begin by mapping the systems that touch the trade lifecycle: trade capture, valuation, risk, scheduling, settlement, reporting, market data, and the general ledger. For each, record what it does, who uses it, what it integrates with, how data moves in and out, and how it is supported. The goal is a clear picture of the estate, including the spreadsheets and end-user tools that have quietly become load-bearing. In most trading operations the true system landscape is more fragmented than the official architecture diagram admits, and the gaps between systems, bridged by manual effort and spreadsheets, are where much of the cost and risk lives.

Pay particular attention to the interfaces between systems. Every interface is a place where data is copied, transformed, and potentially corrupted, and every interface must be maintained. Counting the interfaces, and understanding how brittle each is, gives a concrete measure of the integration burden the current state carries and that a consolidated platform could remove.

Assess the data

Data is the substance of a trading operation, and its current state deserves specific assessment. Where does reference data (commodities, counterparties, calendars, curves) live, and is there a single source of truth or several competing copies? How is data quality managed, and how often do data errors cause downstream problems? Can the organisation reproduce a historical position or valuation as of a past date, or is the past effectively unrecoverable? The answers reveal how much of the migration effort will be spent cleaning and consolidating data, which is almost always the most underestimated part of an ETRM implementation.

Document the processes and their pain

For each major process, trade capture, end-of-day valuation, risk production, settlement, reporting, document how it works today and where it hurts. The pain points are the raw material of the business case and the requirements. Which processes require manual intervention that a better platform would remove? Which are slow, and what does the slowness cost? Which are error-prone, and what do the errors cost? Which cannot be done at all today, representing capability the business wants but the current state cannot provide? Capturing pain concretely, with examples and, where possible, numbers, turns vague dissatisfaction into specific, addressable requirements.

Capture the requirements the current state implies

The current-state assessment naturally produces a first draft of requirements: everything the current systems do that the new platform must continue to do, plus everything they fail to do that the new platform must provide. This draft feeds directly into the functional evaluation and the RFP. Be careful, though, to distinguish requirements that reflect genuine business need from requirements that merely encode the peculiarities of the current system. The aim is to carry forward the need, not the accidental way the old system happened to meet it. This distinction, need versus incumbent implementation, is where the current-state assessment connects to the future operating model, which is the subject of the next chapter.

Done well, the current-state assessment is uncomfortable reading, because it names the true cost and risk of how things work today. That discomfort is the point. An organisation that has looked clearly at its current state is far better equipped to choose a future than one that has not, and far less likely to reproduce its current problems in a new and more expensive system.

The most expensive mistake in an ETRM selection is to choose a platform to support how you work today, rather than how you intend to work tomorrow. A platform is a decade-long commitment. The business it must serve will change over that decade: new commodities, new markets, new products, new regulations, new scale. The future operating model is the organisation's considered statement of the destination it wants the platform to enable, and choosing against that destination rather than against the status quo is what separates a strategic selection from a tactical one.

Define the destination before evaluating the vehicles

Before comparing platforms, the organisation should articulate the operating model it wants: the commodities and markets it intends to trade, the products it wants to offer, the degree of straight-through processing it aspires to, the speed of change it needs, the analytical and risk capabilities it wants at its fingertips, and the shape of the team that will run it. This is a business exercise, not a technology one, and it should involve the front office, risk, operations, and finance, not just IT. The output is a picture of the target operation, against which each platform can be assessed for fit.

The future operating model does not have to be certain to be useful. No one can predict a decade precisely. But the difference between an organisation that has thought explicitly about its direction and one that has not is stark. The former can ask a platform pointed questions about the capabilities it will need; the latter can only ask about the capabilities it needs today, and will discover the gaps later, at the worst possible time.

Design for change, not just for today's requirements

A central theme of the future operating model is agility: the ability to change without a project every time. The organisations that thrive are those whose platforms let them add a commodity, launch a product, or produce a report as a configuration change rather than a development effort. When defining the operating model, name the kinds of change the business expects to make, and treat the platform's ability to absorb that change cheaply as a first-class requirement, not an afterthought. This is where the lifecycle-and-architecture lens of this handbook pays off: a platform built on one governed model and a configuration-first philosophy will absorb change far more cheaply than one where every change is a development project, and that difference compounds over the life of the platform.

Consider the target team and support model

The operating model is not only about the platform; it is about the people who run it. A modern cloud-native platform typically requires a smaller, differently-shaped support team than a legacy on-premises one: fewer infrastructure specialists, more configuration and analytics skills. The organisation should think through the team it wants to run the future operation, because that team shape affects both the total cost of ownership and the kind of platform that fits. A platform that assumes a large specialist team is a poor fit for an organisation that wants to run lean, however capable it is in the abstract.

Translate the operating model into evaluation criteria

The practical output of this chapter is a set of forward-looking evaluation criteria that sit alongside the current-state requirements. Where the current state asks can it do what we do now, the operating model asks can it enable where we are going. These forward-looking criteria, agility, scalability, extensibility to new commodities and markets, readiness for analytical and AI capabilities, deserve significant weight in the scorecard, because they determine the platform's value over its whole life rather than just its first year. A platform that meets every current requirement but cannot grow with the business is a decade-long constraint wearing the disguise of a good fit.

The functional evaluation is where most buyers spend most of their energy, and where the lifecycle lens matters most. The temptation is to build a vast checklist of features and score each platform against it. Resist it. A checklist of several hundred features will be answered yes by every serious platform, and the exercise will consume enormous effort while distinguishing nothing. Instead, evaluate function by walking a trade through its entire life and assessing, at each stage, how well the platform serves that stage and how cleanly it connects to the next.

Walk the lifecycle

Take a representative deal, ideally several, spanning the commodities and instruments you trade, and follow each through the platform from capture to settlement. At capture, assess how the trade is entered, validated, and enriched, and whether it lands on a governed model shared with everything downstream. At valuation, assess how the trade is marked, on what curves, with what models, and whether the valuation is reproducible as of a past date. At risk, assess whether the trade appears immediately in the live position and how the platform computes and aggregates risk. For physical deals, assess how the trade flows into scheduling and operations. At settlement, assess how the trade becomes an invoice and reconciles to actuals. At each handoff, ask the decisive question: does the next stage read the same governed record, or is the trade copied, re-keyed, or reconciled across a boundary?

This lifecycle walk reveals what a checklist hides. Two platforms may both claim trade capture, valuation, risk, and settlement, and both may tick every feature box, yet one may run them all on a single governed model while the other stitches together separate modules that each hold their own copy of the trade. The first reconciles by construction; the second reconciles by nightly batch, with all the cost, delay, and risk that implies. Only the lifecycle walk exposes this difference, and it is the single most important functional distinction between platforms.

The functional domains

Within the lifecycle, the functional evaluation covers a set of domains, each of which has its own chapter later in this handbook and its own section in the RFP question bank. Trade lifecycle and capture; valuation and pricing; risk analytics; physical operations and scheduling; settlement and financial operations; and reporting and analytics. For each domain, the evaluation should assess both breadth (does it cover the instruments and processes you need) and depth (does it do so well, or merely nominally). A platform that covers an instrument in name but handles it poorly is worse than one that is honest about not covering it, because the shortfall will surface only after commitment.

Building the criteria

The functional criteria for the scorecard should be derived from the lifecycle walk and the domain assessment, expressed as capabilities that matter to your operation rather than as generic features. Rather than does it support options, ask does it price the specific options we trade, produce the Greeks we manage, and let us reproduce a past valuation for a dispute or an audit. Specific, operation-relevant criteria discriminate between platforms; generic feature criteria do not. The RFP question bank that accompanies this handbook provides more than three hundred such questions across every functional domain, structured so that vendors answer in a way you can score consistently.

Weighting the functional score

Not every function matters equally to every organisation. A physically-heavy operation weights scheduling and operations highly; a financially-focused desk weights valuation and risk. The weighted scorecard that accompanies this handbook lets you set the weight of each domain to reflect your priorities, so that the evaluation measures fit to your operation rather than fit to a generic ideal. Set those weights deliberately, with the front office, risk, and operations in the room, before you see the scores, so that the weighting reflects genuine priority rather than a post-hoc justification of a preferred outcome.

Functional evaluation checklist

Before concluding the functional evaluation, confirm that you have, for each platform:

• walked at least one representative deal per commodity through the full lifecycle, capture to settlement;
• identified, at every handoff, whether the next stage reads the same governed record or a copy;
• assessed both breadth (does it cover your instruments) and depth (does it cover them well);
• distinguished capabilities delivered out of the box from those requiring configuration or customization;
• scored each functional domain against criteria specific to your operation, not generic features;
• set the domain weights with the front office, risk, and operations before seeing the scores.

Beneath the functions lies the architecture, and the architecture determines far more about a platform's long-term value than any individual feature. Two platforms with identical feature lists can differ enormously in how they are built, and those differences govern how the platform scales, how cleanly it integrates, how cheaply it changes, and whether its numbers reconcile by construction or by batch. The technical architecture review is where the evaluation looks past what the platform does to how it is built.

One governed model, or many?

The single most important architectural question is whether the platform operates on one governed data model shared by every function, or on several models stitched together. This is the architectural root of reconciliation. When trade, valuation, risk, scheduling, settlement, and reporting all read and write the same model, a number computed in one place is the same number everywhere, and reconciliation is unnecessary because there is nothing to reconcile. When each function holds its own copy, the copies drift, and reconciliation becomes a permanent tax. A platform's answer to this one question predicts more about the daily experience of running it than any feature comparison.

Probe the answer carefully, because every vendor will claim integration. The question is not whether the modules are integrated but whether they share one model or synchronise several. Ask to see how a trade booked in the front office appears in risk and in settlement, and whether that is the same record or a propagated copy. Ask how the platform reconciles front-office and back-office numbers, and if the answer involves a reconciliation process, you have learned that the platform holds multiple copies.

API-first and event-driven

A modern platform exposes every capability through a governed API and emits events when meaningful things happen. This matters for two reasons. First, it determines how cleanly the platform integrates with the rest of the estate: an API-first platform integrates through supported, versioned interfaces, while a platform without a real API surface must be integrated through brittle back doors. Second, it determines whether the platform can participate in real-time, event-driven processes, or whether it remains locked in a batch paradigm. Assess the API surface concretely: its coverage, its documentation, its versioning discipline, and the events it emits.

The analytical layer

Operational systems are optimised for processing transactions, not for analysis. A well-architected platform provides a governed analytical layer, materialised from the operational model, so that reporting and analytics run on trusted, consistent data without nightly exports to a separate warehouse. Assess whether the platform offers such a layer, whether it stays consistent with the operational data, and whether it supports the as-of, historical analysis that trading operations frequently need. A platform that forces every analytical question through a nightly export to a separate system has pushed a hard problem, keeping analytics consistent with operations, onto you.

Deployment and technology

Finally, assess the deployment model and technology stack. Is the platform genuinely cloud-native, designed for the elasticity and managed operation of the cloud, or is it a legacy application hosted in the cloud, carrying its on-premises assumptions with it? The distinction matters for scalability, cost, and the pace of updates. Understand the technology stack and its dependencies, and assess whether they align with your enterprise standards and skills. This connects to the cloud and infrastructure chapter, where the deployment question is examined in depth. The architecture review is the lens through which every later technical chapter, data, integration, performance, cloud, security, is focused, because all of them are downstream of how the platform is fundamentally built.

Architecture review checklist

The architecture review should leave you able to answer, for each platform:

• does every function operate on one governed model, or are several models synchronised?
• if numbers are reconciled between front and back office, what does that reveal about the model?
• is every capability exposed through a governed, versioned API, and what events does it emit?
• is there a governed analytical layer consistent with the operational data, or a nightly export?
• is the platform genuinely cloud-native, or a legacy application hosted in the cloud?
• what is the technology stack, and does it align with your enterprise standards and skills?

The data model is the platform. Every function is ultimately an operation on the model, and the quality of the model determines the quality of everything built on it. A platform with a coherent, governed, well-designed data model can support functions the vendor has not even built yet, because the data is there to build on. A platform with a fragmented or poorly-designed model constrains every function, however polished the interface. The data model assessment looks beneath the features at the foundation they stand on.

Coherence and governance

Assess whether the platform has a single, coherent model of trades and reference data, governed as a system of record, or whether data is scattered across modules with no single authority. A governed model has clear ownership, controlled change, and a single version of each fact. Ask how reference data, commodities, counterparties, calendars, curves, is managed: is there one golden source, or several copies that must be kept in sync? The answer predicts how much of your operation will be spent keeping data consistent versus using it.

Versioning and bitemporality

Trading operations live and die by their ability to answer questions about the past. What was the position on the day of the dispute? What was the book worth at the moment of the default, on the curve that was live then? These questions require a bitemporal model, one that records not only how the world was at each past moment but how the system knew it. Assess whether the platform is bitemporal, whether it versions every change, and whether it can reproduce a past state exactly rather than approximately. This capability is invisible on a feature list but decisive in an audit, a dispute, or a regulatory examination, and it is very hard to bolt on to a platform not designed for it.

Lineage

When a number is questioned, and in a trading operation numbers are questioned constantly, the ability to trace it to its inputs is decisive. Assess whether the platform captures lineage: can it show that a disputed valuation came from these positions, this curve, this model version, each traceable to its source? Lineage turns an assertion into a demonstration, and a demonstration settles arguments that an assertion prolongs. A platform without lineage leaves you defending your numbers by reputation; a platform with it lets you defend them by evidence.

Extensibility

Finally, assess whether the model can be extended, to a new commodity, a new instrument, a new attribute, as configuration rather than as a schema-breaking development effort. An extensible model absorbs the business's growth cheaply; a rigid one turns every new requirement into a project. Ask specifically how a new commodity or a new deal type is added, and whether doing so is a configuration change the organisation can make or a development effort that requires the vendor. The answer is a direct measure of the agility the future operating model demands, and it is determined almost entirely by the design of the data model.

No ETRM lives alone. It must exchange data with market-data providers, exchanges, the general ledger, enterprise resource planning, credit and collateral systems, regulatory reporting, and a long tail of downstream consumers. Integration is where much of the cost and risk of an ETRM implementation actually lives, and where the difference between an API-first modern platform and a legacy one is most keenly felt. The integration assessment maps what must connect and evaluates how cleanly each platform can connect it.

Inventory the integrations

Begin from the current-state assessment's map of interfaces and build a complete inventory of the integrations the new platform must support: every inbound feed, every outbound consumer, and every system it must exchange data with in both directions. For each, record the data, the direction, the frequency, and the criticality. This inventory drives both the integration assessment and the integration line in the total cost of ownership model, because each integration has a build cost and an ongoing maintenance cost that the TCO must capture.

Assess the integration mechanisms

For each platform, assess how it integrates. Does it offer a governed, documented, versioned API that supports the reads and writes you need? Does it emit events that let downstream systems react in real time rather than polling or waiting for a batch? Does it provide standard connectors for the common systems, market data, the general ledger, the major exchanges, or must every integration be built from scratch? Are there software development kits that reduce the effort of building against the platform? The richer and more standard the integration mechanisms, the lower the build cost, the maintenance cost, and the risk.

Probe stability across upgrades specifically. An integration is not built once; it must survive the platform's upgrades over a decade. Ask how the platform versions its APIs, how breaking changes are communicated, and how long old versions are supported. A platform whose interfaces break with every upgrade turns integration into a permanent maintenance burden; one with disciplined versioning lets integrations built once keep working.

Market data as a special case

Market data deserves specific attention, because it is the raw material of every valuation and risk number, and because it arrives from many sources in many formats. Assess how the platform ingests, normalises, versions, and validates market data. Can it reproduce the market as of a past date? How does it handle stale or missing prices? How are curves and volatility surfaces constructed from the raw quotes? A platform that handles market data well removes a large and error-prone burden; one that handles it poorly pushes that burden onto you.

The integration cost in the TCO

The integration inventory feeds directly into the total cost of ownership model, where the build cost per integration and the annual maintenance cost are significant lines. A platform that integrates cleanly through standard, API-first mechanisms will carry a lower integration cost, in both build and maintenance, than one that requires bespoke, brittle interfaces. Because integration is a recurring cost over the platform's whole life, this difference compounds, and it is one of the places where the architecture chapter's distinctions translate directly into money in the TCO.

Integration assessment checklist

For a complete integration assessment, confirm you have:

• a full inventory of inbound feeds, outbound consumers, and bidirectional exchanges, with criticality;
• assessed the API surface, event model, standard connectors, and SDKs of each platform;
• probed how interfaces survive upgrades, and how breaking changes are versioned and communicated;
• assessed market-data ingestion, normalisation, versioning, and as-of reproduction specifically;
• fed the build and maintenance cost of each integration into the total cost of ownership model.

A platform that works at demonstration scale may struggle at production scale, and a platform that meets today's volumes may buckle under tomorrow's. Performance and scalability determine whether the platform will keep up as the business grows, and whether its heaviest workloads, the end-of-day risk run, the large report, the stress test across the whole book, complete in the time the business needs. This chapter assesses both the platform's performance today and its ability to scale.

Interactive performance

Assess the responsiveness of the platform for the interactive tasks users perform constantly: capturing a trade, pulling up a position, running a valuation, viewing risk. Slow interactive performance is a daily tax on every user, and it compounds across a large team. Ask for response-time expectations at your scale, and where possible test them against realistic data volumes rather than a clean demonstration environment, because the two can differ dramatically.

Batch and compute-heavy workloads

Trading operations have heavy periodic workloads, the end-of-day risk run, value-at-risk across the portfolio, stress tests, that demand large compute for a short window. Assess how the platform handles these: how long they take at your scale, whether they can run within the operational window, and how the platform provisions the compute they require. A cloud-native platform can scale compute out for the run and release it afterwards, turning a large fixed cost into a small variable one; a legacy platform must be sized for the peak and carry that capacity the rest of the time. This distinction affects both performance and cost.

Scaling with growth

Beyond today's performance, assess how the platform scales as volume, users, and complexity grow. Does it scale horizontally, adding capacity by adding nodes, or is it limited by the size of a single machine? Does performance degrade gracefully or fall off a cliff as load rises? The future operating model's growth expectations should be tested against the platform's scaling behaviour, because a platform that meets today's needs but cannot grow is a constraint waiting to bind.

Isolation of workloads

Finally, assess whether heavy workloads are isolated from interactive users. In a poorly-architected platform, a large risk run or report can slow the system for everyone; in a well-architected one, compute-heavy jobs run on separate capacity that does not affect interactive performance. Ask how the platform separates these workloads, because the answer determines whether your traders' screens freeze every time the risk run starts. Performance and scalability are easy to overlook in a selection focused on features, but they determine whether the platform is a pleasure or a frustration to use every day, and whether it will still serve the business at twice today's scale.

How and where a platform runs shapes its cost, its scalability, its resilience, and the pace at which it improves. The cloud has changed the economics of trading technology profoundly, but not every platform that claims the cloud has genuinely embraced it. This chapter assesses the deployment and infrastructure model and helps distinguish a genuinely cloud-native platform from a legacy application merely hosted in the cloud.

Cloud-native versus cloud-hosted

The critical distinction is between a platform designed for the cloud and one merely running in it. A cloud-native platform is built to exploit the cloud's elasticity: it scales compute up and down with demand, provisions environments through code, and is operated as a managed service that improves continuously. A cloud-hosted legacy platform runs the same monolithic application it always did, on cloud servers instead of your own, carrying its on-premises assumptions, big-bang upgrades, fixed capacity, manual operation, with it. The two can look similar in a demonstration but differ enormously in cost, agility, and the pace of improvement. Probe which one you are looking at by asking how the platform scales, how it is upgraded, and how environments are provisioned.

Deployment options and data residency

Assess the deployment options the platform offers, managed software as a service, private cloud, on-premises, and whether they match your constraints. Data residency and sovereignty matter in many jurisdictions: assess where data can be stored and processed, and whether the platform can meet your regulatory obligations on data location. For organisations with strict requirements, the availability of a private-cloud or on-premises option may be a hard constraint, though it typically comes at a cost in agility and operational burden that the total cost of ownership model should capture.

Resilience and recovery

Assess the platform's resilience: its historical availability, its backup and recovery commitments, and its disaster-recovery architecture. What are the recovery point and recovery time objectives, and are they tested? This connects to the disaster-recovery chapter, but the infrastructure assessment should confirm that the platform's resilience matches the criticality of a system that sits at the centre of a trading operation. An ETRM outage stops trading, so resilience is not a technical nicety but a business-continuity requirement.

Operational model and cost transparency

Finally, assess who operates the infrastructure and how transparent its cost is. In a managed cloud-native model, the vendor operates the infrastructure, patches it, monitors it, and scales it, removing that burden from you; the trade-off is dependence on the vendor's operation and a subscription cost. In a self-operated model, you carry the operational burden but retain control. The choice affects both the total cost of ownership and the shape of the team you need, which ties back to the future operating model. Understand which model each platform assumes, and cost it honestly in the TCO, including the internal operational effort that a self-operated model requires and a managed model removes.

An ETRM holds the record of every deal and produces the numbers that drive the business. A security failure in such a system is not a minor incident; it is a potential catastrophe, exposing positions, enabling fraud, or corrupting the record of record. Security therefore deserves rigorous assessment, and it is an area where claims are easy and evidence is essential. This chapter sets out how to assess a platform's security architecture beyond the reassuring generalities every vendor offers.

Defence in depth

Assess whether the platform's security is layered, defence in depth, rather than resting on a single control. Data should be encrypted in transit and at rest, with keys managed properly and, ideally, the option for customer-managed keys. Network controls, application controls, and data controls should reinforce one another, so that the failure of any one does not expose the system. Ask the platform to describe its security architecture in layers, and be wary of answers that rest heavily on a single mechanism.

Certifications as evidence

Independent certifications provide evidence that security claims have been examined by a third party. A current SOC 2 Type II report and ISO 27001 certification indicate that the vendor's controls have been audited against recognised standards. Ask for these certifications, read the reports rather than accepting the logos, and note any exceptions the auditors raised. Certifications are not a guarantee, but their absence is a warning, and the detail in the reports often reveals more than the headline.

Testing and vulnerability management

Assess how the vendor tests its own security and manages vulnerabilities. How often does it commission penetration testing, and how does it remediate findings? How quickly does it patch vulnerabilities, and how does it handle the disclosure of new ones? Does it run a bug-bounty or responsible-disclosure programme? A vendor with a mature, cadenced approach to testing and patching is far safer than one that treats security as a point-in-time certification exercise, because threats evolve continuously and security must evolve with them.

Audit logging and the record of record

Because the ETRM is the record of record, the integrity and auditability of its data are security concerns as much as availability. Assess how the platform logs consequential actions, how those logs are protected from tampering, and how long they are retained. A complete, tamper-evident audit trail is both a security control and, as the dispute-resolution and regulatory chapters discuss, a business asset. Confirm that the platform records who did what and when, in a log that cannot be silently altered, because that log is what lets you detect misuse, investigate incidents, and evidence your controls to auditors and regulators.

Cybersecurity assessment checklist

The security assessment should confirm, with evidence rather than assurances, that each platform:

• encrypts data in transit and at rest, with sound key management and, ideally, customer-managed keys;
• holds current, independently audited certifications (SOC 2 Type II, ISO 27001), read in full;
• commissions regular penetration testing and remediates findings on a defined cadence;
• patches vulnerabilities promptly and runs a responsible-disclosure or bug-bounty programme;
• maintains a complete, tamper-evident audit trail of consequential actions, retained appropriately;
• enforces least privilege, separation of duties, and access recertification over time.

Who can do what in the platform is a control question of the first order. In a trading operation, the separation of duties, the principle that no single person can both execute and settle a trade, is a fundamental defence against fraud and error. Identity and access management is how that principle, and many others, is enforced in the platform. This chapter assesses how a platform controls access and whether it can enforce the controls a trading operation requires.

Authentication and single sign-on

Assess how users authenticate. The platform should integrate with your enterprise identity provider through single sign-on, so that access is governed centrally and users do not maintain separate credentials. It should support multi-factor authentication, so that a compromised password is not sufficient to gain access. Ask how the platform handles authentication for both human users and machine identities, the service accounts that integrations use, because machine identities are often the weakest link and the least governed.

Role-based access and least privilege

Assess how the platform defines and enforces what users can do. A mature platform supports fine-grained, role-based access control, so that each user has exactly the access their role requires and no more, the principle of least privilege. Ask how roles are defined, how access is granted and revoked, and how the platform prevents privilege creep over time. The same model should govern API access, so that a service account has only the permissions its integration needs, and cannot exceed them even if compromised.

Separation of duties

Separation of duties deserves specific assessment, because it is a control regulators and auditors examine closely. Can the platform enforce that the person who executes a trade cannot also settle it, that the person who changes reference data cannot also approve the change, that sensitive actions require a second pair of eyes? Ask the platform to demonstrate these controls, not merely to assert them, because the ability to enforce separation of duties in configuration, rather than by hoping people follow a policy, is a real distinction between platforms.

Access governance over time

Access is not granted once; it must be governed over the life of the platform as people join, move, and leave. Assess how the platform supports access review and recertification: can managers periodically review and confirm who has access to what, and is access automatically adjusted as roles change? A platform that makes access governance easy keeps the control effective over time; one that makes it hard sees access decay into a sprawl of accumulated permissions that no one fully understands, which is exactly the condition in which fraud and error hide.

An ETRM outage stops trading. Because the platform sits at the centre of the operation, its unavailability is not an inconvenience but a business-continuity event, and its loss of data would be a catastrophe. Disaster recovery and business continuity therefore deserve specific, rigorous assessment, focused not on the vendor's assurances but on its architecture, its commitments, and its evidence that recovery actually works.

Recovery objectives

Assess the platform's recovery point objective, how much data could be lost in a disaster, and its recovery time objective, how long it would take to restore service. These objectives should match the criticality of a trading system: for a platform at the centre of the operation, both should be short. Ask for the specific commitments, understand what they mean in practice, and confirm they are contractual rather than aspirational. A vendor that cannot state its recovery objectives clearly has not thought hard enough about the failure of a system your business depends on.

Architecture of resilience

Assess how resilience is architected. Is the platform deployed across multiple availability zones or regions, so that the failure of one does not take down the service? How is data replicated, and how quickly can service fail over to a recovery site? A platform whose resilience rests on a single location, however reliable, carries a concentration of risk that a distributed architecture avoids. The architecture determines whether the recovery objectives are achievable, so probe it rather than accepting the objectives at face value.

Testing

The decisive question is whether recovery has been tested. A disaster-recovery plan that has never been exercised is a hypothesis, not a capability. Ask when the vendor last tested failover and recovery, what the results were, and how often testing is repeated. A vendor that tests recovery regularly and can show the results has a capability; one that has a plan but has never exercised it has a document. In a crisis, the difference is everything, because untested recovery procedures fail precisely when they are needed most.

Your own continuity

Disaster recovery is not only the vendor's responsibility. Assess how the platform supports your own business continuity: how you would operate if the platform were unavailable, how you would recover your data if you needed to, and how the platform fits your enterprise continuity plans. For a cloud platform, understand the shared-responsibility model, what the vendor guarantees and what remains yours, so that there are no gaps between the two. Continuity planning that assumes the vendor handles everything, or that you handle everything, leaves gaps that surface only in a real incident.

Artificial intelligence is reshaping trading technology, and buyers rightly want to understand a platform's AI readiness. But the assessment must be clear-headed, distinguishing genuine, well-governed AI capability from marketing, and understanding that the foundation for useful AI is not a clever model but governed data. This chapter sets out how to assess a platform's AI readiness without being dazzled by demonstrations or deterred by hype.

The foundation is governed data

The most important thing to understand about AI in a trading platform is that its value is bounded by the quality and governance of the data beneath it. AI acts on data at scale with reduced human oversight, so bad data produces bad outcomes faster and less visibly. A platform with a governed, lineage-tracked data model is ready for AI; a platform with fragmented, ungoverned data is not, however impressive its AI demonstrations. When assessing AI readiness, therefore, look first at the data foundation assessed in the data-model chapter, because it, more than any AI feature, determines whether AI will help or mislead.

Where AI helps, and where it must not lead

Assess where the platform applies AI and whether it does so appropriately. AI genuinely helps in data operations, matching, classifying, cleaning, in anomaly detection, in forecasting the drivers of prices, and in language tasks like summarising and answering questions over governed data. It must not, however, produce the numbers of record, the prices, risk figures, and regulatory numbers that must be exactly right, fully explainable, and auditable. A mature platform uses AI to assist around these numbers while keeping the numbers themselves on transparent, validated models. Assess whether the platform draws this line correctly, or whether it applies opaque models where explainability is required, which is a warning sign rather than a strength.

Governance and explainability

Assess how the platform governs any AI it uses. Is the AI's behaviour explainable, its outputs auditable, its models validated and monitored for bias and drift? Are consequential actions kept under human control, with the AI assisting rather than deciding? A platform that can answer these questions has thought seriously about AI governance; one that treats AI as a black box has not, and its AI is a liability rather than an asset in a regulated business. Ask specifically how the platform would evidence its AI governance to a regulator, because that question separates serious approaches from superficial ones.

Control of models and data

Finally, assess how much control you retain over the AI. Can you bring your own models, control the credentials, and govern what data the AI sees, or must you surrender your data to an opaque embedded service? Control of the model and the data is what allows the governance that a regulated operation requires, so a platform that keeps you in control is safer than one that does not. AI readiness, properly understood, is less about the sophistication of the models on offer and more about the governance of the data beneath them and the control you retain over both. A platform strong on those fundamentals is ready for AI even if its current AI features are modest; one weak on them is not ready however dazzling its demonstrations.

A trading operation runs on its numbers, and reporting is how those numbers reach the people who need them: traders, risk managers, finance, executives, and regulators. A platform that produces excellent data but makes it hard to report on has solved the wrong half of the problem. This chapter assesses how well a platform turns its governed data into the reports and analytics the business depends on.

Standard reports and self-service

Assess both the standard report library and the ability to create new reports without vendor involvement. A good platform ships with the position, profit-and-loss, risk, and settlement reports every operation needs, and lets users build new reports themselves as requirements evolve. The alternative, where every new report is a change request to the vendor, is slow and expensive, and it turns reporting into a bottleneck. Ask how a new report is created, who can create it, and how long it takes, because the answer determines whether reporting keeps pace with the business or lags behind it.

The analytical layer and consistency

Assess whether analytics run on data that is consistent with the operational record. A well-architected platform provides a governed analytical layer, materialised from the operational model, so that a number in a report matches the same number in the operation. A platform that requires a nightly export to a separate warehouse introduces a lag and a risk that the report and the operation disagree. Ask how the platform keeps analytics consistent with operations, because inconsistency between the two is a common and corrosive problem that undermines trust in every number.

Drill-down and as-of reporting

Two capabilities distinguish serious reporting. The first is drill-down: the ability to move from an aggregate number to the underlying trades, so that a figure can be investigated rather than merely reported. The second is as-of reporting: the ability to reproduce a report as it stood at a past date, essential for audits, disputes, and regulatory examination. Assess both, because their absence turns every investigation into a reconstruction and every historical question into guesswork.

Distribution, access, and regulatory reporting

Assess how reports are scheduled, distributed, and access-controlled, so that the right people receive the right numbers and sensitive data is protected. Assess the platform's support for the regulatory reports your jurisdictions require, and how it keeps pace with regulatory change. And assess how the platform exposes data to external business-intelligence tools, because most organisations want the option to analyse their trading data alongside other enterprise data in tools of their own choosing. Reporting that is powerful but locked inside the platform is less valuable than reporting that can feed the wider enterprise.

Risk analytics is why many organisations buy an ETRM in the first place. The ability to measure, aggregate, and act on risk across the whole book, in something close to real time, is a core capability, and it is one where platforms differ substantially. This chapter assesses a platform's risk analytics beyond the headline claim to compute value-at-risk that every vendor makes.

The measures and their methods

Assess which risk measures the platform computes and how. Value-at-risk can be computed by historical simulation, by parametric methods, or by Monte Carlo, and each has strengths and weaknesses; assess which the platform supports and whether they suit your book. Assess how the platform computes and aggregates the Greeks and sensitivities your desk manages, how it supports stress testing and scenario analysis, and how it handles credit and counterparty risk. The breadth and quality of the risk measures determine how completely the platform can capture your risk, and a platform that computes one measure well but others poorly may leave blind spots.

Risk on the same positions the desk sees

The decisive question in risk analytics is whether the risk numbers are computed on the same positions the desk sees, or on a separate copy that must be reconciled. This is the architecture question again, viewed through the risk lens. When risk runs on the one governed model, the risk number reflects exactly the positions that exist, updated as trades are booked. When risk runs on a separate copy, the risk number can diverge from reality, and the divergence is discovered, if at all, through reconciliation. A platform that computes risk on the live governed position gives risk managers numbers they can trust; one that computes it on a stale copy gives them numbers they must first verify.

Intraday versus end-of-day

Assess whether the platform can produce risk intraday, as positions change, or only in an end-of-day batch. Intraday risk lets a desk see and act on its exposures as they develop, rather than discovering them the next morning. This capability depends on the platform's architecture and compute model: a platform that can revalue and re-risk positions quickly, scaling compute for the task, can offer intraday risk, while one locked in a nightly batch cannot. Assess the compute model behind the risk numbers, because it determines how fresh those numbers can be, and freshness is what lets risk management be proactive rather than retrospective.

Limits, alerts, and governance

Finally, assess how the platform manages limits and controls. Can it define limits at the levels you need, book, desk, commodity, counterparty, entity, monitor exposures against them, and alert and escalate when they are breached? How are the models and market data behind the risk numbers governed and versioned? A platform with strong limit management and governance turns risk analytics from a reporting exercise into an active control; one without it produces numbers that inform but do not protect. The goal is risk analytics that not only measures risk accurately but enforces the limits that keep risk within appetite.

For organisations that trade physical commodities, the platform must do more than value and risk-manage financial positions; it must manage the movement of molecules and megawatts. Physical operations, nomination, scheduling, logistics, balancing, and actualisation, are where a trade becomes a physical delivery, and they are a domain where platforms vary widely. This chapter assesses a platform's physical capabilities for organisations to whom they matter.

Nomination and scheduling

Assess how the platform handles nomination and scheduling for your physical commodities. Gas, power, oil, liquefied natural gas, and their associated logistics each have their own processes, deadlines, and counterparties, and a platform strong in one may be weak in another. Assess the platform against the specific physical commodities and logistics you handle: pipelines, storage, transport, capacity, marine. A platform that covers your physical operations well removes a large operational burden; one that covers them poorly leaves you managing physical delivery in spreadsheets alongside the platform, which is exactly the fragmentation an ETRM is meant to eliminate.

Balancing and actualisation

Physical delivery rarely matches the plan exactly, and the platform must handle the difference. Assess how it manages balancing and imbalance, how it captures actual delivered quantities, and how it reconciles the physical position with the financial one. This actualisation, turning planned deliveries into actuals and feeding them into settlement, is where physical trading meets financial settlement, and a platform that handles it cleanly removes a common source of error and dispute. Assess how actuals are captured, from whom, and how they flow into the invoice, because breaks in this flow are a frequent cause of settlement disputes.

Physical and financial on one model

The recurring architectural theme applies to physical operations too. When physical and financial positions live on the same governed model, they reconcile by construction, and the organisation has one view of its true position. When they live on separate systems, the physical and financial views can diverge, and reconciling them becomes another manual burden. Assess whether the platform manages physical and financial on one model or bridges two, because the answer determines whether your physical and financial positions naturally agree or must be forced to agree.

Quality, measurement, and loss

Physical commodities have quality specifications and are measured, sometimes more than once, and the differences matter commercially. Assess how the platform handles quality specifications, measurement and its tolerances, and the allocation of losses in transit. These details are where physical disputes arise, as the dispute-resolution material discusses, and a platform that captures them precisely, as governed data rather than as free text, both reduces disputes and strengthens your position when they occur. For a physically-heavy operation, the depth of these capabilities is a major differentiator that a financially-focused evaluation would miss entirely.

The back office, settlement, invoicing, accounting, and cash management, is where a trade completes its life and where the organisation actually collects or pays the money a deal represents. Financial operations are less glamorous than trading and risk, but errors here have direct financial consequences, and a platform's back-office capabilities deserve as careful an assessment as its front-office ones. This chapter assesses how well a platform handles the financial completion of the trade lifecycle.

Settlement and invoicing

Assess how the platform generates invoices, matches them with counterparties, and handles the disputes and adjustments that inevitably arise. Settlement is document-intensive and detail-sensitive: an invoice must reflect the correct quantity, price, quality adjustments, and charges, and it must reconcile to the trade and the actuals. A platform that generates settlement cleanly from the governed trade record, with a clear audit trail back to the trade, removes a large manual burden and a common source of error and dispute. Assess how settlement traces to the trade, because that traceability is what lets you resolve invoice disputes quickly and evidence your position.

Accounting and the general ledger

Assess how the platform integrates with accounting and the general ledger. The trading activity must be reflected accurately in the financial accounts, and the interface between the ETRM and the accounting system is where that happens. Assess how the platform produces accounting entries, how it handles multiple accounting standards if you report under more than one, and how cleanly it integrates with your general ledger. A weak accounting interface pushes reconciliation work onto finance and creates a risk that the trading records and the financial accounts disagree, which is precisely the kind of divergence that auditors and regulators probe.

Netting, collateral, and cash

Assess the platform's support for netting, so that offsetting obligations with the same counterparty settle as a single net amount; for collateral and margin management, so that credit exposure is secured; and for cash management and payment generation, so that the money actually moves. These capabilities matter more for some operations than others, but where they matter, their absence is keenly felt. Assess them against your specific needs, because a platform strong in front-office analytics but weak in these back-office mechanics may leave you managing collateral and payments outside the system.

Auditability of the financial record

Because financial operations produce the numbers that reach the accounts and the regulators, their auditability is paramount. Assess how the platform makes settlement and accounting traceable to the underlying trades, how it records adjustments and corrections, and how it evidences the controls around financial processing. As with the rest of the platform, a governed, auditable record is both an operational asset and a defence in an audit or dispute, and financial operations are where that record most directly meets the money.

Commodity trading is heavily regulated, and the regulatory burden is rising. A platform must help the organisation meet its obligations, trade and transaction reporting, position limits, surveillance, record retention, reliably and efficiently, and must keep pace as the rules change. This chapter assesses a platform's regulatory and compliance capabilities against the obligations your jurisdictions impose.

Reporting obligations

Assess how the platform supports the trade and transaction reporting your regimes require, whether EMIR, REMIT, Dodd-Frank, MiFID, or others relevant to your markets. Regulatory reporting is detailed and unforgiving: reports must be accurate, complete, and timely, and errors carry penalties. A platform that generates regulatory reports from the governed trade record, with the lineage to evidence them, removes a large burden and reduces the risk of a reporting failure. Assess which regimes the platform supports out of the box, and how it handles the deduplication and reconciliation that cross-border reporting requires.

Position limits and surveillance

Assess how the platform supports position-limit monitoring and large-trader reporting where these apply, and how it supports surveillance for market abuse. These are controls the platform should help enforce, not merely report on after the fact. A platform that monitors limits and flags suspicious activity in something close to real time is a stronger compliance partner than one that produces reports the next day, because compliance, like risk, is more valuable when it is proactive than when it is retrospective.

Auditability and examination readiness

Regulators examine, and when they do, the organisation must be able to evidence its controls and reconstruct its activity. Assess how the platform supports examination: can it reproduce a past state, trace a number to its inputs, and evidence who did what and when? This is where the governed, bitemporal, lineage-tracked record discussed throughout this handbook proves its regulatory worth, turning an examination from a fire drill into a query. A platform that makes examination easy is worth a great deal to a compliance function that would otherwise spend weeks reconstructing history from fragments.

Keeping pace with change

Regulation changes constantly, and a platform must keep pace. Assess how the vendor tracks regulatory change and delivers updates, so that new obligations are supported without a bespoke project each time. A vendor with a mature process for regulatory change, and a track record of delivering it, spares the organisation the recurring cost and risk of adapting to new rules alone. Assess this process, because over a decade the regulatory landscape will shift substantially, and a platform that adapts with it is far more valuable than one that must be re-engineered for each new requirement.

Master data, the commodities, counterparties, calendars, curves, and hierarchies against which every trade is captured and valued, is the reference framework of the whole operation. When it is well governed, everything built on it is consistent; when it is fragmented or wrong, errors propagate everywhere. This chapter assesses how a platform manages master data, a capability easy to overlook and expensive to lack.

Golden sources and governance

Assess whether the platform establishes a single golden source for each master-data domain, or whether reference data is duplicated and must be kept in sync. A golden source, one authoritative version of each commodity, counterparty, and calendar, governed and controlled, is the foundation of data consistency. Assess how changes to master data are approved and propagated, so that a change is made once and reflected everywhere, and how the platform prevents the uncontrolled proliferation of reference data that undermines consistency. Master data that is governed at a single source is a quiet but powerful advantage; master data scattered across modules is a quiet but persistent source of error.

Effective dating and history

Master data changes over time, and the platform must handle those changes without corrupting history. Assess whether the platform supports effective-dated reference data, so that a trade is valued against the reference data that was correct at its time, not the current version. This effective dating is what lets historical valuations reproduce correctly, and its absence is a subtle but serious flaw that surfaces in audits and disputes when a past number cannot be reproduced because the reference data behind it has been overwritten.

Hierarchies and cross-references

Assess how the platform handles the hierarchies, legal entity, book, desk, portfolio, that structure the operation, and the cross-references that map internal identifiers to external ones. These structures are how the organisation aggregates and slices its data, for risk, for reporting, for regulation, and a platform that handles them flexibly supports the organisation's structure as it evolves. A platform with rigid hierarchies forces the organisation to fit the system rather than the system fitting the organisation, and reorganisations become system projects.

Data quality

Finally, assess how the platform supports data quality: how it detects duplicates, conflicts, and errors in master data, and how it helps resolve them. Master-data quality problems are insidious because they propagate silently into every trade and valuation that references the bad data. A platform with data-quality dashboards, exception management, and stewardship support helps keep master data clean over time; one without leaves quality to erode until the errors become visible in the numbers, by which point they have already done their damage. Master-data management is unglamorous, but it is foundational, and a platform that does it well pays dividends across every other capability.

Data migration is the most underestimated and most frequently troubled part of an ETRM implementation. Moving trades, positions, reference data, and history from the old world to the new is harder than it looks, because the old data is rarely as clean, complete, or consistent as anyone assumes. A migration planned carelessly derails implementations; a migration planned carefully de-risks them. This chapter sets out how to approach migration as a strategy rather than a last-minute scramble.

Understand the source data honestly

The migration begins with an honest assessment of the source data, building on the current-state assessment. How clean is it? How complete? How consistent across the systems it lives in? Almost always, the answer is worse than expected, because data quality problems that are tolerable in daily operation become blocking problems when the data must be migrated. Discovering the true state of the source data early, rather than during the migration itself, is the single most important thing a migration strategy can do, because it turns a nasty surprise into a planned workstream.

Decide what to migrate

Not everything must move. Decide deliberately what to migrate: open trades certainly, but how much history? Reference data, but in what form? The temptation is to migrate everything, but migrating bad or irrelevant data is costly and pointless. A clear scope, driven by what the new operation actually needs and what regulation requires you to retain, keeps the migration focused. Sometimes the right answer is to migrate the essential data into the new platform and retain the rest in an accessible archive, rather than forcing everything through a migration that its quality cannot support.

Cleanse, transform, and validate

Migration is not a copy; it is a cleanse, a transformation, and a validation. The source data must be cleaned of the errors that daily operation tolerated, transformed into the new platform's model, and validated to confirm it arrived correctly. Each of these steps takes effort, and each must be planned and resourced. Validation deserves particular emphasis: the migration is not done when the data has moved but when it has been proven correct in the new platform, through reconciliation against the source and testing against known results. A migration declared complete without rigorous validation is a migration whose errors will surface in production, at the worst possible time.

Plan and rehearse the cutover

The cutover, the moment the organisation switches from the old platform to the new, is a high-risk event that must be planned and rehearsed. A common and prudent approach is a parallel run, operating both platforms together for a period and reconciling their outputs, so that discrepancies are found and resolved before the old platform is retired. The migration strategy should define the cutover approach, the parallel-run period, the reconciliation that will confirm the new platform is correct, and the fallback if something goes wrong. The migration workbook that accompanies this handbook provides a structure for planning and tracking this work. Migration handled as a deliberate, rehearsed strategy is a controlled step; migration handled as an afterthought is where implementations go to fail.

Data migration checklist

A sound migration strategy should have, before cutover:

• an honest assessment of source-data quality, completeness, and consistency, done early;
• a deliberate decision on what to migrate versus archive, driven by need and regulation;
• a defined cleanse, transform, and validate process, with validation proving correctness in the new platform;
• a rehearsed cutover plan, ideally including a parallel run with reconciliation against the source;
• a defined fallback if the cutover encounters problems it cannot resolve in the window.

A good platform poorly implemented delivers a bad outcome. The implementation, how the chosen platform is configured, integrated, migrated, tested, and brought into production, determines whether the selection's promise is realised. This chapter sets out the elements of a sound implementation methodology, so that the buyer can assess a vendor's approach and plan the implementation before signing rather than discovering it afterwards.

Configuration over customization

A central choice in any implementation is how much to configure and how much to customise. Configuration, adapting the platform through its supported settings, is fast, low-risk, and survives upgrades. Customization, modifying the platform's code or building bespoke extensions, is slow, risky, and becomes a maintenance burden that complicates every future upgrade. A sound methodology favours configuration and treats customization as a last resort, and a platform that requires heavy customization to meet common requirements is telling you something about its fit. Assess how much of your requirements the platform meets by configuration versus customization, because the answer predicts both the implementation risk and the long-term maintenance burden.

Phasing and scope discipline

Assess how the vendor phases an implementation and how it controls scope. A disciplined implementation delivers in managed phases, each with clear scope, rather than attempting everything at once. Scope discipline is critical: the most common cause of overrun is scope creep, the steady accumulation of just one more requirement that turns a bounded project into an open-ended one. A methodology with strong scope governance, and a vendor with the discipline to hold the line, is worth a great deal, because it is the difference between a project that lands and one that drifts.

Testing and parallel running

Assess the testing approach. A sound implementation tests thoroughly at every level, unit, integration, user acceptance, and validates the whole through a parallel run before go-live. Testing is where problems are found cheaply, before production, rather than expensively, after. A methodology that compresses or skips testing to hit a date is trading a visible short-term saving for a hidden long-term cost, because the problems testing would have found do not disappear; they surface in production, where they cost far more to fix and damage trust in the platform.

Go-live and hypercare

Assess how the vendor supports go-live and the critical period immediately after. Go-live should be a controlled, rehearsed event with a clear plan and a fallback, not a leap of faith. The period after go-live, often called hypercare, is when the new platform meets the full reality of daily operation, and intensive support during this period resolves the inevitable early issues before they undermine confidence. Assess the vendor's go-live and hypercare model, because a strong one turns the riskiest moment of the whole programme into a managed transition, while a weak one leaves the organisation exposed exactly when it is most vulnerable.

Implementation readiness checklist

Before committing to go-live, confirm that:

• the configuration meets requirements without heavy customization, and customizations are documented;
• scope has held, with a governed process for any change and no unmanaged accumulation;
• testing has covered unit, integration, and user acceptance, and a parallel run has validated the whole;
• users are trained and ready, so the platform will be adopted and not merely technically live;
• the go-live plan is rehearsed, with a fallback, and a hypercare model is in place for the period after.

You are not only buying a platform; you are entering a decade-long relationship with a vendor. The vendor's stability, competence, and culture will shape your experience as much as the platform's features. Vendor due diligence is the assessment of the company behind the product, and it is where buyers who focus only on the software expose themselves to risks that have nothing to do with the code.

Financial stability and longevity

Assess the vendor's financial health and longevity. A platform at the centre of your operation is a bet that the vendor will be there, and improving the product, for the life of the platform. Assess the vendor's financial stability, its ownership, its profitability or funding, and its trajectory. Consider what happens if the vendor is acquired, and what protections exist for you if it is. A financially fragile vendor is a risk regardless of how good its product is today, because a vendor that fails or is absorbed can leave you stranded on a platform that stops improving.

References and track record

Assess the vendor's track record through references, ideally from organisations of similar size, commodity mix, and geography. Speak to reference clients directly, and ask not only whether they are satisfied but about the implementation, the support, the upgrades, and the problems and how the vendor handled them. Ask about the vendor's on-time, on-budget delivery record, its client tenure and churn, and any material incidents, breaches, or outages. References reveal what demonstrations conceal: how the vendor behaves over the long run, in good times and bad, which is what you are really buying.

Product investment and roadmap

Assess how much the vendor invests in the product and how it governs its roadmap. A vendor reinvesting substantially in research and development is more likely to keep the platform current; one coasting on a mature product may let it fall behind. Assess how clients influence the roadmap, because a vendor that listens to its clients is more likely to build what you will need. The roadmap is a window into the vendor's priorities and its view of where the market is going, and alignment between its direction and yours matters over a decade.

Support, services, and continuity

Assess the vendor's support model, its professional-services capacity, and its continuity protections. How does support work, through what channels, with what response times, and how does escalation function when something serious goes wrong? Does the vendor have the services capacity to implement and support you well, or will you compete for scarce resources? What continuity protections, such as source-code escrow, exist if the vendor cannot continue? These questions assess whether the vendor can support the relationship you are entering, not just sell you the product at its start. Due diligence on the vendor is as important as evaluation of the platform, because the best software from a failing or unresponsive vendor is a poor long-term bet.

The commercial negotiation determines what you pay and on what terms, and it is where a well-run process converts its diligence into leverage. Negotiation is not about squeezing the lowest possible price; it is about securing fair terms, aligning incentives, and protecting the organisation over the life of the relationship. This chapter sets out how to negotiate from a position of knowledge rather than hope.

Negotiate from the total cost of ownership

Negotiate against the total cost of ownership, not the headline licence price. A low first-year price can hide a high total cost through escalation, add-on charges, expensive change, and costly support. The total cost of ownership model that accompanies this handbook lets you see the whole cost over five and ten years, and negotiate the terms that drive it: the escalation rate, the cost of adding users and commodities, the support terms, the cost of change. A negotiation focused on the headline price while ignoring these drivers can win a cheap first year and a expensive decade, which is a poor trade.

Align incentives

The best commercial terms align the vendor's incentives with your success. Payment milestones tied to implementation progress align the vendor with delivery. Service-level agreements with meaningful remedies align the vendor with reliability. Terms that make the vendor share in the risk of a troubled implementation, rather than being paid in full regardless of outcome, focus the vendor's attention. Assess where incentives can be aligned, because aligned incentives protect you far more reliably than penalties you would have to enforce after the fact.

Protect the exit

Negotiate the exit at the start, when you have leverage, not at the end, when you do not. What are the terms for exporting your data if you leave? What transition assistance is provided? Are there exit fees? A platform holds your data and your operation, and the ease or difficulty of leaving is a real cost that should be negotiated up front. A vendor confident in its product will offer reasonable exit terms; reluctance to do so is itself informative. Protecting the exit is not a sign of expecting failure; it is a sign of prudence, and it preserves your freedom over the life of the relationship.

Use leverage while you have it

Your leverage is highest before you sign, when you have alternatives and the vendor wants the deal. Use it then to secure the terms that matter: price and escalation, the cost of growth and change, support and service levels, exit protections, and the commitments on implementation and roadmap that de-risk the relationship. Once you have signed and implemented, switching becomes expensive, and your leverage falls accordingly. A disciplined negotiation, informed by the diligence and the cost model this handbook has helped you build, converts the effort of the whole selection into terms that will serve you for a decade.

Negotiation checklist

Before signing, confirm you have negotiated:

• price and escalation against the total cost of ownership, not the headline licence;
• the cost of growth and change: adding users, commodities, products, and reports over time;
• support and service levels with meaningful remedies, and payment milestones tied to delivery;
• exit terms: data export, transition assistance, and any exit fees, secured while you have leverage;
• commitments on implementation and roadmap that align the vendor with your success.

The total cost of ownership is what the platform truly costs over its whole life, and it is almost always far more than the licence or subscription price that dominates the initial conversation. A rigorous total cost of ownership model is essential to both the business case and the negotiation, and this handbook provides one as a working tool. This chapter explains what the model captures and how to use it well.

The cost categories

A complete total cost of ownership captures every category of cost over the model horizon, typically five and ten years. Licensing or subscription, with its escalation over time. Infrastructure, whether cloud hosting or on-premises hardware and its refresh cycles. Implementation, including the vendor's services, your internal team, and data migration. Integration, both the one-time build and the ongoing maintenance. Operations and support, including vendor support and the internal staff who run the platform. Change, the cost of adding commodities, products, and reports over time. And the cost of risk, the expected cost of reconciliation, errors, and downtime. Omitting any category understates the true cost, and the categories most often omitted, internal effort, change, and the cost of risk, are precisely the ones where a modern platform most differs from a legacy one.

Cloud versus legacy in the model

The total cost of ownership model that accompanies this handbook compares a cloud-native option against a legacy one across all these categories, and the comparison is illuminating. A legacy platform often shows a lower headline licence but a higher total cost, once its hardware, its larger support team, its expensive change, its big-bang upgrades, and its higher cost of risk are counted. A cloud-native platform often shows a higher subscription but a lower total cost, because it removes the hardware, runs with a smaller team, absorbs change through configuration, upgrades continuously, and reconciles by construction. The model makes these trade-offs explicit, so the decision rests on the whole cost rather than the visible fraction of it.

Discounting to present value

Costs incurred in different years are not directly comparable; a cost next year is worth more than the same cost in year ten. The total cost of ownership model discounts future costs to their present value using your discount rate, so that the comparison reflects the time value of money. This matters particularly when comparing options with different cost profiles, a legacy option with high upfront capital and a cloud option with level subscription, because discounting changes the balance between upfront and ongoing costs. Use your organisation's hurdle rate, and present both the undiscounted total and the net present value, because different audiences find different views persuasive.

Using the model honestly

The total cost of ownership model is only as good as its inputs. Populate it with real figures from the vendors' proposals and your own cost data, not placeholders, and be complete rather than optimistic. The temptation is to understate the costs of the preferred option, but a model that flatters a favoured platform misleads the very decision it is meant to inform. Used honestly, the model is one of the most powerful instruments in the whole selection, grounding the business case, informing the negotiation, and giving the board a clear, defensible view of what each option truly costs over its life.

A worked illustration

To make the total cost of ownership concrete, consider a mid-sized operation of sixty-five seats trading four commodities, comparing a cloud-native option against a legacy one over ten years. The figures below are illustrative and match the default profile in the downloadable calculator; replace them with your own before relying on any conclusion. What the illustration shows is not a specific number but a pattern: the legacy option carries a lower headline subscription but a higher total cost once hardware, a larger support team, expensive change, and the cost of risk are counted.

The lesson of the illustration is the lesson of the chapter: the licence is a fraction of the total, and the areas where a modern platform saves, operations, change, and the cost of risk, are precisely the areas a headline-price comparison ignores. The calculator lets you build this table for your own operation, with your own figures, and see where the balance falls for you.

The total cost of ownership tells you what a platform costs; the return on investment tells you whether it is worth it. The return on investment model weighs the quantified benefits from the business case against the costs from the total cost of ownership model, producing the net present value and payback period that a board uses to decide. This chapter explains how to build a credible return on investment case.

Quantify the benefits conservatively

The benefits, drawn from the business case, fall into the categories discussed earlier: efficiency, risk-reduction, agility, and compliance. Quantify each as concretely as the evidence allows, and err toward conservatism. Efficiency benefits, the removal of manual effort, are the most quantifiable and the most believable. Risk-reduction benefits, fewer and smaller errors, are larger but harder to quantify; use probability-weighted estimates and be transparent about the assumptions. Agility benefits, the value of faster change, are the hardest to quantify but often the most strategically significant; where they cannot be quantified confidently, describe them qualitatively rather than inventing a spurious number. A benefits case built on conservative, well-evidenced figures earns trust; one built on optimistic assertions invites skepticism.

Weigh benefits against total cost

The return on investment is the relationship between the benefits and the total cost of ownership over the model horizon. Bring the two together: the year-by-year costs from the total cost of ownership model and the year-by-year benefits from the business case, discounted to present value, producing a net present value and a payback period. The net present value shows whether the investment creates value over its life; the payback period shows how quickly the investment is recovered. Both matter to a board, which weighs not only whether an investment pays off but how soon and how certainly.

Test the sensitivity

A single return on investment number invites false precision. Test the sensitivity of the result to the key assumptions: what if the benefits are half what you expect, or the costs a third higher, or the implementation takes longer? A return on investment that remains positive across a range of pessimistic assumptions is robust and defensible; one that turns negative under mild pessimism is fragile and should be presented as such. Showing the sensitivity, rather than a single point estimate, demonstrates rigour and builds the board's confidence that the case has been stress-tested rather than merely asserted.

Frame the return against the alternative

As with the business case, frame the return against the alternative of doing nothing. The do-nothing option has no implementation cost but carries the ongoing cost of the current state and forgoes all the benefits, and over time it carries the rising cost of a platform falling further behind. A return on investment case that makes the cost of inaction explicit, alongside the return on action, gives the board the full picture: not just what the investment costs and returns, but what standing still costs too. That framing is often what turns a sound case into a compelling one.

A worked return illustration

Extending the same example, suppose the operation quantifies annual benefits conservatively: efficiency savings from removing manual reconciliation and re-keying, risk-reduction from fewer and smaller errors, and agility from faster change. Weighed against the total cost of ownership and discounted to present value, these benefits produce a net present value and a payback period. The point of the exercise is not the specific numbers but the discipline: benefits quantified conservatively, costs counted completely, both discounted, and the result stress-tested against pessimistic assumptions. A return that survives that stress test is one a board can approve with confidence.

Present the return three ways, because different board members find different framings persuasive: as a net present value (does it create value over its life), as a payback period (how soon is the investment recovered), and as a comparison against doing nothing (what does inaction cost). The three together give a complete picture that a single headline number cannot.

The request for proposal is how you ask the market to demonstrate its fit to your needs, and its quality determines the quality of the responses you receive. A vague request produces vague, incomparable answers; a structured, specific request produces answers you can evaluate side by side. This handbook provides a request-for-proposal question bank of more than three hundred questions as a working tool, and this chapter explains how to use it well.

Structure for comparability

The purpose of an RFP is to produce comparable responses, so structure it for comparison. The question bank is organised into categories, company and commercial, the functional domains, the technical and security domains, implementation and support, so that responses can be evaluated domain by domain and scored consistently. Ask vendors to answer in a structured form, indicating for each requirement whether it is met fully, partially, by roadmap, or not at all, with explanation. This structure turns a pile of prose into a dataset you can analyse, which is what a serious evaluation requires.

Prioritise the questions

Not every question matters equally, and the question bank marks each with a priority, must, should, or could, that you should adjust to your context. Prioritisation serves two purposes: it tells vendors what matters most, focusing their responses, and it lets you weight the evaluation toward the requirements that are decisive for you. Set the priorities deliberately, informed by the future operating model and the current-state assessment, so that the RFP measures fit to what matters rather than treating every requirement as equal.

Tailor to your operation

The question bank is comprehensive and vendor-neutral, but it is a starting point, not a finished RFP. Tailor it: remove questions that do not apply to your operation, add questions specific to your commodities, markets, and constraints, and adjust the priorities to your context. A physically-heavy operation deepens the physical operations questions; a heavily-regulated one deepens the compliance questions. The tailoring is where your knowledge of your own operation enters the process, and it is what turns a generic template into an RFP that discriminates between platforms on the dimensions that matter to you.

Run the process fairly and rigorously

Finally, run the RFP process fairly and rigorously. Give every vendor the same information and the same opportunity, evaluate responses against the scorecard rather than impressions, and document the evaluation so that the decision can be defended. A fair, rigorous process produces a better decision and a defensible one, which matters when a multi-million-dollar choice is scrutinised by a board, a procurement function, or, if it goes wrong, an inquiry. The RFP question bank, used with the weighted scorecard, gives you the instruments to run such a process; the discipline to run it fairly is yours to supply.

The weighted scorecard is where the whole evaluation comes together into a decision. It takes the responses from the RFP, the findings from the evaluation chapters, and the priorities from your operating model, and combines them into a weighted score that ranks the platforms on fit to your needs. This handbook provides the scorecard as a working tool, and this chapter explains how to use it to reach a decision that is both sound and defensible.

Set the weights before you see the scores

The single most important discipline in using a weighted scorecard is to set the weights before you see the scores. The weights encode your priorities, how much each category matters to your operation, and they should reflect genuine business priority, not a justification of a preferred outcome. Setting them first, with the front office, risk, operations, and finance in the room, ensures the weighting is honest. Setting them after the scores are in invites the temptation to tune the weights until the preferred platform wins, which corrupts the whole exercise. The scorecard enforces this discipline by separating the weights, which you set once, from the scores, which you enter per vendor.

Score consistently against evidence

Score each platform on each criterion against evidence, the RFP responses, the demonstrations, the references, the findings of the evaluation, not against impression. Use a consistent scale, and apply it consistently across vendors, so that a score of four means the same thing for every platform. Where possible, have more than one evaluator score independently and reconcile differences, so that the scores reflect collective judgement rather than one person's view. Consistent, evidence-based scoring is what makes the resulting ranking meaningful; inconsistent or impressionistic scoring produces a number that looks rigorous but is not.

Read the result critically

The scorecard produces a weighted total for each platform, but the number is an input to the decision, not the decision itself. Read the result critically. Is the ranking robust, or does it depend on a few close scores that could easily go the other way? Do the category scores reveal a platform that is strong overall but weak in an area that is critical to you? A platform that wins on the total but fails a must-have requirement is not the right choice, whatever the weighted score says. Use the scorecard to structure and inform the judgement, not to replace it, and pay attention to the pattern of scores, not just the total.

Document the decision

Finally, use the scorecard to document the decision. The completed scorecard, with its weights, its scores, and its rationale, is the record of how the decision was reached, and it is what lets you defend the decision to a board, a procurement function, or, if necessary, an audit. A decision documented this way is transparent and defensible; a decision reached by impression and asserted without evidence is neither. The scorecard is thus both a tool for reaching the decision and a record of having reached it well, and both roles matter when the choice is large and scrutinised.

An illustrative weighting

The weights you assign to each category are the most consequential choice in the scorecard, and they should reflect your operation. The illustrative weighting below, which matches the default in the downloadable scorecard, suits a balanced operation trading both physical and financial commodities; a purely financial desk would lower the physical weight and raise valuation and risk, while a physically-heavy operation would do the reverse. Use it as a starting point, not a prescription.

Whatever weights you choose, set them before you see the scores, agree them across the front office, risk, operations, and finance, and confirm they sum to a hundred per cent. The scorecard enforces the sum-to-100 check; the discipline of setting them first is yours to keep.

A selection is not complete until it is approved, and approval requires communicating the recommendation to the executives and the board who must sanction the investment. The executive presentation translates the depth of the selection into the concise, decision-focused form that a steering committee needs. This chapter sets out how to present the recommendation so that it is understood, trusted, and approved.

Lead with the recommendation and the case

Executives are busy and decision-focused, so lead with the recommendation and the case for it, not the journey that produced it. State clearly what you recommend, why, what it will cost, what it will return, and what the risks are and how they will be managed. The depth of the selection, the evaluation, the scorecard, the diligence, is the evidence behind the recommendation, available to support it, but the presentation should lead with the conclusion and marshal the evidence in support, not bury the conclusion under the process. A board wants to know what you recommend and why it should agree, quickly and clearly.

Make the financial case clearly

The financial case, the total cost of ownership, the return on investment, the comparison against alternatives including doing nothing, is central to the executive decision, so present it clearly and honestly. Show the whole cost over five and ten years, the expected return and payback, and the sensitivity to key assumptions. Present the cost of inaction alongside the cost of action, so the board sees that standing still is not free. A clear, honest financial case, presented with confidence and without overreach, is what gives a board the assurance to approve a large investment.

Address the risks head-on

Boards approve investments more readily when they trust that the risks have been thought through, so address the risks head-on rather than hoping they will not be raised. Name the principal risks, implementation, migration, adoption, vendor, and show how each will be managed. The implementation risk register, discussed in the appendices, is the source for this. A recommendation that acknowledges its risks and shows them managed is more credible than one that presents only upside, because a board knows that no investment of this size is without risk, and a case that pretends otherwise invites doubt about everything else in it.

Tailor to the audience

Finally, tailor the presentation to the audience. A technical steering committee wants more architectural detail; a board wants more financial and strategic framing. The executive presentation pack that accompanies this handbook provides a structure that can be tailored to each audience, leading with the recommendation and the case, supported by the financial analysis, the evaluation summary, and the risk management. Present the selection as what it is: a rigorous, evidence-based recommendation that the organisation can approve with confidence, having done the work to earn that confidence.

This final chapter gathers the reference material that supports the selection: a glossary of the terms used throughout, the checklists that condense each chapter into actionable form, an implementation risk register, and the lessons learned from ETRM implementations that went wrong. These appendices are meant to be used directly, as the working reference behind the process the handbook describes.

The implementation risk register

Every implementation carries risks, and the ones that fail usually fail for reasons that were foreseeable. A risk register names the principal risks, assesses their likelihood and impact, and assigns each a mitigation and an owner. The principal risks in an ETRM implementation are consistent: underestimated data migration, scope creep, insufficient testing, weak user adoption, integration complexity, vendor underperformance, and loss of key people. Naming these risks at the start, and managing them actively throughout, is what distinguishes implementations that land from those that drift. The risk register is a living document, reviewed at every programme gate, not a one-time exercise filed and forgotten.

Lessons from failed implementations

ETRM implementations fail in recognisable ways, and learning from those failures is cheaper than repeating them. The common causes are worth naming plainly. Choosing a platform against today's needs rather than tomorrow's operating model, so the platform is outgrown before it is paid off. Underestimating the data migration, so the programme stalls when the true state of the source data emerges. Allowing scope to creep, so a bounded project becomes open-ended. Skimping on testing to hit a date, so the problems surface in production. Neglecting user adoption, so the platform is technically live but practically unused. And treating the vendor relationship as a transaction rather than a partnership, so problems become disputes rather than joint problems to solve. Each of these failures is avoidable, and each is avoided by the disciplines this handbook describes.

The chapter checklists

Each chapter of this handbook condenses into a checklist of the questions to ask and the things to confirm, and the appendices gather those checklists into a single working reference. Used together, they form a step-by-step guide to running the selection: frame the decision, assess the current and future state, evaluate across every dimension, perform due diligence, model the cost and return, negotiate, and plan the implementation. The checklists are the operational distillation of the handbook, the form in which its guidance is actually applied to a live selection.

Using the handbook and its tools together

The handbook and its downloadable tools, the total cost of ownership calculator, the request-for-proposal question bank, and the weighted vendor scorecard, are designed to be used together. The prose explains the thinking; the tools let you execute it. Together they turn ETRM selection from an intuitive, impression-driven exercise into a rigorous, evidence-based process, one that produces a better decision and a decision the organisation can defend. That is the aim of this handbook: not to tell you which platform to buy, but to equip you to choose well, and to know that you have chosen well. A decision of this size and duration deserves nothing less than the disciplined, comprehensive process this handbook sets out, and the organisations that apply it are the ones that look back on their ETRM selection a decade later as a foundation they built on rather than a constraint they worked around.

The principal implementation risks

Review this register at every programme gate, updating the likelihood and impact as the programme proceeds and confirming each mitigation is being acted on. A risk register that lives is a control; one that is filed after the kick-off is a formality. The implementations that succeed are those that treat these risks as active concerns to be managed throughout, not boxes to be ticked at the start.