> ## Documentation Index
> Fetch the complete documentation index at: https://docs.didit.me/llms.txt
> Use this file to discover all available pages before exploring further.

# Aturan Pemantauan Transaksi: Velocity & Kondisi

> Atur aturan pemantauan transaksi di Didit dengan kondisi, velocity, dan tindakan otomatis. 1,000 per bulan termasuk, lalu $0.001 per panggilan.

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.

[Membuat aturan - Didit Academy](https://www.youtube.com/embed/Yhm63_n7HuU?start=474\&rel=0\&playsinline=1)

> [!NOTE]
>
> Aturan dapat dikelola dari **Konsol Bisnis**, **Management API**, dan **Didit MCP**. Gunakan konsol saat anggota tim kepatuhan Anda perlu meninjau setiap perubahan; gunakan API atau MCP saat aturan dibuat dan disesuaikan secara terprogram, misalnya saat memindahkan kumpulan aturan dari penyedia lain. Lihat [referensi API](https://docs.didit.me/id/management-api/transactions/rules-list.md) dan [panduan mengelola aturan melalui API dan MCP](https://docs.didit.me/id/transaction-monitoring/rules-api.md). Aturan dievaluasi pada setiap transaksi yang dikirim melalui [`POST /v3/transactions/`](https://docs.didit.me/id/management-api/transactions/create), dan hasilnya muncul di larik `rule_runs[]` transaksi tersebut (lihat [skema respons](https://docs.didit.me/id/transaction-monitoring/response-schema.md)).

## 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](https://docs.didit.me/id/management-api/transactions/rules-install.md), 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](https://docs.didit.me/id/transaction-monitoring/rules-library.md).

| Bundel | Contoh |
| - | - |
| **Keuangan** | Deteksi pemecahan transaksi (masuk/keluar), transaksi tunggal besar di atas ambang pelaporan |
| **AML/CTF** | Batas volume kumulatif, pergerakan masuk dan keluar yang cepat, pencocokan pihak lawan dengan daftar sanksi, kata kunci referensi pembayaran yang mencurigakan |
| **Deteksi anomali** | Aktivitas masuk/keluar berfrekuensi tinggi, aktivasi kembali akun tidak aktif setelah 12+ bulan tidak aktif |
| **FATF** | Paparan yurisdiksi berisiko tinggi untuk pihak lawan dan alamat subjek |
| **Intelijen Perangkat** | Penggunaan kampanye bonus berulang dari sidik jari perangkat yang sama, beberapa sidik jari perangkat untuk subjek yang sama |
| **Pencegahan penipuan** | Pembuatan banyak akun melalui sidik jari perangkat yang sama di antara subjek yang berbeda |
| **Pemantauan kripto** | Paparan layanan pencampuran/pengaburan, alamat dompet berisiko tinggi (darknet, yang dikenai sanksi, dana curian) |
| **Skrining kripto** | Paparan terhadap sumber dana berisiko tinggi (>30%), beberapa pihak lawan berisiko, penolakan otomatis untuk pendanaan terorisme / eksploitasi anak, penahanan sambil menunggu skrining, penandaan skor risiko dompet menengah |
| **Permainan Bertanggung Jawab** | Lonjakan setoran cepat dalam jendela waktu singkat |
| **E-commerce** | Pola transaksi khusus perdagangan elektronik |

## Sumber aturan

Setiap aturan memiliki `source` yang menunjukkan siapa yang mengelolanya:

| Sumber | Deskripsi |
| - | - |
| **Prasetel** | Aturan yang dipasang dari pustaka bawaan Didit. Anda memilih prasetel mana (atau bundel mana) yang akan dipasang, dan Anda mengontrol mode setiap prasetel yang terpasang (`Active`, `Test`, `Disabled`). Kondisi dan ambang batasnya tetap; untuk menimpanya, buat aturan kustom. Prasetel dihapus dengan cara dicopot pemasangannya, bukan dihapus. |
| **Kustom** | Aturan yang dibuat tim Anda dari Konsol Bisnis. Anda memiliki kendali penuh atas aturan kustom: membuat, mengedit, dan menghapus sesuai kebutuhan. |

## Anatomi aturan

Setiap aturan terdiri dari:

| Komponen | Deskripsi |
| - | - |
| **Judul & deskripsi** | Nama yang dapat dibaca manusia dan penjelasan tentang hal yang dideteksi oleh aturan |
| **Kategori** | Pengelompokan logis (misalnya `finance`, `aml_ctf`, `crypto_monitoring`, `device_intelligence`) |
| **Mode** | `Active` (evaluasi langsung), `Disabled` (dilewati), atau `Test` (dievaluasi tetapi hasilnya tidak memengaruhi transaksi) |
| **Mode evaluasi** | `All` (setiap kondisi harus cocok) atau `Any` (setidaknya satu kondisi harus cocok) |
| **Cakupan** | Membatasi transaksi yang dikenai aturan tersebut. Kunci: `transaction_types`, `directions` (`INBOUND`/`OUTBOUND`), `action_types`. Jika kosong atau tidak ada, berarti tidak ada batasan |
| **Kondisi** | Pemeriksaan tingkat kolom yang membandingkan kolom transaksi dengan nilai menggunakan operator seperti `eq`, `lt`, `gte`, `in`, `contains_any`, `exists` |
| **Agregasi** | Jendela kecepatan: mengagregasi transaksi historis dalam periode waktu tertentu (misalnya jumlah, total, atau jumlah unik dalam 1 jam, 7 hari, 30 hari) |
| **Tindakan** | Apa yang terjadi saat aturan terpenuhi (lihat di bawah) |

## Tindakan

Ketika sebuah aturan cocok dengan transaksi, satu atau beberapa tindakan dijalankan. Setiap aturan dapat memiliki beberapa tindakan yang semuanya diterapkan bersamaan:

| Tindakan | `type` | Kunci | Deskripsi |
| - | - | - | - |
| **Tambah skor** | `add_score` | `value` (integer, boleh negatif) | Menambahkan poin ke skor risiko transaksi. Skor kumulatif dari semua aturan yang cocok menentukan apakah transaksi melampaui ambang batas peninjauan atau ambang batas penolakan. |
| **Ubah status** | `change_status` | `value` (`APPROVED`\|`IN_REVIEW`\|`DECLINED`\|`AWAITING_USER`, alias `status`), `workflow_id` (alias `remediation_workflow_id`) | Langsung mengatur status transaksi, terlepas dari skor. `workflow_id` wajib diisi saat `value` adalah `AWAITING_USER`; jika dihilangkan, akan mengembalikan `400`. |
| **Tambahkan tag** | `add_tags` | `tag_uuid` atau `tag_name` (salah satu), `tag_color` | Memberi tag pada transaksi untuk kategorisasi dan pemfilteran. Berupa `tag_uuid` dari tag yang sudah ada, atau `tag_name` yang dibuat saat pertama kali digunakan (disimpan dalam huruf kapital); `tag_color` menetapkan warna hex untuk tag yang baru dibuat. |
| **Tambah catatan** | `add_note` | `note` (alias `value`) | Melampirkan catatan teks otomatis pada transaksi sebagai konteks bagi analis. |
| **Tambahkan ke daftar** | `add_to_list` | `list_id` | Menambahkan `vendor_data` subjek ke daftar blokir, daftar izin, atau daftar kustom. |
| **Buka kasus** | `open_case` | `blueprint` (UUID blueprint kasus, opsional), `grouping` (`by_applicant`\|`by_rule_and_applicant`), `attach_matched_transaction` (boolean) | Membuka (atau menambahkan ke) kasus investigasi. Hanya tindakan `open_case` pertama pada sebuah aturan yang diterapkan. |

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](https://docs.didit.me/id/transaction-monitoring/sdk-transaction-submission.md#tindakan-yang-diperlukan-pengguna).

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](https://docs.didit.me/id/transaction-monitoring/settings.md#alur-kerja-remediasi) 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](https://docs.didit.me/id/transaction-monitoring/wallet-ownership-widget.md).

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](https://docs.didit.me/id/transaction-monitoring/sdk-transaction-submission.md#contoh-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`.

> [!NOTE]
>
> Setiap jenis alur kerja selain KYB dapat digunakan sebagai tindakan remediasi.
> Alur kerja Autentikasi Biometrik (dan alur kerja yang menjalankan pencocokan wajah sebelum verifikasi identitas) juga memerlukan wajah referensi yang tersimpan untuk subjek: swafoto liveness yang disetujui, foto chip paspor, potret dokumen, atau wajah profil yang didaftarkan secara manual.
> Jika tidak ada, pengguna diminta untuk menyelesaikan alur kerja default aplikasi Anda; alur ini juga mendaftarkan wajah mereka untuk lain kali, dan sebuah catatan pada transaksi mencatat penggantian tersebut.
> Hanya jika tidak ada alur kerja default yang sesuai, sesi akan dilewati, dengan catatan yang menjelaskan alasannya.

## 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):

| Pengaturan | Default | Deskripsi |
| - | - | - |
| **Ambang batas peninjauan** | 75 | Skor yang sama dengan atau lebih tinggi dari nilai ini memicu `IN_REVIEW` |
| **Ambang batas penolakan** | 500 | Skor yang sama dengan atau lebih tinggi dari nilai ini memicu `DECLINED`. Ambang batas default (`500`) tidak pernah menyebabkan transaksi ditolak berdasarkan skor |

## Membuat aturan kustom

Aturan kustom dapat dibuat dari **Konsol Bisnis** atau melalui **API Manajemen** (juga dapat diakses dari [Didit MCP](https://docs.didit.me/id/integration/mcp/tools.md) dan asisten AI apa pun yang terhubung dengan MCP).

> [tab] Konsol
>
> 1. Buka **Transaksi** > **Aturan** di konsol
> 2. Klik **Create Rule**
> 3. Tentukan judul, deskripsi, dan kategori aturan
> 4. Atur **mode**: `Active` untuk berjalan secara langsung, atau `Test` untuk mengevaluasi tanpa memengaruhi transaksi
> 5. Pilih **mode evaluasi**: `All` (setiap kondisi harus cocok) atau `Any` (minimal satu kondisi cocok)
> 6. Atur **scope**: jenis transaksi atau arah transaksi yang berlaku untuk aturan
> 7. Tambahkan **kondisi**: perbandingan field seperti ambang batas jumlah, kode negara, pemeriksaan properti kustom
> 8. Opsional, tambahkan **agregasi**: pemeriksaan laju dalam jangka waktu tertentu (jumlah, total, jumlah unik, dan lainnya)
> 9. Tentukan satu atau beberapa **tindakan**: tambahkan skor, ubah status, tambahkan tag, tambahkan catatan, tambahkan ke daftar, atau buka kasus
> 10. Simpan dan aktifkan aturan

> [tab] API
>
> Panggil [`POST /v3/transactions/rules/`](https://docs.didit.me/id/management-api/transactions/rules-create) dengan field yang sama: `title`, `category`, `mode`, `evaluation_mode`, `scope`, `conditions`, `aggregation`, `actions`. Referensi lengkap field, operator, dan tindakan tersedia di halaman ini, dan [mengelola aturan melalui API dan MCP](https://docs.didit.me/id/transaction-monitoring/rules-api.md) menjelaskan alur kerja yang direkomendasikan, yaitu create -> backtest -> activate, termasuk migrasi kumpulan aturan dari ekspor CSV penyedia lain.

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/`](https://docs.didit.me/id/management-api/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.

| Metrik | Deskripsi |
| - | - |
| `count` | Jumlah transaksi yang cocok dengan filter dalam jendela waktu |
| `sum` | Total dari `field` numerik (misalnya `preferred_currency_amount`) dalam jendela waktu |
| `max` / `min` / `avg` | Nilai terbesar, terkecil, atau rata-rata dari `field` numerik dalam jendela waktu |
| `distinct_count` | Jumlah nilai unik dari `field` (misalnya sidik jari perangkat yang berbeda) dalam jendela waktu (`unique_count` diterima sebagai alias) |

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](#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

| Pola | Cara kerjanya |
| - | - |
| **Strukturisasi** | Jumlah transaksi untuk subjek yang sama dalam 30 hari >= 20, dengan `max` jumlah di bawah \$10,000 dalam jendela yang sama |
| **Laju tinggi** | Jumlah transaksi masuk untuk subjek yang sama dalam 7 hari >= 20 |
| **Masuk dan keluar cepat** | Transaksi saat ini adalah keluar + jumlah transaksi masuk untuk subjek yang sama dalam 6 jam >= 1 |
| **Multi-akun** | Jumlah unik subjek yang berbagi sidik jari perangkat yang sama dalam 7 hari >= 3 |
| **Reaktivasi dorman** | Jumlah hari sejak transaksi sebelumnya dari subjek >= 365, dikombinasikan dengan jumlah >= \$1,000 |

## Katalog kolom

Kondisi dan filter agregasi merujuk ke kolom transaksi berdasarkan path:

| Kolom | Deskripsi |
| - | - |
| `amount`, `currency` | Jumlah dan kode mata uang transaksi |
| `preferred_currency_amount`, `default_currency_code` | Jumlah yang dikonversi ke mata uang pilihan aplikasi Anda (jika tidak tersedia, menggunakan `amount_in_default_currency`) |
| `direction` | `INBOUND` atau `OUTBOUND` |
| `action_type` | Jenis tindakan Anda, misalnya `withdrawal`, `deposit`, `bet` |
| `transaction_type` | `finance`, `kyc`, `travelRule`, `userPlatformEvent` |
| `payment_details` | Referensi pembayaran berupa teks bebas (target `contains_any` untuk aturan kata kunci) |
| `score`, `severity` | Skor risiko dan tingkat keparahan transaksi saat ini |
| `subject_vendor_data`, `counterparty_vendor_data` | Pengidentifikasi Anda untuk kedua pihak |
| `subject_country`, `counterparty_country` | Kode negara pihak (ISO-2 dan ISO-3 sama-sama diterima; dinormalisasi sebelum dibandingkan) |
| `subject_device_fingerprint`, `counterparty_device_fingerprint` | Sidik jari perangkat atau id perangkat persisten |
| `subject_browser_family`, `subject_browser_version`, `subject_platform`, `subject_accept_language`, `subject_session_age_ms` | Detail konteks perangkat (`counterparty_browser_family` juga tersedia) |
| `subject_ip_address`, `subject_ip_country`, `counterparty_ip_address`, `counterparty_ip_country` | Konteks jaringan |
| `subject_payment_method_type`, `subject_payment_method_country`, `subject_payment_method_fingerprint`, `subject_payment_method_account_id` | Metode pembayaran di sisi subjek (empat kolom yang sama juga ada untuk `counterparty_payment_method_*`) |
| `travel_rule_status`, `travel_rule_required`, `travel_rule_obligations_count` | Status pemeriksaan Travel Rule |
| `counterparty_dd_status`, `counterparty_risk_level`, `counterparty_jurisdiction`, `counterparty_responsiveness` | Informasi yang Anda miliki tentang VASP pihak lawan yang dijangkau melalui pertukaran Travel Rule: keputusan Anda terhadapnya (`APPROVED`, `RESTRICTED`, `BLOCKED`), tingkat risikonya (`LOW`, `MEDIUM`, `HIGH`; `HIGH` saat skrining pihak lawan Anda sendiri ditandai), negaranya, dan responsivitasnya (`RESPONSIVE`, `UNRESPONSIVE`, `UNKNOWN`). Lihat [Uji tuntas pihak lawan Travel Rule](https://docs.didit.me/id/transaction-monitoring/travel-rule.md#kolom-aturan-dan-preset) |
| `subject_days_since_previous_transaction` | Jumlah hari sejak transaksi sebelumnya dari subjek ini dengan jenis yang sama (aturan dormansi) |
| `tags` | Nama tag transaksi |
| `custom_values.<key>` | Kunci apa pun yang Anda kirim di `custom_properties` saat membuat transaksi |

## Operator kondisi

Aturan mendukung operator perbandingan berikut untuk kondisi:

| Operator | Deskripsi | Contoh |
| - | - | - |
| `eq` / `ne` | Sama dengan / tidak sama dengan | `direction eq "OUTBOUND"` |
| `gt` / `gte` / `lt` / `lte` | Perbandingan angka dan tanggal; tidak pernah cocok jika salah satu sisi tidak ada | `preferred_currency_amount gte 25000` |
| `in` / `not_in` | Keanggotaan dalam daftar (satu nilai skalar juga diterima) | `counterparty_country in ["IRN", "PRK", "SYR"]` |
| `contains` / `not_contains` | Substring yang tidak peka huruf besar-kecil terhadap nilai string | `payment_details contains "refund"` |
| `contains_any` | Salah satu dari daftar string merupakan substring yang tidak peka huruf besar-kecil di dalam kolom | `payment_details contains_any ["terror", "weapon"]` |
| `regex` | Pola nilai cocok dengan kolom | `subject_vendor_data regex "^guest-"` |
| `fuzzy_match` | Kemiripan string secara fuzzy; memerlukan ambang batas `score` (0-100) pada kondisi | `counterparty_name fuzzy_match "Acme Corp"` dengan `score: 85` |
| `exists` / `is_not_empty` / `is_not_null` | Kolom ada (alias; `value` diabaikan) | `subject_device_fingerprint exists` |
| `not_exists` / `is_empty` / `is_null` | Kolom tidak ada atau kosong (alias; `value` diabaikan) | `subject_ip_address is_empty` |

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:

| `value_type` | Arti |
| - | - |
| `list` | `value` adalah UUID daftar; entri daftar blokir, daftar izin, atau daftar kustom menjadi nilai pembanding, sehingga aturan dapat mencocokkan "pihak lawan dalam daftar pantauan kustom saya". |
| `field` | `value` adalah jalur kolom lain; kondisi membandingkan dua kolom transaksi, misalnya `subject_payment_method_account_id ne counterparty_payment_method_account_id`. |
| `relative_date` | `value` adalah tanggal relatif, misalnya `{"direction": "past", "unit": "days", "amount": 30}`, untuk kolom tanggal seperti `txn_date`. |

### 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/`](https://docs.didit.me/id/transaction-monitoring/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:

| Entitas | Jenis daftar blokir | Yang diperiksa |
| - | - | - |
| **Pengguna (pemohon)** | Daftar blokir pengguna | Pengidentifikasi `vendor_data` pemohon |
| **Bisnis** | Daftar blokir bisnis | Pengidentifikasi `vendor_data` bisnis |
| **Alamat dompet** | Daftar blokir alamat dompet | `account_id` dari metode pembayaran dompet kripto |
| **Rekening bank** | Daftar blokir rekening bank | `account_id` dari metode pembayaran transfer bank |
| **Alamat IP** | Daftar blokir alamat IP | Alamat IP dari konteks perangkat pihak terkait (mendukung rentang CIDR) |
| **Sidik jari perangkat** | Daftar blokir sidik jari perangkat | Sidik jari perangkat atau ID perangkat persisten |

Ketika terjadi kecocokan dengan daftar blokir:

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

> [!NOTE]
>
> Pemeriksaan daftar blokir dijalankan sebelum evaluasi aturan. Entitas yang masuk daftar blokir akan selalu ditolak, terlepas dari konfigurasi aturan atau ambang batas skor.

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

> [card] [Mengirimkan transaksi](https://docs.didit.me/id/transaction-monitoring/transactions.md)
>
> Cara transaksi disusun untuk evaluasi aturan.

> [card] [Skrining kripto](https://docs.didit.me/id/transaction-monitoring/aml-screening.md)
>
> Hasil skrining kripto dan cara aturan preset menggunakannya.

> [card] [Pengaturan](https://docs.didit.me/id/transaction-monitoring/settings.md)
>
> Konfigurasi ambang batas skor dan alur kerja remediasi.

> [card] [Referensi API](https://docs.didit.me/id/management-api/transactions/create.md)
>
> Endpoint API Create Transaction.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.