Pola SQL yang Digunakan untuk Mendeteksi Penipuan Transaksi

• Deteksi penipuan sering kali dimulai bukan dari machine learning, melainkan dari penataan tabel dan join yang benar serta pencarian pola anomali pada kecepatan, lokasi, nominal, merchant, dan waktu transaksi dengan SQL
• Velocity mencari rentetan transaksi pada pemilik kartu yang sama dalam waktu singkat, dan memerlukan penyesuaian jendela waktu, ambang batas, serta whitelist untuk false positive
• Impossible travel menggunakan LAG() dan perhitungan jarak untuk menangkap sinyal kuat kartu kloning, seperti pembayaran di Chicago lalu 7 menit kemudian di Los Angeles, yang secara fisik mustahil
• Anomali nominal mencari rentang nilai seperti $1.00, $99.99, $499.99 yang mengindikasikan card testing atau upaya menghindari aturan, tetapi kurang cocok untuk transaksi tunjangan
• Lonjakan merchant, transaksi di luar jam kebiasaan, dan kolom turunan dari window function dapat dipakai bersama untuk memberi skor transaksi dengan banyak sinyal dan mempersingkat siklus iterasi dari hitungan minggu menjadi jam

---

Pola SQL untuk Menemukan Tanda-Tanda Penipuan dalam Data Transaksi

• Deteksi penipuan sering kali dimulai bukan dari machine learning atau graph database, melainkan dari tabel dan join yang benar, serta SQL untuk menemukan bentuk transaksi yang aneh
• Dapat diterapkan pada data yang melibatkan perpindahan uang dan menyisakan log, seperti kartu kredit, klaim medis, e-commerce, POS, dan program tunjangan pemerintah
• Pada dataset baru, pola biasanya dibangun berurutan mulai dari velocity, impossible travel, anomali nominal, konsentrasi merchant, jam tidak normal, hingga sinyal berbasis window function

1. Velocity: transaksi berlebihan dalam waktu singkat

• Saat kartu atau akun curian ingin segera dihabiskan, biasanya muncul pola transaksi yang menumpuk dalam waktu singkat pada pemilik kartu yang sama
• Query dasar biasanya mengelompokkan transaksi 30 hari terakhir per jam, lalu mencari rentang di mana jumlah transaksi per cardholder_id melebihi batas
• Nilai penyesuaian utamanya adalah ukuran jendela waktu dan ambang jumlah transaksi
  • Versi 1 menit, 5 menit, dan 1 jam bisa dijalankan paralel untuk dibandingkan
  • Kelompok card testing dapat memadatkan transaksi dalam hitungan detik, sedangkan pelaku penyalahgunaan tunjangan bisa bergerak sepanjang setengah hari, jadi skalanya berbeda
• Pengguna normal pun bisa melewati ambang ini
  • operator yang mengelola vending machine
  • orang yang mengisi ulang prepaid card dalam jumlah besar
  • setelah eksplorasi awal, diperlukan whitelist untuk target false positive seperti ini
• Pendekatan sliding window menghitung jumlah transaksi dalam 5 menit terakhir dengan COUNT(*) OVER (...) RANGE BETWEEN INTERVAL '5 minutes' PRECEDING AND CURRENT ROW
• QUALIFY bekerja di Snowflake, BigQuery, Databricks, Teradata
  • Di Postgres, seluruh query perlu dibungkus dengan CTE lalu difilter dari luar

2. Impossible travel: perpindahan yang secara fisik mustahil

• Jika satu kartu dipakai bertransaksi di Chicago lalu 7 menit kemudian di Los Angeles, kemungkinan besar salah satunya palsu
• Pola ini merupakan sinyal kuat untuk kartu kloning, karena hampir tidak ada alasan normal satu kartu bisa berada di dua lokasi jauh dalam hitungan menit
• Query menggunakan LAG() untuk mengambil waktu dan lokasi transaksi sebelumnya, lalu menghitung jarak serta selang waktu antara lokasi sebelumnya dan lokasi saat ini
• haversine adalah fungsi untuk menghitung great-circle distance
  • Sebagian besar data warehouse menyediakannya
  • Jika tidak ada, ini fungsi yang cukup mudah dibuat sendiri
• Contoh ambang batasnya adalah 600mph
  • Karena kecepatan jelajah jet komersial sekitar 575mph, artinya ini adalah kecepatan yang bahkan mustahil dicapai dengan pesawat
  • Jika diturunkan ke 100mph, perpindahan darat yang cepat pun bisa tertangkap, tetapi transaksi normal dari pelancong udara atau orang tua yang menjemput anak juga mulai ikut terjaring
• Ada sinyal lain dalam keluarga pola yang sama
  • Jika transaksi terjadi di dua kota jauh dalam negara bagian yang sama dalam 5 menit, itu bisa mengindikasikan jaringan kloning lokal
  • Jika transaksi muncul di banyak ZIP code dalam satu jam, itu bisa mengindikasikan jaringan skimmer yang bergerak dalam satu wilayah
  • Transaksi lintas perbatasan dalam 10 menit bisa menjadi sinyal jaringan internasional

3. Amount anomalies: transaksi aneh pada rentang nominal tertentu

• Dalam penipuan, ada pola nominal yang sering muncul tetapi jarang terlihat pada penggunaan normal
• Contoh kondisi berikut mencari rentang nominal:
  • $1.00, $5.00, $10.00
  • $99.50 atau lebih dan kurang dari $100.00
  • $499.50 atau lebih dan kurang dari $500.00
• Nilai dolar bulat kecil umumnya merupakan sinyal card testing
  • Alurnya adalah memeriksa apakah nomor yang diperoleh dari dump nomor kartu benar-benar aktif sebelum dijual kembali
  • Jarang pemilik kartu sungguhan membeli barang dengan harga tepat $1.00
  • Kopi kemungkinan bernilai $4.73, bensin $52.81, bukan nominal yang benar-benar bulat
• Nominal tepat di bawah ambang memiliki makna lain
  • $99.99 bisa menjadi bentuk penghindaran batas yang mewajibkan verifikasi identitas mulai $100 di banyak tempat
  • $499.99 bisa menjadi cara menghindari batas harian ATM sebesar $500
  • Ini menjadi sinyal bahwa pelaku tahu aturannya dan sengaja tetap sedikit di bawahnya
• Dalam transaksi tunjangan, pola nominal bulat tidak terlalu membantu
  • Tunjangan tidak diuji dengan pola card testing yang sama
  • Biasanya sinyal yang lebih penting adalah penerima ganda

4. Suspicious merchants: konsentrasi anomali pada tingkat merchant

• Jika card reader tertentu, seperti pembaca kartu di pompa bensin, terinfeksi skimmer, dampaknya bisa menjadi puluhan kasus penipuan, bukan hanya satu kejadian
• Semua kartu yang memakai reader itu selama beberapa minggu bisa masuk ke database seseorang
• Dari sudut pandang merchant, ini terlihat sebagai kenaikan tajam jumlah kartu yang tidak saling terkait dalam periode pendek, beserta kenaikan nominal transaksi
• Contoh ambang sederhana adalah mengelompokkan 7 hari terakhir per merchant dan per jam, lalu menghitung:
  • jumlah kartu unik
  • jumlah total transaksi
  • total nominal transaksi
  • lalu mencari slot waktu saat jumlah kartu unik melebihi 20 dan total nominal melebihi $5000
• Ambang statis punya masalah normalisasi ukuran
  • Costco bisa melewati ambang ini dalam 90 detik
  • toko buku bekas hampir tidak pernah melewatinya
• Cara yang lebih baik adalah membandingkan setiap merchant dengan baseline historis miliknya sendiri
  • Mengelompokkan transaksi 60 hari terakhir per jam
  • Menghitung rata-rata historis jumlah kartu unik tiap merchant berdasarkan 168 bucket per jam sebelumnya
  • Mencari rentang saat jumlah kartu unik saat ini lebih dari 3 kali rata-rata historis
• 168 bucket per jam berarti slot per jam selama 7 hari terakhir
  • Karena musiman harian dan mingguan itu penting
  • Kedai kopi yang sama pun punya baseline berbeda antara Selasa pukul 14.00 dan Sabtu pukul 09.00
• Sebagai titik awal, 3 kali dari normal cukup masuk akal
  • Cukup longgar agar alert tidak membanjir
  • Namun tetap cukup ketat untuk menangkap slot waktu yang benar-benar aneh

5. Off-hours: transaksi di luar jam kebiasaan seseorang

• Kebanyakan orang memiliki pola pengeluaran
• Jika seseorang yang biasa beraktivitas pukul 9 sampai 5 tiba-tiba mengisi bensin pukul 3 pagi, ada kemungkinan kartunya dipakai orang lain atau ia sedang bepergian
• Apakah orang itu sedang bepergian bisa diverifikasi lebih lanjut dengan sinyal lain
• Query menghitung jumlah transaksi per pemilik kartu dan per jam selama 90 hari terakhir, lalu hanya menganggap slot waktu dengan minimal 2 transaksi sebagai jam kebiasaan
• Setelah itu, transaksi baru akan terdeteksi jika waktunya berada di luar rentang earliest_hour dan latest_hour milik pemilik kartu tersebut
• Kondisi “minimal 2 transaksi pada slot waktu itu” dalam query internal sangat penting
  • Ini mencegah satu transaksi bensin larut malam yang terjadi kebetulan 3 bulan lalu masuk sebagai jam kebiasaan
  • Ambang tersebut menyesuaikan baseline dengan kebiasaan nyata, bukan sekadar “pernah terjadi sekali”
• Kekurangannya adalah memerlukan data historis
  • Akun baru belum punya baseline
  • Untuk akun baru, bisa memakai pola jam seluruh pengguna atau melewati pola ini sampai akun memiliki riwayat beberapa bulan

6. Menggabungkan sinyal dengan window function

• Pola window function bukan jenis penipuan tersendiri, melainkan pekerjaan persiapan untuk mengubah lima pola sebelumnya menjadi sinyal yang bisa digabungkan
• Untuk setiap transaksi, bisa dibuat kolom turunan berikut:
  • waktu sejak transaksi sebelumnya: timestamp - LAG(timestamp)
  • apakah merchant berubah: membandingkan merchant_id sebelumnya dengan merchant_id saat ini
  • total nominal 24 jam terakhir: SUM(amount) OVER (...)
  • transaksi ke berapa pada hari itu: ROW_NUMBER()
• Jika kolom-kolom ini dimaterialisasi, aturan penipuan bisa dipangkas menjadi ekspresi filter yang sederhana
• Kelompok card testing bisa ditemukan dengan kondisi berikut:
  • transaksi ke-5 atau lebih dalam sehari
  • kurang dari 60 detik sejak transaksi sebelumnya
  • merchant berbeda dari transaksi sebelumnya
• Jika hipotesis penipuan baru bisa diekspresikan sebagai filter SQL, bukan tiket engineering, maka siklus iterasi bisa dipangkas dari hitungan minggu menjadi hitungan jam
• Hasilnya, lebih banyak penipuan bisa ditangkap lebih cepat

Cara memakai pola-pola ini bersama

• Tidak ada satu pola pun yang cukup sendirian
• Setiap pola punya keterbatasan yang jelas
  • Velocity menimbulkan false positive seperti operator vending machine
  • Perpindahan yang mustahil secara geografis akan melewatkan penipuan yang terjadi dalam satu kawasan metropolitan besar
  • Anomali nominal kurang cocok di luar konteks card testing
  • Aturan jam tidak normal memerlukan riwayat
• Dalam praktik, yang berhasil adalah menjalankan semua pola dan memberi skor pada setiap transaksi berdasarkan banyak sinyal
• Transaksi yang terkena tiga atau empat sinyal hampir selalu merupakan penipuan
• Transaksi yang hanya terkena satu sinyal bisa saja hanya penggunaan tidak biasa dari pemilik kartu normal yang sedang bepergian
• Jika baru mulai membangun deteksi penipuan, sebaiknya mulai dari Velocity
  • Ini mengungkap cukup banyak penipuan yang berguna
  • Aktivitas normal yang ikut tertangkap relatif sedikit
  • Biaya eksekusinya juga rendah
• Jika pola 1 sampai 5 sudah dimiliki, investasi berikutnya adalah kolom mentah berbasis window function
  • Setelah dibuat sekali, semua analis di tim bisa memakainya
  • Menambahkan pola penipuan berikutnya tidak lagi menjadi proyek terpisah

Hal yang perlu diperhatikan

• Penanganan NULL

  • Tabel transaksi nyata sering kali tidak memakai NULL seperti di buku pengantar SQL
  • Banyak sistem lama menggunakan nilai sentinel seperti 9999-12-31 untuk “tidak ada tanggal akhir” dan 0001-01-01 untuk “tidak ada tanggal mulai”
  • Jika memfilter dengan IS NULL, baris-baris seperti ini bisa terlewat tanpa disadari
  • Konvensi pada tabel tertentu harus diperiksa dulu sebelum menulis klausa WHERE

• False positive

  • Semua aturan bisa menangkap perilaku yang aneh tetapi sah dari pemilik kartu yang nyata
  • Kasus yang ditandai perlu melalui review manusia
  • Diperlukan loop umpan balik untuk menyesuaikan ambang berdasarkan mana yang benar-benar penipuan dan mana yang bukan
  • Pemblokiran otomatis dengan satu aturan tunggal bisa membuat pelanggan hilang

• Privasi

  • Jika data mengandung PII, maka kebijakan penggunaan data yang berlaku harus dipatuhi
  • Mulailah dari data yang sudah dianonimkan atau data sampel, dan gunakan data produksi hanya setelah ada persetujuan

• Biaya

  • Window function pada partisi besar tidak murah
  • Filter rentang tanggal sebaiknya diterapkan lebih dulu sebelum window function
  • Jika LAG() dijalankan dulu pada transaksi 2 tahun untuk seluruh dataset lalu WHERE dipasang belakangan, anggaran kredit data warehouse bisa terkuras besar

[GN⁺]

Komentar Hacker News

• Tolok ukur bahwa pemilik kartu yang sebenarnya hampir tidak pernah membeli sesuatu yang harganya tepat $1.00 tampaknya juga bergantung pada bagaimana penjual menetapkan harga
  Saat seseorang membeli sesuatu di situs web untuk menguji kartu kredit curian, pembeli tidak bisa menentukan harga sesuka hati
  Selain itu, ini tampak terlalu disesuaikan dengan situasi seperti di AS, tempat pajak tidak termasuk dalam harga, sementara di wilayah lain harga bulat sangat umum
  Saya juga ragu tolok ukur lain dalam tulisan itu akan bekerja dengan baik. Misalnya, jika menandai orang yang bertransaksi dalam 90 hari terakhir di luar jam saat mereka biasanya pernah bertransaksi lebih dari dua kali, bukankah hampir separuh orang akan kena?
  Tidak jelas apakah ini tulisan yang menyederhanakan pengetahuan profesional yang rumit menjadi kueri SQL yang terlalu sederhana, atau sepenuhnya dugaan dan karangan. Kalimat “enam pola SQL yang dipakai untuk menangkap penipuan transaksi” dan “tidak ada satu pun di sini yang benar-benar pernah saya kerjakan atau lihat” saling bertentangan

  • “Transaksi di luar jam biasanya” tampak seperti tolok ukur yang cukup dasar
    Biasanya orang tidak membeli bensin, kopi, atau camilan jam 2 pagi, tetapi kalau itu sangat jarang terjadi, kemungkinan besar ada keadaan darurat pribadi, dan dalam situasi begitu orang juga tidak ingin menelepon bank
    Saya paham pencuri oportunistis juga bisa beraktivitas pada jam itu, tetapi jelas ada juga biaya false positive
  • Bahkan lebih buruk dari itu. Menurut pengalaman saya, kopi sering kali berharga angka bulat, dan ada juga orang yang sengaja mengisi bensin dengan nominal pas
    Selain itu ada SPBU yang memang meminta nominal tetap lebih dulu, seperti 10, 20, atau 50 euro
  • Suatu malam di bar saya lapar dan ingin membeli sebungkus keripik, tetapi ada minimal pembayaran kartu £5, jadi saya minta ditagihkan saja £5
    Lalu kartu saya diblokir karena dicurigai sebagai penipuan, dan itu cukup menjengkelkan. Bukan hal yang ingin diurus saat mabuk jam 2 pagi
    Mungkin mereka melindungi saya dari diri saya sendiri, tetapi tetap saja merepotkan
  • Saya tidak tahu apakah ini masih dipakai sekarang, tetapi dulu tempat seperti hotel atau rental mobil kadang memeriksa validitas kartu kredit dengan transaksi $1.00 sebelum pemesanan kamar atau penyewaan kendaraan
  • Cara ini mudah dilewati dengan menambahkan sedikit variasi acak pada transaksi uji, dan juga bisa diperbaiki dengan mudah lewat analisis statistik yang layak
    Dan justru pola heuristik seperti ini, yang tidak mengharapkan akurasi hampir 100%, bukankah itu bidang yang seharusnya dikuasai AI?

• Tolok ukur “menyeberangi perbatasan dalam 10 menit berarti organisasi internasional” bisa berlaku juga untuk orang biasa yang tinggal di wilayah dekat perbatasan Eropa
  Bahkan kalau transaksi card-not-present dikecualikan, ini tetap tampak salah mengasumsikan bahwa semua lokasi merchant disetel akurat, semua penjualan terjadi di toko fisik, tidak ada penjualan keliling, dan semua transaksi diproses secara online

  • Beberapa minggu lalu saat saya menyeberang dari AS ke Kanada pun mungkin sekitar 10 menit

• Jika dibaca sampai akhir, nasihatnya kosong dan saling bertentangan. Hampir pasti ini tampak seperti tulisan buatan LLM
  Ia bilang “tim Anda” tidak boleh bergantung pada satu pola pun, tetapi juga mengatakan pola 1 saja bisa mengungkap “jumlah penipuan yang berguna”
  Ada juga kalimat aneh seperti “semua analis di tim Anda akan memakainya, yaitu window function, ketika itu ada, dan menambahkan pola penipuan berikutnya tidak lagi menjadi proyek”
  Selain itu, hampir semua contoh bahkan tidak memakai IS NULL, tetapi tetap muncul pembahasan yang kurang relevan soal filter IS NULL yang mungkin tidak diterapkan, dan satu-satunya contoh yang memakainya pun ada di konteks lain
  Secara keseluruhan ini tulisan yang berkualitas rendah dan terlalu panjang

• Hacker News, ini perlu ditunjukkan
  “Fixel Smith” adalah tokoh buatan AI, dan tulisannya hampir tidak ada hubungannya dengan analisis penipuan. Nama ini dipakai untuk hampir semua identitas yang bisa dibayangkan: musisi (1), novelis (2), analis penipuan (3), influencer (4), dan seterusnya
  Posting ini mendapat lebih dari 220 poin dan lebih dari 70 komentar, tetapi hampir tak ada yang menyadari bahwa ini cukup palsu, dan tak ada yang melihat bahwa sosoknya adalah hasil generasi AI

  1. https://www.amazon.it/Forged-Soundtrack-Explicit-Fixel-Smith...

  2. https://fixelsmith.com

  3. https://analytics.fixelsmith.com/

  4. https://www.instagram.com/fixeltales/

  • Hacker News belakangan tampaknya punya kebiasaan menjengkelkan mengangkat kiriman AI berkualitas rendah seperti ini
    Saya jadi bertanya-tanya apakah banjir AI ini mengungkap kebenaran yang tidak nyaman tentang daya nilai komunitas, atau ini sekadar kegagalan mekanisme pertahanan yang sudah ada dan hanya perlu diperbaiki
  • Saya mengecek posting ini di ponsel dan hanya melihat komentar sekilas. Memang tidak selalu mudah menilai apakah sebuah tulisan dibuat AI atau disunting, tetapi di sini bahkan dari kutipannya saja sudah langsung jelas
    Dengan asumsi semua komentar ditulis dengan itikad baik, cukup mengkhawatirkan bahwa bahkan di sini literasi AI tampaknya rendah
  • Sekilas pun ini tampak seperti orang yang sangat produktif atau bot
    Novel-novelnya hampir tidak berhubungan dengan tulisan analitisnya, dan tulisan analitisnya sendiri tampak punya gaya LLM, jadi semuanya terasa mencurigakan. Mengingat topik tulisan aslinya adalah penipuan, ini ironis
  • Saya justru akan lebih heran kalau kebanyakan orang ternyata terbiasa menyelidiki penulis dari setiap hal yang mereka baca
    Sejujurnya saya biasanya bahkan tidak melihat byline, apalagi bagian lain dari situsnya
  • Ini jelas tulisan yang benar-benar ada. Tentu saja terlihat seperti ditulis LLM, tetapi kalau kritik terburuk yang bisa diberikan pada tulisan ini hanyalah bahwa ia tampak seperti LLM, mungkin itu berarti tidak ada kritik substantif
    Tidak jelas apakah isinya karangan atau bukan, tetapi orang bisa mengkritik isi tulisan ini tanpa perlu menebak apakah ditulis LLM atau oleh novelis. Ada banyak cacat yang jauh lebih spesifik

• Kami sedang mengembangkan framework keamanan open source tirreno
  Saya meragukan pendekatan yang dijelaskan di sini. Misalnya, perjalanan mustahil adalah teknik yang sah dan banyak dipakai, tetapi itu berkaitan dengan perilaku pengguna online berbasis alamat IP
  Di tirreno ada aturan terpisah untuk kasus saat jelas IP berasal dari Apple Relay atau VPN/Tor, dan itu menjadi flag tersendiri
  Saya rasa sebagian atau seluruh contohnya dibuat LLM. Konteksnya campur aduk, dan tidak ada tempat yang benar-benar mengumpulkan lokasi GPS secara massal untuk pembayaran kartu

  1. https://github.com/tirrenotechnologies/tirreno

• Ini lebih mirip logika berbasis aturan yang dienkode ke dalam kueri SQL tanpa data pendukung
  Ambang batasnya banyak, tetapi tidak ada data yang menunjukkan bahwa ambang-ambang itu memang bermakna

• Pernyataan tegas seperti “deteksi penipuan pada data transaksi kebanyakan adalah SQL, bukan machine learning, bukan graph database, dan bukan apa pun yang sedang diangkat Gartner tahun ini” hanya bisa dibenarkan jika yang dibahas adalah seluruh pekerjaan integritas program
  Jika pendekatan yang lebih sederhana dan kasar memang menyelesaikan masalah domainnya, itu mungkin lebih baik
  Klien fintech biasanya ingin tahu apakah transaksi yang sedang terjadi sekarang adalah penipuan, dan mereka ingin jawaban dalam hitungan milidetik terhadap data berdimensi tinggi. Ini pekerjaan pada skala yang menyulitkan database relasional memenuhi batasan real-time seperti itu, sehingga lebih sering dipakai untuk hal lain seperti pemuatan data historis
  Karena itu muncul database in-memory, stream processing engine, dan juga machine learning
  Meski begitu, sebagian poin penulis tetap masuk akal, dan khususnya masalah menangani alert yang bising adalah persoalan umum yang melampaui performance engineering, jadi saya menantikan tulisan lanjutannya

  • Menurut pengalaman saya, apa yang dijelaskan itu lebih tepat disebut pencegahan penipuan daripada deteksi penipuan. Dalam sistem yang matang, keduanya hidup berdampingan dan saling melengkapi
    Dalam pencegahan, selalu ada batasan dari kebutuhan latensi, data yang tersedia, dan gambaran perilaku pengguna yang tidak lengkap. Machine learning dan aturan dipakai untuk mengambil keputusan cepat dan menangani sebagian besar kasus, tetapi karena batasan itu tidak mungkin menghentikan semua penipuan dengan tepat
    Deteksi menangani akibat setelahnya. Umumnya tim analis menganalisis transaksi yang sudah disetujui untuk mencari tanda-tanda penipuan. Ini особенно penting untuk jenis penipuan yang tidak memiliki sinyal eksternal seperti chargeback atau keluhan pelanggan. Integritas platform adalah contohnya, dan sistem anti pencucian uang di fintech juga harus aktif mencari penipuan
    Alasan keduanya saling melengkapi adalah karena transaksi yang terdeteksi menjadi label untuk melatih dan mengevaluasi model pencegahan berikutnya

• Dikatakan bahwa jika kartu digesek di Chicago lalu 7 menit kemudian digesek lagi di Los Angeles, maka salah satunya palsu, tetapi saya penasaran bagaimana ini bekerja untuk belanja online
  Jika saya duduk di sofa dan membeli barang di Amazon, alamatnya akan tercatat di mana?
  Dan ada juga kasus tepi seperti pasangan yang berbagi akun online, lalu salah satunya sedang bepergian dan membeli memakai data kartu yang tersimpan

  • Menggesek, memasukkan, atau men-tap kartu adalah transaksi card-present. Memasukkan nomor kartu seperti saat belanja online adalah transaksi card-not-present
    Peritel dan bank bisa membedakan keduanya
  • Itu bisa dibedakan lewat metadata transaksi. Saya pernah bekerja di perusahaan kartu kredit
  • Setahu saya sistem memang membedakan card-present dan card-not-present

• “Cara ini tidak bekerja sampai riwayatnya cukup terkumpul, dan akun baru tidak punya baseline” adalah faktor pengalaman pelanggan yang diremehkan
  Kalau saya pelanggan baru atau sedang menunjukkan pola baru lalu kartu saya ditolak, rasanya perangkat lunaknya bekerja dengan baik
  Tetapi kalau ada riwayat masa lalu yang sudah saya otorisasi namun transaksi saya tetap ditolak, saya justru kesal pada algoritme yang naif dan paranois

  • Insentif bank adalah mengurangi penipuan
    Transaksi penipuan pada akhirnya membuat bank menanggung kerugian lewat pembatalan atau refund. Transaksi yang ditolak hanya menciptakan satu pelanggan yang marah, lalu pelanggan itu mengeluh dan segera melupakannya. Jadi beban biaya yang dieksternalisasi jatuh ke pelanggan
    Karena itu bank punya insentif untuk salah ke sisi yang lebih hati-hati dan menolak transaksi meskipun ada false positive

• Bukankah inti machine learning justru mempelajari aturan seperti ini dari data?
  Menurut saya pendekatan yang benar adalah memakai model machine learning untuk menemukan pola yang berkorelasi dengan penipuan, lalu mengevaluasi apakah ada yang masuk akal. Dengan begitu kita mungkin menemukan hipotesis baru

  • Sesuatu yang tidak bisa dijelaskan dan tidak bisa diperbaiki secara deterministik lewat iterasi terlalu berisiko untuk tugas penolakan transaksi keuangan
    Analis manusia harus bisa menjelaskan kepada tim compliance dalam email 5 menit mengapa transaksi tertentu ditolak, dan apa yang seharusnya dilakukan berbeda agar keputusan yang merugikan itu bisa dihindari
    Sering kali ketika satu masalah diperbaiki dengan machine learning, muncul dua masalah baru yang belum terlalu terlihat. Dalam hal regresi atau efek samping tak terduga saat berubah seiring waktu, SQL biasanya membawa kejutan yang lebih sedikit