Case study Bank Polskiej Spółdzielczości SA - Cezary Dziułka

Download Report

Transcript Case study Bank Polskiej Spółdzielczości SA - Cezary Dziułka

Wdrażanie metody zaawansowanej AMA w Banku Polskiej Spółdzielczości

Zastosowanie Aplikacji Zarządzania Ryzykiem Operacyjnym (OPERON)

2

BPS – krótka charakterystyka Banku

     BPS – lider polskiego sektora bankowości spółdzielczej Ponad 350 banków zrzeszonych 79 oddziałów na terenie Polski Suma bilansowa – 12,5 mld PLN Wymóg kapitałowy BIA – 32 mln PLN BPS Zrzeszone Banki Spółdzielcze

3

Struktura organizacyjna systemu zarządzania ryzykiem operacyjnym Banku

Poziomy operacyjne nadzorcze i kontrolne Rada Nadzorcza Komitet Ryzyka Operacyjnego Biuro Ryzyka Operacyjnego Zarząd

Audyt i Kontrola Wewnętrzna

4

Proces zarządzania ryzykiem operacyjnym

Główne elementy procesu Identyfikacja Raportowanie Audyt i kontrola wewnętrzna Ocena i limitowanie Ograniczanie Monitorowanie

5

Plan projektu AMA

Planowane stosowanie AMA od roku 2013 Etap I Audyt regulacji i procesów Audyt danych Etap II Modelowanie statystyczne Etap III Wdrożenie narzędzia informatycznego

6

Źródła danych do AMA

Podstawowe rodzaje danych w modelu Analizy scenariuszowe i samoocena Zewnętrzna baza strat (ZORO) Wewnętrzna baza strat (Operon)

7

Proces ewidencji zdarzeń operacyjnych

Ewidencja zdarzeń jest prowadzona w każdej jednostce i komórce organizacyjnej Banku:

– – – – – Punkt Obsługi Bankowej, Filia, Oddział, Oddział Regionalny/ Wojewódzki, Biuro i Departament Centrali.

8

Ewidencja zdarzeń operacyjnych

  System zarządzania ryzykiem operacyjnym wymaga: – – – wysokiej świadomość pracowników Banku co do istnienia ryzyka operacyjnego (szkolenia), znajomości i przestrzegania obowiązujących w Banku przepisów oraz regulacji nadzorczych , poczucie współodpowiedzialności pracowników za kontrolę i ograniczanie ryzyka operacyjnego Zarządzanie ryzykiem operacyjnym Banku

wymaga ujawniania

przez pracowników zdarzeń operacyjnych i/lub incydentów.

Przepływ prac w systemie Operon (1)

9

W Banku funkcjonuje czterostopniowy system kontroli i weryfikacji danych dot. zaistniałych zdarzeń operacyjnych.

System weryfikacji danych czterostopniowy KOORDYNACJA WERYFIKACJA AKCEPTACJA REJESTRACJA

Przepływ prac w systemie Operon (2) Przep ływ prac przy rejestracji zdarzeń operacyjnych rzeczywistych i incydentów w strukturze organizacyjnej 10

ODRZUCENIE ZATWIERDZENIE * ODRZUCENIE AKCEPTACJA AKCEPTACJA

wprowadzenie danych

uzupe łnianie

sprawdzanie

akceptowanie

• • • • ODRZUCENIE AKCEPTACJA

uzupe łnianie sprawdzanie weryfikacja akceptowanie

przegl ądanie

• •

weryfikacja zatwierdzanie

* Po dokonaniu zatwierdzenia, mo żliwe jest wprowadzanie korekt finansowych i modyfikacja danych niefinansowych

Funkcje w systemie

Poziom III - Weryfikator 11

Weryfikator jest pracownikiem Departamentu Rachunkowości i Sprawozdawczości Centrali Banku.

Weryfikator dokonuje porównania zarejestrowanych przez Rejestratora lub Akceptanta danych księgowych i/lub systemie finansowo księgowym. danych finansowych z zapisami w

Ma też możliwość wprowadzenia/modyfikacji danych finansowych i/lub danych księgowych

.

Weryfikator ma prawo wycofania rejestrowanego zdarzenia operacyjnego na niższy poziom przepływu prac.

Funkcje w systemie

Poziom IV - Koordynator 12

 

Koordynator weryfikuje poprawność i jakość wprowadzonych danych,

Wszelkie nieprawidłowości wykryte przez koordynatora są wycofywane na niższy poziom przepływu prac np.

błędna klasyfikacja nadzorcza, błędna klasyfikacja zdarzeń i incydentów, – –

Zatwierdzenie zdarzenia operacyjnego rzeczywistego przez najwyższy poziom przepływu prac uaktywnia opcję dodawania korekt do zdarzenia, finansowych i niefinansowych, oraz jego całkowitego rozliczenia, Sprawdza poprawność korekty pod względem merytorycznym, Całkowite rozliczenie zdarzenia operacyjnego rzeczywistego zostaje wywołane przez Koordynatora i następuje po spełnieniu łącznie dwóch poniższych warunków:

– –

zaksięgowaniu rzeczywistej straty/zysku z tytułu zdarzenia operacyjnego rzeczywistego na rachunku zysków i strat w BPS, wyczerpaniu możliwości odzysku np. z kwot ubezpieczenia, które zmieniłoby rzeczywistą kwotę straty/zysku z tytułu zdarzenia operacyjnego rzeczywistego.

13

Proces rejestracji danych Role w procesie rejestracji

DANE W SYSTEMIE AZRO ROLA UZUPE ŁNIAJĄCE KSI ĘGOWE PODSTAWOWE FINANSOWE

Rejestrator Akceptant Weryfikator Koordynator X X X X X X X X

x Wprowadzanie danych Uzupe ł nianie danych Modyfikacja danych x Weryfikacja danych

14

Proces ewidencji danych

Przepływ prac powinien być zakończony w ciągu 3 tygodni

Długi czas przechowywania informacji o zdarzeniu operacyjnym poza systemem Operon zwiększa prawdopodobieństwo zagubienia części danych co może utrudnić właściwą interpretację oraz prawidłowe zarejestrowanie zdarzenia.

15

Rodzaje ewidencjonowanych zdarzeń

Zdarzenia operacyjne (ze skutkiem finansowym)

– – – –

dane podstawowe – informacje identyfikujące zdarzenie, dane uzupełniające – informacje dotyczące jakościowej oceny zdarzenia, dane finansowe – informacje obejmujące wartościową wycenę zdarzenia, dane księgowe – informacje dotyczące rozksięgowania zdarzenia w ciężar kont wynikowych

.

Incydenty (bez skutku finansowego)

– –

dane podstawowe, dane uzupełniające.

Dane podstawowe

16

Dane zdarzenia dotyczące m.in. atrybutów ujawnienia, wystąpienia, przyczyny zdarzenia oraz jego skutku ewidencjonowane są w grupie danych podstawowych

– – Numer. referencyjny zdarzenia, Data rejestracji, – – – – – – – – – Miejsce rejestracji, Osoba rejestrująca, Sposób ujawnienia, Data wystąpienia, Miejsce wystąpienia, Skutek zdarzenia,  Odpis, Roszczenie w toku, Rozliczenia pozasądowe, Decyzje sądowe, Kary i grzywny, Strata lub uszkodzenie aktywów, Dodatni wpływ lub bez wpływu na wynik finansowy Opis zdarzenia Działania zaradcze Uwagi

Dane uzupełniające

17

       

Kategoria, Rodzaj, Grupa zdarzeń operacyjnych oraz zdarzenie operacyjne, Czynnik ryzyka operacyjnego, Linia biznesowa:

– W Banku BPS występują cztery linie biznesowe wyodrębnione z ośmiu wskazanych w NUK:   Działalność dealerska, Bankowość detaliczna,   Bankowość komercyjna, Płatności i rozliczenia.

+

„Działalność nie związana z czynnościami bankowymi”

.

Proces/Podproces Grupa Produktowa/Produkt Warstwa technologiczna Powiązanie z ryzykiem kredytowym Powiązanie z ryzykiem rynkowym

18

Dane finansowe

 

Charakter głównie ilościowy

– pozwalające określić potencjalną lub rzeczywistą kwotę związaną ze zdarzeniem operacyjnym rzeczywistym

Do danych finansowych zaliczamy:

– Waluta – – – Kwota potencjalna Kwota rzeczywista (strata/ zysk) Opis dodatkowy

Dane księgowe

19

 

Dane księgowe są następstwem danych finansowych,

– Konta WN (koszty) lub konta MA (zyski) – użytkownik wskazuje ścieżkę księgowania,

Dane księgowe:

– Konto – – – Waluta Kwota w walucie oryginalnej i bilansowej Tytuł pozycji księgowej

Status zdarzenia operacyjnego

20 Status zdarzenia Niezaakceptowane Zaakceptowane Niezatwierdzone Zatwierdzone Nierozliczone Rozliczone Wyjaśnienia

Oznacza zdarzenie operacyjne, które jest w trakcie rejestracji na poziomie Rejestratora lub Akceptanta lub Weryfikatora i nie zostało przez nich przekazane na poziom wyższy.

Oznacza zdarzenie operacyjne, które zostało przekazane na poziom wyższy przez Rejestratora lub Akceptanta lub Weryfikatora.

Oznacza zdarzenie operacyjne, które jest w trakcie rejestracji przez Koordynatora Oznacza zdarzenie operacyjne, które zostało zatwierdzone przez najwyższy poziom – przez Koordynatora. Oznacza zdarzenie operacyjne rzeczywiste, którego nie zostało rozliczone, ponieważ nie zostały spełnione obligatoryjne warunki:  zaksięgowanie rzeczywistej straty/zysku z tytułu zdarzenia operacyjnego  rzeczy-wistego na rachunku zysków i strat w BPS, wyczerpaniu możliwości odzysku np. z kwot ubezpieczenia, które zmieniłoby rzeczy-wistą kwotę straty/zysku z tytułu zdarzenia operacyjnego rzeczywistego Oznacza zdarzenie operacyjne rzeczywiste, dla którego została wywołana funkcja rozlicz przez Weryfikatora lub Koordynatora

Proces dodawania korekt do zarejestrowanych zdarzeń operacyjnych

21

Rodzaje korekt:

 – – –

Korekta finansowa -

wprowadza kwotę korygującą wartość wprowadzoną uprzednio do systemu

Odzysk -

operacja zwrotu części bądź całości straty - operacja rejestrowana jako „zysk”

Korekta do odzysku -

kwoty odzysku poprzez wprowadzenie kwoty korygującej wartość odzysku powtórne rozlicznie części bądź całości Dodanie korekty przebiega analogicznie jak przepływ prac przy rejestracji zdarzenia operacyjnego (Rejestrator → Akceptant → Weryfikator → Koordynator)

22 Dane do modelowania statystycznego

Do modelowania wykorzystano zdarzenia rzeczywiste oraz potencjalne Zewnętrzna baza strat (ZORO) OGON ROZKŁADU Analizy scenariuszowe i samoocena DANE UZUPEŁNIAJĄCE Wewnętrzna baza strat (Operon) STRATA OCZEKIWANA

Dane do modelowania statystycznego (2)

Zdarzenia podzielono według kryterium wysokości straty

Przedział Straty wewnętrzne Samoocena Analizy scenariuszowe Dane zewnętrzne Rzeczywiste Potencjalne 100 do 20000 MAŁE

TAK TAK TAK

od od

23

20000 do 100 000 ŚREDNIE

TAK

powyżej 100 000 DUŻE

TAK TAK TAK TAK TAK TAK TAK

24 Zmiany dokonane na potrzeby metody AMA

       zmiany funkcjonalności systemów wspierających zarządzanie ryzykiem operacyjnym; przystąpienie do bazy ZORO; aktualizacja regulacji wewnętrznych; zmiana metodyki samooceny ryzyka operacyjnego; zmiana metody przypisywania zdarzeń do linii biznesowych; wprowadzenie dodatkowych otoczenia gospodarczego); KRI (głównie wskaźników zwiększenie zatrudnienia (1 dodatkowy etat dedykowany do modelowania statystycznego).

25

Wymogi kapitałowe metodą BIA i AMA

 

Wymóg BIA (stosowany) –

32 mln PLN

Wymóg AMA (testowy) -

20 mln PLN

Dziękuję za uwagę!