How should organisations modernise customer onboarding without creating so much friction that legitimate users abandon the process?

Treat onboarding as a risk balancing exercise, not a pure security gate. High assurance should be reserved for regulated or high impact journeys, while lower risk commerce flows can use lighter checks. Use remote identity verification, document validation, and step-up controls only when the transaction, device, or behaviour justifies it. The goal is to reduce fraud while preserving conversion and trust.

Why This Matters for Security Teams

Customer onboarding fails when security treats every user like a highest-risk case. That creates avoidable abandonment, support calls, and shadow processes that bypass controls entirely. The better model is risk-based orchestration: match verification depth to the journey, the amount at stake, and the likelihood of abuse. This is especially important in regulated flows where the organisation must satisfy AML, fraud, and account protection obligations without making normal customers feel blocked.

NHI Management Group’s research shows how often control failures come from poor lifecycle discipline rather than lack of tools, with only 20% of organisations having formal processes for offboarding and revoking API keys and only 5.7% having full visibility into service accounts in the Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs. The same pattern shows up in onboarding design: when teams overcorrect for fraud, legitimate users are pushed into friction-heavy journeys that do not actually improve assurance.

Modern onboarding should therefore separate identity proofing, transaction risk, and session behaviour. Guidance from the FATF Recommendations — AML and KYC Framework supports proportionate controls, not blanket intensity across every user path. In practice, many security teams encounter abandonment and manual workarounds only after conversion drops and fraud teams have already tightened the process reactively.

How It Works in Practice

The operational goal is to apply verification only where it adds meaningful risk reduction. Start by classifying onboarding journeys into risk tiers based on account type, transaction potential, jurisdiction, payment method, and expected abuse patterns. Low-risk journeys can use streamlined identity signals, while high-risk or regulated flows should trigger stronger checks such as document verification, liveness testing, or step-up review.

Risk-based onboarding works best when controls are layered rather than front-loaded. A typical pattern is:

• collect only the minimum data needed at first contact;
• use device reputation, email and phone validation, and velocity checks before asking for heavy evidence;
• reserve remote identity verification for cases that cross a risk threshold;
• reassess risk continuously during the session and after first transaction;
• escalate only when behaviour, device, or transaction profile changes.

This approach aligns with identity proofing principles in the NIST ecosystem, especially when organisations need an auditable basis for step-up decisions rather than arbitrary manual review. It also benefits from learning from incidents such as the Emerald Whale breach and the CI/CD pipeline exploitation case study, both of which show how abuse spreads when trust decisions are too coarse or too static. Strong onboarding is not just about stopping fake users; it is about preserving trust signals while avoiding unnecessary customer drop-off.

Implementation usually succeeds when product, fraud, security, and compliance teams agree on shared thresholds and a single decision engine for orchestration. These controls tend to break down when legacy workflows force every applicant through the same manual review queue because the organisation cannot distinguish low-risk customers from high-risk abuse patterns.

Common Variations and Edge Cases

Tighter onboarding often increases operational cost, so organisations must balance fraud reduction against abandonment, review backlog, and regulatory exposure. That tradeoff becomes sharper in markets with inconsistent identity documents, cross-border customers, or thin-file users who cannot easily pass standard checks.

Current guidance suggests using alternative evidence and progressive verification where full document proof is unreliable, but there is no universal standard for this yet. Some organisations can accept lower initial assurance if they immediately constrain limits and require step-up verification before withdrawals, high-value transfers, or account recovery. Others, especially in financial services and other regulated sectors, may need stronger proof at the outset to meet policy and legal requirements.

Edge cases also include shared devices, family accounts, and business onboarding where one legal entity may represent many end users. In those cases, the onboarding process should distinguish between customer identity, authorised signer, and actual platform operator. The best practice is to make the first pass easy to complete, then deepen assurance only when the customer tries to unlock higher-risk capabilities. That preserves conversion without creating a blind spot for abuse.

Related resources from NHI Mgmt Group

• How should security teams implement customer due diligence without creating too much onboarding friction?
• How should businesses build transaction monitoring programs that reduce fraud without creating too much friction for legitimate users?
• How should fintech teams embed fraud controls without creating too much customer friction?
• How should organisations verify identity documents without creating too much friction?