UK banks are facing mounting enforcement action directly attributable to failures in data quality and data systems, with the Financial Conduct Authority (FCA) and Prudential Regulation Authority (PRA) stepping up scrutiny in recent years. Since 2021, the FCA has imposed 13 fines totalling over £300 million on UK banks for anti-money laundering (AML) systems and controls failings alone.
Yet in most of these cases, the root cause was not absent governance intent. It was the failure to carry that intent through the delivery chain into production systems that worked as designed.
This means that closing the gap between policy and production is now a boardroom priority. The question is: How can it be done?
The delivery function runs from business analysts and compliance teams, who interpret regulatory requirements and define what the data must represent, through to data architects, who design the structures and standards those requirements demand. Then data engineers build the pipelines, quality controls, and monitoring that make governance real in a production system.
When requirements are interpreted without regulatory depth, the chain is weakened. When architecture does not translate design intent into implementable specifications, it is weakened again. And when engineering does not build what the architecture specifies, the governance framework fails in production, regardless of how well it is documented. This is the pattern that has been repeating across the industry.
Architects and business analysts are key to strengthening the whole lifecycle, translating regulatory definitions into data models which production systems can use to make decisions. What is an eligible deposit? What constitutes a critical data element for risk reporting? What does a suspicious transaction mean for AML purposes?
These definitions need to be reflected accurately in the underlying data models, which goes far beyond a documentation exercise. A data model is an engineering artefact. It determines what fields exist, how they are typed and constrained, what relationships hold between entities, and how those structures map to the regulatory concepts they are meant to represent.
Where models are wrong, incomplete, or not maintained as regulation evolves, the systems built on them will misclassify and misreport. This is not because of a processing failure. It is because the model encoding the regulatory definition is itself incorrect.
This is exactly what happened when a leading global bank misclassified 99% of eligible beneficiary deposits as ineligible. The regulatory definition of eligibility was not correctly represented in the data structures the system used to make that determination. A data model reviewed by architects and analysts with genuine regulatory knowledge of relevant depositor protection rules would not have produced that representation.
While good architecture and analysis are necessary, they are not sufficient alone. Regulators examine whether the controls work in production, not simply whether the design was sound.
Take the leading international bank that misreported its USD liquidity position to the PRA five times between 2018 and 2019. The PRA found that the bank did not maintain adequate controls testing for the relevant reporting pipeline and did not have a documented escalation policy for reporting errors or sufficient human resources to investigate misreporting. Put more simply, the reporting architecture existed. The engineering discipline to implement, test, and monitor it in production did not. The result was the PRA’s largest ever fine in a PRA-only enforcement case at that time – £46.55 million.
That is a costly way of finding out that data lineage does not exist because it is described in an architecture diagram. It exists because pipelines have been built to capture and store it in queryable form. The same applies to quality controls. These do not exist because thresholds are agreed in a data dictionary. They exist because validation logic has been written, deployed and is producing alerts that are actioned.
However, good engineering alone is not enough. It is domain knowledge across the delivery chain that determines whether the engineering actually works. We have seen that even institutions which have invested heavily in compliance technology run into problems. A leading global bank’s 2021 AML fine of £63.9 million was imposed despite material investment in monitoring systems during the relevant period.
The effectiveness of technology reflects the know-how of the people specifying, designing, and building it. Business analysts who understand the regulatory intent behind an AML rule write different requirements from those who interpret it at face value. Architects who understand UK financial crime risk typologies design different data models from those working from the technical specification alone. Engineers who understand how UK personal current account customers behave configure monitoring thresholds differently from those calibrating against a theoretical norm.
For instance, a major building society’s customer risk assessment framework was described by the FCA as an “unsophisticated, interim solution” that classified almost all customers as standard risk regardless of their actual behaviour.
Investment in domain expertise also has the considerable added benefit of helping to reduce operational costs, as the burdens imposed by manual reconciliation, RWA over-capitalisation and open-ended remediation programmes are all downstream consequences of the same delivery chain failure.
Ongoing regulatory risk, combined with the opportunity for significant operational efficiencies and cost savings, present a compelling business case for UK banks to take a new approach to their data estate. By investing in disciplined delivery capability, underpinned by genuine regulatory and business domain knowledge throughout the entire chain, they can close the gap between governance strategy and production reality.
Contact Icon Solutions to learn more about our data architecture, modelling, and engineering expertise.