Aturan Pemantauan Transaksi: Velocity & Kondisi

Setiap transaksi yang dikirim ke Didit dievaluasi terhadap semua aturan aktif untuk aplikasi Anda. Aturan menentukan kondisi, pemeriksaan kecepatan, dan tindakan yang menentukan status akhir dan skor transaksi. Bab ini dalam pelajaran mesin aturan penipuan di Didit Academy melanjutkan dengan pembuatan aturan. Pelajaran mesin aturan di Academy menunjukkan pembuatan aturan di kamera pada menit 7:54: pemicu, kondisi, tindakan, dan penilaian, lalu pengujian balik sebelum diterapkan.

​

Bundel aturan bawaan

Didit menyediakan pustaka aturan yang sudah dikonfigurasi sebelumnya dan mencakup tipologi regulasi yang umum. Pasang prasetel (atau seluruh bundel) yang Anda inginkan dari pustaka, baik di konsol, melalui API pemasangan, maupun dengan alat MCP, lalu atur mode setiap prasetel yang terpasang. Untuk katalog lengkap setiap aturan prasetel beserta ambang batas dan tindakannya, lihat Pustaka aturan.

​

Sumber aturan

Setiap aturan memiliki source yang menunjukkan siapa yang mengelolanya:

​

Anatomi aturan

Setiap aturan terdiri dari:

​

Tindakan

Ketika sebuah aturan cocok dengan transaksi, satu atau beberapa tindakan dijalankan. Setiap aturan dapat memiliki beberapa tindakan yang semuanya diterapkan bersamaan: Sebagian besar aturan preset menggabungkan Tambah skor dengan Ubah status, misalnya aturan pihak lawan yang terkena sanksi yang menambahkan 90 poin ke skor dan langsung menolak transaksi.

​

Mewajibkan verifikasi pengguna (AWAITING_USER)

Tindakan Ubah status → AWAITING_USER melakukan lebih dari sekadar mengatur status: Didit secara otomatis membuat sesi verifikasi yang di-hosting untuk subjek transaksi (vendor_data yang sama) pada saat aturan terpicu. Sesi tersebut dikembalikan dalam blok action_required transaksi (dan dalam objek remediation) pada respons pembuatan dan setiap pembacaan berikutnya, serta di kedua webhook transaksi, sehingga Anda dapat langsung mengarahkan pengguna; lihat tindakan pengguna yang diperlukan. Aturan kustom harus menyebutkan alur kerja pada tindakan itu sendiri (workflow_id); baik pembuat aturan di konsol maupun API aturan mewajibkannya. Aturan pustaka bawaan tidak memiliki alur kerja; untuk aturan tersebut, alur kerja sesi ditentukan dengan urutan berikut:

1. Alur kerja remediasi yang dikonfigurasi di pengaturan transaksi Anda.
2. Alur kerja Autentikasi Biometrik aplikasi Anda, jika subjek sudah memiliki wajah referensi yang tersimpan dari verifikasi yang disetujui.
3. Alur kerja default aplikasi Anda.

Artinya, aturan pustaka AWAITING_USER selalu menghasilkan sesi yang dapat ditindaklanjuti sejak awal: langkah biometrik tambahan untuk pengguna yang sudah Anda verifikasi, atau verifikasi penuh untuk yang lainnya. Transaksi Travel Rule dikecualikan dari fallback otomatis ini; status menunggu AWAITING_USER untuk transaksi tersebut ditujukan untuk bukti kepemilikan dompet, yang memiliki alurnya sendiri. Untuk transaksi berisiko tinggi, pilihan yang paling kuat adalah alur kerja Autentikasi Biometrik: karena subjeknya adalah pengguna yang sudah Anda KYC, Didit menggunakan ulang wajah referensi yang telah diverifikasi dari proses onboarding mereka (swafoto liveness yang disetujui, foto chip paspor, atau potret dokumen). Pengguna cukup mengambil satu swafoto langsung, dan Didit menjalankan liveness serta pencocokan wajah 1:1 terhadap identitas yang membuka akun. Kredensial yang dicuri, OTP hasil phishing, dan penukaran SIM semuanya gagal di gerbang ini. Panduan lengkap: biometrik tambahan untuk penarikan bernilai tinggi. Ketika sesi mencapai keputusan, transaksi mengikutinya secara otomatis dan webhook transaction.status.updated terpicu: sesi yang disetujui menyetujui transaksi (decision_reason_code: user_action_approved), sesi yang ditolak menolak transaksi (user_action_declined), dan sesi yang berakhir dengan peninjauan akan mengirim transaksi ke IN_REVIEW (user_action_in_review). Sesi yang kedaluwarsa atau ditinggalkan membuat transaksi tetap berada di AWAITING_USER.

​

Penilaian

Ketika sebuah transaksi cocok dengan satu atau beberapa aturan, skornya digabungkan:

1. Setiap aturan yang cocok berkontribusi pada skor risiko keseluruhan transaksi melalui tindakan add_score
2. Skor akhir menentukan status transaksi berdasarkan ambang batas skor aplikasi Anda
3. Jika ada aturan dengan tindakan change_status, status tersebut langsung diterapkan; DECLINED selalu didahulukan

Ambang batas skor default (dapat dikonfigurasi di konsol):

​

Membuat aturan kustom

Aturan kustom dapat dibuat dari Konsol Bisnis atau melalui API Manajemen (juga dapat diakses dari Didit MCP dan asisten AI apa pun yang terhubung dengan MCP). Aturan dalam mode Active berlaku segera untuk semua transaksi baru. Judul bersifat unik per aplikasi.

​

Pengujian historis

Sebelum mengaktifkan aturan, Anda dapat memvalidasinya terhadap data historis:

• Atur aturan ke mode Test: aturan dievaluasi pada setiap transaksi baru, tetapi hasilnya tidak memengaruhi status atau skor transaksi. Statistik eksekusi (jumlah yang cocok, entitas terdampak) terakumulasi sehingga Anda dapat menilai dampaknya sebelum aturan berjalan secara langsung.
• Gunakan fitur pengujian historis - di konsol atau melalui POST /v3/transactions/rules/backtest/ - untuk mengevaluasi kembali kondisi dan agregasi aturan terhadap transaksi dari periode tertentu. Pengujian historis mengembalikan jumlah transaksi yang dievaluasi, yang cocok, dan entitas terdampak, tanpa mengubah data historis apa pun. Kirim conditions, aggregation, evaluation_mode dan scope yang sama dengan aturan yang akan Anda aktifkan: scope yang dihilangkan berarti tanpa batasan, sehingga backtest akan menghitung transaksi yang dilewati oleh aturan tersimpan.

​

Jendela laju (agregasi)

Aturan laju mengagregasi data transaksi historis dalam jangka waktu tertentu untuk mendeteksi pola yang tidak dapat ditangkap oleh pemeriksaan satu transaksi. Setiap agregasi menentukan:

• Jendela waktu: <N>m (menit), <N>h (jam), atau <N>d (hari), misalnya 30m, 6h, 7d, 30d. Perhatian: m berarti menit, bukan bulan.
• Filter untuk mempersempit transaksi historis yang disertakan. Kuncinya adalah path kolom dari katalog kolom. Nilai khusus "__current__" merujuk pada nilai kolom yang sama pada transaksi yang sedang dievaluasi (misalnya "subject_vendor_data": "__current__" membatasi jendela ke subjek yang sama), dan nilai berupa daftar berarti keanggotaan. Filter hanya membandingkan berdasarkan kesamaan atau keanggotaan. Tidak ada filter lt/gte, sehingga rentang seperti transaksi di bawah 10,000 tidak dapat dinyatakan dengan filter. Letakkan rentang pada metrik (max di bawah 10,000, min di atas 1,000), dan ingat bahwa kondisi membatasi transaksi yang sedang dievaluasi, bukan jendela.
• Operator dan ambang batas (eq, ne, gt, gte, lt, lte terhadap value, misalnya jumlah >= 20)

​

Contoh pola

​

Katalog kolom

Kondisi dan filter agregasi merujuk ke kolom transaksi berdasarkan path:

​

Operator kondisi

Aturan mendukung operator perbandingan berikut untuk kondisi: Setiap operator lain memerlukan value yang tidak kosong, dan API merespons 400 jika tidak ada. contains, not_contains dan regex menerima satu string, bukan daftar atau objek; contains_any menerima daftar string.

​

Tipe nilai kondisi

value_type opsional pada kondisi mengubah cara value ditafsirkan:

​

Kondisi berkelompok

Daftar kondisi datar digabungkan sesuai evaluation_mode aturan (ALL/ANY). Untuk logika campuran, berikan group_index pada kondisi: kondisi dengan indeks yang sama membentuk satu grup, group_logic (AND/OR, default AND) menggabungkan kondisi di dalam grup, dan groups_logic pada kondisi pertama (AND/OR, default OR) menggabungkan hasil grup. Jika ada kondisi yang memiliki group_index, evaluasi berkelompok menggantikan evaluation_mode.

​

Merujuk properti kustom

Setiap kunci yang dikirim dalam objek custom_properties pada POST /v3/transactions/ disimpan pada transaksi sebagai custom_values dan dapat digunakan dalam kondisi dengan jalur kolom custom_values.<key>. Misalnya, transaksi yang dikirim dengan "custom_properties": {"channel": "mobile_app"} cocok dengan kondisi custom_values.channel eq "mobile_app". Semua operator di atas berfungsi dengan properti kustom, dan properti tersebut juga dapat dibandingkan dengan kolom lain atau digunakan dalam filter kecepatan. Di pembuat aturan Console, kunci yang tercatat pada transaksi yang baru masuk akan muncul otomatis di pemilih kolom kondisi di bawah Properti khusus. Anda juga dapat merujuk kunci sebelum transaksi mana pun memilikinya: pilih Masukkan properti kustom di grup yang sama dan ketik kunci persis seperti yang dikirim integrasi Anda (kunci peka huruf besar-kecil). Aturan akan dievaluasi sebagai tidak cocok sampai transaksi yang membawa kunci tersebut masuk.

​

Penolakan otomatis oleh daftar blokir

Sebelum aturan apa pun dievaluasi, Didit memeriksa entitas transaksi terhadap daftar blokir aplikasi Anda. Jika ada kecocokan, transaksi langsung ditolak: aturan tidak dievaluasi. Entitas berikut diperiksa: Ketika terjadi kecocokan dengan daftar blokir:

• Status transaksi diatur menjadi DECLINED
• Alasan keputusan diatur menjadi blocklisted
• Catatan aktivitas dibuat untuk pelacakan audit

​

Skrining transaksi

Didit terintegrasi dengan penyedia analitik AML dan blockchain eksternal untuk memperkaya transaksi dengan intelijen risiko. Saat transaksi dikirim, sistem dapat:

• Menskrining pihak lawan terhadap basis data sanksi dan daftar pantauan global
• Menilai alamat dompet (untuk transaksi kripto) terhadap data intelijen blockchain, termasuk paparan mixer, koneksi ke entitas yang terkena sanksi, dan interaksi dengan layanan berisiko tinggi
• Memeriksa status AML pemohon dengan mencocokkan pengguna yang terhubung dengan transaksi terhadap hasil skrining AML terbarunya

Hasil skrining dilampirkan pada transaksi dan memengaruhi penilaian mesin aturan. Jika pihak lawan atau dompet cocok dengan daftar sanksi, aturan yang sesuai secara otomatis menandai atau menolak transaksi.

​

Langkah selanjutnya