Cara Bank Menggunakan Tanda Tangan Digital untuk e-KYC Nasabah

Nasabah tidak batal membuka rekening karena tidak paham e-KYC nasabah. Mereka batal saat prosesnya terasa seperti pindahan cabang ke layar ponsel: foto KTP diulang, liveness gagal, persetujuan panjang tidak jelas, lalu dokumen akhir masih harus ditandatangani manual. Di titik itu, masalahnya bukan hanya UX. Bank kehilangan conversion, tim compliance kehilangan jejak persetujuan yang rapi, dan tim operasi harus mengejar dokumen yang seharusnya sudah selesai di awal.

Untuk bank, tanda tangan digital bukan fitur tambahan di akhir onboarding. Ia adalah kontrol kepercayaan di dalam alur: siapa orangnya, apakah ia benar memberi persetujuan, dokumen apa yang ditandatangani, kapan disetujui, dan apakah integritas dokumen bisa dibuktikan saat audit.

TL;DR

• e-KYC nasabah yang sehat menggabungkan verifikasi identitas, consent, tanda tangan digital, risk review, dan integrasi core banking dalam satu jejak audit.
• POJK 21 Tahun 2023 memberi landasan penting untuk verifikasi calon nasabah melalui layanan digital, termasuk mekanisme tidak tatap muka secara elektronik.
• Tanda tangan digital bank perlu mengacu pada UU ITE dan PP 71/2019 agar identitas penanda tangan, persetujuan, dan integritas dokumen dapat dipertanggungjawabkan.
• Tilaka relevan untuk onboarding bank karena modul OCR, liveness, e-Consent, dan Tilaka Sign+ dapat diposisikan sebagai trust layer yang API-first.
• Ukur keberhasilan dengan conversion, drop-off, time-to-onboard, manual-review rate, signature completion, dan audit exception, bukan hanya jumlah akun baru.

Friction e-KYC Nasabah Biasanya Muncul Setelah KTP Diunggah

Dalam alur e-KYC nasabah bank, titik geser jarang berdiri sendiri. Calon nasabah mengunggah KTP, sistem OCR membaca data, liveness memastikan wajah yang muncul bukan foto atau video replay, lalu aplikasi meminta consent dan menghasilkan dokumen pembukaan rekening, kredit, atau layanan digital lain. Setelah itu baru ada tanda tangan digital, risk review, dan handoff ke core banking atau customer master.

Masalah muncul saat setiap langkah dibangun seperti proyek terpisah. OCR sukses, tetapi field mapping ke CRM tidak konsisten. Liveness sukses, tetapi bukti consent tidak menyimpan konteks layar yang disetujui. Dokumen bisa ditandatangani, tetapi audit trail tidak mudah dicocokkan dengan sesi onboarding. Hasilnya: proses digital tampak jalan, namun bukti operasionalnya pecah.

Contoh sederhana: calon nasabah lolos liveness pada pukul 09.14, menyetujui syarat layanan pada pukul 09.16, lalu menandatangani dokumen pada pukul 09.21. Bila tiga event ini disimpan di sistem berbeda tanpa correlation ID, tim audit harus menjahit ulang cerita prosesnya. Itu melelahkan. Lebih buruk lagi, saat ada dispute, bank butuh bukti bahwa orang yang sama membaca, menyetujui, dan menandatangani dokumen yang tepat.

Insight: e-KYC bukan hanya “ambil data KTP”. Untuk bank, e-KYC adalah rangkaian bukti: identitas, intent, consent, signature, dan handoff ke sistem inti.

Peta Regulasi e-KYC Nasabah untuk Perbankan Indonesia

Untuk konteks 2026, rujukan OJK yang lebih tepat untuk layanan digital bank adalah POJK Nomor 21 Tahun 2023 tentang Layanan Digital oleh Bank Umum. Pasal 5 ayat (1) mengatur kewajiban bank melakukan identifikasi calon nasabah dan verifikasi atas kebenaran data, informasi, dokumen pendukung, serta kesesuaian profil pemberi data. Pasal 5 ayat (3) membuka mekanisme verifikasi tatap muka elektronik dan tidak tatap muka elektronik.

Pasal 5 ayat (6) POJK 21/2023 juga menuntut paling sedikit dua faktor autentikasi dalam verifikasi, sedangkan ayat (7) meminta faktor “something you are” untuk verifikasi tatap muka elektronik atau tidak tatap muka elektronik. Ini menjelaskan mengapa liveness dan biometrik tidak boleh diperlakukan sebagai dekorasi UX. Ia menjadi kontrol identitas.

Lalu POJK Nomor 8 Tahun 2023 tentang APU, PPT, dan PPPSPM di Sektor Jasa Keuangan mengatur identifikasi dan verifikasi calon nasabah. Pasal 30 memuat data identitas yang harus diminta untuk calon nasabah orang perseorangan, sedangkan Pasal 35 mengarah pada penentuan nasabah berisiko tinggi dan enhanced due diligence.

Untuk tanda tangan, UU ITE Pasal 11 mengakui kekuatan hukum tanda tangan elektronik jika syarat minimum terpenuhi, termasuk keterkaitan data pembuatan tanda tangan hanya kepada penanda tangan, kemampuan mendeteksi perubahan, identifikasi penanda tangan, dan bukti persetujuan. PP 71 Tahun 2019 Pasal 59 dan Pasal 60 memperjelas fungsi tanda tangan elektronik sebagai alat autentikasi dan verifikasi, termasuk perbedaan tanda tangan elektronik tersertifikasi dan tidak tersertifikasi.

Implikasinya praktis: bank perlu merancang onboarding sebagai alur yang bisa dijelaskan kepada auditor, bukan hanya alur yang terlihat cepat di aplikasi.

Arsitektur Tanda Tangan Digital Bank dalam Alur e-KYC

Arsitektur tanda tangan digital bank biasanya paling rapi bila dibangun sebagai trust layer, bukan modul yang ditempel di akhir. Dalam konteks Tilaka, layer ini dapat memadukan OCR untuk membaca identitas, Liveness Detection & Anti-Spoofing untuk memastikan kehadiran subjek, e-Consent untuk merekam persetujuan, dan Tilaka Sign+ untuk penandatanganan dokumen.

Halaman resmi Tilaka menjelaskan enam trust modules untuk operasi enterprise: Tilaka Sign+, e-Consent, Liveness Detection & Anti-Spoofing, OCR & Identity Data Processing, e-Meterai, serta Data Protection & Encryption. Tilaka juga menyebut pendekatan Portal, API, dan On-Prem sebagai pilihan integrasi sesuai kebutuhan operasional dan kontrol data.

Di sisi dokumen, Tilaka Sign+ diposisikan sebagai solusi tanda tangan digital berbasis sertifikat elektronik PSrE. Untuk e-KYC bank, ini relevan saat output onboarding berupa dokumen rekening, aplikasi kredit, consent data, pembukaan layanan digital, atau perjanjian finansial yang butuh bukti persetujuan kuat.

Sementara itu, OCR & Identity Data Processing Tilaka membantu ekstraksi data dari dokumen identitas seperti KTP, paspor, atau SIM. e-Consent Tilaka dapat merekam persetujuan digital dengan jejak audit, termasuk konteks identitas dan timestamp. Rangkaian ini mengurangi kebutuhan input manual sekaligus memberi struktur bukti yang lebih mudah direview.

Dari sudut pandang implementasi Docotel, pertanyaan awal bukan “API-nya ada atau tidak?” Pertanyaan yang lebih menentukan adalah: event apa saja yang harus punya audit trail, field mana yang menjadi source of truth, dan kapan status calon nasabah boleh naik dari “submitted” menjadi “verified”.

Integrasi ke Core Banking Tidak Boleh Menunggu Akhir Proyek

Banyak proyek digital onboarding nasabah terlihat sehat di fase demo karena layar mobile sudah halus. Masalah baru muncul saat integrasi masuk ke sistem bank: customer master, loan origination system, document management, fraud engine, risk scoring, dan core banking punya struktur data yang berbeda.

Karena itu, desain integrasi perlu dimulai dari event. Minimal ada event untuk identity captured, OCR parsed, liveness passed, consent accepted, document generated, signature completed, risk approved, dan account created. Setiap event sebaiknya membawa timestamp, channel, user/session ID, device context, document hash, dan status response dari sistem penerima.

Contoh: jika OCR membaca alamat berbeda dari data sumber yang dipakai bank, jangan langsung overwrite customer master. Kirim event ke queue manual review dengan alasan yang jelas. Jika liveness gagal dua kali, sistem jangan hanya memberi pesan error. Simpan reason code agar fraud/risk team dapat membedakan kegagalan teknis, kualitas kamera, atau pola spoofing.

Pada proyek bank, Docotel biasanya mendorong workshop “data contract” sejak awal. Ini bukan dokumen formalitas. Data contract menentukan nama field, format dokumen, status lifecycle, mekanisme retry, dan siapa owner saat ada mismatch. Tanpa itu, tim aplikasi, compliance, dan core banking akan memakai definisi “verified” yang berbeda.

Catatan: Integrasi e-KYC yang baik tidak selalu berarti semua sistem real-time sejak hari pertama. Yang penting adalah event penting tidak hilang, status tidak ambigu, dan bukti audit bisa ditelusuri.

Timeline 12 Minggu sebagai Kerangka, Bukan Janji SLA

Brief awal sering meminta timeline implementasi 12 minggu. Angka ini masuk akal sebagai kerangka perencanaan, tetapi tidak boleh dibaca sebagai janji SLA. Bank dengan arsitektur API matang, data dictionary jelas, dan owner compliance aktif bisa bergerak lebih cepat. Bank dengan core legacy, banyak approval komite, atau vendor dependency panjang akan membutuhkan fase tambahan.

Kerangka 12 minggu yang realistis biasanya terbagi seperti ini:

Fase	Fokus kerja	Output yang harus jelas
Minggu 1-2	Discovery dan regulasi	Scope, journey nasabah, kontrol POJK, daftar dokumen
Minggu 3-4	Desain arsitektur	Data contract, event model, API mapping, audit requirement
Minggu 5-8	Integrasi dan konfigurasi	OCR, liveness, e-Consent, Tilaka Sign+, callback, logging
Minggu 9-10	UAT dan security review	Test case, error handling, evidence pack, akses role
Minggu 11	Pilot terbatas	Monitoring drop-off, manual review, support ticket
Minggu 12	Rollout decision	Go/no-go, rollout batch, SOP operasi, checklist audit

Dalam timeline seperti ini, compliance tidak menunggu UAT. Compliance masuk sejak minggu pertama untuk menentukan bukti apa yang harus tersedia. Tim risk juga tidak menunggu production. Mereka perlu menyetujui rule kapan calon nasabah masuk manual review, kapan ditolak, dan kapan boleh lanjut.

CTA: Jika tim Anda sedang menata ulang onboarding digital bank, gunakan Download Banking e-KYC Playbook sebagai bahan diskusi awal antara digital banking, compliance, risk, dan IT.

Metrik Digital Onboarding Nasabah yang Layak Dipantau

Metrik digital onboarding nasabah tidak cukup berhenti di “jumlah aplikasi masuk”. Angka itu bisa terlihat bagus, tetapi tetap menyembunyikan drop-off, fraud attempt, atau dokumen yang akhirnya tidak bisa dipakai.

Pantau conversion rate dari mulai aplikasi sampai akun aktif. Pisahkan drop-off per langkah: OCR, liveness, consent, tanda tangan, risk review, dan handoff core banking. Jika drop-off paling tinggi terjadi setelah liveness, masalahnya bisa kualitas instruksi, pencahayaan, perangkat user, atau rule anti-spoofing yang terlalu ketat untuk segmen tertentu.

Metrik kedua adalah time-to-onboard. Hitung median dan p95, bukan hanya rata-rata. Median menunjukkan pengalaman umum, sedangkan p95 menunjukkan calon nasabah yang tersangkut di edge case. Untuk bank, edge case sering menjadi beban support terbesar.

Metrik ketiga adalah manual-review rate. Manual review terlalu rendah bisa berarti rule terlalu longgar. Terlalu tinggi berarti digital onboarding hanya memindahkan pekerjaan dari cabang ke back office. Tambahkan audit exception count: berapa kasus yang tidak memiliki bukti consent lengkap, document hash, atau status tanda tangan.

Docotel melihat pola yang sama di banyak diskusi awal: tim bisnis ingin mempercepat funnel, tim compliance ingin bukti, dan tim IT ingin arsitektur yang tidak rapuh. Dashboard yang benar membuat tiga tim ini melihat masalah yang sama, bukan membawa angka yang saling bertentangan ke rapat steering.

Skenario Mini: Pembukaan Rekening Tanpa Cabang

Bayangkan bank meluncurkan pembukaan rekening tabungan digital untuk nasabah payroll. Calon nasabah menerima link dari perusahaan, mengisi data, mengunggah KTP, lalu OCR mengisi field dasar. Liveness memeriksa wajah, e-Consent merekam persetujuan pemrosesan data, dan Tilaka Sign+ menandatangani dokumen pembukaan rekening.

Sistem risk memberi skor awal. Jika data sesuai dan tidak ada red flag, status masuk ke core banking. Jika ada mismatch alamat, nama, atau kualitas dokumen, kasus masuk manual review dengan reason code. Dokumen final tersimpan di document management dengan hash, timestamp, dan status signature.

Dalam model ini, cabang tidak hilang sepenuhnya. Cabang berubah peran. Mereka menangani exception dan edukasi, bukan input data berulang. Compliance juga tidak kehilangan kontrol karena setiap keputusan punya bukti: siapa calon nasabahnya, data apa yang dibaca, consent apa yang diberikan, dokumen apa yang ditandatangani, dan kapan status berubah.

Penting: Jangan mengukur keberhasilan e-KYC hanya dari kecepatan. Untuk bank, kecepatan yang tidak bisa diaudit akan menjadi masalah saat dispute, pemeriksaan, atau investigasi fraud.

Skenario ini tidak perlu memakai nama bank atau angka klaim yang belum diverifikasi. Nilainya ada pada blueprint: potong friction tanpa memotong kontrol.

Checklist Keputusan untuk Head of Digital Banking dan Compliance

Sebelum memilih vendor atau menulis backlog teknis, bank perlu menyepakati lima keputusan.

Pertama, tentukan dokumen mana yang harus ditandatangani secara elektronik tersertifikasi. Tidak semua persetujuan membutuhkan level yang sama, tetapi dokumen bernilai hukum dan berisiko sengketa sebaiknya tidak memakai bukti lemah.

Kedua, tetapkan source of truth identitas. Apakah data OCR hanya pre-fill, atau boleh menjadi data utama setelah cocok dengan sumber lain? Siapa yang memutuskan saat mismatch?

Ketiga, desain consent sebagai event yang bisa diaudit. Consent bukan checkbox. Ia harus punya versi teks, konteks layar, identitas user, waktu, dan hubungan dengan dokumen yang ditandatangani.

Keempat, tentukan risk tier. Calon nasabah berisiko rendah bisa otomatis lanjut, sementara pola tertentu masuk manual review atau enhanced due diligence sesuai POJK 8/2023.

Kelima, pastikan integrasi tidak menciptakan blind spot. Jika status tanda tangan sukses tetapi callback gagal masuk ke sistem dokumen, sistem harus punya retry, alert, dan rekonsiliasi.

Untuk konteks tanda tangan tersertifikasi, pembaca juga bisa membaca artikel internal tentang perbedaan tanda tangan elektronik sertifikat dan non-sertifikat serta halaman produk Tilaka digital signature.

Frequently Asked Questions

Yang Harus Diputuskan Sebelum Rollout

e-KYC nasabah yang matang tidak dimulai dari layar aplikasi. Ia dimulai dari keputusan kontrol: bukti apa yang harus ada, sistem mana yang menjadi sumber kebenaran, dan bagaimana bank membuktikan bahwa orang yang benar telah menyetujui dokumen yang benar.

Tanda tangan digital bank bekerja paling baik saat masuk sejak desain onboarding, bukan saat dokumen sudah selesai dibuat. Dengan pendekatan itu, OCR, liveness, consent, signature, risk review, dan core banking bisa saling membaca status yang sama.

Docotel membantu bank memetakan arsitektur digital trust bersama Tilaka: dari journey nasabah, integrasi API, audit trail, sampai readiness untuk compliance review.

Disusun oleh: Tim Solution Architects Docotel
Dipublikasikan: 2026-06-22
Terakhir diperbarui: 2026-07-01