- Helena Nguyen & SannaMari Bölenius
- February 22, 2023
Artikelns primära målgrupp är små och medelstora aktörer
I eftermälet av sanktionsbeslutet mot LF Bank genomför allt fler aktörer en genomlysning av sin transaktionsmonitorering. Penningtvättslagstiftningen och kraven på övervakning av transaktioner har funnits sedan länge. Trots att medvetenheten i branschen är relativt hög, blev Finansinspektionens senaste sanktion ytterligare en påminnelse om vikten av en både heltäckande och riskbaserad monitorering. Beslutet kan ses som en varningssignal för de potentiella konsekvenserna av en eftersatt och undermålig monitorering (här kan du läsa beslutet i sin helhet).
Vid en heltäckande genomgång av en organisations monitoreringsarbete får anställda möjligheten att utforska själva systemet och göra en grundlig analys av uppsatta regler, hur de faktiskt fungerar och hur de har presterat historiskt. Inte sällan leder detta till att frågor uppstår och att tidigare vedertagna sanningar om systemet börjar ifrågasättas. Varför kommer inga eller väldigt få larm på vissa regler? Varför larmar alla nya kunder? Varför larmar bara svenska kunder? Varför larmar samma kunder om och om igen?
< Fungerar verkligen reglerna i transaktionsmonitorering som vi tänkt och utgått från? >
Processer som idag är självklara fanns inte vid implementationen
Frågor likt de ovan kan användas för att identifiera problem och peka organisationer i rätt riktning mot problem som är enkla att åtgärda. Andra gånger kan svaren på frågorna indikera mer systematisk problematik. Exempelvis kan det röra sig om utmaningar som uppstått i samband med den ursprungliga implementationen av systemet, men som inte uppmärksammats och således aldrig åtgärdats.
Systembyten är ofta förknippade med stora resursbehov och kostnader. Ett system kan därför leva kvar i en organisation trots att det finns en medvetenhet om dess brister, och utan att någon omfattande genomlysning skett. Samtidigt har processer och rutiner avseende tröskelvärdessättning, testning, dokumentation och validering med största sannolikhet förändrats och är av högre kvalitet nu än vid den ursprungliga systemimplementationen.
Givet den generellt höga personalomsättning som råder inom AML-branschen är medarbetarna som ursprungligen implementerade monitoreringen och utvecklade reglerna ofta inte heller den samma. Plötsligt förefaller förekomsten av systematiska brister i övervakningen kanske vara något verksamhetsutövare borde förvänta sig – och ju snarare man åtgärdar dessa, alternativt utesluter dess relevans, desto bättre!
Tre vanliga fallgropar
I vårt arbete har vi identifierat tre vanliga misstag i övervakningen, som kan vara svåra att upptäcka utan en ordentlig genomgång av hela systemet och den data som skickas in. Vad som är positivt är att dessa inte behöver vara fel som är särskilt svåra att åtgärda, om man bara är medveten om att de finns!
För varje misstag ges en kort introduktion till problemet, ett konkret exempel, samt vad som behöver göras för att åtgärda det i praktiken.
Misstag 1: nya kunder exkluderas inte i regler som tittar på historiskt beteende
Regler som ämnar att identifiera avvikelser från kundens eget historiska beteende bör exkludera nya kunder. Att en viss grad av historisk transaktionsdata krävs för att denna typen av scenario ska ha något att jämföra kundens befintliga beteende emot kan låta som en självklarhet, men är enkelt att missa om det inte från början kravställdes och implementerades korrekt. Många system behandlar avsaknaden av kundhistorik som ett tecken på inaktivitet, vilket innebär att all typ av framtida beteende tolkas som avvikande. Innebörden blir att samtliga nya kunder larmar eftersom modellen tror att dessa ändrat beteende.
Exempel. En regel ska identifiera avvikelser på total transaktionsvolym från en kalendermånad till en annan. Detta innebär att kunden behöver ha varit kund i minst två månader för att regeln ska fungera som tänkt. Tenderar det dessutom att dröja en tid från det att kunden onboardas tills det att produkten används bör detta också beaktas, eftersom det skapar ytterligare en förskjutning av problematiken.
Lösning. Se till att startdatum för affärsförbindelsen skickas in till systemet, samt att det skickas i det format som systemet kräver. Därefter kan du antingen ändra reglerna, alternativt kravställa till leverantören att detta tas i beaktning i de regler du behöver.
Misstag 2: oavsiktlig exkludering av transaktioner som registreras i negativa belopp eller i andra valutor
Beroende på vilka produkter och transaktioner som görs, är det inte ovanligt att utgående transaktioner, returer, eller exempelvis krediter både registreras och skickas till övervakningssystem i negativa belopp. Det kan dessutom vara så att transaktioner i olika valutor inte transformeras till ett gemensamt format på förhand, utan skickas in till övervakningssystemet i sin ursprungliga valuta.
Om detta inte beaktas i de regler som utformas i monitoreringen riskerar tröskelvärdessättningen att bli helt felaktig. Följdeffekten kan bli att samtliga negativa transaktioner/kontovolymer eller transaktioner i andra valutor oavsiktligen exkluderas, alternativt att utfallet inte blir i enlighet med modellens syfte.
Exempel. En regel ska identifiera ovanligt stora transaktioner för en viss kundkategori, och tröskelvärdet sätts till större eller lika med 100 000 SEK. Om växling inte görs på förhand eller kan hanteras av systemet (vilket är ovanligt) kommer transaktioner i andra valutor inte att larma på denna regel. Likaså kommer exempelvis utgående transaktioner/krediter/returer att exkluderas om dessa registreras i negativa belopp.
Lösning: Antingen behöver indatafilen ändras, så att växling sker innan data skickas in till systemet. Alternativt behöver separata scenarier läggas till, som ser till att täcka transaktioner i negativa belopp och andra valutor. Exempelvis då lägga till ett scenario med tröskelvärdet 10 000 EUR, eller – 100 000 i utgående betalning.
Misstag 3. samma transaktion på samma kund genererar larm flera dagar i rad
Det är inte ovanligt att regler har utformats utan full förståelse för den underliggande beräkningslogiken och hur regeln fungerar i praktiken. Ofta har det att göra med att parametrarna som tittar på tidshorisont, exekvering och jämförelseperiod har en olämplig fördelning sinsemellan. Detta kan leda till att en kund som gör en ovanligt stor transaktion en dag larmar dagen för transaktionen, men också fortsätter att larma varje dag de efterföljande 10-15 dagarna, till följd av samma transaktion. Detta kan identifieras genom att titta på samtliga larm som genererats det senaste året exempelvis, och titta på fördelningen mellan kunder och larm.
Exempel. En regel ska identifiera ovanligt stora enskilda transaktioner den senaste veckan (tidshorisont) jämfört med den föregående veckan (jämförelseperiod). Exekvering har satts till dagligen, vilket leder till att samma transaktion tenderar att larma flera dagar i rad och generera falsklarm (se bild nedan för en illustration). Utöver detta, leder den korta jämförelseperioden även till att det genereras extra mycket falsklarm i slutet av varje månad. Vanligtvis är detta en konsekvens av att jämförelseperioden inte anpassats efter produkten och kundernas vanliga transaktionsmönster – ofta är det vanligt att större transaktioner görs en gång per månad efter att löneutbetalningar har skett.
Lösning. Problematiken som beskrivs och illustreras ovan kan lösas genom att se över och optimera fördelningen mellan de tre relevanta parametrarna: tidshorisont, jämförelseperiod och exekveringsfrekvens. I just det här exemplet kan problemet exempelvis lösas genom att sänka tidshorisonten till en dag, öka jämförelseperioden till en månad, samt behålla exekvering dagligen. På detta sätt elimineras problematiken med falsklarm på samma transaktioner flera dagar i rad, samt falsklarmen som alltid kommer i slutet av varje månad.
Sammanfattning – Back to Basics
Sanktionsbeslutet till LF Bank förtydligar vikten av variation i modellfloran – monitoreringen behöver täcka avvikelser från inhämtad kundkännedom, historiskt beteende, samt från en relevant jämförelsegrupp. Tröskelvärdena måste dessutom vara anpassade efter kundens riskklass och ha en tydlig koppling till den allmänna riskbedömningen.
Oavsett om denna variation finns, riskerar dock monitoreringen att vara undermålig om det finns en bristande förståelse för själva systemet, dess begränsningar, samt den data som kommer in och hur den hanteras. Se därmed till att de som arbetar med monitoreringen har både den AML-kunskap som krävs, men även förståelse för den infrastruktur som omger monitoreringen.
< En regel i ett övervakningssystem kan aldrig vara bättre än den data den använder och det system den är byggd i! >
Våra tips och rekommendationer
- Gör en ordentlig datamappning om det inte gjorts vid implementeringen
- Läs systemleverantörens handbok för övervakning och ställ frågor om det är något som är oklart
- Genereras felkoder vid dataimporten till systemleverantören? Se igenom dessa asap!
- Helena Nguyen & SannaMari Bölenius
- February 22, 2023
- 5:35 pm
SannaMari Bölenius
SannaMari är en av våra seniora AML-experter som har lång erfarenhet av arbete med hela riskhanteringskedjan - från allmän riskbedömning till KYC, transaktionsmonitorering och rapportering. Genom att ha drivit projekt på både storbanker, nischbanker och betaltjänstinstitut har hon utvecklat en djup förståelse för hur det riskbaserade förhållningssättet appliceras i praktiken.
Helena Nguyen
Helena har flerårig erfarenhet av projektledning inom AML, samt från att ha arbetat med implementation och utveckling av nya scenarier inom övervakningen. Helena har de senaste åren jobbat nischat med modellriskhantering och validering, vilket gjort att hon har djupgående kunskap även i underliggande tekniska processer som datahantering, tröskelvärdesoptimering och testning.
För mer information och kontakt:
SannaMari Bölenius
Senior Consultant, 421 AML Risk & Analytics
Tel: +46 (0)76-214 36 11
sannamari.bolenius@421.se
Max Knape
Manager, 421 AML Risk & Analytics
Tel: +46 (0)700-749759
max.knape@421.se
https://www.421.se/services/aml-risk-analytics/
Om 421 AML Risk & Analytics
421 AML Risk & Analytics är en del av 421 som är specialiserade inom AML & CTF. Vi har ett uteslutande fokus på AML-relaterade frågor inom regelefterlevnad, riskhantering, analys och verksamhetsstyrning. Vårt utpräglade AML-fokus ger oss möjlighet att erbjuda relevant och nischad expertis inom området.
Tillsammans har våra specialister gedigen erfarenhet och en heltäckande kunskap inom AML. Från tolkning av regelverk och framtagande av interna ramverk till modellutveckling och dataanalys specifikt inom AML. Vi har erfarenhet från en mängd banker och finansiella institut av varierande storlek med geografisk närvaro i Norden och Baltikum.
Vår storlek tillåter oss att erbjuda flexibla lösningar, anpassade efter varje organisations unika behov. Vi tillhandahåller AML-relaterade tjänster dels på löpande basis, dels i projekt av varierande storlek. Oavsett engagemang har vi alltid kundens behov i främsta fokus
