När ett fondbolag 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, implementationstid och pris.

Systemet kan påverka fondvärdering, NAV-beräkning, portföljförvaltning, orderhantering, riskkontroll, likviditetshantering, andelsägarregister, teckning och inlösen, rapportering till Finansinspektionen samt information till fondandelsägarna. Ett fel i systemet kan därför få konsekvenser för såväl fondbolagets regelefterlevnad som fondandelsägarnas ekonomiska intressen.

DORA, lagen om värdepappersfonder, Finansinspektionens föreskrifter, GDPR och penningtvättsreglerna påverkar både hur leverantören ska granskas och vilka krav som behöver finnas i en RFP. Beroende på systemets användningsområde kan även SFDR, EU-taxonomin, PRIIPs-förordningen, AI-förordningen, Data Act, EMIR, SFTR och reglerna om marknadsmissbruk bli relevanta.

Den regulatoriska analysen behöver därför genomföras innan RFP skickas ut. Om klassificeringen görs först när en leverantör redan har valts finns en risk att leverantörens standardtjänst eller standardavtal inte ger fondbolaget den information, kontroll och avtalsmässiga rätt som krävs.

Artikeln utgår främst från ett svenskt fondbolag som förvaltar värdepappersfonder enligt lagen om värdepappersfonder. Ett fondbolag som även förvaltar alternativa investeringsfonder behöver komplettera bedömningen med lagen om förvaltare av alternativa investeringsfonder och AIFMD-regelverket.

Ett IT-inköp är också ett beslut om styrning och verksamhetsrisk

Ett fondsystem är sällan isolerat från fondbolagets övriga verksamhet. Det kan exempelvis ta emot transaktionsdata från portföljförvaltningen, marknadsdata från externa dataleverantörer, positionsdata från förvaringsinstitutet och investerarinformation från distributörer.

Systemet kan därefter användas för att:

  • beräkna fondens värde och NAV,
  • kontrollera placeringsbegränsningar,
  • hantera order och allokeringar,
  • beräkna risk och likviditet,
  • stämma av positioner och likvida medel,
  • producera rapporter till Finansinspektionen,
  • skapa faktablad och fondinformation,
  • dokumentera hållbarhetsrelaterade uppgifter,
  • registrera teckning och inlösen,
  • genomföra kundkännedoms- och penningtvättskontroller.

Det innebär att inköp, verksamhet, IT, informationssäkerhet, risk, compliance, juridik, dataskydd och kontinuitetsansvariga normalt behöver delta i upphandlingen. För vissa system behöver även fondredovisning, portföljförvaltning, transfer agency, hållbarhetsansvariga och rapporteringsansvariga vara involverade.

RFP ska översätta dessa funktioners behov till krav som är tydliga, verifierbara och möjliga att föra in i det bindande avtalet.

Vilka regelverk påverkar fondbolagets IT-upphandling?

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

DORA, förordning (EU) 2022/2554, började tillämpas den 17 januari 2025 och omfattar bland annat fondbolag och andra finansiella företag. Regelverket innehåller krav på IKT-riskhantering, incidenthantering, tester av digital operativ motståndskraft och hantering av risker hos externa IKT-leverantörer.

DORA kan bli relevant vid köp av exempelvis:

  • portfölj- och orderhanteringssystem,
  • fondredovisnings- och NAV-system,
  • risk- och likviditetssystem,
  • andelsägarregister och transfer agency-lösningar,
  • regulatoriska rapporteringssystem,
  • marknadsdata- och analysplattformar,
  • dokument- och informationsplattformar,
  • moln- och hostingtjänster,
  • IT-drift, support och systemförvaltning,
  • säkerhets- och övervakningstjänster,
  • integrationsplattformar och API-tjänster.

Fondbolaget behöver bland annat bedöma om tjänsten stödjer en kritisk eller viktig funktion, genomföra en dokumenterad riskbedömning, bedöma leverantörskoncentration och underleverantörsberoenden samt säkerställa att avtalet innehåller de rättigheter och skyldigheter som DORA kräver.

För IKT-tjänster som stödjer kritiska eller viktiga funktioner skärps kraven på bland annat leverantörsgranskning, kontroll av underleverantörskedjan, revisionsrätt, kontinuitet, säkerhet och exit. De kompletterande DORA-reglerna ställer även krav på hur fondbolaget ska bedöma leverantörens resurser, kontrollmiljö, datalagring, tredjelandsrisker och användning av underleverantörer.

Fondbolaget ska dessutom upprätthålla ett informationsregister över kontraktsmässiga arrangemang med IKT-leverantörer. Finansinspektionen anger att berörda företag årligen ska rapportera registret och att rapporteringen ska avse förhållandena vid utgången av föregående kalenderår. Registret behöver innehålla strukturerade uppgifter om bland annat avtal, juridiska enheter, tjänster, leveransplatser och underleverantörer.

Det innebär att leverantören redan i RFP bör åta sig att lämna och löpande uppdatera den information som fondbolaget behöver till sitt DORA-register.

Lagen om värdepappersfonder – när en funktion delegeras

En separat bedömning behöver genomföras enligt lagen om värdepappersfonder när en leverantör ska utföra en funktion eller tjänst som ingår i fondverksamheten.

Det kan exempelvis vara aktuellt när leverantören ska utföra eller ta ett operativt ansvar för:

  • fondadministration,
  • fondredovisning,
  • NAV-beräkning,
  • portföljförvaltning,
  • riskberäkningar,
  • andelsägarregister,
  • teckning och inlösen,
  • sammanställning av investerarinformation,
  • rapportering,
  • andra administrativa funktioner som ingår i fondverksamheten.

Enligt 2 a kap. lagen om värdepappersfonder ska ett uppdragsavtal och fondbolagets delegeringsstruktur kunna motiveras på objektiva grunder. Uppdragstagaren ska ha tillräcklig sakkunskap och kompetens. Delegeringen får inte hindra fondbolaget från att handla i fondandelsägarnas intresse eller försvåra Finansinspektionens tillsyn. Fondbolaget ska också kunna övervaka funktionen, ge nödvändiga instruktioner och under vissa förutsättningar säga upp uppdragsavtalet med omedelbar verkan.

Delegeringen får inte vara så omfattande att fondbolaget i praktiken inte längre kan anses vara den faktiska förvaltaren. Fondbolaget ska underrätta Finansinspektionen innan uppdragstagaren börjar utföra de delegerade funktionerna eller tjänsterna.

Ett uppdragsavtal fråntar inte heller fondbolaget dess ansvar. Fondbolaget ska säkerställa att den delegerade funktionen utförs i enlighet med lagen. Vid vidaredelegering krävs bland annat fondbolagets förhandsgodkännande, underrättelse till Finansinspektionen och löpande övervakning av den vidaredelegerade funktionen.

DORA och uppdragsavtal är två olika klassificeringar

Det är viktigt att skilja mellan DORA-bedömningen och bedömningen enligt fondregelverket:

  • En SaaS-tjänst kan omfattas av DORA utan att leverantören utför en funktion som ingår i fondverksamheten.
  • En leverantör kan utföra en delegerad fondfunktion samtidigt som den tillhandahåller en IKT-tjänst som omfattas av DORA.
  • Ett fondsystem kan stödja en kritisk eller viktig funktion enligt DORA utan att leverantören tar över ansvaret för själva verksamhetsfunktionen.
  • Ett uppdrag som inte är en IKT-tjänst kan fortfarande vara ett uppdragsavtal enligt lagen om värdepappersfonder.

Finansinspektionens föreskrifter anger att reglerna i 14 kap. FFFS 2013:9 inte ska tillämpas på sådana uppdragsavtal som omfattas av DORA kapitel V. Det innebär dock inte att den separata bedömningen enligt 2 a kap. lagen om värdepappersfonder försvinner när en fondfunktion delegeras.

Fondbolagets inköpsprocess bör därför alltid innehålla två separata beslut:

  1. Är detta ett IKT-avtal som omfattas av DORA, och stödjer det en kritisk eller viktig funktion?
  2. Ska leverantören utföra en funktion eller tjänst som utgör ett uppdragsavtal enligt lagen om värdepappersfonder?

Finansinspektionens föreskrifter

FFFS 2013:9 innehåller omfattande krav på fondbolagets organisation, informationssystem, informationssäkerhet, fondadministration, orderhantering, riskhantering, information och uppdragsavtal.

Föreskrifterna kräver bland annat att fondbolagets verksamhetsplan beskriver hur IT-verksamheten är organiserad, vilka system som används och vilka åtgärder som vidtas för informationssäkerhet och sekretess. Vid delegering ska verksamhetsplanen även beskriva hur fondbolaget uppfyller kraven enligt antingen outsourcingreglerna eller DORA.

För uppdragsavtal som inte träffas av DORA särskilda tredjepartsregler innehåller föreskrifterna bland annat krav på att fondbolaget ska:

  • bedöma hur effektivt uppdragstagaren utför uppdraget,
  • övervaka uppdraget och tillhörande risker,
  • kunna vidta åtgärder vid brister,
  • få information om händelser som kan påverka leveransen,
  • behålla egen kunskap och egna resurser för övervakning,
  • säkerställa leverantörens samarbete med Finansinspektionen,
  • ge fondbolaget, revisorerna och Finansinspektionen faktisk åtkomst,
  • säkerställa sekretess och kontinuitetsplanering,
  • kunna säga upp uppdraget utan att skada verksamhetens kontinuitet eller kvalitet.

Rättigheter och skyldigheter ska regleras tydligt i ett skriftligt avtal.

GDPR – när systemet behandlar personuppgifter

Fondbolagets system kan behandla personuppgifter om fondandelsägare, företrädare, verkliga huvudmän, anställda, kontaktpersoner och personer som omfattas av olika kontroller.

När leverantören behandlar personuppgifter för fondbolagets räkning behöver RFP bland annat behandla:

  • rollerna som personuppgiftsansvarig och personuppgiftsbiträde,
  • personuppgiftsbiträdesavtal,
  • dokumenterade instruktioner,
  • informationssäkerhet,
  • underbiträden,
  • behandlingens ändamål,
  • datalagrings- och behandlingsplatser,
  • åtkomst från länder utanför EU och EES,
  • lagrings- och gallringstider,
  • incidentrapportering,
  • stöd vid registrerades rättigheter,
  • återlämning och radering av uppgifter,
  • revisions- och kontrollrättigheter.

Fondbolaget behöver kartlägga hela behandlingskedjan. Det räcker inte att den primära databasen finns inom EU om support, säkerhetskopiering eller underleverantörer innebär att uppgifterna kan behandlas från andra länder. GDPR ställer krav på bland annat personuppgiftsbiträden, underbiträden, säkerhetsåtgärder och laglig överföring av personuppgifter till tredjeland.

Penningtvättsreglerna

Fondverksamhet enligt lagen om värdepappersfonder omfattas uttryckligen av lagen om åtgärder mot penningtvätt och finansiering av terrorism. Detsamma gäller verksamhet som förvaltare av alternativa investeringsfonder.

System som används i kund- och investerarprocesser kan därför behöva stödja:

  • identifiering och verifiering av kund,
  • kontroll av verklig huvudman,
  • kundriskklassificering,
  • PEP-kontroller,
  • sanktionskontroller,
  • dokumentation av kundkännedom,
  • löpande uppföljning,
  • avvikelse- och varningshantering,
  • ärendehantering och utredning,
  • spårbarhet och behörighetsstyrning,
  • bevarande av dokumentation.

RFP bör även klargöra vem som ansvarar för regelverk, riskmodeller, externa datakällor och manuell hantering när en automatisk kontroll inte ger ett entydigt resultat.

SFDR och EU-taxonomin

SFDR innehåller harmoniserade transparensregler om hur finansiella marknadsaktörer integrerar hållbarhetsrisker och lämnar hållbarhetsrelaterad information på företags- och produktnivå. EU-taxonomin innehåller gemensamma kriterier för när ekonomiska aktiviteter kan klassificeras som miljömässigt hållbara och kompletterar hållbarhetsrapporteringen för finansiella produkter.

System som används för hållbarhetsanalys och rapportering bör därför kunna hantera:

  • datakällor och datalicenser,
  • dokumenterade beräkningsmetoder,
  • uppskattade respektive rapporterade värden,
  • datakvalitet och dataluckor,
  • historik över metod- och dataleverantörsförändringar,
  • hållbarhetsindikatorer,
  • huvudsakliga negativa konsekvenser,
  • taxonomirelaterade beräkningar,
  • produktklassificering och produktinformation,
  • spårbarhet mellan investeringsdata och publicerade uppgifter.

RFP bör kräva att det går att rekonstruera vilken data, metod, klassificering och regelversion som användes när en viss hållbarhetsuppgift publicerades.

PRIIPs och information till investerare

PRIIPs-förordningen kräver att producenter och säljare av vissa paketerade investeringsprodukter ger icke-professionella investerare ett faktablad med standardiserad information om bland annat produkt, risk, kostnader och möjliga utfall. Investeringsfonder omfattas av regelverket.

Ett system som producerar eller levererar underlag till PRIIPs-faktablad behöver därför kunna hantera:

  • produkt- och andelsklassdata,
  • riskindikatorer,
  • kostnadsberäkningar,
  • resultatscenarier,
  • målmarknadsinformation,
  • dokumentversioner,
  • publiceringsdatum,
  • godkännanden,
  • arkivering och spårbarhet.

Det bör vara möjligt att i efterhand fastställa exakt vilken version av ett faktablad som gällde för en viss fond och andelsklass vid en viss tidpunkt.

Data Act – dataportabilitet och leverantörsbyte

Data Act innehåller bland annat regler som ska underlätta byte mellan leverantörer av databehandlingstjänster och minska tekniska och avtalsmässiga hinder mot leverantörsbyte. Reglerna är särskilt relevanta för moln-, SaaS-, PaaS- och IaaS-tjänster.

För fondbolaget kompletterar detta DORA krav på exit och operativ motståndskraft. RFP bör därför reglera hur fonddata, metadata, beräkningsregler, historik, loggar, konfigurationer och dokumentation kan överföras till fondbolaget eller en ny leverantör.

AI-förordningen

AI-förordningen behöver bedömas när lösningen använder AI för exempelvis:

  • investeringsanalys,
  • portföljförslag,
  • riskbedömning,
  • handels- eller orderbeslut,
  • hållbarhetsklassificering,
  • dokumentanalys,
  • kundservice,
  • penningtvättskontroller,
  • övervakning av avvikande beteenden,
  • kodutveckling eller systemsupport.

Alla AI-funktioner inom ett fondbolag är inte automatiskt högrisksystem. Fondbolaget behöver ändå inventera användningen, fastställa roller och krav samt bedöma riskerna med data, modeller, automatisering, mänsklig kontroll, loggning, robusthet och cybersäkerhet.

Klassificera tjänsten innan RFP färdigställs

DORA-klassificering

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. Vilken påverkan får ett avbrott, en felaktig beräkning eller en dataförlust?
  5. Hur snabbt behöver tjänsten och informationen kunna återställas?
  6. Är tjänsten beroende av en större molnplattform eller en koncentrerad leverantörskedja?
  7. Var lagras och behandlas data?
  8. Vilka underleverantörer stödjer tjänsten?
  9. Vilken information behövs till DORA informationsregister?
  10. Behöver Finansinspektionen informeras före avtalsstart eller vid en väsentlig förändring?

Uppdragsavtalsbedömning

Fondbolaget bör separat bedöma:

  1. Ska leverantören utföra en funktion som ingår i fondverksamheten?
  2. Tar leverantören ett självständigt operativt ansvar eller tillhandahåller den endast ett tekniskt verktyg?
  3. Kan uppdraget motiveras på objektiva grunder?
  4. Har leverantören rätt sakkunskap, kompetens, resurser och eventuella tillstånd?
  5. Finns det intressekonflikter?
  6. Kan fondbolaget övervaka funktionen och ge bindande instruktioner?
  7. Har fondbolaget kvar tillräcklig egen kompetens och kontroll?
  8. Kan uppdraget avslutas utan att fondverksamheten eller fondandelsägarna skadas?
  9. Ska Finansinspektionen underrättas innan leveransen påbörjas?
  10. Förekommer vidaredelegering och har fondbolaget kontroll över den?

Verksamhets- och dataanalys

Utöver de två regulatoriska klassificeringarna bör fondbolaget identifiera:

  • vilka fonder och andelsklasser som omfattas,
  • vilka processer som ska stödjas,
  • vilka datakällor som används,
  • vem som äger varje datamängd,
  • vilka beräkningar systemet genomför,
  • vilka manuella kontroller som krävs,
  • vilka rapporter och dokument som produceras,
  • vilka integrationer som är kritiska,
  • vilka historiska uppgifter som måste migreras,
  • vilka avstämningar som krävs före produktionssättning.

Så bör kraven utformas i fondbolagets RFP

1. Tjänstens omfattning och leveransmodell

Leverantören ska lämna en fullständig beskrivning av lösningen och den bakomliggande leveranskedjan.

RFP bör kräva information om:

  • samtliga funktioner och moduler,
  • teknisk arkitektur,
  • driftmiljöer,
  • integrationer och API,
  • datakällor,
  • datalagringsplatser,
  • support- och förvaltningsmodell,
  • ansvarsfördelning,
  • underleverantörer,
  • externa plattformar,
  • standardfunktioner och kundanpassningar,
  • begränsningar och beroenden,
  • produktens utvecklingsplan,
  • support- och avvecklingsperioder.

Exempel på kravformulering:

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

2. Fonddata och fullständig spårbarhet

Spårbarhet är central i fondverksamheten. Fondbolaget behöver kunna rekonstruera hur en position, transaktion, värdering, kontroll, rapport eller investeraruppgift har skapats.

RFP bör ställa krav på:

  • tidsstämplar,
  • versionshistorik,
  • datakällor,
  • manuella ändringar,
  • automatiska och manuella kontroller,
  • beräkningsregler,
  • regel- och parameterändringar,
  • godkännanden,
  • användaraktiviteter,
  • revisionsloggar,
  • export av underlag.

Exempel på kravformulering:

Lösningen ska säkerställa fullständig och sökbar spårbarhet av portföljdata, värderingsunderlag, NAV, order, avstämningar, investerarinformation och regulatoriska rapporter. Det ska vara möjligt att i efterhand fastställa vilken data, beräkningsregel, kontroll, parameter och dokumentversion som användes vid en viss tidpunkt.

3. Fondredovisning, värdering och NAV

För ett fondredovisnings- eller NAV-system bör RFP minst omfatta:

  • stöd för fondbolagets fonder och andelsklasser,
  • värdering av samtliga relevanta instrument,
  • hantering av marknadspriser och alternativa prisfall,
  • ränta, upplupna poster och bolagshändelser,
  • valutakurser,
  • avgifter och kostnader,
  • swing pricing eller andra prisjusteringsmekanismer,
  • skatter och källskatter,
  • hantering av felaktigt NAV,
  • avstämningar,
  • kontrollgränser och fyrögonsprincip,
  • rapporter till förvaringsinstitutet,
  • dokumentation av värderingsmetoder,
  • parallella beräkningar under implementeringen.

Leverantören bör beskriva hur datakvalitetsproblem identifieras och hur manuella korrigeringar registreras, godkänns och följs upp.

4. Portföljförvaltning, order och placeringskontroller

System som används i portföljförvaltningen bör kunna stödja:

  • investeringsbeslut,
  • orderläggning och orderstatus,
  • allokering mellan fonder,
  • kontroll av placeringsbegränsningar,
  • kontroll före och efter handel,
  • best execution,
  • hantering av intressekonflikter,
  • motpartslimiter,
  • derivat och säkerheter,
  • exponering och hävstång,
  • likviditetsrisk,
  • stresstester,
  • incident- och överträdelsehantering,
  • dokumentation av manuella undantag.

RFP bör kräva att systemet kan skilja mellan varningar, hårda stopp, godkända undantag och faktiska regelöverträdelser.

5. Teckning, inlösen och andelsägarregister

För transfer agency och andelsägarregister bör kravbilden bland annat omfatta:

  • teckning och inlösen,
  • byten mellan fonder och andelsklasser,
  • bryttider,
  • handelskalendrar,
  • NAV-koppling,
  • betalningar,
  • investerarinnehav,
  • ägar- och transaktionshistorik,
  • avgifter,
  • rättelser,
  • fullmakter,
  • kundkännedom,
  • distributörsflöden,
  • bekräftelser och aviseringar,
  • personuppgifter och sekretess,
  • sökbar dokumentation och revisionsspår.

Det ska vara möjligt att återskapa hela behandlingskedjan från mottagen order till registrerat innehav och genomförd betalning.

6. Förvaringsinstitut och avstämningar

Fondbolaget behöver säkerställa att lösningen kan stödja informationsutbyte och kontroller tillsammans med förvaringsinstitutet.

RFP bör omfatta:

  • positionsavstämning,
  • likvidavstämning,
  • transaktionsavstämning,
  • NAV-underlag,
  • kontroll av penningflöden,
  • kontroll av fondbestämmelser och placeringsregler,
  • avvikelsehantering,
  • filformat och API,
  • tidsfrister,
  • återrapportering,
  • rättelseprocesser,
  • gemensam incidenthantering.

Ansvarsfördelningen mellan fondbolaget, leverantören och förvaringsinstitutet ska vara tydlig och dokumenterad.

7. Regulatorisk rapportering och investerarinformation

Leverantören bör redovisa vilka rapporter och dokument som stöds, vilka datakällor som används och hur förändringar i regelverk och rapportformat hanteras.

RFP kan exempelvis omfatta:

  • rapportering till Finansinspektionen,
  • årsberättelse och halvårsredogörelse,
  • PRIIPs-faktablad,
  • fondfaktablad och informationsbroschyr,
  • SFDR-upplysningar,
  • taxonomirelaterad information,
  • kostnads- och avgiftsinformation,
  • risk- och resultatindikatorer,
  • rapporter till förvaringsinstitut,
  • EMIR- och SFTR-relaterat underlag när det är relevant,
  • arkivering och publiceringshistorik.

Exempel på kravformulering:

Leverantören ska beskriva hur rapporter, faktablad och investerarinformation skapas, kvalitetssäkras, godkänns, versionshanteras, publiceras och arkiveras. Det ska vara möjligt att fastställa vilka data, metoder och regelversioner som låg till grund för varje publicerad uppgift.

8. Regulatoriskt stöd och uppdragsavtal

RFP bör inte bara fråga om leverantören är ”DORA-compliant” eller ”följer UCITS”. Leverantören behöver redovisa hur tjänsten och avtalet gör det möjligt för fondbolaget att uppfylla sina skyldigheter.

Leverantören bör beskriva:

  • hur tjänsten stödjer DORA,
  • vilken information som kan lämnas till DORA-registret,
  • hur fondbolaget kan övervaka leveransen,
  • hur instruktioner hanteras,
  • hur regulatoriska förändringar införs,
  • hur Finansinspektionens frågor och granskningar hanteras,
  • vilka kontrollrapporter som finns,
  • vilka avvikelser leverantören gör från kundens avtalskrav,
  • hur delegerade och vidaredelegerade funktioner kontrolleras.

Exempel på kravformulering:

Leverantören ska utföra den delegerade funktionen i enlighet med tillämplig lag, fondbestämmelser, Fondbolagets dokumenterade instruktioner och avtalade kontrollkrav. Fondbolaget ska kunna övervaka funktionen, lämna bindande instruktioner och vidta omedelbara riskreducerande åtgärder.

9. Informationssäkerhet

Säkerhetskraven behöver vara konkreta och verifierbara. En ISO-certifiering eller en granskningsrapport kan vara ett viktigt underlag, men ersätter inte bedömningen av den specifika tjänsten.

RFP bör omfatta:

  • säkerhetsstyrning,
  • identitets- och behörighetshantering,
  • multifaktorautentisering,
  • privilegierade konton,
  • fyrögonsprincip och segregation of duties,
  • kryptering,
  • nyckelhantering,
  • loggning och övervakning,
  • separation mellan kunder och miljöer,
  • säker utvecklingsprocess,
  • kod- och beroendegranskning,
  • sårbarhetshantering,
  • penetrationstester,
  • patchhantering,
  • säkerhetskopiering,
  • fysisk säkerhet,
  • personalsäkerhet,
  • rapportering av säkerhetsbrister.

Leverantören bör redovisa bevisning, exempelvis certifieringar, kontrollrapporter, testresultat och åtgärdsplaner.

10. Personuppgifter och datalagring

Leverantören ska redovisa hela behandlingskedjan, inklusive produktion, test, support, loggning, säkerhetskopiering och katastrofåterställning.

Exempel på kravformulering:

Leverantören ska redovisa samtliga länder där Fondbolagets data kan lagras, behandlas, säkerhetskopieras eller göras tillgänglig. Redovisningen ska omfatta Leverantören, underleverantörer och underbiträden samt åtkomst för support och administration.

RFP bör även omfatta:

  • personuppgiftskategorier,
  • kategorier av registrerade,
  • behandlingsändamål,
  • underbiträden,
  • lagrings- och gallringstider,
  • radering ur säkerhetskopior,
  • tredjelandsöverföringar,
  • stöd vid DPIA,
  • incidentstöd,
  • registrerades rättigheter,
  • revisionsrätt,
  • användning av produktionsdata i test,
  • användning av data för analys, produktutveckling eller AI-träning.

11. Incidenthantering

Fondbolaget behöver få tidig information om incidenter. Leverantören ska inte vänta på en fullständig rotorsaksanalys innan den första underrättelsen lämnas.

RFP bör reglera:

  • vad som ska rapporteras,
  • tidsfrist för initial underrättelse,
  • kontaktvägar och tillgänglighet,
  • incidentklassificering,
  • statusuppdateringar,
  • bevarande av loggar och bevis,
  • rotorsaksanalys,
  • korrigerande åtgärder,
  • stöd vid rapportering till Finansinspektionen,
  • stöd vid personuppgiftsincidenter,
  • påverkan på NAV, order, rapporter och fondandelsägare,
  • ansvar för rättelser och kommunikation.

Exempel på kravformulering:

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 tjänsten, Fondbolaget, en fond, en fondandelsägare eller Fondbolagets data. Initial rapportering får inte fördröjas för att incidentens omfattning eller grundorsak ännu inte är fullständigt fastställd.

12. Kontinuitet och återställning

RTO och RPO ska utgå från fondbolagets verksamhetsanalys och inte från leverantörens generella standardnivåer.

RFP bör omfatta:

  • RTO och RPO,
  • tillgänglighetskrav,
  • redundans,
  • geografisk separation,
  • säkerhetskopiering,
  • återställningstester,
  • reservrutiner,
  • manuella processer,
  • alternativa datakällor,
  • prioritering mellan kunder,
  • kapacitet vid marknadsstress,
  • deltagande i fondbolagets övningar,
  • kontinuitetskrav på underleverantörer,
  • dokumentation av testresultat och brister.

För fondredovisning, teckning och inlösen bör RFP även beskriva hur kritiska bryttider och NAV-processer ska hanteras vid ett avbrott.

13. Underleverantörer och vidaredelegering

Fondbolaget behöver förstå hela den relevanta leveranskedjan. Ett SaaS-bolag kan exempelvis använda en molnplattform, externa datacenter, supportbolag, marknadsdataleverantörer och specialiserade beräkningsmotorer.

RFP bör kräva:

  • fullständigt juridiskt namn på relevanta underleverantörer,
  • registreringsland,
  • leverans- och datalagringsplatser,
  • utförd funktion,
  • åtkomst till data,
  • kritikalitet,
  • tillsynsstatus,
  • koncentrationsrisk,
  • kontroll- och revisionsrättigheter,
  • förhandsinformation vid förändringar,
  • fondbolagets rätt att invända,
  • skyldighet att vidta riskreducerande åtgärder,
  • uppsägningsrätt när risken inte kan accepteras.

Exempel på kravformulering:

Leverantören ska redovisa samtliga relevanta underleverantörer och får inte genomföra en väsentlig förändring eller vidaredelegering utan den information, framförhållning och det godkännande som följer av avtalet och tillämpliga regler. Leverantören ansvarar fullt ut för varje underleverantörs prestation.

14. Revision och myndighetsåtkomst

Fondbolaget, dess revisorer, utsedda granskare och behöriga myndigheter behöver kunna få tillgång till relevant information och genomföra nödvändiga kontroller.

RFP bör reglera:

  • dokumentgranskning,
  • intervjuer,
  • tekniska kontroller,
  • riktade revisioner,
  • inspektion på plats när det är motiverat,
  • tillgång till relevanta lokaler,
  • åtkomst till underleverantörer,
  • samarbete med Finansinspektionen,
  • åtgärdsplaner,
  • uppföljning av granskningsresultat.

Exempel på kravformulering:

Fondbolaget, dess revisor, utsedda granskare och behöriga myndigheter ska ha den åtkomst-, revisions- och inspektionsrätt som krävs för att granska tjänsten och Leverantörens efterlevnad. Rätten ska omfatta relevanta underleverantörer och får inte begränsas på ett sätt som gör den ineffektiv.

Standardiserade granskningsrapporter och gemensamma revisioner kan användas när det är lämpligt. De får däremot inte hindra en riktad granskning efter en allvarlig incident, en väsentlig brist eller en myndighetsbegäran.

15. SLA, KPI och KRI

SLA bör spegla fondprocessernas faktiska tidsfrister och risker. Ett generellt tillgänglighetsmått per månad är sällan tillräckligt.

Relevanta mätvärden kan vara:

  • systemtillgänglighet,
  • svarstider och prestanda,
  • genomförande av NAV-processen,
  • leverans av priser och marknadsdata,
  • order- och transaktionsbehandling,
  • genomförda avstämningar,
  • antal och ålder på avvikelser,
  • incidenters svarstid och åtgärdstid,
  • datakvalitetsfel,
  • rapporter levererade i tid,
  • sårbarheter och säkerhetsuppdateringar,
  • genomförda kontinuitetstester,
  • underleverantörsförändringar,
  • öppna revisionsanmärkningar.

Exempel på kravformulering:

SLA, KPI och KRI ska vara objektivt verifierbara. Fondbolaget ska ha tillgång till mätunderlag, avvikelser och historik. Upprepade eller väsentliga brister ska leda till en bindande åtgärdsplan, förstärkt rapportering och, när det är motiverat, uppsägningsrätt.

Servicekrediter bör inte vara fondbolagets enda påföljd när bristen medför en regulatorisk, operativ eller ekonomisk risk.

16. Förändringshantering

Moln- och SaaS-tjänster förändras kontinuerligt. En leverantör kan byta datacenter, molnplattform, underleverantör, datakälla, beräkningsmotor eller AI-modell.

RFP bör kräva förhandsinformation om förändringar som påverkar:

  • funktionalitet,
  • beräkningsmetoder,
  • arkitektur,
  • datamodeller,
  • informationssäkerhet,
  • datalagring,
  • underleverantörer,
  • integrationer,
  • support,
  • regulatorisk rapportering,
  • AI-komponenter,
  • avveckling av produkter och versioner.

Fondbolaget ska få tillräcklig information och tid för att genomföra en ny risk-, säkerhets- och regelefterlevnadsbedömning innan en väsentlig förändring genomförs.

17. Krav på AI-funktioner

Leverantören bör redovisa både AI som är synlig för användaren och AI som används bakom tjänsten.

RFP bör minst omfatta:

  • samtliga AI-komponenter,
  • modeller och modellversioner,
  • användningsområden,
  • vilka beslut och rekommendationer som påverkas,
  • använda data,
  • leverantörens och fondbolagets roller,
  • loggning och spårbarhet,
  • datakvalitet,
  • noggrannhet och kända begränsningar,
  • mänsklig kontroll,
  • möjlighet att åsidosätta resultat,
  • möjlighet att stänga av AI-funktionen,
  • tester av systematiska fel,
  • cybersäkerhet och prompt injection,
  • modellförändringar,
  • ansvar för felaktiga resultat.

Exempel på kravformulering:

Leverantören ska redovisa samtliga AI-komponenter, deras användningsområden, modeller, data, roller, loggning, mänskliga kontroll, kända begränsningar, säkerhet och förändringsprocess. Fondbolagets data, inmatningar, dokument, prompts och utdata får inte användas för modellträning eller tredje parts ändamål utan Fondbolagets föregående skriftliga godkännande.

18. Dataåtkomst, dataportabilitet och exit

Exit ska planeras innan avtalet tecknas. En rätt att ”få tillbaka sin data” är inte tillräcklig.

RFP bör omfatta export av:

  • fond- och andelsklassdata,
  • positioner och transaktioner,
  • investerar- och innehavsdata,
  • historiska NAV och priser,
  • metadata,
  • datamodeller,
  • beräkningsregler,
  • parametrar och parameterhistorik,
  • konfigurationer,
  • loggar och revisionsspår,
  • rapporter och dokument,
  • integrationer och API-dokumentation,
  • kontroll- och avstämningshistorik.

Det bör också finnas krav på:

  • strukturerade och maskinläsbara format,
  • verifiering av dataexportens fullständighet,
  • migreringsstöd,
  • kunskapsöverföring,
  • parallell drift,
  • fortsatt tjänstenivå under övergången,
  • stöd till ny leverantör och förvaringsinstitut,
  • tydliga exitkostnader,
  • radering efter godkänd överföring,
  • raderingsintyg,
  • återkommande test av exitplanen.

Exempel på kravformulering:

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 lämna det stöd som krävs för en säker och kontrollerad övergång.

19. Kommersiella och avtalsmässiga krav

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

Det gäller exempelvis:

  • licenser och abonnemang,
  • användare,
  • fonder och andelsklasser,
  • transaktionsvolymer,
  • lagring,
  • datatrafik,
  • marknadsdata,
  • integrationer,
  • implementation,
  • utbildning,
  • support,
  • regulatoriska förändringar,
  • revision,
  • incidentstöd,
  • dataexport,
  • exit,
  • framtida volymökningar.

Avtalet bör även reglera:

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

20. Implementering, migrering och acceptans

Regulatoriska och operativa krav behöver verifieras före produktionssättning.

RFP bör innehålla krav på:

  • detaljerad implementeringsplan,
  • projektorganisation och ansvar,
  • datainventering,
  • datarensning och datamappning,
  • provmigreringar,
  • kontrollsummeringar,
  • avstämning av positioner och transaktioner,
  • parallell NAV-beräkning när det krävs,
  • säkerhets- och behörighetstester,
  • integrationstester,
  • prestanda- och kapacitetstester,
  • kontinuitets- och återställningstester,
  • regulatoriska acceptanskriterier,
  • dokumentation och utbildning,
  • förvaltningsorganisation,
  • formellt godkännande före produktionssättning.

Exempel på kravformulering:

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

Kräv strukturerade och verifierbara leverantörssvar

Leverantörerna bör inte få besvara regulatoriska och 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 styrker svaret.
  4. Var åtagandet regleras i avtalet.
  5. Vilka beroenden och kundåtgärder som finns.
  6. Om uppfyllandet medför en extra kostnad.
  7. Om det krävs utveckling eller anpassning.
  8. Samtliga reservationer och avvikelser.
  9. När en kvarstående brist kommer att 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 beskriva hur kravet uppfylls, hänvisa till relevant bevismaterial och föreslagen avtalsbestämmelse samt redovisa samtliga reservationer, beroenden, kundåtgärder och avvikelser.

Skallkrav, utvärderingskrav och avtalskrav

Alla krav bör inte hanteras på samma sätt.

Regulatoriskt nödvändiga rättigheter bör normalt vara obligatoriska när det saknas en godtagbar alternativ kontroll. Det kan exempelvis gälla:

  • Finansinspektionens åtkomst,
  • fondbolagets kontroll- och instruktionsrätt,
  • incidentrapportering,
  • personuppgiftsbiträdesavtal,
  • information om underleverantörer,
  • åtkomst till fondbolagets data,
  • kontinuitet och återställning,
  • exit och dataportabilitet,
  • sekretess,
  • bindande skyldighet att följa fondbolagets instruktioner.

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

  • automatiseringsgrad,
  • användarvänlighet,
  • kvaliteten på rapporteringen,
  • leverantörens säkerhetsorganisation,
  • verktyg för migrering,
  • analys- och kontrollfunktioner,
  • implementeringsmetodik,
  • leverantörens erfarenhet av fondverksamhet.

Ett lågt pris bör inte kunna kompensera för en regulatorisk risk som fondbolaget saknar möjlighet att acceptera.

Säkerställ att leverantörens RFP-svar blir bindande

En vanlig brist är att RFP innehåller omfattande krav medan leverantörens slutliga avtal endast reglerar en mindre del av dem.

Det bör därför framgå att:

  • leverantörens RFP-svar är bindande,
  • samtliga avvikelser ska redovisas i anbudet,
  • kravspecifikationen ska vara en avtalsbilaga,
  • säkerhets- och dataskyddskraven ska ingå i avtalet,
  • SLA, kontinuitet och exit ska regleras i avtalsbilagor,
  • underleverantörsförteckningen ska vara avtalsreglerad,
  • leverantörens standardvillkor inte ska ha företräde framför särskilt överenskomna krav,
  • viktiga krav ska verifieras under implementationen,
  • produktionssättning kräver ett formellt godkännande.

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 upphandling av IT-system i fondbolag

Klassificeringen görs efter leverantörsvalet

Det kan då visa sig att tjänsten stödjer en kritisk eller viktig funktion, utgör ett uppdragsavtal eller kräver rättigheter som leverantören inte accepterar.

Fondbolaget frågar bara om leverantören följer DORA

Ett allmänt ja-svar ger begränsat beslutsunderlag. Leverantören behöver visa vilka kontroller, rapporter, rättigheter och avtalsvillkor som finns.

Uppdragsavtal och IKT-tjänst behandlas som samma sak

Bedömningarna överlappar ibland, men har olika rättslig grund och behöver dokumenteras separat.

RFP fokuserar på funktioner men inte på data

För fondbolaget är datakvalitet, spårbarhet, beräkningsregler och historik ofta minst lika viktiga som användargränssnittet.

Underleverantörskedjan granskas inte

Den mest kritiska delen av tjänsten kan utföras av en molnleverantör, dataleverantör eller specialiserad underleverantör som inte är fondbolagets direkta avtalspart.

Revisionsrätten begränsas till en certifiering

Certifieringar och granskningsrapporter är värdefulla, men behöver omfatta rätt tjänst och rätt kontroller. Fondbolaget måste även kunna genomföra riktade kontroller när det finns särskilda skäl.

Exitkraven är för generella

Det behöver framgå exakt vilka data, regler, modeller, historik och dokument som ska exporteras och hur leverantören ska stödja övergången.

Leverantörens svar förs inte in i avtalet

Löften i anbud, presentationer och demonstrationer bör dokumenteras som bindande avtalsåtaganden.

Vanliga frågor

Är alla SaaS-tjänster ett uppdragsavtal?

Nej. En SaaS-tjänst kan vara en IKT-tjänst enligt DORA utan att leverantören tar över en funktion som ingår i fondverksamheten. Bedömningen beror på vad leverantören faktiskt ska utföra och vilket ansvar leverantören får.

Är alla IT-system kritiska eller viktiga enligt DORA?

Nej. Fondbolaget behöver bedöma vilken funktion systemet stödjer och vilka konsekvenser ett avbrott, en säkerhetsincident eller en felaktig leverans skulle få.

Ersätter DORA lagen om värdepappersfonder?

Nej. DORA reglerar bland annat IKT-risk och externa IKT-leverantörer. Lagen om värdepappersfonder innehåller egna krav på delegation, kontroll, ansvar, vidaredelegering och underrättelse till Finansinspektionen.

Räcker en ISO 27001-certifiering?

Nej. Certifieringen kan vara ett viktigt underlag, men fondbolaget behöver även bedöma den specifika tjänsten, leveransmodellen, kontrollomfattningen, underleverantörerna och avtalsvillkoren.

Måste all fonddata lagras i Sverige?

Det finns inte något generellt krav på att all fonddata alltid måste lagras i Sverige. Fondbolaget behöver däremot känna till samtliga lagrings- och behandlingsplatser, bedöma regulatoriska och säkerhetsmässiga risker och säkerställa lagligt stöd för eventuella personuppgiftsöverföringar.

Bör leverantören få använda fondbolagets data för AI-träning?

Det bör inte ske utan ett uttryckligt, informerat och skriftligt godkännande från fondbolaget. RFP och avtalet bör tydligt reglera användning av data, dokument, inmatningar, prompts och utdata.

När ska Finansinspektionen underrättas?

Underrättelsebehovet behöver bedömas utifrån både fondregelverket och DORA. Vid delegering enligt lagen om värdepappersfonder ska Finansinspektionen underrättas innan uppdragstagaren börjar utföra funktionen. DORA medför dessutom krav på informationsregister och särskild hantering av IKT-avtal som stödjer kritiska eller viktiga funktioner.

Sammanfattning

En väl genomförd RFP för IT-system och IT-tjänster i ett fondbolag börjar med tre analyser:

  1. En DORA-klassificering av IKT-tjänsten.
  2. En separat bedömning av uppdragsavtal och delegering.
  3. En verksamhets-, informations- och dataanalys.

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

  • fonddata och spårbarhet,
  • NAV och värdering,
  • portfölj- och orderhantering,
  • risk och likviditet,
  • teckning och inlösen,
  • regulatorisk rapportering,
  • investerarinformation,
  • informationssäkerhet,
  • personuppgifter,
  • incidenthantering,
  • kontinuitet,
  • underleverantörer,
  • revision och myndighetsåtkomst,
  • AI,
  • dataportabilitet och exit.

Kraven ska finnas med redan i RFP, utvärderas tillsammans med anbudet och därefter föras in i det bindande avtalet. På så sätt blir regelefterlevnad och operativ motståndskraft en integrerad del av leverantörsvalet i stället för frågor som måste lösas efter att beslutet redan har fattats.

Ladda ner RFP-checklistan för fondbolag

IJMO Consulting har tagit fram en redigerbar Wordmall med checklista för upphandling av IT-system, SaaS, molntjänster och andra IKT-tjänster i fondbolag.

Mallen omfattar bland annat:

  • DORA-klassificering,
  • uppdragsavtal och vidaredelegering,
  • fondredovisning och NAV,
  • portfölj- och orderhantering,
  • risk och likviditet,
  • andelsägarregister,
  • förvaringsinstitut och avstämningar,
  • GDPR och penningtvätt,
  • SFDR, EU-taxonomin och PRIIPs,
  • informationssäkerhet,
  • incidenthantering,
  • kontinuitet,
  • underleverantörer,
  • revision,
  • SLA, KPI och KRI,
  • AI,
  • exit och dataportabilitet,
  • färdiga standardtexter att lägga in i RFP.

Ladda ner RFP-mallen för fondbolag

Behöver ni stöd med er RFP?

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

  • klassificera IT- och IKT-tjänster,
  • genomföra DORA- och uppdragsavtalsbedö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 samverkansforum,
  • ta fram kontinuitets- och exitkrav.

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



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 →