When to use KYC onboarding
KYC verification is appropriate at any of the following onboarding milestones:- Regulated fintech products — lending, money transmission, brokerage, or payment account creation where AML obligations apply
- High-value account creation — accounts with elevated spending, transfer, or withdrawal limits
- Marketplace seller onboarding — verifying sellers before they can list products or receive payouts
- Crypto exchange registration — meeting FATF travel rule and VASP obligations at account creation
Verification flow overview
The KYC flow has both synchronous and asynchronous phases. When you submit an identity verification request, FraudEG returns an immediate decision for cases it can resolve instantly (e.g., clear data matches or obvious failures). For cases that require document analysis or liveness review, FraudEG returns apending status and delivers the final result asynchronously via the identity.verification_completed webhook.
Integration guide
1
Collect user identity data in your onboarding form
Gather the required fields before making the API call: legal name, date of birth, residential address, and a government-issued document (passport, national ID, or driver’s license). For document verification, collect the document type, number, issuing country, and expiry date. If you are collecting document images for visual verification, upload them to your secure storage and pass the file references in the API request.
2
Submit to POST /v1/identity/verify
Send the full identity payload to the verification endpoint. The request body below covers an individual identity check with a passport document.
cURL
3
Handle the synchronous response
The API responds immediately with a Branch on the
status field that tells you how to proceed:status value:verified— all checks passed. Allow the user to proceed through onboarding.pending— document or liveness review is still in progress. Block the user from transacting and listen for theidentity.verification_completedwebhook (see next step).failed— one or more checks did not pass. Reject the application. You may prompt the user to re-submit with corrected or higher-quality document images, subject to your retry policy.flagged— the user matched one or more entries on a sanctions list, PEP list, or adverse media database. Route the case to manual compliance review before taking any action.
4
Handle async results via webhook
For
pending verifications, FraudEG delivers the final result to your registered webhook endpoint as an identity.verification_completed event. Parse the event payload and update the user’s onboarding status in your system.5
Run watchlist screening
After a The response includes match details, list names (OFAC, UN, EU, PEP), match score, and matched fields.
verified or flagged result, you can also query the watchlist endpoint directly to retrieve the full screening detail for a user. This is useful for compliance records and periodic re-screening.cURL
6
Store the verification_id for compliance records
Persist the
verification_id in your user record immediately after receiving it. You will need this identifier to retrieve verification evidence during audits, regulatory examinations, or dispute resolution. All verification records, check results, and watchlist screening outcomes are linked to this ID.KYB: verifying businesses
The samePOST /v1/identity/verify endpoint handles business (KYB) verification. Set "type": "business" and include company-specific fields alongside the registered address and beneficial owner information.
FraudEG retains all verification records — check results, document metadata, watchlist screening outcomes, and audit logs — in accordance with applicable data retention regulations. For US customers, records are stored for a minimum of five years. For EU customers, retention follows applicable AML directive requirements. You can retrieve a full verification audit trail at any time using the
verification_id.