Regulacje dla sektora finansowego pisane językiem maszynowym? To możliwe
W ocenie wielu ekspertów tworzenie regulacji (niekoniecznie prawa, które musi być bardziej „rozciągliwe”, nawet jeżeli są market-specific), które nie będą pozostawiały wątpliwości i będą mogły być czytane przez algorytmy − to jeden z warunków dalszego rozwoju sektora finansowego i obniżenia kosztów regulacyjnego Compliance.
Pomoc przy raportowaniu
MRR może zmienić to, w jaki sposób instytucje finansowe wypełniają swoje obowiązki regulacyjne, w tym w zakresie analizy BION (SREP) czy raportowania obowiązkowych danych, jak np. w zakresie wymogów kapitałowych, nieautoryzowanych transakcji czy danych finansowych.
Wiele z danych, które obecnie przekazywane są do regulatorów wymaga praktycznie manualnego przenoszenia do uprzednio opracowanych wzorców, które segregują te dane.
Tworzenie regulacji, które mogą być swobodnie odczytywane przez algorytm komputerowy (bądź to już w języku programowania – mniej prawdopodobne, bądź w formie niedwuznacznego tekstu wyrażonego w języku naturalnym) − otwierają drogę do większej automatyzacji i uproszczenia wielu procesów.
To zaś może istotnie przyczynić się do obniżenia kosztów (w tym czasu) poświęconego dotychczas na zebranie, opracowanie i wysłanie określonych danych do regulatora.
Czym w ogóle jest MRR?
Nie ma wypracowanej definicji, ale można stwierdzić, że to nic innego jak regulacje (wytyczne, rekomendacje, komunikaty czy opinie regulatorów), które są widoczne i zrozumiałe dla algorytmu komputerowego (sztucznej inteligencji – AI czy też uczenia maszynowego), który może przekonwertować je na konkretne działania.
Tego typu regulacje mogą być pisane zarówno w języku naturalnym (NL), jak i języku maszynowym (programistycznym), a najlepiej w obu wariantach.
Jak można wykorzystać MRR?
Obecnie wiele inicjatyw RegTechowych zmierza do uproszczenia procesów raportowania oraz oceny ryzyka braku zgodności (compliance). W wielu przypadkach są to procesy manualne, opierające się na wyabstrahowaniu z regulacji konkretnych obowiązków ciążących na ich adresatach. I np. przerzucenia ich do Excela lub usystematyzowania w inny sposób, a następnie przesyłania alertów lub nadzorowania w inny sposób.
Mogą to być obowiązki raportowe, komunikacyjne (np. względem klientów), czy też określone zakazy lub ograniczenia, które muszą być następnie monitorowane przez funkcje kontroli.
Uporządkowanie określonych wymogów i następnie możliwość przypisania im określonych metadanych (lub „zassanie” ich z określonego zasobu towarzyszącego regulacji, np. na stronie www − metadane będą też miały istotne znaczenie w przypadku budowania stosownej taksonomii) − umożliwia rozrysowanie mapy procesów, ze wskazaniem konkretnych terminów końcowych oraz obowiązanych podmiotów, która może znacznie zwiększyć efektywność tzw. regulatory compliance. Zarówno po stronie podmiotów nadzorowanych, jak i samych regulatorów.
Jest jednak wiele wyzwań
Tworzenie tego typu regulacji nie jest jednak zadaniem łatwym, co wynika z kilku atrybutów przypisywanych językowi naturalnemu:
- Definicje mogą mieć różne znaczenie w różnych kontekstach (stanach faktycznych);
- Niekiedy nie jest możliwe stworzenie krótkiej definicji, a definicje opisowe utrudniają tworzenie unikalnych identyfikatorów na potrzeby np. raportowania;
- Niejednoznaczność słów w języku naturalnym;
- Skomplikowana gramatyka (mały błąd może prowadzić do „katastrofy”).
Nie są to oczywiście jedyne wady języka naturalnego w kontekście tworzenia MRR, ale te są największym wyzwaniem dla regulatorów.
Można tutaj jeszcze wskazać chociażby na fakt, że określona definicja w danym języku może całkowicie lub częściowo zatracić swoje znaczenie w przypadku próby tłumaczenia. M.in. dlatego tak trudno stworzyć jeden słowniczek pojęć prawnych dla Unii Europejskiej – choć tutaj mamy również wpływ kultury prawnej.
Podejmowane są różne inicjatywy, jak np. European Legal Identifier czy Semantics of Business Vocabulary and Business Rules opracowane przez OMG, ale nadal są to jednak inicjatywy, które nie rozwiązują podstawowych problemów, z którymi przyjdzie się zmierzyć przy tworzeniu MRR.
Z drugiej strony można przyjąć, że nie jest to do końca problem lokalny, choć jak dobrze wiemy, nawet w jednym systemie prawnym (jurysdykcji) możemy znaleźć pojęcia, którym w różnych aktach przypisuje się różne znaczenia.
Co więc zrobić, aby tchnąć życie w MRR?
Wydaje się, że po pierwsze należy opracować pewien standard tworzenia regulacji wraz ze stosownym glosariuszem (być może oparty o PN?), który już dzisiaj byłby bardzo pomocny przy tworzeniu rozwiązań RegTechowych.
Stworzenie listy unikalnych zwrotów i przypisanie im określonego znaczenia będzie miało takie znaczenie, że algorytm będzie mógł praktycznie bezsprzecznie nadać takiemu zwrotowi konkretną funkcję i następnie – po spełnieniu określonych warunków – ją wykonać, spełniając określony obowiązek regulacyjny.
Nie mniej istotne będzie tworzenie regulacji, które są jasne, tj. nie budzą wątpliwości. Niekiedy wymaga to rozbudowania treści określonego zapisu, ale z drugiej strony ogranicza to czas, który teraz należy poświęcić na interpretację. Nie zawsze mniej będzie więc znaczyło lepiej – przynajmniej w tym konkretnym przypadku.
Tutaj pojawia się jednak zasadnicze pytanie: czy zawsze oczekiwaniem będzie wyraźne zamknięcie ram regulacji − czy raczej pewna otwartość? Czyli: precyzyjne rozporządzenie bez odstępstw versus neutralne technologicznie rozporządzenie techniczne.
Wiele zależeć będzie od celu, jaki regulacja ma osiągnąć. Jeżeli chodzi o kwestie raportowe, to zasadnym wydaje się pisanie regulacji jasnych i niewymagających interpretacji.
Tam, gdzie jednak mogą pojawić się nowe (nieoczekiwane) scenariusze – np. nowe rodzaje oszustw czy przestępstw finansowych – potrzebna może być większa otwartość i elastyczność.
Dlatego też tak istotne wydaje się stworzenie odpowiedniego wachlarza definicji i pojęć. Niekiedy korzystne może być stosowanie katalogów.
Innym wyzwaniem będzie stworzenie ram prawnych dla stosowania tego typu rozwiązań. Jednym z postulatów, które można przywołać przy okazji MRR jest możliwość dostosowania regulacji do zmieniającego się otoczenia. Takie otwarte regulacje – pod warunkiem stworzenia odpowiedniego ekosystemu – np. regulacyjnego API – mogłyby znacznie zwiększyć efektywność regulacyjnego compliance.
Z drugiej strony można zidentyfikować istotne ryzyka związane m.in. z zasadą pewności prawnej (choć to regulacje), która mogłaby ulec zniekształceniu przy nadaniu nadmiernej elastyczności autorom regulacji. Wymagałoby to więc określenia jasnych zasad zarówno dla regulatorów, jak i podmiotów nadzorowanych.
Wyzwań przed MRR jest znacznie więcej, jednakże te wskazane powyżej wydają mi się najbardziej aktualne. Warto jeszcze może wskazać na konieczność pozyskania odpowiedniej wiedzy eksperckiej (technologia / legislacja / językoznawstwo), aby regulacje spełniały rzeczywiście oczekiwania technologii.
Nieprecyzyjne i budzące wątpliwości regulacje zwiększają tylko niepewność prawną i nie zwiększają efektywności zarówno po stronie regulatorów, jak i instytucji nadzorowanych.
Czy pójdziemy w tym kierunku? Czas pokaże − brytyjski FCA już od jakiegoś czasu nad tym pracuje.
Michał Nowakowski, https://pl.linkedin.com/in/michal-nowakowski-phd-35930315,
Counsel w Citi Handlowy, założyciel www.finregtech.pl
Opinie wyrażone w artykule są osobistymi opiniami Autora i nie mogą być utożsamiane z jakąkolwiek instytucją, z którą Autor jest lub był związany.
