Penyebaran Daftar Blokir: Menjadikan Satu Kasus Penyalahgunaan yang Terkonfirmasi Melumpuhkan Seluruh Jaringan (ID)

Ada momen spesifik di mana sebagian besar program penyalahgunaan kehilangan nilainya: momen setelah Anda menang.

Lapisan lalu lintas Anda menandai sebuah akun. Seorang analis menyelidiki. Buktinya kuat, kasusnya terkonfirmasi, akunnya diblokir. Dan kemudian, beberapa jam kemudian, operator yang sama kembali dengan akun baru, karena satu-satunya hal yang disentuh oleh penegakan Anda adalah satu baris di tabel pengguna.

Anthropic menggambarkan dinamika ini dengan tepat dalam laporannya pada Februari 2026 tentang kampanye distilasi — jaringan proxy yang "mengelola lebih dari 20.000 akun penipuan secara bersamaan," menggantinya saat dihapus. Penghapusan bukanlah hambatan. Regenerasi lebih murah daripada penghapusan.

Solusinya adalah membuat penegakan beroperasi pada pengenal, bukan akun. API Daftar Didit dibangun di sekitar satu mekanisme yang melakukan ini dalam satu panggilan.

Poin-poin penting

• Memblokir dengan reference_session_id membuat Didit secara otomatis mengekstrak nilai yang tepat dari sesi — wajah, dokumen, telepon, email, IP, atau perangkat — menandai model yang mendasari sebagai diblokir, dan menautkan entri kembali ke sesi sumber.
• 12 jenis entri: face, document, phone, email, ip_address, device_fingerprint, wallet_address, bank_account, user, business, country, key.
• Daftar blokir dibuat oleh sistem, satu per jenis entri, dan tidak dapat diubah. Anda tidak dapat membuatnya, itulah yang membuat penegakan seragam.
• Entri berlaku segera pada saat verifikasi. Menghapus entri akan membuka blokir kecocokan.
• ip_address menerima rentang CIDR, sehingga Anda dapat memblokir infrastruktur daripada satu alamat.
• Daftar izin di seluruh 12 jenis yang sama menjaga pengembang tepercaya dari setiap jalur eskalasi.

Dua jenis daftar yang penting

API memiliki tiga jenis daftar, dan perbedaan di antaranya disengaja.

Daftar blokir dibuat oleh sistem — satu per jenis entri — dan tidak dapat diubah. Anda tidak dapat membuatnya, mengganti namanya, atau menghapusnya. Anda menambah dan menghapus entri. Batasan itu adalah fitur: itu berarti "diblokir" memiliki satu arti yang sama di seluruh organisasi Anda, dan tidak ada cara untuk memiliki empat daftar blokir wajah yang bersaing yang diperiksa secara tidak konsisten oleh layanan yang berbeda.

Daftar izin dapat Anda buat sendiri. Perangkat yang diketahui baik, rentang alamat, entitas bisnis, dan pengguna masuk ke sini.

Daftar kustom adalah untuk hal lain — taksonomi Anda sendiri, grup pengawasan, kohort ulasan.

# Temukan daftar blokir wajah
curl -X GET 'https://verification.didit.me/v3/lists/?list_type=blocklist&entry_type=face' \
  -H 'x-api-key: YOUR_API_KEY'

Mekanisme yang penting

Berikut adalah cara biasa untuk memblokir sesuatu, dan itu adalah cara yang salah di hampir setiap situasi nyata:

curl -X POST 'https://verification.didit.me/v3/lists/{list_uuid}/entries/' \
  -H 'x-api-key: YOUR_API_KEY' \
  -H 'Content-Type: application/json' \
  -d '{ "value": "203.0.113.44" }'

Itu memblokir satu alamat. Sementara itu, sesi yang Anda selidiki juga membawa wajah, nomor dokumen, telepon, email, dan sidik jari perangkat — setiap pengenal tersebut harus diganti oleh operator sebelum kembali.

Panggilan yang lebih baik:

curl -X POST 'https://verification.didit.me/v3/lists/{list_uuid}/entries/' \
  -H 'x-api-key: YOUR_API_KEY' \
  -H 'Content-Type: application/json' \
  -d '{ "reference_session_id": "a7f3...c19" }'

Lewati reference_session_id dan Didit secara otomatis mengekstrak nilai yang tepat untuk jenis entri daftar tersebut dari sesi, menandai model yang mendasari sebagai diblokir, dan menautkan entri kembali ke sesi sehingga konsol dapat menunjukkan dari mana asalnya.

Tiga hal yang muncul dari itu, dan ketiganya penting secara operasional:

Tidak ada ekstraksi manual. Analis Anda tidak membaca sidik jari perangkat dari layar dan mengetiknya ulang. Kesalahan transkripsi dalam data penegakan adalah kegagalan diam-diam — larangan tersebut tidak berlaku, dan tidak ada yang mengetahuinya.

Asal-usul dipertahankan. Setiap entri menautkan kembali ke sesi yang membenarkannya. Ketika seseorang bertanya dalam empat bulan mengapa perangkat ini diblokir, jawabannya adalah satu klik, bukan proyek arkeologi.

Penegakan dapat diulang. Panggilan yang sama terhadap setiap daftar blokir jenis entri mencakup seluruh permukaan pengenal sesi.

Jika satu sesi berisi beberapa instans dari jenis yang sama, lewati value bersama dengan reference_session_id untuk menghilangkan ambiguitas.

Anda juga dapat melakukan penegakan dari luar sesi verifikasi. reference_object_uuid bersama dengan metadata.reference_type — transaction, vendor_user, atau vendor_business — memblokir dari transaksi atau dari pengguna atau bisnis vendor, dan menjaga tautan yang sama kembali ke sumber.

12 jenis entri

Jenis entri	Memblokir	Catatan
face	Orang tersebut	Juga dapat dimuat langsung melalui unggahan wajah
document	Kredensial
phone	Nomor	Otomatis dinormalisasi ke E.164
email	Alamat
ip_address	Alamat atau rentang	Menerima CIDR, mis. 10.0.0.0/8
device_fingerprint	Mesin	Minimum 8 karakter alfanumerik
wallet_address	Alamat on-chain
bank_account	Akun
user	Catatan pengguna
business	Entitas
country	Yurisdiksi
key	Kunci kustom

Dua hal patut diperhatikan untuk masalah ini.

ip_address menerima rentang CIDR. Memblokir 203.0.113.0/24 memblokir infrastruktur, bukan satu alamat. Ketika operasi farming berjalan di subnet sewaan, inilah perbedaan antara penegakan yang skalabel dan penegakan yang bermain whack-a-mole. Gunakan dengan hati-hati — suatu rentang juga mencakup pengguna nyata, dan rentang yang terlalu luas adalah cara Anda secara diam-diam memblokir operator seluler suatu negara.

face mendukung unggahan langsung. Jika Anda memiliki gambar tetapi tidak ada sesi, muat langsung:

curl -X POST 'https://verification.didit.me/v3/lists/{list_uuid}/entries/face-upload/' \
  -H 'x-api-key: YOUR_API_KEY' \
  -H 'Content-Type: application/json' \
  -d '{ "image": "<base64-encoded image>" }'

Didit mengekstrak biometrik. Sejak saat itu, wajah itu akan disaring pada setiap verifikasi.

Apa yang terjadi setelah sebuah entri mendarat

Menambahkan ke daftar blokir sistem akan memblokir kecocokan di masa mendatang segera pada saat verifikasi. Tidak ada penundaan penyebaran dan tidak ada pekerjaan batch.

Pada verifikasi berikutnya, penegakan muncul sebagai peringatan:

• FACE_IN_BLOCKLIST — kecocokan definitif, verifikasi ditolak. POSSIBLE_FACE_IN_BLOCKLIST adalah kecocokan batas di bawah ambang batas keras dan harus diarahkan untuk ditinjau, bukan ditolak.
• IP_ADDRESS_IN_BLOCKLIST / DEVICE_FINGERPRINT_IN_BLOCKLIST — hit jaringan dan perangkat.

Dalam Pencarian Wajah, kecocokan daftar blokir adalah satu-satunya hal yang mengatur status menjadi "Declined". Setiap kecocokan dalam respons juga membawa is_blocklisted, sehingga penyelidikan akan segera menunjukkan kepada Anda bagian mana dari klaster yang sudah dalam penegakan dan mana yang masih aktif.

Penghapusan bersifat simetris: menghapus entri akan membuka blokir entitas yang cocok. Penegakan dapat dibatalkan berdasarkan desain, yang penting karena penegakan yang terlalu luas adalah risiko nyata dan Anda memerlukan jalur yang bersih untuk kembali.

curl -X DELETE 'https://verification.didit.me/v3/lists/{list_uuid}/entries/{entry_uuid}/' \
  -H 'x-api-key: YOUR_API_KEY'

Daftar Izin: melindungi pengembang yang Anda inginkan

Penegakan yang hanya meningkat pada akhirnya akan mencekik produk. 12 jenis entri yang sama mendukung daftar izin, dan itu adalah katup pengaman.

Izinkan rentang IP kantor mitra desain. Izinkan perangkat tim teknik pelanggan perusahaan. Izinkan entitas bisnis yang terverifikasi sehingga penggunanya tidak pernah masuk ke jalur eskalasi. IP_ADDRESS_IN_ALLOWLIST dan DEVICE_FINGERPRINT_IN_ALLOWLIST aktif ketika kecocokan terjadi, sehingga Anda dapat mengkonfirmasi bahwa pengecualian diterapkan daripada mengasumsikannya.

Ini adalah mekanisme yang membuat penegakan agresif dapat bertahan. Anda dapat menerapkan kebijakan ketat pada infrastruktur yang tidak dikenal justru karena populasi Anda yang diketahui baik secara eksplisit dikecualikan.

Kesalahan yang perlu ditangani

• 400 — nilai gagal dalam validator jenis entri, list_type salah untuk operasi (misalnya, unggahan wajah terhadap daftar non-wajah), atau reference_session_id tidak memiliki data dari jenis yang diminta. Kasus terakhir umum dan tidak berbahaya: tidak setiap sesi menangkap setiap pengenal.
• 403 — {"detail": "Anda tidak memiliki izin untuk melakukan tindakan ini."}

Perhatikan bahwa 400 dari "sesi tidak memiliki data dari jenis itu" diharapkan ketika Anda mengulang sesi di semua daftar blokir jenis entri. Tangani sebagai lewati, bukan kegagalan.

Alur penegakan yang berhasil

Seorang analis telah mengkonfirmasi penyalahgunaan pada akun acct_8842.

1. Selesaikan klaster terlebih dahulu. Pencarian Wajah pada wajah sesi mengembalikan dua belas akun; korelasi perangkat dan IP menarik selusin lainnya. Penegakan sebelum resolusi memblokir satu akun dan memperingatkan operator.
2. Blokir dari sesi yang dikonfirmasi — reference_session_id terhadap daftar blokir wajah, perangkat, IP, email, telepon, dan dokumen. Enam panggilan, tanpa ekstraksi manual, asal-usul lengkap.
3. Pertimbangkan rentangnya. Jika bukti jaringan menunjukkan infrastruktur sewaan, entri CIDR mencakup subnet. Periksa apa lagi yang ada di sana terlebih dahulu.
4. Bertindak pada klaster sesuai dengan kebijakan Anda sendiri — akun yang sudah Anda identifikasi tidak akan membuka blokir sendiri.
5. Verifikasi penegakan. Jalankan kembali pencarian wajah. Kecocokan sekarang harus membawa is_blocklisted: true.
6. Tunggu upaya regenerasi. Akun berikutnya yang dibuat pada wajah, perangkat, atau subnet itu ditolak pada verifikasi alih-alih muncul dalam lalu lintas Anda tiga minggu kemudian.

Langkah 6 adalah intinya. Biaya operator untuk kembali tidak lagi "membuat alamat email baru." Ini adalah "memperoleh perangkat keras baru, jaringan baru, dan orang baru."

Kasus penggunaan

Platform API AI mengubah kasus distilasi atau penyalahgunaan yang dikonfirmasi menjadi penegakan di setiap pengenal yang disentuh operator.

Penyalahgunaan uji coba dan kredit di mana perangkat dan wajah yang sama terus kembali untuk alokasi gratis yang baru.

Pasar memblokir penjual yang dihapus agar tidak mendaftar ulang di bawah bisnis baru.

iGaming memberlakukan pengecualian diri, di mana pemain yang dikecualikan yang kembali adalah kegagalan regulasi dan penegakan tingkat wajah adalah satu-satunya kontrol yang andal.

Pertanyaan yang sering diajukan

Bisakah saya membuat daftar blokir sendiri?

Tidak. Daftar blokir dibuat oleh sistem, satu per jenis entri, dan tidak dapat diubah — Anda menambah dan menghapus entri. Anda dapat membuat daftar izin dan daftar kustom dengan bebas. Batasan ini menjaga arti "diblokir" tetap sama di mana-mana.

Seberapa cepat sebuah entri berlaku?

Segera, pada verifikasi berikutnya.

Bagaimana jika saya memblokir sesuatu secara tidak sengaja?

Hapus entri dan entitas akan dibuka blokirnya. Inilah mengapa asal-usul itu penting — setiap entri yang dibuat dari sesi menautkan kembali ke sana, sehingga Anda dapat mengaudit tujuan sebuah entri sebelum menghapusnya.

Apakah memblokir rentang IP memengaruhi pengguna sah dalam rentang tersebut?

Ya, dan itulah risikonya. Entri CIDR memblokir segala sesuatu di dalamnya. Gunakan rentang ketika bukti menunjukkan infrastruktur khusus, gunakan alamat tunggal jika tidak, dan izinkan rentang yang diketahui baik terlebih dahulu.

Bisakah saya memblokir dari sesuatu yang bukan sesi verifikasi?

Ya. reference_object_uuid ditambah metadata.reference_type (transaction, vendor_user, atau vendor_business) mencakup transaksi dan pengguna atau bisnis vendor.

Apakah ini menghentikan ekstraksi model?

Tidak. Ini menghentikan aktor tertentu yang diketahui untuk masuk kembali melalui pengenal yang telah Anda terapkan penegakannya, dan ini meningkatkan biaya regenerasi. Mendeteksi ekstraksi sejak awal adalah tugas lapisan lalu lintas Anda, dan membatasi hasil ekstraksi adalah tugas lapisan model Anda. Ini adalah lengan penegakan dari pertahanan tiga lapis, bukan pengganti dua lainnya.

Siap untuk memulai?

API Daftar tersedia di setiap akun Didit.

• Baca dokumen — Ikhtisar API Daftar dan katalog peringatan IP & Perangkat.
• Lihat produknya — Verifikasi Pengguna.
• Periksa harga — terdaftar secara publik, bayar per keberhasilan, tanpa minimum.
• Mulai gratis — business.didit.me, 500 verifikasi KYC per bulan tanpa biaya.