TL;DR: Identity verification software must balance compliance evidence and customer completion, according to OneID, because onboarding flows decide whether a user finishes in seconds or abandons the sign-up. The governing question is not whether verification exists, but whether the check is proportionate, auditable, and fast enough to preserve conversion.
At a glance
What this is: NHI Mgmt Group's analysis, drawing on OneID's blog post: Identity verification software for KYC is framed as a choice between compliance assurance and onboarding completion, with API integration and reusable identity doing most of the practical work.
Why it matters: IAM, KYC, and fraud teams need to treat verification as a governed control point, because the integration pattern, assurance level, and audit trail all shape both regulatory defensibility and customer drop-off.
By the numbers:
- The Financial Conduct Authority fined Barclays a combined £42 million over failings in financial crime risk management, including weaknesses in information gathered at the start of customer relationships.
Context
Identity verification is the control that decides whether a new customer can be trusted enough to enter a regulated digital journey. In practice, that means checking evidence, validating it, and linking it to the person presenting it before money moves or access is granted.
The problem is not just accuracy. If the verification step is too rigid, too slow, or too hard to complete, users abandon the flow and the business loses sign-up revenue before the onboarding process is finished.
That makes verification architecture a governance choice, not just a product choice. Teams have to balance assurance, evidence quality, and user completion in the same control point.
Key questions
Q: How should security teams handle identity verification during login for regulated applications?
A: Security teams should treat login-time verification as a gating control for high-risk access, not as a cosmetic check. The process should be policy-driven, fail closed when verification is incomplete, and produce audit evidence that ties the user, the check, and the access decision together.
Q: Why do identity verification journeys lose sign-ups?
A: They lose sign-ups when the verification step is harder or slower than the customer expects. Long forms, poor method coverage, repeated rechecks, and jarring handoffs all create abandonment. If the customer cannot finish quickly, the control may be compliant in theory but commercially ineffective in practice.
Q: What do teams get wrong when they compare verification providers?
A: They often compare product features without comparing governance outputs. The stronger test is whether the provider is certified, what level of confidence each method meets, what evidence trail it returns, and whether the result can be reused. Those factors determine whether the control is defensible and scalable.
Q: What is the difference between hosted and embedded verification?
A: Hosted verification sends the user to a provider-run journey, while embedded verification keeps the flow inside your own product through an API and SDKs. Hosted is faster to ship, embedded gives more control over experience, and orchestration can combine methods from one integration when different users need different routes.
Technical breakdown
How verification APIs fit into a KYC flow
An identity verification API is the machine interface that lets an onboarding system ask a verification service to check a person’s evidence and return a result. The service may run multiple methods behind the same request, including document checks, bank-verified identity, or digital wallet credentials. The important design point is that the API does not simply say yes or no. It returns verified attributes and an evidence trail, which lets the calling system make a policy decision and retain defensible proof of how that decision was reached. See the Identity Proofing and KYC Guide.
Practical implication: Define the decision boundary between the verification service and your own due-diligence workflow before integration begins.
Why integration pattern changes completion rates
Hosted, embedded, and orchestrated verification are different control patterns, not just different UX styles. Hosted flows minimise build effort by moving the user into a provider-run journey, while embedded SDKs preserve more of your own product experience. Orchestration adds a routing layer that can select a method based on user context, which matters when one method will not work for every population. The technical distinction is that orchestration expands reach without changing the single integration point your product owns. See the Identity Verification Buyer's Guide.
Practical implication: Match the integration pattern to your conversion risk, not only to your engineering preference.
How assurance levels map to risk in regulated onboarding
GPG45 confidence levels are a policy mechanism for matching identity assurance to the risk of the journey. Low, medium, high, and very high are not universal product settings. They are a way to express how much confidence the organisation needs that the identity is genuine, valid, and linked to the person presenting it. In regulated onboarding, the higher the impersonation or fraud risk, the stronger the assurance requirement. That means the same software can support different journeys if the service lets you tune the level per use case. Read the Ultimate Guide to NHIs: Standards.
Practical implication: Set assurance levels per journey and avoid forcing one threshold across all onboarding use cases.
Breaches seen in the wild
- Coupang Signing Key Breach: Unrevoked signing key credentials expose 33.7 million records after employee offboarding failure at Coupang.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Verification is a governance control point, not a checkout feature. The article frames identity verification as a place where compliance evidence and customer completion collide. That is the right mental model for regulated onboarding: the control has to satisfy the regulator, but it also has to keep the customer inside the journey. Teams that treat verification as a standalone technical widget usually underweight the business cost of abandonment and overweight the elegance of the integration.
Assurance without completion is not operationally useful. A highly stringent check that users cannot finish is a broken control, even if it is technically defensible. In identity programmes, control value depends on whether the check can be executed in the real onboarding path. The practical implication is that assurance design and conversion design need to be reviewed together, not in separate workstreams.
Reusable identity shifts the economics of trust. Reverification on every return visit turns trusted identity into repeated friction. When a prior verified result can be reused, the organisation reduces repeated evidence collection while preserving an auditable trail. That changes the economics of onboarding and makes orchestration more than a convenience feature. It becomes a governance mechanism for reducing unnecessary repetition without lowering the assurance bar.
Regulated identity programmes should score evidence, not just vendor features. The useful questions are about certified status, assurance level, coverage, audit trail, and whether the result can be reused across journeys. Those are the properties that determine whether the control can stand up under the Money Laundering Regulations and still support commercial growth. The implication for practitioners is to compare providers on governance outcomes, not interface polish.
What this signals
Completion is now a control requirement, not a marketing metric. Teams that optimise only for assurance will often build a flow users do not finish. The practical signal is to measure verification as a governed journey, where method coverage, audit trail, and drop-off rate belong in the same review.
Reusable identity is the most underused friction reduction lever in regulated onboarding. If a customer has already proved who they are, forcing a second full check adds cost without adding equivalent assurance. The programme implication is to reserve repeated verification for materially different risk contexts, not for routine returns.
For practitioners
- Define the control boundary for regulated onboarding Document exactly which identity checks sit inside the verification service and which due-diligence decisions remain with your own workflow.
- Score providers on assurance and completion together Use the same evaluation sheet for GPG45 confidence, audit trail quality, method coverage, and drop-off performance.
- Choose the integration pattern by journey risk Use hosted flows for low-complexity paths, embedded SDKs where brand control matters, and orchestration where user populations need multiple verification methods.
- Set per-journey assurance levels Assign low, medium, high, or very high confidence based on the fraud exposure of each onboarding journey rather than applying one default threshold.
Key takeaways
- Identity verification is both a compliance mechanism and a conversion point, so teams have to govern evidence and completion together.
- The strongest provider comparison is based on certified assurance, audit trail quality, method coverage, and reuse, not feature count.
- Integration pattern and assurance level directly affect whether onboarding succeeds, so both belong in the selection decision.
Related NHI Mgmt Group resources: Identity Proofing and KYC Guide · Identity Verification Buyer's Guide · NHI Lifecycle Management Guide · Ultimate Guide to NHIs: Regulatory and Audit Perspectives
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 addresses the attack surface, NIST SP 800-63 sets the technical controls, and GDPR defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | Identity verification is the assurance step that prevents weak onboarding authentication from admitting the wrong person. |
| NHI-10 — Human Use of NHI | The article centers on human identity verification performed through non-human service workflows and APIs. | |
| Recommendation — Map onboarding verification to NHI-04 and require methods that confirm the claimant's identity with defensible evidence. Treat verification services as governed identity workflows and document how humans interact with automated checks. | ||
| NIST SP 800-63 | SP 800-63A — Enrollment and Identity Proofing | The topic is fundamentally about proofing and enrolling an identity during onboarding. |
| Recommendation — Use SP 800-63A to align proofing strength with the risk of the onboarding journey. | ||
| GDPR | Art.32 — Security of Processing | The article discusses identity data handling, minimisation, and evidential processing during verification. |
| Recommendation — Apply Art.32 controls to protect identity data collected during verification and keep processing proportionate. | ||
Key terms
- Identity Verification API Call: A cloud API request used to confirm which identity is currently authenticated. In AWS, this kind of call can help both defenders and attackers validate whether a key is live, so unusual use can indicate credential testing, automation, or abuse preparation.
- Kyc flow: A KYC flow is the sequence of checks used to establish a customer’s identity and risk level before allowing access to regulated services. In iGaming, it usually combines document checks, non-document signals, and behavioural review so the operator can balance conversion with compliance.
- GPG45 Confidence Level: A GPG45 confidence level is the assurance target assigned to an identity check based on the risk of impersonation or fraud. It helps an organisation choose how strong the verification process needs to be, rather than applying one fixed standard to every onboarding journey.
- Reusable Identity: Reusable identity is a verification model that allows an identity proof to be used again across multiple platforms or journeys. It can reduce repeated document collection, but it also requires clear governance for revalidation, revocation, and jurisdictional boundaries so trust does not become portable without control.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on October 28, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org