niedziela, Grudzień 8

Regulacje dla sektora finansowego pisane językiem maszynowym? To możliwe. Jakie korzyści i jakie wyzwania przed Machine-readable Regulations”.

Google+ Pinterest LinkedIn Tumblr +

Do napisania tego tekstu skłonił mnie artykuł M. Frohlicha oraz D. Chaplina „Enabling RegTech Up The Front: Unambiguous Machine-readable Regulation” w The Reg Tech Book. W jednym z artykułów poświęconych SupTech poruszyłem kwestię istotności zmiany podejścia do kształtowania regulacji w sektorze finansowym, która powinna zmierzać ku upraszczaniu ich tekstów, aby możliwe było tworzenie bardziej efektywnych rozwiązań RegTechowych (o nich pisałem z kolei tutaj). 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. W tym artykule postaram się przybliżyć nieco moją wizję regulacji machine-readable (MRR) i jak można je wykorzystać, aby ułatwić życie wszystkim uczestnikom rynku finansowego, w tym regulatorom.

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 moa 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ądkowaniu 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 znacznie zwiększyć może efektywność tzw. regulatory compliance (zarówno po stronie podmiotów nadzorowanych, jak i samych regulatorów, o czym pisałem już w artykule o SupTech).

Jest jednak wiele wyzwań

Tworzenie tego typu regulacji nie jest jednak zadaniem łatwym, co wynika z kilku atrybutów przypisywanych językowi naturalnemu:

  1. Definicje mogą mieć różne znaczenie w różnych kontekstach (stanach faktycznych);
  2. Niekiedy nie jest możliwe stworzenie krótkiej definicji, a definicje opisowe utrudniają tworzenie unikalnych identyfikatorów na potrzeby np. raportowania;
  3. Niejednoznaczność słów w języku naturalnym;
  4. Skomplikowana gramatyka (mały błąd może prowadzić do „katastrofy”).

Nie są to oczywiście jedyne „wady” NL 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 znaczenie 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ślonych 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ść (przykład: 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 (ciekawie opisane zostały w tym artykule), 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.

 

Udostępnij.

Zostaw komentarz