Smart kontrakty i technologia rozproszonego rejestru[1] są coraz częściej postrzegane jako narzędzia na zwiększenie skuteczności operacyjnej kontraktów na instrumenty finansowe oraz sposób na obniżenie kosztów przy tego typu transakcjach. Wydaje się, że poprzez ciągle przyspieszający rozwój tych technologii rynek finansowy może ulec znaczącej zmianie.
Problemem cały czas pozostaje wczesna faza rozwoju technologii opartej na blockchain oraz samych smart kontraktów. Tak naprawdę na świecie nie ma jeszcze jednolitej, wspólnej definicji czym są smart kontrakty, nie wspominając w ogóle o polskim porządku prawnym. Tym bardziej trudnym wydaje się zadanie opisania potencjalnego wpływu smart kontraktów na rozwój rynku instrumentów pochodnych i jak tak specyficzne rodzaje umów umieścić w obecnej rzeczywistości prawnej.
1. DEFINICJA SMART KONTRAKTU
W literaturze możemy znaleźć kilka koncepcji czym jest smart kontrakt. Najbardziej trafną wydaje się ta zaproponowana przez J. Starka[2], przedstawiająca dwie zasadnicze strony smart kontraktu:
Smart kontrakt jako kod: Dla deweloperów oprogramowania i wszystkich osób pracujących bardziej od strony technicznej z blockchainem, określenie “smart kontrakt” odnosi się przede wszystkim do kodu umożliwiającego ich realizację. Określenie wszystkich linijek kodu mianem kontraktu wynika z faktu, że sam kod odpowiada za określony element bądź określoną wartość. Smart kontraktem będzie więc linijka kodu, która będzie w stanie zrealizować określone zadania w zdefiniowanych warunkach. Wszystko oczywiście będzie realizowane w ramach czy też poprzez technologię blockchain.
Smart kontrakt jako umowa, zobowiązanie gdzie znaczące postanowienia umowne są wykonywane przez oprogramowanie. Idea smart kontraktu zawiera się w sposobie użycia języka programowania. Możemy go zastosować do:
· Nadania znaczenia odpowiednim postanowieniom umownym,
· Podkreślenia znaczenia, zwiększenia znaczenia konkretnego punktu,
· Zautomatyzowania realizacji wybranych postanowień kontraktu.
W praktyce takie kontrakty byłyby połączeniem kodu i tradycyjnego języka prawniczego. Nie ulega wątpliwości, że w przyszłości tego typu kontrakty mogłyby być traktowane jak dzisiejsze, normalne umowy.
Od kilku lat zauważa się, że najszybciej i najłatwiej dałoby się zastosować smart kontrakty w branży finansowej. Przede wszystkim w szeroko pojętym obrocie instrumentami finansowymi (akcje, obligacje, instrumenty pochodne). Wynika to z faktu, że rynek instrumentów finansowych w dużej mierze opiera się na rozwiniętej technologii a pewne procesy są poddane automatyzacji (np. Dematerializacja akcji i związany z tym obrót giełdowy). Blockchain i smart kontrakty mogłyby ten proces jeszcze usprawnić i przyspieszyć.
Clack, Bakshi i Braine[3] przedstawili złożoną definicję smart kontraktu: “Smart kontrakt jest zautomatyzowaną i umożliwiającą realizację roszczeń umową. Zautomatyzowaną przez komputer, natomiast niektóre jej elementy mogą wymagać kontroli i wkładu ze strony ludzi. Umożliwiającą egzekwowanie umowy od strony prawa albo przez odporny na manipulację kod komputerowy.
Jest to definicja szeroka, obejmująca obydwa wskazane wyżej zagadnienia, to bardziej prawnicze i bardziej techniczne.
2. SMART KONTRAKTY A DLT
O smart kontraktach i DLT często mówi się jak o tożsamych konstrukcjach, są to jednak odrębne, uzupełniające się technologie. Technologia rozproszonego rejestru stworzyła pewnego rodzaju platformę do wkroczenia smart kontraktów na salony i podniosła dyskusję na temat ich zastosowania. Możemy zadawać sobie pytanie: Skoro technologia komputerowa jest dostępna od kilkudziesięciu lat, dlaczego jeszcze nie stosujemy smart kontraktów? Problemem wydaje się to, że każda ze stron odpowiedni kod oprogramowania napisałaby inaczej. Prawo powszechne jest takie same dla wszystkich, kod komputerowy może się różnić chociaż też się cechuje swoimi pryncypiami. Rozwiązaniem tej bolączki jest właśnie zastosowanie technologii rozproszonego rejestru. Poprzez nią eliminujemy ryzyko różnicy w kodzie i różnej interpretacji kluczowych warunków potencjalnej transakcji. Nie ma też potencjalnego ryzyka w niedochowaniu warunków transakcji, wynikających np. Z braku płatności w odpowiednim terminie (zazwyczaj tzw. T+2 czyli dwa dni robocze po zawarciu transakcji na rynku). Odpowiednio ustalone i zagregowane postanowienia spowodują, że “skrypt” w automatyczny sposób zrealizuje warunki transakcji.
Należy jednak pamiętać, że smart kontrakty i DLT to oddzielne technologie, które mają różne wady i zalety. Nie należy ich mylić patrząc na nie z perspektywy prawnej.
3. DWA MODELE SMART KONTRAKTÓW
A) Model zewnętrzny
W modelu zewnętrznym sama umowa pozostaje w formie znanej nam wszystkim (naturalny język ludzki) natomiast pewnego rodzaju warunki są zaprogramowane w formie kodu i automatycznie wykonywane w przypadku ich spełnienia.
Sam kod nie byłby częścią umowy, tylko pewnego rodzaju wsparciem dla automatycznej realizacji wybranych postanowień. W przypadku różnicy pomiędzy tym co jest zapisane w kodzie, a tym co jest w umowie to umowa miałaby charakter nadrzędny.
Warto dodać, że samo zaprogramowanie elementów umowy nie wyłączałoby możliwości dochodzenia swoich praw na drodze sądowej. Ten dodatek technologiczny miałby tylko charakter pomocniczy, instrukcyjny. Strony odpowiednio powinny mieć świadomość, że kod odpowiada ich oczekiwaniom i reprezentuje ich oczekiwania w umowie.
W wielu przypadkach, przynajmniej dla prawników, model zewnętrzny to stosunkowo niewielki progres w porównaniu do mechanizmów operacyjnych, które strony w transakcjach pochodnych mają do dyspozycji. Samej umowy nie nazwałbym tutaj smart kontraktem, bardziej umową z użyciem smart kodu.
B) Model wewnętrzny
Model zewnętrzny w swojej zasadzie pozostałby przy języku naturalnym, natomiast lwia część postanowień zapisanych językiem naturalnym zostałaby zapisana językiem odpowiadającym kodowi oprogramowania realizującym w sposób automatyczny podmiotowe zapisy. Miękki, naturalny język zostałby zastąpiony przez język programowania.
Myślę, że zautomatyzowane postanowienia mogłyby zostać zapisane w formie odnośnika do zewnętrznego rejestru gdzie w sposób elektroniczny mógłby zostałby zawarty odpowiedni warunek.
Niezależnie który model kontraktu zastosujemy, sstnieją dwa potencjalne problemy z jakimi muszą się mierzyć potencjalni użytkownicy smart kontraktów:
W jaki sposób mogę mieć pewność, że moje intencje zostały poprawnie zawarte w języku programowania skoro go nie znam? To trochę tak jak z językiem stosowanym przez prawników czy finansistów. Nie ujmując przeciętnemu Kowalskiemu, trudno będzie mu zrozumieć sens zawarty w takim języku. Podobnie z językiem oprogramowania. Istotnym wydaje się wypracowanie odpowiedniego porozumienia oraz współpracy pomiędzy prawnikami a programistami. Ponadto nieocenionym byłaby znajomość wybranego języka programowania (np. Python, C++) przez prawnika zajmującego się smart kontraktami. Rynek nie znosi próżni i w przyszłości może coś takiego zobaczymy.
Drugim problemem jest faktyczny wpływ zapisanego kodu na określony stan faktyczny. Skutek okazał się inny od zamierzonego przez stronę. Wydaje się, że jedynym rozwiązaniem jest odpowiednie przygotowanie, badanie oraz testy pozwalające potwierdzić, że odpowiednio zapisany kod będzie uosabiał wolę strony w taki sam sposób w jaki robiłby to język naturalny. Z takimi samymi problemami wiążą się prawnicy od setek lat więc nie wydaje mi się to barierą nie do przeskoczenia.
4. Rodzaje klauzul mogące podlegać automatyzacji
Klauzule podlegające potencjalnej automatyzacji możemy podzielić w sposób dychotomiczny na:
Klauzule operacyjne – zawierają w treści czynności prawnej warunek, od którego spełnienia zależne są konkretnego rodzaju działania.
· Klauzula zawierająca zobowiązanie do zapłaty ściślej określonej kwoty w momencie realizacji opcji
· Klauzula cross-default – naruszenie zobowiązania w umowie bezpośrednio związanej z umową zabezpieczająca (np. Kredyt inwestycyjny zabezpieczany przez transakcje pochodne) powoduje naruszenie zobowiązania w umowie zabezpieczającej
· Cross acceleration czyli “naruszenie zobowiązań innych wierzycieli skutkujące akcją wierzyciela”. Jeśli firma naruszy jakąkolwiek z zawartych przez sobie umów finansowania i spowoduje to powzięcie przez daną instytucję odpowiednich kroków przewidzianych w takiej umowie (np. Egzekucję zabezpieczeń), to zgodnie z tą klauzulą następuje również naruszenie umowy zabezpieczającej
Z klauzulami operacyjnymi możemy przeciwstawić klauzule nieoperacyjne – zawierające cechy charakterystyczne umowy, nieposiadające warunku, od którego zależy spełnienie umowy.
· Postanowienie wskazujące jakiego sądu jurysdykcja będzie miała zastosowanie w sytuacji ewentualnych sporów pomiędzy stronami
· Klauzula wskazująca np. Process agenta transakcji
· Zapis stanowiący, że do wszystkich płatności pomiędzy stronami z tytułu transakcji będzie mieć zastosowanie netting (kompensacja)
· Oświadczenie potwierdzające, że strona transakcji nie jest w trakcie upadłości lub restrukturyzacji
Prosta obserwacja pozwala zauważyć, że zdecydowanie łatwiejszymi elementami do potencjalnej automatyzacji są postanowienia nieoperacyjne. W praktyce oprogramowanie zaopatrzone w odpowiedni zestaw danych mogłoby dokonać weryfikacji czy wszystkie niezbędne elementy są spełnione. Interesuje nas umowa pod prawem angielskim zdefiniowana jako “1”, wszystkie inne systemy prawne będą “0”, czyli będą fałszywe.
Problemem, który pojawia się przy tego typu postanowieniach jest ich charakter; obiektywny albo subiektywny. Odpowiedni dokument potwierdzający, że spółka nie ogłosiła upadłości bądź nie jest w restrukturyzacji stanowi fakt obiektywny. W jaki sposób określimy czy bilans finansowy spółki jest odpowiedni do zawierania transakcji pochodnych? Stosując różną metodologię bądź korzystając z opinii kilku analityków, odpowiedź na powyższe pytanie nie musi być taka sama. Jest to stwierdzenie subiektywne.
Myślę, że dla obecnych i przyszłych prawników jednym z największych wyzwań jest rozwiązanie problemu zderzenia “twardych” zapisów prawnych, w szczególności tych, które potencjalnie będą zapisane w formie elektronicznego kodu z postanowieniami o bardziej miękkim charakterze, które sąd może rozpatrywać w indywidualny sposób. W coraz bardziej zaawansowanym technologicznie rynku finansowym, gdzie instytucje finansowe starają się przewidzieć każdy możliwy ruch rynku oraz w interesie swoim jak i regulatora, chcą jak najbardziej ograniczyć ryzyko zawieranych transakcji, w szczególności tych przy użyciu derywatów pożądanym celem jest możliwość zawierania umów pozbawionych “miękkiego charakteru”.
5. Potencjalne korzyści wynikające z automatyzacji przy użyciu smart kontraktów
W 2016 KPMG opublikowało raport[4] wskazujący, że zautomatyzowanie procesów w usługach finansowych mogłoby obniżyć koszty operacyjne o 40-75% w porównaniu do 15-30% obniżki wynikającej z przenoszenia stanowisk typu middle i back office do krajów z niższymi kosztami operacyjnymi.
Jak wynika z podobnego raportu przygotowanego przez McKinsey Global Institute[5], sektor finansowy i ubezpieczeniowy mogłby zaoszczędzić 43% czasu swoich pracowników przy odpowiednim zautomatyzowaniu procesów.
Nie posiadamy żadnych empirycznych danych umożliwiających oszacowanie potencjalnego wpływu smart kontraktów na obniżenie kosztów i zwiększenie automatyzacji w przedsiębiorstwach finansowych, ale nie ulega wątpliwości, że ten wpływ byłby ogromny.
Blockchain oraz technologia rozproszonego rejestru, pomimo swojej wczesnej fazy rozwoju są fascynującymi narzędziami, które stanowią podstawę smart kontraktów – niejednolicie zdefiniowanych umów, które w zależności od swojej struktury zawierają kod pozwalający wesprzeć realizację wybranych postanowień umownych bądź całkowicie zastąpić, napisane językiem naturalnym postanowienia umowne, które będą automatycznie realizowane przez oprogramowanie.
Niezależnie od wybranego modelu, zewnętrznego czy wewnętrznego, smart kontrakty mogą zostać użyte na rynku finansowym w celu przyspieszenia zawierania transakcji, obniżenia kosztów i wzrostu pewności obrotu.
Jednym z najpoważniejszych wyzwań dla prawników i programistów jest ujednolicenie stosowanego języka, nawiązanie odpowiedniej komunikacji, która pozwoliłaby w skuteczny sposób tworzyć inteligentne kontrakty wspierające nie tylko rynek finansowy, ale i inne branże stosujące inteligentne rozwiązania.
Niniejsza publikacja stanowi moją subiektywną opinię, nie prezentuje żadnego stanowiska mojego obecnego lub byłego pracodawcy.
Autor: Tomasz Sulejko
[1] Distributed Ledger Technology – DLT.
[2] J. Stark, “Making sense of blockchain smart contracts”, 2016. http://www.coindesk/com/making-sense-smart-contracts/
[3] C. Clack, V. Bakshi, L..Braine, “Smart Contract Templates: foundations, design landscape and research directions”, 2017.
[4] KPMG, “Rise of the Robots”, 2016. https://www.the-digital-insurer.com/wp-content/uploads/2017/07/943-rise-of-the-robots.pdf
[5] McKinsey Global Institute, “A future that works: Automation, Employment and Productivity”, January 2017. https://www.mckinsey.com/~/media/mckinsey/featured%20insights/Digital%20Disruption/Harnessing%20automation%20for%20a%20future%20that%20works/MGI-A-future-that-works-Executive-summary.ashx