Sistem Fraud Ini Mencegah Kerugian Rp200 Juta Setelah Berhenti Menebak Siapa Fraudster-nya.

Sistem Fraud Ini Mencegah Kerugian Rp200 Juta Setelah Berhenti Menebak Siapa Fraudster-nya.

Ketika fraud mulai naik, reaksi pertama saya adalah seperti banyak engineer lain: mari buat rules. Transaksi seperti apa yang harus ditandai? Threshold berapa yang aman? Kapan transaksi perlu diblokir?

Semua pertanyaan itu terdengar masuk akal. Tapi saya bergerak terlalu cepat.

Saya belum cukup memahami user yang ada di platform ini.

Platform ini memiliki multiple persona user. Mereka datang dengan kebutuhan, perilaku, dan tingkat pemahaman teknologi yang berbeda. Ketika sebuah transaksi terlihat aneh, saya belum bisa langsung tahu apakah itu fraud, perilaku operasional yang wajar, atau konsekuensi dari cara user memakai produk.

Saya mengira masalahnya ada pada rules. Ternyata saya belum punya dasar untuk membuat rule.

Hipotesis awal saya mengarah ke pola penyalahgunaan yang bersembunyi di balik aktivitas operasional sehari-hari. Sebagian pola dapat terlihat praktis atau wajar di permukaan, tetapi tetap menciptakan blind spot. Satu device dapat berkaitan dengan beberapa user. Satu user dapat muncul dalam pola transaksi yang tidak sama dengan user lain.

Kalau sistem langsung memblokir semua hal yang terlihat tidak biasa, ia berisiko menghukum perilaku yang lahir dari keterbatasan operasional, bukan niat jahat. Kalau sistem membiarkannya, ia memberi ruang bagi orang yang memang sedang bermain di celah yang sama.

Itulah titik ketika saya sadar: fraud detection bukan pertama-tama soal membuat mesin yang pintar. Saya perlu belajar membedakan perilaku normal dari perilaku yang patut dicurigai.

Saya perlu memahami hubungan, bukan hanya transaksilink

Transaksi adalah jejak terakhir dari sebuah aktivitas. Kalau hanya melihat nominal, frekuensi, atau waktu transaksi, saya kehilangan konteks yang menjelaskan kenapa transaksi itu terjadi.

Karena itu, saya mendorong desain platform yang melihat hubungan antarobjek. Bukan hanya transaction sebagai baris data yang berdiri sendiri, tetapi juga user, device, dan relasi di antara semuanya.

Pertanyaan yang perlu saya jawab bukan hanya “transaksi ini aneh?” tetapi “siapa yang terhubung dengan transaksi ini, lewat device apa, dan polanya seperti apa?”

Saya mulai dari tiga hal yang paling mendasar:

- tipe user dan konteks aktivitasnya;

- relasi device dengan user: satu device dipakai siapa saja dan dalam konteks apa;

- perilaku transaksi: pola aktivitas, perpindahan nilai, dan anomali yang baru terlihat ketika dibandingkan dengan pola sebelumnya.

Dengan model ini, satu device yang dipakai oleh banyak user tidak otomatis berarti fraud. Tetapi itu menjadi signal yang bisa digabungkan dengan signal lain. Misalnya, device yang sama dipakai untuk sejumlah akun, lalu ada pola transaksi yang tidak konsisten dengan perilaku akun tersebut.

Perbedaannya penting. Saya tidak ingin membuat sistem yang menghukum orang hanya karena realitas lapangannya berantakan. Saya ingin membuat sistem yang membantu tim melihat kapan realitas itu mulai dimanfaatkan.

MVP pertama bukan mesin pemblokir otomatislink

Kesalahan paling mudah dalam proyek fraud adalah mencoba membangun engine lengkap sejak hari pertama. Model, rule engine, block, sanction, dashboard, alert, case management, semuanya ingin dibuat sekaligus.

Tim tidak bisa menunggu semua itu sempurna. Tapi saya juga belum punya cukup pemahaman untuk memberi mesin kewenangan memblokir user secara otomatis.

Jadi MVP ini saya arahkan untuk belajar lebih cepat, bukan untuk terlihat canggih.

Engine pertama berbasis rule. Rules-nya sederhana dan dibangun dari hipotesis yang saat itu paling relevan: tipe user, hubungan device dengan user, dan perilaku transaksi. Hasilnya tidak langsung menjadi vonis. Aktivitas yang memenuhi rule akan di-flag agar bisa dilihat dan dipastikan.

Dashboard sederhana dibuat untuk mendukung proses itu. Fungsinya bukan untuk membuat fraud operation terlihat enterprise-ready. Dashboard itu ada supaya tim bisa melihat aktivitas yang di-flag, memeriksa konteksnya, dan belajar dari false positive maupun pola yang ternyata memang bermasalah.

Di tahap ini, dashboard adalah bagian dari product design, bukan tambahan setelah engine selesai. Tanpa tempat untuk melihat hasil rule dan menilai apakah signal-nya benar, sistem hanya mengganti tebakan manual dengan tebakan otomatis.

Rule adalah hipotesis yang harus bisa dipatahkanlink

Saya pikir ini bagian yang sering hilang ketika orang bicara fraud rule.

Rule bukan kebenaran. Rule adalah hipotesis tentang pola risiko.

Kalau satu device digunakan oleh banyak user, hipotesisnya mungkin ada potensi penyalahgunaan. Tetapi ketika sebuah rule menghasilkan flag, pekerjaan saya baru dimulai: menguji apakah hipotesis di baliknya benar.

Fraud engine yang sehat tidak hanya bertanya “apa yang harus diblokir?” Ia juga bertanya “signal ini sebenarnya sedang menceritakan apa?”

Proses itu membawa saya pada konsep fraud ring dan sanction. Saya tidak hanya melihat satu user atau satu transaksi secara terpisah. Saya melihat keterhubungan yang membentuk pola. Lalu, saya memisahkan proses mendeteksi risiko dari keputusan apa yang pantas dilakukan setelahnya.

Sanction juga tidak harus selalu berarti blokir permanen. Respons harus mengikuti konteks dan tingkat keyakinan terhadap signal yang ada. Ada aktivitas yang cukup untuk di-monitor. Ada yang perlu ditinjau. Ada yang memang membutuhkan pembatasan.

Tanpa pemisahan ini, threshold berubah menjadi angka yang terasa objektif, padahal ia sedang memikul keputusan bisnis dan operasional yang jauh lebih besar.

Baru setelah itu threshold punya artilink

Di awal, saya ingin segera menemukan angka yang tepat. Berapa skor yang membuat transaksi layak ditahan? Berapa banyak false positive yang bisa diterima?

Tapi threshold tidak akan punya arti kalau signal di bawahnya belum dipahami. Angka hanya memberi kesan presisi. Ia tidak otomatis membuat keputusan menjadi benar.

Setelah loop data, hubungan antarobjek, rules MVP, dan proses review terbentuk, barulah saya bisa memperbaiki threshold. Saya melihat mana rule yang terlalu sensitif, mana yang terlalu longgar, dan pola mana yang belum tertangkap sama sekali.

Apa perilaku normal untuk setiap jenis user di platform ini?

Pertanyaan itu menjadi lebih penting daripada mencari satu threshold universal. Multiple persona user tidak bisa dinilai dengan standar perilaku yang sama. Sistem yang mengabaikan perbedaan ini akan terlihat tegas, tetapi sebenarnya hanya kasar.

Dampak datang setelah loop untuk belajar terbentuklink

MVP tersebut tidak menyelesaikan fraud dalam satu kali release. Ia memberi tim cara untuk mengubah dugaan menjadi signal, signal menjadi review, dan review menjadi rules yang lebih baik.

Ketika loop itu mulai berjalan, sistem bergerak dari fraud detection yang reaktif menjadi lebih terstruktur. Dalam tiga bulan pertama setelah sistem live, ia mencegah kerugian lebih dari Rp200 juta.

Angka itu penting, tapi bukan pelajaran utamanya.

Sistem fraud mulai bekerja bukan ketika saya menemukan rule yang paling pintar. Sistem itu bekerja ketika saya berhenti memperlakukan user sebagai baris transaksi dan mulai memahami hubungan serta perilaku di baliknya.

Kalau kamu sedang membangun fraud system, jangan mulai dari pertanyaan “rule apa yang harus kita buat?”

Mulailah dari siapa user-mu, perilaku apa yang normal bagi mereka, signal apa yang benar-benar kamu punya, dan bagaimana tim akan belajar saat signal itu ternyata salah.

AI bisa membantu membuat rules lebih cepat, mencari anomali, dan merangkum pola dari data yang besar. Tapi AI tidak bisa menentukan perilaku mana yang normal untuk user di platformmu tanpa pemahaman yang cukup tentang konteksnya.

Kamu tidak sedang kekurangan fraud rules. Kamu mungkin sedang kekurangan cara untuk belajar sebelum mempercayai rules tersebut.