Skip to main content
This guide covers exceptions that can occur during IDV, AML, KYC, and Biometric processes. Use this reference to plan your internal processes for handling these scenarios.
Note: IDV vendors (Daon, Incode, Onfido) have built-in quality gates that prevent submission of poor quality images or fraudulent documents at capture stage. Many technical errors are handled by vendor SDKs before reaching FrankieOne.

Summary

Primary Resolution Approaches

Before diving into specific exceptions, these are the standard fallback approaches:

Workflow Status Values

Understanding the workflow result statuses:

Exception Categories at a Glance

Handler Reference


IDV - Access Issues

Exceptions related to customers accessing the verification flow.

URL Access

Browser Issues

Network Issues


IDV - Document Issues

Exceptions related to document capture and validation.

Document Quality

Document Type

Document Validity

Document Authenticity (IDV_DOCUMENT)

IDV document checks validate visual authenticity, image integrity, data validation, and document compromise status.

IDV - OCR Issues

Exceptions related to data extraction and matching. OCR extracts data from documents (IDV_OCR), then comparison checks this against entity information (IDV_OCR_COMPARISON), flagging discrepancies via a mismatchMap.
Note: The system uses fuzzy matching logic (Levenshtein distance) to tolerate minor OCR errors before flagging mismatches.

Data Mismatch

Data Extraction


IDV - Biometric Issues

Exceptions related to liveness checks and facial matching. IDV results use statuses: CLEAR, SUSPECTED, or REJECTED.

Liveness Failed (IDV_FACIAL_LIVENESS)

Face Match (IDV_FACIAL_COMPARISON)

Image Quality

Obstruction

Detection

Appearance Change


IDV - Technical Issues

Technical exceptions during the verification process.

Camera Access

Upload

Processing


KYC Exceptions

Exceptions during electronic KYC verification.

Verification Failed

Data Issues

Credit Header

Technical


AML Exceptions

Exceptions from Anti-Money Laundering screening. AML screening checks against four categories: PEPs, Sanctions, Adverse Media, and Regulatory/Law Enforcement Watchlists.

Screening Hits

When AML returns a HIT result, compliance teams must classify the match.

AML Hit Classification

Use the PATCH /v2/individuals/{entityId}/results/aml endpoint to classify matches:
Note: Re-run the workflow after classification as statuses may change.

Review Required

Technical

Ongoing Monitoring

AML Ongoing Monitoring continuously screens entities after onboarding. When risk status changes, alerts are triggered requiring review.

Blocklist & Duplicate Exceptions

Exceptions from internal matchlist/blocklist and duplicate detection.

Matchlist/Blocklist Matches

When a matchlist check returns a HIT, a BLOCKLISTED issue is generated. Classification Options:
  • FALSE_POSITIVE - Match is incorrect, no risk
  • TRUE_POSITIVE_REJECT - Match confirmed, reject entity
Note: After classification, re-run the workflow. If all hits are marked FALSE_POSITIVE, the step changes to CLEARED and the BLOCKLISTED issue is removed.

Duplicate Detection

When the DUPLICATE step finds a match, a DUPLICATE issue is generated and the workflow typically goes to REVIEW. Classification Options:
  • FALSE_POSITIVE - Not a duplicate, no relationship created
  • TRUE_POSITIVE_ACCEPT - Confirmed duplicate; marks the older entity as duplicate
  • TRUE_POSITIVE_REJECT - Confirmed duplicate; marks the newer entity as duplicate
Note: After classification, re-run the workflow so the DUPLICATE step can reassess and update the overall status.

Fraud Check Exceptions

Exceptions from the FRAUD workflow step, which evaluates email, phone, device, and IP risk.

Fraud Hits

When fraud checks return a HIT result, issues are generated with category: FRAUD.

Risk Levels

Fraud checks return risk levels: LOW, MEDIUM, HIGH, or UNACCEPTABLE.

Fraud Hit Classification

Use the PATCH /v2/individuals/{entityId}/results/fraud endpoint to classify fraud detections:
Note: Results automatically become MARKED_INVALID or STALE when associated data (email/phone) is modified or deleted.

Biometrics - Vendor Specific

Vendor-specific biometric exceptions.

Manual Override

IDV results can be manually overridden via PATCH /v2/individuals/{entityId}/results/idv by updating the manualStatus field. Results automatically invalidate (STALE or MARKED_INVALID) when underlying entity data changes post-verification.

Quick Reference: Escalation Paths


Support