Resources / Transformation and Risk / Regulatory Change Delivery in Financial Services

Resource guide · Transformation and Risk

Regulatory Change Delivery in Financial Services

A practitioner’s guide to delivering regulatory change in regulated organisations. How to read the regulation, build a credible plan, manage scope under a fixed deadline, and land the change so the business can actually operate it.

Note. This guide is provided for general information and educational purposes. It reflects the author's independent views and experience and does not constitute professional advice.

UK examples are used because that is the regulatory environment most familiar to the author, with explicit reference to New Zealand and Australia, where the framework or regulatory approach differs. Readers operating in other jurisdictions should map the points to their own regulators and rules. Where specific obligations apply to your organisation, take appropriate professional advice.

All content represents the independent views and experience of Russel Fielding and does not represent any employer or client organisation.

Contents

Introduction
What makes regulatory change different
Reading the regulation
Building the plan
Governance and decision-making under a fixed deadline
Multi-programme environments and portfolio prioritisation
Operational readiness
Evidencing compliance
After go-live: embedding and the next iteration
Implementation checklist
A final note

Introduction

Most large financial services firms are running multiple regulatory change programmes at any given moment. In the UK, that usually means a mix of conduct regulation, prudential reform, consumer credit change, accountability regimes, and financial crime obligations, alongside the steady flow of supervisory communications that shape how firms are expected to respond in practice. That is before they get to anything internal or discretionary.

The companion guide to this one, Delivering Transformation in Financial Services, sits at the board and executive level. It covers the governance, sponsorship, and capability questions that determine whether a transformation programme has a realistic chance of succeeding. This guide sits one tier down. It is written for the people actually running regulatory change programmes: senior project and programme managers, compliance leads working alongside them, operations and technology leaders carrying the delivery weight, and the senior managers who hold accountability under the Senior Managers and Certification Regime.

Regulatory change is the most common form of delivery in financial services and one of the most demanding. It has a deadline that cannot be moved. It has a scope that the organisation did not get to choose. It has personal consequences for senior managers if it goes wrong. And it sits within an organisation that is almost certainly running several other regulatory programmes at the same time, competing for the same resources and leadership attention.

The discipline of doing this well is not mysterious. It is built on the same principles that underpin any well-run programme: clear scope, credible plan, active dependency management, honest risk reporting, and a governance forum that actually makes decisions. What makes regulatory change distinctive is the combination of constraints under which those disciplines have to operate, and the consequences of getting any of them wrong. This guide works through how that combination plays out in practice.

What makes regulatory change different

The defining features of regulatory change as a delivery context are worth setting out at the start, because almost every other choice in the programme follows from them.

The deadline is fixed and externally imposed

Most delivery contexts allow some negotiation of the timeline. A technology programme that encounters difficulties can extend its delivery date, descope, or phase the release. A regulatory programme generally cannot. The regulator sets the deadline, and missing it has consequences that range from supervisory action through to enforcement, fines, and in the most serious cases, personal consequences for senior managers.

That single constraint changes how every other dimension of the programme has to be managed. Scope cannot be allowed to grow beyond what the deadline can accommodate, because there is no relief valve on time. Resources must be available when the plan needs them, because schedule compression is constrained by what the regulation permits. Risk has to be escalated promptly, because the cost of late discovery is a missed deadline rather than a delayed go-live.

The scope is defined by someone else

In discretionary transformation, the organisation decides what it is doing and can adjust the scope as it learns. In regulatory change, the scope is defined by the regulation. The organisation's job is to interpret what the regulation requires and translate that into operational and technical change. That interpretation work is harder than it looks. The regulation is a legal instrument. It tells you what outcome you have to achieve, sometimes in considerable detail, but it does not tell you how to organise your business to achieve it.

This creates a particular pattern of risk. The most expensive mistakes in regulatory change delivery happen at the scoping stage, when the organisation interprets the requirement narrowly, broadly, or wrongly, and builds against that interpretation. By the time the gap is discovered, the design decisions have been made and the systems have been configured, making rework expensive. Getting the interpretation right at the outset, with proper involvement from legal, compliance, operations, and technology, is the single highest-leverage activity in a regulatory programme.

The consequences of failure are not just commercial

A discretionary programme that overruns or underdelivers produces a commercial consequence: a delayed benefit, a written-off cost, a frustrated stakeholder. A regulatory programme that fails produces a regulatory breach. That distinction matters because it changes how risk should be treated and how governance should be designed.

In the UK, the Senior Managers and Certification Regime places clear personal accountability on senior managers for the areas they are responsible for. Under section 66A(5) of the Financial Services and Markets Act 2000, a senior manager may be accountable for a breach occurring in their area if they did not take the steps a person in their position could reasonably be expected to take. New Zealand and Australia differ in legal structure, but both have strengthened conduct and accountability expectations that make governance, oversight, and evidence of reasonable steps material in practice.

The practical implication is that a regulatory change programme is not a discretionary investment that can be quietly deprioritised. It is a vehicle through which senior managers discharge personal accountability. The programme manager who understands this dynamic is positioned to operate at a different level than one who treats it as just another delivery assignment.

The asymmetry of regulatory risk. A regulatory programme that finishes a month late has missed a deadline. A regulatory programme that finishes on time but with the wrong scope has produced a non-compliance that may not surface for years, when a supervisor or auditor finds it. Both are failures, but they are not equivalent. The late delivery is visible immediately and can sometimes be remedied. The wrongly scoped delivery embeds an issue into the operating model that compounds with time. Get the interpretation right first, then plan for the deadline.

Reading the regulation

The first task in any regulatory change programme is to understand what the regulation actually requires. This sounds obvious. In practice, it is the step organisations most consistently rush, with the highest downstream cost.

Read it yourself

A programme manager who does not read the regulation relies on secondhand interpretation. That dependency is a problem. Compliance and legal colleagues are essential interpreters of the regulation, but they work from their own perspective, which is generally legal and supervisory. The translation from "this is what the regulation says" to "this is what we have to build" is a joint exercise. The programme manager who has read the source material is a better partner in that translation than one who is working from a briefing document.

Read the regulation itself. Read the supervisory statements, policy statements, and consultation responses that surround it. Read the Q&A documents and Dear CEO letters where they exist. In the UK, sector reports, supervisory communications, and regulatory policy material often give the clearest view of where the FCA or PRA expects firms to focus. In New Zealand, the relevant material is set out in the Reserve Bank's prudential standards, the FMA's guidance, and the conduct regime for financial institutions. In Australia, APRA's prudential practice guides sit alongside the Financial Accountability Regime and ASIC's conduct expectations. The exact documents will vary by topic. The discipline is the same: read the rule, then read the material that shows how the regulator expects firms to apply it.

Get the right people in the room

Scoping a regulatory programme is a cross-functional exercise. The minimum participation is legal, compliance, operations, technology, and risk. Legal interprets the regulation in its statutory context. Compliance understands what the supervisor is likely to expect in practice. Operations knows how the current state actually works, which is often different from how the policy specifies it. Technology understands what is genuinely achievable in the available systems. Risk understands what the obligation means for the firm's risk profile and existing controls.

The pattern to avoid is the sequential handoff: legal interprets the regulation and produces a memo, compliance translates the memo into requirements, operations translates the requirements into process changes, technology translates the process changes into system changes, and risk reviews the result at the end. By the time the chain has run, each translation has lost some of the original intent, and the final design may have only a loose relationship with what the regulation actually required.

The alternative is to have these functions in the same room from the outset, working through the interpretation together. It is slower at the front end and significantly faster overall, because it surfaces the disagreements early, when they are cheap to resolve.

Define the current state honestly

Most regulatory change programmes are working against an obligation that the firm is, in some sense, already trying to meet. There is an existing process, control, or system that performs part of what the new obligation requires—understanding that current state honestly is essential before designing the future state.

"Honestly" is the operative word. Current state documentation in large organisations is often aspirational rather than descriptive. It captures what the process is supposed to do, not what people actually do day to day. A scoping exercise that relies on policy documents and process maps without speaking to the people doing the work will produce a gap analysis that is wrong in important ways. The gap will be smaller than it really is on the items where the current practice has drifted away from the documented process. It will be larger than it really is on the items where workarounds have already been built to meet emerging supervisory expectations.

The work of mapping the genuine current state, with input from the people who run the process every day, is unglamorous and time-consuming. It is also the single most important input into a credible scope.

Document the interpretation

Once the cross-functional team has worked through the regulation, the interpretation needs to be written down. This is not a compliance memo for the file. It is a working document that describes the obligation, the firm's interpretation of what compliance looks like in practice, the assumptions that underpin that interpretation, and the open questions that remain. It is signed off by the relevant functions and becomes the reference point for the rest of the programme.

The reason this document matters is that interpretations change. New supervisory guidance emerges. New Q&As clarify ambiguous points. A senior leader joins the firm and reads the obligation differently. Without a written record of why the original interpretation was reached and on what assumptions, the programme is exposed to drift that can quietly invalidate decisions made months earlier. The interpretation document is the basis for assessing any subsequent change.

Building the plan

A regulatory programme plan is a working document, not a presentation. It captures what needs to happen, when, in what sequence, by whom, with what dependencies, and with what room to absorb the inevitable surprises. A plan that does not do those things is a chart of milestones, which is a different artefact and one that does not help anyone deliver.

Work backwards from the deadline

The fixed deadline is the strongest organising principle in the plan. Use it. Identify the regulatory date, work backwards through the activities that must be completed before it, and identify the latest point at which each activity can start without putting the deadline at risk. That gives you the critical path: the sequence of activities where any delay translates directly into a missed regulatory date.

Knowing the critical path changes how the programme is managed. Critical path activities get the most senior resources, the closest attention, and the first call on shared dependencies. Non-critical activities can be delayed, resequenced, or descoped without affecting the deadline. Plans that treat all activities as equally important are missing the point. The critical path is where the programme manager spends their attention.

Decompose the work properly

Most regulatory programmes are too large to plan as a single block of work. They need to be broken down into the workstreams, components, and individual activities that make up the whole. The decomposition is a thinking exercise, not a documentation exercise. The act of breaking the programme down into its parts is how the programme team works out what it is actually being asked to deliver, what the dependencies between the parts are, and where the risks sit.

The right level of decomposition is the level at which an activity can be estimated, owned, and tracked. If an activity is too big to estimate honestly, it needs to be broken down further. If it is so small that the overhead of tracking it exceeds its value, it can be rolled up. A good rule of thumb is that any activity longer than two or three weeks should be broken down into smaller pieces, because beyond that timeframe, the estimate becomes a guess and the slippage becomes invisible until it is too late.

Estimate honestly

Estimation is one of the most consistently dishonest activities in large-organisation delivery. The estimate that gets approved is often the one that fits the deadline, not the one that reflects the work. The team knows the real number is larger. The leadership knows the real number is larger. But the plan that goes to the steering committee shows the optimistic number, and everyone agrees to pretend it is.

The cost of this is paid later, when the programme starts missing milestones. The honest estimate would have prompted a conversation about scope, resourcing, or phasing at the outset, when the options were still open. The dishonest estimate forecloses those conversations until the programme is already in trouble.

Build estimates from the people doing the work, not from those managing it. Cross-check them against the actuals of previous programmes that did similar things. Apply contingency at the right points: not as a flat percentage across every activity, but concentrated where the uncertainty actually lives. A clear scope with a known method needs little contingency. A novel integration with a third party needs a lot.

Identify dependencies and manage them as risks

Dependencies are one of the most consistently mismanaged elements of programme planning. A dependency on a technology team, a regulatory decision, a third-party provider, or another programme in the portfolio is a risk to the deadline. It needs to be identified, owned by someone with the authority to act on it, and tracked with the same discipline as any other risk.

The pattern to avoid is a dependency listed in a register but not actively managed. The dependency owner has not been engaged, the date by which the dependency needs to be resolved is unclear, and the trigger for escalation has not been agreed upon. When the dependency slips, as it inevitably does, the programme finds out late and has no contingency. Each significant dependency should have a name, a target resolution date, an agreed escalation route if that date slips, and a regular check-in.

Build the right contingency

Contingency is the slack the plan has to absorb the unexpected without breaching the deadline. Regulatory programmes need real contingency, not nominal contingency, because the cost of running out of it is missing a regulatory date.

Two forms of contingency matter. Schedule contingency is time built into the plan to absorb activity slippage. Resource contingency is access to people who can be brought in if the plan needs additional capacity. Both should be visible in the plan, owned at the programme level, and protected from being eroded by routine slippage. Contingency that is consumed silently to cover ordinary delays is not contingency at all by the time the genuine crisis arrives.

Plan for change control from the outset

A regulatory programme will face requests to change scope during delivery. Some of those requests are legitimate: new supervisory guidance, a clarification that changes the interpretation, or a discovery in delivery that requires a different approach. Some are not: stakeholders wanting to bundle unrelated improvements, business units lobbying for their preferred design, leadership wanting to add features to improve optics.

The plan needs to anticipate this and establish a clear change-control process from day one. Any proposed change to scope, schedule, or cost goes through a defined assessment: what is the impact, what is the rationale, what are the implications for the deadline, and what is the recommendation. The programme board makes the call, and the decision is documented. Without that process, scope creeps quietly until the deadline is no longer achievable.

Governance and decision-making under a fixed deadline

Governance in a regulatory programme has to work harder than governance in a discretionary one, because the cost of failing to decide is higher. A discretionary programme can absorb a deferred decision by adjusting the timeline. A regulatory programme cannot. Every deferred decision shortens the runway and increases the chance of a missed deadline.

The programme board needs the authority to act

A programme board that has to escalate every significant decision is not a programme board. It is a recommendation forum. For a regulatory programme to operate at the pace the deadline requires, the programme board needs a clear mandate to make decisions within the programme's scope without further escalation. That mandate has to come from above, and it has to be respected by the people who sit on the board.

The decisions the board needs to be able to make include changes to scope within the regulatory envelope, reallocations of resources between workstreams, and judgments about where to apply contingency. Decisions that genuinely require escalation include changes that affect the regulatory commitment, decisions that have implications for other programmes in the portfolio, and judgements that require board-level risk appetite. The boundary between the two should be agreed at the outset and reviewed if it starts to drift.

Pick the right cadence

Programme governance often defaults to monthly meetings because that is how diaries work. Monthly may not be the right rhythm for a programme on a fixed regulatory deadline. As the deadline approaches, the cadence needs to tighten. A programme that meets monthly twelve months out should be meeting weekly in the final eight weeks, with senior leaders available for rapid escalation in between.

The rhythm should be designed against the plan, not against the calendar. The board meets when it needs to make decisions. If a critical path activity reaches a decision point, the board needs to be in a position to make that decision, not wait for the next scheduled meeting.

Honest status reporting

RAG reporting in large organisations is often performative. Green means the programme manager believes they can recover from current issues, not that everything is on track. Amber means there is a problem the programme manager is working on, but does not want senior visibility on. Red means something has gone so wrong that it can no longer be hidden. This system tells the board very little until it is too late.

The fix is not to discard RAG status but to require the underlying narrative to be honest. What is going well, with evidence? What is not, with specifics. What decisions are needed, and what options are available? What risks are emerging with assessment? A status report that contains none of those things is theatre.

Programme managers are sometimes reluctant to report honestly because they have learned that honest reporting attracts unwelcome attention. That is a culture problem at the programme board level, not a programme manager problem. Boards that respond to amber and red status by asking constructive questions and supporting the programme manager get honest reporting. Boards that respond by berating the programme manager get carefully managed reporting. The board sets the tone.

Escalate decisions before they become crises

The most useful skill a regulatory programme manager develops is knowing when to escalate. Too early, and the board is overwhelmed by trivia. Too late, and the options have collapsed. The judgment is partly about timing and partly about framing.

An escalation that arrives with a clear statement of the issue, the options, the assessment, and a recommendation lets the board make a decision. An escalation that arrives as a problem statement requires the board to conduct the analysis, which they are not well-placed to do in a one-hour meeting. The programme team's job is to decide as easily as possible. The board's job is to take it.

The SMCR dimension. Under the Senior Managers and Certification Regime, the senior manager accountable for a regulatory programme has a personal duty of responsibility for the area in which the programme sits. That accountability is not transferable to the programme manager, the steering committee, or the consulting firm running the work. A senior manager who is poorly informed about a programme they are accountable for is exposed to a duty-of-responsibility issue, not just a delivery problem. Good governance in regulatory change is not just a delivery practice. It is how the senior manager discharges their personal regulatory obligation.

Multi-programme environments and portfolio prioritisation

No regulatory programme exists in isolation. Most large financial institutions are running several at once, sometimes a dozen or more, alongside technology-led and customer-led transformation. The programmes compete for the same scarce resources: senior technologists, business analysts, operations capacity, leadership attention, and change capacity in the parts of the business that have to absorb the change.

The portfolio view

The decisions that determine whether an individual programme can succeed are often made at the portfolio level, not at the programme level. If two regulatory programmes need the same systems integration team in the same quarter, the question of which one gets the resource is a portfolio question. The individual programme manager cannot solve it. The organisation needs a forum at which those trade-offs are made deliberately, with the right information and the right authority.

Portfolio governance in many large firms is weaker than programme governance. Individual programmes have boards, sponsors, and risk processes. The portfolio that contains them has, in many cases, only an aggregated reporting view, with no clear authority to resolve conflicts between programmes. The result is that programmes negotiate informally for shared resources, the loudest sponsor wins, and the strategic prioritisation that should happen at the portfolio level is replaced by political prioritisation at the operational tier.

Mature portfolio governance does several things that individual programme governance cannot. It maintains a current view of which programmes are in flight, what resources they are consuming, where the dependencies between them lie, and where the genuine conflicts sit. It makes prioritisation calls when conflicts arise, applying a consistent framework rather than being swayed by the relative seniority of the people making the case. It can stop or pause programmes when their value no longer justifies the resources they consume, which is one of the most difficult and underused decisions in transformation.

Prioritisation when deadlines conflict

The hardest prioritisation question in a regulatory portfolio is what to do when two regulatory deadlines conflict for the same resource. There is no comfortable answer. Both have regulatory consequences. Both have senior managers personally accountable for them.

The right place to make that call is the executive committee, with input from compliance, risk, and the affected programmes. The factors to weigh include the relative consequences of missing each deadline, the regulator's likely appetite for a controlled extension on one of them, the cost and feasibility of additional resourcing to deliver both, and the strategic priority of the underlying obligations. The decision should be documented, communicated, and, where appropriate, raised with the regulator in advance. Quietly accepting that one programme will be late, without anyone deciding which one, is the worst available outcome.

Building portfolio capacity

The longer-term answer to recurrent portfolio crunch is to build the organisation's capacity to deliver regulatory change. Some of this is structural: a regulatory change function that holds the portfolio view, a strengthened PMO that consistently supports multiple programmes, and a clear methodology that all programmes apply rather than each reinventing the approach. Some of it is about talent: a deeper bench of experienced regulatory change leaders, career paths that retain them, and a culture that recognises delivery as a profession rather than a stepping stone to other roles.

Organisations that invest in regulatory delivery capability between cycles handle the next cycle better than those that scramble to assemble a programme team each time a new obligation arrives. The investment is not glamorous and rarely shows up in shareholder communications. It is one of the highest-return investments a regulated firm can make.

Operational readiness

The technical build of a regulatory programme is often the easiest part. The harder part is the operational change that has to land alongside it. A system that is built but cannot be used effectively, a process that is documented but not embedded, a control that exists on paper but is inconsistently applied: all of these are non-compliant, regardless of whether the technical delivery was on time.

Readiness is more than testing

Operational readiness is sometimes treated as a testing activity at the end of delivery. It is not. It is an organisational state in which the people who need to operate the new way of working have the knowledge, capability, tools, and support they need to do so consistently from go-live.

That state has to be designed from the outset of the programme. The training has to be planned, designed, delivered, and reinforced. The new process has to be documented, communicated, and embedded. The line managers who supervise the new way of working have to be coached on what good looks like and how to intervene when it is not happening. The exceptions and edge cases have to be anticipated, decided upon, and built into the operating model. None of this happens automatically in the four weeks leading up to go-live.

Train for capability, not knowledge

Most regulatory training is built around the content of the regulation and the features of the new system. That is the wrong starting point. The right starting point is what people need to be able to do differently after the change, and how they need to handle the edge cases and exceptions that the regulation throws up.

A person who has been shown a new system but cannot use it effectively to do their job has not been adequately trained. A person who can recite the regulation but cannot recognise when it applies has not been adequately trained. Training design starts with the desired capability, works backwards through what people need to know to achieve it, and then builds the learning experience that gets them there.

The timing matters as much as the content. Training delivered too early is forgotten before it is needed. Training delivered at go-live, when people are already absorbing the operational pressure of implementation, lands badly. The right timing depends on the role, the complexity of the change, and the learning approach. Most programmes default to whatever fits the project timeline, which is the wrong answer.

Test the operating model, not just the system

Pre go-live testing in most programmes focuses on whether the technology works. That is necessary but not sufficient. The harder question is whether the operating model works: can the people, processes, and systems together produce the outcome the regulation requires, consistently, across normal cases and edge cases, with the right supervision and escalation?

Testing the operating model means simulating realistic volumes, including the awkward cases, with the actual people who will operate the process post go-live. It means running the management information that will exist in production and checking whether it surfaces the issues it needs to surface. It means rehearsing the escalation pathways and verifying that the right people get involved at the right point.

Operational readiness assessments that focus solely on technology testing systematically underestimate the risk of post-go-live issues. The most consistent pattern of regulatory programme failure is a technically delivered programme that lands on time but produces an unstable operating environment in the months that follow, because the operating model around the technology was not adequately tested.

Plan the cutover

Go-live for a regulatory programme is rarely a clean cutover from the old way to the new way. There are usually customers, transactions, or cases in flight that need to be migrated. There is a period during which both ways of working may need to operate in parallel. There are decisions to be made about what to do with edge cases that fall across the cutover date.

The cutover plan needs to address all of this. It identifies the work cohorts that need to migrate, the sequence in which they migrate, the criteria for treating a case under the old rules versus the new rules, and the contingency arrangements if something goes wrong. It rehearses the go-live activities themselves, often through one or more dress rehearsals in the weeks before the regulatory date. It includes a clear definition of what success looks like on the first day, the first week, and the first month after go-live, and how that will be assessed.

Hypercare

The period immediately after go-live is when most problems surface. The volume of edge cases is higher than predicted by testing. The new management information is unfamiliar and harder to read than expected. The training has not yet been reinforced by repeated practice. People are slower and less consistent than they will be in a few weeks.

The programme needs to plan for an intensive support period after go-live, often referred to as hypercare. The programme team stays in place. Issues are triaged, prioritised, and addressed rapidly. Management information is reviewed daily. Senior support is visibly available. The programme is not declared complete until the post-go-live environment is stable and the operating model is producing the required outcomes under the regulation. That point usually arrives several weeks after go-live, sometimes longer, depending on the complexity of the change.

Evidencing compliance

A regulatory programme must produce two outputs: a compliant operating state and evidence that the operating state is compliant. The second output is sometimes treated as an afterthought, which is a mistake. A firm that is compliant in fact but cannot evidence the compliance is exposed in supervisory examinations, audits, and enforcement.

Design for evidence from the outset

The evidence of compliance is not a separate workstream. It is a property of the programme's design and delivery. Decisions made during the programme need to be captured in a form that can be reviewed later by a supervisor or an internal auditor. Controls being put in place need to be documented in a way that demonstrates how they meet the obligation. Testing being performed needs to be recorded in a way that shows what was tested, by whom, when, and with what result.

The phrase "no decision without a record" is a useful discipline. Every significant decision in the programme has a memo, an email, or a minute that captures what was decided, on what basis, by whom, and when. That record sits in a structured archive that will outlast the programme team, so that when a question arises three years later about why a particular interpretation was reached, the answer is in the record rather than in the memory of someone who has since left the firm.

Document the control design

The output of a regulatory programme is, in most cases, a set of new or revised controls. Those controls need to be documented in a way that shows the obligation they meet, the design that addresses the obligation, the testing that confirms the design works, and the monitoring that will detect if it stops working. The documentation is not a one-off artefact produced at go-live. It is a living set of documents that gets maintained as the control evolves.

The level of detail varies with the control's complexity and materiality. A major control supporting a significant regulatory obligation requires detailed documentation, including the control owner, operating frequency, testing approach, supporting management information, and the escalation route in the event of a control failure. A simpler control may need less. The principle is the same: the design and operation of the control are documented in a form that a supervisor or auditor can review without interviewing the people who run it.

Build the audit trail

Supervisors and internal auditors will, at some point, examine the firm's compliance with the obligation the programme has delivered. The programme that has thought about this from the outset will produce an audit trail that makes the examination straightforward. The programme that has not will produce a regulatory exercise that takes months and consumes significant senior attention.

A good audit trail covers the interpretation of the regulation, the decisions made during delivery, the testing performed, the controls implemented, the training delivered, and the monitoring established. It is accessible without heroics. It is consistent in its level of detail. It tells the story of how the firm understood the obligation, what it built to meet it, and how it satisfies itself that the controls are working. Building this trail during delivery is dramatically cheaper than constructing it retrospectively when the supervisor is on site.

Engage assurance early

Internal audit and the second line are often engaged by regulatory programmes at the end of delivery, when the design has been finalised, and the controls are about to go live. That is too late. By that point, the cost of changing the design in response to assurance feedback is high, and the programme's natural response is to defend the design rather than improve it.

The alternative is to engage internal audit and the second line at design points throughout delivery. They become informed observers of the choices being made, with the opportunity to flag concerns when they can still be addressed economically. This is sometimes resisted on the basis that it compromises their independence, a misreading of how the three-line model is supposed to work. The second line and internal audit can provide informed input on design without compromising their later review role, provided their input is captured, and the programme retains decision authority.

After go-live: embedding and the next iteration

The programme is not finished at go-live. The change has been delivered but not yet embedded. The benefits have been promised but not yet realised. The operating environment is unstable and will remain so for some period. And the regulation that the programme was built to meet will itself evolve in the coming years, in ways the programme needs to be designed to accommodate.

Embedding takes time

The work of embedding a regulatory change continues for months after the go-live date. The new process becomes a habit only through repeated practice. The exception cases are worked through, and decisions are made about how to handle them. The management information starts to tell a coherent story rather than a noisy one. The supervisors who run the process learn what good looks like and how to coach their teams.

The programme needs to plan for this phase. Resourcing has to be available to support emerging issues. The original programme team often disperses too quickly, with knowledge walking out the door before the operating environment is stable. A deliberate transition into business as usual, with named owners taking on responsibility for the control, the process, and the supporting technology, is an essential closing activity.

Realise the benefits

Most regulatory programmes are accurately positioned as compliance obligations rather than value-creation initiatives. That positioning sometimes leads to an attitude of "the benefit is being compliant, so we don't need to track anything else." This is a missed opportunity. Regulatory change programmes almost always also produce process improvement, technology modernisation, and control uplift. Those benefits are real and worth tracking.

Define the benefits at the outset, in measurable terms, with a baseline established before the programme begins. Assign a benefits owner accountable for realising those benefits after delivery, separate from the programme manager who delivered the change. Track benefits realisation at six and twelve months post go-live, not just at programme closure. The benefits picture often takes a year or more to stabilise, and the governance structure needs to outlast the programme to see it through.

Capture the lessons honestly

Post-implementation reviews in many large organisations are an exercise in mutual congratulation. The programme is declared a success, the lessons are captured at a level of generality that makes them unactionable, and the document goes into the archive. The next programme starts and repeats the same mistakes.

An honest post-implementation review asks what went well, what did not, what would be done differently, and what specific changes the organisation should make to deliver better next time. It is honest about estimation errors, dependency surprises, scope misinterpretations, and stakeholder management failures. It captures the lessons at a level of specificity that lets the next programme avoid the same trap. And it is written for use, not for the file. Lessons that are not subsequently incorporated into the firm's delivery practice add no value.

Build for the next iteration

Regulation does not stand still. The obligation the programme has just delivered will itself be amended, extended, or replaced within two to five years. The programme built for the obligation, as currently written, has produced a control environment that will need to be partially rebuilt the next time the regulation changes. The programme, built for the obligation while anticipating its evolution, has produced an environment that can adapt at marginal cost.

Building for the next iteration means designing controls and systems with flexibility in mind. It means documenting decisions and assumptions clearly enough that future changes can be reasoned about. It means maintaining a live view of how the regulation is likely to evolve, through horizon scanning by the compliance and risk functions. It means treating the operating model as a living capability rather than a fixed artefact. The firms that adapt efficiently to regulatory change are the ones that have made this discipline part of how they operate, not the ones that build a new programme from scratch each time.

Implementation checklist

The following covers the questions a programme manager, senior manager, or sponsor should be able to answer at any point in a regulatory change programme. It is intended as a working reference rather than an exhaustive methodology.

Foundation and scoping

Regulation read. Has the programme manager read the underlying regulation, supervisory statements, and current guidance, rather than working from second-hand briefing notes?
Cross-functional interpretation. Has the obligation been interpreted by legal, compliance, operations, technology, and risk together, with disagreements surfaced and resolved before the scope was fixed?
Current state mapped honestly. Is the current state documented as it actually operates, with input from the people running the process, rather than as the policy says it operates?
Interpretation documented. Is the firm's interpretation of the obligation documented, signed off, and retained as a reference point for the rest of the programme?
Scope agreed and held. Is the scope clearly defined, signed off at the right level, and protected by a change control process that activates on any proposed scope change?

Planning

Critical path identified. Has the plan been built backwards from the regulatory deadline, with the critical path explicitly identified and protected?
Decomposed to a workable level. Has the programme been broken down into activities that can be estimated, owned, and tracked?
Honest estimation. Are the estimates built from the people doing the work, cross-checked against previous programmes, and reflective of the genuine uncertainty in the activities?
Dependencies identified and owned. Is each significant dependency named, owned, dated, and tracked with an agreed escalation route?
Contingency built in. Does the plan include a genuine schedule and resource contingency, owned at the programme level and protected from routine slippage?
Change control is active. Is there a defined process for assessing and deciding on proposed changes to scope, schedule, or cost, with decisions documented?

Governance and decision-making

Board has authority. Does the programme board have a clear mandate to make decisions within the programme's scope without further escalation?
Right people in the room. Are the right functional representatives on the board, with the seniority to make decisions on their function's behalf?
Cadence matches deadline. Is the meeting cadence appropriate to the proximity of the deadline, tightening as go-live approaches?
Honest status reporting. Does the programme report on what is going well and not going well with specifics, options, and recommendations, rather than RAG-coded reassurance?
Escalation is practised. Is the programme team escalating decisions to the board early enough to keep options open, with clear framing and recommendations?
SMCR accountability mapped. Is the senior manager accountable for the programme, clearly identified, with the information they need to discharge their duty of responsibility?

Portfolio

Portfolio view exists. Does the organisation maintain a current view of which regulatory programmes are in flight and what resources they are consuming?
Conflicts surfaced. Are conflicts between programmes for shared resources surfaced to the right governance forum, with deliberate prioritisation decisions?
Deadline conflicts addressed. Where two regulatory deadlines conflict, is there a clear decision route at the executive committee level, with documented prioritisation?
Portfolio capacity invested in. Is the organisation investing between cycles in delivery capability, PMO function, and regulatory change talent?

Operational readiness

Readiness designed in. Is operational readiness planned from the outset of the programme, not added as a workstream towards delivery?
Training built for capability. Is training designed around what people need to be able to do, with appropriate timing and reinforcement?
Operating model tested. Is testing covering the operating model end-to-end, not just the technology, with realistic volumes and the awkward edge cases?
Cutover planned and rehearsed. Is the cutover plan documented, with criteria for treatment of old-rules versus new-rules, contingency arrangements, and one or more dress rehearsals before go-live?
Hypercare in place. Is there a defined post-go-live support period, with the programme team available, daily management information reviews, and senior support visible?

Evidencing compliance

Decisions documented as taken. Is every significant decision captured in a record that will outlast the programme team, with rationale, date, and author?
Control design documented. Are new or revised controls documented with obligation, design, testing, monitoring, and owner, in a form that supports later supervisory review?
Audit trail built during delivery. Is the audit trail being constructed in real time during the programme, not retrospectively when an examination is announced?
Assurance engaged early. Are internal audit and the second line engaged at design points during delivery, with their input captured and decision authority retained by the programme?

After go-live

Embedding planned for. Is there a defined embedding period after go-live, with named owners for the controls, processes, and systems being handed over to business as usual?
Benefits tracked. Are benefits defined in measurable terms, baselined before the programme began, and tracked through to realisation at six and twelve months post go-live?
Honest lessons learned. Is the post-implementation review honest about what did not work and specific enough for the next programme to act on?
Built for the next iteration. Has the design built in flexibility for the next iteration of the regulation, with clear documentation of decisions and assumptions?

A final note

Regulatory change is the most common delivery method in financial services. It is the work that most consistently absorbs the time of project and programme managers in the sector, and the work most consistently scrutinised when it goes wrong. The discipline of doing it well is not glamorous. It is built on careful interpretation, honest planning, active dependency management, governance that decides, and a sustained focus on the operational reality the change has to land in.

The programme managers who become good at this work do so over years, not weeks. They develop the regulatory literacy to read the obligation themselves. They build relationships with colleagues in compliance, legal, operations, and technology that make cross-functional interpretation possible. They develop the judgement to know when to escalate and when to absorb a problem. They learn the difference between a deadline that has to be defended and one that can be renegotiated. And they treat each programme as an opportunity to add to that judgement, rather than as an isolated assignment to be completed and moved on from.

The organisations that handle regulatory change well are the ones that recognise this discipline as a profession and invest in it. They develop their people, maintain their delivery infrastructure, and learn between programmes. The organisations that handle it badly treat each new obligation as a fresh staffing problem, scramble together a programme team, and lose the institutional memory each time the team disperses. The difference, over a decade, is substantial: in supervisory outcomes, in the cost of delivery, and in the quality of the operating environment the programmes produce.

The discipline is teachable. The judgment comes with experience. Both repay the investment.

Key takeaways

The essentials

Three constraints define regulatory change. A fixed external deadline, a scope defined by someone else, and consequences for failure that include personal accountability for senior managers. Every other choice in the programme has to be made with those constraints in mind.
Get the scope right at the start. Read the regulation yourself. Get legal, compliance, operations, technology, and risk in the room together. Map the current state honestly. Document the interpretation.
The plan is built backwards from the deadline. Identify the critical path. Decompose into estimable activities. Treat dependencies as risks. Build genuine contingency. Plan change control from day one.
Governance under a fixed deadline makes decisions. The board needs authority. Cadence tightens as the deadline approaches. Status reporting earns its keep by being honest.
Portfolio governance matters more than programme governance. Conflicts between regulatory programmes are decided at the portfolio level, not negotiated informally between programme managers.
Operational readiness is where most programmes live or die — training built for capability. Operating model tested end-to-end. Cutover planned and rehearsed. Hypercare in place after go-live.
Evidence is built during delivery, not retrospectively. Every significant decision has a record. Controls are documented with obligation, design, testing, monitoring, and the owner. Assurance is engaged at design points.
The programme is not finished at go-live. Embedding takes months. Benefits tracked at six and twelve months. Lessons captured honestly. Design built for the next iteration.

More from Transformation and Risk

← All Transformation and Risk guides All resources →