Frauduleuze transacties en RapidMiner

Het ontdekken van financiële fraude is een belangrijk tak van sport binnen de Machine Learning wereld. Probleem is de publieke beschikbaarheid van real-life data. De banken beschikken uiteraard over hun eigen data-sets, maar voor buitenstaanders is het lastig om aan goede data te komen vanwege allerlei privacy-regels en dergelijken.

De data-set die ik heb gebruikt is afkomstig van Kaggle en is gegenereerd door simulatie van financiële transacties. Voor een detail-beschrijving van de data-set, zie http://bth.diva-portal.org/smash/get/diva2:955852/FULLTEXT06.pdf

In het kort bestaat de data-set uit een aantal transacties (ongeveer 6 miljoen) die voor een periode van 30 dagen zijn gegenereerd. De transacties zijn afkomstig van een mobiel-betalen provider. Het zijn betalingen van klanten onderling en van klanten naar merchants (winkeliers?) die diensten rondom het mobiele betalen aanbieden. Denk aan diensten als het storten of opnemen van cash geld en het uitschrijven van cheques voor klanten die geen mobiel-betalen account hebben.

In de data-set zijn twee fraude-scenario’s opgenomen. Het eerste scenario is dat de boeven via phishing de rekeninggegevens van een klant hebben achterhaald en vervolgens de rekening leeghalen door het geld over te maken naar muilezel-rekeningen en het geld vervolgens als cash bij de merchant opnemen. Het tweede scenario bestaat uit scamming waarbij klanten overgehaald worden rekeninggegevens, inclusief PIN-codes bekend te maken voor een of ander doel en waarna ook de rekening geplunderd wordt.

Deze blog is gebaseerd op een artikel op Kaggle van Arjun Joshua: https://www.kaggle.com/arjunjoshua/predicting-fraud-in-financial-payment-services/notebook. In het artikel van wordt gebruik gemaakt van Python. Mijn benadering is iets anders en ik probeer met de data-set en RapidMiner een model te ontwikkelingen om fraude in de transactie-log op te sporen/te voorspellen.

Data exploratie

De eerste stap is het analyseren en opschonen van de data. Hiervoor heb ik Excel gebruikt. Nadeel is dat Excel maximaal 1 miljoen rijen (1.048.576) aan kan. We werken dus met 1/6 van de gehele dataset (is ongeveer 4 dagen logging). We veronderstellen dat de verdeling van de fraudegevallen ‘uniform’ is over de gehele periode 30 dagen. Voordeel is dat we het ontwikkelde machine learning model kunnen testen op de resterende 5 miljoen transacties.

Hieronder staat een voorbeeld van de data-set.

  • Step: het nummer geeft het uur aan. Step = 1 betekent het 1e uur van de logfile;
  • Type: dit is het soort transactie:
    • CASH-IN: contant geld storten bij de merchant
    • CASH-OUT: content geld opnemen bij de merchant
    • DEBIT: is geld opnemen van de rekening naar een bankrekening.
    • PAYMENT: betaling voor goederen of diensten
    • TRANSFER: mobiel betalen van geld tussen klanten
  • Amount: dit is het bedrag van de transactie; waarschijnlijk in Zweedse kronen omdat de ontwikkeling van deze data-set als promotie onderzoek is uitgevoerd aan een Zweedse Universiteit;
  • Name Orig, Name Dest: zijn de klant of merchant namen. C….. is Client en M….. is Merchant;
  • Oldbalance Org en Dest, Newbalance Org en Dest zijn de saldo’s voor en na de transactie van de betreffende klant of merchant;
  • isFraud: is de indicatie dat de betreffende transactie fraude betreft;
  • isFlaggedFraud: is niet relevant.

Voor het analyseren van de data, is het zaak om te ontdekken of er bepaalde patronen aanwezig zijn. Hiervoor hebben we het data filter in Excel gebruikt.

Onbalans

Als je alle transacties die als frauduleus zijn gekenmerkt (isFraud = 1) filtert, dan zie je dat het in alle gevallen gaat om de transacties TRANSFER en CASH-OUT. Het aantal fraudegevallen bedraagt 1.142 op een totaal van 1.048.576 transacties, overeenkomend met ongeveer 0,1 %. Dat is een duidelijke onbalans in de data-set en in principe een probleem bij dit soort classificatie vraagstukken. Voor het verdere verloop laten we het even buitenbeschouwing. We kunnen er later nog op terugkomen.
Verder zie we dat deze transacties vaak opeenvolgend zijn en gelijke bedragen betreffen.

Zie onder.

Uit verder onderzoek (bv. komen bepaalde nameOrig of nameDest vaker voor dan je zou verwachten of zijn er patronen te ontdekken rondom de kolommen die de bedragen voorstellen e.d.) blijkt dat de kolommen van de personen niet van belang zijn. Ook de rol van de merchants is niet van belang. Als je zoekt in de nameOrig en nameDest kolommen naar strings die beginnen met een “M”, zie je dat bij de fraude transacties geen merchants betrokken zijn. Wat op zich merkwaardig is omdat de CASH-OUT transactie volgens de toelichting op de data-set alleen via een merchant plaatsvindt. In het algemeen lijkt de data-set op bepaalde aspecten niet consistent. Dit is niet onoverkomelijk omdat in real-life situaties de data-sets meestal ook niet ideaal zijn.

Feature engineering

De constatering met Excel data filtering dat fraude transacties vaak achtereenvolgens worden uitgevoerd en waarbij de betrokken bedragen gelijk zijn, kan gebruikt worden om een nieuwe feature aan de data-set toe te voegen.

Om de tijdvolgordelijkheid te introduceren voegen we een kolom Ordinal met ordinaalgetallen 1,2,3,…. Als eerste indicatie voor fraude voegen we een kolom Equal Amount Successor toe die vastlegt of het bedrag van de transactie gelijk is aan het bedrag van de volgende transactie.

De kolommen Ordinal en Equal Amount Successor gebruiken we om een nieuw kolom Suspicious Transaction te introduceren die als nieuwe feature gaat dienen. De waarde drukt uit dat een transactie verdacht is en dat er samenhang is met de vorige of volgende transactie. Op deze manier krijgen we gepaarde transacties die als verdacht gekenmerkt kunnen worden. De waarde van het nieuwe feature wordt in Excel als volgt bepaald:

= IF ( AND((Ai-Ai-1=1); OR(Di=Di-1;Di=Di+1)) ; TRUE ; Ni-1)
Met:

  •  i de lopende rij;
  • A de kolom met Ordinal;
  • D de kolom voor amount;
  • N de kolom met boolean Equal Amount Successor: (amount(i-1) = amount(i)).

Hieronder staat een voorbeeld van het resultaat.

Van de 1.142 fraudegevallen zijn er 27 die niet voldoen aan het Suspicious Transaction criterium maar toch als fraude zijn gekenmerkt. Dat is ongeveer 2% van het totaal. Deze afwijkende gevallen laten we even liggen omdat ze qua aantal statistisch gezien verwaarloosbaar zijn.

De volgende stap is om met RapidMiner een model te ontwikkelen en te valideren. Globaal worden de stappen: Inlezen Data, Selecteren Attributen, Algoritme kiezen, Cross Valideren, resultaten bekijken.

Voor het opsporen van fraude worden verschillende ML technieken gebruikt. De Decision Tree (DT) methode komt vaak voor omdat die een goed beeld geeft van de situatie. Zie afbeelding onder. Dit in tegenstelling tot bijvoorbeeld Deep Learning dat eigenlijk een black-box is met een partij geheimzinnige parameters die je vertellen wat er binnen de box gebeurd is.

Met DT zie je meteen op welke kenmerken (attributen) het DT algoritme onderscheid maakt tussen de aangeboden gegevens. Uiteraard heeft ook DT een aantal knoppen waar je aan kunt draaien en die vorm en diepte van de Tree bepalen.  Wat opvalt is dat met Suspicious Transaction al meteen het merendeel (66) van de vermoedelijke fraude transacties onderscheiden wordt. Daarna wordt er in de resterende transacties gekeken naar een nieuw ingevoerd berekend eindsaldo (errorBalanceNew, zie artikel van Arjun Joshua) na uitvoering van een transactie. Hier wordt nog maar 1 transactie als frauduleus beschouwd.

Om te voorkomen dat een Tree tot in verre hoogtes groeit of overfitted wordt (veel takjes en blaadjes), kun je bijvoorbeeld de diepte van de Tree of het aantal blaadjes maximeren. Dit noemen ze pruning (snoeien). Binnen RapidMiner (RM) wordt standaard een aantal pruning parameters gezet voor het DT algoritme.

In het RapidMiner proces worden extra attributen errorBalanceOrg en errorBalanceNew (zie artikel Arjun Joshua) toegevoegd met de operator Generate Attributes. Deze nieuwe Features (extra attributen) zijn gebaseerd op de waarneming dat bij de transacties die als fraude worden gekenmerkt, de eindsaldo’s veel vaker kleiner, gelijk aan 0 zijn dan bij de niet-fraude transacties. Wat natuurlijk niet zo verwonderlijk is.  De reden dat we deze Features ook gebruiken is om te kijken in hoeverre ze de Feature Suspicious Transaction out-performen. In RapidMiner wordt met de operator Cross Validation het model geoptimaliseerd met een Trainings- en Validatieset.

We maken gebruik van het DT algoritme met de standaard parameter instellingen. Als we het proces runnen dan levert dat de volgende resultaten op.

true false true true class precision
pred. false 9931 2 99.98%
pred. true 0 66 100.00%
class recall 100.00% 97.06%

Wat we zien is dat de standaardinstelling voor DT (met name de pre-pruning instelling) de Tree minimaliseert met maximaal resultaat. Recall en Precision zijn hoog. De Recall zegt iets over de trefkans dat een echte frauduleuze transactie daadwerkelijk gevonden wordt. De Precision zegt iets over de mate van nauwkeurigheid oftewel de verhouding tussen de echte fraudegevallen en alle gevonden (echte en foutieve) fraudegevallen.

Voorlopige conclusie: invoeren van het Feature Suspicious Transaction lijkt een goede voorspeller te zijn voor fraude. Wat achteraf niet verwonderlijk was. Bij de Excel exercitie zagen we al dat 98% van de fraude gevallen ontdekt werden met het Suspicious Transaction feature.