Att börja experimentera med Nordeas Open Banking-API är gjort på en eftermiddag. Att få samma integration godkänd för skarp drift mot riktiga kundkonton är ett helt annat projekt. Skillnaden ligger sällan i koden, utan i två krav som varje utvecklare måste uppfylla innan banken släpper fram trafik mot produktion: ett tillstånd från Finansinspektionen och kvalificerade eIDAS-certifikat. Den här genomgången följer utvecklarflödet steg för steg och förklarar var de flesta team faktiskt fastnar.
Sandbox är medvetet enkelt
Nordeas testmiljö är öppen och kräver varken tillstånd eller certifikat. Du registrerar dig i utvecklarportalen, får nycklar och kan direkt anropa de PSD2-reglerade gränssnitten mot fiktiva testkonton. Autentiseringen sker via OAuth 2.0, precis som i produktion, så att flödet du bygger i sandbox liknar det skarpa. Det är just det som är poängen: sandbox finns för att du ska kunna verifiera anropslogik, felhantering och samtyckesflöden utan att någon riktig persons bankdata är inblandad.
Vilka API:er som finns, vilka licenser varje gränssnitt kräver och hur den femstegade registreringen ser ut är dokumenterat i vår tekniska genomgång av open banking nordea. Den här artikeln tar vid där sandbox slutar och förklarar de två trösklar som skiljer en fungerande prototyp från en integration som får röra verkliga konton.
Tröskel ett: tillstånd från Finansinspektionen
PSD2 tillåter inte vem som helst att hämta kontodata eller initiera betalningar. Den som vill göra det i skarp drift måste vara en registrerad tredjepartsleverantör, en så kallad TPP, och tillståndet utfärdas av den nationella tillsynsmyndigheten. I Sverige är det Finansinspektionen.
Vilket tillstånd du behöver beror på vad din tjänst gör:
- Kontoinformationstjänst (AISP). Krävs om din tjänst läser kontouppgifter, till exempel saldon och transaktioner. För AISP räcker en registrering hos Finansinspektionen.
- Betalningsinitieringstjänst (PISP). Krävs om din tjänst initierar betalningar för användarens räkning. Här krävs ett auktorisationsbeslut, inte bara en registrering, eftersom verksamheten innebär att hantera betalningar.
Det är ingen formalitet som klaras av över en helg. Finansinspektionen prövar bland annat bolagets ägare, ledning, interna styrning och hur kunddata skyddas. För ett tidigt team är det här ofta den längsta ledtiden i hela projektet, och något att starta parallellt med utvecklingen i stället för efter den.
Tröskel två: eIDAS-certifikat från en betrodd utfärdare
Tillståndet ensamt öppnar inte porten till bankens produktionsmiljö. Banken måste tekniskt kunna lita på att den som anropar API:et verkligen är den registrerade aktören. Det löses med kvalificerade certifikat enligt eIDAS-förordningen, utfärdade av en kvalificerad betrodd tjänsteleverantör (QTSP). Två certifikattyper är aktuella:
- QWAC (Qualified Website Authentication Certificate) upprättar en säker, ömsesidigt autentiserad TLS-kanal mellan din tjänst och banken, så att banken kan identifiera dig som TPP.
- QSealC (Qualified Electronic Seal Certificate) försluter själva datan och ger ett rättsligt hållbart bevis på att meddelandet kommer från dig och inte har ändrats på vägen.
Certifikaten ska följa den europeiska standarden ETSI TS 119495, som beskriver hur en TPP:s roll och tillståndsnummer bäddas in i certifikatet. Nordea pekar i sin egen kravdokumentation särskilt ut QSealC-certifikatet som en del av kompabilitetssteget innan produktionsåtkomst beviljas. Värt att notera för den som följer certifikatmarknaden: sedan den sjunde april 2025 tas det så kallade Client Authentication EKU bort ur vanliga eIDAS QWAC-certifikat, men PSD2-profilen för QWAC behåller det, eftersom det krävs för just den här typen av bankintegrationer. Beställ alltså rätt certifikatprofil, inte ett generiskt webbcertifikat.
Hur autentiseringen faktiskt går till i skarpt läge
När tillstånd och certifikat är på plats styr PSD2:s tekniska standard, RTS, hur den enskilde kundens samtycke hämtas. Kravet kallas stark kundautentisering (SCA) och bygger på minst två av tre oberoende faktorer: något kunden vet, något kunden har och något kunden är.
I praktiken sker det genom ett omdirigeringsflöde med OAuth 2.0. Din tjänst skickar kunden vidare till Nordeas inloggning, kunden legitimerar sig hos banken, och din tjänst får tillbaka en auktorisationskod som växlas mot en åtkomsttoken. Du hanterar alltså aldrig kundens bankinloggning själv. Ett samtycke har dessutom begränsad livslängd, så en kontoinformationstjänst måste be kunden förnya sitt godkännande med jämna mellanrum i stället för att läsa data hur länge som helst.
En realistisk tidslinje
Det utvecklingsarbete som syns i en demo är ofta den minsta delen av projektet. En grov bild av vad som faktiskt tar tid:
- Sandbox och prototyp. Dagar till veckor. Här bygger och testar du flödet fritt.
- Tillstånd hos Finansinspektionen. Veckor till månader, beroende på tjänstetyp och hur väl ansökan är förberedd.
- Beställning av eIDAS-certifikat. Dagar till veckor hos en QTSP, ofta med identitetskontroll av bolaget.
- Produktionsgodkännande hos banken. Det avslutande steget där certifikat och tillstånd verifieras innan trafik mot riktiga konton släpps fram.
Slutsatsen för den som planerar en integration är att lägga kraften på rätt ställe. Tekniken bakom Nordeas gränssnitt är väldokumenterad och förutsägbar. Det som avgör tidsplanen är de regulatoriska stegen, tillståndet och certifikaten, och de bör startas tidigt och drivas parallellt med kodandet. Den som förstår det redan vid projektstart slipper den vanligaste överraskningen: att den färdiga koden får vänta veckor på ett godkännande som kunde ha varit klart.