Building e-KYC for Indonesian Fintech: NIK/Dukcapil Verification Done Right

On a recent project I built the onboarding flow for an Indonesian lending app, and the single most misunderstood requirement was identity verification. Founders assume there is a public Dukcapil endpoint you POST a NIK to. There is not. Dukcapil (Direktorat Jenderal Kependudukan dan Pencatatan Sipil) runs the national civil registry behind the e-KTP, and it does not hand raw data to private companies. Instead it signs data-cooperation agreements and lets a small set of authorized providers run match-only checks against the population database.

This article is about the architecture and compliance of that flow, not about scraping. If someone offers you a way to bulk-look-up NIK data, walk away: it is illegal, it breaches UU PDP, and it will get your license revoked. The legitimate path is boring, auditable, and exactly what OJK wants to see.

How Dukcapil verification actually works

Dukcapil operates a verify-not-share model. An authorized institution sends the data it already collected from the user, and Dukcapil answers whether that combination exists and matches. It never returns fields the caller did not already have. The access tiers you will encounter in practice are:

• Data verification (verifikasi) — you submit NIK plus demographic fields (name, date of birth) and get back true/false per field. This is the core check.
• Face verification (verifikasi wajah) — you submit a live selfie and Dukcapil-side face matching compares it to the reference photo stored against that NIK, returning a similarity score.
• Direct MOU access — the largest banks and capital-market players (KSEI) sign directly with Dukcapil; over a thousand banks already have such agreements.
• Shared-platform access (platform bersama) — smaller institutions plug into an operator such as an authorized e-KYC provider that already holds the Dukcapil connection.

The end-to-end verification flow

A production e-KYC onboarding for an Indonesian app usually chains five steps. Providers such as Verihubs, Privy, and others expose each as an API call, and a full run typically completes in under 30 seconds.

1. OCR the KTP — the user photographs their e-KTP, OCR extracts NIK, name, and date of birth. Never trust OCR alone; it only pre-fills the fields you will verify.
2. Verify demographics against Dukcapil — send NIK plus the extracted fields; get a per-field match result.
3. Capture a liveness selfie — the SDK runs active or passive liveness to reject printed photos, screens, and deepfakes.
4. Face-match the selfie to the Dukcapil reference photo — you receive a similarity score, not the reference image itself.
5. Decide — approve, decline, or route to manual review based on your thresholds, and write an audit record.

// POST /v1/identity/verify  (via authorized e-KYC provider)
// Request — you only ever send data the user gave you
{
  "nik": "3174xxxxxxxxxxxx",
  "name": "BUDI SANTOSO",
  "birth_date": "1994-03-12",
  "selfie_image": "<base64 jpeg>",
  "consent_id": "cns_01HXQ..."   // proof of user consent, see UU PDP section
}

// Response — match-only, no raw Dukcapil record is returned
{
  "nik_valid": true,
  "name_match": true,
  "birth_date_match": true,
  "face_match_score": 0.972,   // 0..1 similarity
  "liveness_passed": true,
  "decision": "approved",
  "reference_id": "vrf_01HXQ...", // store THIS, not the biometrics
  "verified_at": "2026-07-11T04:12:55Z"
}

Face-match and liveness: tune the thresholds

The face-match score is a probability, not a yes/no. Set two thresholds: an auto-approve floor and a manual-review band below it. A single hard cutoff either lets fraud through or rejects legitimate users whose selfie lighting differs from a years-old KTP photo. Liveness is a separate, non-negotiable gate — a high face-match on a spoofed photo is worthless, so liveness must pass before the match score is even considered.

Handling sensitive data under UU PDP

UU No. 27 Tahun 2022 (UU PDP) has been fully enforceable since October 2024. It classifies biometric data as specific personal data (data pribadi spesifik) that demands stricter protection and, critically, explicit and separate consent — not a checkbox buried in your general terms. NIK is personal data too. The practical obligations that shape your architecture are:

• Explicit consent — record what the user agreed to, when, and for which purpose, before you send anything to a provider.
• Purpose limitation — you may use the data only for the KYC purpose the user consented to, not for marketing or resale.
• Data minimization — store the verification result and a reference ID, not the raw selfie or the NIK in plaintext where you can avoid it.
• Retention and deletion — define how long you keep identity data and honor the data subject's right to erasure.
• Breach handling — you are obliged to notify affected subjects and the authority on a personal-data breach.

// Persist the CONSENT before the verify call, keep it immutable
CREATE TABLE kyc_consent (
  id            TEXT PRIMARY KEY,        -- consent_id sent to provider
  user_id       TEXT NOT NULL,
  purpose       TEXT NOT NULL,           -- 'identity_verification'
  scope         TEXT[] NOT NULL,         -- ['nik','biometric_face']
  policy_version TEXT NOT NULL,
  granted_at    TIMESTAMPTZ NOT NULL,
  ip_address    INET,
  revoked_at    TIMESTAMPTZ
);

// After verification: store the RESULT, discard the biometrics
CREATE TABLE kyc_result (
  id            TEXT PRIMARY KEY,        -- your reference_id
  user_id       TEXT NOT NULL,
  nik_hash      TEXT NOT NULL,           -- HMAC-SHA256(nik, pepper), never plaintext
  decision      TEXT NOT NULL,          -- approved | review | declined
  face_score    NUMERIC(4,3),
  liveness      BOOLEAN,
  provider_ref  TEXT,
  verified_at   TIMESTAMPTZ NOT NULL
);
// selfie bytes: process in memory, do NOT write to disk / object storage

Two engineering rules fall out of this. First, hash the NIK with a keyed HMAC and a server-side pepper so you can still de-duplicate users without holding the raw number. Second, treat the raw selfie as radioactive: stream it to the provider, keep it in memory, and never let it touch your logs, object storage, or an APM trace. Store only the score and the decision.

Choosing a provider

You are really choosing a compliance partner, not just an API. The right questions are about legal standing and data handling, not just uptime. Compare candidates on these axes:

Pricing is usually per successful verification. As a reference point, one provider (Didit) publicly lists around USD 0.30 per verification with a free monthly tier; incumbents cost several times more. Treat any public number as a starting point and confirm current rates and volume tiers directly, because Indonesian fintech pricing and regulation both change fast.