PSD2 i otwarta bankowość w Finlandii: infrastruktura API, SCA i natychmiastowe przelewy SEPA

Druga dyrektywa w sprawie usług płatniczych (PSD2) uczyniła z rachunku bankowego interfejs: instytucje kredytowe muszą zapewniać regulowanym podmiotom trzecim dostęp do rachunków płatniczych, a płatnicy muszą stosować silne uwierzytelnianie. Równolegle natychmiastowe polecenia przelewu SEPA (SCT Inst) przeszły od usługi opcjonalnej do podstawowej infrastruktury strefy euro na mocy rozporządzenia w sprawie płatności natychmiastowych (UE) 2024/886.

Artykuł opisuje techniczną granicę między tymi dwiema warstwami: jakie dane są wymieniane podczas silnego uwierzytelniania klienta (SCA), jak autoryzowane zlecenie płatnicze przechodzi przez API i jak przelew natychmiastowy jest rozliczany w pieniądzu banku centralnego lub w środkach wcześniej zabezpieczonych w ciągu dziesięciu sekund. Perspektywa jest fińska, ale mechanizmy są ogólnoeuropejskie.

Ramy regulacyjne

Ramy składają się z trzech poziomów:

• Dyrektywa (UE) 2015/2366 (PSD2) definiuje usługi inicjowania płatności (PIS) i usługi dostępu do informacji o rachunku (AIS) oraz obowiązek stosowania silnego uwierzytelniania klienta (art. 97).
• Rozporządzenie delegowane Komisji (UE) 2018/389, czyli regulacyjne standardy techniczne (RTS) dotyczące SCA oraz wspólnej i bezpiecznej komunikacji (CSC), określa techniczne wymogi uwierzytelniania, wyjątki oraz zasady komunikacji między dostawcami prowadzącymi rachunki (ASPSP) a dostawcami zewnętrznymi (TPP). Stosuje się je od 14 września 2019 r.; zostało zmienione rozporządzeniem delegowanym (UE) 2022/2360.
• Transpozycja krajowa: Finlandia wdrożyła dyrektywę głównie poprzez zmiany ustawy o usługach płatniczych (290/2010) i ustawy o instytucjach płatniczych (297/2010), które weszły w życie 13 stycznia 2018 r. Właściwym organem jest fiński Urząd Nadzoru Finansowego (FIN-FSA).

W zakresie płatności natychmiastowych kluczowymi źródłami są rozporządzenie SEPA (UE) 260/2012, jego zmiana wprowadzona rozporządzeniem w sprawie płatności natychmiastowych (UE) 2024/886 oraz zasady (rulebooki) Europejskiej Rady ds. Płatności (EPC) dla SCT Inst i Verification of Payee (VoP).

Parametry wymiany danych przy SCA

Elementy uwierzytelniania

SCA wymaga co najmniej dwóch niezależnych elementów z trzech kategorii: wiedza (np. PIN), posiadanie (np. zarejestrowane urządzenie mobilne lub karta) oraz cechy klienta (np. odcisk palca). Niezależność oznacza, że naruszenie jednego elementu nie może osłabiać wiarygodności pozostałych (RTS art. 9). Jeżeli elementy są używane na urządzeniu wielofunkcyjnym, takim jak smartfon, urządzenie musi zapewniać odrębne bezpieczne środowiska wykonawcze.

Wymogi dotyczące kodu uwierzytelniania

Artykuł 4 RTS określa następujące parametry kodu generowanego w procesie uwierzytelniania:

• z kodu nie można wywnioskować informacji o elementach, a nowego kodu nie można wygenerować na podstawie znajomości poprzednich
• maksymalnie pięć kolejnych nieudanych prób, po których czynność jest blokowana tymczasowo lub na stałe
• maksymalnie pięć minut bezczynności po uwierzytelnieniu, zanim sesja zostanie zakończona
• proces nie ujawnia, który element był nieprawidłowy

Dynamiczne powiązanie

W przypadku zdalnych transakcji płatniczych kod musi być powiązany z kwotą i odbiorcą (RTS art. 5). Płatnik musi widzieć oba te elementy podczas uwierzytelniania, a każda ich zmiana unieważnia kod. W przypadku płatności zbiorczych kod jest powiązany z łączną kwotą i wszystkimi odbiorcami. Na poziomie API oznacza to, że pola instructedAmount i creditorAccount muszą zostać zablokowane przed rozpoczęciem SCA, a TPP musi utworzyć nowe zlecenie, jeśli ulegną zmianie.

Wyjątki

RTS dopuszczają wyjątki od SCA. Decyzja o zastosowaniu wyjątku zawsze należy do dostawcy usług płatniczych płatnika (ASPSP).

Progi TRA (załącznik do RTS) zależą od kwartalnego wskaźnika oszustw dostawcy usług płatniczych:

Wspólna i bezpieczna komunikacja (CSC)

Identyfikacja stron za pomocą certyfikatów eIDAS

Artykuł 34 RTS wymaga, aby dostawcy usług płatniczych identyfikowali się wzajemnie za pomocą kwalifikowanych certyfikatów eIDAS. W praktyce TPP przedstawia w warstwie transportowej certyfikat QWAC (Qualified Website Authentication Certificate) do wzajemnego TLS i może podpisywać komunikaty na poziomie aplikacji certyfikatem QSealC (Qualified Electronic Seal Certificate). Certyfikat zawiera numer zezwolenia nadany przez krajowy organ nadzoru oraz role PSD2: PSP_AS, PSP_PI, PSP_AI i PSP_IC.

Dedykowany interfejs i mechanizm awaryjny

ASPSP może zapewniać dostęp przez interfejs klienta lub przez dedykowany interfejs (dedicated interface). Dedykowany interfejs musi dorównywać kanałowi klienta pod względem dostępności i wydajności, a statystyki muszą być publikowane kwartalnie (art. 32). O ile krajowy organ nadzoru nie udzielił zwolnienia, ASPSP musi utrzymywać mechanizm awaryjny (art. 33).

Modele SCA w interfejsie

Najczęściej stosowanym europejskim standardem API są ramy NextGenPSD2 XS2A Berlin Group. Wdrożenia fińskich banków są zróżnicowane: część stosuje model Berlin Group, inne rozwiązania własne lub nordyckie. Typowe modele SCA to:

• Redirect: TPP przekierowuje użytkownika do środowiska uwierzytelniania banku i z powrotem (TPP-Redirect-URI). Najczęstszy model w Finlandii.
• Decoupled: uwierzytelnianie odbywa się w aplikacji mobilnej banku, niezależnie od interfejsu TPP; TPP odpytuje o status.
• Embedded: dane uwierzytelniające przechodzą przez interfejs TPP. Rzadki ze względów bezpieczeństwa.
• OAuth2: często stosowany jako etap wstępny przekierowania lub jako mechanizm autoryzacji.

Typowe parametry wymiany danych

Przykładowa treść zgody na dostęp do informacji o rachunku (styl Berlin Group):

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
}

Bez aktywnego żądania użytkownika AISP może pobierać dane najwyżej cztery razy na dobę, o ile nie uzgodniono inaczej (RTS art. 36 ust. 5). Wartość frequencyPerDay: 4 odzwierciedla ten limit.

Fiński ekosystem uwierzytelniania

W Finlandii silną identyfikację elektroniczną reguluje ustawa o silnej identyfikacji elektronicznej i usługach zaufania (617/2009). Dane logowania do banku i certyfikat mobilny (mobiilivarmenne) służą jako środki identyfikacji w fińskiej Sieci Zaufania (Luottamusverkosto), nadzorowanej przez Traficom.

Z punktu widzenia architektury ważne jest rozróżnienie dwóch przypadków użycia, które często mają to samo doświadczenie użytkownika:

• Weryfikacja tożsamości na potrzeby usługi podmiotu trzeciego (Sieć Zaufania, ustawa 617/2009).
• Autoryzacja płatności lub dostęp do rachunku w środowisku banku (SCA w ramach PSD2, rozporządzenie 2018/389), gdzie dynamiczne powiązanie dotyczy transakcji.

Fińskie banki w dużej mierze przeniosły SCA do własnych aplikacji mobilnych (posiadanie plus PIN lub biometria), przez co w praktyce dominują przepływy redirect i decoupled.

Natychmiastowe polecenia przelewu SEPA (SCT Inst)

Schemat SCT Inst EPC wystartował w listopadzie 2017 r. Rozporządzenie w sprawie płatności natychmiastowych (UE) 2024/886 uczyniło przelewy natychmiastowe obowiązkowymi: dostawcy usług płatniczych w strefie euro musieli być w stanie odbierać przelewy natychmiastowe od 9 stycznia 2025 r., a wysyłać je i oferować Verification of Payee (VoP) od 9 października 2025 r. Jako członek strefy euro Finlandia podlega tym terminom.

Wcześniejsza maksymalna kwota na poziomie schematu w rulebooku EPC (100 000 € od 2020 r.) została usunięta w celu dostosowania do rozporządzenia. Przed wdrożeniem sprawdź aktualną wersję rulebooka.

Rozrachunek w czasie rzeczywistym

Przepływ komunikatów

1. Płatnik autoryzuje płatność za pomocą SCA (w kanale banku lub przez PISP). Bank płatnika sprawdza dostępność środków, uwzględnia wynik VoP i blokuje kwotę.
2. Bank płatnika wysyła komunikat pacs.008 ze znacznikiem czasu do systemu rozliczeniowego (CSM).
3. CSM weryfikuje komunikat i przekazuje go do banku odbiorcy.
4. Bank odbiorcy sprawdza rachunek i odpowiada komunikatem pacs.002 (przyjęty lub odrzucony).
5. Po pozytywnej odpowiedzi CSM rozlicza transakcję i potwierdza ją obu stronom. Bank odbiorcy natychmiast uznaje rachunek.
6. W API PSD2 status zmienia się na przykład z ACTC na ACSC lub ACCC.

Systemy rozrachunkowe

• TIPS (TARGET Instant Payment Settlement): usługa Eurosystemu działająca od 2018 r. Rozrachunek odbywa się w pieniądzu banku centralnego na dedykowanych rachunkach TIPS uczestników (DCA), zasilanych z T2. Rozrachunek jest ostateczny i nieodwołalny z chwilą zaksięgowania.
• RT1 (EBA CLEARING): prywatny system ogólnoeuropejski działający od 2017 r. Uczestnicy z góry zasilają swoje pozycje w pieniądzu banku centralnego w T2, a system rozlicza transakcje w ciężar tych pozycji.

Na mocy działań Eurosystemu dotyczących osiągalności banki przystępujące do SCT Inst i osiągalne w T2 muszą być również osiągalne przez TIPS, co umożliwia routing w całej strefie euro.

Zarządzanie płynnością

Ponieważ przelewy natychmiastowe są rozliczane całodobowo w ciężar wcześniej zasilonych sald, prognozowanie płynności przechodzi z dziennych procesów wsadowych w proces ciągły. Banki muszą odpowiednio dobrać zasilenie TIPS lub RT1 zwłaszcza na weekendy i święta, gdy możliwości przenoszenia płynności z systemu RTGS są bardziej ograniczone.

Zwroty i odwołania

Odrzucona transakcja (RJCT) nigdy nie zostaje rozliczona. Odwołanie rozliczonej transakcji (camt.056) jest możliwe w terminie określonym w rulebooku, np. w przypadku płatności zdublowanej lub oszukańczej, ale bank odbiorcy nie jest zobowiązany do zwrotu środków bez podstawy. Zwroty realizuje się komunikatem pacs.004, a odpowiedzi negatywne komunikatem camt.029.

Uwagi architektoniczne

• Idempotentność: używaj X-Request-ID i identyfikatora end-to-end, aby zapobiegać zdublowanym zleceniom po przekroczeniu limitu czasu.
• Maszyny stanów: modeluj scaStatus i transactionStatus jako osobne maszyny stanów; przelew natychmiastowy może osiągnąć stan końcowy w kilka sekund, a standardowy przelew SEPA może dłużej pozostawać w stanie ACTC.
• Odpytywanie a powiadomienia: wielu ASPSP obsługuje wyłącznie odpytywanie o status; dobierz częstotliwość zgodnie z warunkami korzystania z interfejsu.
• Uzgadnianie: wykorzystuj powiadomienia camt.054 i wyciągi camt.053 do uzgadniania stanu bieżącego ze stanem zaksięgowanym.
• Ciągłość działania: rozrachunek 24/7 wymaga również całodobowego monitoringu, dyżurów i przeciwdziałania oszustwom.
• Cykl życia certyfikatów: automatyzuj odnawianie certyfikatów QWAC i QSealC oraz monitoruj ich ważność i status unieważnienia.

Propozycje Komisji Europejskiej z 2023 r. dotyczące dyrektywy PSD3 i rozporządzenia w sprawie usług płatniczych (PSR) prawdopodobnie zmienią wymogi dotyczące interfejsów i praktyki SCA. Aktualny etap procesu legislacyjnego warto sprawdzić w bieżących źródłach.

Źródła

1. Dyrektywa (UE) 2015/2366 w sprawie usług płatniczych w ramach rynku wewnętrznego (PSD2).
2. Rozporządzenie delegowane Komisji (UE) 2018/389 (RTS dotyczące silnego uwierzytelniania klienta oraz wspólnych i bezpiecznych otwartych standardów komunikacji).
3. Rozporządzenie delegowane Komisji (UE) 2022/2360 (zmiana 2018/389; 180-dniowy wyjątek dla informacji o rachunku).
4. Rozporządzenie (UE) 2024/886 w sprawie natychmiastowych poleceń przelewu w euro (rozporządzenie w sprawie płatności natychmiastowych).
5. Rozporządzenie (UE) nr 260/2012 (rozporządzenie SEPA).
6. Fińska ustawa o usługach płatniczych (290/2010) i ustawa o instytucjach płatniczych (297/2010).
7. Fińska ustawa o silnej identyfikacji elektronicznej i usługach zaufania (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. Europejski Bank Centralny: dokumentacja TARGET Instant Payment Settlement (TIPS).

Niniejsza publikacja ma charakter ogólnego przeglądu informacyjnego i nie stanowi porady prawnej. Przepisy i rulebooki schematów są okresowo aktualizowane; sprawdź obowiązujące wersje w źródłach pierwotnych.