Även om AMLR består av ett omfattande och fastställt regelverk med omkring 90 artiklar, kommer många centrala delar att konkretiseras först genom kommande Regulatory Technical Standards (RTS:er), Implementing Technical Standards (ITS:er) och vägledningar. Även när dessa är färdiga kommer det dock att finnas betydande osäkerhet kring hur kraven ska tolkas och appliceras i en svensk kontext. Detta innebär att vi just nu befinner oss i ett mellanläge: tillräckligt mycket är känt för att börja agera men långt ifrån allt är tillräckligt tydligt för att bygga färdiga lösningar. Mot bakgrund av detta uppstår två naturliga frågor som ämnar besvaras i denna artikel.

1) Är AMLR-stressen befogad?  
2) Om ja, vad bör man fokusera på redan nu?

‍

AMLR innebär mer data men långt ifrån allt är tydligt

En central förändring med AMLR är att miniminivån på inhämtning av data höjs genom införandet av specifika datapunkter som verksamheter kommer att behöva inhämta, definiera, verifiera, lagra, uppdatera och behandla i sina processer. Det är tydligt redan nu att antalet datapunkter för fullständig kundkännedom och behovet av data i system och processer kommer att öka markant.

Exempel på data som behöver inhämtas och behandlas:

• Födelseort (födelseland i nuvarande utkast på RTS) – artikel 22  
• Medborgarskap - artikel 22
• Anställning/yrke - artikel 20 och 25
• ”Ovanliga omständigheter” – bilaga III

Eftersom det inte är färdigt hur dessa datapunkter ska definieras och appliceras i praktiken är det också svårt och riskabelt att börja implementera detta redan nu. Samtidigt innebär passivitet en risk att stå oförberedd när kraven väl konkretiseras.

‍

När AMLR-stress är befogad

När nya datapunkter introduceras innebär det att data behöver inhämtas, definieras, lagras och appliceras i relevanta processer/modeller. Eftersom vi vet att antalet datapunkter ökar markant (även om de exakta definitionerna av datapunkterna inte är helt klara), vet vi att trycket på själva processen att lägga till datapunkter kommer att öka. Detta innebär i sin tur att brister som kan härledas till själva processen för att lägga till datapunkter riskerar att amplifieras och bilda tydliga flaskhalsar så fort kraven så småningom förtydligats och det är dags för implementation, om man inte tagit tag problemen i tid.  
‍

Fyra exempel på problem som kommer att bli värre med den nya lagstiftningen:‍

1. Data som lagras på flera olika ställen (flera olika källsystem) utan tydlig 'master'

Den bästa indikatorn för huruvida detta är ett problem är hur den periodiska rapporteringen upplevs. Om det är en återkommande huvudvärk beror det ofta på fragmenterad data och det kan komma att bli ännu mer huvudvärk med flera nya datapunkter som ska definieras och hanteras av systemen under nästa år.  Frågor kommer att uppstå likt hur ska den nya datan definieras? och var ska den lagras?, vilket därmed är bra att ha tänkt igenom redan nu. ‍

‍

2. Flera olika onboardingflöden/gränssnitt eller sätt att bli kund

Heterogenitet i onboarding-flöden är något som också kommer att skapa problem, då ändringar i kundkännedomsformulär kommer att behöva göras på flera ställen samtidigt så fort kraven är färdiga. Nedan är indikatorer på heterogenitet:

• Om produkter erbjuds på flera olika marknader med olika språk
• Om flera olika distributionskanaler/tredje parter används vid onboarding
• Kundkännedomsformulären skiljer sig väsentligt åt mellan produkter  
• Produkter erbjuds genom flera olika kanaler (manuell blankett, hemsida, app t.ex.)

‍

3. Begränsad flexibilitet i formulär, processer, system och modeller

Om system för kundriskklassificering, kundkännedom och transaktionsövervakning saknar flexibilitet kommer ändringar i data snabbt att leda till efterföljande fel i processer. Nedan är indikatorer på detta:

• Nya scenarier i transaktionsövervakning eller parametrar i kundriskklassificering är beroende av att data skickas i ett specifikt format  
• Kundkännedomsformulär är inte dynamiska och lätta att förändra (t.ex. att addera nya frågor, följdfrågor beroende på olika svar eller krav på svar i ett visst format)
• Svårt att simulera vad olika förändringar i scenarier eller riskklassificering skulle få för utfall i kundstocken
• Bristande logik och ärendehantering för avvikelser i kundkännedom
• Avvikande kombinationer av svar i kundkännedomsformulär
• Avvikande svar på kundkännedomsformulär gentemot externa register
• Avvikande faktiskt beteende gentemot svar på kundkännedomsformulär

‍

4. Bristande kopplingar till externa datakällor

Om kopplingar till extern registerdata inte finns på plats finns även här en risk för uppenbara, större problem vid AMLR. Nedan är indikatorer på sådana problem:

• Kundkännedomsdata i systemen uppdateras inte vid ändringar i externa register  
• Informationen uppdateras, men inte i samma system som lagrar kundkännedomsdata från onboarding/löpande uppföljning från kund (otydligt vilken som ”gäller”?) Detta är ett vanligt problem för t.ex. verklig huvudman, det vill säga att det uppstår konflikter i data.

––––––
Ovan fyra huvud-utmaningar är exempel på vad som, enligt våra erfarenheter, oftast identifieras när man titta AMLR och försöka konkretisera vad den innebär i praktiken.  

Sammanfattningsvis, om igenkänningen är hög i beskrivningarna ovan, då är tyvärr stressen befogad. Det viktiga är dock att sätta fingret på just ert problem och lyfta det nu, så att ni har tid att åtgärda kärnproblematiken innan alla nya datapunkter i AMLR ska tryckas in i föråldrade processer som redan idag inte fungerar effektivt.
‍

Var ska man börja?

Baserat på våra erfarenheter ser vi ett antal prioriterade områden som är relevanta oavsett hur slutlig reglering kommer att se ut: ‍

Skapa en tydlig datastruktur

Säkerställ att samla kritisk KYC-data på ett ställe, definiera vad varje datapunkt innebär och se till att det finns en “single source of truth”. Säkerställ att det finns ett tydligt datum för ”senast uppdaterad kundkännedom” på alla kunder.

Förenkla och standardisera flöden

Sträva mot ett gemensamt onboardingflöde/flöde för uppdatering av kundkännedom som är dynamiskt och där frågebatteriet kan anpassa sig baserat på produkt och vad kunden svarar. Se till att det finns logik och system för ärendehantering vid avvikelser, t.ex. om svaren kunden fyller i skiljer sig åt från faktiskt beteende/externt register eller om kombinationerna av svar indikerar hög risk.

Säkerställ flexibilitet  

Ställ krav på tillräcklig flexibilitet i systemen som används och att det går att simulera utfall av ändringar på ett tydligt sätt. Exempelvis hur ändringar i kundriskklassificering slår på antalet högriskkunder och hur tröskelvärdesändringar påverkar antalet och kvaliteten på larm.

Förbättra datainhämtning

Etablera kopplingar till externa register, säkerställ att data kan uppdateras löpande och att det är tydligt i vilka fall det går att förlita sig på extern registerdata kontra när uppdateringarna behöver kontrolleras eller bedömas manuellt.

Hantera befintliga brister

Slutligen, om det redan idag finns brister i processer gentemot dagens lagkrav – åtgärda dessa. Kraven blir inte lägre med den nya lagstiftningen, utan miniminivån höjs. Ej åtgärdade brister gentemot dagens lagstiftning kommer således, nästan alltid, att vara brister även den 10 juli 2027.

‍

Sammanfattning

Det finns i nuläget ingen anledning att stressa över AMLR:s exakta datapunkter och deras slutliga definitioner. Mycket återstår att konkretisera genom RTS:er, ITS:er och vägledningar, vilket gör det för tidigt att bygga färdiga lösningar. Det finns däremot goda skäl att redan nu agera på de grundläggande brister som AMLR kommer att förstärka. Fragmenterad data, otydliga definitioner, flera onboardingflöden, oflexibla system och svaga kopplingar till externa datakällor riskerar annars att bli tydliga flaskhalsar när kraven skärps. AMLR handlar därför i nuläget mindre om att implementera varje ny detalj, och mer om att skapa rätt förutsättningar för att kunna göra det när kraven väl klarnar.

Det innebär att:

• det är för tidigt att bygga färdiga lösningar, men
• det är helt rätt tid att stärka grunden.  

De verksamheter som kommer att vara bäst förberedda är sannolikt inte de som försöker göra allt först, utan de som redan nu:

• skapar ordning i sin data
• standardiserar och förenklar sina flöden, och
• bygger tillräcklig flexibilitet i system och processer för att kunna anpassa sig när detaljerna blir tydligare.  
  ‍

Key takeaways

Stressa inte över detaljerna, de är inte färdiga än. Många krav kommer att konkretiseras genom RTS:er, ITS:er och vägledningar. ‍

Stressa över grunden. Fragmenterad data, otydliga definitioner och oflexibla system är redan idag ett problem.

‍

‍