RBS и NatWest превратили восстановление пакетной обработки в тест банковской подотчётности

Резюме

• Сбой RBS, NatWest и Ulster Bank в 2012 году относится к досье рисков и подотчётности, потому что отказ пакетной обработки превратился в событие, затронувшее ликвидность клиентов, платежи, клиринг и доверие общества, а не в узкий технологический сбой бэк-офиса.
• Кто имел практический контроль над риском изменений в пакетной обработке, восстановлением состояния платежей, урегулированием трудностей клиентов, отчётностью перед регуляторами, устойчивостью устаревших платформ и доказательствами того, что банковскую автоматизацию можно восстановить, не перекладывая издержки на клиентов?
• Пресс-релиз FCA по ссылкеhttps://www.fca.org.uk/news/press-releases/fca-fines-rbs-natwest-and-ulster-bank-ltd-%C2%A342-million-it-failuresи финальное уведомление по ссылкеhttps://www.fca.org.uk/publication/final-notices/rbs-natwest-ulster-final-notice.pdf— основные открытые доказательства: FCA оштрафовала банки на 42 млн фунтов, установила нарушения принципа 3 (системы и контроль), выявила не менее 6,5 млн напрямую затронутых клиентов в Великобритании и описала последствия для платежей, остатков, банкоматов, Bankline, кредитов, SWIFT, процентов, выписок, постоянных поручений и клиринга.
• Запись PRA по ссылкеhttps://www.bankofengland.co.uk/news/2014/november/pra-fines-rbs-natwest-and-ulster-bankиhttps://www.bankofengland.co.uk/-/media/boe/files/prudential-regulation/enforcement-notice/en201114.pdfважна, потому что пруденциальный регулятор Банка Англии оштрафовал банки на 14 млн фунтов и квалифицировал инцидент как риск для безопасности и надёжности и клиринговой системы, а не только как нарушение в сфере поведения.
• Соглашение Центрального банка Ирландии по ссылкеhttps://www.centralbank.ie/docs/default-source/news-and-media/legal-notices/settlement-agreements/ulster-bank-ireland-limited.pdf?sfvrsn=6добавляет измерение Республики Ирландия: Ulster Bank Ireland была оштрафована на 3,5 млн евро за нарушения ИТ-управления, а в публичном заявлении говорилось, что примерно 600 тыс. клиентов были лишены банковских услуг.
• Эта статья рассматривает материалы FCA, PRA, Банка Англии, Центрального банка Ирландии и инвесторов RBS/NatWest как прямые открытые доказательства, использует The Guardian, Computer Weekly, Sky News и парламентские материалы для хронологии и контекста последствий, а публикации об операционной устойчивости — для более позднего контрольного словаря, а не частные журналы пакетных заданий или рабочие документы привлечённых экспертов.

Почему это дело относится к досье рисков и подотчётности

Сбой RBS, NatWest и Ulster Bank в 2012 году относится к досье рисков и подотчётности, потому что он разрушил обычное разделение между автоматизацией бэк-офиса и публичной банковской жизнью. Планировщик пакетных заданий должен координировать ночную обработку. Клиенты его не видят. Работодатели не видят. Ипотечные кредиторы, продавцы, арендодатели, получатели пособий и контрагенты по платежам не видят.

Но когда пакетная обработка выходит из строя внутри крупной банковской группы, невидимая автоматизация становится видимой: пропавшие зарплаты, неверные остатки, несостоявшиеся переводы, отклонённые покупки, очереди в отделениях, нагрузка на колл-центры и неопределённость относительно того, кто может тратить деньги, которые уже должны быть доступны.

Финальное уведомление FCA по ссылкеисточник: fca.org.uk— центральная публичная запись. В нём говорится, что в среду 20 июня 2012 года клиенты обнаружили, что не могут использовать все возможности интернет-банкинга для доступа к счетам или получения точных остатков в банкоматах. Затем записаны более широкие последствия: клиенты не могли получить кредиты, переводить платежи внешним кредиторам, включая компании эмитентов кредитных карт и ипотечных провайдеров, или переводить деньги с помощью платежей SWIFT. Позже клиенты обнаружили неверные начисленные и списанные проценты, дублированные записи в выписках, неточные записи операций и постоянные поручения, не обработанные вовремя.

Вот почему это не просто сбой. Это дело об ответственности за состояние платежей. Банковский счёт — это не только строка в базе данных. Это способность клиента платить за аренду, получать зарплату, снимать наличные, завершить покупку дома, выполнить расчёты по зарплате, сверить счета-фактуры, избежать штрафов и доказать, что платёж состоялся или не состоялся. Когда банк не может надёжно обновлять состояние платежей, финансовая жизнь клиента становится зависимой от очереди восстановления банка.

Поэтому главный вопрос практический: кто имел практический контроль над риском изменений в пакетной обработке, восстановлением состояния платежей, урегулированием трудностей клиентов, отчётностью перед регуляторами, устойчивостью устаревших платформ и доказательствами того, что банковскую автоматизацию можно восстановить, не перекладывая издержки на клиентов? Публичная запись указывает прежде всего на RBS Group и её централизованную функцию Technology Services, затем на управление бизнес-рисками, внутренний аудит, надзор совета директоров, клиентские бренды и регуляторов.

Клиенты несли последствия, но они не контролировали планировщик пакетных заданий, управление изменениями, устойчивость систем или доказательства восстановления.

Сбой начался до того, как клиенты его заметили

Публичная картина инцидента началась 20 июня 2012 года, но регуляторная запись относит техническую причину к более раннему времени. Финальное уведомление PRA по ссылкеисточник: bankofengland.co.ukговорит, что фактической причиной была несовместимость программного обеспечения между обновлённой версией ПО планировщика пакетных заданий и предыдущей версией. Проблема совместимости возникла, когда Technology Services откатила обновление ПО, установленное в воскресенье 17 июня 2012 года.

Уведомление FCA также описывает период нарушений с 1 августа 2010 года — даты внутреннего аудита группы по пакетным процессам на мэйнфрейме, выявившего риск отказа планировщика пакетных заданий, — до 10 июля 2012 года, когда большинство систем снова работали после инцидента.

Эти даты — стержень подотчётности. Неудачное изменение в июне 2012 года стало триггером. Известный риск, выявленный в 2010 году, был частью контекста управления. Клиентские сбои обнаружились, когда состояние счетов и платежей перестало обновляться. Большинство систем RBS и NatWest были нарушены до 26 июня 2012 года. Большинство систем Ulster Bank — до 10 июля 2012 года. Другие системы, включая BankTrade и IFS, оставались нарушенными и в июле 2012 года.

Эта хронология не позволяет дать узкое объяснение. Дело не только в том, что технический оператор выполнил плохое изменение. Регуляторы выявили нарушения в системах и контроле. FCA наложила штраф в 42 млн фунтов после скидки за урегулирование. PRA — 14 млн фунтов после скидки за урегулирование. Центральный банк Ирландии отдельно оштрафовал Ulster Bank Ireland на 3,5 млн евро. Эти санкции отражают провал управления, а не разовый сбой.

Хроника The Guardian за 2012 год по ссылкеисточник: theguardian.comи более поздние материалы о штрафе по ссылкеисточник: theguardian.comпоказывают, как публичная история превратилась из технической проблемы в дело об управлении и регулировании. Репортаж Computer Weekly по ссылкеисточник: computerweekly.comзафиксировал раннее требование регулятора о проведении проверки, а отчёт 2014 года по ссылкеисточник: computerweekly.com— результат правоприменения.

Пакетная обработка — это инфраструктура обычной жизни

Словосочетание «планировщик пакетных заданий» может звучать отдалённо. Это не так. Банки обычно обновляют операции текущего дня вечером, а планировщик пакетных заданий координирует порядок обработки данных, лежащих в основе этих обновлений. Если координация нарушается, остатки на счетах, постоянные поручения, зачисления, списания, проценты, выписки и нижестоящие системы могут выйти из синхронизации. В розничном и коммерческом банке это означает, что ночная работа не становится надёжным финансовым состоянием следующего дня.

Уведомление FCA описывает конкретный ущерб. Розничные клиенты не могли получить доступ к счетам или точным остаткам. Некоторые не могли совершать платежи внешним кредиторам. Клиенты за границей сталкивались с отклонёнными покупками по кредитным картам и не имели доступа к наличным. Коммерческие клиенты не могли пользоваться Bankline для доступа к счетам или совершения платежей. Некоторые коммерческие клиенты не могли завершить аудит счетов или выполнить зарплатные обязательства. Неклиенты пострадали, потому что не могли получать деньги от клиентов банков и, следовательно, не могли выполнять собственные обязательства.

На более широком уровне способность банков полностью участвовать в клиринге была нарушена.

Эти факты объясняют, почему автоматизация корпоративного ПО — публичная тема подотчётности. Автоматизированный процесс внутренний, но последствия социальны. Зарплатный файл, не обработанный за ночь, становится проблемой ликвидности домохозяйства. Постоянное поручение, которое не выполняется, становится проблемой арендодателя, коммунальной службы, кредитной карты или ипотеки. Сбой делового платежа становится проблемой поставщика, сотрудника и налогов. Проблема клиринга становится проблемой финансовой системы.

Те же факты объясняют, почему непрерывность услуг для малого и среднего бизнеса имеет значение. У крупных компаний могут быть казначейские отделы, несколько банковских отношений, резервы ликвидности и персональные менеджеры. У малого бизнеса может быть зарплатный цикл, вход в Bankline, один основной банковский счёт и сотрудники, ожидающие зарплату. Когда Bankline или состояние пакетной обработки выходит из строя, малый бизнес становится человеческим слоем поддержки технологического дефекта банка.

Число 6,5 млн — лишь один из знаменателей

В записях FCA и PRA указано, что напрямую затронуты не менее 6,5 млн клиентов в Великобритании. Пресс-релиз PRA по ссылкеисточник: bankofengland.co.ukговорит, что 92 % напрямую затронутых были розничными клиентами и что инцидент повлиял на способность розничных клиентов получать доступ к счетам, коммерческих клиентов — пользоваться интернет-банкингом, клиентов других учреждений — получать платежи, а банков — полностью участвовать в клиринге. Такой масштаб сам по себе достаточен для демонстрации существенности.

Но 6,5 млн — не единственный знаменатель. Другой знаменатель — количество счетов, по которым остатки, зачисления, списания, проценты, выписки или постоянные поручения были неточными или задержанными. Другой — количество коммерческих клиентов, не имевших доступа к Bankline. Другой — неклиенты, не получившие платежи от пострадавших клиентов. Другой — нагрузка на отделения и колл-центры. Другой — случаи трудностей: люди за границей без наличных, заёмщики, не получившие кредиты, отложенные покупки жилья, пропущенные зарплаты и клиенты, обеспокоенные комиссиями или кредитной историей.

Ещё один — время: большинство систем RBS и NatWest были нарушены до 26 июня, большинство систем Ulster Bank — до 10 июля, а другие системы — до июля.

Соглашение Центрального банка Ирландии по ссылкеисточник: centralbank.ieдобавляет ещё один знаменатель. В нём говорится, что Ulster Bank Ireland была оштрафована на 3,5 млн евро и получила выговор за ИТ- и управленческие недостатки, в результате которых примерно 600 тыс. клиентов были лишены банковских услуг. Выступление Центрального банка об уроках правоприменения по ссылкеисточник: centralbank.ieсообщает, что Центральный банк потребовал программу возмещения, по которой фирма выплатила пострадавшим клиентам примерно 59 млн евро. Эта ирландская запись важна, потому что инцидент группы RBS пересекал границы брендов и юрисдикций.

Вопрос о знаменателях — это вопрос подотчётности. Банк может сказать, что системы снова работают, но клиентам всё ещё нужны исправления платежей, исправление процентов, исправление дублированных записей, защита кредитной истории, рассмотрение жалоб, возмещение комиссий и чёткие доказательства того, что важные платежи не были потеряны. Время до технического восстановления — не то же самое, что время до исправления последствий для клиентов.

Регуляторы расценили инцидент и как нарушение в сфере поведения, и как пруденциальный риск

Двойное действие FCA и PRA — одна из самых важных особенностей дела. FCA оштрафовала банки за сбои в системах и контроле, обращённые к поведению. PRA оштрафовала их за пруденциальные сбои в системах и контроле. PRA заявила, что инцидент мог угрожать безопасности и надёжности и, в крайнем случае, оказать неблагоприятное воздействие на финансовую стабильность, поскольку нарушал основные банковские функции, затрагивал третьи стороны и рисковал нарушить клиринговую систему.

Это двойное действие важно, потому что не позволяет банку рассматривать сбой только как проблему обслуживания клиентов. Сбой обработки платежей в крупной банковской группе может повлиять на безопасность и надёжность банка, общественное доверие, участие в клиринге и контрагентов. Он также может навредить отдельным клиентам и малому бизнесу. Оба слоя реальны.

Пресс-релиз FCA по ссылкеисточник: fca.org.ukзаявил, что современный банкинг зависит от эффективных, надёжных и устойчивых ИТ-систем и что банки не обеспечили адекватные системы и контроль для выявления ИТ-риска и управления им. Пресс-релиз PRA заявил, что правильно функционирующие системы и контроль управления ИТ-рисками являются неотъемлемой частью безопасности и надёжности. Эти заявления не декоративны. Они делают ИТ-управление регулируемым банковским контролем.

Более поздний документ Банка Англии о финансовой стабильности по ссылкеисточник: bankofengland.co.ukиспользует инцидент RBS как пример того, как небольшие первопричины, например рутинные обновления ПО, могут дать непропорционально масштабные последствия при слабой операционной устойчивости. Этот более поздний документ — не запись о правоприменении 2012 года, но он показывает сохраняющуюся актуальность инцидента в мышлении об операционной устойчивости.

Риск устаревших платформ — это проблема управления, а не оправдание

Публичная запись неоднократно указывает на темы устаревших систем и управления. Пресс-релиз PRA описал очень плохое наследие ИТ-устойчивости и неадекватное управление ИТ-рисками. Финальное уведомление FCA описывает централизованную групповую ИТ-функцию, три линии защиты, стратегическое управление ИТ-рисками, внутренний аудит и политические рамки. Дело не в том, что старые системы по своей природе безответственны. Крупным банкам неизбежно приходится эксплуатировать сложные платформы с длинной историей.

Дело в том, что сложность устаревших систем повышает требования к управлению изменениями, картированию зависимостей, тестированию восстановления и планированию последствий для клиентов.

Отказ планировщика пакетных заданий предсказуем в том смысле, что любой критический планировщик следует рассматривать как зависимость с высоким влиянием. Регуляторная запись говорит, что внутренний аудит в 2010 году выявил риск отказа планировщика пакетных заданий. Как только риск выявлен, вопрос подотчётности становится вопросом о том, что банк с ним сделал. Был ли риск приоритизирован? Были ли проверены контроли? Были ли отрепетированы пути отката? Оспаривало ли управление рисками технические допущения? Понимал ли совет директоров последствия отказа планировщика для клиентов и клиринга?

Включали ли планы непрерывности бизнеса исправление состояния платежей клиентов, а не только восстановление систем?

Контекст годовых отчётов здесь важен. Материалы для инвесторов RBS/NatWest, включая отчёт за 2012 год по ссылкеисточник: investors.natwestgroup.comи отчётность за 2014 год по ссылкеисточник: investors.rbs.com, встраивают ИТ-инцидент в более широкую историю восстановления банка после финансового кризиса и реструктуризации. Статья не использует эти отчёты как частные технические доказательства. Она использует их, чтобы показать, что ИТ-устойчивость, доверие клиентов, операционный риск и инвестиции стали темами, обращёнными к инвесторам.

Устаревшие системы не освобождают от ответственности. Устаревшие системы — причина, по которой управление должно быть более жёстким. Если платформа не может отказать без задержки зарплат, пособий, ипотек, международных переводов и участия в клиринге, банк должен знать это до открытия окна изменений.

Работа с трудностями клиентов была частью восстановления системы

Банковский сбой устраняется не тогда, когда перезапускается сервер. Он устраняется, когда клиенты получают компенсацию и могут доверять своему финансовому состоянию. Это означает, что работа с трудностями — часть контрольной записи. Уведомление FCA фиксирует клиентов, не имевших доступа к наличным за границей, несостоявшиеся платежи кредиторам, недоступность Bankline, пропущенные зарплатные обязательства, неверные проценты, дублированные записи в выписках и задержанные постоянные поручения. Для каждой категории нужен свой путь исправления.

Клиенту за границей без наличных нужна немедленная поддержка ликвидности. Домохозяйству, чей ипотечный платёж не прошёл, нужна защита от комиссий, повреждения кредитной истории и действий кредитора. Малому бизнесу, не способному выполнить зарплатные обязательства, нужна срочная платёжная поддержка и коммуникация с сотрудниками. Неклиенту, не получившему деньги от пострадавшего клиента RBS, нужен способ быть признанным, даже если у него нет счёта в RBS. Клиенту с дублированными записями в выписках нужна сверка и уверенность. Коммерческому пользователю, заблокированному вне Bankline, нужны рекомендации по непрерывности.

Заявление RBS об урегулировании, переданное службами регуляторных новостей по ссылкеисточник: shareprices.com, говорит, что FCA и PRA отметили, что RBS выплатила 70,3 млн фунтов в качестве возмещения клиентам в Великобритании и 460 тыс. фунтов лицам и компаниям, не являвшимся клиентами. Статья рассматривает это как вторичную копию рыночного заявления, а не как страницу регулятора. Это всё равно полезно, потому что показывает, что вред неклиентам был признан частью возмещения.

Выступление Центрального банка Ирландии об уроках правоприменения фиксирует примерно 59 млн евро возмещения пострадавшим клиентам Ulster Bank Ireland. Эта цифра делает тот же вывод в другой юрисдикции. Последствия для клиентов не закончились, когда остатки снова стали видимыми. Возмещение, рассмотрение жалоб, исправление комиссий, коммуникация и восстановление репутации продолжались после технического восстановления.

Непрерывность государственного сектора пострадала через обычные платежи

Манифест включает непрерывность государственного сектора, и событие RBS подходит, потому что банки — часть платёжной инфраструктуры общества. Инцидент затронул получателей пособий, государственные платежи, ипотечных заёмщиков, зарплаты и домохозяйства. Он также затронул клиринг, который FCA описала как фундаментальный для финансовых рынков. Запись парламента Ирландии (Oireachtas) по ссылкеисточник: data.oireachtas.ieпоказывает, как ирландская общественность и парламентская запись рассматривали последствия для Ulster Bank как вопрос публичной подотчётности, а не только частный спор между банком и клиентом.

Непрерывность государственного сектора не означает, что банк был государственным органом. Это означает, что банковская платёжная инфраструктура лежит в основе общественной жизни. Зарплаты, пособия, жилищные сделки, налоги, поставщики и малый бизнес полагаются на банки в надёжном обновлении состояния. Когда банк подводит, государственные органы и третьи стороны берут на себя давление. Признание неклиентов в уведомлении FCA важно, потому что показывает, что вред распространился за пределы договорной клиентской базы банка.

Именно поэтому операции отделений и колл-центров имеют значение. Во время сбоя цифровых и пакетных процессов физические отделения становятся аварийной инфраструктурой. Сотрудники должны обслуживать клиентов, которые не видят остатки, нуждаются в наличных, у которых пропали платежи или которым нужна уверенность, что кредитные истории и комиссии будут исправлены. План непрерывности банка должен включать человеческий слой. Недостаточно иметь план технического восстановления, если сотрудники первой линии не имеют точной информации, полномочий, путей поддержки ликвидности и маршрутов эскалации.

Материалы Sky News по ссылкеисточник: news.sky.comи материалы The Guardian о штрафе показывают, как общественное внимание сосредоточилось не только на технической причине, но и на человеческих последствиях. Эти отчёты — вторичные источники, но они помогают сохранить общественную память об инциденте: люди были злы не на планировщик заданий; они были злы из-за невозможности использовать свои деньги.

Подтверждённые факты, обоснованные выводы и неизвестные

Подтверждённые публичные факты включают штраф FCA в 42 млн фунтов, штраф PRA в 14 млн фунтов и штраф Центрального банка Ирландии в 3,5 млн евро. Подтверждённые публичные факты включают не менее 6,5 млн напрямую затронутых клиентов в Великобритании, из которых 92 % — розничные клиенты; нарушение большинства систем RBS и NatWest до 26 июня 2012 года; нарушение большинства систем Ulster Bank до 10 июля 2012 года; и другие сбои систем в июле. Подтверждённые публичные факты также включают вывод регуляторов о том, что фактической технической причиной была несовместимость ПО планировщика пакетных заданий после отката обновления.

Подтверждённые факты о последствиях для клиентов включают невозможность использовать все возможности интернет-банкинга, неточные остатки в банкоматах, невозможность получить кредиты, несостоявшиеся переводы внешним кредиторам, проблемы с переводами SWIFT, неверные проценты, дублированные записи в выписках, неточные записи операций, постоянные поручения, не обработанные вовремя, недоступность Bankline, проблемы с коммерческими платежами и влияние на участие в клиринге. Публичное заявление ирландского регулятора подтверждает, что примерно 600 тыс. клиентов Ulster Bank Ireland были лишены банковских услуг.

Обоснованные выводы включают заключение о том, что управление изменениями в пакетной обработке, эскалация внутреннего аудита, эффективность трёх линий защиты, последовательность восстановления, сверка состояния платежей, аварийная работа отделений и колл-центров, возмещение за трудности и инвестиции совета директоров в устаревшие системы были центральными поверхностями подотчётности. Этот вывод следует из уведомлений FCA и PRA, соглашения Центрального банка и более поздней системы операционной устойчивости. Он не требует утверждать доступ к частным журналам пакетных заданий.

Неизвестные остаются. Общественность не может увидеть полный отчёт привлечённых экспертов, полные документы внутреннего аудита, все заявки на изменения, все записи решений об откате, все журналы пакетных заданий, все сообщения штаба инцидента, все решения отделений о трудностях, все жалобы клиентов, все расчёты возмещения, все обсуждения совета директоров или точную архитектуру каждой затронутой системы. Общественность также не может определить только по публичным записям, получил ли каждый клиент возмещение достаточно быстро и были ли устойчивыми все внутренние улучшения контроля.

Эти неизвестные не следует заполнять необоснованными обвинениями. Их следует рассматривать как набор доказательств, который содержало бы полное досье подотчётности. Регуляторы имели доступ к большему количеству материалов, чем общественность, и их выводы устанавливают публичный базовый уровень. Ответственная статья останавливается там, где заканчивается эта запись.

Что должно доказать устойчивое восстановление

Устойчивое досье восстановления после инцидента RBS/NatWest должно сначала доказать факты управления изменениями. В нём должно быть показано, кто утвердил обновление планировщика пакетных заданий, кто утвердил откат, какое тестирование совместимости проводилось, какая предпроизводственная среда существовала, какие известные риски учитывались, какие критерии отката были определены и кто имел полномочия остановить или отменить изменение. В нём также должно быть показано, как вывод внутреннего аудита 2010 года отслеживался, эскалировался, финансировался и закрывался.

На уровне архитектуры досье должно идентифицировать системы, зависящие от пакетной обработки: обновления счетов клиентов, данные об остатках в банкоматах, интернет-банкинг, Bankline, постоянные поручения, получение кредитов, переводы SWIFT, клиринг, торговые системы, международные валютные системы, формирование выписок, расчёт процентов и нижестоящую отчётность. Банк не может управлять устойчивостью, если не знает, какие услуги зависят от планировщика.

На уровне восстановления досье должно показать, как было реконструировано состояние платежей. Какие операции были в ожидании? Какие были дублированы? Какие расчёты процентов были неверными? Какие постоянные поручения не выполнились? Какие коммерческие платежи были заблокированы? Какие неклиенты пропустили входящие средства? Как банк сохранял доказательства, обрабатывая накопленные данные? Как он отличал истинное поручение клиента от артефакта восстановления?

На уровне клиентов досье должно показать протоколы работы с трудностями, полномочия отделений, скрипты колл-центров, политики отказа от комиссий, защиту кредитной истории, категории компенсаций, требования неклиентов, работу с уязвимыми клиентами и поддержку бизнес-клиентов. Файл возмещения должен быть проверяемым: кто имел право, какие доказательства требовались, что было выплачено, сколько времени заняло и как разрешались споры.

На уровне управления досье должно показать ответственность совета директоров, аппетит к риску для критических технологий, приоритизацию инвестиций, оспаривание внутренним аудитом, надзор за рисками второй линии, независимую оценку третьей линии, рекомендации привлечённых экспертов, отчётность перед регуляторами и пост-инцидентную проверку. Штрафы регуляторов показывают, что это был провал систем и контроля. Поэтому устойчивое восстановление должно доказать, что системы и контроль изменились, а не только то, что немедленная очередь пакетной обработки была очищена.

Более поздняя система операционной устойчивости называет отсутствовавшую дисциплину

Инцидент 2012 года предшествовал более позднему режиму операционной устойчивости в Великобритании, но более поздняя система помогает назвать дисциплину, которой требовал инцидент. Страница FCA об операционной устойчивости по ссылкеисточник: fca.org.ukговорит, что фирмы должны уметь предотвращать, адаптироваться, реагировать, восстанавливаться и учиться на операционных сбоях. Страница надзорного заявления Банка Англии и PRA по ссылкеисточник: bankofengland.co.ukописывает важные бизнес-услуги и допустимые пределы воздействия. Эти материалы — не выводы о правоприменении 2012 года. Это словарь, который регуляторы позже формализовали.

В рамках этого словаря затронутые услуги были не «планировщиком пакетных заданий». Важными бизнес-услугами были доступ к счетам, платежи, снятие наличных, интернет- и коммерческий банкинг, участие в клиринге и поддержка клиентов. Вопрос о допустимых пределах воздействия звучал бы так: какое нарушение этих услуг банк мог допустить, прежде чем клиенты, рынки и третьи стороны столкнутся с недопустимым ущербом? Запись 2012 года показывает, что ответ был не просто процентом времени безотказной работы сервера.

Операционная устойчивость также требует картирования зависимостей. Банк должен знать, какие люди, процессы, технологии, объекты, информация и третьи стороны поддерживают каждую важную бизнес-услугу. В 2012 году зависимость от планировщика пакетных заданий была достаточно критичной, чтобы затронуть миллионы клиентов и участие в клиринге. Если зависимость может дать такой эффект, она должна быть в карте устойчивости.

Более поздний макропруденциальный документ Банка Англии делает тот же вывод на уровне системы. Рутинные изменения могут создавать непропорциональные последствия при слабой устойчивости. Инцидент RBS — пример того, как небольшое техническое событие внутри крупного и пользующегося доверием учреждения может стать публичной проблемой финансовой стабильности, потому что услуга центральная, а запасной вариант неадекватен.

Контрфактический сценарий — не отсутствие сбоев, а ограниченный сбой

Ни один крупный банк не может обещать, что сложные технологии никогда не откажут. Контрфактический сценарий — ограниченный сбой. Совместимое изменение тестируется до производства. Неудачное изменение обнаруживается быстро. Откат безопасен и полон. Зависимости пакетной обработки картированы. Клиентские сервисы деградируют плавно. Сотрудники первой линии знают, что говорить клиентам. Состояние платежей восстанавливаемо. Клиенты могут получить экстренные наличные. Коммерческие пользователи могут совершать срочные зарплатные платежи. Неклиенты могут быть признаны. Кредитные истории защищены. Регуляторы получают точные отчёты.

Возмещение быстрое и документированное.

Ограниченный сбой также означает, что банк знает, какой вред важнее всего. Пропавшие зарплаты, пособия, ипотечные платежи, аренда, расчёты по зарплате, налоги и наличные для зарубежных поездок — не то же самое, что задержанный несущественный дискреционный перевод. Банк должен сортировать воздействие по последствиям для клиентов, а не только по системной очереди. Это человеческая версия операционной устойчивости.

Событие RBS также показывает, почему к аутсорсингу и централизации нужно относиться с доказательствами, а не лозунгами. Регуляторная запись сосредоточена на централизованной функции Technology Services группы RBS и провалах управления. В публичных дебатах были вопросы об аутсорсинге и инвестициях в устаревшие системы. Статья не делает необоснованных утверждений о причинности аутсорсинга. Подтверждённый вывод уже и сильнее: банковская группа несла обязанность управления системами и контролем, используемыми для управления ИТ-риском, независимо от того, как были организованы внутренние команды, поставщики или площадки.

Поэтому контрфактический сценарий — не более простой банк без устаревших систем. Это банк, который относится к устаревшим системам как к критической инфраструктуре, соответственно финансирует устойчивость, репетирует сбои и может быстро сказать клиентам правду, когда что-то ломается.

Данные о состоянии платежей — центр досье подотчётности

Самые важные доказательства в этом деле — состояние платежей. Банк может сообщить, что произошёл технологический инцидент, но клиентам нужно знать, пришли ли деньги, ушли ли деньги, не прошёл ли прямой дебет, не было ли продублировано постоянное поручение, правильно ли рассчитаны проценты, существует ли получение кредита, дошёл ли ипотечный платёж до кредитора и будет ли повторена платёжная инструкция. Это не общие вопросы о статусе сервиса. Это вопросы реестра, очереди, сверки и вреда клиентам.

Поэтому файл доказательств банка должен позволять воспроизвести затронутые очереди. В нём должно быть показано, какие пакеты завершились, какие не выполнились, какие были обработаны частично, какие операции удерживались, какие были воспроизведены, какие были отменены, какие были дублированы и какие были исправлены вручную. В нём также должно быть показано, кто разрешил каждый шаг восстановления и как банк предотвратил создание второго вреда действием по восстановлению. Поспешное восстановление может быть таким же разрушительным, как и исходный сбой, если оно повредит состояние платежей.

Клиентам также нужны были доказательства в форме, которую они могут использовать. Малому бизнесу не нужно было объяснение планировщика перед зарплатой. Ему нужно было знать, будут ли выплачены зарплаты, безопасны ли заменяющие платежи, произойдут ли дублирующие платежи и получат ли сотрудники надёжное объяснение. Домохозяйству не нужна была техническая причина до дня аренды или ипотеки. Ему нужно было знать, будут ли защищены просроченные комиссии, овердрафтные сборы, кредитные отчёты и претензии кредиторов. Неклиент, ждущий деньги от пострадавшего клиента, нуждался в пути в процесс возмещения банка.

Вот почему компенсацию и исправление нельзя рассматривать как добрую волю задним числом. Возмещение — часть архитектуры восстановления. Если технологический сбой банка создаёт предсказуемые комиссии, пропущенные платежи, потерянные проценты, экстренные заимствования, сбои бизнеса или тревогу о кредитной истории, план исправления должен включать, как этот вред будет выявлен и исправлен. Внимание регуляторной записи к пострадавшим клиентам, коммерческим клиентам, неклиентам и возмещению показывает, что периметр исправления был шире восстановления систем.

Готовность фронт-офиса — это технологический контроль

Инцидент RBS также показывает, что готовность отделений и колл-центров неотделима от технологической устойчивости. Когда цифровой доступ к счетам и состояние платежей выходят из строя, клиенты обращаются в отделения, по телефону, к персональным менеджерам и публичным заявлениям. Эти сотрудники становятся видимой контрольной поверхностью. Если у них нет точной информации, полномочий и путей эскалации, технологический сбой банка становится вторым коммуникационным сбоем.

Готовность первой линии должна включать чёткую таксономию последствий для клиентов. Сотрудники должны знать, какие случаи требуют экстренных наличных, какие — отслеживания платежей, какие — писем кредиторам, какие — эскалации по бизнесу, какие — поддержки уязвимых клиентов, а какие — обработки требований неклиентов. Банк также должен сохранять записи о консультациях, данных во время инцидента, поскольку непоследовательные консультации могут создавать дополнительный вред клиентам и поздние споры по жалобам.

Тот же вывод относится к коммерческой поддержке. Нарушение Bankline — не просто сбой веб-сайта. Оно может помешать выплате зарплаты, платежам поставщикам, налоговым платежам, казначейским операциям или закрытию бухгалтерского периода. Коммерческому клиенту могут понадобиться временные средства, ручная поддержка платежей, подтверждающие письма или прямой маршрут поддержки. Если банк относится к каждому пострадавшему как к обычному розничному пользователю, он упускает операционную роль, которую его платформа играет для малых и средних фирм.

Готовность первой линии также защищает собственное восстановление банка. Когда сотрудники могут точно сортировать, технические команды получают лучшие сигналы о том, какие услуги остаются сломанными и какие группы клиентов сталкиваются с немедленным вредом. Когда сотрудники не могут сортировать, руководство инцидента заваливается анекдотами, дублирующими жалобами и политическим давлением. Вот почему планирование устойчивости должно связывать карты систем с картами обслуживания клиентов до возникновения сбоя.

Ответственность совета директоров начинается до окна изменений

Совету директоров и старшему руководству не нужно утверждать каждое пакетное задание. Им нужно обеспечивать, чтобы критический технологический риск был картирован, профинансирован, протестирован и оспорен. Упоминание в регуляторной записи ранее выявленного риска внутренним аудитом важно, потому что показывает, что риск не был совершенно непознаваемым. Как только критическая зависимость выявлена, руководство должно решить, приемлема ли среда контроля и какие инвестиции требуются для снижения неприемлемого риска.

Ответственность совета директоров поэтому начинается до окна изменений. Она начинается, когда банк определяет, какие услуги достаточно важны, чтобы требовать специальных доказательств устойчивости. Она продолжается, когда руководство решает, будут ли старые платформы исправляться, заменяться, изолироваться или контролироваться более тщательно. Она включает выбор финансировать тестовые среды, автоматизировать сверку, репетировать роли инцидента и поддерживать запасные варианты отделений и колл-центров. Она также включает дисциплину рассматривать технологический риск как клиентский и пруденциальный риск, а не как операционный центр затрат.

После инцидента ответственность совета директоров смещается к проверке. Руководство должно быть в состоянии показать не только то, что немедленная неисправность была устранена, но и что вывод аудита, процесс изменений, карта зависимостей, план восстановления, процесс возмещения клиентам и контрольная гарантия изменились. Штраф регулятора может привлечь внимание, но устойчивое восстановление требует, чтобы банк доказал, что тот же режим отказа не может повториться через другое изменение или другую зависимость.

Это доказательство должно быть практическим. Оно должно включать результаты тестов, учения по инцидентам, независимую оценку, показатели результатов для клиентов, доказательства закрытия возмещения и взаимодействие с регулятором. Комитет по технологиям, получающий только дашборды безотказности, упустит риск состояния платежей. Совет, который спрашивает, как клиенты испытали бы неудачный пакет и как банк узнал бы, кто пострадал, ближе к правильному контрольному вопросу.

Ответственность следует за контролем над состоянием платежей

Финальное распределение подотчётности должно следовать за контролем над состоянием платежей. Клиенты зависели от банка в поддержании точных остатков на счетах, обработке платежей, обеспечении доступности наличных, проведении операций по клирингу и исправлении записей. Малый бизнес зависел от банка в поддержке зарплат, платежей поставщикам и коммерческого банкинга. Неклиенты зависели от входящих платежей от пострадавших клиентов. Регуляторы зависели от банка в ведении безопасных, надёжных и справедливых систем. Банк контролировал системы, управление и доказательства восстановления.

Записи FCA, PRA и Центрального банка Ирландии делают вывод о подотчётности защитимым. Банки не просто пережили неудачный сбой. Регуляторы выявили неадекватные системы и контроль. Инцидент затронул миллионы клиентов, третьи стороны, участие в клиринге и доверие клиентов. За этим последовали возмещение и штрафы. Более поздняя работа по операционной устойчивости превратила тот же урок в более широкий регуляторный словарь.

Устойчивый урок состоит в том, что банковская автоматизация должна управляться как инфраструктура, обращённая к общественности, даже когда она работает ночью в фоновом режиме. Планировщик пакетных заданий — не второстепенный внутренний инструмент, если его сбой может задержать зарплаты, заблокировать ипотеки, нарушить зарплатные циклы малого бизнеса, ухудшить клиринг и оставить клиентов за границей без наличных.

RBS и NatWest превратили восстановление пакетной обработки в тест банковской подотчётности, потому что событие показало: сторона, контролирующая невидимые механизмы, также контролирует способность общества использовать деньги, когда эти механизмы выходят из строя.

Этот урок остаётся актуальным по мере того, как банки переводят больше услуг в интернет, закрывают отделения, консолидируют платформы и полагаются на автоматизированные контроли. Цифровой банкинг может повысить удобство и снизить издержки, но он увеличивает обязанность доказывать устойчивость. Банк, который просит клиентов и бизнес доверять автоматизированным платёжным системам, должен также доказать, что сбои ограничены, видимы, обратимы и устраняются с последствиями для клиентов в центре записи.