Stack or orchestrate: why adding more checks no longer reduces risk

The multilayer illusion

Each layer of a multilayer system runs on its own logic, with its own thresholds, scores and rules. Results sit side by side, rarely correlated. The final decision then rests on implicit trade-offs, made by an analyst mentally weighing six heterogeneous outputs.

Those trade-offs are rarely documented. They are hard to explain. And they hold up poorly under regulatory scrutiny.

The problem runs deeper than ergonomics. Contemporary fraud is designed to pass unit-level checks. A valid document, a compliant selfie, a silent external database, seemingly normal behaviour. Each signal reassures on its own. Together, they can conceal a structural inconsistency that no single layer sees, because no single layer looks at the whole picture.

The real cost of stacking

A fraud getting through is the visible failure, and the rarest. The everyday cost runs in three directions, which is why it is rarely added up.

1. False positives. Each layer adds its own noise without necessarily improving overall discrimination. Teams work through numerous, sometimes redundant alerts at the expense of genuinely risky cases. The system becomes expensive and time-consuming without a proportional gain in effectiveness. This is why reducing false positives is rarely solved by adding another detection tool.
2. Loss of purpose. When checks become an end in themselves, they lose their strategic value. The point of KYC is not to run the maximum number of verifications. It is to produce a reliable, explainable decision about how much trust to place in an identity.
3. The evidence gap. This is the most underestimated cost, and the one the Anti-Money Laundering Regulation (AMLR) will expose. When a decision rests on the sum of heterogeneous results, it becomes very hard to explain why an identity was accepted or rejected. An organisation can show it holds many tools. It struggles to demonstrate how their combination lets it actually control the risk. That gap between holding tools and producing defensible KYC decisions is precisely what AMLR requires institutions to demonstrate.

What defensible KYC decisions actually require

A defensible KYC decision is one an institution can reconstruct and justify after the fact: which signals were considered, how each was weighted, which rule was applied, and why the outcome follows from them. Holding the evidence is not the same as being able to defend the conclusion drawn from it.

The mechanism that produces one is orchestration: interpreting the signals from different identity checks in relation to one another rather than in isolation, to reach a single weighted and traceable level of trust. It is not about adding another layer. It is a change of logic, moving from a juxtaposition of checks to a coherent, decision-oriented reading of signals, assessed in light of context and risk profile.

Three practical consequences follow.

1. The value of a check becomes relative. A compliant document strengthens trust when it is consistent with the other elements. It weakens trust when it contradicts behavioural or relational signals. The same signal can therefore reinforce confidence in one situation and undermine it in another.
2. Signals stop being binary verdicts. They become contributors to an overall trust level, with explicit weightings and traceable decision rules. That explicitness is what makes the proportionality required under the Anti-Money Laundering Regulation genuinely operable rather than declarative.
3. Time enters the model. Every significant event, a change of contact details, a sensitive request, a governance change, a behavioural break, becomes an occasion to re-examine the identity entity. Trust becomes dynamic, able to strengthen or weaken in an explainable way.

Orchestration does not oppose existing layers. It gives them their meaning back. A signal is no longer evaluated for itself, but for what it contributes to the overall understanding of the entity.

The loop that is almost never closed: verification and authentication

Dynamic trust has a precondition: the moment an identity is established and every moment after it have to stay connected. They are routinely treated as the same thing.

• Identity verification answers: who are you? It happens at onboarding and establishes an initial truth, based on documents, declarative data and sometimes biometric checks. It is a one-off process, centred on static information.
• Authentication answers: are you still that person? It happens afterwards, throughout the relationship, based on credentials, biometric factors or dynamic mechanisms. It is a continuous process.

The two are sequential and interdependent. Without verification, authentication rests on a fragile foundation. Without authentication, verification becomes inoperative from the first login onwards. The EBA guidelines on remote customer onboarding already expect institutions to treat the reliability of the initial verification and its later reuse as one question, not two.

Yet in most existing architectures they live in separate worlds. Verification belongs to compliance, authentication to access security. Those worlds rarely intersect, and when they do it is usually because of an incident. That functional no-man's-land is exactly where post-onboarding fraud settles. A user who logs back in six months later is authenticated by a one-time code or a fingerprint, but no mechanism confirms it is still the person whose identity was established at onboarding.

Closing the loop requires three conditions:

1. anchoring the authentication method at the exact moment of verification,
2. maintaining continuity of that hardware anchor so an uncontrolled device change is treated as a risk signal rather than a technical incident,
3. and traceability linking every authentication back to the initial verification.

A model that combines the three turns authentication into identity confirmation, which is exactly what perpetual KYC is meant to produce. Verification and authentication are not two sequential projects. They are a single architecture, either designed together or rebuilt later at high cost.

Reliability equivalence: the question behind eIDAS

What reliability equivalence actually means

A common misunderstanding holds that the rise of eIDAS 2.0 will mechanically exclude other identification methods. That is inaccurate, and contrary to the spirit of the regulation.

Reliability equivalence means a solution not notified under Regulation (EU) 2024/1183 remains fully usable, provided it achieves the same objective: establishing a reliable, independent, risk-proportionate identity based on verifiable, traceable attributes. AMLR judges a system by its actual effectiveness, not its label.

That freedom comes at a price. Unlike notified methods, whose assurance level is recognised under a European framework, a non-notified solution directly engages the responsibility of the organisation using it, through vendor assessment, documented choices, contractual frameworks, traceability requirements and incident management. A poorly governed solution weakens the whole system, however sophisticated it is technically.

There is also an inclusion issue, rarely mentioned. Not every profile, geography or use case allows for a notified digital identity. Excluding those situations would create unjustified access barriers. Demonstrating reliability equivalence for alternative solutions is what maintains a high level of vigilance alongside equal treatment.

Designing for the EUDI Wallet without making it a prerequisite

The practical posture is neither wait-and-see nor rushed anticipation. Member States must make the European Digital Identity Wallet available by 24 December 2026, and regulated private actors including banks must accept it from 24 December 2027, as set out on the European Commission's EUDI Regulation page. Rollout will be uneven, so the period ahead is one of coexistence rather than cutover. The answer is to design an identity orchestration layer now that reserves a place for hardware attestation and certified attributes without making them a prerequisite. When the wallet becomes available for a customer segment, it slots in as one more source in a system already built to accommodate it. For the technical detail of how those attestations are structured, the EUDI Wallet Architecture and Reference Framework is the reference.

A high-assurance identity provides strong proof at a given moment. On its own it says nothing about the coherence of the entity over time. An entity can be perfectly authenticated and still be exploited fraudulently six months later. The organisations that understand this do not ask whether to go eIDAS or non-eIDAS. They ask whether their system produces a reliable, traceable, proportionate decision whatever the entry-point layer.

The architecture behind defensible KYC decisions

Four properties, regardless of the technology chosen.

• Signals converge on a single entity repository that reconciles natural persons, legal entities, directors and beneficial owners. Contemporary fraud schemes specifically exploit the gaps between KYC and KYB.
• Weightings are explicit. Each layer contributes to the trust level in a documented proportion, not through an analyst's mental trade-off.
• The decision is a traceable, timestamped event, linked to the signals that grounded it and the rule applied.
• The model is built to evolve. New sources are added, weightings adjust, rules change, without rebuilding the whole system.

This is what the multilayer approach forbids and orchestration makes possible: defensible KYC decisions, and risk control that is robust, proportionate and demonstrable at the same time. It is also what turns the diversity of identification methods into an advantage rather than a source of complexity. Harmoney's AI orchestrator, for example, is built around these four properties.

Conclusion

Adding a seventh check to a stack of six will not close the gap that the six already leave open. The shift that matters is not technological but doctrinal: from collecting verifications to producing decisions that can be explained, weighted and defended. Orchestration is what makes that shift operable, and defensible KYC decisions are what will separate institutions that can demonstrate control of their identity risk from those that can only show a list of tools.

One last step remains. Orchestration that is not measured stays an intention.

Assessing whether your current architecture can demonstrate its identity decisions, and not only perform them, is the practical starting point. The full analysis sits in the white paper written with ShareID, Trustfull and ID Protect: the complete identity-entity model, from reconciling signals into a single entity record to making weightings and decision rules explicit enough to hold up under AMLR and eIDAS 2.0.

Frequently asked questions about defensible KYC decisions

What is a defensible KYC decision?

A defensible KYC decision is one that can be reconstructed and justified afterwards, showing which signals were considered, how they were weighted and which rule was applied. It connects the signals from different checks into a single, weighted, traceable level of trust rather than a juxtaposition of independent results.

Why does adding more KYC checks increase false positives?

Because each layer adds its own noise on its own logic, without the results being correlated. Overall discrimination does not improve in proportion to the number of checks, while the volume of alerts does. Teams then spend more time on redundant alerts and less on genuinely risky cases.

What is the difference between identity verification and authentication?

Verification establishes who the person is at onboarding, based on static information. Authentication confirms, throughout the relationship, that it is still the same person, based on dynamic data. One creates the reliable identity, the other sustains it over time.

Can non-eIDAS identity solutions still be used after 2027?

Yes. AMLR enshrines a regulated technological neutrality. Non-notified methods remain usable as long as their reliability level is equivalent and demonstrated, which engages the responsibility and governance of the organisation relying on them.

Do defensible KYC decisions require replacing existing verification tools?

No. Orchestration does not remove layers, it relates them to each other. Existing document verification, biometrics and database checks keep their role, but each signal is assessed for what it contributes to the overall understanding of the entity rather than judged in isolation.