Jednym z trwałych problemów polskiego rynku płatniczego jest tzw. debanking — odmowa otwarcia rachunku przez bank dla krajowej instytucji płatniczej (KIP), agenta KIP albo wnioskodawcy o licencję. Art. 36 ust. 5 dyrektywy 2015/2366 (PSD2) wymagał już od państw członkowskich zapewnienia, by instytucje kredytowe udostępniały rachunek instytucjom płatniczym na zasadach proporcjonalnych, obiektywnych i niedyskryminujących, ale praktyka — w tym ta znana nam z postępowań przed KNF — pokazała, że przepis był zbyt miękki. Projekt rozporządzenia PSR (dokument Rady 8221/26 z 17 kwietnia 2026 r.) zaostrza te wymogi w art. 32 i obudowuje je narzędziami egzekucji.
Równolegle — w ramach tego samego rozdziału (art. 33–48 PSR) — zmienia się ramowa logika open bankingu. Niżej omawiamy obie zmiany razem, bo z perspektywy KIP dostęp do rachunku w banku i dostęp do dedykowanego API to dwie strony tej samej kwestii operacyjnej. Wpis warto czytać razem z artykułem o konsolidacji licencji KIP/MIP/EMI oraz o weryfikacji odbiorcy w każdym poleceniu przelewu.
Czego dotyczy art. 32 PSR?
Art. 32 ust. -1 PSR stanowi, że instytucje kredytowe udostępniają rachunki płatnicze instytucjom płatniczym, ich agentom i wnioskodawcom o autoryzację jako instytucji płatniczej na zasadach obiektywnych, niedyskryminujących i proporcjonalnych. Co istotne — dostęp ma być „sufficiently extensive as to allow payment institutions to provide payment services in an unhindered and efficient manner”. To nie jest dowolny rachunek bieżący — bank musi zapewnić zakres usług umożliwiający efektywne świadczenie usług płatniczych.
Art. 32 ust. 1 PSR wyczerpująco wylicza powody, dla których bank może odmówić otwarcia lub może zamknąć rachunek:
| Podstawa odmowy | Treść (skrót) |
|---|---|
| art. 32 ust. 1 lit. a PSR | Otwarcie lub utrzymanie rachunku skutkowałoby naruszeniem rozporządzenia 2024/1624 (AML). |
| art. 32 ust. 1 lit. b PSR | Doszło lub doszłoby do istotnego naruszenia umowy przez instytucję płatniczą lub jej agenta. |
| art. 32 ust. 1 lit. c PSR | Wnioskodawca nie przekazał odpowiednich informacji lub dokumentów. |
| art. 32 ust. 1 lit. ea PSR | Właściwy organ odmówił udzielenia lub cofnął zezwolenie instytucji płatniczej. |
Lista jest zamknięta. Bank nie może odmówić z innych przyczyn — przykładowo z uwagi na wewnętrzny apetyt na ryzyko, ogólne polityki risk-based wobec sektora fintech albo nieformalne wytyczne.
Procedura — terminy i obowiązek uzasadnienia
Art. 32 ust. 3 PSR wprowadza twarde ramy proceduralne:
- decyzja w terminie maksymalnie 1 miesiąca od otrzymania kompletnego wniosku o otwarcie rachunku — co istotne, decyzja musi być przekazana zarówno instytucji płatniczej (lub agentowi/wnioskodawcy), jak i właściwemu organowi nadzoru,
- uzasadnienie ma być specyficzne dla ryzyk konkretnej działalności tej KIP lub jej agenta (assessed by the credit institution), oparte na przesłankach z art. 32 ust. 1 PSR i nie być generyczne,
- zamknięcie rachunku — co najmniej 4 miesiące wypowiedzenia przed faktycznym zamknięciem; uzasadnienie również specyficzne i oparte na przesłankach z art. 32 ust. 1 PSR; bank musi uwzględnić zdolność KIP do utrzymania safeguardingu (art. 9 PSD3) po zamknięciu rachunku.
Wyjątek dotyczy odmów z przesłanki AML (art. 32 ust. 1 lit. a PSR). W tym przypadku bank:
- informuje wnioskodawcę o naruszeniu rozporządzenia 2024/1624, ale nie ujawnia szczegółów charakteru naruszenia,
- może zastosować krótszy okres wypowiedzenia rachunku.
Art. 32 ust. 4 PSR daje KIP, agentowi lub wnioskodawcy prawo zaskarżenia negatywnej decyzji do właściwego organu. To oznacza, że KNF — jako właściwy organ — będzie miała narzędzie nie tylko do nadzoru, ale i do bezpośredniej oceny zasadności odmowy. Z naszego doświadczenia w postępowaniach licencyjnych była to dotychczas największa luka: KNF mogła pośrednio zachęcać banki do otwarcia rachunku, ale nie miała narzędzia formalnego rozpatrzenia odwołania. PSR tę lukę zamyka.
Co więcej — art. 32 ust. 3a PSR upoważnia właściwy organ do publikowania zagregowanych danych o odmowach i zamknięciach. Dla rynku to istotny sygnał transparentności — naszym zdaniem dane te będą publikowane co najmniej raz na rok (na wzór raportu UKNF o sektorze KIP), choć ostateczny standard ma określić EBA w regulacyjnych standardach technicznych z art. 32 ust. 5 PSR.
Open banking — nowy reżim API
Drugi obszar, który zmienia się równolegle, to dedykowany interfejs dostępu do danych. Art. 35 PSR zachowuje wymóg, by każdy ASPSP oferujący online rachunek płatniczy posiadał co najmniej jeden dedykowany interfejs do wymiany danych z dostawcami usługi dostępu do informacji o rachunku (AISP) i dostawcami usługi inicjowania transakcji płatniczej (PISP). Co warto zauważyć — w przeciwieństwie do PSD2 i art. 31 rozporządzenia delegowanego 2018/389, gdzie ASPSP mógł wybrać między dedykowanym interfejsem a dostosowanym interfejsem klienta (i obok dedykowanego interfejsu utrzymywać mechanizm fallback), art. 35 ust. 1 PSR jednoznacznie wymaga dedykowanego interfejsu. Wyjątki przewiduje art. 39 PSR (derogacja na wniosek), ale są one wąskie i wymagają decyzji właściwego organu z uwzględnieniem m.in. wielkości i obrotów ASPSP.
Najważniejsze zmiany w obowiązkach po stronie ASPSP:
- 3 miesiące od autoryzacji — termin uruchomienia dedykowanego interfejsu (art. 35 ust. 2 PSR),
- 2 miesiące uprzedzenia przy każdej zmianie specyfikacji technicznej (z wyjątkiem zmian awaryjnych) — art. 35 ust. 4 PSR,
- kwartalne statystyki dostępności i wydajności publikowane na stronie ASPSP wraz z porównaniem do interfejsu klienta (art. 35 ust. 5 PSR),
- środowisko testowe ze wsparciem — udostępniane bezpłatnie autoryzowanym AISP/PISP oraz wnioskodawcom (art. 35 ust. 6 PSR),
- parytet danych — art. 37 PSR: dedykowany interfejs ma dostarczać AISP-om co najmniej te same informacje, które są dostępne dla klienta w bezpośrednim interfejsie (z wyłączeniem sensitive payment data), a PISP-om — co najmniej te same informacje o inicjacji i wykonaniu transakcji,
- dostępność i wydajność — art. 38 PSR: niedostępność uznaje się za nastąpioną, jeżeli pięć kolejnych żądań w ciągu 30 sekund otrzyma błąd serwera; planowane przerwy zwykle 00:00–06:00 i z wyprzedzeniem co najmniej 1 miesiąca,
- funkcjonalności PISP — art. 36 ust. 4 PSR: m.in. zlecenia stałe, płatności jednorazowe, płatności z datą przyszłą, płatności do wielu odbiorców, weryfikacja nazwy posiadacza rachunku przed inicjacją, wybór procedury uwierzytelniania spośród oferowanych przez ASPSP.
Co warto pamiętać — art. 36 ust. 5a PSR wprost stanowi, że nazwa posiadacza rachunku oraz unikalny identyfikator rachunku nie stanowią wrażliwych danych dotyczących płatności dla potrzeb działalności PISP i AISP. To rozwiązanie usuwa wątpliwości, które utrzymywały się od kilku lat na styku PSD2 i RODO.
Co z art. 33 PSR — prawem klienta do korzystania z AISP/PISP?
Art. 33 PSR zawiera prostą, ale kluczową regułę — dostawca usług płatniczych nie może utrudniać użytkownikowi korzystania z usług AISP i PISP. Ten zakaz obejmuje wszystkie rachunki płatnicze klienta dostępne online. W zestawieniu z art. 34 PSR — który wyłącza warunkowanie dostępu do danych rachunku istnieniem stosunku umownego między AISP/PISP a ASPSP — uzyskujemy spójną ramę: klient ma prawo, dane są dostępne, infrastruktura ma być zapewniona.
Egzekucja po stronie organu nadzoru
Art. 48 PSR wzmacnia rolę właściwych organów. KNF będzie miała obowiązek:
- zapewniać, by ASPSP wypełniał obowiązki związane z dedykowanym interfejsem (art. 35 ust. 1 i art. 38 PSR) oraz by wszelkie zakazane przeszkody z art. 44 PSR były niezwłocznie usuwane,
- podejmować działania egzekucyjne — w tym sankcje — w przypadku naruszeń (art. 48 ust. 2 PSR),
- organizować spotkania trójstronne z ASPSP, AISP i PISP w celu trwałego rozwiązywania problemów dostępu (art. 48 ust. 6 i 6a PSR),
- otrzymywać dane o dostępie do rachunków od ASPSP i, w razie potrzeby, od AISP i PISP (art. 48 ust. 7 PSR).
EBA będzie koordynować raportowanie i co dwa lata informować Komisję o stanie rynku usług AIS i PIS w UE.
Co teraz zrobić — z perspektywy KIP, MIP i banku?
Z naszego doświadczenia rekomendujemy:
Dla KIP, MIP, agentów KIP i wnioskodawców:
- Zachować pełną dokumentację złożenia kompletnego wniosku o rachunek — od tej daty liczy się termin 1 miesiąca z art. 32 ust. 3 PSR.
- W razie odmowy — zażądać uzasadnienia specyficznego dla działalności (a nie generycznego) i równoległego zawiadomienia właściwego organu nadzoru. Generyczne uzasadnienie jest po wejściu PSR samodzielną przesłanką do odwołania.
- Przy zamknięciu rachunku — zweryfikować, czy bank zachował minimum 4-miesięczny okres wypowiedzenia i czy uzasadnienie odnosi się do art. 32 ust. 1 PSR.
Dla banków jako instytucji kredytowych:
- Przejrzeć politykę otwierania rachunków dla instytucji płatniczych i wnioskodawców — czy procedura zawiera oceny specyficzne dla ryzyka działalności, a nie tylko ogólny scoring sektora.
- Wprowadzić pisemny standard uzasadnień odmowy zgodny z RTS, które EBA opracuje na podstawie art. 32 ust. 5 PSR.
- Wprowadzić procedurę zawiadamiania właściwego organu w przypadku odmów i zamknięć — to wymóg, którego nieprzestrzeganie będzie ujawniane w trakcie kontroli.
Dla banków jako ASPSP:
- Zaplanować wymianę dokumentacji technicznej dedykowanego interfejsu — art. 35 ust. 4 PSR wymaga publikacji zmian co najmniej 2 miesiące przed wdrożeniem.
- Wprowadzić mechanizm publicznych statystyk kwartalnych dostępności i wydajności (art. 35 ust. 5 PSR), a środowisko testowe musi być dostępne także dla wnioskodawców (nie tylko podmiotów już z licencją).
- Przygotować się na audyt parytetu danych z art. 37 PSR — w postępowaniach KNF z lat 2023–2024 dostrzegamy, że to ten obszar najczęściej generuje skargi PISP-ów na ograniczanie funkcjonalności.
Naszym zdaniem PSD3/PSR niedopowiada w pełni jednej kwestii — w jaki sposób KNF będzie rozpatrywać odwołania KIP od odmów banku. Mechanizm odwołania z art. 32 ust. 4 PSR zostawia państwu członkowskiemu wybór trybu (administracyjny, sądowoadministracyjny, mediacyjny). Polska implementacja tego mechanizmu w nowelizacji ustawy o usługach płatniczych będzie warta śledzenia w pierwszej kolejności.
Jeżeli reprezentujesz KIP lub agenta i mierzysz się z odmową otwarcia rachunku albo planujesz wdrożenie nowych zasad open bankingu od strony ASPSP, w Legal Geek prowadzimy oba typy spraw — wspieramy zarówno wnioskodawców licencyjnych w sporze z bankami, jak i ASPSP w przygotowaniu polityk dostępu i dokumentacji API.
