Stripe Radar on erinomainen siinä, mitä se tekee: se pisteyttää tapahtuman sillä hetkellä, kun rahaa liikkuu. Mutta juuri silloin, kun rahaa ei liiku, piili meidän ongelmamme.
Meillä on 7 päivän ilmainen kokeilu. Sen aloittamiseksi käyttäjä tallentaa kortin, mutta häntä ei veloiteta — taustalla kyseessä on Stripe SetupIntent, ei maksu. Koska veloitusta ei tapahdu, ei synny veloitushetken tapahtumaa, jolloin Radar ei pääse hyödyntämään tehokkaimpia sääntöjään juuri sillä hetkellä, kun sillä olisi eniten merkitystä: kun huijaustili luodaan ja alkaa käyttää kokeilukrediittejä.
Tämä on tarina siitä, miten siirryimme yksittäisten huijaustapausten sammuttelusta täysin automatisoituun, minuutin välein toimivaan petostorjuntakerrokseen — rakennettuna oman tuotteemme, Zeron, päälle.
Radar on hyvä. "Hyvä" ei ole "täydellinen."
Stripe Radar on aidosti hyvä siinä, mitä se tekee. Se on koulutettu yli $1 biljoonan vuosittaisella maksuliikenteellä, ja sen mallit tunnistavat aiemmin nähdyn kortin 92% tapauksista, ja Stripen mukaan Radar vähentää petoksia keskimäärin 32% sitä käyttävillä yrityksillä.
Lue tuo luku uudelleen: vähentää, ei poista. 32% keskimääräinen vähennys on suuri — mutta se tarkoittaa, että merkittävä osa petospainetta päätyy silti sinun vastuullesi, ja Stripe on tästä ilahduttavan rehellinen. Heidän omilla sanoillaan: "väärien positiivisten määrän vähentäminen usein lisää todennäköisyyttä, että todellisia petoksia pääsee läpi." Vuoto ei ole mallin virhe, vaan tietoinen hinta siitä, ettei oikeita asiakkaita estetä. Jokainen petostiimi valitsee tietoisesti, kuinka paljon päästää läpi.
Kokeilupohjaisessa tuotteessa tuo vuoto on suurempi kuin otsikkoluku antaa ymmärtää — koska Radarin tehokkain osa ei edes käynnisty.
Miksi portti voi vain vähentää
On syvempi syy siihen, miksi veloitushetken moottori voi vähentää petoksia, muttei koskaan poistaa niitä, eikä se liity Stripen malleihin — vaan ajankohtaan ja tietoon. Kun kortti lisätään, asiakas ei ole vielä tehnyt mitään. Ei kirjautumishistoriaa, ei tuotekäyttäytymistä, ei käyttökuvioita — vain kortti ja muutama verkon signaali. Radar tekee parhaansa ohuimmalla mahdollisella näytöllä, juuri sillä hetkellä, kun sillä on vähiten tietoa käytettävissään.
Tämä on todellinen katto. Porttia voi säätää, mutta sille ei voi antaa tietoa, jota ei vielä ole olemassa. Tieto, joka oikeasti erottaa väärinkäyttäjän asiakkaasta, syntyy pääosin portin jälkeen.
Vaihe 1: Sammuttelua chat-ikkunassa
Ensimmäinen reaktiomme oli täysin manuaalinen. Kun väärinkäytösaalto iski, joku avasi keskustelun agenttimme kanssa ja hoiti tapauksen livenä: haettiin uusimmat rekisteröitymiset, katsottiin kortit, etsittiin kuvio ja suljettiin tilit käsin.
Se toimi, mutta ei skaalautunut. Jokainen tapaus alkoi nollasta. Tieto — miltä tämä rengas näyttää, mitkä signaalit ovat luotettavia — oli yhden henkilön päässä ja yhdessä keskusteluketjussa, ja katosi, kun ikkuna suljettiin.
Opimme myös kalliin opetuksen funnelin hyvältä puolelta: kun halusimme voittaa takaisin oikeita käyttäjiä, jotka olivat jättäneet kassalle siirtymisen kesken, huolimaton yhteydenotto huijausosoitteeseen tekee todellista vahinkoa — se vahvistaa osoitteen olevan käytössä. Kaiken automaation, jonka rakensimme, piti erottaa oikea prospekti istutetusta.
Vaihe 2: Etuoven vahvistaminen Radarilla
Seuraava siirtomme oli siirtää kaikki mahdollinen ylävirtaan Radariin — estolistat ja nopeussäännöt kortinlisäysvaiheessa, säädettynä sen mukaan, millaista painetta näimme. Tämä oli oikea ensimmäinen askel, ja se pysäytti alkeellisimmat hyökkäykset.
Mutta kaksi kattoa tuli nopeasti vastaan. Ensimmäinen on se, jonka Stripe itsekin nimeää: veloitushetken moottori on tasapainosäädin, ei muuri — jos säädät sitä tiukemmaksi, estät oikeita asiakkaita, jos löysemmäksi, enemmän petoksia pääsee läpi. Toinen on rakenteellinen ja liittyy kokeiluihin: 32% ansaitaan veloitushetkellä, ja SetupIntent-kokeilussa ei ole mitään veloitettavaa. Ellet erikseen ota Radaria käyttöön tallennetuissa maksutavoissa, moottori ei käynnisty lainkaan — ja silloinkin SetupIntentissä toimivat vain Block, Allow ja 3DS -säännöt. "Review"-toiminto, joka antaisi ihmiselle toisen tarkastuksen, ei koskaan aktivoidu.
Joten pinon tehokkain kerros on oletuksena poissa pelistä juuri sillä hetkellä, kun sitä eniten tarvittaisiin. Radar on portti etuovella. Me tarvitsimme partion sen taakse.
Vaihe 3: Toinen kerros, rakennettu Zerolla
Rekisteröitymisen jälkeen tietokuva muuttuu. Tili alkaa jättää jälkiä — ja arvokkain osa niistä on järjestelmässä, jota maksupalvelu ei koskaan näe: identiteetin tarjoajassamme, Clerkissä.
Annoimme Zerolle pääsyn siihen. Clerk tietää asioita, joita Stripe ei tiedä: miten tili luotiin, rekisteröitymismenetelmä ja sähköposti, istunto ja laite sen takana sekä tarkka ajoitus suhteessa muihin saman päivän rekisteröitymisiin. Stripe tuntee kortin. Kumpikaan järjestelmä ei yksin kerro koko tarinaa — mutta agentti voi lukea molempia ja yhdistää tiedot niiden välillä. Portilla näkymätön väärinkäyttö tulee ilmeiseksi rinnakkain: upouusi tili, jonka kirjautumisidentiteetti ei täsmää laskutusidentiteettiin, luotu hetkeä aiemmin samannäköisten joukossa. Tämä järjestelmien välinen yhdistys on juuri se, mihin veloitushetken portti ei pysty — ja mihin agentti molempien järjestelmien päällä pystyy.
Tämän laajemman tietopohjan avulla ajamme joukon aikataulutettuja Zero-tehtäviä muutaman minuutin välein tuoreeseen rekisteröitymis- ja laskutusaineistoon. Kolme periaatetta ohjaa niitä:
1. Partioi, älä pelkästään portita. Yhden hetken arvioinnin sijaan agentti käy läpi kaikki tuoreet rekisteröitymiset lyhyellä silmukalla, yhdistäen tilitiedot ja maksutiedot nostaakseen esiin tilit, jotka pääsivät portista läpi.
2. Erota toimenpiteet varmuuden mukaan. Kaikki signaalit eivät ansaitse samaa toimenpidettä. Varmimmat kuviot hoidetaan automaattisesti — tili jäädytetään ja kokeilu perutaan heti, koska toimenpide on peruttavissa ja odottamisen kustannus on todellinen. Vähemmän varmat signaalit eivät koskaan johda automaattitoimiin; ne kootaan raporttiin ihmisen tarkistettavaksi. Ratkaiseva siellä, missä se on turvallista, varovainen siellä, missä ei ole.
3. Pidä inhimillinen auditointijälki. Jokainen automaattinen toimenpide tallentaa tarkan signaalin, joka sen laukaisi, jotta se voidaan tarkistaa — ja perua — sekunneissa. Automaatio, jota ei voi auditoida, ei ole luotettavaa.
Sovelsimme samaa tarkkuutta funnelin ystävälliselle puolelle. Erillinen tehtävä etsii oikeat kesken jättäneet käyttäjät ja luonnostelee voittosähköpostin ihmisen hyväksyttäväksi — tarkoituksella tiukan petossuodattimen takana, jotta emme koskaan vahvista huonoa osoitetta. Sama moottori, päinvastainen tavoite.
Mitä se teki taloudelle
Kun partio oli käynnissä, luvut muuttuivat heti. Katso 90. prosenttipisteen rekisteröitymistä — raskaita tilejä, jotka aiheuttivat todellista vahinkoa. Kokeilulaskentateho, jonka yksi niistä kulutti ensimmäisten tuntien aikana, laski noin $4:sta noin $0.25:een — 94% pudotus. Kaikkien uusien rekisteröitymisten keskiarvolla per tili -tappio laski noin 85%.
Muutoksen muoto kertoo kaiken. Useimmat rekisteröitymiset eivät koskaan maksaneet meille mitään; tappiot keskittyivät aina pitkään, raskaaseen häntään tilejä, jotka oli luotu vain kokeilukrediittien tyhjentämiseen. Partio ei pienentänyt funnelia — se katkaisi tuon hännän. Ei vähemmän rekisteröitymisiä. Puhdistuneempia.
Miksi agentti, ei skripti
Olisimme voineet kirjoittaa cron-ajon. Emme tehneet niin yhdestä syystä: uhka muuttuu nopeammin kuin julkaisusykli. Kun hyökkääjä vaihtaa taktiikkaa, päivitämme tehtävän ohjeistusta selkokielellä ja uusi logiikka on käytössä seuraavalla ajolla — ei julkaisua, ei skeemamuutosta, ei tikettiä. "Säännöt" ovat kehotteita, ja kehotteen muuttaminen on yhtä nopeaa kuin hyökkääjän taktiikan vaihto.
Tämä on todellinen opetus. Radar on oikea työkalu veloitushetken riskin hallintaan, ja käytämme sitä paljon. Mutta kokeilupohjaisessa liiketoiminnassa on rakenteellinen sokeapiste, jota mikään veloitushetken työkalu ei kata — eikä ratkaisu ole isompi sääntömoottori. Se on nopea, auditoitava, aina päällä oleva toinen kerros, jonka voi ohjelmoida uudelleen yhtä nopeasti kuin uhka muuttuu.
Opit kokeiluvetoisille tiimeille
- Karttaile maksuttomat hetket. Kaikki kohdat, joissa käyttäjä saa arvoa ennen maksun arviointia, ovat aukkoja, joita veloitushetken työkalu ei näe.
- Lisää kerroksia, älä korvaa. Pidä Radar etuovella. Lisää jatkuva rekisteröitymisen jälkeinen partio sen taakse.
- Yhdistä järjestelmien välillä. Maksupalvelu ja identiteetin tarjoaja pitävät kumpikin puolet kuvasta. Petos näkyy niiden leikkauspisteessä.
- Erota toimenpiteet varmuuden mukaan ja kirjaa jokainen. Toimi automaattisesti vain, jos toimenpide on peruttavissa ja signaali vahva; ohjaa muut ihmiselle.
- Optimoi sopeutumisnopeus. Petoksissa nopeimmin sääntöjään muuttava tiimi voittaa.
Kiinnostaako, mitä jatkuvasti päällä oleva agentti voisi automatisoida omassa pinossasi? Tutustu Zeroon.
Huomautukset: Radar-luvut ovat Stripen omia julkaistuja tietoja (stripe.com/radar; "A primer on machine learning for fraud detection"). Tappioluvut kuvaavat laskentakustannusta per uusi rekisteröityminen ensimmäisten tuntien aikana ennen ja jälkeen käyttöönoton, sisäiset tilit poissuljettu; käyttöönoton jälkeinen otos on vielä varhainen ja tarkentuu ajan myötä.
