Stripe Radar doskonale robi to, do czego został stworzony: ocenia transakcję w momencie, gdy przepływają pieniądze. Ale właśnie wtedy, gdy pieniądze nie przepływają, pojawia się nasz problem.
Oferujemy 7-dniowy darmowy okres próbny. Aby go rozpocząć, użytkownik zapisuje kartę, ale nigdy nie jest obciążany — w tle to Stripe SetupIntent, a nie płatność. Brak obciążenia oznacza brak zdarzenia w momencie płatności, co sprawia, że najpotężniejsze reguły Radaru nie mają czego oceniać w najważniejszym momencie: gdy tworzone jest fałszywe konto i zaczyna wykorzystywać kredyty próbne.
To historia o tym, jak przeszliśmy od gaszenia pożarów związanych z oszustwami na czacie do uruchomienia zautomatyzowanej, minutowej warstwy ochrony przed nadużyciami — zbudowanej na naszym własnym produkcie, Zero.
Radar jest świetny. "Świetny" to nie "idealny".
Stripe Radar naprawdę dobrze spełnia swoją rolę. Modele, wytrenowane na ponad $1 bilionie rocznego wolumenu płatności, rozpoznają kartę, którą już widziały w 92% przypadków, a Stripe podaje, że Radar średnio redukuje oszustwa o 32% dla firm, które z niego korzystają.
Przeczytaj tę liczbę jeszcze raz: redukuje, nie eliminuje. Średni spadek o 32% to dużo — ale oznacza, że znaczna część presji oszustw nadal dociera do Twoich drzwi, a Stripe uczciwie tłumaczy dlaczego. Ich własnymi słowami: „zmniejszenie liczby fałszywych alarmów często zwiększa prawdopodobieństwo, że prawdziwe oszustwa przejdą niezauważone.” Przeciek to nie błąd modelu; to celowy koszt nieblokowania prawdziwych klientów. Każdy zespół ds. oszustw świadomie decyduje, ile przepuścić.
Dla produktu opartego na okresie próbnym ten przeciek jest większy, niż sugeruje główna liczba — bo najpotężniejsza część Radaru nawet się nie uruchamia.
Dlaczego bramka może tylko ograniczać
Jest głębszy powód, dla którego silnik działający w momencie płatności może ograniczyć oszustwa, ale nigdy ich nie wyeliminuje, i nie chodzi tu o modele Stripe — chodzi o czas i informacje. W chwili dodania karty klient jeszcze nic nie zrobił. Brak historii logowań, brak zachowań w produkcie, brak wzorca użytkowania — tylko karta i kilka sygnałów sieciowych. Radar podejmuje najlepszą możliwą decyzję na podstawie najcieńszego wycinka danych, w momencie, gdy ma najmniej informacji.
To jest prawdziwy sufit. Możesz dostroić bramkę, ale nie dasz jej danych, które jeszcze nie istnieją. Informacje, które naprawdę odróżniają nadużywającego od klienta, powstają głównie po tym, jak bramka musiała już podjąć decyzję.
Etap 1: Gaszenie pożarów na czacie
Nasza pierwsza reakcja była całkowicie ręczna. Gdy pojawiała się fala nadużyć, ktoś otwierał rozmowę z naszym agentem i na żywo rozwiązywał incydent: pobierał ostatnie rejestracje, sprawdzał karty, szukał wzorca, ręcznie zamykał konta.
To działało, ale nie było skalowalne. Każdy incydent zaczynał się od zera. Wiedza — jak wygląda ta grupa, które sygnały są wiarygodne — istniała w głowie jednej osoby i jednym wątku czatu, i znikała, gdy okno się zamykało.
Nauczyliśmy się też kosztownej lekcji po dobrej stronie lejka: gdy chcieliśmy odzyskać prawdziwych użytkowników, którzy porzucili koszyk, nieostrożny e-mail do fałszywego adresu wyrządzał realną szkodę — potwierdzał, że adres jest aktywny. Każda automatyzacja musiała odróżniać prawdziwego klienta od podstawionego.
Etap 2: Wzmocnienie wejścia za pomocą Radaru
Następnie przesunęliśmy wszystko, co mogliśmy, do Radaru — listy blokad i reguły prędkości na etapie dodawania karty, dostosowane do presji, którą obserwowaliśmy. To właściwy pierwszy krok i zatrzymał najprostsze ataki.
Ale szybko pojawiły się dwa ograniczenia. Pierwsze to to, które sam Stripe wskazuje: silnik działający w momencie płatności to pokrętło kompromisu, nie mur — podkręć i blokujesz prawdziwych klientów, poluzuj i więcej oszustw przechodzi. Drugie jest strukturalne i dotyczy okresów próbnych: ocena 32% następuje przy płatności, a okres próbny SetupIntent nie generuje płatności do oceny. Jeśli nie włączysz Radaru dla zapisanych metod płatności, silnik w ogóle się nie uruchamia — a nawet gdy działa, na SetupIntent obowiązują tylko reguły Block, Allow i 3DS. Akcja „Review”, która daje człowiekowi drugą szansę, nigdy się nie uruchamia.
Najlepiej działająca warstwa w całym stosie domyślnie nie działa w momencie, gdy jest najbardziej potrzebna. Radar to bramka przy wejściu. Potrzebowaliśmy patrolu za nią.
Etap 3: Druga warstwa, zbudowana na Zero
Po rejestracji obraz informacji się odwraca. Konto zaczyna zostawiać ślady — a najcenniejsza część tych śladów znajduje się w systemie, którego procesor płatności nigdy nie widzi: naszym dostawcy tożsamości, Clerk.
Daliśmy więc Zero do niego dostęp. Clerk wie rzeczy, których Stripe nie zna: jak utworzono konto, metoda rejestracji i e-mail, sesja i urządzenie, a także dokładny czas względem innych rejestracji tego dnia. Stripe zna kartę. Żaden z tych systemów samodzielnie nie daje pełnego obrazu — ale agent może czytać oba i korelować dane między nimi. Nadużycie niewidoczne przy bramce staje się oczywiste w zestawieniu: nowe konto, którego tożsamość logowania nie zgadza się z tożsamością rozliczeniową, utworzone chwilę po grupie podobnych kont. Takiego połączenia systemów bramka nie zrobi — a agent nadzorujący oba już tak.
Na tej bogatszej bazie dowodowej uruchamiamy zestaw zaplanowanych zadań Zero co kilka minut na bieżących danych rejestracyjnych i rozliczeniowych. Kierują nimi trzy zasady:
1. Patroluj, nie tylko blokuj. Zamiast oceniać jeden moment, agent przegląda wszystkie ostatnie rejestracje w krótkiej pętli, korelując dane konta i metadane płatności, by wyłapać konta, które przeszły przez bramkę.
2. Stopniuj reakcję według pewności. Nie każdy sygnał zasługuje na tę samą reakcję. Wzorce o wysokiej pewności obsługiwane są automatycznie — konto jest zawieszane, a okres próbny anulowany natychmiast, bo akcja jest odwracalna, a koszt zwłoki realny. Sygnały o niższej pewności nigdy nie są automatycznie obsługiwane; trafiają do raportu do ręcznego przeglądu. Decyzyjność tam, gdzie to bezpieczne, ostrożność tam, gdzie nie.
3. Zachowaj audyt dla człowieka. Każda automatyczna akcja zapisuje dokładny sygnał, który ją wywołał, by można było ją przejrzeć — i cofnąć — w kilka sekund. Automatyzacja bez audytu to automatyzacja bez zaufania.
Tę samą staranność zastosowaliśmy po przyjaznej stronie lejka. Osobne zadanie znajduje prawdziwych użytkowników, którzy porzucili koszyk, i tworzy szkic e-maila odzyskującego, do zatwierdzenia przez człowieka — za celowo silnym filtrem antyfraudowym, by nigdy nie potwierdzić złego adresu. Ten sam silnik, odwrotny cel.
Wpływ na ekonomię
Gdy patrol ruszył, liczby zmieniły się natychmiast. Spójrz na rejestracje z 90. percentyla — konta, które generowały największe straty. Zużycie mocy obliczeniowej przez jedno takie konto w pierwszych godzinach spadło z około $4 do około $0.25 — spadek o 94%. Średnio na każde nowe konto w tym samym okresie strata spadła o około 85%.
Kształt tej zmiany mówi wszystko. Większość rejestracji nigdy nie kosztowała nas nic; straty zawsze koncentrowały się w długim, ciężkim ogonie kont stworzonych tylko po to, by wyczerpać kredyty próbne. Patrol nie zmniejszył lejka — odciął ten ogon. Nie mniej rejestracji. Czystsze.
Dlaczego agent, a nie skrypt
Mogliśmy napisać zadanie cron. Nie zrobiliśmy tego z jednego powodu: zagrożenie zmienia się szybciej niż cykl wydawniczy. Gdy atakujący zmienia taktykę, aktualizujemy instrukcje zadania w zwykłym języku i nowa logika działa już przy następnym uruchomieniu — bez wdrożenia, bez migracji schematu, bez zgłoszenia. „Reguły” to prompt, a prompt zmienia się tak szybko, jak atakujący.
To najważniejsza lekcja. Radar to właściwe narzędzie do oceny ryzyka w momencie płatności i mocno na nim polegamy. Ale produkt oparty na okresie próbnym ma strukturalną ślepotę, której żadne narzędzie działające przy płatności nie pokryje — i rozwiązaniem nie jest większy silnik reguł. To szybka, audytowalna, zawsze aktywna druga warstwa, którą można przeprogramować w tempie zagrożenia.
Wnioski dla zespołów oferujących okres próbny
- Zmapuj momenty bez płatności. Wszędzie tam, gdzie użytkownik otrzymuje wartość przed oceną płatności, powstaje luka, której narzędzie płatnicze nie widzi.
- Warstwuj, nie zastępuj. Pozostaw Radar przy wejściu. Dodaj ciągły patrol po rejestracji.
- Łącz dane między systemami. Twój procesor płatności i dostawca tożsamości mają po połowie obrazu. Nadużycie widać w ich nakładaniu się.
- Stopniuj działania według pewności i loguj każde. Automatyzuj tylko tam, gdzie akcja jest odwracalna i sygnał silny; resztę kieruj do człowieka.
- Optymalizuj pod kątem szybkości adaptacji. W walce z oszustwami wygrywa zespół, który najszybciej zmienia reguły.
Ciekawi Cię, co agent zawsze aktywny mógłby zautomatyzować w Twoim stacku? Poznaj Zero.
Uwagi: Dane Radaru pochodzą z oficjalnych publikacji Stripe (stripe.com/radar; „A primer on machine learning for fraud detection”). Straty dotyczą kosztów obliczeniowych na nowe konto w pierwszych godzinach po rejestracji, mierzone w porównywalnych okresach przed i po wdrożeniu, z wyłączeniem kont wewnętrznych; próbka po wdrożeniu jest jeszcze wczesna i z czasem się ustabilizuje.
