Aturan keputusan dan ambang batas
Setiap pemeriksaan menghasilkan warning, dan Anda yang menentukan apa yang dilakukan setiap warning tersebut - lolos, review, atau decline. Pemetaan itulah tempat selera risiko Anda sebenarnya berada.
Setiap langkah memetakan warning-nya ke sebuah tindakan: lolos, review, atau decline. Langkah yang dikonfigurasi untuk decline menghentikan workflow - langkah setelahnya tidak pernah berjalan, dan Anda tidak ditagih untuknya. Itu membuat urutan aturan menjadi keputusan risiko sekaligus keputusan biaya.
#Di mana keputusan sebenarnya dibuat
Wajar jika Anda membayangkan workflow sebagai "pemeriksaan yang saya jalankan". Padahal pemeriksaan hanyalah setengahnya. Setengah lainnya - dan yang menentukan tingkat persetujuan Anda - adalah apa yang dikonfigurasi untuk dilakukan oleh warning setiap pemeriksaan.
- Setiap node fitur membawa ambang batas dan keputusannya sendiri.
- Sebuah pemeriksaan bisa diwajibkan atau opsional, yang sendirinya adalah keputusan tentang siapa yang lolos.
- Aturan yang diubah berlaku untuk sesi baru begitu workflow-nya disimpan.
Untuk setiap langkah, setiap warning yang bisa dimunculkannya dipetakan ke salah satu dari tiga tindakan:
| Tindakan | Efek |
|---|---|
| Approve (atau abaikan) | Warning-nya tercatat tapi tidak mengubah hasilnya |
| Review | Sesi tersebut masuk ke In Review agar seseorang yang memutuskan |
| Decline | Sesi tersebut di-decline dan workflow-nya berhenti |
Pemetaan itulah kebijakan Anda, yang dinyatakan dalam bentuk konfigurasi.
#Sebuah decline menghentikan workflow
Ini perilaku yang paling mengejutkan orang, jadi penting untuk dijelaskan dengan tegas: saat sebuah langkah decline, eksekusinya berhenti di situ. Langkah-langkah setelahnya tidak pernah berjalan.
Dua konsekuensinya:
- Hasilnya akan kehilangan pemeriksaan yang Anda harapkan. Pemeriksaan itu bukan gagal - ia tidak pernah dijalankan. Sesi yang di-decline pada verifikasi ID tidak akan memiliki liveness, face match, atau AML.
- Anda tidak ditagih untuknya. Penagihan dihitung per fitur yang selesai, sehingga langkah yang tidak pernah berjalan tidak dikenai biaya.
#Menggunakan urutan aturan untuk mengendalikan biaya
Karena sebuah decline menghentikan alurnya, urutan langkah adalah tuas pengeluaran. Menempatkan pemeriksaan risiko yang murah di depan bundel yang mahal berarti trafik yang memang tidak akan pernah lolos berhenti sebelum Anda membayar bagian yang mahal itu.
Analisis perangkat dan IP seharga $0,03 di depan alur KYC penuh adalah contoh standarnya: ia menyaring trafik yang memang akan Anda tolak, dengan murah.
Trade-off-nya adalah pengalaman pengguna dan false positive. Sinyal perangkat dan IP adalah pemeriksaan paling bising yang ditawarkan Didit - jaringan korporat, NAT operator, dan browser cloud semuanya menempatkan pengguna asli di balik alamat yang dipakai bersama. Menggerbangi seluruh alur berdasarkan sinyal ini akan memblokir pelanggan sungguhan, jadi arahkan ke review alih-alih decline kecuali Anda sudah mengukur trafik Anda sendiri.
#Aturan yang butuh pertimbangan, bukan otomatisasi
Beberapa warning tidak ambigu dan sebaiknya di-decline: checksum MRZ yang gagal, chip yang signature-nya tidak berantai ke penerbitnya, wajah yang ada di blocklist Anda. Itu semua adalah kegagalan integritas.
Yang lain hampir selalu lebih baik sebagai review:
- Kecocokan alamat sebagian pada bukti alamat - formatnya berbeda-beda per negara.
- Kecocokan nama sebagian pada validasi database - sumber otoritatif mencatat nama secara berbeda-beda.
- Hit kandidat AML dengan keyakinan rendah - nama umum terus-menerus memicunya.
- Face match yang batas-batas (borderline) - lihat skor dan ambang batas face match.
- Flag wajah duplikat - yang berarti penipuan untuk akun baru dan wajar untuk pelanggan yang kembali.
Dan beberapa adalah kegagalan usability yang layak diberi retry, bukan vonis: chip NFC yang tidak terbaca, capture yang buram, frame kamera yang terputus.
#Kebijakan usia
Usia minimum dan maksimum dikonfigurasi per workflow, dan tindakan atas pelanggarannya adalah pilihan Anda. MINIMUM_AGE_NOT_MET bisa langsung decline, atau diarahkan ke review jika kebijakan Anda mengizinkan pengecualian dengan bukti. Keduanya sah; pilih dengan sengaja.
#Aturan custom pada data yang diekstrak
Selain pemetaan per-warning, Anda bisa menulis aturan terhadap data yang diekstrak oleh sebuah langkah - misalnya, men-decline ketika sebuah field yang diekstrak bernilai tertentu. Dua hal yang perlu diingat:
- Aturan tersebut hanya bisa bekerja pada data yang benar-benar dihasilkan oleh langkah itu. Jika OCR tidak mengekstrak field-nya, aturan itu tidak punya apa pun untuk dievaluasi.
- Aturan yang men-decline tetap menghentikan workflow, dengan konsekuensi yang sama seperti di atas.
Jika Anda membangun aturan yang menyasar karakteristik yang dilindungi, perlakukan itu sebagai pertanyaan hukum untuk tim compliance Anda sebelum menjadi pertanyaan engineering.
#Uji aturannya, bukan cuma langkah-langkahnya
Langkah-langkah sebuah workflow mudah diperiksa dengan mata. Aturannya tidak - satu-satunya cara untuk mengetahui bahwa sebuah warning diarahkan ke tempat yang Anda kira adalah dengan benar-benar memunculkan warning tersebut.
Sandbox ada untuk ini. Setiap skenario memaksa satu warning tertentu, sehingga Anda bisa memastikan tindakan setiap aturan secara end-to-end: decline_document_expired, review_face_match_borderline, decline_aml_hit, review_poa_partial_match, dan seterusnya. Lihat menguji di sandbox.
Uji jalur review sama telitinya seperti jalur decline. Aturan yang mengarah ke review baru berguna jika ada orang yang benar-benar mengerjakan antreannya, dan cara mengetahui apakah proses review Anda berfungsi adalah dengan menjalankan sebuah sesi sintetis lewat proses itu sebelum pelanggan sungguhan sedang menunggu.
#Perubahan berlaku untuk sesi baru
Mengedit sebuah workflow tidak mengubah sesi yang sudah dibuat secara retroaktif. Sebuah sesi membawa konfigurasi saat ia dibuat, jadi setelah mengubah sebuah aturan, uji dengan sesi baru alih-alih memeriksa ulang sesi lama.