Maker i checker w rejestrach compliance: konflikty interesów, prezenty, płatności

Deklaracje konfliktu interesów, prezenty i zaproszenia, wyjątki od limitów płatności. Każdy z nich może być zwykłą listą, którą ktoś wypełnia, albo kontrolą, w której jedna osoba wpisuje, a druga ocenia i zatwierdza. Różnica nie jest kosmetyczna: tylko w drugim przypadku można później udowodnić, że ktoś faktycznie podjął decyzję.

Podstawy są wspólne dla całego sektora bankowego. Wytyczne EBA w sprawie zarządzania wewnętrznego (EBA/GL/2021/05) oczekują odpowiedniego podziału obowiązków, w tym powierzania sprzecznych czynności przy przetwarzaniu transakcji różnym osobom (pkt 149). Rekomendacja H KNF opisuje podział obowiązków jako sposób na to, by pracownik nie kontrolował samego siebie (rekomendacja 5.5 lit. b), a rozporządzenie w sprawie systemu kontroli wewnętrznej w bankach wymienia autoryzację i podział obowiązków w § 37 ust. 1.

Deklaracje konfliktu interesów: kto ocenia, kto zatwierdza mitygację

Maker to tu sam pracownik. Wytyczne EBA oczekują, że personel niezwłocznie ujawnia wewnętrznie każdą sprawę, która może prowadzić lub już doprowadziła do konfliktu interesów (pkt 113). Polityka ma obejmować interesy najbliższych członków rodziny i relacje z przeszłości, a instytucja ustala okres, za jaki takie relacje się zgłasza (pkt 109 i 110).

Checker to funkcja, która ocenia istotność i dobiera środki. EBA rozróżnia konflikty trwałe, którymi trzeba zarządzać stale, od jednorazowych, związanych z jednym zdarzeniem, jak wybór dostawcy (pkt 114). Jeśli konflikt zostaje zaakceptowany, instytucja dokumentuje decyzję i to, jak ryzyko zostało ograniczone (pkt 118).

W praktyce dobrze działa podział na trzy role. Compliance robi triage: kompletność, istotność, rekomendacja środka. Mitygację zatwierdza ktoś, kto ma władzę ją wykonać, czyli przełożony deklarującego, a przy wysokiej istotności dodatkowo szef compliance. Nikt z tej trójki nie może być stroną konfliktu, a przy członkach zarządu wytyczne przewidują wstrzymanie się od głosu w sprawie, w której członek ma lub może mieć konflikt (pkt 115 lit. c).

Druga połowa tej kontroli to przegląd okresowy. Konflikt trwały zaakceptowany dwa lata temu ze środkiem „wyłączenie z decyzji kredytowych dla spółki X” trzeba sprawdzić: czy pracownik nadal jest tam, gdzie był, czy wyłączenie działa w systemie uprawnień i czy ktoś nie podpisał jednak decyzji. Bez tego rejestr pokazuje stan z dnia zgłoszenia, a nie stan faktyczny.

Rejestr prezentów: progi i zakaz samoakceptacji

Tu zasady są w dużej mierze wewnętrzne, więc tym bardziej muszą być twarde w systemie. Polityka ustala progi wartości, poniżej których wystarcza zgłoszenie, i powyżej których potrzebna jest zgoda, najlepiej przed przyjęciem. Wartość zapisuje się w walucie instytucji po kursie z dnia zgłoszenia, bo inaczej próg można obejść rozbiciem na waluty.

Reguła bez wyjątków: obdarowany nigdy nie zatwierdza własnego prezentu. Nie zatwierdza go też ktoś, kto sam uczestniczy w tej samej relacji z darczyńcą. Brzmi to oczywiście, a mimo to w wielu systemach uprawnienie „akceptujący” jest nadane całemu działowi.

Rejestr prezentów nabiera sensu dopiero w połączeniu z innymi danymi. Zaproszenie od dostawcy, który właśnie bierze udział w przetargu, to nie jest pozycja w rejestrze prezentów, tylko potencjalny konflikt interesów jednorazowy. Checker powinien to widzieć na jednym ekranie: kto daje, komu, w jakiej relacji biznesowej i co się w tej relacji dzieje teraz.

Płatności: podwójna autoryzacja i rozdział ról w systemie

Rekomendacja H podaje jako przykład autoryzacji obowiązek autoryzacji w systemie informatycznym przy transakcjach przekraczających określony poziom (rekomendacja 5.5 lit. c). W bankowości elektronicznej oznacza to role: przygotowujący płatność i zatwierdzający płatność, przypisane różnym osobom.

Trzy słabe miejsca widać w niemal każdym przeglądzie. Pierwsze to zmiana danych beneficjenta, która przechodzi bez drugiej osoby, choć to ona decyduje, dokąd trafią pieniądze. Drugie to dzielenie płatności tuż poniżej progu, które wymaga osobnej reguły detekcyjnej. Trzecie to administrator, który może nadać sobie obie role naraz; Rekomendacja H wymienia kontrolę dostępu jako odrębny mechanizm (rekomendacja 5.5 lit. d) i tu ona właśnie się przydaje.

Ten sam wzór obowiązuje poza bankowością elektroniczną. W systemie transakcyjnym i księgowym osoba, która zawiera lub wprowadza operację, nie powinna jej rejestrować ani uzgadniać; Rekomendacja H podaje wprost przykład oddzielenia etapu zawierania transakcji od etapów jej rejestrowania i weryfikowania. Uzgodnienie rachunków rozrachunkowych robione przez tego, kto księguje, wykrywa pomyłki, ale nie wykrywa nadużyć.

Najsłabszym ogniwem podwójnej autoryzacji rzadko jest zatwierdzający. Częściej jest nim ktoś, kto może zmienić, komu wolno zatwierdzać.

Ślad audytowy, który udowadnia kontrolę

Rekomendacja H oczekuje dokumentowania stosowania mechanizmów kontrolnych tak, by dało się je niezależnie monitorować i zbadać w audycie; jako formy wymienia podpisy, potwierdzenia w systemie informatycznym i raporty (rekomendacja 5.7). W rejestrach compliance minimum to: kto wpisał, kto ocenił, kto zatwierdził, kiedy, na jakiej wersji danych i z jakim uzasadnieniem. Odrzucenia i zwroty do uzupełnienia zapisują się tak samo jak akceptacje, bo to one pokazują, że checker działa.

Pliki Excela z kolumną „zatwierdził” nie spełniają tego standardu. Każdy może tam wpisać cokolwiek, w dowolnym momencie, bez śladu zmiany. Rejestr, który ma być dowodem, musi być niezmienny po zamknięciu wpisu albo przynajmniej wersjonowany.

Co zrobić w tym kwartale

• Dla każdego rejestru spisać role makera i checkera i sprawdzić, czy system technicznie blokuje akceptację własnego wpisu.
• Połączyć rejestr prezentów z listą aktywnych przetargów i postępowań zakupowych.
• Przejrzeć, kto w bankowości elektronicznej może zmieniać dane beneficjentów i kto może nadawać role zatwierdzających.
• Policzyć odrzucenia i zwroty w każdym rejestrze za ostatni rok; zero to sygnał do testu, a nie powód do zadowolenia.