Change management for financial services: a 3-level governance model
On 1 July 2025, APRA’s Prudential Standard CPS 230 came into force, and with it, a requirement most financial services change functions still have not absorbed: boards must now oversee operational risk arising from their own institution’s change activity, as a standing governance responsibility, not a project-level concern raised only when something has already gone wrong. It is one of the first times a regulator has said explicitly, in a binding prudential standard, that a poorly sequenced portfolio of change is a board-level risk in its own right, and it is one instance of a pattern now playing out in board rooms well beyond Australia, from London to Toronto to Singapore.
CPS 230 did not invent this problem. It named it. And it forces a question most financial services change functions have never had to answer cleanly: at which level of the organisation, exactly, is the volume and sequencing of change actually governed, and does the board see the performance and benefit impact of that portfolio, or only a status summary of individual projects.
Most change management for financial services content treats regulatory pressure as one more generic source of “change volume” to manage. It is not generic. It is a structural governance question that plays out differently at three distinct levels, the frontline teams absorbing change day to day, the business unit coordinating it across them, and the enterprise and board reviewing what it is doing to performance and value. This article sets out a working governance model across those three levels, and shows why regulators well beyond Australia are now converging on the same demand.
Why this is now a board-level governance question
CPS 230 is not an isolated Australian requirement. Over the past three years, financial services regulators across several major markets have independently converged on treating change-related operational risk as a governance obligation, not a delivery detail. A few examples make the pattern clear.
- Australia: alongside CPS 230’s operational risk requirement, the Financial Accountability Regime requires banks (from March 2024) and insurers and superannuation trustees (from March 2025) to name accountable persons against specific responsibilities, backed by formal accountability statements.
- The United Kingdom: in April 2023, the Bank of England’s Prudential Regulation Authority personally fined TSB Bank’s former Chief Information Officer for breaching the PRA’s Senior Manager Conduct Rules, following a 2018 core banking migration that locked out 5.2 million customers and eventually cost the bank £48.65 million in combined FCA and PRA fines. The regulators were explicit that the failure was not the migration itself, migrations fail regularly, but that no one had both the authority and the full picture needed to stop it going ahead once the warning signs were there.
- Canada: the Office of the Superintendent of Financial Institutions’ Guideline E-21, finalised in August 2024, explicitly lists change management alongside business continuity and crisis management as a named component of operational risk and resilience that federally regulated institutions must govern.
- Singapore: the Monetary Authority of Singapore’s Guidelines on Individual Accountability and Conduct require financial institutions to clearly identify the senior managers responsible for each core function and hold them accountable for the conduct of the business under their purview.
- The European Union: the Digital Operational Resilience Act, in force since January 2025 across roughly 22,000 financial entities, ties ICT and change-related operational resilience directly to internal governance obligations, with penalties reaching €1 million for individual senior managers.
None of these regimes were written with change management in mind specifically. All of them arrive at the same practical requirement: a financial services change portfolio needs real governance at every level where a decision about sequencing, capacity or risk actually gets made, not a single dashboard the board glances at once a quarter. If you already have a strong grip on the different categories of transformation running through your organisation, our companion piece on the eight core types of financial services transformation is the right place to map what is actually in your portfolio before applying the governance model below.
A governance model for change portfolios: operations, business unit, enterprise
Most financial services change functions have governance on paper, a steering committee here, a change advisory board there, but it rarely maps cleanly onto the three levels where decisions about change risk and value actually get made. Here is a model that does, built around a single artefact each level contributes to and draws from: a risk-in-change register, a live record of what change is landing where, how much capacity it is consuming, and what operational, consumer-outcome or performance risk it is creating, that exists as one shared view rather than three disconnected reporting lines.
Operations level: the source of real signal
The operations level, claims processing teams, contact centre agents, branch tellers, loan servicing staff, is where change load is actually experienced, not where it is reported from a spreadsheet. This is the frontline delivering the customer interaction every disclosure and prudential regime ultimately cares about. This level should surface three specific things upward:
- Real capacity data, not estimated capacity. How many hours per week is this team realistically able to absorb in new process, system or product change, given its existing operational workload, not a generic FTE assumption inherited from a project template.
- Early psychosocial and readiness signals. Frontline supervisors are the first people to see when concentrated change load is producing disengagement, error rates, or attrition risk, well before it shows up in a portfolio dashboard.
- First-hand evidence from the customer interaction itself. Where a change affects a customer-facing product or process, frontline staff are the ones who can confirm whether customers actually understand what changed, not just whether a disclosure document was technically issued.
The failure mode at this level is not incompetence. It is that most portfolio governance never asks operations teams for this information in a structured, recurring way, so it only surfaces informally, if at all, until it becomes an incident.
Business unit level: the sequencing function
This is the divisional or business-unit layer, retail banking, claims, wealth advice, coordinating operations teams underneath it, and it is the level TSB’s case shows was structurally missing: someone with a live, cross-initiative view who can see that two individually “green” projects are about to land on the same operations team in the same fortnight, one driven by a hard regulatory deadline and one entirely discretionary.
This level should own:
- Cross-referencing regulatory deadlines against operational capacity data, not managing regulatory and discretionary change as separate, uncoordinated streams reporting into different committees.
- The sequencing and trade-off recommendation, deciding, with evidence, which discretionary initiative slows down when a mandatory obligation is added to a team’s load, rather than leaving that decision to whichever project manager escalates loudest.
- Genuine change conflict detection across the business unit’s initiatives, treating overlapping change on the same team as a standing risk to monitor, not a coincidence discovered after go-live.
- Aligning frontline readiness and engagement data with the customer communication plan, rather than letting the two run on separate tracks. A business unit that knows its contact centre team is stretched thin two weeks out from a major product change should be the same function deciding when and how customers hear about that change, because a rushed or poorly staffed customer response is exactly when a communications gap turns into a complaint, an escalation, or a DDO and Consumer Duty evidence problem.
Without a real system of record spanning every initiative, not a folder of individual project plans, this function is guesswork dressed up as governance. This is precisely the gap a dedicated change portfolio platform is built to close.
Enterprise and board level: performance and portfolio benefit impact
The board and executive committee should not be reviewing individual project statuses, and their interest in this governance model is not primarily who is personally accountable for what. It is performance: what is the change portfolio, taken as a whole, doing to operational performance, customer outcomes and the benefits the organisation committed to when it funded each initiative. This level should own three things:
- A portfolio-wide performance and benefit-impact view, showing where concurrent change is degrading operational metrics, error rates, service levels, adoption, or customer satisfaction, against the benefit case that justified the investment in the first place, not a status roll-up of red, amber and green.
- The change capacity ceiling, set as an explicit decision: how much combined regulatory-mandated and discretionary change the organisation can absorb in a given period without measurably eroding performance, informed by what the business unit and operations levels are reporting, not set once a year and forgotten.
- The trade-off decision when capacity and benefit realisation conflict, deferring or resequencing discretionary transformation when the evidence shows it is putting delivery of committed benefits, or day-to-day performance, at risk. TSB’s board found this out only after the fact; CPS 230 and its international equivalents now expect boards to be asking the question before it happens.
If your board only ever sees a portfolio-wide status summary with no visibility of the performance and benefit impact underneath it, you do not yet have this layer, regardless of how many steering committees exist beneath it.
Customer disclosure obligations are now a change design constraint
Two regimes change what “ready to launch” means for any customer-facing financial services change. Under ASIC’s Design and Distribution Obligations, issuers and distributors must define a target market and take reasonable steps to keep distribution within it on an ongoing basis, not through a one-off disclosure document; ASIC has already secured an $8 million penalty against Firstmac and issued more than 80 preliminary stop orders for DDO contraventions. In the UK, the FCA’s Consumer Duty, in force since July 2023, goes further still, requiring firms to evidence good outcomes across products, price, consumer understanding and consumer support, with an annual board-level assessment of whether they achieved this.
The practical effect is that the customer communications and monitoring plan, historically a downstream deliverable finished once “the real work” was done, is now itself a compliance artefact that has to be designed before a change goes live, not written up afterwards. For any financial services group operating across more than one of these regimes, and most larger insurers and wealth managers do, a single change rolled out on one timeline needs two distinct evidence trails, not one disclosure pack adapted after the fact, because DDO and Consumer Duty ask genuinely different questions of the same change.
Inside the governance model, this obligation sits at the intersection of the operations and business unit levels, and it fails when it is treated as belonging to neither. Three things need to move earlier in the change lifecycle to close that gap:
- Target market and product governance checks belong inside the change design phase, reviewed alongside scope and timeline, not bolted on as a compliance sign-off after design is locked.
- Frontline readiness and engagement data has to be read alongside the customer communication plan, not separately. If operations-level signals show a team is already stretched, that is a reason to reconsider the timing or intensity of the customer-facing message going out at the same time, not just a resourcing footnote for the business unit to manage quietly.
- Consumer-facing changes need enough lead time built into sequencing to construct the outcomes evidence base regulators expect, which the business unit level can only protect if it has visibility of the deadline early, not discover it competing with an unrelated regulatory-mandated change for the same launch window.
- Overlapping customer segments need to be visible at portfolio level, because a segment absorbing three separate product changes in one quarter is a consumer-understanding risk even where each change individually cleared its own DDO or Consumer Duty review in isolation.
Two risk domains most governance models still bolt on instead of owning
AI as its own governance lane
APRA’s April 2026 letter to industry, following targeted engagement with large banks, insurers and superannuation trustees, found that “AI governance, risk management and assurance are struggling to keep pace” with adoption, with specific gaps in identity and access management, patch management and testing of AI-generated code. The governance model above answers this directly: an AI-enabled change, a new underwriting model, an AI-assisted advice tool, needs its own line in the enterprise-level performance and benefit-impact view and its own capacity and risk data at the operations and business unit levels, not a place inside the general “technology change” category where AI-specific risk gets diluted into a bucket it does not fit.
Badly managed change as a named operational and legal hazard
Canada’s OSFI Guideline E-21 is unusual among the regimes above in naming change management explicitly as a component of operational risk and resilience regulators expect institutions to govern, not folding it into generic technology or project risk. Australia’s Safe Work Australia Model Code of Practice on psychosocial hazards reaches a parallel conclusion from the workplace health and safety side, naming badly managed change, alongside high job demands and low role clarity, as a specific hazard organisations have a legal duty to identify and control. Read together, these two regimes from two different regulatory traditions are saying the same thing: change load concentration on a team is not a soft people-risk footnote. It belongs in the operations and business unit levels of the governance model as a tracked risk, on the same footing as a system outage or a compliance breach.
For financial services specifically, this hazard concentrates in exactly the operations and frontline teams carrying the heaviest regulatory-mandated load, claims, contact centre, lending operations, the same teams disclosure and prudential regimes place under the most scrutiny. A governance model that tracks capacity and readiness at the operations level is therefore not a parallel wellbeing initiative sitting alongside risk management. It is the same data serving both obligations at once, which is precisely why it belongs in the risk-in-change register rather than a separate HR dashboard nobody in risk or compliance ever sees.
What this looks like in practice
Take a claims operations team absorbing three concurrent changes: a mandatory process update to meet a new disclosure deadline, a core system upgrade, and a discretionary efficiency initiative the business case was signed off eighteen months ago. Under most current governance arrangements, each of these reports green individually, three separate project managers, three separate steering committees, no shared view of the team underneath them. Under the three-level model, operations would have flagged the combined load against real team capacity weeks earlier; the business unit would have used that signal to recommend deferring the discretionary initiative and to hold back the customer communication until the team had capacity to handle the resulting enquiries well, since the disclosure deadline is fixed and the system upgrade is nearly complete; and the enterprise level would have seen the benefit-realisation and performance trade-off explicitly, on the record, rather than discovering it once the team’s error rate, complaint volume or attrition spikes. That is the exact sequence of missing decisions TSB’s post-mortem points to, replayed at a smaller, everyday scale.
A governance model is only as good as the data feeding it. In practice, the financial services change functions doing this well share four disciplined habits.
- They maintain a rolling, not point-in-time, change readiness assessment at the operations level, because readiness collected once at project kickoff is stale within weeks in a fast-moving regulatory environment.
- They give the board a single portfolio-level view of performance and benefit impact, where regulatory deadlines, capacity and consumer-facing change intersect, rather than a stack of individual project RAG statuses that hide exactly the kind of overlap TSB’s failure exposed.
- They treat the organisational structure question, centralised, federated or hybrid change governance, as a deliberate design choice rather than an accident of history; if this decision has not been made explicitly in your organisation, our guide to choosing the right enterprise change management structure is a useful next step.
- They tie change delivery to sustained benefit realisation, not milestone completion, so the enterprise level’s capacity-ceiling decisions are informed by what previous change actually protected or delivered, not just what it shipped on time.
None of this is achievable through steering-committee reporting alone. It requires a system of record spanning the whole portfolio that can answer, for any team, at any level, “what is landing here, from every source, this quarter, and what is it doing to performance,” as a standing question rather than a special request pulled together after something has already gone wrong. This is the specific gap a change intelligence platform like Change Compass is built to close for financial services portfolios: giving each governance level, operations, business unit and enterprise, the same live view of change load, sequencing, readiness and benefit impact, rather than three disconnected versions of the truth.
Where governance actually has to start
TSB’s board found out only after the fact what its change portfolio was doing to operational performance and customer outcomes. That is the test worth applying to your own portfolio today: can your board see, right now, the performance and benefit impact of everything landing on your frontline teams this quarter, not just a status roll-up of individual projects. If the answer is no, that is where your governance model needs to start, at whichever of the three levels, operations, business unit or enterprise, currently has the least visibility, before the next regulatory deadline forces you to find out the hard way.
Frequently asked questions
What does governance at the operations, business unit and enterprise level mean for change management? It means splitting change portfolio governance into three distinct levels: operations teams who surface real capacity, readiness and customer-interaction data, a business unit layer that sequences change and aligns frontline readiness with customer communication, and an enterprise or board level that reviews the performance and benefit impact of the whole portfolio and sets the capacity ceiling. Most financial services change functions have committees at each level but rarely this clean a division of what each one actually owns.
Why do financial services regulators increasingly treat change-related operational risk as a board-level issue? Regimes such as Australia’s CPS 230, Canada’s OSFI Guideline E-21, the EU’s DORA and the UK’s Senior Managers regime were all designed to close a gap regulators saw repeatedly: institutional failures where no one at the right level had both the visibility and the authority to prevent them. Some of these regimes go further and require a named accountable individual, but the underlying demand in every case is board-level oversight of the risk change activity creates, not just after-the-fact accountability.
How is change management treated as an operational risk under regimes like CPS 230 and OSFI Guideline E-21? Both regimes require boards to oversee operational risk arising from an institution’s own change activity, not just external threats. OSFI’s Guideline E-21 goes further by explicitly naming change management as a component institutions must govern, alongside business continuity and crisis management, rather than treating it as a generic project management concern.
Why do design and distribution obligations affect how a change is rolled out, not just how it is communicated? DDO and the FCA’s Consumer Duty both require ongoing evidence that a product or service change is reaching its intended market and delivering good customer outcomes, not a one-off disclosure at launch. This means the monitoring and evidence plan has to be designed into the change itself before go-live, rather than treated as a communications task completed afterwards.
Is AI-enabled change different from other technology change in a governance model? Yes. Regulators including APRA have found that AI governance, risk management and assurance are not keeping pace with the speed of AI adoption in financial services. This means AI-enabled change needs its own line in the enterprise-level performance view and its own risk data at the operations and business unit levels, rather than being managed inside a general technology change category where AI-specific risks are easy to miss.
Why should frontline readiness data be linked to customer communication planning? If a frontline team is already stretched by concentrated change load, that is directly relevant to when and how a customer-facing message about that change should go out, because an under-resourced team is more likely to produce inconsistent answers, longer wait times or missed follow-up when customers respond. Treating readiness and customer communication as two separate workstreams is a common reason DDO and Consumer Duty evidence gaps appear even when each team believes it delivered its part correctly.
References
- Bank of England (PRA): PRA fines the former Chief Information Officer of TSB Bank plc
- FCA: TSB fined £48.65m for operational resilience failings
- APRA: Financial Accountability Regime
- OSFI: Backgrounder, Guideline E-21, Operational Risk and Resilience
- MAS: Guidelines on Individual Accountability and Conduct
- EIOPA: Digital Operational Resilience Act (DORA)
- APRA: Prudential Standard CPS 230 Operational Risk Management
- Corrs Chambers Westgarth: ASIC begins enforcement of design and distribution obligations
- FCA: Consumer Duty
- Safe Work Australia: Model Code of Practice, Managing psychosocial hazards at work
- APRA: Letter to Industry on Artificial Intelligence (AI)
