Key Takeaway
You cannot query Dukcapil without a signed agreement. Permendagri 102/2019, amended in 2023, grants access only after a memorandum of understanding and a cooperation agreement, so a fintech without one verifies a NIK through a provider that has one. Majority-foreign-owned users get only match or no-match. Biometrics are specific personal data under UU PDP, demanding explicit consent and strict storage.
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 grants access to population data only to institutions that sign an agreement with it. An app without its own agreement reaches it through an authorized provider that has one.
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 does not run an open lookup service, and how much it returns depends on who is asking. Permendagri 102/2019, as amended by Permendagri 17/2023, limits Indonesian legal entities with majority foreign ownership to a match or no-match answer (Article 29(4)). For everyone else, data accessed through the web service may be stored only after the data owner's consent has been verified with NIK and biometrics (Article 30(1)). 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 agreement access — an Indonesian legal entity applies to the Director General of Dukcapil, signs a memorandum of understanding and then a cooperation agreement, and connects over a closed network it provides itself. Banks, capital-market players such as KSEI, and remittance companies have taken this route.
- Through an e-KYC provider — an app without its own agreement calls a provider that holds one. Permendagri 17/2023 deleted the shared-platform (Platform Bersama) provisions with effect from 30 October 2023, so the regulation no longer has a separate intermediary tier: what a provider may do for you depends on its own agreement with Dukcapil.
Since Permendagri 17/2023, every user of population data must apply a security standard that gives priority to Indonesia's national standards (SNI) for information or cyber security, proven by holding a security-standard certificate (Article 18A), and the parties to a cooperation agreement may not pass population data to third parties or use it outside the agreement (Article 7(k)). Any provider claiming to sell you a NIK-to-full-profile lookup is either lying or breaking the law. Choose providers that publish their data-cooperation status and their security certification.
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.
- 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.
- Verify demographics against Dukcapil — send NIK plus the extracted fields; get a per-field match result.
- Capture a liveness selfie — the SDK runs active or passive liveness to reject printed photos, screens, and deepfakes.
- Face-match the selfie to the Dukcapil reference photo — you receive a similarity score, not the reference image itself.
- 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.
Start conservative: auto-approve only above a high similarity score, send the middle band to manual review, and hard-decline the rest. Log every decision with its scores so you can move the thresholds later using real data instead of guesses. OJK examiners love that audit trail.
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 storageTwo 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.
The penalties are real. UU PDP allows administrative fines up to 2% of a company's annual revenue. Its criminal provisions reach up to 4 years and Rp4 billion for unlawfully disclosing someone else's personal data and up to 5 years and Rp5 billion for unlawfully obtaining, collecting or using it (Article 67), which is where illegally selling identity data lands; the 6-year, Rp6 billion maximum is for creating false personal data or falsifying it (Article 68). A corporation can be fined up to ten times those maximums (Article 70). Storing raw biometrics or NIK in plaintext logs is exactly the kind of exposure that turns a breach into a fine.
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:
| What to check | Why it matters |
|---|---|
| Dukcapil data-cooperation status | Confirms the provider is authorized, not scraping. |
| OJK / Bank Indonesia registration | Required for regulated financial products. |
| Liveness + face-match bundled | Avoids stitching two vendors and two data flows. |
| Per-verification pricing model | Predictable unit cost as you scale onboarding. |
| Data residency and retention terms | Determines your UU PDP exposure downstream. |
| Audit-log export | Needed to satisfy OJK examinations. |
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.