Transformation Delivery for Financial Services

A Practitioner's Course

Session Eight

Handover and Sustaining the Change

Why the transfer from build to business as usual is where many regulatory programmes start to fail, and what a genuine handover and ongoing monitoring look like

Disclaimer This course is provided for general information and education only. It is not legal advice. Legislation, rules and regulatory guidance change, sometimes quickly. Readers should confirm the current position and obtain jurisdiction-specific professional advice where needed. The views and experience expressed are Russel Fielding's own and do not represent any employer or client organisation.

Session Eight: Handover and Sustaining the Change

Most organisations spend the visible effort on a major regulatory or transformation programme before it goes live. The work is designed, documented, tested, and delivered. A team is assembled, a deadline is set, and the work takes the shape every project takes: a beginning, a middle, and an end. Go-live, or a licence, or a sign-off, is that end. And it is the point at which the actual work often begins.

Why the handover is the weak point

A programme is built by a team that is, by design, temporary. It is assembled for the build, funded for the build, and once the outcome is achieved, disbanded, with its people returned to their previous roles or moved to the next priority. This is normal and not a criticism; it is how organisations resource major pieces of work.

But it means the programme has to change hands, and the moment of transfer is rarely treated as the significant event it actually is. It is treated as administrative: documents are moved to a repository, the owner field is updated, a closure report is signed, and the project is declared complete.

What that treatment misses is that a programme is not only its documents. It is also the understanding behind them: why a particular control was designed the way it was, which risk a process was meant to address, what was considered and rejected, and which parts of the programme are robust and which are held together with goodwill.

None of that sits in the policy document, and all of it matters to whoever now has to run the programme. When the handover is treated as administrative, that understanding leaves with the project team. The operational owners inherit a set of artefacts whose internal logic they cannot fully reconstruct. They can follow the programme, but they cannot readily improve it, adapt it, or judge when a proposed change would quietly break it.

What a real handover involves

Treating the handover as genuine work, rather than a closing formality, requires a small number of deliberate actions.

An overlap period. The operational owners should be running the new state while the build team is still available to answer questions, not for a single briefing session, but for a period of weeks during which the people who will own it can turn to those who built it when something is unclear. A handover that happens on one day is a document transfer, not a handover.

The reasoning written down, not just the artefacts. The handover needs to record why each significant control exists, what it is meant to catch, what was considered and not done, and where the build team knows the outcome is weaker than anyone would like. This is uncomfortable to write, because it commits known weaknesses to paper, and it is also the single most useful thing the build team can leave behind.

Named owners who can be asked. Every significant part of the new operating state needs an owner who could be asked today what it is for and whether it is working, without assembling a working group to answer. Ownership held by a committee or a function in the abstract is ownership no individual actually holds.

A monitoring mechanism already running before the build team leaves. The way the outcome will be checked on an ongoing basis should be operational and should have produced its first results while the build team is still in place. If the first real test happens months after the people who built it have gone, the organisation loses the only group that could quickly diagnose and fix what that test finds.

The monitoring that has to follow

A regulatory programme's output cannot be set running and left, not because regulators say so, though they do, but because the organisation around it does not stand still. Products are launched and withdrawn, distribution channels change, systems are replaced. Each of these changes is managed by people focused on the change itself, not on the outcome the earlier programme was built to protect, and each one moves the business a small distance away from what was originally designed.

Monitoring is what catches that drift, and useful monitoring has a particular quality: it is built into ordinary operation, not bolted on as a periodic exercise. A programme monitored by a special annual review produces a verdict once a year, assembled by people pulling information together specifically to answer the question.

A programme monitored continually produces evidence of how it is working as a by-product of running: complaint data is already telling a story, breach identification and response speed are already being tracked, and assurance findings already exist. When someone asks whether the outcome is working, the answer is assembled from data the organisation was already capturing. That is both more honest, because it is harder to stage, and more useful, because it surfaces problems close to when they arise.

Licensing and supervision ask different questions

Licensing, or a formal go-live sign-off, asks whether the outcome is credible: well designed, complete, and plausible. Supervision, where a regulator's ongoing attention goes once a sector is operating, asks whether it is working: shaping decisions, catching problems, and keeping pace with the business. An organisation that has answered the first question well does not automatically have an answer to the second, because the programme was, reasonably enough, built to satisfy the first assessment. Unless it was deliberately handed over and is being genuinely monitored, the honest answer to the supervisory question may be that nobody quite knows whether it is working, because nobody has been positioned to tell.

The cost, and where it sits

A proper handover and a real monitoring mechanism cost something. An overlap period means the build team is retained a little longer. Writing down the reasoning takes time. Establishing monitoring before the build team leaves brings forward work that is easy to defer. It is genuinely tempting, on the day a licence is granted or a system goes live, to declare the project complete, release the team, and bank the saving.

But the cost of doing the handover well is small set against the cost of the build, and very small set against the cost of discovering, two or three years later, that the outcome has drifted, that nobody can explain why it was built as it was, and that the organisation has to reconstruct an understanding it once had and gave away.

Jurisdiction equivalents

New Zealand's Conduct of Financial Institutions regime is a clear worked example of this pattern. Financial institutions had to build a fair conduct programme meeting the minimum requirements of section 446J of the Financial Markets Conduct Act 2013, secure a licence from the Financial Markets Authority, and then operate that programme for as long as they hold the licence. The build had an end date; the operation does not, and the institutions that come through the regime well are unlikely to be the ones that built the most polished programme. They are more likely to be the ones that treated the day after the licence as part of the licence work, not the day after it ended. Australia's Financial Accountability Regime presents the same handover challenge: once implementation closes, accountable persons still need to embed the regime in the areas for which they are responsible.

Key takeaways from Session Eight The handover is not the end of the programme. It is where the real work begins. Treating it as an administrative closing step is the single most common way a well-built outcome starts to fail. A real handover has four features. An overlap period, the reasoning written down alongside the artefacts, named owners who can be asked, and a monitoring mechanism already running before the build team leaves. Continual monitoring is more honest and more useful than an annual review. It surfaces problems while they are small and while the people who can fix them are still in post. Licensing and supervision ask different questions. Passing the first does not answer the second. Only a genuine handover and real monitoring can. The cost of a good handover is small against the cost of silent drift. New Zealand's Conduct of Financial Institutions regime shows this pattern across an entire sector at once.

Coming up in Session Nine

Session Nine consolidates the whole course into a single implementation checklist, cross-referenced across governance, sponsorship, regulatory change, people and change, risk, framework choice, reporting, and handover. Continue to Session Nine.

Further reading and resources

The handover is where regulatory programmes start to succeed. The published Ārai Tika article this session draws on, using New Zealand's Conduct of Financial Institutions regime as its detailed worked example. Available at araitika.com.

Financial Markets Conduct Act 2013, section 446J. The minimum requirements for a fair conduct programme under the Conduct of Financial Institutions regime. Available at legislation.govt.nz.

Financial Markets (Conduct of Institutions) Amendment Act 2022. The amending legislation that introduced the Conduct of Financial Institutions regime by amending the Financial Markets Conduct Act 2013. Available at legislation.govt.nz.

Financial Accountability Regime commencement materials. APRA and ASIC guidance relevant to embedding accountable persons' obligations after implementation. Available at apra.gov.au and asic.gov.au.