RegTech, czyli cichy brat Fintech. Jak automatyzacja procesów compliance może wspierać rozwój i gdzie potrzebna jest interwencja. Cz. 1

Do napisania tego artykułu skłonił mnie ostatni raport University of Cambridge, który dość kompleksowo podchodzi do kwestii wykorzystania technologii „w służbie” regulacji czy też wypełniania obowiązków nadzorczych. Dokument „The Global RegTech Industry Benchmark Report” nie odnosi się stricte do sektora finansowego, ale dane w nim zawarte świetnie ilustrują rosnącą rolę RegTech na świecie. W tym artykule przedstawię moją – bardzo subiektywną – ocenę tego gdzie jesteśmy z rozwojem tego obszaru i co jeszcze trzeba zrobić, aby zwiększyć szanse na szersze wykorzystanie w sektorze finansowym. Dzisiaj skupię się na podstawowych pojęciach oraz wyzwaniach związanych z formą i jakością regulacji, które można wykorzystać do zautomatyzowania procesów.

Zacznijmy od zdefiniowania czym w ogóle jest RegTech. Wspomniany raport skłania się ku definicji funkcjonalnej zgodnie z którą należy go rozumieć jako wykorzystanie technologii do „łączenia” ustrukturyzowanych i nieustrukturyzowanych danych w zaawansowane sieci powiązań (taksonomie) lub zasad podejmowania decyzji w celu zautomatyzowania procesów compliance i innych podobnych procesów. Ja skłaniam się jednak ku nieco prostszej definicji, o której pisałem już w tym artykule. Jest to więc nic innego jak technologia w służbie regulacji, czyli całokształt działań automatyzujących wypełnianie obowiązków nakładanych na podmioty regulowane (w tym w zakresie zarządzania ryzykiem).

Dlaczego interesujemy się RegTechem?

AML, RODO, PSD2, CRDV/CRR2, BRRD2, MiFID2, STIR, SPLIT PAYMENT, MDR, WHITE LIST, MAR, MADII i wiele innych. Te akronimy budzą „grozę” wśród przedstawicieli sektora finansowego, ale o tym w trzecim akapicie. A interesujemy się RegTechem bo…  

…może być łatwiej. Mamy w końcu mamy sztuczną inteligencję (AI) i uczenie maszynowe (ML), a także pokaźne zbiory danych (Big Data), które mogą znacznie ułatwić podejmowanie (trudnych) decyzji. Mamy też chmurę obliczeniową, która obniża koszt analizy tych danych (możliwość przesunięcia zasobów osobowych czy mocy obliczeniowej na inne – zyskowne – obszary. Są to jednak tak naprawdę środki do osiągnięcia innego celu – minimalizacji kosztów dostosowania się do rosnącej liczby regulacji (rozumiane jako compliance przy minimalizacji obciążenia finansowego i operacyjnego). Compliance, czyli zgodność z regulacjami jest nadal postrzegane raczej jako koszt niż realna korzyść dla instytucji (a w praktyce jest to przecież „obrona” przed dotkliwymi sankcjami).

Ilość przepisów i regulacji z którymi „mierzyć” musi się sektor finansowy stale rośnie (to jak wpływa to na wynik finansowy obrazuje m.in. raport ZBP). Są to nie tylko akty prawne, ale również wytyczne, opinie, interpretacje, stanowiska i komunikaty krajowych i unijnych regulatorów, które wpływają bezpośrednio na zakres, jak i sposób funkcjonowania tych podmiotów w sektorze (w tym w relacji z klientami). RegTech oferuje wiele rozwiązań (ciekawie opisane m.in. przez jednego z przedstawiciela ESMA w tym artykule), które pozwalają m.in. na przyspieszenie procesu gromadzenia danych niezbędnych do raportowania, np. transakcji fraudowych czy lepsze zarządzanie ryzykiem. To także możliwość lepszego „operowania” regulacjami, które mają zastosowanie do instytucji.

Ale czy jest tak różowo?

Jeszcze nie, ale może być lepiej. Nadal jesteśmy raczej dalej niż bliżej w tworzeniu efektywnego otoczenia RegTechowego. Zbudowanie ram prawnych, operacyjnych, a nawet infrastrukturalnych, wymaga współpracy wielu aktorów tworzących rynek finansowy i większego udziału sektora publicznego (nie tylko regulatorów, ale również prawodawców i policy-makerów).

Prawda jest taka, że technologia to jedno, a możliwość jej wykorzystania to drugie. Może nawet bardziej istotne. Obszarów, które wymagają większej atencji jest sporo. Poniżej zebrałem te, które wydają mi się w tej chwili najistotniejsze, choć nie oznacza to, że postulowana zmiana jest łatwa do wprowadzenia (a może w ogóle niemożliwa na tym etapie?).

Zacznijmy od (formy) prawa

Prawo jest pisane trudnym i dość specyficznym językiem. Czytanie aktów prawnych może wywoływać zawroty głowy, a kiedy mamy je dodatkowo interpretować, to zadanie staje się jeszcze większym wyzwaniem. Dodajmy do tego, że stosowana nomenklatura może różnić się na poziomie unijnym i krajowym, a także coraz popularniejsze nadawanie przepisom charakteru „neutralnych technologicznie” (vide Rozporządzenie 2018/389 towarzyszące pakietowi PSD2) i jesteśmy ugotowani.

Brytyjski organ nadzoru podjął próbę zmiany podejścia do prawa i rozpoczął program pilotażowy, którego celem było sprawdzenie czy możliwe jest tworzenie regulacji machine readable and executable, czyli pisanych językiem maszynowym lub przynajmniej możliwym do odczytania i zinterpretowania przez algorytm. Ćwiczenie okazało się sukcesem, choć oparte było o niewielką próbkę regulacji. Potwierdziło się jednak, że tworzenie takich regulacji jest możliwe. Jeżeli algorytm mógłby uczyć się prawa i wyciągać z nich właściwe wnioski (np. zbierz dane i zaraportuj określony zakres informacji do regulatora w tym a tym terminie), to obciążenie instytucji byłoby praktycznie zerowe (w tej chwili wymaga to zazwyczaj zaangażowania wielu osób z różnych obszarów i operacyjnego zgrania różnych procesów).

Wyzwanie jakie tutaj się pojawia to przede wszystkim „niepodważalność” przepisów. Algorytmy (ML czy AI) mogą mieć trudności z interpretacją przepisów które nie są jasne i (prawie) niebudzące wątpliwości. Takich przepisów jest jednak niewiele. Nie wynika to często z jakości prawodawstwa, ale faktu, że przepisy muszą mierzyć się z rzeczywistością i dynamicznie zmieniającym się otoczeniem, a to jest trudne do przewidzenia na etapie tworzenia przepisów. Aby spełnić surowe wymagania regulacyjne z użyciem „automatu” instytucja musi mieć pewność, że interpretacja jest (praktycznie) pewna.

To z kolei rodzi pytanie o odpowiedzialność

Jeżeli nie spełnimy powyższego warunku, to pojawią się liczne wątpliwości w zakresie poprawności interpretacji, co skłonić może instytucję do zatrudnienia sztabu specjalistów (prawników, inspektorów compliance i innych ekspertów do „upewnienia” się, że dany obowiązek regulacyjny zostanie wypełniony poprawnie. Nie taki jest jednak cel automatyzacji z użyciem narzędzi RegTech.

Mamy więc dwa wyjścia. Albo tworzyć praktycznie doskonałe regulacje, albo zachęcić w inny sposób do wykorzystywania tych rozwiązań. Tutaj niezwykle istotne będzie podejście regulatora. Przyjęcie podejścia, w którym stosowanie rozwiązań RegTechowych nie będzie obarczone dodatkowy ryzykiem regulacyjnym (negatywną reakcją regulatora) w związku z „wyłączeniem” czynnika ludzkiego, może być dodatkową zachętą do ich stosowania. Wydaje się jednak, że nie może się to obejść bez określenia pewnych ram tej odpowiedzialności. Można to przykładowo osiągnąć wprowadzając pewne minimalne standardy (rekomendacje/dobre praktyki lub nawet normy), które muszą spełnić tego typu rozwiązania. Jeżeli instytucja zastosowałaby „certyfikowane” (może to być np. baza czy rejestr samego regulatora), to mogłaby uznać, że dochowała należytej staranności i obowiązki regulacyjne wykonała poprawnie i zgodnie z literą prawa.

Oczywiście nadal mogą pojawić się żądania uzupełnienia danych czy złożenia dodatkowych wyjaśnień, ale obowiązek byłby spełniony o czasie. Nie jest to jednak rozwiązanie doskonałe. Może być oczywiście tak, że pewne dane nie zostaną (intencjonalnie lub nie) przekazane przez instytucję. Prawidłowe ułożenie zasad oceny „należytej staranności” i „nieumyślności” w działaniu byłoby tutaj pożądane, jeżeli nie niezbędne.

Trudności mogą pojawić się również w kontekście oceny funkcjonowania samego algorytmu oraz odpowiedzialności za jego (nie)działanie. Jak więc widać nie jest to zadanie łatwe.

Na dziś to koniec

W kolejnej części zmierzę się z perspektywą regulatora oraz wykorzystaniem tzw. SupTech.

Dodaj komentarz

Twój adres e-mail nie zostanie opublikowany. Wymagane pola są oznaczone *