Common signs include high onboarding abandonment, repeated document re-submission, long manual review queues, and users abandoning transactions after verification prompts. If customers pass identity checks only after multiple touches, the process is probably too heavy. Teams should also watch for inconsistent completion rates across customer segments, which often indicate that controls are not tuned to real risk.
When KYC or KYB Starts Frictioning the Customer Journey
When identity checks become too burdensome, the problem is usually not the existence of verification itself but the volume, sequencing, or repetition of checks relative to the customer’s risk and context. For KYC and KYB, that often shows up as customers stalling before completion, dropping off after a document request, or failing to understand why a “simple” account action now needs a new round of evidence.
That friction matters because it changes verification from a trust-building step into a conversion barrier. Over time, teams can mistake slow approval cycles for diligence, when the real issue is that the process has drifted away from user reality and control proportionality. In regulated environments, the challenge is to keep assurance strong enough for AML and fraud obligations without making the path to completion so heavy that low-risk customers disengage. FATF’s FATF Recommendations — AML and KYC Framework is useful context here because it frames customer due diligence as risk-based, not one-size-fits-all. In practice, many teams discover the burden only after abandonment and repeated support escalations have already become normal.
How the Burden Shows Up in Real Operations
Operational burden is easiest to spot when the same customer has to prove the same thing more than once. Repeated document uploads, duplicate beneficial ownership questions, manual exceptions for routine cases, and review queues that stretch beyond the point where customers still see value all suggest that the process has crossed from control into drag. The issue can appear in both KYC and KYB, but KYB often becomes more painful because ownership, authority, and entity structure are harder to present cleanly than a personal identity packet.
A practical way to read the signs is to look for mismatch between the control and the decision being made. If low-risk users are forced through the same high-friction path as higher-risk users, the process is probably over-applied. If completion only happens after repeated nudges, reminders, or manual intervention, the workflow likely depends too heavily on customer persistence rather than a usable design. If different customer segments complete at very different rates, that may indicate the journey is unintentionally penalising particular business models, geographies, or document types.
- High abandonment after the first or second verification step suggests the form factor is too heavy.
- Long review times for routine cases suggest too much manual handling is being used as a default.
- Frequent resubmission requests suggest document requirements are unclear or overly rigid.
- Customer complaints about “already doing this” usually signal poor reuse of verified data.
Controls should also be checked against the actual decision purpose. If a step does not materially change the risk decision, it is likely to be burden without proportional benefit. NIST’s NIST Cybersecurity Framework 2.0 is relevant at a governance level because it reinforces outcomes-based control design, while not replacing AML-specific due diligence logic. This guidance breaks down when the organisation cannot distinguish a genuinely high-risk case from a process that is simply inconvenient for everyone.
Where Proportionality Breaks Down
Tighter verification often increases assurance but also increases drop-off, so organisations have to balance regulatory comfort against customer effort. That tradeoff becomes visible when the process is technically compliant yet commercially self-defeating, especially for products that rely on fast activation or repeat customer interactions.
One common edge case is where burden is concentrated in specific segments rather than across the whole population. For example, a cross-border customer base, complex corporate structures, or customers with limited document availability may experience much higher friction even when the average journey looks acceptable. That does not automatically mean the control is wrong, but it does mean the policy may be too rigid for the operational mix. Another edge case is when teams add extra checks after a control concern without retiring earlier steps. The result is layered verification that looks thorough on paper but creates avoidable repetition.
There is also a consensus gap in industry practice: some organisations treat every extra request as acceptable if it reduces analyst workload, while others treat any meaningful delay as a sign of poor design. The better test is whether the additional step improves the quality of the risk decision enough to justify the user cost. When it does not, the burden is probably a control design issue rather than a customer patience issue. eIDAS 2.0’s EU Digital Identity Framework is relevant where digital identity re-use and trust portability may reduce repeated checks, but only where the jurisdiction and use case permit it.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0, CIS Controls v8 and NIST SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.RM-01 — Risk Management Strategy | Burdensome verification is a governance and risk-balancing issue. |
| GV.OV-01 — Oversight | Completion friction should be monitored as an oversight signal. | |
| PR.AA-01 — Identity and Access Management | Identity proofing journeys should be designed to reduce unnecessary user burden. | |
| Recommendation — Set proportional review thresholds that balance assurance with customer friction. Track abandonment, rework, and review delay metrics as control-performance indicators. Streamline identity proofing steps that do not materially change the trust decision. | ||
| CIS Controls v8 | 6.3 — Access Rights Provisioning | Overly heavy verification often reflects poor process design and manual bottlenecks. |
| Recommendation — Reduce manual handling in routine onboarding and reserve exceptions for higher-risk cases. | ||
| NIST SP 800-63 | SP 800-63-3 — Digital Identity Guidelines | Identity proofing and lifecycle assurance should be proportionate to assurance needs. |
| Recommendation — Match identity assurance steps to the required assurance level instead of defaulting to maximum friction. | ||
Practitioner Guidance
What to prioritise: focus first on the points where customers are asked to provide new evidence without a clear change in risk. That is usually where burden is created faster than value. If a step does not alter the decision threshold, it is a candidate for simplification or reuse.
What to verify: compare completion rates, resubmission rates, and manual-review delays across customer types, not just in aggregate. A process can look healthy overall while still being materially overbearing for specific segments or products. The most useful check is whether low-risk cases are being treated differently for a defensible reason.
Common mistake: assuming that more friction automatically means stronger compliance. In practice, the strongest design is usually the one that reserves the heaviest checks for the highest-risk cases and lets routine customers move cleanly through a lighter path.
Practitioner takeaway: if customers need persistence, support intervention, or repeated document churn to complete verification, the process is no longer behaving like risk-based due diligence and should be treated as a design failure, not a customer discipline problem.
Related resources from NHI Mgmt Group
- What breaks when KYB due diligence is too light for higher-risk corporate customers?
- How should organisations build KYB compliance workflows for the UK without creating unnecessary friction for legitimate customers?
- Why do KYC, KYB, and transaction monitoring need to be coordinated in fintech compliance programmes?
- What are the signs that an open source project is becoming too risky to rely on?