Membangun e-KYC untuk Fintech Indonesia: Verifikasi NIK/Dukcapil yang Benar

Di sebuah proyek baru-baru ini saya membangun alur onboarding untuk aplikasi pinjaman di Indonesia, dan syarat yang paling sering disalahpahami adalah verifikasi identitas. Banyak founder mengira ada endpoint Dukcapil publik yang tinggal Anda kirimi NIK. Tidak ada. Dukcapil (Direktorat Jenderal Kependudukan dan Pencatatan Sipil) mengelola registri kependudukan nasional di balik e-KTP, dan tidak menyerahkan data mentah ke perusahaan swasta. Sebaliknya, Dukcapil menandatangani perjanjian kerja sama data dan mengizinkan sejumlah kecil penyedia resmi menjalankan pengecekan match-only ke basis data kependudukan.

Artikel ini membahas arsitektur dan kepatuhan alur tersebut, bukan scraping. Jika ada yang menawarkan cara melakukan lookup NIK secara massal, tinggalkan saja: itu ilegal, melanggar UU PDP, dan bisa membuat izin Anda dicabut. Jalur yang sah memang terkesan membosankan, dapat diaudit, dan justru itulah yang ingin dilihat OJK.

Cara kerja verifikasi Dukcapil yang sebenarnya

Dukcapil menerapkan model verifikasi, bukan berbagi data. Institusi resmi mengirim data yang sudah dikumpulkan dari pengguna, lalu Dukcapil menjawab apakah kombinasi itu ada dan cocok. Dukcapil tidak pernah mengembalikan field yang belum dimiliki pemanggil. Tingkatan akses yang akan Anda temui di lapangan adalah:

• Verifikasi data — Anda mengirim NIK plus field demografis (nama, tanggal lahir) dan menerima true/false per field. Ini adalah pengecekan inti.
• Verifikasi wajah — Anda mengirim selfie langsung dan pencocokan wajah di sisi Dukcapil membandingkannya dengan foto referensi yang tersimpan untuk NIK tersebut, mengembalikan skor kemiripan.
• Akses MOU langsung — bank besar dan pelaku pasar modal (KSEI) menandatangani langsung dengan Dukcapil; lebih dari seribu bank sudah punya perjanjian semacam itu.
• Akses platform bersama — institusi lebih kecil terhubung melalui operator seperti penyedia e-KYC resmi yang sudah memegang koneksi Dukcapil.

Alur verifikasi ujung ke ujung

Onboarding e-KYC produksi untuk aplikasi Indonesia biasanya merangkai lima langkah. Penyedia seperti Verihubs, Privy, dan lainnya menyediakan tiap langkah sebagai panggilan API, dan satu proses penuh umumnya selesai di bawah 30 detik.

1. OCR KTP — pengguna memotret e-KTP, OCR mengekstrak NIK, nama, dan tanggal lahir. Jangan pernah percaya OCR saja; ia hanya mengisi awal field yang akan Anda verifikasi.
2. Verifikasi demografi ke Dukcapil — kirim NIK plus field yang diekstrak; dapatkan hasil kecocokan per field.
3. Ambil selfie liveness — SDK menjalankan liveness aktif atau pasif untuk menolak foto cetak, layar, dan deepfake.
4. Cocokkan selfie dengan foto referensi Dukcapil — Anda menerima skor kemiripan, bukan gambar referensinya.
5. Putuskan — setujui, tolak, atau arahkan ke tinjauan manual berdasarkan ambang batas Anda, lalu tulis catatan audit.

// 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 dan liveness: setel ambang batasnya

Skor face-match adalah probabilitas, bukan ya/tidak. Tetapkan dua ambang: batas bawah auto-approve dan pita tinjauan manual di bawahnya. Satu batas keras saja akan meloloskan penipuan atau menolak pengguna sah yang pencahayaan selfienya berbeda dari foto KTP bertahun-tahun lalu. Liveness adalah gerbang terpisah yang tidak bisa ditawar — face-match tinggi pada foto palsu tak berarti apa-apa, jadi liveness harus lolos sebelum skor kecocokan dipertimbangkan.

Mengelola data sensitif menurut UU PDP

UU No. 27 Tahun 2022 (UU PDP) sudah berlaku penuh sejak Oktober 2024. Undang-undang ini mengklasifikasikan data biometrik sebagai data pribadi spesifik yang menuntut pelindungan lebih ketat dan, yang penting, persetujuan eksplisit dan terpisah — bukan checkbox yang terselip di syarat umum Anda. NIK juga merupakan data pribadi. Kewajiban praktis yang membentuk arsitektur Anda adalah:

• Persetujuan eksplisit — catat apa yang disetujui pengguna, kapan, dan untuk tujuan apa, sebelum Anda mengirim apa pun ke penyedia.
• Pembatasan tujuan — Anda hanya boleh memakai data untuk tujuan KYC yang disetujui pengguna, bukan untuk pemasaran atau dijual kembali.
• Minimalisasi data — simpan hasil verifikasi dan reference ID, bukan selfie mentah atau NIK dalam bentuk teks biasa jika bisa dihindari.
• Retensi dan penghapusan — tentukan berapa lama Anda menyimpan data identitas dan hormati hak subjek data untuk penghapusan.
• Penanganan kebocoran — Anda wajib memberi tahu subjek yang terdampak dan otoritas jika terjadi kebocoran data pribadi.

// 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

Dua aturan rekayasa muncul dari sini. Pertama, hash NIK dengan HMAC berkunci dan pepper di sisi server agar Anda tetap bisa mendeduplikasi pengguna tanpa menyimpan angka mentahnya. Kedua, perlakukan selfie mentah seperti bahan radioaktif: alirkan ke penyedia, tahan di memori, dan jangan pernah biarkan menyentuh log, object storage, atau trace APM Anda. Simpan hanya skor dan keputusannya.

Memilih penyedia

Anda sebenarnya memilih mitra kepatuhan, bukan sekadar API. Pertanyaan yang tepat menyangkut kedudukan hukum dan penanganan data, bukan hanya uptime. Bandingkan kandidat pada sumbu berikut:

Harga biasanya per verifikasi berhasil. Sebagai acuan, satu penyedia (Didit) mencantumkan sekitar USD 0,30 per verifikasi dengan kuota gratis bulanan; pemain lama bisa beberapa kali lipat. Anggap angka publik mana pun sebagai titik awal dan konfirmasikan tarif serta tier volume terkini secara langsung, karena harga dan regulasi fintech Indonesia sama-sama cepat berubah.