PSD2 och öppen bankverksamhet i Finland: API-infrastruktur, SCA och SEPA-direktöverföringar

Det andra betaltjänstdirektivet (PSD2) gjorde bankkontot till ett gränssnitt: kreditinstitut måste ge reglerade tredje parter åtkomst till betalkonton, och betalare måste autentisera sig starkt. Parallellt har SEPA-direktöverföringar (SCT Inst) gått från en frivillig tjänst till grundläggande infrastruktur i euroområdet genom förordningen om direktbetalningar (EU) 2024/886.

Den här artikeln beskriver den tekniska gränsen mellan de två skikten: vilka uppgifter som utbyts vid stark kundautentisering (SCA), hur en auktoriserad betalningsinitiering passerar genom API:t och hur en direktöverföring avvecklas i centralbankspengar eller förfinansierade medel inom tio sekunder. Perspektivet är finskt, men mekanismerna är gemensamma för hela Europa.

Regelverk

Regelverket består av tre nivåer:

• Direktiv (EU) 2015/2366 (PSD2) definierar betalningsinitieringstjänster (PIS) och kontoinformationstjänster (AIS) samt skyldigheten att tillämpa stark kundautentisering (art. 97).
• Kommissionens delegerade förordning (EU) 2018/389, de tekniska tillsynsstandarderna (RTS) för SCA och gemensam och säker kommunikation (CSC), fastställer de tekniska kraven på autentisering, undantagen och kommunikationsreglerna mellan kontoförvaltare (ASPSP) och tredjepartsleverantörer (TPP). Den tillämpas sedan den 14 september 2019 och har ändrats genom delegerad förordning (EU) 2022/2360.
• Nationellt genomförande: Finland genomförde direktivet huvudsakligen genom ändringar i lagen om betaltjänster (290/2010) och lagen om betalningsinstitut (297/2010), som trädde i kraft den 13 januari 2018. Behörig myndighet är Finansinspektionen (FIN-FSA).

För direktbetalningar är de viktigaste källorna SEPA-förordningen (EU) 260/2012, ändringen av den genom förordningen om direktbetalningar (EU) 2024/886 samt Europeiska betalningsrådets (EPC) regelböcker för SCT Inst och Verification of Payee (VoP).

Parametrar för datautbyte vid SCA

Autentiseringsfaktorer

SCA kräver minst två oberoende faktorer från tre kategorier: kunskap (t.ex. en PIN-kod), innehav (t.ex. en registrerad mobil enhet eller ett kort) och inneboende egenskap (t.ex. ett fingeravtryck). Oberoende innebär att om en faktor komprometteras får det inte försämra tillförlitligheten hos de övriga (RTS art. 9). Om faktorerna används på en enhet med flera användningsområden, till exempel en smarttelefon, måste enheten erbjuda separata säkra exekveringsmiljöer.

Krav på autentiseringskoden

Artikel 4 i RTS fastställer följande parametrar för den kod som autentiseringen ger upphov till:

• ingen information om faktorerna kan härledas ur koden, och en ny kod kan inte skapas utifrån kännedom om tidigare koder
• högst fem misslyckade försök i följd, varefter åtgärden spärras tillfälligt eller permanent
• högst fem minuters inaktivitet efter autentiseringen innan sessionen avslutas
• processen avslöjar inte vilken faktor som var felaktig

Dynamisk länkning

Vid distansbetalningar måste koden vara knuten till beloppet och betalningsmottagaren (RTS art. 5). Betalaren ska få se båda under autentiseringen, och varje ändring av dem gör koden ogiltig. Vid samlingsbetalningar knyts koden till det totala beloppet och samtliga mottagare. På API-nivå innebär det att fälten instructedAmount och creditorAccount måste låsas innan SCA startar, och att TPP måste skapa en ny initiering om de ändras.

Undantag

RTS tillåter undantag från SCA. Att tillämpa ett undantag är alltid betalarens betaltjänstleverantörs (ASPSP) beslut.

Tröskelvärdena för TRA (bilagan till RTS) beror på betaltjänstleverantörens bedrägerinivå per kvartal:

Gemensam och säker kommunikation (CSC)

Identifiering av parterna med eIDAS-certifikat

Artikel 34 i RTS kräver att betaltjänstleverantörer identifierar varandra med kvalificerade eIDAS-certifikat. I praktiken visar TPP ett QWAC-certifikat (Qualified Website Authentication Certificate) i transportskiktet för ömsesidig TLS, och kan signera meddelanden på applikationsnivå med ett QSealC-certifikat (Qualified Electronic Seal Certificate). Certifikatet innehåller det tillståndsnummer som den nationella tillsynsmyndigheten utfärdat och PSD2-rollerna: PSP_AS, PSP_PI, PSP_AI och PSP_IC.

Särskilt gränssnitt och reservlösning

En ASPSP kan erbjuda åtkomst via sitt kundgränssnitt eller via ett särskilt gränssnitt (dedicated interface). Det särskilda gränssnittet måste motsvara kundkanalen i tillgänglighet och prestanda, och statistiken ska offentliggöras kvartalsvis (art. 32). Om inte den nationella tillsynsmyndigheten har beviljat undantag måste ASPSP upprätthålla en reservlösning (art. 33).

SCA-modeller i gränssnittet

Den mest refererade europeiska API-standarden är Berlin Groups ramverk NextGenPSD2 XS2A. De finska bankernas implementationer varierar: vissa följer Berlin Group-modellen, andra egna eller nordiska varianter. De vanliga SCA-modellerna är:

• Redirect: TPP skickar användaren till bankens egen autentiseringsmiljö och tillbaka (TPP-Redirect-URI). Den vanligaste modellen i Finland.
• Decoupled: autentiseringen sker i bankens mobilapp, separat från TPP:s gränssnitt; TPP frågar efter status.
• Embedded: inloggningsuppgifterna passerar genom TPP:s gränssnitt. Ovanligt av säkerhetsskäl.
• OAuth2: används ofta som ett förstadium till redirect eller som auktoriseringsmekanism.

Typiska parametrar för datautbyte

Exempel på innehållet i ett samtycke till kontoinformation (Berlin Group-stil):

POST /v1/consents
X-Request-ID: 6f1c2a9e-3b7d-4e1a-9c55-2d8f0b7a41e2
PSU-IP-Address: 192.0.2.10
TPP-Redirect-URI: https://tpp.example/cb

{
  "access": {
    "accounts":     [{ "iban": "FI2112345600000785" }],
    "balances":     [{ "iban": "FI2112345600000785" }],
    "transactions": [{ "iban": "FI2112345600000785" }]
  },
  "recurringIndicator": true,
  "validUntil": "2027-04-05",
  "frequencyPerDay": 4,
  "combinedServiceIndicator": false
}

Utan att användaren aktivt begär det får en AISP hämta uppgifter högst fyra gånger per dygn, om inget annat har avtalats (RTS art. 36.5). Värdet frequencyPerDay: 4 återspeglar den gränsen.

Den finska autentiseringsmiljön

I Finland regleras stark elektronisk identifiering av lagen om stark autentisering och betrodda elektroniska tjänster (617/2009). Bankkoder och mobilcertifikat (mobiilivarmenne) fungerar som identifieringsverktyg inom Förtroendenätet, som övervakas av Traficom.

Ur arkitektursynpunkt är det viktigt att skilja mellan två användningsfall som ofta delar samma användarupplevelse:

• Identitetskontroll för en tredje parts tjänst (Förtroendenätet, lag 617/2009).
• Auktorisering av betalning eller åtkomst till konto i bankens egen miljö (PSD2-SCA, förordning 2018/389), där dynamisk länkning gäller transaktionen.

Finska banker har i stor utsträckning flyttat SCA till sina egna mobilappar (innehav plus PIN-kod eller biometri), vilket gör redirect- och decoupled-flöden till de dominerande mönstren i praktiken.

SEPA-direktöverföringar (SCT Inst)

EPC:s system SCT Inst lanserades i november 2017. Förordningen om direktbetalningar (EU) 2024/886 gjorde direktöverföringar obligatoriska: betaltjänstleverantörer i euroområdet måste kunna ta emot direktöverföringar från den 9 januari 2025 och skicka dem samt erbjuda Verification of Payee (VoP) från den 9 oktober 2025. Som medlem i euroområdet omfattas Finland av dessa tidsfrister.

Det tidigare högsta beloppet på systemnivå i EPC:s regelbok (100 000 € från 2020) har tagits bort för att stämma överens med förordningen. Kontrollera gällande version av regelboken före implementering.

Avveckling i realtid

Meddelandeflöde

1. Betalaren auktoriserar betalningen med SCA (i bankens kanal eller via en PISP). Betalarens bank kontrollerar täckningen, beaktar VoP-resultatet och reserverar beloppet.
2. Betalarens bank skickar ett tidsstämplat pacs.008 till clearing- och avvecklingssystemet (CSM).
3. CSM validerar meddelandet och vidarebefordrar det till mottagarens bank.
4. Mottagarens bank kontrollerar kontot och svarar med ett pacs.002 (godkänt eller avvisat).
5. Vid positivt svar avvecklar CSM transaktionen och bekräftar den till båda parter. Mottagarens bank krediterar medlen omedelbart.
6. I PSD2-API:t ändras statusen till exempel från ACTC till ACSC eller ACCC.

Avvecklingssystem

• TIPS (TARGET Instant Payment Settlement): Eurosystemets tjänst, i drift sedan 2018. Avvecklingen sker i centralbankspengar på deltagarnas särskilda TIPS-konton (DCA) som finansieras från T2. Avvecklingen är slutgiltig och oåterkallelig så snart den bokförts.
• RT1 (EBA CLEARING): ett privat paneuropeiskt system, i drift sedan 2017. Deltagarna förfinansierar sina positioner i centralbankspengar i T2, och systemet avvecklar transaktionerna mot dessa positioner.

Genom Eurosystemets åtgärder för nåbarhet måste banker som anslutit sig till SCT Inst och som är nåbara i T2 också vara nåbara via TIPS, vilket möjliggör routning i hela euroområdet.

Likviditetsstyrning

Eftersom direktöverföringar avvecklas dygnet runt mot förfinansierade saldon flyttas likviditetsprognoserna från intradagliga batchjobb till en kontinuerlig process. Bankerna måste dimensionera sin TIPS- eller RT1-finansiering särskilt för helger och helgdagar, då möjligheterna att överföra likviditet från RTGS-systemet är mer begränsade.

Returer och återkallelser

En avvisad transaktion (RJCT) avvecklas aldrig. En återkallelse av en avvecklad transaktion (camt.056) är möjlig inom regelbokens tidsgräns, till exempel vid en dubblerad eller bedräglig betalning, men mottagarens bank är inte skyldig att återbetala medel utan grund. Returer görs med pacs.004 och negativa svar med camt.029.

Arkitekturöverväganden

• Idempotens: använd X-Request-ID och end-to-end-identifieraren för att förhindra dubbla initieringar efter timeouter.
• Tillståndsmaskiner: modellera scaStatus och transactionStatus som separata tillståndsmaskiner; en direktöverföring kan nå sitt slutliga tillstånd på några sekunder, medan en vanlig SEPA-överföring kan ligga kvar i ACTC längre.
• Förfrågningar kontra aviseringar: många ASPSP:er stöder endast statusförfrågningar; dimensionera frekvensen enligt gränssnittets användarvillkor.
• Avstämning: använd camt.054-aviseringar och camt.053-kontoutdrag för att stämma av realtidsstatus mot bokförd status.
• Kontinuerlig drift: avveckling dygnet runt kräver också övervakning, jour och bedrägeribekämpning dygnet runt.
• Certifikatens livscykel: automatisera förnyelsen av QWAC- och QSealC-certifikat och övervaka giltighet och spärrstatus.

Europeiska kommissionens förslag från 2023 till ett PSD3-direktiv och en betaltjänstförordning (PSR) kommer sannolikt att ändra kraven på gränssnitt och SCA-praxis. Kontrollera var lagstiftningsprocessen befinner sig i aktuella källor.

Källor

1. Direktiv (EU) 2015/2366 om betaltjänster på den inre marknaden (PSD2).
2. Kommissionens delegerade förordning (EU) 2018/389 (RTS för stark kundautentisering och gemensamma och säkra öppna kommunikationsstandarder).
3. Kommissionens delegerade förordning (EU) 2022/2360 (ändring av 2018/389; 180-dagarsundantaget för kontoinformation).
4. Förordning (EU) 2024/886 om direktöverföringar i euro (förordningen om direktbetalningar).
5. Förordning (EU) nr 260/2012 (SEPA-förordningen).
6. Finlands lag om betaltjänster (290/2010) och lag om betalningsinstitut (297/2010).
7. Finlands lag om stark autentisering och betrodda elektroniska tjänster (617/2009).
8. European Payments Council: SEPA Instant Credit Transfer Scheme Rulebook; Verification of Payee Scheme Rulebook.
9. The Berlin Group: NextGenPSD2 XS2A Framework, Implementation Guidelines.
10. Europeiska centralbanken: dokumentation för TARGET Instant Payment Settlement (TIPS).

Denna publikation är en allmän informationsöversikt och utgör inte juridisk rådgivning. Regelverk och systemens regelböcker uppdateras regelbundet; kontrollera gällande versioner i primära källor.