W jednym z ostatnich artykułów poruszyłem kwestię RegTech i jego wpływu na rozwój sektora finansowego w dobie rosnącej liczby regulacji. Rozwój technologii, w tym rosnące znaczenie dużych zbiorów danych (Big Data), powoduje że również po stronie regulatorów pojawiają się inne potrzeby niż miało to miejsce 10 lat temu.

Liczba obowiązków raportowych (a także rozmiar samych raportów) rodzi konieczność wykorzystania zaawansowanych mechanizmów automatycznej (lub semi-automatycznej) analizy danych, których zadaniem będzie tworzenie „strawnych” dla człowieka informacji (np. o lukach regulacyjnych czy naruszeniach compliance’owych).

Ma to szczególne znaczenie w czasach kiedy na rynku pojawiają się coraz to nowe podmioty (w tym Third Party Providers), które uzyskują dostęp do wrażliwych danych klientów, a także są szczególnie narażone na wycieki danych (data leaks). Aby sprostać wymogom cyfrowego otoczenia, również regulatorzy muszą „inwestować” w rozwój narzędzi nadzorczych. Z pomocą przychodzi SupTech, który może zmienić obraz nadzoru nad instytucjami finansowymi.

Raport Banku Rozliczeń Międzynarodowych w sprawie SupTech definiuje tą dziedzinę jako innowacyjne technologie wykorzystywane przez nadzorców do wspierania nadzoru. Najczęściej podkreśla się, że SupTech to zbieranie i analiza danych, ale śmiało można do tej kategorii zaliczyć wszelkie innowacje, które przyczyniają się do zwiększenia skuteczności nadzoru (również z punktu widzenia instytucji finansowych), a więc np.:

  1. Chatboty (rozwijające się w Azji) do rozwiązywania prostych spraw, w tym skarg;
  2. Regulacje w formie „dostępnej” dla algorytmu (machine-readable)
  3. Różne formy cyfrowej interakcji pomiędzy regulatorami a przedstawicielami instytucji (przykładowo nadzorca z Singapuru stosuje tego typu rozwiązania w ramach swojej piaskownicy regulacyjnej) czy też
  4. Wykorzystanie chmury obliczeniowej do przechowywania i przetwarzania danych.

Oczywiście rozwiązań jest znacznie więcej, jednakże mają one głównie charakter rozwiązań back-endowych, czyli usprawniających procesy wewnętrzne regulatora. Jednym z najciekawszych pomysłów jest wykorzystanie API, czyli interfejsów programistycznych do integracji pomiędzy regulatorem a nadzorowanymi podmiotami. Może to mieć dwie zasadnicze zalety:

  1. Możliwość przeprowadzania nadzoru w czasie rzeczywistym (przy czym tutaj istotne jest wyraźne określenie zasad dotyczących możliwości „włączenia” wtyczki;
  2. Udostępnienie instytucjom nadzorowanym bazy danych regulatora, co może mieć przykładowo znaczenie w kontekście rejestrów TPP czy wytycznych i rekomendacji, a także możliwość ich swobodnego adoptowania do środowiska banku.

Można też również wyobrazić sobie pewną formę „ERP”, czyli Enterprise Resource Planning jako platformy do interakcji z regulatorem. Z API wiąże się również możliwość swobodnego przekazywania raportów (np. dotyczących fraudów czy wymogów ostrożnościowych) niekoniecznie w formie ustrukturyzowanej (co wymaga wiele pracy po stronie instytucji), ale również „nieobrobionych” informacji.

To z kolei implikuje konieczność stworzenia odpowiednich algorytmów wykorzystujących uczenie maszynowe (Machine Learning – ML) i/lub sztuczną inteligencję (Artificial Intelligence), które takie dane uporządkują i podejmą stosowną decyzję (ocenę) warunkującą podjęcie określonych działań (lub stwierdzą brak takiej konieczności). Oczywiście nie może to być proces całkowicie pozbawiony czynnika ludzkiego, tym bardziej, że ostateczną odpowiedzialność za ewentualne niedopatrzenia lub błędna decyzję poniesie człowiek.

Innym, choć podobnym, przykładem użycia SupTech może być ocena BION (SREP) z użyciem automatycznego przetwarzania danych (co znacznie zmniejszyłoby obciążenie osobowe po stronie regulatora oraz samej instytucji finansowej w przypadku kontroli on-site). Wymaga to jednak również dobrego (i analogicznego) przygotowania po stronie instytucji finansowej (RegTech). Z pewnością jednak przygotowania dokumentacji technicznej (BION-API?), która umożliwiłaby integrację w z góry określonym zakresie przyśpieszyłaby wiele procesów po stronie organu nadzoru.

SupTech’owy sandbox?

Można jeszcze wspomnieć o piaskownicach regulacyjnych opartych o nowe technologie. Testowanie nowych produktów i usług w środowisku cyfrowym ze wsparciem chatbotów opartych o sztuczną inteligencję, ale i interakcje z regulatorami in personam znacznie skracałoby czas przeprowadzania pilotażu. Jeżeli algorytmy byłby w stanie „wyłapywać” ewentualne regulacyjne luki, a także oceniać ryzyko w oparciu o różne (predefiniowane) scenariusze, to ryzyko błędu jak i czas wdrożenia produktu mógłby ulec znacznemu skróceniu.

Jedną z podstawowych zalet wykorzystania Big Data jest dostępność danych dla różnych (praktycznie nieograniczonej liczby) wariantów. Odpowiednie oprogramowanie mogłoby również usprawnić proces przygotowywania dokumentów wewnętrznych np. w oparciu o wcześniej przygotowaną checklistę (jeżeli regulacje byłyby wystarczająco precyzyjne, to dlaczego nie „zlecić” tego sztucznej inteligencji i następnie zweryfikować przez człowieka?).

Sam proces licencyjny czy rejestracji również mógłby być znacznie uproszczony. Wyobraźmy sobie bowiem sytuację, w której instytucja otrzymuje uwagi do przygotowywanych dokumentów w czasie rzeczywistym. Może wprowadzić niezbędne zmiany i przekazać do „zaopiniowania” przez regulatora. Kryje się jednak za tym pewien dość poważny problem.

Formalizm związany z postępowaniem przed nadzorcą. Jeżeli za tego typu – technologicznymi – zmianami nie pójdą zmiany prawne to ich wdrożenie może okazać się prawdziwą udręką. Skoro bowiem postępowanie odbywa się zasadniczo na wymianie pism i zachowaniem odpowiednich terminów określonych w aktach regulujących procedurę administracyjną, to taki automatyczny system wymiany danych może rodzić pewne ryzyka prawne zarówno dla regulatora, jak i samej instytucji nadzorowanej. Jest to jednak temat na odrębny artykuł. Warto jednak mieć jego świadomość.

Jakie wyzwania przed SupTech?

Jest ich całkiem sporo i są związane m.in. z faktem, że nadzorcy są podmiotami publicznymi. Dane, którymi dysponuje nadzorca stanowią tajemnicę zawodową, którą należy chronić ze szczególną starannością. Z drugiej strony tworzenie rozwiązań, o których wspomniałem powyżej, z udziałem wyłącznie środków własnych może być praktycznie niewykonalne. Konieczne może być więc zlecenie wykonania i utrzymania rozwiązania (oprogramowania) podmiotowi trzeciemu (outsourcing?). To zaś rodzi obawę o bezpieczeństwo danych (ten sam problem pojawi się w przypadku korzystania z chmury obliczeniowej – więcej w tym artykule) i w ogóle możliwości powierzenia tak odpowiedzialnego zadania podmiotowi trzeciemu. Być może rozwiązaniem jest przetwarzanie danych zanonimizowanych (po stronie instytucji)?

Innym wyzwaniem jest oczywiście kwestia wdrożenia SupTech i ograniczeń budżetowych. Stworzenie nowych API czy nawet całych platform to oczywiście duże koszty. Do tego należy „dołożyć” ograniczenia prawne oraz operacyjne.

Ważnym aspektem jest również jasne określenie zasad odpowiedzialności oraz weryfikacji danych przetwarzanych przez zautomatyzowane narzędzia. Algorytmy również mogą się mylić (np. wskutek awarii czy niewłaściwego zaprogramowania) lub być podatne na ataki ze strony podmiotów trzecich, co może wpływać ich funkcjonowanie. Zawsze istnieje również ryzyko, że regulator nie otrzyma kompletu danych (choć w przypadku pozyskiwania ich bezpośrednio z infrastruktury IT i z zastrzeżeniem wielu ograniczeń związanych z integralnością tych danych, ryzyko jest stosunkowo niewielkie).

Na koniec warto wspomnieć, że niektóre państwa pracują już nad bardziej zaawansowanymi narzędziami (wiele jest jednak jeszcze na etapie testowania). Wydaje się, że najbliższe lata mogą zmienić obraz nadzoru, który dziś znamy. Pociągnie to z pewnością rozwój RegTech, co przyczynić się może również do obniżenia kosztów compliance po stronie instytucji nadzorowanych i dodatkowo zwiększyć ich transparentność i zaufanie.

Artykuł stanowi moją prywatną opinię i nie może być utożsamiany ze stanowiskiem jakiejkolwiek instytucji z którą jestem lub byłem związany.