Så kravställer ett kreditbolag IT-system och IT-tjänster i en RFP

När ett kreditbolag köper ett nytt IT-system, en SaaS-tjänst, en molntjänst eller en extern IT-tjänst räcker det inte att utvärdera funktionalitet, användarvänlighet, implementationstid och pris.

Systemet kan påverka hela kreditens livscykel – från marknadsföring, kundidentifiering och kreditprövning till kreditbeslut, utbetalning, löpande betalningar, kreditövervakning, anstånd, inkasso och avslut.

En felaktig regel, datakälla eller systemkonfiguration kan medföra att:

• en kund beviljas en kredit som kunden saknar återbetalningsförmåga för,
• en kreditvärdig kund nekas kredit,
• fel ränta eller avgift tillämpas,
• ett automatiserat beslut inte kan förklaras,
• ett betalningsflöde eller kundsaldo blir fel,
• kreditförluster upptäcks för sent,
• misstänkta transaktioner inte fångas upp,
• rapporteringen till Finansinspektionen blir ofullständig,
• kunduppgifter röjs eller används för otillåtna ändamål,
• kreditbolaget inte kan flytta verksamheten från leverantören.

RFP behöver därför behandla IT-lösningen som en del av kreditbolagets styrning, riskhantering och kontrollmiljö – inte enbart som ett tekniskt verktyg.

Vilken typ av kreditbolag avses?

Begreppet ”kreditbolag” är inte en enhetlig juridisk företagskategori. Den här artikeln utgår främst från ett svenskt kreditmarknadsbolag, det vill säga ett aktiebolag som har tillstånd att bedriva finansieringsrörelse, och som därmed är ett kreditinstitut enligt lagen om bank- och finansieringsrörelse.

Underlaget kan även användas av andra kreditgivare, men behöver då anpassas efter företagets:

• tillstånd,
• kreditprodukter,
• kundgrupper,
• distributionskanaler,
• eventuella betaltjänster,
• tillsynsmyndighet,
• användning av externa kreditförmedlare,
• användning av inkassobolag och andra externa parter.

Ett bolag som enbart lämnar vissa former av konsumentkrediter men inte är ett kreditinstitut omfattas inte automatiskt av alla regler som beskrivs i artikeln. Den rättsliga klassificeringen av verksamheten bör därför fastställas innan RFP tas fram.

IT-inköpet påverkar hela kreditprocessen

Ett kreditbolags IT-miljö består ofta av flera sammanlänkade lösningar, exempelvis:

• digital ansökningsportal,
• identifierings- och signeringstjänst,
• kreditprövningssystem,
• beslutsmotor,
• kreditupplysnings- och datatjänster,
• bedrägeri- och identitetskontroller,
• kund- och avtalsregister,
• låneadministrationssystem,
• betalningsplattform,
• reskontra och ekonomisystem,
• system för kreditrisk och portföljövervakning,
• rapporteringslösningar,
• kundservice- och ärendehanteringssystem,
• krav- och inkassosystem,
• data warehouse och analysplattform,
• AI- och modellplattformar.

En RFP behöver därför inte bara beskriva den nya lösningen. Den måste också klargöra hur lösningen samverkar med övriga system, datakällor, kontroller och externa leverantörer.

Inköp, kreditverksamheten, IT, informationssäkerhet, riskkontroll, compliance, juridik, dataskydd, ekonomi, penningtvättsfunktionen och kontinuitetsansvariga behöver normalt delta i kravställningen. För konsumentkrediter bör även de funktioner som ansvarar för kundskydd, klagomål, marknadsföring och kravhantering involveras.

Vilka regelverk påverkar kreditbolagets IT-upphandling?

DORA – huvudregelverket för externa IKT-tjänster

DORA började tillämpas den 17 januari 2025 och gäller bland annat för kreditinstitut. Regelverket omfattar IKT-riskhantering, incidentrapportering, tester av digital operativ motståndskraft och risker kopplade till externa IKT-leverantörer.

DORA kan bli relevant vid köp av exempelvis:

• kreditprövningssystem,
• beslutsmotorer,
• låneadministrationssystem,
• betallösningar,
• moln- och hostingtjänster,
• data- och analystjänster,
• kreditupplysningstjänster,
• IT-drift och systemförvaltning,
• säkerhets- och övervakningstjänster,
• kundportaler och mobilappar,
• integrationstjänster,
• AI- och modellplattformar.

Kreditbolaget ska bedöma om IKT-tjänsten stödjer en kritisk eller viktig funktion. Före avtal behöver bolaget bland annat bedöma relevanta risker, informationssäkerhet, leverantörskoncentration, utbytbarhet, underleverantörskedja, tredjelandsrisk och förutsättningarna för exit.

DORA kräver också att kreditbolaget upprätthåller ett informationsregister över sina avtalsarrangemang med externa IKT-leverantörer. Avtalen ska dokumenteras och delas upp utifrån om de stödjer kritiska eller viktiga funktioner.

RFP bör därför kräva att leverantören lämnar och löpande uppdaterar information om bland annat:

• avtalspart och berörda juridiska enheter,
• tjänstens innehåll,
• leverans- och datalagringsplatser,
• funktioner som tjänsten stödjer,
• underleverantörer,
• uppsägnings- och förlängningsdatum,
• revisions- och kontrollrättigheter,
• incident- och kontinuitetsarrangemang.

DORA innehåller även konkreta krav på avtalsinnehållet. Avtalet ska bland annat innehålla en tydlig beskrivning av tjänsten, regler om datalagringsplatser, dataskydd, incidentstöd, återlämning av data, samarbete med myndigheter och uppsägningsrättigheter. För tjänster som stödjer kritiska eller viktiga funktioner tillkommer skärpta krav på bland annat SLA, kontinuitet, tester, revision och exit.

Lagen om bank- och finansieringsrörelse

Ett kreditmarknadsbolag ska ha en verksamhet som bedrivs på ett sunt sätt och med en styrning och kontroll som är anpassad efter verksamhetens risker.

IT-upphandlingen behöver därför utformas så att kreditbolaget behåller kontroll över:

• kreditbeslut,
• riskaptit och kreditpolicy,
• kunddata,
• behörigheter,
• modeller och regler,
• rapportering,
• leverantörens förändringar,
• underleverantörskedjan,
• kontinuitet och återställning,
• möjligheten att ingripa när fel uppstår.

Lagen innehåller också en särskild tystnadsplikt: enskildas förhållanden till kreditinstitut får inte obehörigen röjas. Detta påverkar bland annat leverantörens personal, supportåtkomst, loggning, testdata, datalagring och användning av underleverantörer.

RFP bör därför behandla banksekretess och konfidentialitet som ett eget kravområde och inte enbart som en allmän sekretessklausul.

Finansinspektionens regler om styrning, riskhantering och kontroll

Finansinspektionens föreskrifter FFFS 2014:1 reglerar bland annat styrning, riskhantering, kontrollfunktioner och interna regler i kreditinstitut.

Genom ändringarna i FFFS 2026:15, som började gälla den 1 juli 2026, ska riskkontrollfunktionen bland annat utvärdera riskerna innan företaget beslutar om nya eller väsentligt förändrade produkter, tjänster, marknader, processer och IT-system samt bedöma påverkan på företagets samlade risk.

Det innebär i praktiken att ett större IT-inköp inte bör gå direkt från kravspecifikation till leverantörsval. RFP-processen behöver innehålla en dokumenterad riskbedömning där den oberoende riskkontrollfunktionen får tillräcklig information för att bedöma bland annat:

• kreditrisk,
• operativ risk,
• IKT-risk,
• modellrisk,
• bedrägeririsk,
• regelefterlevnadsrisk,
• dataskyddsrisk,
• leverantörs- och koncentrationsrisk,
• konsekvenser för kapital och rapportering.

Reglerna om kreditriskhantering

FFFS 2018:16 innehåller regler och allmänna råd om kreditriskhantering i kreditinstitut och värdepappersbolag. Finansinspektionen anger att bestämmelserna om kreditprövning och kreditbeslut gäller för krediter till andra kredittagare än konsumenter samt för bostadskrediter till konsumenter.

Regelverket påverkar hur kreditbolaget bör kravställa systemstöd för bland annat:

• kreditpolicy och kreditstrategi,
• kreditprövning,
• kreditbeslut och beslutsmandat,
• dokumentation,
• säkerheter,
• löpande kreditövervakning,
• problemkrediter,
• kreditriskrapportering,
• oberoende kontroll.

Ändringarna som började gälla den 1 juli 2026 innebär bland annat att styrelsen minst vartannat år ska utvärdera och fastställa att delegeringsbestämmelserna för kreditbeslut är ändamålsenliga. Systemet behöver därför kunna visa vilka mandat som gäller, vem som har fattat ett beslut och vilka regler som tillämpades vid beslutstillfället.

Konsumentkreditlagen – särskilda krav för konsumentaffären

För kreditbolag som lämnar konsumentkrediter är 2026 ett övergångsår.

Den nya konsumentkreditlagen, lag 2026:1011, träder i kraft den 20 november 2026. Samtidigt upphävs konsumentkreditlagen från 2010. Äldre avtal omfattas i flera delar fortsatt av den upphävda lagen, vilket innebär att systemen kan behöva hantera olika regelversioner parallellt.

Den nya lagen ställer bland annat krav på att kreditprövningen ska vara grundlig, göras i konsumentens intresse och baseras på uppgifter om konsumentens inkomster, utgifter, skulder och andra nödvändiga och proportionerliga ekonomiska förhållanden. Uppgifterna ska kontrolleras på ett lämpligt sätt.

RFP behöver därför säkerställa att systemet kan:

• inhämta relevanta ekonomiska uppgifter,
• dokumentera uppgifternas källa,
• kontrollera uppgifternas aktualitet,
• registrera hur uppgifterna har verifierats,
• hantera gemensamma kreditåtaganden,
• genomföra ny kreditprövning vid väsentlig kreditökning,
• skilja mellan olika kreditprodukter och risknivåer,
• bevara det beslutsunderlag som gällde när beslutet fattades.

Den nya lagen innehåller även särskilda regler om automatiserad behandling. Om kreditprövningen innefattar automatiserad behandling ska konsumenten på begäran kunna få kreditprövningen granskad med mänsklig medverkan, få en förklaring av prövningen och få information om riskerna med den automatiserade behandlingen. Även automatiserat personanpassade krediterbjudanden och priser medför särskilda informationskrav.

Kreditbolaget behöver därför kunna förklara mer än att ”systemet gav avslag”. Det bör gå att visa:

• vilka uppgifter som användes,
• vilka regler eller modeller som påverkade beslutet,
• om information kom från en extern databas,
• vilka centrala faktorer som ledde till resultatet,
• hur en mänsklig omprövning genomförs,
• vem som är behörig att ändra beslutet,
• hur omprövningen dokumenteras.

Finansinspektionen publicerade den 20 maj 2026 ett remissförslag till nya föreskrifter och allmänna råd om konsumentkrediter. Förslaget förtydligar bland annat vilka uppgifter som bör ingå i kreditprövningen och hur de bör samlas in och kontrolleras. De föreslagna ändringarna var avsedda att börja gälla den 20 november 2026. Eftersom underlaget var ett remissförslag vid artikelns uppdatering behöver slutlig lydelse kontrolleras innan RFP publiceras eller avtalet tecknas.

GDPR och automatiserade beslut

Kreditprövning innebär ofta profilering och omfattande behandling av personuppgifter.

GDPR påverkar bland annat:

• vilka uppgifter som får behandlas,
• rättslig grund,
• information till den registrerade,
• automatiserade individuella beslut,
• dataminimering,
• lagrings- och gallringstider,
• personuppgiftsbiträden,
• underbiträden,
• tredjelandsöverföringar,
• säkerhetsåtgärder,
• registrerades rättigheter,
• konsekvensbedömningar.

IMY lyfter uttryckligen fram automatiserade kreditbeslut som ett område där den registrerade kan ha rätt att få information, bestrida beslutet och få det granskat av en människa.

RFP bör därför kräva att systemet kan:

• identifiera vilka beslut som fattats helt automatiserat,
• skilja automatiska beslut från beslutsstöd,
• dokumentera logiken bakom beslutet,
• hantera begäran om mänsklig omprövning,
• rätta felaktiga uppgifter,
• återskapa den data- och modellversion som användes,
• exportera relevant information till kundservice och dataskyddsfunktionen,
• begränsa användningen av personuppgifter till avtalade ändamål.

AI-förordningen – kreditvärdering är ett särskilt riskområde

AI-system som används för att bedöma fysiska personers kreditvärdighet eller fastställa deras kreditpoäng är klassificerade som högrisk-AI enligt AI-förordningens bilaga III. Undantag görs för AI-system som används för att upptäcka finansiella bedrägerier.

AI-förordningen började i huvudsak tillämpas den 2 augusti 2026. Efter den ändring som framgår av den konsoliderade lydelsen börjar de särskilda kraven i kapitel III avsnitt 1–3 för högrisksystem enligt bilaga III tillämpas den 2 december 2027.

Ett kreditbolag bör därför redan i RFP kräva att leverantören redovisar:

• om lösningen innehåller AI,
• AI-systemets avsedda användning,
• om det används för kreditvärdighet eller kreditpoäng,
• modellägare och ansvarsfördelning,
• använda datakategorier,
• tränings-, validerings- och testdata,
• modellversioner,
• datakvalitet,
• noggrannhet och felmarginaler,
• mänsklig kontroll,
• loggning och spårbarhet,
• robusthet och cybersäkerhet,
• förändringshantering,
• hantering av diskriminerande eller osakliga utfall,
• stöd till kreditbolagets dokumentation och tillsyn.

Leverantören bör inte få beskriva lösningen som en ”svart låda” och samtidigt förvänta sig att kreditbolaget ska bära hela den regulatoriska risken.

Penningtvätt och finansiering av terrorism

Kreditinstitut omfattas av penningtvättslagen. Verksamhetsutövaren ska bland annat göra en allmän riskbedömning som tar hänsyn till produkter, tjänster, kunder, distributionskanaler och geografiska riskfaktorer.

Systemet kan behöva stödja:

• identifiering och verifiering av kund,
• kontroll av verklig huvudman,
• PEP- och sanktionskontroller,
• kundriskklassificering,
• dokumentation av affärsförbindelsens syfte och art,
• löpande kundkännedom,
• transaktionsövervakning,
• avvikelse- och varningshantering,
• utredning av misstänkta aktiviteter,
• sekretess kring rapportering,
• bevarande av dokumentation.

Kundkännedom ska normalt genomföras när en affärsförbindelse etableras, och kundens identitet ska kontrolleras genom en oberoende och tillförlitlig källa. Kundriskprofilen och kundkännedomen ska därefter följas upp under den pågående affärsförbindelsen.

RFP bör tydligt skilja mellan:

• kundidentifiering,
• kreditprövning,
• bedrägerikontroll,
• penningtvättskontroll,
• sanktionskontroll.

Kontrollerna kan använda samma uppgifter men har olika syften, rättsliga grunder, beslutsregler och dokumentationskrav.

Kreditupplysningar

När kreditupplysningar inhämtas och används behöver kreditbolaget beakta kreditupplysningslagen och GDPR. Kreditupplysningslagen innehåller regler om bland annat integritet, legitimt behov, registerinnehåll, rättelse och information till den som upplysningen avser.

RFP bör kräva att systemet kan dokumentera:

• vilken kreditupplysningsleverantör som användes,
• när upplysningen hämtades,
• vilken typ av upplysning som hämtades,
• vilket legitimt behov som förelåg,
• vilken version av upplysningen som användes,
• hur uppgiften påverkade beslutet,
• hur rättade uppgifter hanteras,
• hur information lämnas till kunden när det krävs.

Kravhantering och inkasso

När lösningen omfattar påminnelser, kravhantering eller inkasso behöver inkassolagens regler och god inkassosed beaktas. Inkassolagen innehåller bland annat krav på att inkassoverksamhet ska bedrivas enligt god inkassosed och att ett inkassokrav ska innehålla tydliga uppgifter om fordran.

Systemet behöver exempelvis kunna hantera:

• förfallodagar,
• påminnelser,
• ränta och avgifter,
• amorteringsplaner,
• anstånd och uppgörelser,
• bestridanden,
• inkassokrav,
• rättelser,
• preskription,
• överföring till externt inkassobolag,
• återrapportering från inkassobolaget,
• dokumentation av kundkontakter.

Kreditbolaget bör dessutom kunna skilja mellan en kund som inte vill betala och en kund som har betalningssvårigheter och kan behöva en alternativ lösning.

Betaltjänster

Om kreditbolaget själv tillhandahåller betaltjänster eller använder ett system som utför betalningar, kontoöverföringar, autogiro eller andra reglerade betalningsfunktioner kan även betaltjänstlagen bli relevant.

RFP behöver då kompletteras med krav på exempelvis:

• stark kundautentisering,
• betalningsgodkännande,
• obehöriga transaktioner,
• transaktionsloggar,
• återbetalningar,
• incidentrapportering,
• säker kommunikation,
• avstämning,
• kundinformation.

Data Act – byte av moln- och SaaS-leverantör

Data Act började tillämpas den 12 september 2025 och innehåller särskilda regler som ska underlätta byte mellan leverantörer av databehandlingstjänster. Reglerna omfattar bland annat avtalsvillkor, dataportabilitet, exportformat, tekniskt stöd och kontinuitet under leverantörsbytet.

För kreditbolaget kompletterar dessa regler DORA exitkrav.

RFP bör därför inte stanna vid att kreditbolaget ”äger sin data”. Avtalet behöver reglera hur följande faktiskt kan flyttas:

• kund- och kreditdata,
• ansökningar och beslutsunderlag,
• avtal och signaturer,
• betalningshistorik,
• kundreskontra,
• regler och konfigurationer,
• modellparametrar,
• loggar och revisionsspår,
• rapporteringshistorik,
• dokument och kundkommunikation,
• integrationer och API-specifikationer.

Från den 12 januari 2027 får leverantörer av databehandlingstjänster som huvudregel inte ta ut bytesavgifter för den reglerade bytesprocessen. Det är ändå viktigt att avtalet tydligt skiljer mellan ordinarie bytesstöd och eventuella tilläggstjänster som kunden särskilt beställer.

Klassificera tjänsten innan RFP färdigställs

En väl genomförd RFP börjar med en intern klassificering.

1. Fastställ verksamhets- och produktscope

Kreditbolaget bör dokumentera:

• vilka juridiska enheter som ska använda tjänsten,
• vilka kreditprodukter som omfattas,
• om krediter lämnas till konsumenter eller företag,
• om bostadskrediter omfattas,
• vilka länder och valutor som berörs,
• vilka distributionskanaler som används,
• om kreditförmedlare eller återförsäljare ingår,
• vilka faser i kreditens livscykel som ska stödjas.

Kraven för en intern företagskredit skiljer sig från kraven för en helt digital konsumentkredit som marknadsförs, prissätts och beslutas i realtid.

2. Genomför DORA-klassificeringen

Följande frågor bör besvaras:

1. Är det som köps en IKT-tjänst enligt DORA?
2. Vilka verksamhetsfunktioner stödjer tjänsten?
3. Är någon av funktionerna kritisk eller viktig?
4. Vilka konsekvenser får ett avbrott eller ett felaktigt resultat?
5. Vilken återställningstid och tillåten dataförlust kan verksamheten acceptera?
6. Är leverantören eller en underleverantör svår att ersätta?
7. Uppstår koncentrationsrisk till en viss moln- eller dataleverantör?
8. Var lagras, behandlas och säkerhetskopieras data?
9. Vilka uppgifter behöver samlas in till DORA informationsregister?
10. Behöver Finansinspektionen informeras om avtalet?

3. Bedöm om en verksamhetsfunktion läggs ut

En separat bedömning behöver göras av om leverantören enbart tillhandahåller tekniken eller om leverantören faktiskt utför en del av kreditbolagets verksamhet.

Det kan exempelvis handla om att leverantören:

• genomför kreditprövningen,
• fattar eller verkställer kreditbeslut,
• hanterar kundkännedom,
• administrerar krediter och kundreskontra,
• utför betalningar,
• hanterar kundservice,
• genomför portföljövervakning,
• utför krav- eller inkassohantering,
• tar fram regulatorisk rapportering.

Kreditbolaget behöver alltid behålla tillräcklig kompetens och kontroll för att kunna bedöma leveransen, ingripa vid fel och ta tillbaka eller flytta funktionen.

4. Klassificera data, beslut och modeller

Kreditbolaget bör identifiera:

• vilka personuppgifter som behandlas,
• om känsliga eller särskilt skyddsvärda uppgifter förekommer,
• vilka uppgifter som omfattas av banksekretess,
• vilka externa datakällor som används,
• om automatiserade beslut fattas,
• om profilering genomförs,
• om AI eller maskininlärning används,
• vilka modeller som påverkar kreditbeslut, pris eller limit,
• om uppgifter behandlas utanför EU eller EES,
• vilka data som måste kunna återskapas historiskt.

5. Genomför en kund- och konsekvensanalys

Riskbedömningen bör inte bara behandla tekniska avbrott.

Kreditbolaget bör också bedöma konsekvenserna av:

• felaktigt beviljad kredit,
• felaktigt avslag,
• diskriminerande utfall,
• felaktig ränta eller avgift,
• försenad utbetalning,
• felaktigt kundsaldo,
• felaktigt kravbrev,
• utebliven hantering av betalningssvårigheter,
• felaktig rapportering till kreditupplysningsföretag,
• bristande förklaring av ett automatiserat beslut,
• förlust av data eller revisionsspår.

Så bör kraven utformas i RFP

1. Tjänstens omfattning och leveransmodell

Leverantören ska beskriva hela lösningen och inte enbart visa ett användargränssnitt eller en produktpresentation.

RFP bör kräva information om:

• samtliga funktioner och moduler,
• teknisk arkitektur,
• datamodell,
• dataflöden,
• regler och beslutsmotorer,
• integrationer och API,
• produktions-, test- och återställningsmiljöer,
• drift- och supportmodell,
• ansvarsfördelning,
• underleverantörer,
• externa datakällor,
• standardfunktioner och kundanpassningar,
• tekniska och funktionella begränsningar,
• roadmap och avvecklingspolicy.

Exempel på RFP-krav:

Leverantören ska lämna en fullständig beskrivning av samtliga funktioner, tjänstekomponenter, datakällor, beslutsregler, modeller, integrationer, driftmiljöer och tekniska beroenden. Det ska framgå vilka delar som utförs av Leverantören, Kreditbolaget respektive underleverantörer.

2. Kreditprocess och produktregler

Systemet behöver kunna stödja kreditbolagets beslutade kreditpolicy och produktvillkor.

RFP bör bland annat omfatta:

• kreditprodukter,
• kundsegment,
• kreditbelopp och limiter,
• löptider,
• amorteringsmodeller,
• räntor och avgifter,
• prissättningsregler,
• kreditändamål,
• distributionskanaler,
• kreditförmedlare,
• kampanjer och personliga erbjudanden,
• produktgodkännande,
• versionshantering av regler och villkor.

Exempel på RFP-krav:

Lösningen ska säkerställa att varje kreditansökan behandlas enligt den produktversion, kreditpolicy, beslutsregel, räntemodell och avgiftsstruktur som gällde vid den aktuella tidpunkten. Historiska versioner ska bevaras och kunna återskapas.

3. Kundidentifiering och bedrägerikontroll

RFP bör ställa krav på:

• säkra identifieringsmetoder,
• elektronisk legitimering,
• kontroll av identitetsuppgifter,
• hantering av skyddade personuppgifter,
• kontroll av verklig huvudman för företagskunder,
• kontroll av dokument och signaturer,
• upptäckt av identitetsmissbruk,
• enhets- och beteendeanalys,
• dubblettkontroller,
• varningar och manuell granskning,
• dokumentation av genomförda kontroller.

Kreditbolaget bör kunna konfigurera vilka kontroller som ska genomföras för olika produkter, belopp, kanaler och risknivåer.

4. Kreditprövning och datakvalitet

Kreditprövningen måste bygga på relevant, korrekt och tillräcklig information.

RFP bör därför omfatta:

• uppgifter om inkomst,
• utgifter och levnadskostnader,
• skulder och krediter,
• boendekostnader,
• hushållssammansättning när det är relevant,
• anställning och andra inkomstkällor,
• företagsuppgifter och bokslutsdata,
• säkerheter och garantier,
• kreditupplysningar,
• interna betalningsuppgifter,
• datakällornas aktualitet,
• kontroll och verifiering,
• hantering av motstridiga uppgifter,
• hantering av saknad information,
• dokumentation av manuella justeringar.

Exempel på RFP-krav:

Lösningen ska dokumentera samtliga uppgifter som använts vid kreditprövningen, uppgifternas källa, tidpunkten för inhämtandet, genomförda kontroller och eventuella manuella justeringar. Det ska vara möjligt att återskapa det fullständiga beslutsunderlaget för en historisk kreditansökan.

5. Kreditbeslut, mandat och mänsklig omprövning

Systemet bör kunna skilja mellan:

• helautomatiskt beslut,
• automatiskt beslutsförslag,
• manuellt beslut,
• beslut som kräver två behöriga personer,
• eskalerat beslut,
• omprövning,
• undantagsbeslut.

RFP bör ställa krav på:

• rollbaserade beslutsmandat,
• belopps- och produktgränser,
• fyrögonsprincip,
• jäv- och intressekonfliktskontroller,
• dokumentation av beslutsfattare,
• beslutsskäl,
• manuella avsteg,
• tidsstämplar,
• historik över ändrade mandat,
• stöd för mänsklig omprövning,
• möjlighet att korrigera ett felaktigt beslut.

Exempel på RFP-krav:

För varje kreditbeslut ska det framgå om beslutet fattades automatiskt eller manuellt, vilka uppgifter, regler och modeller som användes, vilken person eller beslutsfunktion som var ansvarig och om något manuellt undantag gjordes.

6. Förklaringar av automatiserade beslut

Leverantören bör beskriva hur systemet möjliggör en begriplig förklaring av resultatet.

RFP bör kräva att kreditbolaget kan:

• identifiera de viktigaste faktorerna bakom beslutet,
• förklara hur felaktiga eller ändrade uppgifter påverkar resultatet,
• skilja affärsregler från modellresultat,
• genomföra mänsklig omprövning,
• dokumentera omprövningens resultat,
• lämna kundanpassad information,
• hantera information från externa databaser.

Exempel på RFP-krav:

Leverantören ska säkerställa att Kreditbolaget kan lämna en klar och begriplig förklaring av ett automatiserat kreditbeslut. En hänvisning till att beslutet har fattats av en algoritm, modell eller extern dataleverantör är inte tillräcklig.

7. Prissättning och information före avtal

För konsumentkrediter behöver systemet stödja korrekt och fullständig information före avtal.

RFP kan behöva omfatta:

• nominell och effektiv ränta,
• samtliga avgifter,
• totalt belopp att betala,
• betalningsplan,
• förutsättningar för ränteändring,
• personanpassad prissättning,
• kreditens kostnad vid olika scenarier,
• standardiserad förhandsinformation,
• giltighetstid för erbjudandet,
• språk- och kanalversioner,
• tidpunkt när informationen lämnades,
• dokumentation av kundens godkännande.

Exempel på RFP-krav:

Lösningen ska kunna visa exakt vilken förhandsinformation, prisuppgift, ränta, avgift, återbetalningsplan och avtalsversion som presenterades för kunden före avtalets ingående.

8. Avtal, signering och dokumenthantering

RFP bör ställa krav på:

• versionsstyrda avtalsmallar,
• elektronisk signering,
• bevisning om signering,
• kontroll av behörig firmatecknare,
• avtalsdatum och ikraftträdande,
• koppling mellan erbjudande och avtal,
• dokumentarkiv,
• sökbarhet,
• export och långtidsbevarande,
• rättelse och makulering,
• kundens tillgång till avtalet.

9. Utbetalning och låneadministration

Systemet bör kunna hantera:

• utbetalningsvillkor,
• kontroll före utbetalning,
• mottagarkonto,
• delutbetalningar,
• kreditlimit,
• ränta och amortering,
• betalningsplaner,
• extra amortering,
• förtidsbetalning,
• avgifter,
• dröjsmålsränta,
• ränteändringar,
• saldon och transaktioner,
• aviseringar,
• återbetalningar och korrigeringar.

Det bör gå att återskapa hur varje saldo och belopp har beräknats.

10. Löpande kreditövervakning

Kreditrisken upphör inte när krediten har betalats ut.

RFP bör omfatta stöd för:

• tidiga varningsindikatorer,
• betalningsförseningar,
• försämrad ekonomisk ställning,
• limitöverskridanden,
• covenant-överträdelser,
• ändrade kreditupplysningar,
• omklassificering av kreditrisk,
• bevakningslistor,
• portföljsegmentering,
• riskrapporter,
• eskalering och åtgärdsplaner.

11. Betalningssvårigheter, anstånd och omstrukturering

Systemet bör stödja en kontrollerad process för kunder som får betalningsproblem.

RFP kan omfatta:

• anstånd,
• tillfälligt sänkt betalning,
• förlängd löptid,
• ändrad amorteringsplan,
• frysning av avgifter,
• skuldnedskrivning,
• uppgörelser,
• omstrukturering,
• dokumentation av kundens situation,
• godkännanden,
• uppföljning av överenskomna åtgärder.

Alla ändringar ska vara spårbara och möjliga att koppla till rätt beslutsmandat.

12. Kravhantering och inkasso

RFP bör bland annat omfatta:

• påminnelseprocess,
• förfallna belopp,
• kravbrev,
• ränta och avgifter,
• kundkontakter,
• bestridanden,
• rättelser,
• avbetalningsplaner,
• överföring till inkassobolag,
• återrapportering,
• återkallelse av felaktiga ärenden,
• preskription,
• dödsbo och insolvens,
• avslut och avskrivning.

Exempel på RFP-krav:

Lösningen ska förhindra att ett bestridet, felaktigt eller pausat krav automatiskt överförs till fortsatt kravhantering eller externt inkasso utan föreskriven kontroll.

13. Säkerheter, garantier och värderingar

För säkerställda krediter bör RFP omfatta:

• typ av säkerhet,
• ägare och pantsättare,
• värdering och värderingsdatum,
• värderingskälla,
• belåningsvärde,
• prioritet,
• garantier,
• försäkringar,
• omvärdering,
• dokumentation,
• frigivning och realisation,
• bevakning av utgångsdatum och villkor.

14. Kreditrapportering, kapital och redovisning

Beroende på tjänsten kan systemet behöva stödja:

• kreditriskrapportering,
• portföljdata,
• förfallostruktur,
• nödlidande exponeringar,
• anstånd och omstrukturering,
• reserveringar och nedskrivningar,
• säkerhetsvärden,
• kapital- och riskmått,
• myndighetsrapportering,
• finansiell rapportering,
• avstämning mot huvudbok.

RFP bör kräva datalinjering från källtransaktion till rapporterat värde.

15. Informationssäkerhet och banksekretess

Informationssäkerhetskraven ska vara konkreta och verifierbara.

RFP bör omfatta:

• ledningssystem för informationssäkerhet,
• identitets- och behörighetshantering,
• multifaktorautentisering,
• privilegierade konton,
• segregation of duties,
• kryptering,
• nyckelhantering,
• loggning och övervakning,
• separation mellan kunder,
• säker utveckling,
• sårbarhetsskanning,
• penetrationstester,
• patchhantering,
• säkerhetskopiering,
• personal- och fysisk säkerhet,
• hantering av sekretessbelagda kunduppgifter.

Exempel på RFP-krav:

Leverantören ska säkerställa att uppgifter om Kreditbolagets kunder endast är tillgängliga för personer som behöver uppgifterna för att utföra avtalade arbetsuppgifter. All administrativ och privilegierad åtkomst ska vara behörighetsstyrd, tidsbegränsad och loggad.

16. Personuppgifter och datalagring

Leverantören ska redovisa hela behandlingskedjan, inte enbart var den primära databasen finns.

RFP bör omfatta:

• personuppgiftskategorier,
• kategorier av registrerade,
• behandlingsändamål,
• personuppgiftsbiträdesavtal,
• underbiträden,
• lagrings- och supportländer,
• säkerhetskopiering,
• tredjelandsöverföringar,
• gallring och radering,
• registrerades rättigheter,
• incidenthantering,
• revisionsrätt,
• användning av produktionsdata i test,
• användning av data för produktutveckling eller AI-träning.

Exempel på RFP-krav:

Kreditbolagets data, dokument, inmatningar, prompts och utdata får inte användas för Leverantörens eller tredje parts analys, produktutveckling eller modellträning utan Kreditbolagets föregående skriftliga godkännande.

17. Penningtvätt, sanktioner och bedrägeri

RFP bör tydligt definiera vilka kontroller som ingår och vem som ansvarar för dem.

Kravbilden kan omfatta:

• kundidentifiering,
• verklig huvudman,
• PEP och sanktioner,
• kundriskklassificering,
• geografiska risker,
• löpande kundkännedom,
• transaktionsövervakning,
• bedrägerisignaler,
• varningshantering,
• ärendeutredning,
• godkännande och stängning av varningar,
• rapportunderlag,
• sekretess och begränsad åtkomst,
• modell- och regeluppföljning.

Leverantören ska kunna visa skillnaden mellan en regel som upptäcker kreditrisk och en regel som upptäcker penningtvätt eller bedrägeri.

18. AI- och modellrisk

AI- och modellkraven bör behandlas som ett eget avsnitt i RFP.

Leverantören bör redovisa:

• samtliga modeller och AI-komponenter,
• modellernas användningsområden,
• modellägare,
• leverantörens och kundens roller,
• tränings- och valideringsdata,
• representativitet och datakvalitet,
• valideringsmetod,
• noggrannhet och felmått,
• stabilitet över tid,
• bias- och diskrimineringstester,
• förklarbarhet,
• mänsklig kontroll,
• modellövervakning,
• omkalibrering,
• versionshantering,
• förändringar och rollback,
• tredjepartsmodeller,
• säkerhet och manipulation.

Exempel på RFP-krav:

Ingen modell eller AI-komponent som påverkar kreditprövning, kreditbeslut, kreditlimit eller prissättning får ändras eller ersättas utan att Kreditbolaget i förväg har fått tillräcklig dokumentation för att bedöma och godkänna förändringen.

19. Incidenthantering

Kreditbolaget kan behöva rapportera eller hantera en incident innan leverantören har fastställt grundorsaken.

RFP bör därför reglera:

• vilka incidenter som ska rapporteras,
• initial rapporteringstid,
• kontaktväg och tillgänglighet,
• incidentklassificering,
• statusuppdateringar,
• bevarande av loggar och bevis,
• stöd vid DORA- och dataskyddsrapportering,
• kundpåverkan,
• rättelse av felaktiga beslut och saldon,
• rotorsaksanalys,
• åtgärdsplan,
• verifiering av genomförda åtgärder.

Exempel på RFP-krav:

Leverantören ska utan onödigt dröjsmål och senast inom avtalad tidsfrist rapportera varje faktisk eller misstänkt incident som kan påverka kreditbeslut, kunddata, betalningar, saldon, rapportering eller tjänstens tillgänglighet. Den initiala rapporteringen får inte fördröjas av att grundorsaken ännu inte är fastställd.

20. Kontinuitet och återställning

RTO och RPO bör baseras på kreditbolagets verksamhetsanalys och inte enbart på leverantörens standardnivåer.

RFP bör omfatta:

• processpecifika RTO och RPO,
• redundans,
• geografisk separation,
• säkerhetskopiering,
• återställningstester,
• reservrutiner,
• alternativa besluts- och betalningsprocesser,
• återkörning av transaktioner,
• avstämning efter avbrott,
• kapacitet vid hög belastning,
• prioritering mellan kunder,
• gemensamma kontinuitetsövningar,
• underleverantörernas kontinuitet.

21. Underleverantörer och leveranskedja

Leverantören ska redovisa vilka parter som faktiskt utför tjänsten eller får åtkomst till kreditbolagets data.

RFP bör kräva information om:

• juridiskt namn,
• registreringsland,
• utförd tjänst,
• leveransplats,
• datalagringsplats,
• supportåtkomst,
• kritikalitet,
• kontroll- och revisionsrätt,
• koncentrationsrisk,
• vidaredelegering,
• planerade förändringar.

Kreditbolaget bör ha rätt att:

• informeras i god tid,
• genomföra en ny riskbedömning,
• invända mot en väsentlig förändring,
• kräva riskreducerande åtgärder,
• säga upp berörd tjänst om risken inte kan accepteras.

22. Revision och myndighetsåtkomst

RFP bör ge kreditbolaget, dess revisorer, utsedda granskare och behöriga myndigheter tillgång till relevant:

• dokumentation,
• data,
• loggar,
• kontrollresultat,
• intervjuer,
• tekniska tester,
• lokaler,
• underleverantörer.

Certifieringar och standardiserade granskningsrapporter kan användas som en del av kontrollen men bör inte automatiskt ersätta riktade revisioner efter en allvarlig incident, väsentlig brist eller myndighetsbegäran.

Exempel på RFP-krav:

Leverantören får inte införa avtalsmässiga, tekniska eller praktiska begränsningar som gör Kreditbolagets eller behörig myndighets gransknings- och åtkomsträtt ineffektiv.

23. SLA, KPI och KRI

Ett generellt tillgänglighetsmått per månad ger sällan tillräcklig styrning.

Relevanta mätvärden kan exempelvis vara:

• systemtillgänglighet,
• svarstid i kreditprövningen,
• andel tekniskt misslyckade ansökningar,
• andel beslut som kräver manuell hantering,
• felaktiga beslut eller beräkningar,
• datakvalitetsfel,
• betalningar genomförda i tid,
• felaktiga saldon,
• incidenters svarstid och åtgärdstid,
• öppna kundklagomål,
• sårbarheter och säkerhetsuppdateringar,
• kontinuitetstester,
• öppna revisionsanmärkningar,
• förändringar av underleverantörer.

Servicekrediter bör inte vara kreditbolagets enda påföljd vid en brist som medför kundskada eller regulatorisk risk.

24. Förändrings-, release- och modellhantering

SaaS- och molntjänster förändras kontinuerligt.

RFP bör kräva förhandsinformation om förändringar av:

• funktionalitet,
• kreditregler,
• modeller,
• datakällor,
• arkitektur,
• integrationer,
• säkerhetskontroller,
• datalagringsplats,
• supportland,
• underleverantörer,
• AI-komponenter,
• produkt- och versionsstöd.

Kreditbolaget ska få tillräcklig tid och dokumentation för att genomföra en ny risk-, säkerhets- och regelefterlevnadsbedömning.

25. Dataåtkomst, dataportabilitet och exit

Exit ska planeras före avtalstecknandet.

RFP bör omfatta export av:

• kund- och kreditdata,
• ansökningar,
• beslutsunderlag,
• kreditavtal,
• betalningshistorik,
• saldon och reskontra,
• säkerheter,
• kundkontakter,
• krav- och inkassohistorik,
• regler och konfigurationer,
• modeller och modellparametrar,
• loggar och revisionsspår,
• regulatoriska rapporter,
• teknisk dokumentation.

Det bör också finnas krav på:

• strukturerade och maskinläsbara format,
• verifiering av exportens fullständighet,
• migreringsstöd,
• kunskapsöverföring,
• parallell drift,
• fortsatt servicenivå,
• stöd till ny leverantör,
• förutsebara exitkostnader,
• radering efter godkänd överföring,
• raderingsintyg,
• regelbundna exittester.

Exempel på RFP-krav:

Vid avtalets upphörande ska Leverantören tillhandahålla samtliga data, metadata, konfigurationer, regler, modeller, loggar, revisionsspår och relevant dokumentation i strukturerade och maskinläsbara format samt bistå vid en säker och kontrollerad övergång.

26. Kommersiella och avtalsmässiga krav

Samtliga kostnader och kommersiella beroenden behöver redovisas i anbudet.

Det gäller exempelvis:

• licenser och abonnemang,
• användare,
• ansökningar och krediter,
• transaktioner,
• datalagring,
• externa datakällor,
• API-anrop,
• implementation,
• support,
• regulatoriska förändringar,
• revision,
• incidentstöd,
• dataexport,
• exit.

Avtalet bör även reglera:

• ansvar och ansvarsbegränsningar,
• banksekretess och konfidentialitet,
• immateriella rättigheter,
• rätt till kundanpassningar,
• försäkringsskydd,
• regulatoriska förändringar,
• ägar- och kontrollförändringar,
• avstängningsrätt,
• uppsägningsgrunder,
• fortsatt åtkomst till data,
• avtalets prioritetsordning.

27. Implementering, migrering och acceptans

Regulatoriska och verksamhetskritiska krav ska verifieras före produktionssättning.

RFP bör kräva:

• detaljerad implementeringsplan,
• projektorganisation,
• data- och integrationsinventering,
• datamappning,
• provmigrering,
• kontrollsummeringar,
• parallell körning,
• test av kreditregler och modeller,
• test av räntor och avgifter,
• test av kreditbeslut och mandat,
• test av kundinformation och avtal,
• säkerhets- och behörighetstester,
• kontinuitets- och återställningstest,
• incident- och eskaleringstest,
• regulatoriska acceptanskriterier,
• utbildning och dokumentation,
• skriftligt godkännande före produktionssättning.

Exempel på RFP-krav:

Produktionssättning får ske först efter Kreditbolagets skriftliga godkännande av funktionella, tekniska, regulatoriska, säkerhetsmässiga och operativa acceptanskriterier samt godkänd migrering och avstämning.

Kräv strukturerade leverantörssvar

Leverantören bör inte få besvara regulatoriska eller säkerhetsmässiga krav med ett enkelt ja.

För varje krav bör leverantören ange:

1. Om kravet uppfylls fullt ut, delvis eller inte alls.
2. Hur kravet uppfylls.
3. Vilken dokumentation som verifierar svaret.
4. Vilken funktion eller modul som används.
5. Vilka förutsättningar och kundåtgärder som finns.
6. Var åtagandet regleras i avtalet.
7. Om kravet medför extra kostnad.
8. Om utveckling eller anpassning krävs.
9. Samtliga reservationer och avvikelser.
10. När en kvarstående brist ska vara åtgärdad.

Standardtext till RFP:n:

För varje krav ska Leverantören ange ”Uppfylls”, ”Uppfylls delvis”, ”Uppfylls inte” eller ”Ej tillämpligt”. Svaret ska innehålla en beskrivning av hur kravet uppfylls, hänvisning till relevant bevismaterial och föreslagen avtalsbestämmelse samt en fullständig redovisning av reservationer, beroenden, kundåtgärder och avvikelser.

Skallkrav, utvärderingskrav och avtalskrav

Alla krav ska inte hanteras på samma sätt.

Regulatoriskt nödvändiga krav bör normalt vara obligatoriska när kreditbolaget saknar möjlighet att hantera bristen genom en annan kontroll.

Det kan exempelvis gälla:

• banksekretess,
• myndighetsåtkomst,
• incidentrapportering,
• personuppgiftsbiträdesavtal,
• åtkomst till kreditbolagets data,
• information om underleverantörer,
• dokumentation av kreditbeslut,
• mänsklig omprövning av automatiserade beslut,
• kontinuitet och återställning,
• exit och dataportabilitet.

Andra krav kan utvärderas utifrån kvalitet och mognad, exempelvis:

• användarvänlighet,
• automatiseringsgrad,
• rapporteringsfunktioner,
• implementeringsmetodik,
• modellövervakning,
• verktyg för datamigrering,
• säkerhetsorganisation,
• leverantörens erfarenhet från kreditverksamhet.

Ett lägre pris bör inte kunna kompensera för en regulatorisk eller kundrelaterad risk som kreditbolaget inte kan acceptera.

Säkerställ att RFP-svaren blir bindande

En omfattande kravspecifikation har begränsat värde om leverantörens svar inte förs in i det slutliga avtalet.

Det bör framgå redan i RFP att:

• leverantörens svar är bindande,
• samtliga avvikelser ska redovisas med anbudet,
• kravspecifikationen ska ingå som avtalsbilaga,
• säkerhets- och dataskyddskraven ska ingå i avtalet,
• SLA, kontinuitet och exit ska regleras,
• underleverantörsförteckningen ska vara avtalsreglerad,
• särskilt överenskomna villkor ska ha företräde framför standardvillkor,
• kritiska krav ska verifieras före produktionssättning.

Standardtext till RFP:n:

Leverantörens svar på RFP och kravspecifikationen ska vara bindande och ingå i det slutliga avtalet. Samtliga avvikelser ska redovisas tydligt och samlat i anbudet. Ett krav eller villkor som inte uttryckligen har kommenterats ska anses accepterat av Leverantören.

Vanliga misstag vid kreditbolagets IT-RFP

Kreditprocessen beskrivs för övergripande

Ett krav på att systemet ska ”stödja kreditprövning” är inte tillräckligt. RFP behöver beskriva data, verifiering, regler, modeller, mandat, undantag, omprövning och dokumentation.

DORA och outsourcing behandlas som samma sak

En IKT-tjänst kan omfattas av DORA utan att leverantören tar över en verksamhetsfunktion. Bedömningarna kan överlappa men behöver dokumenteras separat.

Konsument- och företagskrediter blandas ihop

Regelverk, uppgifter, informationskrav och beslutsprocesser kan skilja sig väsentligt. Systemet behöver kunna hantera produkt- och regelversioner separat.

Kreditbeslutet kan inte återskapas

Det räcker inte att systemet visar att en ansökan avslogs. Kreditbolaget behöver kunna visa vilka data, regler, modeller och mandat som användes vid beslutstidpunkten.

Leverantören äger reglerna och modellen

Kreditbolaget får då svårt att förklara beslut, följa upp risk, genomföra validering och byta leverantör.

Automatiserade beslut saknar process för mänsklig omprövning

Ett manuellt beslut i ett separat e-postflöde är sällan tillräckligt. Omprövningen behöver vara behörighetsstyrd, dokumenterad och spårbar.

Banksekretess behandlas som en standardklausul

RFP behöver även behandla faktisk åtkomst, supportländer, privilegierade konton, testdata och underleverantörer.

Certifieringar ersätter den egna riskbedömningen

ISO-certifieringar och kontrollrapporter är värdefulla men visar inte automatiskt att den aktuella tjänsten, kreditprocessen och avtalslösningen uppfyller kreditbolagets krav.

Produktdemonstrationen används som acceptanstest

En demonstration visar inte att systemet kan hantera kreditbolagets egna produkter, data, prismodeller, undantag och regulatoriska kontroller.

Exitkraven begränsas till kunddata

Kreditbolaget behöver även få ut regler, konfigurationer, modeller, loggar, revisionsspår och teknisk dokumentation.

Vanliga frågor

Omfattas alla SaaS-tjänster av DORA?

En SaaS-tjänst som är en IKT-tjänst omfattas normalt av kreditinstitutets DORA-hantering. Kravnivån behöver dock anpassas efter vilken funktion tjänsten stödjer och om funktionen är kritisk eller viktig.

Är alla externa IT-tjänster outsourcing?

Nej. En leverantör kan tillhandahålla ett tekniskt verktyg utan att ta över en verksamhetsfunktion. Bedömningen beror på tjänstens faktiska innehåll, leverantörens ansvar och kreditbolagets egen kontroll.

Räcker en ISO 27001-certifiering?

Nej. Certifieringen är ett viktigt underlag men ersätter inte bedömningen av den aktuella tjänsten, datan, underleverantörerna, kontinuiteten och avtalsvillkoren.

Måste all kunddata lagras i Sverige?

Det finns inte något generellt krav på att all data alltid måste lagras i Sverige. Kreditbolaget behöver däremot känna till samtliga lagrings-, behandlings- och supportländer samt bedöma banksekretess, dataskydd, tillsynsåtkomst, säkerhet och exit.

Får ett kreditbolag använda helt automatiserade kreditbeslut?

Automatiserade kreditbeslut kan förekomma, men kreditbolaget behöver bedöma kraven enligt bland annat konsumentkreditlagen, GDPR och AI-förordningen. Det måste finnas tillräcklig information, dokumentation och möjlighet till mänsklig omprövning när reglerna kräver det.

Är all kreditvärdering med AI högrisk?

AI-system som bedömer fysiska personers kreditvärdighet eller fastställer kreditpoäng omfattas av högriskklassificeringen i AI-förordningens bilaga III, med undantag för AI som används för att upptäcka finansiella bedrägerier. Traditionella regelbaserade system är inte automatiskt AI-system; en teknisk och rättslig klassificering behöver göras.

Ska alla regulatoriska krav vara skallkrav?

Krav som är nödvändiga för regelefterlevnad och inte kan hanteras genom alternativa kontroller bör normalt vara obligatoriska. Andra krav kan användas som kvalitets- och utvärderingskriterier.

Sammanfattning

En väl genomförd RFP för ett kreditbolag börjar med att tjänsten klassificeras.

Kreditbolaget behöver bedöma:

• om tjänsten omfattas av DORA,
• om en verksamhetsfunktion läggs ut,
• vilka kreditprodukter och kundgrupper som påverkas,
• vilka data och personuppgifter som behandlas,
• om automatiserade beslut eller AI används,
• vilka underleverantörer och externa datakällor som ingår,
• hur kreditbolaget behåller kontroll och kompetens,
• hur kontinuitet och exit ska genomföras.

Därefter behöver regelverken översättas till konkreta och verifierbara krav på bland annat:

• kreditprövning,
• kreditbeslut och mandat,
• automatiserad behandling,
• kundinformation och prissättning,
• låneadministration,
• kreditövervakning,
• betalningssvårigheter och inkasso,
• informationssäkerhet och banksekretess,
• GDPR,
• penningtvätt och bedrägeri,
• AI- och modellrisk,
• incidenter och kontinuitet,
• underleverantörer,
• revision,
• dataportabilitet och exit.

Kraven ska finnas med i RFP, utvärderas tillsammans med leverantörens anbud och därefter föras in i det bindande avtalet.

Ladda ner RFP-checklistan för kreditbolag

IJMO Consulting har tagit fram en redigerbar Wordmall som kan användas vid upphandling av IT-system, SaaS, molntjänster och andra IKT-tjänster i kreditverksamhet.

Mallen omfattar bland annat:

• DORA-klassificering,
• outsourcing och bibehållen kontroll,
• kreditprövning och kreditbeslut,
• automatiserade beslut och mänsklig omprövning,
• konsumentkrediter och företagskrediter,
• ränta, avgifter och kundinformation,
• utbetalning och låneadministration,
• kreditövervakning och problemkrediter,
• kravhantering och inkasso,
• informationssäkerhet och banksekretess,
• GDPR, AML och sanktioner,
• AI- och modellrisk,
• incidenthantering och kontinuitet,
• underleverantörer och revision,
• exit, migrering och acceptans,
• färdiga standardtexter att lägga in i RFP.

Ladda ner RFP-checklistan för kreditbolag

Behöver ni stöd med en konkret IT-upphandling?

IJMO Consulting hjälper kreditmarknadsbolag och andra finansiella företag att:

• klassificera IKT-tjänster,
• genomföra DORA- och outsourcingbedömningar,
• ta fram RFP och kravspecifikation,
• granska leverantörer och underleverantörer,
• utvärdera anbud och regulatoriska avvikelser,
• förhandla IT-, SaaS- och outsourcingavtal,
• etablera SLA, KPI, KRI och leverantörsuppföljning,
• ta fram kontinuitets- och exitkrav.

Kontakta IJMO Consulting för stöd med er nästa RFP eller IT-upphandling.

Källor

1. Europaparlamentets och rådets förordning (EU) 2022/2554 om digital operativ motståndskraft för finanssektorn, DORA, särskilt artiklarna 28–30.
2. Kommissionens delegerade förordning (EU) 2024/1773 om policy för IKT-tjänster som stödjer kritiska eller viktiga funktioner.
3. Kommissionens delegerade förordning (EU) 2025/532 om underleverantörer till IKT-tjänster som stödjer kritiska eller viktiga funktioner.
4. Kommissionens genomförandeförordning (EU) 2024/2956 om DORA:s informationsregister.
5. Lag (2004:297) om bank- och finansieringsrörelse.
6. FFFS 2014:1 om styrning, riskhantering och kontroll i kreditinstitut, inklusive FFFS 2026:15.
7. FFFS 2018:16 om hantering av kreditrisker, inklusive FFFS 2026:19.
8. EBA/GL/2020/06, riktlinjer om låneutgivning och övervakning.
9. Konsumentkreditlagen (2010:1846) och konsumentkreditlagen (2026:1011).
10. Europaparlamentets och rådets förordning (EU) 2016/679, GDPR.
11. Europaparlamentets och rådets förordning (EU) 2024/1689, AI-förordningen.
12. Lag (2017:630) om åtgärder mot penningtvätt och finansiering av terrorism samt FFFS 2017:11.
13. Kreditupplysningslagen (1973:1173).
14. Inkassolagen (1974:182) och FFFS 2025:2 om inkasso.
15. Lag (2010:751) om betaltjänster, när den upphandlade lösningen omfattar betaltjänster.
16. Europaparlamentets och rådets förordning (EU) 2023/2854, Data Act.

Om författaren

Mathias Olsson är grundare av IJMO Consulting och senior inköpskonsult med erfarenhet av IT-inköp, SaaS, ERP, strategisk sourcing, avtalsförhandling och leverantörsstyrning. Han har arbetat i ledande inköps- och sourcingroller inom bland annat försäkring, IT, telekom och transport. Hans artiklar bygger på praktisk erfarenhet från upphandlingar, avtalsförhandlingar och förändringsprojekt.

Läs mer om Mathias Olsson →

Publicerad: 25 augusti 2026

Senast uppdaterad: 30 augusti 2026