Jeszcze niedawno dyskusja o wykorzystaniu sztucznej inteligencji w płatnościach miała charakter czysto teoretyczny. Obecnie jednak organizacje płatnicze prowadzą zaawansowane pilotaże, a pierwsze komercyjne wdrożenia płatności agentowych zapowiadane są w nieodległej perspektywie.

Visa poinformowała o zakończeniu pilotażu pierwszych transakcji płatniczych wykonanych przez agenta AI, prowadzonego z udziałem kilkudziesięciu instytucji finansowych, w tym podmiotów działających na polskim rynku. Wcześniej o pierwszej w Polsce uwierzytelnionej transakcji zainicjowanej przez agenta AI informował Mastercard. Równolegle zainteresowanie realnymi wdrożeniami w tym zakresie widzę we własnej praktyce, gdzie klienci coraz częściej pytają o prawne ramy obsługi płatności przez narzędzia AI. Jeszcze niedawno tego typu pytania zadawane były raczej z ciekawości niż w kontekście konkretnych projektów wdrożeniowych.

Płatności wykonywane przez agentów AI przestają być zatem jedynie technologiczną ciekawostką, a stają się realnym modelem świadczenia usług płatniczych. Należy zauważyć, że już teraz płatności z udziałem agentów AI da się zorganizować zgodnie z wymogami regulacyjnymi, w tym z wymogami silnego uwierzytelniania. Nie da się natomiast wyeliminować ryzyka sporów o autoryzację transakcji, które ten model ze sobą niesie. To ryzyko jednak można i trzeba aktywnie mitygować. Niestety każdy kto uzna, że zgodność techniczna z SCA zamyka temat, może jednak niemiło zaskoczyć się przy realnym wdrożeniu.

Autoryzacja i uwierzytelnienie

W pierwszej kolejności należy przypomnieć znaczenie kluczowych dla omawianego zagadnienia pojęć ustawy o usługach płatniczych. Zgodnie z nią, uwierzytelnienie oznacza procedurę umożliwiającą dostawcy usług płatniczych weryfikację tożsamości użytkownika lub ważności stosowania konkretnego instrumentu płatniczego, łącznie ze stosowaniem indywidualnych danych uwierzytelniających. Autoryzacja zaś jest pojęciem szerszym i poza czynnością techniczną, związaną z uwierzytelnieniem, obejmuje także swym zakresem zgodę użytkownika na dokonanie transakcji płatniczej.

Polski rynek ma przy tym za sobą spór dotyczący wzajemnej relacji powyższych pojęć oraz zasad zwrotu nieautoryzowanych transakcji, o którym to sporze pisałem szerzej w artykułach dotyczących zwrotu nieautoryzowanych transakcji: „Zwrot nieautoryzowanych transakcji – kontrowersyjne zarzuty Prezesa UOKIK wobec sektora bankowego” oraz „Kolejna odsłona sporu o zwrot nieautoryzowanych transakcji”. Niezależnie od oceny przebiegu tego sporu oraz towarzyszących mu błędów legislacyjnych, w praktyce organów utrwaliło się stanowisko, zgodnie z którym samo prawidłowe uwierzytelnienie transakcji nie przesądza jeszcze o jej autoryzacji (art. 45 ust. 2 ustawy o usługach płatniczych). Tym samym w ocenie organów nadzoru transakcją nieautoryzowaną będzie również transakcja uwierzytelniona, ale dokonana bez zgody konsumenta.

Nie ulega wątpliwości, że rozwój płatności agentowych każe do tych doświadczeń wrócić. W sporze o transakcję wykonaną przez agenta AI dostawca znajdzie się bowiem w jeszcze gorszej pozycji dowodowej, gdzie być może będzie dysponował kompletnym dowodem prawidłowego uwierzytelnienia, ale jeszcze trudniejsze będzie udowodnienie prawidłowej autoryzacji. Kierunek dotychczasowej praktyki, konsekwentnie akcentującej element rzeczywistej zgody płatnika, każe traktować to ryzyko poważnie.

Zgoda płatnika a polecenie wydane agentowi

Powyższy problem najlepiej zobrazować na przykładzie. Użytkownik wydaje agentowi AI polecenie opłacenia wszystkich zaległych faktur. Agent analizuje skrzynkę mailową, identyfikuje zobowiązania, przygotowuje i wykonuje serię przelewów. Czy takie polecenie może zostać uznane za zgodę na wykonanie każdej z tych transakcji w rozumieniu ustawy o usługach płatniczych? 

W mojej ocenie sprawa jest co najmniej dyskusyjna. Polecenie tego rodzaju przypomina bardziej umocowanie o charakterze rodzajowym, niż zgodę na konkretną transakcję płatniczą. Ustawa o usługach płatniczych przewiduje wprawdzie możliwość autoryzacji kolejnych transakcji płatniczych, jednak konstrukcja zgody płatnika zakłada odniesienie do transakcji określonych, a nie do otwartej kategorii przyszłych operacji, których to parametry jak kwota, odbiorca, moment wykonania, ustali dopiero algorytm na podstawie własnej interpretacji danych.

Na powyższym przykładzie wyraźnie widać, że w rzeczywistości mamy do czynienia z dwoma odrębnymi problemami. Pierwszy z nich ma charakter techniczny i dotyczy uwierzytelnienia zgodnego z wymogami SCA oraz powiązania wykonywanej transakcji ze zleceniem płatniczym klienta. Drugi problem dotyczy natomiast samej autoryzacji, a więc faktycznej woli wykonania danej transakcji przez klienta. Rozróżnienie to ma kluczowe znaczenie dla dalszych rozważań. Pierwszy z powyższych problemów sektor jest bowiem w stanie dość prosto rozwiązać narzędziami technicznymi, drugi zaś stanowi większe wyzwanie.

Na problemy związane z wykorzystywaniem AI przy realizowaniu płatności można także spojrzeć jeszcze z innej perspektywy, tj. strony, po której mogą pojawić się określone ryzyka:

• po stronie samego użytkownika – klient zatwierdzający operację przygotowaną przez agenta coraz częściej będzie dokonywał zatwierdzenia bez rzeczywistej weryfikacji kwoty i odbiorcy, ufając prawidłowości działania narzędzia. W tym zakresie pojawia się zatem wspomniany problem oceny faktycznej woli wykonania danej transakcji przez klienta, a tym samym prawidłowej autoryzacji transakcji.
• po stronie samego agenta – modele sztucznej inteligencji pozostają podatne na manipulację treścią, którą przetwarzają (tzw. prompt injection). Odpowiednio spreparowana faktura lub treść strony internetowej może skłonić agenta do przygotowania operacji innej niż zamierzona przez użytkownika, jeszcze przed etapem jakiegokolwiek zatwierdzenia.

SCA i dynamic linking – realna rola i granice

W odniesieniu do omawianych problemów, obowiązujące wymogi regulacyjne z zakresu bezpieczeństwa nie pozostają wobec omawianego ryzyka całkowicie bezradne. Silne uwierzytelnianie klienta wraz z prawidłowo wdrożonym mechanizmem tzw. dynamic linking (art. 5 rozporządzenia RTS/SCA) może wiązać kod autoryzacyjny z konkretną kwotą oraz konkretnym odbiorcą, gdzie zmiana któregokolwiek z tych parametrów skutkuje unieważnieniem wygenerowanego kodu. W praktyce oznacza to, że jeden z najczęściej przywoływanych scenariuszy zagrożeń tj. podmiana numeru rachunku przez zmanipulowanego agenta po zatwierdzeniu operacji przez klienta,  powinien zostać wychwycony na poziomie tak prawidłowo wdrożonego mechanizmu. 

Należy odnotować, że wspomniane na wstępie prace organizacji płatniczych, w tym pilotaże prowadzone przez Visa i Mastercard, obejmują między innymi mechanizmy, które mają wiązać polecenie użytkownika z transakcją inicjowaną przez agenta oraz umożliwiać spełnienie wymogów SCA w ruchu agentowym. Celem tego rodzaju rozwiązań jest w szczególności umożliwienie odróżnienia zaufanych interakcji agentów AI od interakcji niezweryfikowanych, a także zachowanie przez uczestników rynku kontroli nad tym, w jaki sposób agenci AI uzyskują dostęp do ich serwisów, wyszukują w nich produkty oraz finalizują transakcje. 

Dla powyższych modeli potencjalne zastosowanie mogą też znaleźć niektóre wyłączenia od stosowania SCA, jako naturalna droga do zapewnienia płynnego doświadczenia użytkownika w płatnościach agentowych, jak np. lista zaufanych odbiorców. Należy jednak pamiętać o konstrukcji powyższych wyłączeń i ograniczeniach z nich wynikających. Omawiane mechanizmy SCA odpowiadają jednak przede wszystkim na pytanie o tożsamość klienta stojącego za daną operacją, nie zaś na pytanie o rzeczywistą treść jego woli. Warto jednak przypomnieć, że w tej sferze uwierzytelniania polski sektor bankowy oraz sektor usług płatniczych uczyniły już wiele, aby wyjść naprzeciw oczekiwaniom organów, formułowanych w związku z omawianym sporem o nieautoryzowane transakcje. Podobne działania będą musiały być podejmowane również w odniesieniu do nowego kanału zlecania transakcji, jeżeli sektor chce uniknąć powtórzenia znanych już problemów. Uwierzytelnienie może zostać zautomatyzowane i zabezpieczone na poziomie technologicznym – co już obserwujemy. Zgoda płatnika w rozumieniu art. 40 ustawy o usługach płatniczych jest już trudniejsza do wykazania i wymaga szerszej palety działań na poziomie komunikacji z klientem.

Jeśli dostawcą agenta jest sam bank, krajowa instytucja płatnicza lub podmiot z rynku kryptoaktywów świadczący usługi płatnicze lub ich partnerzy, to w takim przypadku dostawca kontroluje cały łańcuch płatności. Możliwe jest zatem zaprojektowanie systemu  odbierania zleceń, granice samodzielności agenta, momentu i formy zatwierdzenia operacji oraz treści umowy z klientem. Dostawca dysponuje zatem realnymi narzędziami pozwalającymi mitygować omawiane ryzyka. Mitygacja ta nie powinna jednak sprowadzać się wyłącznie do technicznego uwierzytelnienia klienta, lecz powinna koncentrować się na takim ukształtowaniu procesu, aby zgoda płatnika na konkretną transakcję przygotowaną przez agenta była świadoma, jednoznaczna i możliwa do późniejszego wykazania. W praktyce oznacza to konieczność wyraźnego oddzielenia etapu przygotowania operacji przez agenta od aktu jej autoryzacji przez klienta, a także stosowania odpowiednich ograniczeń, limitów, komunikatów ostrzegawczych lub dodatkowych potwierdzeń w przypadku transakcji podwyższonego ryzyka. 

Jednocześnie podmiot taki nie będzie mógł przerzucić odpowiedzialności na zewnętrzne narzędzie, skoro agent stanowi jego produkt, a błąd agenta będzie błędem po stronie dostawcy usługi płatniczej, ze wszystkimi tego konsekwencjami, łącznie z obowiązkiem zwrotu kwoty nieautoryzowanej transakcji. 

Agent AI poza wiedzą i kontrolą dostawcy

W kontekście działalności agentów AI w procesach płatniczych, należy też zwrócić uwagę na szerszy problem wykraczający poza model, w którym instytucja finansowa świadomie wdraża płatności agentowe. Istnieją bowiem scenariusze wykorzystywania rozwiązań AI, które to dotyczą sektora już dziś, niezależnie od planów produktowych poszczególnych podmiotów. Klient może bowiem samodzielnie korzystać z przeglądarki AI lub innego agenta, który to agent działa w ramach prawidłowo uwierzytelnionej sesji bankowości elektronicznej. Ruch generowany przez agenta może pozostawać z perspektywy systemów dostawcy ruchem klienta, a systemy monitoringu antyfraudowego, kalibrowane na wzorce ludzkiego zachowania, nie zawsze mogą być w  stanie wychwycić działania agenta. Ponadto postanowienia umów ramowych, dotyczące nieudostępniania instrumentu płatniczego oraz indywidualnych danych uwierzytelniających osobom trzecim, konstruowane były w realiach, w których osobą trzecią mógł być wyłącznie człowiek. Zastosowanie tych postanowień do oprogramowania działającego lokalnie na urządzeniu klienta jest co najmniej dyskusyjne.

Co również istotne, rozkład ryzyka w powyższym scenariuszu jest wyjątkowo niekorzystny. W przypadku, w którym agent błędnie zinterpretuje polecenie lub padnie ofiarą manipulacji, klient zgłosi transakcję jako nieautoryzowaną. Dostawca przedstawi dowód prawidłowego uwierzytelnienia, który to dowód, jak wskazano powyżej, sam w sobie nie przesądza kwestii autoryzacji. Dostawca narzędzia AI, którego działanie faktycznie doprowadziło do powstania szkody, pozostanie natomiast poza reżimem ustawy o usługach płatniczych i tym samym poza sporem. Możliwość skutecznego regresu wobec takiego podmiotu należy dziś ocenić jako wątpliwą.

Czy PSR odpowie na nowe wyzwania?

Na koniec wypada zadać pytanie, czy nadchodzące regulacje zmienią przedstawiony powyżej obraz. Pakiet PSD3/PSR jest bliski finalizacji i publikacji w Dzienniku Urzędowym UE można spodziewać się w najbliższych miesiącach, przy czym rozpoczęcie stosowania nowych przepisów poprzedzone zostanie wydłużonym okresem przejściowym. W obszarze nieautoryzowanych transakcji oraz przeciwdziałania oszustwom pakiet przewiduje szereg istotnych zmian, w tym w szczególności:

• obowiązek weryfikacji zgodności nazwy odbiorcy z unikatowym identyfikatorem przy przelewach;
• rozbudowanie obowiązków monitorowania transakcji pod kątem ryzyka fraudu;
• ramy wymiany informacji o fraudach pomiędzy dostawcami usług płatniczych;
• mechanizmy współpracy dostawców usług płatniczych z dostawcami hostingu, platformami internetowymi oraz dostawcami usług komunikacji elektronicznej;
• możliwość zawieszenia albo odmowy wykonania transakcji w przypadku obiektywnie uzasadnionego podejrzenia fraudu;
• obowiązki po stronie dostawcy odbiorcy dotyczące odmowy udostępnienia środków i ich zwrotu w określonych przypadkach.

Powyższe mechanizmy nie były jednak projektowane pod kątem zagrożeń wynikających z działalności agentów AI. Projektowane przepisy nie adresują zatem modelu, w którym decyzję operacyjną podejmuje oprogramowanie działające w imieniu klienta i za jego ogólnym przyzwoleniem, a szkoda nie stanowi rezultatu działania oszusta, lecz błędnej interpretacji polecenia. 

Podsumowanie

Przedstawione zagadnienie jest niewątpliwie złożone, jednak z całą pewnością nie powinno stanowić powodu do rezygnacji z rozwoju płatności agentowych. Wdrożenie takiego modelu jest możliwe,  przy prawidłowym zastosowaniu SCA, wykorzystaniu mechanizmu dynamic linking tam, gdzie znajduje on zastosowanie oraz rozważnym ukształtowaniu wyłączeń, a w zakresie problemu autoryzacji, przy ustanowieniu odpowiednich ograniczeń, limitów, komunikatów ostrzegawczych lub dodatkowych potwierdzeń w przypadku transakcji podwyższonego ryzyka. 

Z drugiej strony instytucje, które nie planują wdrażania płatności agentowych, nie powinny zakładać, że omawiany problem ich nie dotyczy. Klienci tych instytucji zaczną bowiem korzystać z agentów niezależnie od stanowiska dostawcy, a część z nich korzysta z takich narzędzi już dziś. Minimalny zakres działań powinien zatem obejmować ocenę zdolności monitoringu transakcyjnego do identyfikacji ruchu agentowego oraz przygotowanie się na sytuacje, w których klient wskaże, że kwestionowaną transakcję wykonał jego agent. Wystąpienie tego rodzaju sporów wydaje się przy tym wyłącznie kwestią czasu.