Основні банківські, хмарні, аутсорсингові та технологічні регулювання

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

Що робить основна банківська система

Основна банківська система є головною книгою записів. У ній зберігаються дані про клієнтів і рахунки, відображається кожна операція, розраховуються відсотки та комісії, а також створюються баланси, на яких засновано все інше.

До типових функцій належать:

Функція	Що це включає
Керування клієнтами і рахунками	Реєстри клієнтів, відкриття рахунків, умови використання продуктів, стан рахунків
Книга обліку і оподаткування	Реальний час або пакетний запис дебетів і кредитів, подачі загальної книги
Вкладення	Текущі, накопичувальні та строкові рахунки, нарахування відсотків і капіталізація
Позайм	Інтерфейси створення кредитів, розклади, погашення, заборгованості, подачі пропозицій
Інтерфейси оплати	З’ єднання з платіжними центрами, обробниками карток і рахунками кореспондентів
Налаштування продукту	Ставки, платежі, обмеження і правила без змін коду
Дані і звіти	Витяги для фінансів, ризику, регуляторних звітів і моніторингу AML

Навколо ядра розташовані інші системи: цифрові канали, платіжний центр, управління картками, впровадження клієнтів і перевірка особистості, відстеження санкцій, моніторинг транзакцій, казна, фінанси та регулятивний рушій звітності.

Параметри архітектури

Нові банки зазвичай вибирають між трьома моделями.

1. Ліцензійне програмне забезпечення, розміщене банком або провайдером. Банк контролює налаштування і дані, але несе відповідальність за інтеграцію.
2. Програмне забезпечення як послуга на хмарній платформі. Швидше запускати, але банк залежить від дорожньої карти і стійкості постачальника, а угода є аутсорсингом.
3. Банківський обслуговування від іншого ліцензованого установи. Найшвидший шлях, але це може викликати питання про те, чи новий банк має достатньо власної субстанції.

Наглядові органи не визначають модель. Вони оцінюють, чи розуміє банк і контролює ту, яку він вибрав.

Правила аутсорсингу

Аутсорсинг означає, що постачальник послуг виконує процес, службу або діяльність, яку банк в іншому випадку виконав би самостійно. У ЄС EBA Настанови щодо аутсорсингу (EBA/GL/2019/02) набули чинності 30 вересня 2019 року. Вони замінили попередні рекомендації, зокрема окрему рекомендацію EBA щодо аутсорсингу постачальникам хмарних послуг.

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

Критичні або важливі функції

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

1. Виконувати оцінку ризиків і належні дії щодо постачальника перед підписанням договору.
2. Включити договірні права доступу, інформації та аудиту для банку і компетентного органу.
3. Контроль суб-аутсорсингу, включаючи попередження і право на заперечення або припинення.
4. Визначте вимоги до безпеки даних, розташування та конфіденційності.
5. Задокументували і перевірили стратегії виходу.
6. Попередньо інформувати компетентні органи про запланований критичний або важливий аутсорсинг.

Всі договори повинні бути зареєстровані в реєстрі аутсорсингу, який веде банк.

За межами ЄС

Аналогічні правила застосовуються в інших місцях. У Великій Британії, PRA Наглядова заява SS2/21 про аутсорсинг і управління ризиками третіх осіб, опублікована в березні 2021 року і діє з 31 березня 2022 року, охоплює матеріальність, безпеку даних, хмарне та планування виходу. PRA описує його як призначене для сприяння «більшій стійкості та прийняттю хмари та інших нових технологій».

У Сингапурі MAS Технологічні рекомендації щодо управління ризиками, опубліковані 18 січня 2021 року, встановлюють принципи управління технологічним ризиком, ІТ і кіберстійкістю, а також доповнюються обов'язковим повідомленням та інструкціями з повідомлення про інцидент.

DORA: цифрова оперативна стійкість в ЄС

Це... Закон про цифрову операційну стійкість, Регламент (ЄС) 2022/2554, застосовується з 17 січня 2025 року. Він об'єднує управління ризиками ІКТ, повідомлення про інциденти, тестування і ризики третьої сторони в одне регулювання для більшості фінансових установ ЄС, включаючи банки.

Область DORA	Основні вимоги до банків
Керування ризиками ІКТ	Задокументована система, схвалена і контролюється органом управління, що включає в себе ідентифікацію, захист, виявлення, відповідь та відновлення
Звіт про подію	Про великі інциденти, пов'язані з ІКТ, слід повідомляти компетентному органу відповідно до Статті 19, використовуючи узгоджену класифікацію і шаблони
Перевірка на міцність	Програма тестування для всіх суб'єктів; для суб'єктів, визначених органами влади, розширене тестування проникнення під час загрози щонайменше раз на три роки на живих виробничих системах за Стаття 26
ІКТ третій ризик	Стратегія щодо ризику ІКТ від третьої сторони, контрактні мінімуми і реєстр інформації про всі контракти на послуги ІКТ за Стаття 28
Нагляд за критичними постачальниками	Європейські наглядові органи визначають критичних постачальників послуг ІКТ і контролюють їх безпосередньо за статтею 31

У статті 28 зазначено, що фінансові суб’ єкти, які використовують послуги ІКТ, « повинні завжди залишатися повністю відповідальними за дотримання та виконання всіх зобов’ язань » за DORA і законом про фінансові послуги. Реєстр повинен розрізняти послуги, що підтримують критичні або важливі функції. Суб’ єкти повинні щорічно повідомляти про нові договори і своєчасно інформувати орган про заплановані контракти для критичних або важливих функцій.

DORA застосовується разом з EBA принципами аутсорсингу. На практиці, банки підтримують один запас, який задовольняє обидва.

Кібербезпека

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

Клавіші керування зазвичай включають:

1. Надійне керування ідентифікацією та доступом, з багатофакторною автентифікацією та привілейоване керування доступом.
2. Безпечна розробка програмного забезпечення і управління змінами, включаючи випуски виробників.
3. Шифрування даних під час передачі та у стані спокою, а також управління ключами, що контролюється банком.
4. Постійний моніторинг і можливості операцій безпеки, внутрішні або аутсорсинг.
5. Керування вразливістю і регулярне тестування проникнення.
6. Резервні копії, які було ізольовано від виробничого середовища і перевірено на відновлення.
7. Плани реагування на інциденти, що охоплюють регулятивне попередження і комунікацію з клієнтами.

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

Регуляторна звітність

Банки повідомляють великі обсяги даних органам нагляду і центральним банкам. У ЄС, Стаття 430 CRR вимагає від установ повідомляти про вимоги до власних коштів, включаючи співвідношення кредитного плеча, великі експозиції, вимоги щодо ліквідності, обтяження активами і експозиції ESG, серед інших пунктів, а деякі установи також повинні повідомляти фінансову інформацію. Центральні банки додають статистичні звіти, а підрозділи фінансової розвідки отримують звіти про підозрілі операції.

Звіти є лише на стільки хорошими, наскільки хорошими є дані, які вони містять. Ланцюг від системи ядра до регулятора зазвичай виглядає так:

1. Джерела даних у ядрі системи та інших операційних системах.
2. Склад даних або рівень звіту з прирівнюванням до головної книги.
3. Рушій регуляторного звіту, який відображає дані у шаблонах нагляду і правилах перевірки.
4. Перегляд і підписання фінансами та ризиком, з документованим контролем.
5. Подання через портал або формат регулятора.

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

На що звертають увагу керівники у заявці на ліцензію

1. Ясна цільова архітектура, з кожною системою, її власником, провайдером і розташуванням.
2. Карта критичних або важливих функцій, яка показує які функції аутсорсинговані і кому.
3. Плани виходу для кожного критичного постачальника, реалістичні за часом і вартістю.
4. Місцезнаходження та доступ до даних, в тому числі для органу нагляду і розв' язання.
5. Перевірена стійкість, з часом відновлення, що відповідає обіцянкам бізнес-плану.
6. Докази готовності, такі як повне тестування, репетиція міграції і прийняття до експлуатації.

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

Наступна стаття пояснює платіжні рейки, до яких під’ єднується основна система: схеми карт, SEPA, миттєві платежі і валовий розрахунок у реальному часі.