Compliance-bevis bör vara en biprodukt, inte ett revisionsprojekt

Ett företag kan sköta sina kundrelationer väl i flera år utan att någonsin upptäcka att det finns brister i dess compliancedokumentation. Kunder onboardas, riskbedömningar genomförs, screeningar utförs och granskningar äger rum enligt schema. Ingenting i relationen antyder att något är fel – för ingenting är heller fel. Arbetet görs genuint och samvetsgrant.

Svagheten, när den finns, tenderar att förbli osynlig tills någon ställer en specifik fråga: inte "gjorde ni rätt sak", utan "visa mig exakt vad ni gjorde, vad ni visste och varför". Den frågan kan komma från en tillsynsmyndighet, en revisor, en ny MLRO som granskar ett äldre bestånd, eller en intern granskning. Svaret beror på något som de flesta företag aldrig faktiskt har testat: om historiken för en kundrelation går att hämta fram och är sammanhängande, eller om den är utspridd bland alla de personer som råkade hantera den längs vägen.

Att utföra compliancearbetet korrekt och att kunna bevisa det flera år senare är två helt olika förmågor. Ett företag kan vara starkt på det första och svagt på det andra – och den sistnämnda svagheten bär sin egen risk, oavsett om något faktiskt har gjorts fel.

Kommersiell livscykelhantering är inte detsamma som compliance-livscykelhantering

De flesta företag hanterar den kommersiella sidan av en kundrelation via ett CRM-system, ett onboardingverktyg eller en bredare plattform för klientlivscykeln – ofta sådana som är mycket bra på det de byggdes för: att effektivt föra en potentiell kund till en aktiv, intäktsgenererande relation. Det är ingen kritik mot kategorin som sådan; det speglar vad dessa system var utformade för att optimera, och det reglerade bevisunderlaget var kanske inte det primära designmålet.

Som ett resultat sker compliancearbete ofta vid sidan av det kommersiella flödet snarare än inuti det: en bolagsregistersökning här, en sanktions- och PEP-screening där, ett kalkylblad med utestående punkter, en skärmdump som kanske spelar roll senare, ett dokument i SharePoint, ett övervägande förklarat på det ställe som verkade mest naturligt just då.

En samvetsgrann person kan få detta att fungera, men resultatet är i hög grad beroende av den personens egna arkiveringsrutiner – och av att ingen annan någonsin behöver rekonstruera det utan dennes medverkan. Den personen tar ledigt, byter roll eller slutar; någon annan tar över med andra vanor och en annan uppfattning om vad som var viktigt. Ingenting av detta syns kommersiellt – relationen fortsätter utan avbrott. Det blir synligt först när någon måste rekonstruera vad som hände, och finner att historien lever i ett flertal personers huvuden och mappar snarare än i ett sammanhängande underlag.

Den verkliga revisionsfrågan är inte "vad vet ni idag"

Föreställ dig att en revisor slumpmässigt väljer ut en enskild kundrelation, flera år efter onboarding, och ber företaget rekonstruera den i sin helhet.

Beroende på tillämpligt regelverk och kund kan företaget behöva visa: vem kunden var och relevanta bolagsuppgifter; jurisdiktion och affärsverksamhet; ägar- och kontrollstruktur, inklusive ägarkedja där en sådan finns; identifierade verkliga huvudmän; geografiska och övriga riskfaktorer som beaktades; genomförd screening och dess resultat; inhämtad dokumentation; vad som faktiskt var känt när riskbedömningen genomfördes; den resulterande klassificeringen och varför den var lämplig vid den tidpunkten; vem som fattade beslutet, och när; varför företaget godtog, avböjde eller vidhöll relationen; vad som förändrades efteråt; om det utlöste ytterligare granskning; vad som gjordes, av vem; och det slutliga utfallet.

Detta är ingen universell checklista som tillämpas identiskt överallt – kraven varierar beroende på regelverk och kundtyp. Den underliggande principen är konsekvent: företaget måste kunna styrka beslutet i den kontext det faktiskt fattades, inte rekonstruera en trovärdig version av det i efterhand. EU:s förordning om bekämpning av penningtvätt (förordning (EU) 2024/1624, "AMLR"), som är direkt tillämplig från och med den 10 juli 2027, gör detta explicit. Artikel 20 kräver att ansvariga enheter vid varje tidpunkt ska kunna visa sina tillsynsmyndigheter att de vidtagna åtgärderna för kundkännedom är lämpliga med hänsyn till de identifierade riskerna – inte bara att en åtgärd vidtogs, utan att dess ändamålsenlighet kan påvisas. Artikel 21(3) går längre: den kräver att ansvariga enheter ska föra register över de åtgärder som vidtagits för att uppfylla kraven på kundkännedom, inklusive de beslut som fattats, relevanta styrkande handlingar och motiveringar till dessa. Den kräver också att handlingar, uppgifter och information som innehas av den ansvariga enheten uppdateras när kundkännedom granskas enligt artikel 26. Compliancebevis är, enligt denna tolkning, inte bara de underliggande fakta – det är besluten och resonemanget bakom dem, bevarade tillsammans med dessa fakta.

Ett aktuellt register är inte ett historiskt register

Ett av de mer konsekvensrika misstag ett compliancesystem kan begå är tyst och lätt att förbise: att skriva över gårdagens information med dagens.

Antag att ett bolagskunds ägarstruktur förändras. Om systemet helt enkelt ersätter den gamla strukturen med den nya, kommer det att korrekt tala om för företaget vem som äger kunden idag. Det kommer däremot inte att kunna visa en revisor, om två år, varför den bedömning som gjordes vid onboarding var rimlig med hänsyn till vad som då var känt – eftersom det tidigare tillståndet inte längre existerar i sin ursprungliga form.

Detta sträcker sig längre än kunddata: den regulatoriska miljön förändras i sig, i takt med att riskfaktorer utvecklas, vägledning uppdateras och ett företags egna metodik och riskaptit mognar. Poängen är inte att varje historisk regel måste reproduceras i varje ärende – bara att bevismaterialet kring ett historiskt beslut måste bevara tillräckligt av sitt ursprungliga sammanhang för att kunna förstås på sina egna villkor, snarare än att bedömas mot information som ännu inte existerade. Artikel 26 i AMLR kräver löpande övervakning: ansvariga enheter måste hålla kundinformation uppdaterad på riskkänslig basis och specifikt granska den när kundens relevanta omständigheter förändras eller företaget får kännedom om ett relevant faktum. Förordningen föreskriver inte i sig hur denna historik ska bevaras. Ur ett operativt och bevismässigt perspektiv är det dock ett system som behåller det tidigare tillståndet vid sidan av det nya – i stället för att ersätta det – som i praktiken gör det möjligt att visa vad som förändrades och varför den vidtagna åtgärden var lämplig.

Bevisunderlaget bör följa relationens hjärtslag

Den rätta mentala modellen är inte ett enda dokument som skapas vid onboarding och sedan tyst underhålls. Den liknar mer en kronologisk serie ögonblicksbilder tagna vid varje meningsfullt tillfälle: den tillgängliga informationen, bevismaterialet bakom den, vad som förändrades, vad det krävde, vem som bedömde det, och vad som beslutades, och när. Ny information ska läggas till i denna historik, inte skriva över den.

På IQON ser vi detta som klientrelationens hjärtslag – från start, genom onboarding, varje efterföljande förändring, granskning och beslut, till relationens eventuella slut, där varje betydande händelse lägger till ytterligare ett slag i registret. Metaforen spelar mindre roll än det krav den fångar: vid varje punkt i relationens liv ska företaget kunna se hur det såg ut då, och vad som hände därefter.

Ta ett konkret fall. En bolagskund genomgår en väsentlig ägarförändring och en ny verklig huvudman dyker upp i en annan jurisdiktion. Beroende på omständigheterna kan detta, men behöver inte, utlösa förstärkt kundkännedom – ett riskbaserat övervägande, inte en automatisk regel. Vad registret behöver visa är inte bara den nya strukturen, utan att förändringen inträffade, vad som förändrades, vad som övervägdes, vilka ytterligare kontroller som krävdes, vem som granskade ärendet, och vad som beslutades, och när. En reglerad relation förändras, och förändring kan skapa en skyldighet; ett bra system hjälper till att identifiera den, säkerställer att rätt arbetsflöde följer och bevarar vad som hände – i stället för att bara presentera det aktuella tillståndet som om det vore det enda som någonsin existerat.

Tekniken ska ta bort dokumentationsarbetet, inte omdömet

För en bolagskund kan mycket av den relevanta faktamiljön – bolagsinformation, jurisdiktion, bransch, ägande och ägarkedjor, verkligt huvudmannaskap, screening, relevanta riskfaktorer, styrkande dokumentation och hur allt detta förändras över tid – sammanställas och underhållas systematiskt. En compliancespecialist ska inte behöva manuellt återskapa ett spår av revisionsinformation för information som systemet redan innehar. Teknikens uppgift är att samla in, strukturera, bevara, övervaka, lyfta fram, sammanfatta, samordna och tidsstämpla; människans uppgift är det omdöme som fakta ger underlag för.

IQON håller för närvarande på att lansera AI-stödd funktionalitet som sammanfattar det bevisunderlag som samlats in vid riskklassificering – inte för att avgöra om en kund ska godtas, utan för att hantera ett utpräglat mänskligt, administrativt problem. En kundakt kan snabbt ackumulera en stor mängd information, och att sammanställa den till något som en beslutsfattare faktiskt kan ta till sig tar tid och riskerar att något relevant förbises. AI:n hjälper till att sammanställa och summera denna information och lyfta relevanta punkter till beslutsfattarens uppmärksamhet, vilket bidrar till att minska den risken – den garanterar inte att ingenting någonsin förbises. Sammanfattningen är ett underlag för beslutet, inte beslutet i sig; den ansvariga personen granskar den och beslutar, och registret bevarar vad som var tillgängligt, vad som presenterades, vad som beslutades och, där det är lämpligt, varför.

Detta är väl förenligt med var AMLR drar gränsen. Artikel 76(5) tillåter automatiserade processer, inklusive profilering och AI-system, över uppgifter som inhämtats genom kundkännedom – men varje beslut om att inleda, avböja, vidmakthålla eller justera den kundkännedom som tillämpas på en relation kräver ett meningsfullt mänskligt ingripande, och kunden har rätt till en förklaring och att ifrågasätta det. Artikel 18 behandlar den parallella frågan om utkontraktering: den tillåter ansvariga enheter att delegera AML/CFT-uppgifter till tjänsteleverantörer, inklusive teknikföretag, men den ansvariga enheten är fortsatt fullt ansvarig för allt som görs eller lämnas ogjort i samband med det utlokaliserade arbetet, och vissa beslut – däribland kundens riskprofil och beslutet att inleda relationen – kan i allmänhet inte överlämnas till tredje part, om inte förordningens egna specifika undantag är tillämpliga. Lästa tillsammans pekar de två bestämmelserna åt samma håll: en betydande del av AML-arbetet, administration och specialistverksamhet kan delegeras eller teknikstödjas, men ansvaret för de beslut som regelverket tilldelar den ansvariga enheten följer inte med.

Revisionsbarheten måste överleva de personer som skapade ärendet

Det djupare problemet med manuell dokumentation är inte att ett dokument kan gå förlorat. Det är att det exakta tillståndet och sammanhanget för information är svårt att bevara när det beror på en persons sätt att kopiera, ta skärmdumpar, sammanfatta och arkivera – vilket bara fungerar så länge den personen kan svara på frågor om ärendet.

När en revisor ställer sin fråga kan den person som samlade in informationen ha lämnat organisationen, och det kan den som fattade beslutet också ha gjort; den som hanterar revisionen kanske aldrig ens visste att relationen existerade. Ett användbart test för varje bevissystem är om någon utan förkunskaper om relationen skulle kunna hämta fram och förstå dess fullständiga compliancehistorik flera år senare – utan att vara beroende av någons minne, befattning eller kännedom om hur ärendet var organiserat.

Dashcam-problemet

Föreställ dig att någon kör in i din bil. Du kan vara helt övertygad om att du körde korrekt, men det är ändå en avgörande skillnad mellan att säga "det var vad som hände" och att lägga fram samtida bevis på vad som hände. En dashcam gör dig inte till en bättre förare, och den fattar inte beslutet åt dig. Den ger dig ett oberoende, tidsstämplat underlag som kan påvisa vad som inträffade, på begäran, inför någon som inte var på plats.

Compliancebevis fyller samma funktion. Ett företag kan ha agerat helt korrekt under hela en relation, men om det flera år senare inte kan visa vad det visste, vad det övervägde, vad det beslutade och vad som hände efteråt, är dess förmåga att försvara sin ståndpunkt långt svagare än kvaliteten på det underliggande arbetet förtjänar. Risken är inte bara att ett företag har gjort något fel; det är att det har gjort allt rätt men inte längre kan bevisa det – och under ett regelverk som AMLR:s har det ett pris. Artikel 77 kräver att underliggande kundkännedomsdokumentation och transaktionsregister bevaras, i allmänhet i fem år efter relationens slut; där ett företag behåller referenser snarare än kopior tillåter förordningen detta endast om informationen fortfarande kan tillhandahållas omedelbart till en behörig myndighet och inte kan ändras eller manipuleras. Ett register som tekniskt sett finns någonstans är av begränsat värde om det inte går att hitta, i sitt ursprungliga skick, och lämnas ut på begäran. Artikel 78 tillför en relaterad men snävare skyldighet: företag måste ha system som kan besvara en behörig myndighets förfrågan fullständigt och skyndsamt om huruvida de har, eller har haft, en relation med en angiven person, och vad den bestod av.

Bygg upp bevisunderlaget medan relationen pågår

IQON byggdes med utgångspunkt i den reglerade relationen, inte det kommersiella flödet, med revisionsbarhet behandlad som en del av arkitekturen snarare än något som adderas i efterhand. Avsikten är inte att trycka in compliancespecialister i ett separat system medan alla andra arbetar i det kommersiella – det är att stödja klientlivscykelflödet på ett sätt som ger upphov till compliancebevis som en naturlig följd av det arbete som utförs, snarare än som en separat övning ovanpå det. IQON är inte utformat för att hjälpa ett företag att rekonstruera sitt revisionsunderlag i efterhand; det är utformat så att revisionsunderlaget redan existerar, eftersom plattformen fångar de tidsbundna fakta, besluten och skälen bakom dem i realtid och bevarar historiken i stället för att skriva över den. God revisionsbarhet bör vara en följd av att arbetet utförs väl – inte ytterligare ett arbetsmoment som konkurrerar om samma complianceteams tid.

Ett complianceteam ska inte behöva ta reda på om dess bevisunderlag håller när revisorn dyker upp. Då kan besluten vara flera år gamla, de underliggande fakta kan ha förändrats och de personer som fattade dem kanske inte längre finns kvar för att förklara sitt resonemang. Bevisunderlaget ska redan finnas, eftersom det skapades som en del av att driva relationen. Om ett företag måste rekonstruera sitt compliancebevis innan det kan klara en revision, har bevissystemet redan misslyckats.