Verification of Payee przy paczkach przelewów z ERP: kiedy firma może wyłączyć VoP dla płatności masowych i jakie ryzyko wtedy bierze na siebie?

Firma eksportuje z SAP-a, Microsoft Dynamics 365, Comarch ERP XL czy innego systemu plik z kilkuset płatnościami, wysyła go do banku i chce zachować dotychczasowy proces: jedna paczka, kilka akceptacji, wysyłka. Verification of Payee (VoP) komplikuje ten schemat, bo przed autoryzacją przelewu dochodzi kontrola zgodności odbiorcy z rachunkiem. Przy 300 czy 3000 pozycjach oznacza to nie tylko dodatkowe komunikaty, ale przede wszystkim konieczność zdecydowania, co zrobić z wynikami „close match”, „no match” oraz sytuacją, w której weryfikacji nie udało się przeprowadzić.

Unijne przepisy przewidują wyjście z tego problemu. Firma może w określonej sytuacji zrezygnować z VoP dla paczki przelewów. Nie jest to jednak furtka pozwalająca wyłączyć kontrolę odbiorcy we wszystkich płatnościach ani sposób na przeniesienie odpowiedzialności na bank. Wręcz przeciwnie: opt-out ma sens tylko wtedy, gdy przedsiębiorstwo potrafi wykazać, że bezpieczeństwo danych dostawców kontroluje wcześniej, we własnym procesie ERP.

Wyłączenie VoP jest możliwe dla paczki, a nie dla dowolnego przelewu firmowego

Podstawa jest konkretna. Art. 5c ust. 6 rozporządzenia nr 260/2012, zmienionego rozporządzeniem (UE) 2024/886, nakazuje dostawcy usług płatniczych umożliwić użytkownikowi niebędącemu konsumentem rezygnację z VoP, gdy składa wiele zleceń płatniczych jako paczkę.

W praktyce oznacza to cztery ważne ograniczenia.

Po pierwsze, prawo do opt-out dotyczy podmiotów niebędących konsumentami. Obejmuje przedsiębiorstwa, a zgodnie z wyjaśnieniami Komisji Europejskiej również mikroprzedsiębiorstwa. Mikroprzedsiębiorca nie jest na potrzeby tego przepisu traktowany jak konsument.

Po drugie, musi chodzić o wiele zleceń przekazywanych jako pakiet. Typowym przypadkiem będzie plik płatniczy wygenerowany z ERP, np. pain.001 w standardzie ISO 20022, albo inny obsługiwany przez bank format masowych zleceń. Przepisy nie ustanawiają progu typu 10, 100 czy 1000 przelewów. Istotny jest sposób przekazania zleceń jako paczki, a nie to, czy dział finansowy marketingowo nazywa operację „płatnością masową”.

Po trzecie, opt-out jest decyzją klienta, a nie banku. Bank nie może stwierdzić, że przy plikach korporacyjnych VoP po prostu nie obsługuje. Jeżeli przedsiębiorstwo nie zrezygnowało z weryfikacji, dostawca usług płatniczych ma ją zaoferować. Firma, która wcześniej zrezygnowała, musi również mieć możliwość ponownego włączenia usługi.

Po czwarte, wyjątek nie rozciąga się na pojedyncze zlecenia. Komisja Europejska wyjaśniła to jednoznacznie: podmiot niebędący konsumentem nie może korzystać z opt-out na podstawie art. 5c ust. 6 przy pojedynczym przelewie. Sam fakt, że przelew pochodzi z systemu ERP, API czy host-to-host, niczego tu nie zmienia.

Istotny jest też kalendarz. W państwach strefy euro obowiązek VoP zaczął być stosowany przez PSP od 9 października 2025 r. W Polsce, jako państwie, którego walutą nie jest euro, termin wynikający z art. 5c przypada na 9 lipca 2027 r. Firma korzystająca z rachunku prowadzonego przez PSP w strefie euro może więc zetknąć się z pełnym procesem znacznie wcześniej niż przedsiębiorstwo realizujące płatności z polskiego banku.

Regulacyjny VoP z rozporządzenia 2024/886 dotyczy poleceń przelewu w euro w zakresie objętym regulacją SEPA. Nie należy automatycznie utożsamiać go z funkcjonującymi w poszczególnych bankach kontrolami odbiorców przelewów w PLN.

Sama usługa VoP ma być dla użytkownika bezpłatna. To jednak nie oznacza, że wdrożenie procesu jest bezkosztowe dla przedsiębiorstwa. Zmiana interfejsu bankowego, obsługa odpowiedzi VoP w TMS lub ERP, modyfikacja workflow akceptacji i praca nad kartoteką kontrahentów nadal oznaczają koszt projektu po stronie firmy.

Opt-out nie usuwa błędnego przelewu. Usuwa jedną z ostatnich szans na jego zatrzymanie

Największy błąd przy podejmowaniu decyzji brzmi: „Mamy kontrolę przelewów w ERP, więc VoP niczego nie wnosi”. ERP kontroluje przede wszystkim dane, które już posiada. Jeżeli sam master data kontrahenta został zmieniony na rachunek oszusta, perfekcyjnie skonfigurowany workflow może bardzo sprawnie wysłać pieniądze na niewłaściwe konto.

VoP działa w innym miejscu. Bank płatnika przekazuje do banku odbiorcy numer rachunku oraz nazwę lub inny dopuszczalny identyfikator odbiorcy i otrzymuje wynik weryfikacji. W modelu EPC podstawowe wyniki to:

• Match – dane odpowiadają sobie,

• Close Match – występuje niewielka rozbieżność,

• No Match – dane nie odpowiadają sobie,

• Verification Not Possible – sprawdzenia nie można wykonać.

VoP jest więc ostatnią kontrolą wykonaną poza środowiskiem firmy, na podstawie informacji znajdujących się po stronie dostawcy usług płatniczych odbiorcy.

Ma to znaczenie również dla odpowiedzialności. Jeżeli PSP prawidłowo wykonuje obowiązki VoP, przepisy chronią go przed odpowiedzialnością za wykonanie przelewu do niezamierzonego odbiorcy wynikające z użycia nieprawidłowego unikatowego identyfikatora. Jeżeli natomiast PSP nie wykona obowiązkowej weryfikacji prawidłowo, a to zaniedbanie doprowadzi do wadliwie wykonanego przelewu, przepisy przewidują zwrot płatnikowi przelanej kwoty bez zbędnej zwłoki i, jeżeli jest to potrzebne, odtworzenie stanu rachunku.

Opt-out zmienia sytuację praktyczną. Firma sama decyduje, że przy danej kategorii paczek nie chce otrzymywać warstwy kontrolnej VoP. Nie powinna później traktować braku ostrzeżenia jako argumentu, że bank miał wykryć błędny rachunek. Komisja i EPC zwracają uwagę, że po autoryzacji płatności przez przedsiębiorstwo zasadniczy ciężar decyzji nadal pozostaje po stronie użytkownika korporacyjnego.

Najbardziej niebezpieczny przypadek to nie literówka przy ręcznym wpisywaniu IBAN-u. To fraud na zmianę rachunku dostawcy, często poprzedzony przejęciem skrzynki e-mail kontrahenta albo podszyciem się pod jego pracownika. Scenariusz wygląda banalnie:

1. dział AP otrzymuje informację o „nowym rachunku bankowym”,

2. pracownik aktualizuje rekord dostawcy w ERP,

3. następna faktura przechodzi standardowy three-way match,

4. plik płatności zawiera już rachunek oszusta,

5. dwie osoby poprawnie zatwierdzają paczkę,

6. przy wyłączonym VoP bank nie pokazuje rozbieżności nazwa–IBAN.

W takim przypadku mechanizm „czterech oczu” przy samym zatwierdzaniu pliku niewiele daje. Obie osoby widzą te same, wcześniej podmienione dane.

Dlatego globalny opt-out dla wszystkich paczek jest złą praktyką. Do jednej paczki nie powinny trafiać bez rozróżnienia rachunki używane od trzech lat, nowy dostawca dodany rano, jednorazowa płatność na 250 tys. euro oraz dostawca, któremu wczoraj zmieniono IBAN.

Rozsądniejszy model dzieli płatności według ryzyka. Wyłączenie VoP można rozważyć dla kontrahentów z dojrzałej, kontrolowanej bazy, których rachunki są używane regularnie i nie zostały niedawno zmienione. Nowy albo zmodyfikowany IBAN powinien automatycznie wykluczać płatność z paczki objętej opt-out.

VoP również nie jest cudownym systemem antyfraudowym. Jeśli przestępca przejmie rachunek należący do właściwego odbiorcy albo przekona firmę do zapłacenia prawidłowo zidentyfikowanemu, lecz nieuczciwemu podmiotowi, zgodność nazwy z IBAN-em może być pełna. VoP ogranicza przede wszystkim ryzyko błędnego lub podmienionego rachunku, nie zastępuje kontroli faktury, uprawnień, sankcji, AML czy procesu potwierdzania zmiany danych dostawcy.

Zamiast wyłączać VoP dla całej firmy, podziel płatności na bezpieczne i wymagające kontroli

Najlepszy proces nie zaczyna się w banku. Zaczyna się w vendor master data.

Jeżeli przedsiębiorstwo chce używać opt-out dla dużych paczek z ERP, powinno najpierw ustalić, które rekordy kontrahentów zasługują na potraktowanie jako zaufane. W praktyce potrzebne są co najmniej trzy klasy.

Klasa A – rachunki stabilne. Kontrahent jest już zweryfikowany, IBAN nie był zmieniany, firma regularnie wysyłała na niego płatności i nie wystąpiły incydenty. Takie płatności są najlepszym kandydatem do paczki z opt-out.

Klasa B – rachunki zmienione. Dostawca jest znany, ale IBAN został ostatnio zmodyfikowany. Taka pozycja nie powinna korzystać z automatycznego zaufania wynikającego z historii kontrahenta. Historia dotyczy starego rachunku, nie nowego.

Klasa C – nowi i jednorazowi odbiorcy. Brakuje historii płatności, więc wyłączanie zewnętrznej kontroli właśnie przy tych przelewach nie ma operacyjnego uzasadnienia.

Do tego potrzebna jest prosta, ale twarda zasada: zmiana rachunku bankowego nie może być zatwierdzana na podstawie tej samej wiadomości, w której przesłano nowy IBAN. Potwierdzenie należy wykonać drugim kanałem, np. telefonicznie do znanego wcześniej przedstawiciela kontrahenta, wykorzystując numer już zapisany w bazie. Numer telefonu podany w e-mailu z prośbą o zmianę rachunku nie jest niezależnym kanałem weryfikacji.

Drugi poziom to uprawnienia w ERP. Osoba wprowadzająca nowy IBAN nie powinna samodzielnie go zatwierdzać. W systemach takich jak SAP, Dynamics 365 czy Oracle rozdzielenie funkcji powinno obejmować osobno:

• wprowadzenie lub zmianę danych bankowych,

• akceptację zmiany,

• utworzenie propozycji płatności,

• zatwierdzenie paczki,

• wysłanie pliku do banku.

Najbardziej praktyczny model hybrydowy wygląda tak: ERP generuje osobno paczkę niskiego ryzyka, dla której firma korzysta z opt-out, oraz paczkę wymagającą VoP. Do drugiej automatycznie wpada każdy nowy kontrahent, zmieniony IBAN, ręczny override oraz płatność oznaczona innym ustalonym przez firmę kryterium podwyższonego ryzyka.

Nie trzeba przy tym wymyślać jednego „unijnego” limitu kwotowego, bo taki limit nie istnieje. Próg 10 tys., 50 tys. czy 100 tys. euro jest wewnętrzną decyzją risk management, zależną od wielkości przedsiębiorstwa. Dla firmy wysyłającej miesięcznie 500 mln euro próg 10 tys. euro będzie bezużyteczny; dla spółki wykonującej kilkanaście przelewów może być sensowny.

Kolejnym problemem jest obsługa wyniku VoP. „Close Match” nie powinien automatycznie oznaczać podejrzenia oszustwa. Powodem może być skrócona nazwa spółki, znak diakrytyczny, forma prawna, nazwa handlowa albo różnica pomiędzy nazwą zapisaną w kartotece ERP i nazwą znajdującą się w banku odbiorcy. Dlatego przed uruchomieniem kontroli na tysiącach pozycji trzeba oczyścić nazwy odbiorców w master data.

Szczególną uwagę warto zwrócić na eksport do banku. Jeżeli ERP przechowuje pełną nazwę „ABC Technologie Przemysłowe spółka z ograniczoną odpowiedzialnością”, a format albo middleware wysyła skrócone „ABC Technologie”, problem nie leży w VoP. Leży w mapowaniu danych między ERP, TMS, systemem integracyjnym i bankiem.

Dla dużych paczek dochodzi jeszcze ograniczenie techniczne. Międzybankowy schemat EPC opiera weryfikację na pojedynczych zapytaniach dotyczących rachunków, natomiast sposób obsługi całego pliku w relacji firma–bank nie został narzucony jako jeden uniwersalny proces. Bank może zastosować model dwuetapowy – najpierw przekazanie danych do VoP, potem właściwy plik płatniczy – albo workflow, w którym pozycje z wyjątkami wymagają dodatkowej decyzji użytkownika.

To jest jeden z najbardziej irytujących elementów wdrożenia: proces dla paczek może wyglądać inaczej w różnych bankach. Firma korzystająca z pięciu banków nie powinna zakładać, że jedna integracja ERP obsłuży każdy z nich identycznie.

W dokumentacji EPC dla pojedynczego zapytania międzybankowego maksymalny czas oczekiwania na odpowiedź VoP wynosi 5 sekund, przy czym preferowany jest czas do około 1 sekundy. Nie oznacza to jednak, że plik z 10 tys. odbiorców zostanie zweryfikowany w pięć sekund. Przy dużych wolumenach istotne stają się przepustowość interfejsu, sposób kolejkowania oraz rozwiązanie przyjęte przez konkretny bank.

Dlatego decyzja o opt-out powinna być zapisana i audytowalna. Przy każdej paczce warto zachować przynajmniej identyfikator batcha, datę i godzinę eksportu z ERP, użytkowników zatwierdzających, informację o zastosowaniu lub pominięciu VoP oraz wersję danych kontrahentów użytych przy generowaniu płatności. Gdy po sześciu miesiącach pojawi się spór dotyczący przelewu na 180 tys. euro, stwierdzenie „chyba mieliśmy wtedy wyłączone VoP” nie jest procesem kontrolnym.

FAQ

Czy firma może na stałe wyłączyć VoP dla wszystkich swoich przelewów?
Nie na podstawie wyjątku dla płatności masowych. Art. 5c ust. 6 pozwala podmiotowi niebędącemu konsumentem zrezygnować z VoP przy wielu zleceniach przesyłanych jako paczka. Nie daje analogicznego opt-out dla pojedynczych przelewów.

Czy mikroprzedsiębiorca może skorzystać z opt-out?
Tak. Komisja Europejska potwierdziła, że mikroprzedsiębiorstwa nie są w tym przepisie traktowane jak konsumenci. Wyłączenie nadal jest jednak ograniczone do paczek wielu zleceń.

Czy wynik „No Match” automatycznie blokuje przelew?
Nie. Konstrukcja VoP zakłada, że płatnik otrzymuje ostrzeżenie, ale ostateczna decyzja o autoryzacji pozostaje po jego stronie. Bank nie powinien uniemożliwiać zatwierdzenia przelewu wyłącznie z powodu wyniku weryfikacji.

Czy „Verification Not Possible” oznacza, że firma może bezpiecznie wysłać płatność?
Nie. Oznacza tylko, że kontrola nie została wykonana. Trzeba ustalić przyczynę i ocenić ryzyko. Przy nowym rachunku dostawcy albo wysokiej kwocie właściwą reakcją jest dodatkowa weryfikacja, a nie potraktowanie braku wyniku jak „Match”.

Czy VoP jest już obowiązkowy dla wszystkich polskich banków?
Nie. Dla dostawców usług płatniczych znajdujących się w państwach UE, których walutą nie jest euro, termin stosowania art. 5c przypada na 9 lipca 2027 r. Bank może oczywiście uruchomić rozwiązanie wcześniej. Inaczej wygląda sytuacja firmy korzystającej z PSP zlokalizowanego w państwie strefy euro, gdzie obowiązek obowiązuje od 9 października 2025 r.

Czy VoP obejmuje standardowe przelewy, czy tylko natychmiastowe?
Obowiązek weryfikacji został skonstruowany szerzej niż sam przelew natychmiastowy i obejmuje objęte regulacją polecenia przelewu w euro. Nie należy więc zakładać, że wystarczy wysłać zwykły SCT zamiast SCT Inst, aby ominąć VoP.

Czy stary, wielokrotnie używany IBAN trzeba za każdym razem sprawdzać?
Jeżeli firma nie korzysta z dopuszczalnego opt-out dla paczki, VoP jest częścią procesu przewidzianego przed autoryzacją. Z punktu widzenia polityki wewnętrznej właśnie stabilne, wcześniej używane rachunki są jednak najbardziej racjonalną grupą do objęcia opt-out, pod warunkiem że firma skutecznie kontroluje zmiany master data.

Pierwszy krok nie powinien więc brzmieć „wyłączmy VoP, bo paczki zaczną się wolniej procesować”. Najpierw sprawdź w ERP wszystkie ścieżki zmiany IBAN-u kontrahenta i usuń możliwość, w której jedna osoba może wprowadzić albo zatwierdzić nowy rachunek bez niezależnej weryfikacji. Dopiero gdy master data jest pod kontrolą, podziel płatności na stabilnych odbiorców i wyjątki. Opt-out stosuj do pierwszej grupy; nowe i zmienione rachunki pozostaw w VoP. To daje realną oszczędność operacyjną bez wyłączania kontroli dokładnie tam, gdzie jest najbardziej potrzebna.

Więcej informacji na: https://finansowa-wiedza.pl