SolvaPay, FinTech ze Sztokholmu, tworzy infrastrukturę płatniczą dla agentów sztucznej inteligencji. Dyrektor generalny Viggo Stenseth zwraca uwagę, że boty potrafią już samodzielnie realizować zadania, ale przepływ pieniędzy nadal opiera się na założeniu, że po drugiej stronie transakcji stoi człowiek. W praktyce oznacza to, że firmy muszą odróżnić upoważnionego agenta od złośliwego oprogramowania i jednocześnie kontrolować limity wydatków.
- SolvaPay buduje system płatności maszynowych, rozliczeń opartych na zużyciu oraz transakcji między agentami AI.
- Zabezpieczenia takie jak 3DS czy kody CVV powstały, aby blokować boty, więc teraz handlowcy muszą rozpoznać, które zautomatyzowane zakupy są dozwolone.
- Jeden zlecony agentowi projekt może wygenerować serię powiązanych płatności, które sięgają kilka warstw w głąb łańcucha.
- Agent może pełnić jednocześnie rolę kupującego i sprzedającego, co sprzyja modelowi rozliczeń za konkretne użycie zamiast miesięcznego abonamentu.
- Pieniądze nadal muszą przechodzić przez istniejący system finansowy z wymogami AML, księgami i licencjami.
Dlaczego obecne zabezpieczenia nie wystarczają?
Branża płatnicza przez lata wzmacniała mechanizmy, które miały uniemożliwić botom podszywanie się pod klientów. Stenseth podkreśla, że systemy 3DS, kody CVV i inne narzędzia stworzono po to, aby powstrzymać złośliwe oprogramowanie. Teraz pojawia się paradoks, bo część botów ma legalnie dokonywać zakupów.
Handlowcy nie mogą po prostu wyłączyć tych ochronnych rozwiązań tylko dlatego, że zautomatyzowany kupujący otrzymał zgodę na wydawanie pieniędzy. Muszą nadal odróżniać upoważnionego agenta od szkodliwego kodu i jednocześnie sprawdzać, z czyich środków agent korzysta oraz co wolno mu kupić.
Zbudowaliśmy naprawdę solidne systemy weryfikacji, że transakcję wykonuje człowiek, 3DS, kody CVV, wszystko, aby zapobiec działaniom złych botów – powiedział Stenseth.
W praktyce oznacza to, że stare reguły bezpieczeństwa zostają w infrastrukturze, ale muszą zostać uzupełnione o nową warstwę rozpoznawania kontekstu zleceń.
Jedno zlecenie może uruchomić wiele płatności
Agenci niekoniecznie dokonują transakcji w taki sam sposób jak ludzie. Zadanie powierzone jednemu agentowi może zostać podzielone między inne wyspecjalizowane agenty. Jeden może zapłacić drugiemu, a ten kolejnemu za konkretny fragment pracy.
Stenseth wyjaśnia, że tego typu transakcje potrafią sięgać kilku warstw w głąb. Powstają wtedy pytania o uzgadnianie płatności, które nie pojawiają się przy pojedynczym zdarzeniu. Jeśli coś zawiedzie na niższym poziomie łańcucha, trzeba zdecydować, czy cofnąć całą operację, czy tylko jej wadliwy fragment.
Zbudowaliśmy systemy wokół uzgadniania lub rozwiązywania pojedynczej transakcji – dodał Stenseth.
To pokazuje, że samo przyjęcie płatności od oprogramowania to dopiero początek. Systemy muszą też śledzić zależności między wieloma płatnościami wygenerowanymi przez jedno pierwotne zlecenie.
Agent jako kupujący i sprzedający
Stenseth opisał przykład młodego dewelopera zainteresowanego analizą finansową. Zbudował on system, który pobiera informacje od zewnętrznych dostawców danych, a agent potrafi komunikować się z tymi dostawcami i płacić za potrzebne informacje.
Deweloper mógł potem nałożyć własną analizę, połączyć dane z innymi narzędziami i zaoferować gotowe rozwiązanie kolejnym użytkownikom. Jak podkreśla Stenseth, to, co ktoś zbudował dla siebie, może warstwowo rozbudować i dalej odsprzedawać.
W takim scenariuszu deweloper nie potrzebuje wyłącznie sposobu na przyjmowanie płatności. Jego oprogramowanie może również musieć opłacać każdy wykorzystany komponent, na przykład pojedyncze wywołania API, zbiory danych czy usługi obliczeniowe.
To naturalnie sprzyja rozliczeniom za rzeczywiste użycie, a nie tradycyjnemu miesięcznemu abonamentowi. Osoby budujące rozwiązania z agentami są już bardziej przyzwyczajone do takiego modelu, bo często same korzystają z usług w ten sposób.
Nie można pominąć istniejącego systemu finansowego
Choć agenci działają szybciej niż klasyczne procesy, pieniądze nadal muszą wpływać i wypływać z uznanego systemu finansowego. Stenseth zauważa, że połączenie transakcji agentów z obecnymi szynami płatniczymi oznacza konieczność spełnienia wymogów przeciwdziałania praniu pieniędzy, prowadzenia ksiąg, licencji i zabezpieczeń.
Nie można traktować autonomicznego oprogramowania jako odrębnego środowiska płatniczego, w którym można pominąć pewne etapy. Stenseth mówi wprost, że nie da się przeskoczyć kroków.
Dla handlowców wyzwanie wykracza poza samo przyjęcie płatności zainicjowanej przez oprogramowanie. Systemy przeciwdziałania oszustwom muszą rozpoznawać, kiedy zautomatyzowana aktywność jest legalna. Fakturowanie może wymagać obsługi zakupów pojedynczych jednostek danych lub usług obliczeniowych. Uzgadnianie musi uwzględniać agentów dzielących pracę między siebie i generujących wiele powiązanych płatności.
Agent może optymalizować wybór karty
W przyszłości wybór metody płatności może przejść na agenta. Stenseth opisuje sytuację, w której konsument prosi agenta o optymalizację wydatków pod kątem konkretnego celu, na przykład zbierania mil lotniczych. Oprogramowanie mogłoby wtedy automatycznie wybierać kartę, która najlepiej realizuje to polecenie przy każdym zakupie.
To pokazuje, jak bardzo rola agenta wykracza poza proste wykonanie transakcji. Agent staje się decydentem w zakresie instrumentu płatniczego, co dodatkowo komplikuje kwestie autoryzacji i kontroli.
SolvaPay próbuje połączyć szybkość zmian w oprogramowaniu agentowym z ostrożnym tempem, jakie narzucają regulacje i bezpieczeństwo finansowe. Stenseth podkreśla, że celem jest spięcie tych dwóch światów bez odrywania płatności agentów od głównego systemu finansowego.