How should security teams implement customer due diligence without creating too much onboarding friction?

Why This Matters for Security Teams

customer due diligence sits at the point where fraud prevention, AML obligations, and conversion pressure collide. If the workflow is too light, bad actors can open accounts, layer transactions, or exploit synthetic identities. If it is too heavy, legitimate customers abandon onboarding or provide poor-quality data just to get through it. Current guidance from the FATF Recommendations — AML and KYC Framework supports a risk-based approach rather than a one-size-fits-all process.

The practical mistake is treating due diligence as a single form or a fixed identity check. Security teams need a design that matches the customer segment, geography, product, transaction exposure, and fraud signals already present in the onboarding journey. That means separating policy decisions from the user experience so the control logic can change without redesigning the entire workflow. It also means defining what evidence is actually sufficient, instead of collecting extra documents because the process feels safer.

Teams often focus on what compliance can accept in theory, rather than what customers can complete in practice. In practice, many security teams encounter due diligence failures only after high-friction onboarding has already pushed legitimate users into workarounds or has encouraged staff to waive checks informally.

How It Works in Practice

Effective due diligence usually starts with risk-tiered onboarding. A low-risk customer may only need basic identity evidence, screening, and payment or contact verification. A higher-risk customer may require beneficial ownership review, source-of-funds checks, sanctions screening, or enhanced due diligence. The control objective is consistency: each risk tier should map to a defined evidence set, a defined approval path, and a defined exception rule.

Operationally, teams should separate the policy engine from the frontend journey. That allows the organisation to ask fewer questions at the start, then request additional evidence only when signals justify it. This is especially important when KYC and AML workflows are paired with fraud controls, because unnecessary document collection often increases drop-off without improving trust. The FATF guidance is useful here because it reinforces proportionality and ongoing monitoring rather than static, one-time verification.

• Define minimum evidence by risk tier, not by customer type alone.
• Use automated screening and document checks for routine cases.
• Route exceptions to human review with clear escalation criteria.
• Log why each decision was made so reviewers can explain it later.
• Reassess risk when customer behaviour, geography, or payment patterns change.

Security teams should also align this workflow with identity assurance and fraud analytics. If a customer presents strong identity evidence but later behaves like an account mule or synthetic identity, the onboarding decision should be revisited. Likewise, if the business adds new payment rails or cross-border exposure, the due diligence baseline should be updated instead of reused unchanged. Guidance from CISA resources on operational risk management is not KYC-specific, but the same principle applies: controls work best when they are targeted, measurable, and continuously adjusted. These controls tend to break down in high-volume, multi-jurisdiction onboarding flows because local legal requirements, language differences, and inconsistent manual review thresholds create process drift.

Common Variations and Edge Cases

Tighter due diligence often increases abandonment and review overhead, requiring organisations to balance stronger assurance against customer experience and operational cost. That tradeoff becomes sharper when the customer base spans retail, SMB, and enterprise segments, because the acceptable evidence burden is not the same for each.

There is no universal standard for exactly how much friction is appropriate for every product. Best practice is evolving toward adaptive due diligence, where the workflow changes based on risk signals rather than a fixed checklist. For example, a bank or fintech may apply stronger checks at account opening, while a SaaS platform with lower financial exposure may place more weight on payment verification, device intelligence, or post-onboarding monitoring.

Edge cases matter. PEPs, complex legal entities, non-resident customers, and high-risk jurisdictions typically require more scrutiny, but teams should still avoid broad overcollection. Overcollection creates privacy exposure and can make it harder to defend data minimisation decisions later. A useful reference point is the general structure of FATF Recommendations — AML and KYC Framework, but implementation should always be adapted to local regulation and product risk.

Where the organisation uses automation, review the false-positive rate and exception queue regularly. If too many low-risk cases are being escalated, the policy is probably too blunt. If too many high-risk cases are approved automatically, the model or rule set is too permissive. The right answer is not the lowest-friction journey possible, but the shortest journey that still produces defensible evidence.

Related resources from NHI Mgmt Group

• How should security teams implement just-in-time access without creating too much friction?
• How should security teams implement context-aware authentication without creating too much user friction?
• How should teams implement customer MFA without creating too much login friction?
• How should security teams implement zero trust authentication without adding too much user friction?