Stripe Radar sangat hebat dalam apa yang dilakukannya: menilai sebuah transaksi pada saat uang berpindah. Tetapi justru saat uang tidak berpindah itulah masalah kami berada.
Kami menjalankan free trial 7 hari. Untuk memulainya, pengguna menyimpan kartu tetapi tidak pernah ditagih — di balik layar, itu adalah Stripe SetupIntent, bukan sebuah pembayaran. Tidak ada penagihan berarti tidak ada event saat penagihan, yang berarti aturan paling kuat Radar tidak punya apa pun untuk dievaluasi pada momen yang paling penting: ketika sebuah akun penipuan sedang dibuat dan mulai membakar trial credit.
Inilah kisah bagaimana kami beralih dari memadamkan kebakaran penipuan di obrolan-obrolan dadakan menjadi menjalankan lapisan anti-penipuan otomatis yang bekerja menit demi menit — dibangun di atas produk kami sendiri, Zero.
Radar memang hebat. "Hebat" bukan berarti "sempurna."
Stripe Radar benar-benar bagus dalam apa yang dilakukannya. Dilatih dengan lebih dari $1 triliun volume pembayaran tahunan, modelnya mengenali sebuah kartu yang pernah mereka lihat sebelumnya 92% dari waktu, dan Stripe melaporkan Radar mengurangi penipuan rata-rata 32% bagi bisnis yang menggunakannya.
Namun, baca lagi angka itu: mengurangi, bukan menghilangkan. Pengurangan rata-rata 32% itu besar — tetapi artinya sebagian besar tekanan penipuan masih tiba di depan pintu Anda, dan Stripe sangat jujur soal alasannya. Dalam kata-kata mereka sendiri, "mengurangi jumlah false positive sering kali meningkatkan kemungkinan lebih banyak penipuan asli lolos melalui celah." Kebocoran bukanlah bug pada modelnya; itu adalah biaya yang disengaja agar tidak memblokir pelanggan asli Anda. Setiap tim anti-penipuan, secara sengaja, memilih seberapa banyak yang dibiarkan lolos.
Untuk produk berbasis trial, kebocoran itu lebih lebar daripada yang ditunjukkan angka utama tersebut — karena bagian Radar yang paling kuat justru tidak pernah berjalan.
Mengapa sebuah gerbang hanya bisa mengurangi
Ada alasan yang lebih dalam mengapa mesin saat penagihan bisa mengurangi penipuan tetapi tak pernah mengakhirinya, dan itu bukan soal model Stripe — melainkan soal waktu dan informasi. Pada saat sebuah kartu ditambahkan, pelanggan belum melakukan apa pun. Tidak ada riwayat sign-in, tidak ada perilaku produk, tidak ada pola penggunaan untuk dipelajari — hanya sebuah kartu dan segelintir sinyal jaringan. Radar membuat keputusan terbaiknya di atas potongan bukti setipis mungkin, pada satu momen ketika ia punya paling sedikit pegangan.
Itulah batas atas yang sebenarnya. Anda bisa menyetel sebuah gerbang, tetapi Anda tidak bisa memberinya data yang belum ada. Informasi yang benar-benar membedakan seorang pelaku penyalahgunaan dari seorang pelanggan sebagian besar baru tercipta setelah gerbang itu sudah harus memutuskan.
Tahap 1: Memadamkan kebakaran di jendela obrolan
Respons pertama kami sepenuhnya manual. Ketika gelombang penyalahgunaan menyerang, seseorang membuka percakapan dengan agent kami dan menangani insidennya secara langsung: tarik signup terbaru, lihat kartunya, temukan polanya, lalu tutup akun-akunnya secara manual.
Itu berhasil, tetapi tidak bisa diskalakan. Setiap insiden dimulai dari nol. Pengetahuannya — seperti apa rupa jaringan penipuan ini, sinyal mana yang andal — hidup di kepala satu orang dan satu thread obrolan, lalu menguap begitu jendela itu ditutup.
Kami juga belajar pelajaran mahal di sisi baik funnel: ketika kami ingin merebut kembali pengguna asli yang meninggalkan checkout, sebuah email outreach yang ceroboh ke alamat penipuan menimbulkan kerugian nyata — ia mengonfirmasi bahwa alamat itu aktif. Otomasi apa pun yang kami bangun harus bisa membedakan antara calon pelanggan asli dan yang ditanam.
Tahap 2: Memperkuat pintu depan dengan Radar
Langkah berikutnya adalah mendorong segala hal yang kami bisa ke hulu, ke dalam Radar — block list dan aturan velocity di langkah penambahan kartu, disetel sesuai tekanan yang kami lihat. Itu langkah pertama yang tepat, dan ia menghentikan serangan-serangan paling kasar.
Tetapi dua batas atas muncul dengan cepat. Yang pertama adalah yang disebut Stripe sendiri: mesin saat penagihan adalah sebuah tombol tradeoff, bukan tembok — putar naik dan Anda memblokir pelanggan asli, putar turun dan lebih banyak penipuan lolos. Yang kedua bersifat struktural dan khas trial: 32% itu diperoleh saat penagihan, dan trial SetupIntent tidak punya penagihan untuk dinilai. Kecuali Anda secara eksplisit mengaktifkan Radar pada metode pembayaran tersimpan, mesinnya tidak berjalan sama sekali — dan bahkan ketika berjalan, hanya aturan Block, Allow, dan 3DS yang berlaku pada sebuah SetupIntent. Aksi "Review", yang memberi manusia kesempatan untuk melihat ulang, tidak pernah aktif.
Jadi lapisan dengan kinerja terbaik di seluruh tumpukan, secara default, justru absen pada momen yang paling kami butuhkan. Radar adalah gerbang di pintu depan. Kami butuh patroli di baliknya.
Tahap 3: Lapisan kedua, dibangun di atas Zero
Setelah signup, gambaran informasinya berbalik. Akun mulai meninggalkan jejak — dan bagian terkaya dari jejak itu hidup di sebuah sistem yang tidak pernah dilihat pemroses pembayaran: penyedia identitas kami, Clerk.
Maka kami memberi Zero akses ke sana. Clerk tahu hal-hal yang tidak diketahui Stripe: bagaimana akun itu dibuat, metode signup dan emailnya, sesi dan perilaku perangkat di baliknya, serta waktu persisnya relatif terhadap setiap signup lain di hari itu. Stripe tahu kartunya. Tidak ada satu sistem pun, sendirian, yang menceritakan kisah utuhnya — tetapi agent bisa membaca keduanya dan mengorelasikan keduanya. Penyalahgunaan yang tak terlihat di gerbang menjadi jelas saat disandingkan: sebuah akun yang benar-benar baru yang identitas sign-in-nya tidak cocok dengan identitas penagihannya, dibuat hanya beberapa saat dari sekelompok akun serupa. Penggabungan lintas sistem itulah yang persis tidak bisa dilakukan gerbang saat penagihan — dan persis yang bisa dilakukan agent yang duduk di atas kedua sistem.
Di atas basis bukti yang lebih kaya itu, kami menjalankan serangkaian tugas Zero terjadwal setiap beberapa menit terhadap data signup dan billing langsung. Tiga prinsip membentuknya:
1. Patroli, bukan sekadar menjaga gerbang. Alih-alih mengevaluasi satu momen, agent menyapu setiap signup terbaru dalam putaran singkat, mengorelasikan data akun dan metadata pembayaran untuk memunculkan akun yang lolos dari pintu depan.
2. Bertingkatkan respons berdasarkan tingkat keyakinan. Tidak setiap sinyal layak mendapat aksi yang sama. Pola berkeyakinan tinggi ditangani secara otomatis — akunnya disuspensi dan trial-nya dibatalkan saat itu juga, karena aksinya bisa dibalik dan biaya menunggu itu nyata. Sinyal berkeyakinan lebih rendah tidak pernah ditindak otomatis; mereka dikumpulkan menjadi sebuah laporan untuk ditinjau manusia. Tegas di tempat yang aman, konservatif di tempat yang tidak.
3. Pertahankan jejak audit untuk manusia. Setiap aksi otomatis mencatat sinyal persis yang memicunya, sehingga bisa ditinjau — dan dibalik — dalam hitungan detik. Otomasi yang tidak bisa Anda audit adalah otomasi yang tidak bisa Anda percaya.
Kami menerapkan ketelitian yang sama di sisi ramah funnel. Sebuah tugas terpisah menemukan pengguna abandoned-checkout yang asli lalu mendraf email win-back untuk disetujui manusia — di balik filter penipuan yang sengaja dibuat ketat, sehingga kami tidak pernah memvalidasi alamat yang buruk. Mesin yang sama, tujuan yang berlawanan.
Apa dampaknya pada ekonomi
Begitu patroli aktif, angka-angka langsung bergerak. Lihat signup di persentil ke-90 — akun-akun berat yang menimbulkan kerugian nyata. Compute trial yang dibakar salah satunya dalam jam-jam pertama turun dari sekitar $4 menjadi sekitar $0,25 — penurunan 94%. Dirata-ratakan di seluruh signup baru pada rentang waktu yang sama, kerugian per akun turun sekitar 85%.
Bentuk perubahannya adalah petunjuknya. Sebagian besar signup tidak pernah merugikan kami; kerugian selalu terkonsentrasi di ekor panjang dan berat berisi akun-akun yang ada hanya untuk menguras trial credit. Patroli itu tidak menyusutkan funnel — ia memotong ekor itu. Bukan signup yang lebih sedikit. Tetapi signup yang lebih bersih.
Mengapa sebuah agent, bukan sebuah skrip
Kami bisa saja menulis sebuah cron job. Kami tidak melakukannya, karena satu alasan: ancamannya berubah lebih cepat daripada siklus rilis. Ketika penyerang mengubah taktik, kami memperbarui instruksi sebuah tugas dalam bahasa sederhana dan logika baru itu langsung aktif pada putaran berikutnya — tanpa deploy, tanpa migrasi skema, tanpa tiket. "Aturannya" adalah sebuah prompt, dan prompt itu secepat penyerang dalam berubah.
Itulah pelajaran yang sebenarnya. Radar adalah tool yang tepat untuk risiko saat penagihan, dan kami sangat bersandar padanya. Tetapi bisnis berbasis trial punya titik buta struktural yang tidak bisa ditutupi oleh tool saat penagihan mana pun — dan solusinya bukanlah mesin aturan yang lebih besar. Solusinya adalah lapisan kedua yang cepat, bisa diaudit, dan selalu aktif yang bisa Anda program ulang secepat ancamannya.
Poin penting untuk tim berbasis trial
- Petakan momen-momen tanpa penagihan Anda. Di mana pun pengguna mendapat nilai sebelum sebuah pembayaran dinilai, di situ ada celah yang tidak bisa dilihat tool saat penagihan.
- Berlapis, jangan mengganti. Pertahankan Radar di pintu depan. Tambahkan patroli pasca-signup yang berkelanjutan di baliknya.
- Gabungkan lintas sistem. Pemroses pembayaran dan penyedia identitas Anda masing-masing memegang separuh gambaran. Penipuannya terlihat di area tumpang tindih.
- Tingkatkan aksi Anda berdasarkan keyakinan, dan catat setiap aksi. Tindak otomatis hanya di tempat aksi bisa dibalik dan sinyalnya kuat; arahkan sisanya ke manusia.
- Optimalkan untuk kecepatan adaptasi. Dalam penipuan, tim yang bisa mengubah aturannya tercepat akan menang.
Penasaran apa yang bisa diotomasikan oleh sebuah agent yang selalu aktif di stack Anda sendiri? Jelajahi Zero.
Catatan: Angka-angka Radar adalah angka publikasi Stripe sendiri (stripe.com/radar; "A primer on machine learning for fraud detection"). Angka kerugian mencerminkan biaya compute per signup baru pada jam-jam pertama setelah registrasi, diukur pada rentang waktu yang dicocokkan sebelum dan sesudah peluncuran, dengan akun internal dikecualikan; sampel pasca-peluncuran masih awal dan akan semakin mantap seiring waktu.