An identity verification and KYC platform decides who gets an account, and a rollout that trusts the provider's "approved" flag without designing the evidence, the integration and the exception path will let fraudsters in at scale while turning genuine applicants away. This playbook covers rolling out remote identity verification as a product class: setting the assurance target per journey, designing the capture and integration so results cannot be forged, protecting the identity documents and biometrics you will collect, testing performance and fairness, and launching in stages with a manual fallback. It is vendor-neutral and based mainly on NIST SP 800-63A-4, ISO/IEC 30107-3, the FATF Guidance on Digital ID and NIST SP 800-53. It is written for product owners for onboarding, fraud and financial crime teams, identity architects and privacy officers. What identity proofing is, and the obligations behind KYC, are in the Identity Proofing and KYC Guide; selection is in the Identity Verification Buyer's Guide.
Key takeaways
- Set the assurance level per journey first. The identity assurance level decides which evidence, checks and fallback routes you build; choosing it after integration means rebuilding.
- Never trust a verdict that arrives through the browser. Your back end must fetch or verify results directly from the provider, bound to the session that started the check.
- Injection attacks are now the main remote threat. SP 800-63A-4 requires controls against virtual cameras, emulators and manipulated media, not only liveness against printed photos and masks.
- You become a store of documents and biometrics. Decide retention, deletion and access for images and templates before go-live, and keep only what law and fraud investigation need.
- Design the human route as carefully as the automated one. Manual review and trusted referees handle failures fairly, and they are also where social engineering and insider collusion happen.
Phase 0: assurance targets and obligations
NIST SP 800-63A-4 defines three identity assurance levels. IAL1 validates core attributes against authoritative or credible sources and is designed to limit automated enrolment and synthetic identities. IAL2 adds stronger evidence and confirms the applicant is the genuine owner of that evidence, remotely or on site. IAL3 is on-site attended only, with a trained proofing agent and at least one biometric collected. SP 800-63A-4 also states that knowledge-based verification shall not be used for identity verification.
| Journey | Typical target (NHI Mgmt Group recommendation) | Design implication |
|---|---|---|
| Low-risk account, age or attribute check | IAL1 or attribute-only check | Validate attributes; avoid collecting documents you do not need |
| Regulated account opening (bank, payments, crypto, lending) | IAL2 with fraud checks; local KYC law sets the minimum | Document plus biometric comparison or authoritative data check; sanctions and PEP screening |
| High-value change on an existing account (new payee, recovery after takeover) | Re-verification to the original IAL | Compare against the stored enrolment, notify the existing contact channel |
| Workforce or contractor onboarding, help desk recovery | IAL2 | See the Workforce and Help Desk Identity Verification Buyer's Guide |
| Business customers (KYB) | Entity checks plus IAL2 for controllers and beneficial owners | Registry data, ownership structure, director verification |
Legal obligations depend on sector and country. The FATF Guidance on Digital ID (March 2020) asks regulated entities to take a risk-based approach and understand the assurance levels of a digital ID system before relying on it for customer due diligence. Confirm the current requirements of your own regulator with compliance before fixing the design; the Identity Proofing and KYC Guide summarises the main regimes.
Phase 1: evidence, checks and the decision model
- Evidence: SP 800-63A-4 grades evidence as FAIR, STRONG or SUPERIOR and requires a government identifier among the core attributes. Decide which document types and issuing countries you accept per market, and whether you will read the chip in ePassports and ID cards. See ePassport NFC Verification.
- Document validation: for automated document validation SP 800-63A-4 sets a document false acceptance rate and document false rejection rate of 0.1 or less, and requires live document capture and document liveness checks.
- Biometric comparison: for 1:1 matching it sets a false match rate of 1 in 10,000 or better and a false non-match rate of 1 in 100 or better, with testing to ISO/IEC 19795-1 and 19795-10.
- Presentation attack detection: remote biometric capture needs PAD tested to ISO/IEC 30107-3:2023 with an impostor attack presentation accept rate below 0.07. See the Biometric Liveness and Presentation Attack Detection Guide.
- Fraud checks: SP 800-63A-4 requires a documented fraud management programme, a death records check in all proofing processes, and lists checks such as SIM swap detection, device fingerprinting and transaction analytics. Add sanctions and politically exposed person screening where your regime requires it.
- Decision model: map provider outputs to your own outcomes (approve, refer to manual review, decline, request more evidence). Keep the thresholds in your configuration, under change control, not hard-coded in the provider's default.
Phase 2: integration architecture
The integration is where most self-inflicted weaknesses appear. Hardening of the running platform is in Securing the Identity Verification and KYC Platform Itself, and connector detail is in the Identity verification and KYC platform integration security guide.
| Design point | Weak pattern | Secure pattern (NHI Mgmt Group recommendation) |
|---|---|---|
| Starting a check | Client creates the verification session with an embedded secret key | Back end creates the session and passes a short-lived, single-use token to the client |
| Receiving the result | Browser or app reports "verified" to your back end | Back end fetches the result server-side or verifies a signed webhook, and checks it belongs to this applicant and session |
| Binding | Result looked up by email address | Result tied to your internal applicant ID and session ID; reject replays and mismatches |
| Capture | File upload of existing images allowed | Live capture only, provider SDK with device and injection checks |
| Credentials | One API key shared by all environments | Separate keys per environment and service, with owners and rotation |
| Webhooks | Unauthenticated endpoint accepting any payload | Signature verification, timestamp checks, idempotency and allow-listed source |
The SP 800-63A-4 injection controls set the bar for capture: detect virtual cameras, emulators and jailbroken devices, analyse submitted media for manipulation, test detection against known attack artefacts, and use only authenticated protected channels. Confirm which of these the provider SDK does and which fall to you. See the Deepfake-Resistant Identity Verification Guide.
Phase 3: privacy, data and the provider
- Privacy risk assessment first: SP 800-63A-4 requires a documented privacy risk assessment covering retention schedules and third-party processing, reassessed when the service changes, and a privacy risk assessment of fraud checks before deployment. In the EU and UK, biometric data used for unique identification is special category data under GDPR Article 9, and large-scale processing of it is a strong indicator that a data protection impact assessment is needed.
- Minimise: collect only the attributes the decision needs; prefer storing the outcome, document type and reference over full images where your legal retention duty allows.
- Retention and deletion: SP 800-63A-4 requires a publicly available deletion process and a default retention period for biometrics. Align provider retention with yours: images often persist at the provider unless you configure deletion.
- Notice: tell applicants at collection what is processed, by whom, for how long, and how to delete or dispute it.
- Provider due diligence: data location, sub-processors, model training on your applicants' images, breach notification terms, independent PAD and biometric test results, and exit terms for your data (NIST SP 800-53 SA-9, SR-6).
- Access inside your organisation: reviewers, fraud analysts and support should see images only when needed, with every view logged (AC-6, AU-6).
Phase 4: manual review, referees and redress
- Trusted referees: SP 800-63A-4 requires referee services for automated verification failures, training covering document checks, facial comparison and social engineering indicators, and a record of every referee session with reason, decision and rationale.
- Insider controls: the standard requires insider threat controls against collusion. Our recommendation: random assignment of cases, second review for overrides of a decline, and monitoring for reviewers with unusual approval rates.
- Redress: provide a clear way for genuine applicants who fail checks to complete verification another way, and for people to dispute a proofing event they did not start.
- Notifications: SP 800-63A-4 requires proofing notifications to a validated postal address or phone number (email only at IAL1), including the service name, date and how to dispute the event.
Phase 5: testing, fairness and staged launch
- Functional and security testing: test session creation, result retrieval, webhook verification, replay of an old result, mismatched applicant IDs, and uploads that bypass live capture. Map tests to OWASP ASVS where they touch your application.
- Attack testing: with the provider's agreement, test with printed and screen replays, virtual camera injection and altered documents, using an authorised tester.
- Performance and fairness: SP 800-63A-4 says biometric performance for any demographic group may be no more than 25% worse than the overall population and should be assessed under conditions like your real environment. Ask for evidence and measure pass rates by device type, document type and country in your pilot.
- Pilot: run on one product or market with manual review of a sample of approvals and all declines. Compare outcomes with your previous process.
- Staged launch: increase traffic share while watching pass rates, abandonment, manual review queues and early fraud.
- Rollback and outage plan: keep the previous verification route or a manual route available. Decide in advance whether onboarding pauses or continues with deferred verification and restricted account limits when the provider is unavailable.
- Incident readiness: agree how you would re-verify accounts if the provider or your integration were compromised. See the identity verification platform compromise playbook.
Decision guidance
- Document plus selfie or authoritative data checks: document and biometric flows reach IAL2 for applicants without a data footprint; data-only checks are cheaper and lower friction but weaker against synthetic and stolen identities. Many programmes use data checks first and step up to documents on risk.
- Single provider or orchestration: one provider is simpler to secure and audit; an orchestration layer adds fallback and coverage across countries, and adds one more component holding images and keys.
- Reusable or wallet-based identity: accepting verified credentials from digital identity wallets may reduce data you hold; check your regime's acceptance first. See the Digital Identity Wallet Fraud Risks Guide.
- Small versus large organisations: smaller firms should use the provider's hosted capture flow and default fraud checks and focus effort on result retrieval, retention and manual review; large firms need per-market policy, an in-house decision engine, fraud analytics and independent testing.
Detection and measurement
Log every verification session, result retrieval, override, reviewer view and configuration change, and send them to the SIEM and fraud tooling. Alert on spikes in attempts per device or IP, repeated use of the same face or document across applicants, injection detections, reviewer override bursts and threshold changes.
| Metric | Why it matters |
|---|---|
| Fraud found in verified accounts within 90 days of onboarding | Outcome measure of the whole control |
| Automated pass rate and abandonment by country, document and device | Friction and fairness signals |
| Manual review volume, overturn rate and time to decision | Whether the human route is working and not being abused |
| Injection and presentation attack detections per 10,000 sessions | Attack pressure and control effectiveness |
| Images and templates held past retention period | Privacy and breach exposure |
| Results accepted without server-side verification (target: zero) | Integration integrity |
Framework mapping
| Rollout element | NIST SP 800-53 Rev. 5 | NIST CSF 2.0 | Other references |
|---|---|---|---|
| Identity proofing | IA-12 Identity Proofing | PR.AA-02 | SP 800-63A-4 |
| Customer authentication after enrolment | IA-8 Identification and Authentication (Non-organizational Users) | PR.AA-03 | SP 800-63B-4 |
| Input and media validation | SI-10 Information Input Validation | No direct subcategory | ISO/IEC 30107-3:2023 |
| Privacy and purpose | PT-3 Personally Identifiable Information Processing Purposes | GV.OC-03 | GDPR Article 9 and Article 35 |
| Provider risk | SA-9 External System Services, SR-6 Supplier Assessments and Reviews | GV.SC-05 | FATF Guidance on Digital ID |
| Reviewer access and monitoring | AC-6 Least Privilege, AU-6 Audit Record Review, Analysis, and Reporting | DE.CM-03 | SP 800-63A-4 insider threat controls |
Common failure patterns
- Client-reported results: the app tells the back end the check passed, and an attacker edits the response.
- Upload allowed: a "can't use camera" fallback that accepts stored images, bypassing liveness and injection checks.
- Provider defaults as policy: thresholds and accepted documents never reviewed against your own risk or law.
- Images kept forever: no retention configured at the provider or in your own case system, building a breach target of identity documents and faces.
- Unwatched manual review: reviewers approve declined applicants without second review, and collusion goes undetected.
- No outage plan: the provider goes down and the business switches verification off without a record of who was onboarded unverified.
Practitioner checklist
- Set an assurance target per journey and confirm KYC obligations with compliance.
- Choose accepted evidence per market, and require live capture with injection checks.
- Create sessions server-side and fetch or verify results server-side, bound to the applicant.
- Separate API keys per environment, with owners and rotation; verify webhook signatures.
- Complete a privacy risk assessment or DPIA and configure retention at the provider.
- Build trusted referee, manual review and redress routes with insider controls.
- Test attacks, replay and fairness in a pilot, then launch in stages with a fallback.
- Monitor fraud in verified accounts, overrides and retention breaches monthly.
Standards and references
- NIST: SP 800-63A-4, Digital Identity Guidelines: Identity Proofing and Enrollment
- ISO: ISO/IEC 30107-3:2023 Biometric presentation attack detection, Part 3: Testing and reporting
- FATF: Guidance on Digital ID
- EUR-Lex: Regulation (EU) 2016/679, General Data Protection Regulation
- NIST: SP 800-53 Rev. 5 Security and Privacy Controls
- NIST: Cybersecurity Framework 2.0
Related NHI Mgmt Group resources: Identity verification and KYC platform health check · Identity Verification RFP Template · NIST SP 800-63A-4 Identity Proofing (IAL) Guide · Synthetic Identity Fraud Guide