Home/Documentation/Use cases/Identity verification (KYC)Intermediate12 min

Identity verification (KYC)

Confirm a customer's identity by matching the details they give you against the data their mobile operator already holds — name, address, date of birth, and account tenure — without OTPs, document uploads, or selfie checks. This guide covers the KYC Match flow and how to read its results.

Why operator-backed KYC

Traditional KYC asks the user to upload an ID and take a selfie — slow, high-drop-off, and spoofable. Operators already verified their subscribers at SIM registration and hold current name, address, and birth-date records. KYC Match lets you compare your applicant's claims against that authoritative source and get back a per-field match result, with no document handling on your side.

It returns match indicators, not the underlying data — so you confirm "the name matches" without the operator ever exposing the stored value. That keeps you data-minimal and privacy-aligned.

What you'll need

An application registered to KYC Match (see Your first verified API call)
A valid access token with the KYC scope (see OAuth2 with Konera)
The applicant's phone number and the identity details they've entered in your form
End-user consent to verify against operator data (required — see Consent below)

Step 1 — Submit the details to match

Send the applicant's number plus the fields you want to check. Send only what you need.

curl -X POST https://api.pxg.konera.com/camara/kyc-match/v1/match \
-H "Authorization: Bearer $TOKEN" \
-H "Content-Type: application/json" \
-d '{
"phoneNumber": "+14155550123",
"idDocument": null,
"name": "Jane Doe",
"givenName": "Jane",
"familyName": "Doe",
"address": "10 Market St, San Francisco, CA 94103",
"birthdate": "1990-04-17"
}'

Step 2 — Read the per-field result

Each submitted field returns a match indicator rather than the stored value:

{
"nameMatch": "true",
"givenNameMatch": "true",
"familyNameMatch": "true",
"addressMatch": "partial",
"birthdateMatch": "true"
}

Each field is one of:

Value	Meaning
`true`	The value matches the operator's record.
`false`	The value does not match.
`partial`	Close but not exact (e.g. abbreviations, missing unit number).
`not_available`	Operator holds no data for that field.

Step 3 — Decide on the combined result

Don't require every field to be true — weight them by how strongly each proves identity, and treat partial as a soft pass for tolerant fields like address.

const r = await kycMatch(payload);const strong = r.nameMatch === "true" && r.birthdateMatch === "true";
const address = r.addressMatch === "true" || r.addressMatch === "partial";
if (strong && address) return "PASS";
if (strong)            return "REVIEW";   // identity ok, address soft
return "FAIL";                            // name or DOB mismatch

KYC checks operator-held personal data, so you must capture the end user's explicit consent before calling KYC Match, and be able to evidence it. Surface a clear consent statement at the point you collect their details, and store the consent record alongside your verification log.

Interpreting results well

Normalise input before sending. Trim whitespace, standardise address format, and use ISO YYYY-MM-DD dates to avoid avoidable partial/false results.
Treat not_available as neutral, not a fail — fall back to another field or a step-up check.
Pair with fraud signals. A clean KYC match plus a recent SIM swap is still risky — combine with fraud prevention signals for high-value onboarding.
Log the correlation ID from each response for audit and dispute handling (see Rate limits & error handling).

Next steps

Fraud prevention with Network APIs — layer SIM Swap and Number Verification on top of KYC.
Testing with sandbox numbers — synthetic identities that return each match combination.
CAMARA standard, explained — how KYC Match fits the CAMARA family.