Scamdetectie op je telefoon is geen fraudebeleid

Een medewerker van een installatiebedrijf krijgt een bericht van een vaste leverancier: de rekening voor morgen moet naar een nieuw IBAN. De toon klopt, de order klopt en de afzender lijkt vertrouwd. Mijn stelling: zelfs perfecte scamdetectie op de telefoon is geen fraudebeleid. De beslissende beveiliging zit tussen het bericht en de betaling.

Dat maakt een nieuwe ontwikkeling van Google DeepMind en de overheid van Singapore interessant, maar ook makkelijk verkeerd te begrijpen. Zij beschrijven een hulpmiddel dat met lichte Gemma-modellen verdachte patronen in privégesprekken op het apparaat zelf herkent, zonder die gesprekken naar de cloud te sturen. Dat is een wezenlijk andere aanpak dan een filter dat alleen bekende afzenders of links controleert. Bron: https://deepmind.google/blog/on-device-ai-scam-detection-mddi/.

De gevaarlijke stap is niet het bericht, maar de handeling erna

Een scam hoeft geen verdachte link te bevatten. De oplichter kan een gesprek voeren, geduldig een relatie opbouwen en pas na meerdere berichten om een overboeking vragen. Juist daarom is detectie tijdens een gesprek een zinnige ontwikkeling: de context telt mee, niet alleen een losse zin.

Maar een waarschuwing is geen blokkade op de bankrekening. De medewerker kan haar wegklikken, de formulering verkeerd begrijpen of aannemen dat deze leverancier een uitzondering is. En als de waarschuwing uitblijft, is dat geen bewijs dat het verzoek veilig is. Geen melding is geen goedkeuring.

Daarom zou ik een MKB-bedrijf niet eerst vragen welke AI-scanner het wil installeren. Ik zou vragen: wat gebeurt er als iemand per chat een rekeningnummer wijzigt? Als het antwoord is ‘de administratie past het aan’, zit daar het echte probleem.

Privacyvriendelijker betekent niet risicovrij

Het sterke aan de beschreven aanpak is dat de analyse lokaal kan plaatsvinden. Een bericht hoeft dan niet naar een externe server om beoordeeld te worden. Voor een gesprek met klantgegevens, offertes of personeelsinformatie is dat een relevant ontwerpverschil.

Toch verdient ‘op het apparaat’ een precieze vraag: welke gegevens verlaten het apparaat nog wél? Denk aan diagnostiek, gebruiksstatistieken, updates en eventuele meldingen die een gebruiker zelf deelt. De bron beschrijft geen cloudverkeer voor de privégesprekken; dat zegt niet automatisch alles over iedere mogelijke gegevensstroom van een uiteindelijke toepassing.

Ook lokaal verwerken vraagt om keuzes. Wie mag de waarschuwing zien? Wordt er iets bewaard? Werkt de detectie in alle berichtendiensten, talen en toesteltypen die medewerkers gebruiken? Zonder antwoorden op die vragen kun je de techniek niet als bedrijfsbrede maatregel behandelen.

En er is een menselijke kant. Een werkgever die ‘voor de veiligheid’ privégesprekken van medewerkers wil laten controleren, creëert een nieuw vertrouwensprobleem. Een hulpmiddel dat een gebruiker op het eigen toestel waarschuwt, is iets anders dan een dashboard waarmee de baas gesprekken kan volgen. Die grens moet helder blijven.

Maak van een betaalverzoek een proces, geen oordeel

Stel dat een leverancier op vrijdag om 16.40 uur een nieuw rekeningnummer doorgeeft. De factuur is €8.400 en moet volgens het bericht vandaag nog betaald worden. De combinatie van tijdsdruk en een bekend contact maakt dit lastig voor een medewerker, ook als die goed is getraind.

De oplossing is niet dat die medewerker voortaan beter moet ‘aanvoelen’ of het echt is. Leg vast dat een IBAN-wijziging nooit op basis van het inkomende bericht wordt verwerkt. Bel de leverancier via een nummer dat al in je eigen administratie stond, laat een tweede persoon de wijziging bevestigen en bewaar wie welke controle heeft gedaan.

Dat kost tijd. Reken bijvoorbeeld met twee controles van vijf minuten, bij een intern uurtarief van €40: ongeveer €6,67 aan arbeid per wijziging. Dit is een rekenvoorbeeld, geen gemeten gemiddelde. Tegenover één verkeerd overgemaakte factuur is die frictie doorgaans een goede ruil.

Belangrijker nog: de controle werkt ook als een scam geen alarmsignaal oplevert. Ze werkt bij een overtuigend gesprek, een gehackt account en een gewone typefout in een rekeningnummer. Een goede procedure is niet afhankelijk van hoe slim het bericht eruitziet.

Waar AI-waarschuwingen wél waarde toevoegen

Zie een lokale waarschuwing als een remlicht. Het vertelt de bestuurder dat er mogelijk iets misgaat, maar neemt het stuur niet over. Vooral bij een gesprek dat langzaam richting betaalgegevens, inlogcodes of geheimhouding schuift, kan zo'n signaal iemand nét op tijd laten stoppen.

Voor een klein accountantskantoor kan dat relevant zijn wanneer een medewerker berichten ontvangt namens tientallen klanten. Voor een webshop kan het gaan om een zogenaamd bericht van een betaalpartner over een vastgelopen uitbetaling. De vorm verschilt, maar het patroon is hetzelfde: iemand probeert via een vertrouwd kanaal een uitzondering op de normale werkwijze af te dwingen.

Juist daarom zou ik de waarschuwing koppelen aan een eenvoudige vervolgstap. Niet: ‘Let op, mogelijk fraude’, waarna de medewerker alleen verder moet. Wel: ‘Stop de handeling, controleer via een eerder vastgelegd kanaal en meld het verzoek intern.’ De waarde van detectie wordt pas zichtbaar als iemand weet wat ermee te doen.

Dat geldt ook voor fout-positieven. Een echte leverancier kan onhandig formuleren of haast hebben. Als elk alarm leidt tot een ingewikkeld incidenttraject, gaan mensen waarschuwingen negeren. Maak de eerste controle klein en voorspelbaar, zodat ook een onterecht signaal weinig schade doet.

Test je proces zonder nieuwe software

Je hoeft niet te wachten tot deze specifieke techniek beschikbaar is voor jouw bedrijf. Pak de laatste tien verzoeken erbij om een rekeningnummer, betaaltermijn of contactpersoon te wijzigen. Vraag per verzoek: via welk kanaal kwam het binnen, wie controleerde het en waar is die controle terug te vinden?

Vind je bij drie verzoeken geen onafhankelijk controlemoment, dan heb je een concreet verbeterpunt. Niet omdat die drie verzoeken fraude waren, maar omdat je bij het volgende verzoek niet op een medewerker onder tijdsdruk wilt vertrouwen. Leg vervolgens één regel vast die iedereen kan uitvoeren: wijzigingen in betaalgegevens worden bevestigd via een al bekend contactkanaal.

Geef ook aan wie bij twijfel beslist. In een bedrijf van twaalf mensen hoeft dat geen comité te zijn; een eigenaar en een vervanger volstaan vaak. Zorg wel dat afwezigheid of haast geen reden wordt om de controle over te slaan. Een proces dat alleen op rustige dinsdagen werkt, is geen proces.

Pas daarna zou ik een AI-waarschuwing beoordelen. Vraag bij een proef niet alleen hoeveel verdachte berichten ze herkent, maar ook hoeveel onterechte meldingen ontstaan, welke gesprekken buiten bereik vallen en of medewerkers na een melding daadwerkelijk de afgesproken controle uitvoeren. Zonder die laatste meting test je een schermmelding, geen fraudepreventie.

De grens van deze ontwikkeling

Lokale modellen kunnen helpen bij patronen in gesprekken. Ze kennen niet automatisch jouw leveranciersbestand, interne bevoegdheden of een mondelinge afspraak met de eigenaar. Een bericht kan bovendien volkomen normaal klinken terwijl de afzender is overgenomen. Dat is geen reden om de techniek af te schrijven, wel om haar taak scherp te begrenzen.

Mijn advies voor het MKB is dus minder futuristisch dan het nieuws doet vermoeden: bouw eerst de regel die een betaling tegenhoudt, gebruik daarna slimme detectie om mensen vaker op tijd naar die regel te leiden. De telefoon mag waarschuwen. Het betaalproces moet beslissen.