Behörigheter och loggning i finanssystem: så uppfyller ni kraven

Det här tittar tillsynen på – och därför är behörigheter och loggning en compliance-fråga

Finansinspektionens webbplats tar bland annat upp cybersäkerhetshot från avancerad AI och nya nationella rekommendationer. FI har dessutom startat en kartläggning av hur finansiella företag använder AI och hanterar teknikens möjligheter, risker och utmaningar (publicerat 2026-09-03). FI driver också forumet Nationell riskbedömning av penningtvätt och finansiering av terrorism, där myndigheten redogör för identifierade risker och prioriterade risker i penningtvättstillsynen under året.

Vilka regelverk ni omfattas av beror på verksamhetstypen. En svensk leverantör av granskningsinfrastruktur uppger att lösningen riktar sig till banker, försäkringsbolag, värdepappersinstitut, kryptotjänsteleverantörer och deras kritiska ICT-leverantörer, och att den ska täcka krav från bland annat Finansinspektionen, EBA och ESMA. Oavsett leverantör är första steget detsamma: identifiera vilka av FI:s föreskrifter (FFFS) som gäller er, eftersom de publiceras i FI:s egen FFFS-samling och är den text tillsynen utgår från. Utgå från verksamhetstypen i inventeringen, inte från vilka system ni råkar ha.

Tillsynen får ekonomiska konsekvenser. I september 2026 beslutade FI om en anmärkning och en sanktionsavgift på 2 miljoner kronor mot AIFM Capital AB. FI avslutar samtidigt undersökningar löpande – under 2026 bland annat undersökningar av MedMera Banks och Ica Bankens kreditprövningar. Vid en sådan granskning behöver ni kunna visa två saker: en aktuell behörighetsmatris och en logg som visar faktisk användning. Saknas någon av dem tvingas ni rekonstruera händelseförlopp i efterhand, vilket tar tid och lämnar utrymme för tolkning.

Statistik från tillsynsbeslut och rekommendationer (2026)

• Förslag om invändningsrätt i RP 49/2026 — Godkänt av riksdagen

Roller, attestflöden och minsta nödvändiga åtkomst

Börja med en funktionskartläggning, inte en systemlista. Beskriv arbetsuppgifterna i kedjan från ansökan eller transaktion till beslut och bokföring: handläggare som registrerar och bereder, attestant eller beslutsfattare som godkänner, systemförvaltare som konfigurerar regler och behörigheter, och externa parter som leverantörer, konsulter eller samarbetspartner. Gå sedan till varje system och översätt varje funktion till de behörigheter den kräver. Resultatet är en matris med funktion i raderna och system/behörighetsnivåer i kolumnerna, där varje cell antingen är motiverad av en arbetsuppgift eller tas bort.

Dela upp behörigheter i nivåer som motsvarar vad någon faktiskt behöver göra: läsrättighet till uppgifter, rätt att registrera, rätt att attestera eller besluta, rätt att ändra regler och parametrar samt rätt att administrera behörigheter. Separera särskilt den som registrerar ett ärende från den som attesterar det – ingen ska kunna både lägga in och godkänna samma transaktion eller samma kreditbeslut. Behörigheten att ändra i behörighetssystemet ska ligga hos en liten, namngiven grupp och loggas separat.

Hantera undantagen lika strukturerat som grundfallen. Tillfällig förhöjd åtkomst (till exempel felsökning i produktion) ska vara tidsbegränsad, knuten till ett ärendenummer och avslutas automatiskt när tiden går ut. Externa leverantörers åtkomst ska ske via namngivna konton, aldrig via delade inloggningar, och kopplas till ett uppdrag med start- och slutdatum. Vid rollbyte eller avslut ska den gamla behörigheten stängas samma dag som ändringen registreras i HR-systemet – annars ligger kvarvarande åtkomst kvar och syns först vid nästa genomgång.

Samma ärende ska ge samma utfall – oavsett vem som handlägger

Beslutskonsistens innebär att lika ärenden behandlas lika. Tekniskt bygger det på att beslutsregler – tröskelvärden, kontrollpunkter och vilka uppgifter som måste finnas på plats – ligger i systemet i stället för i den enskilde handläggarens huvud. En svensk leverantör beskriver sitt granskningslager som en plattform för beslutskonsistens, med formuleringen att samma ärende ska ge samma utfall. Oavsett om ni bygger eller köper funktionen är principen densamma: reglerna ska vara dokumenterade, versionerade och kopplade till den behörighet som krävs för att ändra dem.

Behörighetsstyrningen och granskningslagret hänger ihop i två led. Först ser behörighetsmodellen till att bara rätt roll kan fatta eller ändra ett beslut. Sedan jämför granskningslagret det fattade beslutet mot vad reglerna förutsåg för den ärendetypen och flaggar avvikelser. Det gör att ni kan svara på om avvikelsen beror på att regeln var fel, att underlaget var ofullständigt eller att någon agerat utanför sin behörighet – tre olika orsaker som kräver tre olika åtgärder.

För att detta ska fungera i praktiken behöver varje beslut bära med sig spårbara fakta: vilken regelversion som tillämpades, vilket underlag som låg till grund, vem som fattade beslutet och vem som attesterade. Gör återkommande stickprovskontroller där samma typ av ärende plockas ut över tid och jämförs, och logga även själva kontrollen.

Loggning när någon begär kontouppgifter eller transaktionsdata

Varje begäran om kontotransaktioner eller kontouppgifter ska lämna ett spår som går att läsa utan att läsaren känner till systemet. Loggposten bör minst innehålla: vem som begärde (namn eller systemidentitet, roll och organisation), tidpunkt (tidsstämpel med tidszon och synkroniserad klocka mellan systemen), ärende (ärendenummer eller motsvarande uppdrag samt grunden för begäran), vad som begärdes (vilka konton eller kontonummer, vilken tidsperiod och vilket urval), via vilket stöd begäran gjordes (manuell sökning i handläggningssystemet, integration, API eller automatiskt system) och vad som returnerades. Om uppgifterna fördes vidare till någon annan i handläggningen ska även det framgå.

Koppla loggen till rätten att invända. I Finland finns ett övervakningssystem för bank- och betalkonton, och i regeringens proposition RP 49/2026 rd föreslås att den som ansöker om en förmån ska kunna förbjuda att en begäran om uppgifter om kontotransaktioner görs via övervakningssystemet. Oavsett vilken rättslig grund som gäller hos er visar exemplet vilken typ av invändning ni behöver hantera: en registrerad invändning måste vara sökbar i loggen, och det måste framgå att ingen begäran gjorts i strid med den.

Bygg rutinen så att invändningen har samma status som en spärr: registrera datum, vem som begärde den, vilket konto eller vilken ärendetyp den avser och vem som beslutat att lägga in den. Lägg en kontroll som stoppar begäran i systemet om en invändning finns, och logga även blockerade försök – ett stoppat försök är bevis på att kontrollen fungerar, inte en incident. Vid uppföljning ska ni per konto kunna visa tre saker: vilka begäranden som gjorts, vilka som stoppats av en invändning och vilka invändningar som är aktiva just nu.

Från rå logg till underlag som håller vid en granskning

Skilj på händelselogg och ändringslogg. Händelseloggen svarar på vem som gjorde vad och när; ändringsloggen visar vad som ändrades, från vilket värde till vilket, och av vem. Båda behövs, men de används olika: händelseloggen för att följa ett ärende eller ett konto, ändringsloggen för att följa en regel, en parameter eller en behörighet över tid. Samla dem centralt i stället för att lämna dem kvar i respektive system, så att ni kan söka tvärs över system vid en förfrågan.

Skydda loggen mot de personer den beskriver. Loggen ska vara skrivskyddad för handläggare och systemförvaltare, och behörigheten att läsa eller exportera loggdata ska ligga hos en separat funktion, till exempel internrevision eller compliance. Tekniskt innebär det vanligen append-only-skrivning, hashning eller signering av loggposter och en separat åtkomstkontroll för loggplattformen. Gallring ska följa en dokumenterad policy som utgår från ändamålet med loggen, så att ni kan förklara både varför data sparas och varför den tas bort.

Gör underlaget begripligt innan någon begär det. Bestäm en rapportmall som kan filtreras på ärende, person, konto och tidsperiod, se till att fältnamnen är begripliga för en extern läsare och dokumentera datamodellen så att kolumnerna betyder samma sak i alla system. Testa mallen genom att plocka fram ett slumpvis valt ärende från begäran till beslut med enbart loggdata, och tidsätt övningen. Om framtagningen kräver manuellt detektivarbete mellan flera system är det den svagheten en granskning först hittar.

AI-funktioner och kritiska ICT-leverantörer i behörighetsmodellen

AI-stöd i handläggningen är en ny åtkomstväg och ska behandlas som en sådan. Ett AI-verktyg som får läsa ärendedata behöver ett eget, avgränsat konto eller en egen integration – aldrig ett delat användarkonto och aldrig åtkomst till mer data än uppgiften kräver. AI-funktionen ska inte kunna attestera eller fatta beslut; den kan föreslå, och förslaget ska granskas av en namngiven handläggare.

Logga AI-anropen som andra begäranden: vilken modell eller tjänst som anropades, vilken data som skickades in, vilken tidpunkt, inom vilket ärende och vilken utdata som kom tillbaka till handläggningen. Då kan ni i efterhand visa om ett beslut byggde på AI-stöd och på vilket underlag. Bestäm också i förväg vilka ärendetyper AI-stödet får användas i och dokumentera det i behörighetsmodellen.

Kritiska ICT-leverantörer behöver komma in i systemen på villkor ni kontrollerar. I er modell betyder det: namngivna konton per leverantör och person, åtkomst begränsad till de system och miljöer uppdraget avser, tidsbegränsning med automatiskt avslut och loggning av varje session med uppdragsreferens. Ställ avtalskrav på att leverantören lämnar ut sin egen åtkomstlogg vid begäran, och följ upp att åtkomsten faktiskt stängs när uppdraget är slut – inte bara att den planerades stängas.

Löpande uppföljning: behörighetsgenomgång, avvikelser och åtgärder

Sätt en fast kadens och en fast agenda för behörighetsgenomgången. Vid varje tillfälle: lista samtliga konton och roller per system, stäm av varje behörighet mot en aktuell person och en aktuell arbetsuppgift, stäng det som inte längre är motiverat och dokumentera vem som genomfört genomgången och när. Lägg särskild vikt vid behörigheter som inte går via den vanliga rolltilldelningen – tillfälliga konton, break-glass-åtkomst och externa användare. En genomgång utan signering är ingen genomgång; avsaknaden av dokumentation gör att ni inte kan visa att rutinen följs.

Bygg larmregler för de avvikelser som faktiskt betyder något och knyt dem till loggen: åtkomst till kontouppgifter utan kopplat ärendenummer, begäranden i strid med en registrerad invändning, ovanligt hög uttagsvolym från en enskild användare, åtkomst utanför normal arbetstid, upprepade misslyckade inloggningsförsök och åtkomst från platser eller enheter som inte använts tidigare. Varje larm ska ha en namngiven mottagare och en definierad svarstid, annars blir larmlistan bara brus.

Dokumentera varje avvikelse och brist så att den går att följa över tid: datum, vad som hände, vilket ärende eller konto det gällde, orsak, vilken åtgärd som vidtogs, ansvarig person och datum för åtgärden. För in slutsatserna i behörighetsmodellen – om en avvikelse berodde på en för bred roll ska rollen ändras, inte bara ärendet stängas. Rapportera sammanställningen till ledning och compliance med jämna mellanrum, så att ni vid tillsyn kan visa både rutinen och att den tillämpats över tid.