Od 2025 r. dostawcy usług płatniczych prowadzący rachunki w euro mają obowiązek oferować płatnikowi tzw. weryfikację odbiorcy (ang. Verification of Payee, VoP) przy poleceniach przelewu w euro objętych zakresem rozporządzenia 260/2012. Obowiązek wprowadziło rozporządzenie 2024/886 (rozporządzenie o płatnościach natychmiastowych — IPR), które dodało art. 5c i 5b do rozporządzenia 260/2012. Projekt rozporządzenia PSR (dokument Rady 8221/26 z 17 kwietnia 2026 r.) idzie o krok dalej: art. 50 PSR rozszerza ten obowiązek na wszystkie polecenia przelewu, niezależnie od waluty i niezależnie od tego, czy mieszczą się w zakresie rozporządzenia 260/2012.
Poniżej omawiamy, co dokładnie się zmienia i jakie obowiązki spadają na dostawców usług płatniczych prowadzących rachunki (ang. account servicing payment service provider, ASPSP) — w tym banki, krajowe instytucje płatnicze (KIP) i małe instytucje płatnicze (MIP). Wpis warto czytać razem z analizą nowego open bankingu i prawa dostępu KIP do rachunku w banku oraz z artykułem o nowej odpowiedzialności PSP za impersonation fraud.
Czego dotyczy art. 50 projektu PSR?
Art. 50 PSR ma jeden, ale szeroki cel — zniwelować ryzyko, że płatnik wyśle środki na konto, którego unikalny identyfikator (najczęściej IBAN) nie odpowiada nazwie, którą zamierzał wskazać jako odbiorcę. Sam mechanizm jest już w prawie unijnym opisany — art. 50 PSR stanowi, że „payment service providers shall comply with provisions of Articles 5c(1) to (7) and 5b(2) of Regulation (EU) 260/2012, and those articles shall apply mutatis mutandis to all credit transfers, including those that fall outside the scope of Regulation (EU) 260/2012”.
Tłumacząc — wszystkie polecenia przelewu, niezależnie od waluty, schematu i tego, czy wchodzą w zakres rozporządzenia 260/2012, mają być obsługiwane z weryfikacją zgodności unikalnego identyfikatora z nazwą odbiorcy. To istotne rozszerzenie. Dziś:
- przelewy w euro objęte zakresem rozporządzenia 260/2012 — z VoP wynikającą z art. 5c tego rozporządzenia (terminy stosowania zależą od typu dostawcy i tego, czy ma siedzibę w państwie strefy euro),
- przelewy w innych walutach UE (np. PLN, CZK, RON) i przelewy poza systemem SEPA — bez ujednoliconego unijnego obowiązku VoP.
Po wejściu w życie PSR — wszystkie polecenia przelewu, bez względu na walutę i schemat.
Kiedy dokładnie zaczyna obowiązywać?
Co prawda PSR wchodzi w życie 20. dnia po publikacji w Dzienniku Urzędowym UE, ale stosuje się dopiero od 21 miesiąca po wejściu w życie (art. 112 PSR). Dla art. 50 i art. 57 PSR przewidziano osobny, odroczony termin — 27 miesięcy od wejścia w życie PSR. To pole manewru dla banków i instytucji płatniczych, które nie obsługują dzisiaj weryfikacji odbiorcy w pełnym zakresie, ale w skali wdrożenia operacyjnego nie jest to nadmiernie hojny okres.
Co konkretnie musi zrobić dostawca usług płatniczych?
Mechanizm z art. 5c rozporządzenia 260/2012, do którego odsyła PSR, w skrócie wymaga:
- przed wykonaniem polecenia przelewu sprawdzić zgodność unikalnego identyfikatora odbiorcy z nazwą wskazaną przez płatnika,
- przekazać płatnikowi wynik weryfikacji w jasnym i zrozumiałym komunikacie — pełna zgodność, bliska zgodność, brak zgodności,
- umożliwić płatnikowi rezygnację z usługi VoP wyłącznie wyjątkowo i z odrębną zgodą (z naszego doświadczenia istotny jest sposób udokumentowania świadomej rezygnacji),
- oferować usługę bez dodatkowej opłaty od konsumenta.
Co ważne — art. 5b ust. 2 rozporządzenia 260/2012, do którego odsyła art. 50 PSR, wyłącza odpowiedzialność dostawcy płatnika za błędną realizację, jeżeli dostawca prawidłowo zrealizował polecenie zgodnie z unikalnym identyfikatorem (a płatnik mimo ostrzeżenia o niezgodności nakazał wykonanie). To rozwiązanie znamy już dziś z art. 143 ustawy z dnia 19 sierpnia 2011 r. o usługach płatniczych — PSR utrzymuje tę logikę, ale dokłada do niej obowiązkowe ostrzeżenie weryfikacyjne.
Co z odpowiedzialnością PSP, gdy zawiedzie weryfikacja?
Tu kluczowy jest art. 57 projektu PSR, który wprowadza nową, samodzielną podstawę odpowiedzialności:
„Where payment service providers fail to comply with Article 50, and where that failure results in a defectively executed payment transaction, the payer's payment service provider shall without delay refund the payer the amount transferred and, where applicable, restore the debited payment account to the state in which it would have been had the transaction not taken place.”
Innymi słowy — jeżeli dostawca usług płatniczych nie wywiąże się z obowiązku weryfikacji i przelew zostanie wykonany wadliwie, dostawca płatnika ma bez opóźnienia zwrócić kwotę i przywrócić rachunek płatnika do stanu sprzed transakcji. Jeżeli za naruszenie odpowiada dostawca odbiorcy lub dostawca usługi inicjowania transakcji płatniczej (PISP), dostawca płatnika ma roszczenie regresowe wobec tych podmiotów (art. 57 akapit drugi PSR).
Na tle art. 144 ustawy o usługach płatniczych jest to istotne zaostrzenie — dziś dostawca odpowiada przede wszystkim za zgodność realizacji z unikalnym identyfikatorem. PSR dokłada warstwę odpowiedzialności za sam mechanizm weryfikacji. Naszym zdaniem to jeden z największych operacyjnych hot-pointów PSR — błąd w UX komunikatu o niezgodności może w przyszłości skutkować obowiązkiem zwrotu.
Co z transakcjami inicjowanymi przez PISP?
Art. 36 ust. 4 lit. g PSR dokłada obowiązek funkcjonalny po stronie ASPSP — dedykowany interfejs API ma umożliwiać PISP-owi „verify the name of the account holder before the payment is initiated and regardless of whether the name of the account holder is available via the direct interface”. PISP-y zyskają dostęp do nazwy posiadacza rachunku, niezależnie od tego, czy jest ona pokazywana w interfejsie klienta banku.
Art. 36 ust. 5a PSR wprost stanowi, że dla potrzeb działalności PISP-a i AISP-a nazwa posiadacza rachunku oraz unikalny identyfikator nie są wrażliwymi danymi dotyczącymi płatności (ang. sensitive payment data). To rozwiązanie usuwa wątpliwości dotyczące dotychczasowej praktyki niektórych banków, które ograniczały dostęp do tych pól, traktując je jako sensitive payment data.
Co teraz zrobić — z perspektywy banku, KIP i MIP?
Rekomendujemy kilka obszarów do przeglądu jeszcze przed publikacją regulacyjnych standardów technicznych EBA:
- UX procesu przelewu — czy ostrzeżenia o niezgodności są jasne i niezależne od identyfikacji wzrokowej (np. czytelne dla osób korzystających z czytników ekranu, z odpowiednią notyfikacją w kanale agreed manner).
- Polityka logowania weryfikacji — z naszego doświadczenia w kontrolach KNF i sporach z klientami brakuje często twardego dowodu, jaki komunikat został wyświetlony i kiedy. Po wejściu PSR ten dowód będzie krytyczny dla obrony przed roszczeniem zwrotu z art. 57.
- Umowy ramowe (framework contracts) — czy zawierają warunki, na jakich klient niebędący konsumentem może świadomie zrezygnować z VoP (rozporządzenie 260/2012 dopuszcza to dla profesjonalistów, ale wymaga formalnej zgody).
- Modele liability split — kto ponosi koszt zwrotu po stronie dostawcy odbiorcy lub PISP-a. Warto rozważyć zmiany w umowach z PISP-ami i z bankami korespondentami pod regres z art. 57 zd. 2.
- Raportowanie incydentów — błędy w VoP będą się zazębiać z obowiązkami z DORA (rozporządzenie 2022/2554) i z procedurami zgłaszania nadużyć, w tym z reżimem zwrotu dla ofiary impersonation fraud z art. 59 PSR.
Naszym zdaniem największym ryzykiem nie jest sama integracja techniczna — większość banków i KIP ma już od października 2025 r. silnik VoP dla SEPA. Ryzykiem jest rozszerzenie tego silnika na waluty inne niż euro i schematy spoza SEPA oraz ujednolicenie standardu nazewnictwa we wszystkich kanałach inicjacji (bankowość elektroniczna, mobilna, otwarta bankowość, MOTO, paczki przelewów). Spotykamy się z tym, że banki obsługujące PLN mają po stronie systemu Elixir mechanizm sprawdzania nazwy odbiorcy, ale nie jest on zharmonizowany z funkcjonalnościami VoP wymaganymi przez rozporządzenie 260/2012.
Jeżeli planujesz audyt readiness pod art. 50 i art. 57 PSR albo chcesz omówić, jak skomponować mapowanie ryzyk z procesami z DORA i AML, zapraszamy do kontaktu z zespołem Legal Geek.
