The silent crisis in compliance architecture

Figures that speak for themselves

In many transaction monitoring systems, between 95 and 99% of the alerts generated are false positives. In other words, the vast majority of analyst time is spent processing signals that teams know, before they even open the file, will not reveal any genuine risk. An estimated 60 to 70% of this time is absorbed by collecting and reconstructing data, not by the analysis itself. At the same time, the average cost of compliance has quadrupled since 2010, with no proportional gain in the effectiveness of risk detection. These figures, far from being anomalies, describe the operational normality of many institutions. They are the measurable symptoms of a compliance architecture under strain.

A model built by accumulation

Compliance architecture describes how data, decision processes, and evidence are structured and connected across an institution's compliance systems. When that architecture is weak, every individual tool can perform well while the system as a whole underdelivers. This is precisely what has happened across the industry.

The situation results neither from a lack of rigour nor from institutions being indifferent to their obligations. It is the direct consequence of a way of building compliance systems founded on accumulation. With every crisis, every sanction, every new regulatory wave, the response was rational in the short term: one more tool, a dedicated team, an added control in the process. Over twenty years, this logic has produced architectures no one would have deliberately designed: juxtaposed building blocks, locally optimised but rarely aligned within an overall vision.

The same symptoms can be seen everywhere: sanctions screening systems that do not talk to transaction monitoring engines, siloed KYC databases that ignore core banking data, adverse media tools disconnected from client reference data, workflows that require re-keying into one system what another has just produced. Each block was designed to meet a specific requirement, often under time pressure, without the overall architecture ever being truly rethought. This additive model held up for a long time, but it is now reaching its structural limits.

The five breaking points saturating the system

Five operational dysfunctions, taken together, characterise this silent crisis in compliance architecture.

1. Manual onboarding. Documents collected by email, data entered several times into separate systems, verifications spread across teams that do not always share the same view. The information collected at the start of the relationship feeds little, if at all, into the subsequent stages of the compliance cycle.
2. Noisy detection. Detection systems calibrated according to a cautious logic, better too many alerts than too few, produce noise rather than knowledge. False positive rates remain structurally high, teams become saturated, and vigilance declines precisely where it should be concentrating on complex cases.
3. Dispersed data. The information needed for a complete risk analysis is scattered across onboarding platforms, KYC databases, transaction monitoring systems, screening solutions, and case management tools.
4. Proof that is difficult to produce. When a supervisor asks for the decision chain leading to the closure of an alert to be reconstructed, teams spend days gathering elements spread across inboxes, directories, and scattered comments. This difficulty is not merely a documentation problem. It reveals that decisions were never really traced within an architecture designed for proof.
5. Regulatory inflation. Each new obligation (AMLA, DORA, beneficial ownership transparency, ESG risks) layers itself onto this saturated architecture, generating additional work without correcting the underlying inefficiencies.

A problem of compliance architecture, not volume

Taken in isolation, each of these dysfunctions may seem solvable with more resources, more tools, or more controls. Together, they form a self-reinforcing system. Fragmented onboarding produces incomplete data, which degrades detection quality, which overloads teams, who no longer have time to trace their decisions, which makes auditability difficult. The classic reaction, recruit, add a tool, adjust a few thresholds, treats the symptoms but reinforces the structural complexity that produces them.

The heart of the problem is no longer a deficit of formal compliance, nor even a shortfall of effort. It lies in a compliance architecture designed by reaction rather than by design. In a financial system characterised by the speed of flows, the complexity of digital infrastructure, and the growing opacity of corporate structures, a model built by accumulation is structurally behind. A system that is not designed to resist will be designed to be exploited. As long as the systems remain fragmented, criminal organisations exploit not only the gaps, but the very performance of the financial system.

Toward an architecture of risk

Doing it differently means thinking of compliance no longer as a peripheral control function, but as an architecture of risk structured around three layers: data, decision, and proof.

1. The data layer organises identities, relationships, transactions, and events into a unified representation.
2. The decision layer structures the processes of analysis and adjudication.
3. The proof layer preserves the elements needed to reconstruct each decision.

Together, they form a compliance architecture designed for proof from the start.

Conclusion

This shift in perspective is at the heart of the executive morning session "Compl.IA.nce as a Service: Building Architectures of Trust in the Era of Operational AI" on 30 June in Paris. The aim there will not be to present yet another tool or yet another AI initiative, but to show how to rebuild compliance decision chains to make them industrialisable, supervisable, and orchestratable in a real-time environment. The silent compliance crisis will not be resolved through marginal adjustments. It calls for a different compliance architecture.

Frequently asked questions about compliance architecture

What is compliance architecture

Compliance architecture is the way data, decision processes, and evidence are structured and connected across an institution's compliance systems. It determines whether information collected at onboarding flows through to monitoring, whether decisions can be traced, and whether proof can be produced on demand. A strong architecture makes individual tools more effective. A weak one undermines them all.

Why do transaction monitoring systems generate so many false positives?

Most detection systems are calibrated according to a cautious logic: better too many alerts than too few. Combined with fragmented data that gives each system only a partial view of the client, this produces false positive rates of 95 to 99% in many institutions. The cause is architectural, not a matter of tuning individual thresholds.

How does improving compliance architecture differ from adding more tools?

Adding tools treats symptoms: each new solution covers a specific requirement but adds another silo to maintain and reconcile. An architectural approach instead redesigns how data, decisions, and evidence connect across the whole compliance cycle, so that information captured once serves every subsequent step.

What are the three layers of an effective architecture of risk?

The data layer unifies identities, relationships, transactions, and events into a single representation. The decision layer structures analysis and adjudication processes. The proof layer preserves everything needed to reconstruct each decision for supervisors and auditors.

Harmoney offers a cutting-edge digital platform that streamlines intricate onboarding and compliance procedures, featuring automated screening functionalities. Interested in discovering more about our innovative solution? Reach out to us for further details or stay in touch via our newsletter ⬇️.