Pola SQL yang Digunakan untuk Mendeteksi Penipuan Transaksi

• Deteksi penipuan sering kali dimulai bukan dari machine learning, melainkan dari tabel dan join yang benar serta menemukan pola anomali pada kecepatan, lokasi, jumlah, merchant, dan waktu transaksi dengan SQL
• Velocity mencari rentetan transaksi dari 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 perpindahan yang mustahil secara fisik, seperti pembayaran di Chicago lalu 7 menit kemudian di Los Angeles, sebagai sinyal kuat kartu kloning
• Anomali jumlah mencari kisaran nilai seperti $1.00, $99.99, $499.99 yang mengindikasikan pengujian kartu atau upaya menghindari aturan, tetapi kurang cocok untuk transaksi manfaat
• Lonjakan merchant, transaksi di luar jam normal, dan kolom turunan dari window function dapat dipakai bersama untuk memberi skor transaksi dengan banyak sinyal dan memangkas siklus iterasi dari hitungan minggu menjadi hitungan 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 janggal
• Dapat diterapkan pada data seperti kartu kredit, klaim medis, e-commerce, POS, dan program manfaat bantuan pemerintah—apa pun yang melibatkan perpindahan uang dan menyisakan log
• Pada dataset baru, pola biasanya disusun berurutan dari velocity, impossible travel, anomali jumlah, konsentrasi merchant, waktu tidak normal, hingga sinyal berbasis window function

1. Velocity: transaksi berlebihan dalam waktu singkat

• Jika kartu atau akun curian sedang dihabiskan secepat mungkin, akan muncul pola transaksi yang menumpuk dalam waktu singkat pada pemilik kartu yang sama
• Query dasar mengelompokkan transaksi 30 hari terakhir per jam, lalu mencari interval saat jumlah transaksi per cardholder_id melewati ambang tertentu
• Nilai penyesuaian utama adalah ukuran jendela waktu dan ambang jumlah transaksi
  • Versi 1 menit, 5 menit, dan 1 jam bisa dijalankan paralel untuk dibandingkan
  • Kelompok penguji kartu bisa menjejalkan transaksi dalam hitungan detik, sedangkan kelompok penipuan manfaat bisa bergerak selama setengah hari, jadi skalanya berbeda
• Pengguna normal juga bisa melewati ambang ini
  • operator yang mengelola vending machine
  • orang yang mengisi banyak kartu prabayar
  • 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 harus dibungkus dalam CTE lalu difilter di luar

2. Impossible travel: perpindahan yang mustahil secara fisik

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

3. Amount anomalies: transaksi aneh pada kisaran jumlah tertentu

• Dalam penipuan, ada pola jumlah transaksi yang sering muncul tetapi jarang terlihat pada penggunaan normal
• Contoh kondisinya mencari kisaran jumlah berikut
  • $1.00, $5.00, $10.00
  • $99.50 atau lebih dan kurang dari $100.00
  • $499.50 atau lebih dan kurang dari $500.00
• Jumlah dolar bulat yang kecil umumnya merupakan sinyal pengujian kartu
  • Alurnya adalah memeriksa apakah nomor dari dump kartu benar-benar berfungsi sebelum dijual kembali
  • Jarang ada pemilik kartu asli membeli barang dengan harga tepat $1.00
  • Kopi cenderung bernilai seperti $4.73, dan bensin seperti $52.81, bukan jumlah yang dibulatkan persis
• Jumlah tepat di bawah ambang memiliki arti lain
  • $99.99 bisa menjadi cara menghindari batas yang di banyak tempat mewajibkan verifikasi identitas mulai $100
  • $499.99 bisa menjadi cara menghindari batas harian ATM sebesar $500
  • Ini menjadi sinyal bahwa pelaku memahami aturan dan sengaja tetap berada sedikit di bawahnya
• Pada transaksi manfaat, pola jumlah bulat tidak terlalu membantu
  • Manfaat tidak diuji seperti kartu
  • Biasanya, penerima ganda lebih merupakan sinyal penting

4. Suspicious merchants: konsentrasi anomali pada tingkat merchant

• Jika reader kartu tertentu, seperti card reader pada pompa bensin, terinfeksi skimmer, akibatnya bisa bukan hanya satu kasus melainkan puluhan kasus penipuan
• 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 singkat, disertai nilai transaksi yang juga membesar
• Contoh ambang sederhana: untuk 7 hari terakhir, kelompokkan per merchant dan per jam lalu hitung
  • jumlah kartu unik
  • total jumlah transaksi
  • total nilai transaksi
  • cari slot waktu saat jumlah kartu unik melebihi 20 dan total nilai melebihi $5000
• Ambang statis punya masalah penyesuaian skala
  • Costco bisa melewati ambang itu dalam 90 detik
  • toko buku bekas mungkin hampir tidak pernah melewatinya
• Pendekatan yang lebih baik adalah membandingkan tiap merchant dengan baseline historisnya sendiri
  • kelompokkan transaksi 60 hari terakhir per jam
  • hitung rata-rata jumlah kartu unik berdasarkan 168 bucket jam historis untuk setiap merchant
  • cari interval saat jumlah kartu unik saat ini melebihi 3 kali rata-rata historis
• 168 bucket jam berarti slot per jam selama 7 hari terakhir
  • karena musiman harian dan mingguan itu penting
  • coffee shop yang sama pun punya baseline berbeda antara Selasa pukul 14.00 dan Sabtu pukul 09.00
• Sebagai titik awal, bisa gunakan 3 kali lipat dari biasanya
  • cukup longgar agar alert tidak membanjir
  • tetapi cukup ketat untuk tetap 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 bekerja pukul 9 sampai 5 tiba-tiba mulai membeli bensin pada pukul 3 pagi, mungkin kartunya dipakai orang lain atau dia sedang bepergian
• Apakah dia sedang bepergian dapat diverifikasi lagi dengan sinyal lain
• Query menghitung jumlah transaksi per pemilik kartu dan per jam dalam 90 hari terakhir, lalu hanya mengakui jam yang pernah memiliki setidaknya 2 transaksi sebagai jam kebiasaan
• Setelah itu, transaksi baru dideteksi jika waktunya berada di luar rentang earliest_hour dan latest_hour milik pemilik kartu tersebut
• Kondisi “setidaknya 2 transaksi pada jam itu” dalam query internal sangat penting
  • Ini mencegah satu transaksi isi bensin tengah malam yang kebetulan terjadi 3 bulan lalu masuk sebagai jam kebiasaan
  • Ambangnya disesuaikan dengan kebiasaan nyata, bukan “sesuatu yang pernah terjadi sekali”
• Kekurangannya adalah memerlukan data historis
  • akun baru tidak punya baseline
  • untuk akun baru, Anda bisa memakai pola jam transaksi seluruh pengguna, atau melewati pola ini sampai akun mengumpulkan histori 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, Anda dapat membuat kolom turunan berikut
  • waktu yang berlalu sejak transaksi sebelumnya: timestamp - LAG(timestamp)
  • apakah merchant berubah: bandingkan merchant_id sebelumnya dengan merchant_id saat ini
  • jumlah kumulatif 24 jam terakhir: SUM(amount) OVER (...)
  • transaksi ke berapa pada hari itu: ROW_NUMBER()
• Jika kolom-kolom ini dimaterialisasi, aturan penipuan menyusut menjadi ekspresi filter yang sederhana
• Kelompok penguji kartu bisa ditemukan dengan kondisi berikut
  • transaksi ke-5 atau lebih pada hari itu
  • kurang dari 60 detik sejak transaksi sebelumnya
  • merchant berbeda dari transaksi sebelumnya
• Jika hipotesis penipuan baru bisa dinyatakan sebagai filter SQL, bukan tiket engineering, siklus iterasi bisa turun dari hitungan minggu menjadi hitungan jam
• Hasilnya, lebih banyak penipuan bisa ditangkap lebih cepat

Cara memakai pola-pola ini bersama-sama

• Tidak ada satu pola pun yang cukup sendirian
• Setiap pola punya batasan yang jelas
  • Velocity punya false positive seperti operator vending machine
  • Perpindahan yang mustahil secara geografis akan melewatkan penipuan yang terjadi dalam satu area metropolitan besar
  • Anomali jumlah tidak terlalu cocok di luar konteks pengujian kartu
  • Aturan waktu tidak normal memerlukan histori
• Dalam praktik, pendekatan yang efektif adalah menjalankan semua pola lalu memberi skor setiap transaksi berdasarkan banyak sinyal
• Transaksi yang terkena tiga atau empat sinyal hampir selalu merupakan penipuan
• Transaksi yang hanya terkena satu sinyal bisa jadi sekadar penggunaan yang tidak biasa dari pemilik kartu normal yang sedang bepergian
• Jika baru mulai membangun deteksi penipuan, sebaiknya mulai dari Velocity
  • mengungkap jumlah penipuan yang berguna
  • relatif sedikit menangkap aktivitas normal
  • biaya eksekusinya juga rendah
• Jika pola 1 sampai 5 sudah dimiliki, investasi berikutnya yang paling baik adalah kolom mentah berbasis window function
  • sekali dibuat, semua analis di tim dapat memakainya
  • penambahan pola penipuan berikutnya tidak lagi menjadi proyek terpisah

Hal-hal yang perlu diperhatikan

• Penanganan NULL

  • Tabel transaksi nyata sering kali tidak memakai NULL seperti di buku pengantar SQL
  • Banyak sistem legacy 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
  • Anda perlu memeriksa konvensi pada tabel tertentu sebelum menulis klausa WHERE

• False positive

  • Setiap aturan bisa menangkap perilaku yang aneh tetapi sah dari pemilik kartu nyata
  • Kasus yang terflag memerlukan tinjauan manusia
  • Diperlukan feedback loop untuk menyesuaikan ambang berdasarkan mana yang benar-benar penipuan dan mana yang bukan
  • Pemblokiran otomatis berdasarkan satu aturan saja bisa membuat Anda kehilangan pelanggan

• Privasi

  • Jika data mengandung PII, Anda harus mematuhi kebijakan penggunaan data yang berlaku
  • Sebaiknya mulai dengan data yang sudah dide-identifikasi atau data sampel, lalu gunakan data produksi setelah ada persetujuan

• Biaya

  • Window function pada partisi besar tidaklah murah
  • Filter dulu rentang tanggal, baru terapkan window function
  • Jika Anda menjalankan LAG() lebih dulu pada transaksi 2 tahun untuk seluruh dataset lalu baru menambahkan WHERE, anggaran kredit data warehouse bisa terkuras besar

[kaydash]

Ini adalah metode yang dulu pernah dipinjam dan digunakan di sistem inti perbankan dan sistem kanal.

[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

[aliveornot]

Tadinya saya bingung apa maksudnya jumlah bulat.. ternyata rounded ya

[xguru]

Kenapa ini diterjemahkan seperti itu ya, hiks. Saya sudah memperbaikinya.