Kebanyakan tim finance masih menganggap deteksi fraud AI hanya milik bank yang punya departemen fraud dan tim machine learning sendiri. Itu benar lima tahun lalu. Sekarang tidak lagi. Ide anomaly-detection yang sama, yang dipakai untuk menandai transaksi kartu mencurigakan, bisa juga menandai invoice vendor duplikat, ghost supplier, atau pola approval yang hanya masuk akal kalau ada orang yang sedang mengakali sistem. Kalau perusahaan Anda memproses payable, payroll, atau reimbursement dalam volume berapa pun, ini sudah terjangkau tahun ini, bukan nanti-nanti.
Alasan ini relevan sekarang adalah kelelahan, bukan teknologi. Seorang finance controller yang meninjau dua ratus invoice sebulan menangkap hal-hal yang jelas. Tapi setelah invoice ke-dua ratus di Jumat sore, mata berhenti menangkap pola. Fraud tidak perlu canggih untuk berhasil. Ia hanya butuh reviewer yang lelah.
Mulai dengan rules, tambahkan anomaly detection kemudian
Lewati dulu godaan untuk langsung membeli platform fraud AI di hari pertama. Bangun dalam dua lapis.
- Lapis rules. Batasan keras yang tidak pernah berubah: tidak ada pembayaran vendor di atas ambang batas tertentu tanpa dua approver, tidak ada vendor baru dibayar dalam 48 jam sejak didaftarkan, tidak ada nomor invoice yang dipakai ulang. Rules menangkap yang jelas dan tidak memakan biaya selain disiplin.
- Lapis anomaly. Di sinilah AI benar-benar berkontribusi. Beri ia data transaksi historis, catatan vendor, dan log approval, lalu biarkan ia menandai apa pun yang menyimpang dari pola normal yang sudah dipelajari, misalnya jumlah invoice yang secara statistik janggal untuk vendor tersebut, pembayaran yang disetujui di luar jam kerja, atau nomor rekening baru yang tiba-tiba menempel pada ID vendor yang sudah ada.
Kombinasi keduanya berhasil karena rules menangkap pola fraud yang sudah dikenal secara instan tanpa perlu tuning false-positive, sementara anomaly detection menangkap fraud yang belum pernah terpikirkan untuk dibuatkan aturannya.
Pola yang ditangkap AI tapi terlewat oleh manusia
Tiga pola ini muncul berulang kali di payable perusahaan skala menengah, dan ketiganya sulit ditangkap reviewer manusia karena mereka bersembunyi di dalam volume, bukan di satu dokumen tertentu.
- Invoice duplikat dengan perubahan kosmetik. Jumlah sama, vendor sama, nomor invoice berbeda satu digit, diajukan enam minggu berselang. Manusia yang memindai baris demi baris akan melewatkannya. Sistem yang membandingkan setiap invoice terhadap semua invoice lain dari vendor yang sama tidak akan.
- Ghost vendor. Sebuah catatan vendor dibuat, dibayar dua atau tiga kali dengan jumlah kecil yang sengaja dijaga tetap di bawah ambang approval, lalu ditinggalkan. Anomaly detection menandai pola vendor yang riwayat pembayarannya tidak menyerupai hubungan supplier yang wajar, terlalu teratur, terlalu bulat angkanya, tanpa purchase order yang menyertainya.
- Approval clustering. Satu approver yang tiba-tiba menyetujui porsi tidak wajar dari invoice-invoice yang ada di batas ambang, atau invoice yang mengelompok mencurigakan di sekitar jadwal satu approver tertentu. Ini pola yang paling mungkin mengindikasikan fraud internal, dan nyaris tidak terlihat tanpa menyilangkan log approval dengan jumlah dan vendor sepanjang waktu.
Tidak satu pun dari ini membutuhkan machine learning yang eksotis. Yang dibutuhkan adalah seseorang yang benar-benar membangun logika cross-referencing dan menjalankannya secara konsisten, yang justru merupakan jenis pekerjaan tekun dan konsisten yang lebih baik dikerjakan AI dibanding manusia yang sedang dikejar deadline.
Berapa biayanya untuk perusahaan skala menengah
Stack deteksi fraud setara bank itu berlebihan dan mahal untuk perusahaan yang memproses, katakanlah, beberapa miliar rupiah payable per bulan. Berikut yang realistis:
| Pendekatan | Perkiraan biaya | Cocok untuk |
|---|---|---|
| Rules engine di dalam ERP/software akuntansi yang sudah ada | Sering sudah termasuk atau add-on murah | Semua perusahaan, sejak hari pertama |
| Script anomaly detection terhadap data transaksi yang diekspor | Biaya build sekali, puluhan juta rupiah | Perusahaan dengan 100+ invoice/bulan |
| SaaS deteksi fraud khusus | Biaya bulanan berulang, mengikuti volume | Perusahaan dengan tim finance ops khusus dan risiko transaksi lebih tinggi |
Kebanyakan perusahaan Indonesia skala menengah yang pernah saya tangani berada di baris tengah. Anda tidak butuh platform berlangganan. Anda butuh seseorang yang menarik data transaksi dan vendor secara terjadwal lalu menjalankannya lewat model yang disesuaikan dengan riwayat perusahaan Anda sendiri. Itu sebuah pembangunan sistem, bukan pembelian produk, dan ia balik modal sejak pertama kali berhasil menangkap pembayaran duplikat bernilai ratusan juta sebelum sempat cair.
Di mana ini terhubung dengan rekonsiliasi
Deteksi fraud dan rekonsiliasi adalah dua sisi dari koin yang sama. Kalau proses tutup buku bulanan Anda masih melibatkan seseorang yang mencocokkan rekening koran dengan buku besar secara manual, Anda sebenarnya sudah punya data mentah yang dibutuhkan deteksi fraud, hanya saja belum dimanfaatkan untuk hal lain selain menutup buku. Mengotomatisasi rekonsiliasi pembayaran dan menambahkan lapisan anomaly detection di atas pipeline data yang sama jauh lebih murah dibanding membangun dua sistem terpisah.
Siapa yang seharusnya memegang ini
Kesalahan umum adalah memperlakukan deteksi fraud murni sebagai proyek IT dan menyerahkannya ke developer tanpa latar belakang finance, atau murni proyek finance dan berharap controller membangunnya sendiri di Excel. Keduanya tidak berjalan baik sendirian. Pembangunannya butuh seseorang yang memahami alur approval dan hubungan vendor perusahaan Anda yang sebenarnya, dipasangkan dengan seseorang yang bisa menulis query dan menyiapkan penarikan data yang berjalan otomatis secara berkala. Di kebanyakan perusahaan skala menengah, itu berarti seorang finance lead yang mendefinisikan rules dan seorang developer atau freelance engineer yang mengimplementasikan pipeline-nya, dengan rapat review bulanan di mana kedua pihak melihat bersama apa yang tertandai dan kenapa.
Tetapkan ambang batas, lalu percayai flag-nya
Failure mode yang paling sering saya lihat adalah perusahaan membangun lapisan deteksi fraud, kebanjiran false positive di minggu pertama, lalu diam-diam mematikannya. Atur ambang batas secara konservatif saat peluncuran. Lebih baik menandai lima kasus nyata dan sepuluh false positive dalam sebulan, daripada menandai nol dan membiarkan satu kasus nyata lolos. Tinjau tingkat false positive setiap bulan dan perketat seiring model mempelajari pola transaksi Anda yang sebenarnya. Deteksi fraud AI bukan pembelian sekali pasang lalu ditinggal, ini adalah disiplin yang dibangun bertahap, sama seperti finance controller yang baik membangun insting selama bertahun-tahun, hanya saja sistem ini membangunnya dalam hitungan minggu dan tidak pernah lelah di Jumat sore.