Why Large-Scale KYC Remediation Programmes Fail 

Overview

Large-scale KYC remediation programmes often look straightforward on paper: identify the customer population, review the files, address deficiencies and update the target system. 

In practice, they can become some of the most complex programmes within a financial institution. 

The reason is simple. KYC remediation is rarely just a compliance exercise. It sits at the intersection of risk, regulation, data, technology, operations and programme delivery. When thousands of customers and tens of thousands of accounts are involved, weaknesses in any one of these areas can quickly affect the entire programme. 

So why do large-scale KYC remediation programmes struggle? 

1. Treating remediation as a volume problem 

A common response to a large KYC backlog is to increase the number of analysts reviewing files. 

But more people do not necessarily solve the underlying problem. 

If teams are working with inconsistent processes, unclear remediation rules or poorly understood customer populations, increasing headcount can simply increase the volume of inconsistent decisions. 

Before scaling delivery, institutions need to understand the population: customer overlaps, existing KYC files, risk assessments, system mappings and the relative priority of different remediation groups. 

This is why Brickendon’s approach starts with discovery and prioritisation, rather than immediately moving into mass remediation.  

2. Underestimating differences between KYC systems 

KYC platforms do not necessarily store or interpret information in the same way. 

Looking across the clients we have worked with to remediate KYC files, one thing is clear: every organisation is different. Some use standard implementations of established vendor platforms such as Fenergo, Nice Actimize or SAS, while others operate highly customised versions of vendor systems. Others have built bespoke platforms, often developed before many of today’s more advanced vendor solutions became available. Across all these scenarios, there are differences in how KYC data is captured and stored, including structured data fields, data formats and free-text information.  

This matters because KYC remediation isn’t simply about pumping data into a system. The data needs to be understood, mapped and assessed against the requirements of the specific remediation process identified for that client. Where information cannot be mapped cleanly, manual remediation and varied workflows may be necessary. 

Without sufficient analysis upfront, these differences often emerge during execution, when they are considerably more disruptive and costly and can negatively impact the client experience. 

3. Different data sets and client files create different remediation challenges 

Technology is only one part of the challenge. 

KYC client files can contain very different data sets depending on when they were created, and which system and processes were  used to create them. Historically the organisation may have held structured and complete customer information, while at another time they may have relied on different data fields, formats, supporting documentation or free-text information. 

This creates an immediate challenge: how do you determine what information can be accepted, what needs to be requested and what can be created for other sources?  

Analysts need to identify gaps, inconsistencies and differences between the existing client file and the requirements. Some information may map directly, while other data may need to be validated, supplemented or manually remediated. 

At scale, these differences across thousands of client files can create significant additional remediation activity, making early data analysis, mapping and categorisation critical to successful delivery. 

4. Failing to identify customer overlap 

Customer duplication can create another source of unnecessary effort. 

Where customers already exist within the target system, teams first need to establish whether they are dealing with the same customer and then determine whether the underlying KYC information and risk assessments are consistent and can be applied across the various client accounts. Customer overlap analysis is a real opportunity to eliminate inefficiency, while also recognising that differences in risk ratings can require manual remediation in individual client accounts.  

Getting this analysis right early can prevent teams from unnecessarily treating existing customers or client accounts as entirely new remediation cases. 

5. Trying to design every answer before delivery begins 

Large remediation programmes inevitably uncover scenarios that were not completely understood at the outset. 

Trying to design a perfect end-to-end process before beginning execution can therefore slow delivery significantly. 

An alternative is to identify the principal scenarios, define a workflow for each and test those workflows through rapid proofs of concept on the samples of the remediation data. 

Brickendon’s approach does exactly this: we define workflows for known scenarios, implement rapid POCs, document the resulting processes and use them to create the detailed delivery workflows, update processes and implement a reliable roadmap.  

This creates a repeatable model that can then be scaled. 

6. Treating the process as static 

A remediation methodology that looks effective during planning may need to change once hundreds or thousands of real customer files begin moving through it. 

Successful programmes therefore need mechanisms for learning and refinement. 

The implementation approach outlined in the proposal uses Agile delivery against the roadmap, with processes refined daily or as required. End-of-sprint reporting and regular management “show and tell” sessions provide visibility over progress.  

The objective is not uncontrolled change. It is controlled continuous improvement. 

As recurring issues emerge, workflows can be refined so that subsequent cases are processed more effectively. 

7. Weak governance and visibility 

At this scale, management needs to understand more than how many files have been completed. 

The programme needs visibility across discovery, workflow design and implementation. 

Brickendon’s project planning methodology places programme governance and reporting across the delivery lifecycle, alongside customer-overlap analysis, KYC and model analysis, system mapping, workflow development, POCs, roadmap delivery and remediation.  

This creates a much clearer view of whether the programme is actually progressing towards completion and whether the remediation approach itself is working. 

From remediation exercise to controlled execution 

Large-scale KYC remediation programmes rarely fail because institutions don’t understand the importance of KYC. 

They struggle because complexity has been underestimated. 

Different systems, data structures, risk models, customer populations and operating processes all have to be reconciled while maintaining effective governance and continuing to deliver at scale. 

The answer is therefore not simply more remediation capacity. 

It is a structured delivery model that allows the organisation to discover the true nature of the problem, architect repeatable solutions and implement them at scale with strong governance and continuous refinement. That three-stage approach is the core methodology set out in Brickendon’s methodology.