The first meeting on a remediation programme is rarely advertised as the meeting that will decide whether the programme succeeds. It is usually described as a scoping conversation. In practice it is the moment the programme is built.
I tend to ask the same seven questions in that meeting. The answers are almost always incomplete. That is fine. The point is to find out which answers are missing.
- What triggered the remediation?
- What population is in scope, and on whose authority?
- What is the cut-off date?
- What does a completed file look like, and who has signed that definition?
- What does the firm think the volume is, and what does the data think it is?
- What governance already exists, and who is sitting on it?
- What has been promised to the regulator, and in what document?
If those questions can all be answered precisely in the first hour, the programme is in unusually good shape. They rarely can. The work of the first month is to make sure each of them has an answer that is documented, agreed and capable of surviving a Steering Committee challenge.
Defining scope: in, out, and on what authority
Scope drift is the most common reason a remediation programme overruns. The drift almost always begins in week one, when the in-scope population is described in conversation but never written down.
Scope needs to be defined in three layers, and each layer needs a written owner.
The first layer is the population: which legal entities, which product lines, which customer segments, which jurisdictions. The second is the trigger date: the cut-off after which a relationship is considered. The third is the deficiency: which control failures the programme is fixing. A programme that remediates incomplete source-of-funds evidence is not the same programme that remediates missing UBO documentation, and the Steering Committee needs to know which one it is approving.
When the scope is written down, I ask the sponsor to read it back to me and tell me what is not in it. That conversation usually surfaces the relationships the firm was quietly hoping would be excluded. Those are the relationships the regulator will ask about first.
Estimating volumes: twice
Volume estimates produced by extracting the customer master against a few risk filters are almost always wrong. They are wrong because the data engineer was given the filters before the scope was agreed.
I estimate volumes twice. Once from the data, with explicit filters tied to the agreed scope. Once from the policy, by walking through the in-scope segments and projecting what proportion will actually require review. The two numbers rarely match. The gap is where the early conversations need to happen.
The gap is also where the regulator will eventually look. If the data-driven estimate produces forty thousand files and the policy-driven estimate produces fifty-five, the difference is fifteen thousand customer relationships that someone has implicitly excluded. The Steering Committee should know which fifteen thousand, and why.
The volume I plan against is not the smaller of the two estimates and not the average. It is the larger, until the gap between them is reconciled in writing.
Designing the governance before hiring the team
Remediation programmes that begin by hiring reviewers and end by hiring governance are programmes that have ceded the most important decisions to whoever happens to be in the room. The order is the other way round.
Three forums are needed and they are not interchangeable.
The Steering Committee is the decision-making body. It owns scope, prioritisation, risk acceptance, escalation thresholds and completion criteria. It meets fortnightly at the start of the programme and monthly once delivery is stable. The MLRO sits on it. So does the Executive sponsor. So does whoever owns the customer relationship, because they will be needed when a closure decision is made.
The Programme Management Office is the operational body. It owns the plan, the resource model, the dependencies, the risk log, the issue log and the management information pack. It meets weekly. It is not the place where scope is changed.
The workstream stand-ups are where the daily work is run: file allocation, quality findings, escalations, blockers. They are short, factual and produce the data that feeds the PMO and, in turn, the Steering Committee.
If the three forums are not clearly separated, the Steering Committee ends up debating individual files and the workstream stand-ups end up debating scope. Both forums then fail at the work they were designed to do.
Ownership: who decides, who informs, who escalates
Every decision a remediation programme will make can be written down in the first month. I do this on a single page. It lists, by decision type, the named individual who owns the decision, the named individual who provides the recommendation, the named individual who must be informed, and the threshold above which the decision escalates.
The decisions worth naming are not the obvious ones. They are: who can close a file with a residual issue, who can authorise an exit, who signs off a risk acceptance, who approves a deviation from the file standard, who can pause a workstream, and who can change the in-scope population. If any of those decisions are unowned in the first month, they will be made later under pressure by whoever feels most senior in the room.
Reporting cadence and the management information pack
The first Steering Committee should not be the first time the management information pack is presented. The pack should exist by the end of week two, populated with whatever the data can support, even if half the fields are flagged as estimates.
The pack I work from has eight pages. Programme summary on one page. Scope, volume and forecast on another. Progress by risk segment. Quality assurance findings and themes. Escalation summary. Programme risk register. Resource and capacity. Decisions required from the Steering Committee, with options.
The last page is the one that is missed most often, and it is the one that determines whether the Steering Committee adds value. A Committee that is not presented with named decisions and options will discuss progress in general terms and approve nothing in particular.
Prioritising customer populations
Risk-based prioritisation is a phrase that is much easier to write than to deliver. In practice, the order in which customers are reviewed is the most consequential design decision in the programme, and it is the one that most often gets handed to the operations team because nobody else wants to own it.
I take the in-scope population and apply three lenses to it. The first lens is residual financial crime risk, before any remediation activity: PEPs, high-risk jurisdictions, complex ownership structures, unexplained activity, prior internal escalations. The second lens is regulatory visibility: the customers the supervisor is most likely to sample if it inspects mid-programme. The third lens is operational dependency: the customers whose files are needed to unlock related work elsewhere in the firm.
The three lenses do not always agree. When they do not, the Steering Committee decides, in writing, which one wins. That decision is what risk-based sequencing actually looks like once it leaves the policy document.
Complex and escalated cases
Every remediation programme has a long tail of files that the standard process cannot close. They are the ones with the trust structures, the politically exposed individuals connected through intermediaries, the historical SAR activity, the legal hold notices, the unresolved adverse media. The standard reviewer cannot close them, and they should not try.
A complex case panel is established by week three. It is a small, named group: the MLRO or deputy, the head of the second line, a senior reviewer, and an external view when one is helpful. It meets weekly and works to a documented framework that records the file reference, the issue, the options considered, the decision and the rationale. Every file the panel closes leaves a paper trail that a supervisor can read.
The panel is also where the firm learns. The patterns it sees feed back into the file standard, the training material and the management information themes. Programmes that route complex cases through the standard queue lose that learning, and they tend to lose the cases as well.
Quality assurance: the standard, before the work
Quality assurance introduced in month four against work performed in months one to three creates rework at scale. The cost of that rework is not only the time to redo the files. It is the loss of credibility with the Steering Committee, because the volumes that were reported as complete now have to be reclassified.
Four documents need to exist before the first file is opened. The file standard, with the evidence required for each control point. The sampling plan, with the percentages and the risk weighting. The rework protocol, describing what happens when a file fails QA and how that affects reviewer calibration. The calibration cadence, describing how reviewers and QA are aligned on edge cases as they emerge.
None of these documents needs to be long. They need to exist, be agreed and be in use.
Management information: activity, quality and residual risk
Three families of MI matter. Activity tells the Steering Committee what has been done. Quality tells it whether what has been done is defensible. Residual risk tells it whether the firm is materially safer than it was at the start of the programme.
The mistake I see most often is reporting only the first family. Volumes are easy to count, so they are reported every week. Quality is harder, so it is reported monthly if at all. Residual risk is hardest, so it is reported in narrative form, if at all.
The Board needs the third family more than the first. A programme that has completed seventy per cent of its files but cleared only thirty per cent of its highest-risk relationships is not seventy per cent done. The MI should make that visible.
Reporting to the Board
Board reporting on remediation is a different document from the management information pack. It is shorter, it is written in plain English, and it is built around the decisions the Board needs to take.
The format I use is three pages. The first page summarises the position: scope, progress against the highest-risk segments, headline quality findings, forecast against the regulatory commitment, and a residual risk view. The second page describes the issues the Board needs to be aware of, with the action being taken and the owner. The third page sets out the decisions the Board is being asked to make, with options and a recommendation.
If the Board does not see options and a recommendation, it will not make decisions. It will receive reassurance instead, which is what most remediation programmes mistakenly provide.
Programme risks and dependencies
The programme risk register is not the same as the firm's financial crime risk register. It records the risks to the programme itself: a key supplier failing, a regulatory inspection landing mid-delivery, an attrition wave in the reviewer pool, a system change that affects the data, a parallel transformation programme reaching a milestone that disrupts ours.
Dependencies are tracked alongside. The two most common dependencies that derail remediation programmes are the customer outreach process and the data quality fixes that the operations team is delivering in parallel. Both are owned outside the remediation team, both are critical, and both will slip silently if the PMO does not track them as named risks with named owners.
Completion criteria
A programme without written completion criteria does not finish. It tapers.
Completion criteria are agreed in the first month. They cover scope completion (every in-scope customer reviewed against the file standard), quality completion (a defined QA pass rate sustained across the final two months), residual risk completion (no unacceptable residual risk outside agreed risk acceptances), governance completion (every Steering Committee decision actioned and recorded), and remediation of root causes (the controls that allowed the issue to arise are demonstrably fixed).
The criteria are signed off by the Steering Committee. They are reviewed at the midpoint. They are not amended quietly.
Close-out and handover
Close-out is not a meeting. It is a document, a handover and a post-implementation review.
The close-out document records the final position against each completion criterion, the residual risks accepted, the operational changes the firm has made, and the lessons that should travel into the next supervisory engagement. The handover transfers the management of any remaining work, including risk acceptances and outreach tails, to a named owner in the business as usual organisation. The post-implementation review, which I prefer to chair independently when the engagement allows, examines what worked, what did not, and what should be different next time.
Done in that order, the close-out leaves the firm with a programme that finished and a record that a supervisor can read. Done without that order, the programme tapers and the lessons travel only in conversation.
Final thoughts
A remediation programme is not a file review exercise that has been scaled up. It is a governance programme that happens to use files as its unit of work. The decisions that determine whether it succeeds are taken before any file is opened.
The first ninety minutes set the direction. The first month builds the architecture. The first three months prove the model. Everything after that is execution against a design that has either been done well or done loosely. The cost of doing it loosely is paid in month nine, when the regulator asks a question the programme cannot answer.
Guide 004 is the longer version of this article. If you are about to start a programme, or if you have inherited one mid-flight, download it and work through the fourteen sections before your next Steering Committee.
