Рішення Наглядової ради — це лише початок

Наглядова рада страховика затвердила Декларацію про ризик-апетит, визначила сукупний рівень ризику, який компанія готова приймати для досягнення своїх цілей, погодила ризик-апетит за суттєвими ризиками та систему відповідних лімітів. З формального погляду один із ключових елементів системи управління ризиками створено: межі встановлені, відповідальність розподілена, документ затверджений, але вже наступного робочого дня компанія продовжує жити своїм звичайним життям: андеррайтери укладають нові договори, змінюється структура страхового портфеля, надходять страхові виплати, перестраховики підтверджують або затримують відшкодування, фінансова служба розміщує кошти, виникає дебіторська заборгованість, ІТ-підрозділ реєструє інциденти, комплаєнс виявляє порушення, актуарії переглядають оцінки, а Правління приймає десятки рішень, кожне з яких тією чи іншою мірою змінює ризиковий профіль страховика. Затверджений ризик-апетит при цьому може залишатися незмінним, але фактичний ризик компанії змінюється постійно.

У цьому й полягає, мабуть, найбільша практична складність системи ризик-апетиту. Визначити показники, встановити ліміти та затвердити їх рішенням Наглядової ради недостатньо, оскільки потрібно створити механізм, який дозволяє постійно розуміти, де компанія перебуває відносно встановлених меж, чи не наближається вона до них, що спричинило зміну ризикової позиції та що потрібно робити, якщо тенденція стає несприятливою, причому система повинна реагувати не лише на вже здійснений факт перевищення ліміту. Якщо функція управління ризиками дізнається про проблему лише тоді, коли встановлену межу вже порушено, значна частина управлінського сенсу ризик-апетиту втрачається: хороший моніторинг має дозволяти побачити небезпечний рух раніше, ніж компанія опиниться за встановленою нею ж межею.

За коротким формулюванням «моніторинг ризик-апетиту» тому приховується велика кількість щоденної й часто досить рутинної роботи. Необхідно визначити джерела інформації для кожного показника, відповідальних за її надання, періодичність оновлення, правила розрахунку та перевірки даних; порівнювати фактичні значення з цільовими рівнями, порогами раннього попередження та лімітами; аналізувати не лише поточне значення, а й тенденцію його зміни; визначати причини відхилень; своєчасно передавати інформацію тим органам і посадовим особам, які мають право приймати рішення; контролювати виконання погоджених заходів і перевіряти, чи повернувся ризик до прийнятної зони. До цього додається ще складніше завдання: окремі ліміти можуть формально дотримуватися, але одночасне погіршення кількох ризиків здатне змінити сукупний ризиковий профіль настільки, що компанія наблизиться до затвердженого сукупного ризик-апетиту, отже, контролювати потрібно не лише кожний показник окремо, а й картину в цілому.

Тому ця стаття буде не стільки про те, що таке ризик-апетит, скільки про те, як із ним жити після затвердження: хто повинен контролювати дотримання встановлених меж, звідки надходить інформація, як часто її потрібно отримувати, чим відрізняється нормальна ситуація від раннього попередження, коли потрібна ескалація, хто має приймати рішення при перевищенні ліміту, як контролювати виконання заходів і за яких обставин проблема полягає вже не у фактичному ризиковому профілі, а в тому, що сам затверджений ризик-апетит перестав відповідати бізнесу компанії. Іншими словами, спробуємо подивитися на ризик-апетит не як на розділ внутрішнього документа, а як на постійно діючий управлінський механізм.

Від Декларації до щоденного управління

Після затвердження ризик-апетиту виникає перше практичне питання: як верхньорівневе рішення Наглядової ради має дійти до співробітника, який сьогодні приймає конкретне рішення? Андеррайтер не може щоразу перед укладанням договору оцінювати його вплив на сукупний ризик-апетит компанії, фахівець із перестрахування — перераховувати весь ризиковий профіль перед кожним розміщенням, а ІТ-підрозділ — співвідносити кожну технологічну зміну безпосередньо із затвердженою величиною сукупного ризику. Для цього верхньорівневий ризик-апетит і конкретизується за суттєвими ризиками, а далі переводиться в систему лімітів, допустимих відхилень, ключових індикаторів ризику та інших обмежень, зрозумілих тим, хто щодня управляє відповідними процесами. Практичний сенс такого каскадування полягає в тому, що рішення Наглядової ради має перетворитися на межі, які можна застосувати до конкретної операції, портфеля, контрагента, процесу або управлінського рішення.

Припустимо, компанія визначила певний ризик-апетит щодо страхового ризику. Для андеррайтингу це рішення може бути переведене у максимальне власне утримання, обмеження концентрації за окремими видами страхування, територіями або великими ризиками, вимоги до перестрахового захисту та показники збитковості, за якими відстежується зміна якості портфеля. Для кредитного ризику практичними межами можуть стати концентрація коштів на одному банку або вимог до одного перестраховика, для ризику ліквідності — мінімальний запас ліквідних активів та показники очікуваних грошових потоків, для ІТ-ризику — допустима тривалість простою критичних систем, строки їх відновлення та кількість критичних інцидентів. Частина цих показників є лімітами, частина — ключовими індикаторами ризику, частина може виконувати функцію раннього попередження, і змішувати їх між собою не варто. Проте всі вони мають виконувати спільне завдання: перекладати верхньорівневу готовність компанії приймати ризик на мову конкретних управлінських рішень.

Саме тут починається щоденний контроль. Для кожного показника повинно бути зрозуміло не лише його затверджене значення, а й фактичне значення на відповідну дату, джерело даних, відповідальний підрозділ, періодичність оновлення та порядок дій при наближенні до встановленої межі. Якщо, наприклад, ліміт концентрації на певного контрагента контролюється лише раз на квартал, тоді як операції з ним здійснюються щодня, формально правильний показник може виявитися практично непридатним для управління, і навпаки, немає сенсу щодня вимагати інформацію за показником, який за своєю природою змінюється повільно і достовірно розраховується лише після завершення звітного періоду. Тому періодичність контролю повинна визначатися не зручністю складання звіту функцією управління ризиками, а швидкістю, з якою відповідний ризик здатний змінитися та привести компанію до порушення встановленої межі.

Не менш важливо розрізняти контроль фактичного значення і контроль тенденції. Умовно кажучи, ліміт певного показника становить 20%, а його фактичне значення дорівнює 14%. Формально все гаразд, але якщо три місяці тому показник становив 8%, два місяці тому — 10%, минулого місяця — 12%, а зараз уже 14%, для ризик-менеджера це зовсім інша ситуація, ніж стабільні 14% протягом року. Ліміт ще не порушено, але напрям і швидкість руху вже несуть управлінську інформацію. Звідси виникає потреба в порогах раннього попередження, які дозволяють відокремити звичайний режим роботи від ситуації, коли ризик усе ще залишається прийнятним, але його подальша динаміка потребує уваги. У найпростішому вигляді це можна уявити як зелену, жовту та червону зони, хоча практичний зміст такої моделі полягає не в кольорах, а в тому, що кожній зоні має відповідати заздалегідь визначена управлінська реакція.

У зеленій зоні компанія не просто констатує відсутність порушень, а продовжує регулярний моніторинг і аналіз тенденцій. Перехід у зону раннього попередження повинен означати вже інший режим: з’ясування причин погіршення, оцінку прогнозу, інформування відповідального власника ризику, а за потреби — підготовку превентивних заходів, поки ліміт ще не порушений. Перевищення встановленої межі переводить ситуацію на наступний рівень, де потрібні формальна ескалація, визначення заходів, відповідальних і строків, а в окремих випадках — рішення Правління або Наглядової ради. Якщо ж одна й та сама таблиця просто щомісяця забарвлює показники зеленим, жовтим і червоним кольором, але перехід між зонами не змінює поведінку компанії, перед нами система візуалізації ризиків, а не система управління ними.

Є ще одна принципова обставина — контроль ризик-апетиту не може бути виключною роботою функції управління ризиками. Підрозділ ризик-менеджменту фізично не створює більшість первинних даних і не управляє більшістю ризикових експозицій: договори укладає андеррайтинг, виплати здійснює врегулювання, коштами управляє фінансова функція, перестрахуванням — відповідний підрозділ, інформаційними системами — ІТ. Тому власник ризику та відповідний бізнес-підрозділ повинні першими бачити свою ризикову позицію, контролювати встановлені для них обмеження і реагувати на небезпечну динаміку, тоді як функція управління ризиками забезпечує незалежний погляд на цю інформацію, перевіряє дотримання встановленої системи меж, аналізує взаємний вплив ризиків, агрегує картину на рівні компанії та забезпечує ескалацію там, де рішення виходить за межі повноважень першої лінії.

Таким чином, після затвердження Декларації починається безперервний цикл: фактична діяльність змінює ризиковий профіль → зміна відображається у відповідних показниках → показники порівнюються з установленими межами → відхилення або несприятлива тенденція запускають управлінську реакцію → результат цієї реакції знову змінює ризиковий профіль. І цей цикл працює лише за умови, що в кожній його точці зрозуміло, хто відповідає за ризик, хто формує інформацію, хто здійснює незалежний контроль, кому вона передається і хто має право прийняти необхідне рішення, тому наступне питання цілком закономірне: хто конкретно і за що відповідає в цій системі — від власника ризику до Наглядової ради?

Хто за чим стежить: від власника ризику до Наглядової ради

Фраза «контроль за дотриманням ризик-апетиту здійснюється на всіх рівнях управління» звучить правильно, але для практичної роботи майже нічого не пояснює. Якщо всі контролюють усе, дуже швидко може виявитися, що в момент виникнення проблеми ніхто не вважає її своєю: бізнес-підрозділ переконаний, що за лімітами стежить ризик-менеджер, ризик-менеджер очікує повідомлення від власника ризику, Правління дізнається про перевищення під час підготовки чергового звіту, а Наглядова рада отримує вже історичну інформацію про подію, щодо якої всі необхідні рішення давно мали бути прийняті. Тому система працює лише тоді, коли для кожного ризику та кожного контрольованого показника заздалегідь зрозуміло, хто формує первинну інформацію, хто контролює ризик у процесі діяльності, хто здійснює незалежний моніторинг, хто приймає рішення при наближенні до встановленої межі та кому і за яких умов питання має бути ескальоване.

Першим у цьому ланцюгу є власник ризику та відповідний бізнес-підрозділ, оскільки ризик виникає не в таблиці ризик-менеджера, а в реальній діяльності компанії. Уявімо, що страховик установив граничну концентрацію певної категорії ризиків у портфелі на рівні 20%, а поріг раннього попередження — 17%. На початку місяця фактична концентрація становить 15%, але андеррайтинговий підрозділ отримує пропозицію щодо кількох великих договорів, укладення яких збільшить її до 18,5%. Формального перевищення ліміту ще немає, і якби компанія контролювала показник лише за фактом на кінець місяця, договори можна було б укласти, а про зміну ризикової позиції функція управління ризиками дізналася б пізніше. У нормально побудованій системі перша лінія повинна бачити наслідки свого рішення до його прийняття: вихід за поріг раннього попередження означає необхідність оцінити подальші можливості прийняття аналогічних ризиків, потребу в додатковому перестраховому захисті або інші заходи, а за встановленими внутрішніми правилами — повідомити функцію управління ризиками. Ризик ще не став неприйнятним, але компанія вже повинна змінити режим управління ним.

Роль функції управління ризиками в такій ситуації полягає не в тому, щоб замість андеррайтера вирішити, укладати договори чи ні, — вона повинна незалежно оцінити, як запропоноване рішення впливає на встановлені межі, чи враховано всі пов’язані ризики та чи не створює нова концентрація проблем на рівні сукупного ризикового профілю. Припустимо, андеррайтинг обґрунтовує укладення договорів високою очікуваною прибутковістю та наявністю перестрахового захисту. Ризик-менеджер при цьому бачить, що частина ризику передається перестраховику, на якого вже припадає значна частка чинних відшкодувань, і тоді рішення, яке з погляду страхового ризику виглядає прийнятним, може одночасно збільшувати контрагентський ризик. Завдання другої лінії — побачити цей зв’язок, якого може не бути в полі зору окремого бізнес-підрозділу, і дати органу, що приймає рішення, цілісну картину, а не просто повідомити, що показник змінив колір із зеленого на жовтий.

Інша ситуація може виникнути у врегулюванні збитків. Припустимо, протягом двох тижнів компанія отримала декілька великих заявлених збитків, і прогноз страхових виплат суттєво зріс. Сам по собі встановлений ліміт страхового ризику ще не порушено, але одночасно очікується затримка значного перестрахового відшкодування. Для підрозділу врегулювання це насамперед питання виконання зобов’язань перед страхувальниками, для підрозділу перестрахування — питання роботи з перестраховиком, для фінансової функції — питання грошових потоків, а для ризик-менеджера всі три обставини мають скластися в одну картину: подія, яка починалася як страховий ризик, може створити проблему ліквідності ще до того, як остаточний фінансовий збиток стане відомим. Якщо система побудована правильно, функція управління ризиками не чекатиме кінця кварталу, щоб відобразити це у профілі ризиків, а оцінить вплив на ліквідну позицію та необхідність ескалації одразу після отримання суттєвої інформації.

Саме тут проходить межа між моніторингом і управлінським рішенням. Функція управління ризиками повинна виявити проблему, оцінити її значущість, перевірити дотримання встановлених меж, проаналізувати можливий подальший розвиток і забезпечити своєчасну ескалацію, але вона не повинна підміняти собою Правління. Якщо повернутися до попереднього прикладу, рішення може полягати в тимчасовому обмеженні певних нових операцій, зміні структури ліквідних активів, прискоренні роботи з перестраховиком, коригуванні плану грошових потоків або застосуванні декількох заходів одночасно, і це вже управлінський вибір, у якому необхідно враховувати не лише величину ризику, а й вартість заходів, їх вплив на бізнес та можливі альтернативи. Завдання ризик-менеджера — зробити так, щоб це рішення приймалося з повним розумінням ризикових наслідків і не суперечило встановленому ризик-апетиту.

Розглянемо ще один приклад, у якому формального порушення взагалі немає. Компанія встановила ключовий індикатор для простроченої дебіторської заборгованості, і протягом чотирьох місяців його значення послідовно змінюється з 4% до 5,5%, потім до 7% і нарешті до 8,5%, тоді як поріг раннього попередження встановлений на рівні 10%. Якщо дивитися лише на поточне значення, ситуація залишається зеленою, але послідовність показує стійкий негативний тренд, і ризик-менеджер має поставити питання раніше, ніж показник формально перейде в жовту зону: що відбувається зі структурою заборгованості, чи пов’язане зростання з одним великим контрагентом або є системним, який строк погашення, чи достатньо ефективно працює процедура стягнення, яким буде показник через місяць за збереження поточної тенденції? Такий аналіз добре демонструє, чому контроль ризик-апетиту не можна звести до механічного порівняння фактичного значення з лімітом. Ризик-менеджмент повинен бачити не лише місце, де компанія перебуває сьогодні, а й напрям, у якому вона рухається.

Правління включається в систему не лише після перевищення ліміту, оскільки частина ситуацій повинна потрапляти на його рівень ще в зоні раннього попередження, якщо можливі заходи виходять за межі повноважень власника ризику або здатні суттєво вплинути на бізнес. Уявімо, що збитковість певного страхового продукту три місяці поспіль погіршується і наблизилася до встановленого порогу, хоча ліміт ще не перевищено. Андеррайтинг пропонує підвищити тариф, продажі заперечують, оскільки це може призвести до втрати частини клієнтів, актуарна функція підтверджує погіршення очікуваного результату, а ризик-менеджер показує, що за збереження тенденції через два місяці компанія з високою ймовірністю вийде за встановлену межу. Це вже не технічне питання контролю показника, а бізнес-рішення: продовжувати зростання, змінити тарифну політику, переглянути умови страхування, скоротити прийняття певних ризиків або свідомо допустити тимчасове наближення до межі, і таке рішення має приймати той орган, який має відповідні повноваження та відповідає за результати діяльності компанії.

Наглядова рада перебуває ще на іншому рівні, оскільки її завдання полягає не в оперативному розгляді кожного жовтого індикатора і тим більше не в управлінні окремими договорами, контрагентами чи ІТ-інцидентами. Вона затвердила ризик-апетит і повинна отримувати достатню інформацію, щоб розуміти, чи працює компанія в установлених межах, чи не виникають системні відхилення, чи адекватно Правління реагує на суттєві порушення та чи не змінився ризиковий профіль настільки, що потрібен перегляд самого ризик-апетиту. Якщо певний ліміт короткостроково перевищено, але Правління має затверджений план повернення до прийнятної зони і ситуація не створює суттєвої загрози, рівень залучення Наглядової ради буде одним. Якщо ж перевищення стосується ключової верхньорівневої межі, повторюється, не усувається в установлені строки або свідчить про те, що стратегія компанії фактично перестала відповідати затвердженому ризик-апетиту, це вже інший рівень питання.

Особливо небезпечною є ситуація, коли перевищення намагаються «виправити» зміною самого ліміту. Припустимо, концентрація на одному контрагенті перевищила встановлені 20% і досягла 24%. Найпростіше рішення — запропонувати підвищити ліміт до 25%, після чого формальне порушення зникне. Іноді перегляд ліміту справді може бути обґрунтованим, якщо змінилися бізнес-модель, структура портфеля, фінансові можливості або інші передумови, на яких він був установлений, але якщо єдиною причиною перегляду є вже здійснене перевищення, система ризик-апетиту втрачає сенс: замість того щоб обмежувати ризик, ліміт починає пристосовуватися до фактичної поведінки компанії. Тому будь-яке рішення про підвищення межі після її перевищення повинно містити відповідь на питання, що фундаментально змінилося порівняно з моментом її затвердження і чому новий рівень ризику тепер вважається прийнятним.

У результаті відповідальність можна описати досить просто, хоча за цією простотою стоїть велика організаційна робота: перша лінія управляє ризиком і контролює його там, де він виникає; функція управління ризиками незалежно оцінює ситуацію, бачить взаємозв’язки, контролює дотримання встановлених меж та забезпечує ескалацію; Правління приймає управлінські рішення в межах своїх повноважень і забезпечує повернення ризику до прийнятного рівня; Наглядова рада контролює дотримання затвердженого ризик-апетиту та приймає рішення з питань, що належать до її компетенції. При цьому жоден із цих рівнів не може працювати без іншого: ризик-менеджер не здатний контролювати те, про що не отримує інформації, Правління не може своєчасно реагувати на те, що не було ескальовано, а Наглядова рада не може здійснювати належний контроль, якщо бачить лише квартальну фотографію ризиків без пояснення того, як і чому вона змінилася.

І тут ми підходимо до, можливо, найбільш приземленої, але критично важливої частини всієї системи. Щоб андеррайтер, власник ризику, ризик-менеджер, Правління та Наглядова рада могли виконувати описані функції, хтось повинен своєчасно дати їм правильні дані, причому дані про капітал можуть надходити з одного джерела, про збитковість — з іншого, про перестрахування — з третього, про ІТ-інциденти — взагалі з окремої системи, а частина інформації може існувати лише у вигляді ручних реєстрів або повідомлень відповідальних підрозділів. Тому наступний рівень нашої повсякденної роботи — це питання, без якого вся красива архітектура ризик-апетиту просто не запрацює: звідки ризик-менеджер насправді бере інформацію і як побудувати її регулярний рух усередині компанії?

Звідки беруться дані: інформаційна система ризик-апетиту

Можна побудувати бездоганну методологію ризик-апетиту, правильно розподілити відповідальність, установити ліміти та пороги раннього попередження, але вся ця конструкція втрачає практичну цінність, якщо ризик-менеджер отримує необхідну інформацію із запізненням, у різних форматах або взагалі дізнається про суттєву подію випадково. У реальному страховику навряд чи існує одна інформаційна система, у якій натисканням кнопки можна побачити весь фактичний ризиковий профіль компанії: дані про страхові премії та портфель містяться в страховій обліковій системі, інформація про виплати та заявлені збитки — у системі врегулювання, відомості про перестрахування — у відповідному реєстрі або модулі, про кошти й дебіторську заборгованість — у фінансовому та бухгалтерському обліку, про капітал і платоспроможність — у регуляторній та управлінській звітності, про ІТ-інциденти — у власних системах ІТ-підрозділу, а інформація про комплаєнс-події, скарги, судові справи або операційні інциденти нерідко формується окремими підрозділами. Хоча, можливо, така система і існує, просто мені не поталанило побачити її на власні очі.  Тому одна з найменш помітних зовні, але найбільш трудомістких функцій ризик-менеджменту полягає у створенні регулярного інформаційного потоку, який перетворює розрізнені факти діяльності компанії на систему показників, придатних для управління ризиками.

Починати цей процес варто не з питання «який звіт мені надсилатимуть щомісяця?», а з кожного конкретного показника, який компанія вирішила контролювати. Для нього потрібно визначити джерело первинних даних, підрозділ, відповідальний за їх формування, порядок розрахунку, дату або подію, після якої інформація має бути надана, а також того, хто перевіряє її коректність. Якщо встановлено ліміт концентрації страхового портфеля, ризик-менеджеру необхідно знати не просто його величину, а звідки береться чисельник і знаменник показника, на яку дату вони розраховуються та як швидко в них відображаються нові договори. Якщо контролюється прострочена дебіторська заборгованість, необхідно однаково розуміти, з якого дня вона вважається простроченою та які види заборгованості включаються до розрахунку. Якщо показником ІТ-ризику є тривалість недоступності критичної системи, повинно бути зрозуміло, хто фіксує початок і завершення інциденту та які системи вважаються критичними. Інакше через кілька місяців можна виявити, що всі підрозділи справно подавали інформацію, але фактично рахували різні речі.

Уявімо просту ситуацію — компанія контролює концентрацію коштів у банках і встановила для кожного банку відповідний ліміт. Фінансова служба раз на місяць передає ризик-менеджеру залишки на рахунках, і протягом тривалого часу всі показники перебувають у зеленій зоні, але одного дня компанія отримує значну страхову премію та тимчасово розміщує більшу частину коштів в одному банку. Наступний регулярний звіт має бути сформований лише через три тижні, і якщо єдиним джерелом контролю є місячна таблиця, компанія може майже місяць перебувати за встановленою межею, не відображаючи цього у своїй системі моніторингу. Проблема тут не в неправильно встановленому ліміті і навіть не обов’язково в неправильній дії фінансової служби — проблема в тому, що частота контролю не відповідає швидкості зміни ризику. Для такого показника може бути потрібен значно частіший автоматизований або ручний контроль, а для великої операції — перевірка ліміту ще до її здійснення.

Зовсім інша ситуація виникає з показником збитковості страхового продукту. Вимагати його повноцінного перерахунку після кожної страхової виплати навряд чи має сенс, оскільки окрема операція може суттєво викривляти короткострокову картину, а для змістовного аналізу потрібен певний період спостереження. Тут місячний контроль може бути цілком достатнім, але ризик-менеджеру важливо бачити не лише останню цифру, а часовий ряд, структуру збитків та причини зміни. Наприклад, збитковість послідовно зростає з 48% до 52%, потім до 57% і 61%. Ліміт, припустимо, встановлений на рівні 70%, тому формально порушення немає, але якщо зростання спричинене не одним великим збитком, а поступовим погіршенням результатів у певному сегменті портфеля, інформація про це може вимагати управлінської реакції задовго до досягнення 70%. Отже, джерелом інформації для ризик-менеджера є вже не одна цифра зі звіту, а поєднання самого показника, його динаміки та пояснення причин зміни.

Ще складніше працювати з ризиками, для яких інформація не народжується автоматично у фінансовій або страховій системі. Візьмемо операційний ризик. Співробітник помилився під час введення даних, помилку виявили наступного дня та виправили без фінансових наслідків. В іншому підрозділі через збій протягом двох годин не працювала важлива система, але клієнти суттєвих наслідків не відчули. В третьому випадку помилка призвела до неправильної виплати, частину якої вдалося повернути. Якщо компанія реєструє лише події, які вже спричинили фактичний фінансовий збиток, перші дві ситуації можуть взагалі не потрапити до поля зору ризик-менеджменту, проте повторення подібних інцидентів здатне бути набагато важливішим сигналом, ніж одна невелика фактична втрата. Тому для операційного ризику потрібне джерело інформації, яке дозволяє фіксувати не лише збитки, а й події, порушення, збої та ситуації, які могли призвести до негативних наслідків, але цього разу їх вдалося уникнути.

Практично це означає необхідність журналу ризикових подій або іншого аналогічного механізму, причому його цінність визначається не красою форми, а тим, чи знають співробітники, що і коли вони повинні повідомляти. Якщо кожен ІТ-збій, операційна помилка або скарга проходять складну процедуру з десятьма полями, погодженнями та пояснювальними записками, люди дуже швидко навчаться реєструвати лише те, що вже неможливо приховати. Якщо ж критерії суттєвості сформульовані зрозуміло, форма повідомлення проста, а сама реєстрація не сприймається як пошук винного, компанія поступово отримує власну історію ризикових подій, без якої оцінювати операційний ризик доводиться переважно експертно. Для ризик-менеджера тут особливо важливо відрізняти одиничну випадкову подію від повторюваного сигналу: п’ять однакових дрібних помилок протягом місяця можуть розповісти про стан процесу більше, ніж один значний, але унікальний інцидент.

Окремої уваги потребує зовнішня інформація. Припустимо, всі внутрішні показники щодо перестраховика залишаються в межах установлених лімітів: прострочених відшкодувань немає, концентрація прийнятна, договори виконуються, але на ринку з’являється інформація про погіршення його фінансового стану або зниження рейтингу. Якщо система моніторингу дивиться лише на внутрішню бухгалтерську інформацію, індикатор залишатиметься зеленим до моменту, коли проблема проявиться безпосередньо у відносинах із компанією. Аналогічна ситуація можлива з банком, великим корпоративним страхувальником або навіть окремим сегментом страхового ринку, тому джерелами інформації для системи ризик-апетиту повинні бути не тільки внутрішні бази даних, а й релевантна зовнішня інформація: повідомлення регулятора, рейтингових агентств, офіційна фінансова інформація контрагентів, зміни законодавства, ринкові показники та інші джерела, здатні завчасно вказати на зміну ризику.

Іноді найбільш цінна інформація взагалі не виглядає як показник ризику: різке збільшення кількості скарг може передувати проблемі у врегулюванні збитків; збільшення кількості ручних коригувань у страховій системі — свідчити про недоліки процесу або ІТ-рішення; постійні затримки підрозділу з наданням регуляторної звітності — сигналізувати про ризик майбутнього порушення строків; зростання частки договорів, укладених із винятками із стандартних правил андеррайтингу, — поступово змінювати якість портфеля, хоча поточна збитковість ще залишається прийнятною. У таких випадках завдання ризик-менеджера полягає не лише в отриманні готових цифр, а у визначенні випереджальних індикаторів, які здатні показати проблему до того, як вона проявиться у фінансовому результаті або порушенні встановленого ліміту.

Звідси випливає ще один важливий практичний принцип: не всі показники повинні контролюватися з однаковою періодичністю. Частину ризиків доцільно контролювати в момент здійснення операції, частину — щодня або щотижня, інші — щомісяця чи щокварталу, а для окремих подій регулярного календаря взагалі недостатньо. Критичний ІТ-інцидент, суттєвий страховий збиток, різке погіршення стану ключового контрагента або виявлене значне порушення не можуть чекати наступної дати подання звіту. Для них має діяти подієве інформування: певна подія автоматично або за встановленою процедурою запускає повідомлення власнику ризику, функції управління ризиками та, залежно від її суттєвості, іншим визначеним особам.

На практиці тому корисно мати для кожного контрольованого показника своєрідний інформаційний паспорт: що вимірюється, з якого джерела надходять дані, хто є їх власником, хто здійснює розрахунок, як часто показник оновлюється, яке його цільове значення, де починається зона раннього попередження, де проходить ліміт, кому і протягом якого часу надсилається інформація при відхиленні та хто відповідає за подальші дії. Це може бути звичайна робоча таблиця, а не ще один багатосторінковий внутрішній документ, але така таблиця часто дає для реальної роботи більше, ніж загальне положення про те, що «функція управління ризиками здійснює постійний моніторинг ризиків».

Наприклад, для великого страхового збитку запис у такій таблиці може означати: джерело — система врегулювання; відповідальний за первинну інформацію — підрозділ врегулювання; звичайний контроль — щоденний; при збитку понад визначений поріг — повідомлення в день реєстрації; одержувачі — відповідний керівник, функція управління ризиками, фінансова функція та перестрахування; наступний крок — оцінка власного утримання, очікуваного перестрахового відшкодування та впливу на ліквідність. Для простроченої дебіторської заборгованості логіка буде іншою: джерело — бухгалтерський облік, оновлення — щотижневе або місячне залежно від суттєвості, додатково контролюється тренд і концентрація за найбільшими боржниками. Для ІТ-ризику — третя: критичний інцидент повідомляється негайно, а накопичена статистика щодо кількості, тривалості та причин інцидентів аналізується за встановленою періодичністю. Одна система ризик-апетиту, але зовсім різна інформаційна логіка для різних ризиків.

І тут виникає ще одна дуже життєва проблема — якість даних. Уявімо, що функція управління ризиками щомісяця отримує від десяти підрозділів двадцять п’ять показників, сумлінно переносить їх до загальної таблиці, розфарбовує відповідно до встановлених зон і готує звіт Правлінню. Через пів року з’ясовується, що один підрозділ розраховував показник за даними на кінець місяця, інший — наростаючим підсумком, третій змінив алгоритм розрахунку, але нікого про це не повідомив, а четвертий протягом трьох місяців просто копіював значення з попереднього звіту, оскільки відповідальний співробітник звільнився. Формально моніторинг здійснювався безперервно, але фактично компанія частину часу контролювала не ризики, а таблицю.

Тому функція управління ризиками не повинна беззастережно перетворювати будь-яку отриману цифру на офіційний показник ризикового профілю. Потрібні елементарні процедури контролю якості: порівняння з попередніми періодами, перевірка аномальних змін або, навпаки, підозрілої незмінності показника, звірка пов’язаних даних із різних джерел, фіксація змін методики розрахунку та, де це можливо, автоматизація отримання інформації без ручного переписування. Якщо показник раптом зменшився з 18% до 7%, хорошою реакцією ризик-менеджера буде не негайно пофарбувати клітинку зеленим, а спочатку запитати, що сталося з ризиком або з даними.

У підсумку інформаційна система контролю ризик-апетиту може виглядати значно простіше, ніж іноді здається. Її базова логіка вкладається в один ланцюг: джерело даних → відповідальний → показник → періодичність або подія → фактичне значення і тенденція → поріг раннього попередження → ліміт → одержувач інформації → необхідна дія. Якщо хоча б одна ланка цього ланцюга не визначена, існує ризик, що потрібна інформація або не з’явиться, або з’явиться тоді, коли управляти ситуацією буде вже значно дорожче й складніше.

Але припустимо, що інформаційний механізм ми побудували: дані надходять своєчасно, показники розраховуються однаково, тенденції видно, відповідальні визначені, і тепер на екрані ризик-менеджера умовно з’являються три показники: один зелений, другий жовтий, третій червоний. Що конкретно має відбутися в компанії в кожному з цих трьох випадків? Бо найбільша помилка починається тоді, коли зелений означає «нічого не робимо», жовтий — «візьмемо до уваги», а червоний — «відобразимо у квартальному звіті». Це вже тема наступного розділу.

Побачити ризик — ще не означає ним управляти

Отже, рішення Наглядової ради про затвердження ризик-апетиту не завершує роботу з ним, а переводить її в зовсім іншу площину. Відтепер компанія повинна щодня співвідносити фактичну діяльність із тими межами ризику, які вона для себе встановила. Для цього верхньорівневий ризик-апетит переводиться в конкретні ліміти, допустимі відхилення та ключові індикатори ризику; визначаються власники ризиків і відповідальні за показники; встановлюються джерела даних, порядок їх розрахунку та періодичність отримання; створюються пороги раннього попередження та правила інформування, і лише після цього затверджена Декларація перестає бути документом, до якого повертаються під час підготовки чергового звіту, і перетворюється на частину повсякденного управління страховиком.

При цьому найбільш складна частина такої роботи часто залишається непомітною. Ризик-менеджер отримує інформацію з різних систем і від різних підрозділів, перевіряє її, порівнює з попередніми періодами, аналізує незвичні зміни, стежить за тенденціями, повертається до власників даних із запитаннями, з’ясовує причини відхилень і намагається зрозуміти не лише те, де компанія перебуває сьогодні, а й куди вона рухається. Частина цієї роботи може бути автоматизована, але значна її частина ще довго залишатиметься професійним аналізом: одна й та сама зміна показника може бути випадковим коливанням, наслідком одиничної події або першою ознакою системної проблеми. Таблиця покаже цифру, але не пояснить її економічного змісту і тим більше не вирішить, чи потрібно компанії щось робити.

У результаті перед ризик-менеджером поступово складається картина, яка умовно може виглядати дуже просто: більшість показників перебуває в зеленій зоні, декілька наблизилися до встановлених порогів, один перейшов у жовту, а ще один перевищив ліміт і став червоним. На цьому етапі можна сказати, що система моніторингу працює: компанія бачить свій фактичний ризиковий профіль, розуміє його динаміку та здатна вчасно виявляти відхилення, але це ще не означає, що працює система управління ризиками. Моніторинг відповідає на запитання «що відбувається?», тоді як управління починається з наступного: «що ми тепер із цим робимо?»

І це питання значно складніше, ніж може здатися. Чи потрібно реагувати на показник, який залишається зеленим, але чотири місяці поспіль погіршується? Що конкретно повинно відбутися після переходу в жовту зону: достатньо повідомити власника ризику чи вже потрібен план заходів? Хто і протягом якого строку має його підготувати? Чи можна продовжувати операції, які збільшують відповідний ризик? Що робити після перевищення ліміту: негайно припиняти операції, зменшувати експозицію, передавати частину ризику, погоджувати тимчасове відхилення або в окремих випадках переглядати сам ліміт? Хто має право прийняти кожне з цих рішень і коли інформація повинна перейти від власника ризику до функції управління ризиками, від неї — до Правління, а від Правління — до Наглядової ради?

Є й складніше питання. Припустимо, жодного червоного показника взагалі немає: збитковість зросла, але залишається в допустимих межах; перестрахове відшкодування затримується, але критичного строку ще не досягнуто; дебіторська заборгованість збільшується, але ліміт не порушено; запас ліквідності скоротився, проте формально залишається достатнім. Кожен власник ризику окремо може доповісти: ситуація контрольована, але чи означає це, що компанія в цілому залишається в межах затвердженого сукупного ризик-апетиту? Можливо, чотири жовтих сигнали, які виникли одночасно і пов’язані між собою, для страховика важливіші за один червоний.

Тому після побудови системи постійного контролю починається наступний етап — перетворення отриманої інформації на рішення. І тут нам доведеться пройти весь шлях ще раз, але вже в іншому напрямі: сигнал → оцінка → ескалація → управлінське рішення → план заходів → контроль виконання → повернення ризику до прийнятної зони, а іноді цей шлях приведе до зовсім іншого висновку: змінилася не лише фактична ризикова позиція компанії, а й умови, на яких колись був установлений її ризик-апетит, і переглядати потрібно вже його.

На цьому поставимо крапку в першій частині. Ми побудували систему, яка дозволяє компанії бачити ризик, тепер подивимося, як навчити її діяти відповідно до того, що вона побачила.

Сергій БАБИЧ