Консалтинг и автоматизация в области управления
эффективностью банковского бизнеса

Публикации

Банковские технологии

Семь нот качества данных

Всем известно, что качество данных определяется их своевременностью, полнотой, достоверностью и точностью1. Обеспечение качества данных -- это уникальная по своей природе и сложности задача, стоящая перед банковскими ИТ- и бизнес-подразделениями. Как показало анкетирование участников Data Integration Forum 2010, более 80 % российских банкиров не в полной мере доверяют данным, содержащимся в учетных операционных системах и применяемым для формирования регуляторной и управленческой отчетности.

Чем же можно объяснить столь пристальное внимание к этой задаче? По нашему мнению, в первую очередь это связано с мировой тенденцией ужесточения регулятивных и надзорных норм. Подтверждением могут служить результаты опроса финансовых учреждений, проведенного компанией Business Development Research Consultants: 73 % респондентов указали, что инвестиции, направленные на обеспечение качества данных, вызваны прежде всего необходимостью выполнения регулятивных требований. При этом 90 % опрошенных отметили, что они ожидают дальнейшего усиления требований регуляторов.

Похожая ситуация наблюдается и в России. Как показало анкетирование, проведенное на встрече банковских бухгалтеров с представителями Банка России, где обсуждались изменения в расчете обязательных нормативов, регламентированных указаниями Банка России № 2324-У, подавляющее большинство (75 %) бухгалтеров считает, что подготовка отчетности в последние годы существенно усложнилась.

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

В Директиве о требованиях к капиталу Базельского комитета сказано: «Данные, используемые для внесения в модель, должны быть точными, полными и адекватными»2 . Уже сегодня органы банковского надзора ряда европейских стран, опираясь на жесткие требования Базель II, вменяют в обязанность банкам обеспечить полноту, точность и соответствие данных, необходимых для подготовки отчетности по Базельскому соглашению.

Что же касается нашей страны, то Банк России объявил о присоединении к Базельским принципам еще в октябре 1998 г., и в последнее время его нормативно-законодательные акты ориентируются на выполнение этих принципов. Например, включение операционного риска в расчет норматива достаточности собственных средств (капитала) банка (Н1) обусловлено переходом отечественной банковской системы с 1 июля 2010 г. на международные стандарты оценки достаточности капитала.

Таким образом, абсолютно очевидно, что задача по обеспечению качества данных переходит в разряд наиболее приоритетных, непосредственно связанных с реализацией подготовки банковской отчетности.

Ситуация с качеством данных в российских банках

Если в европейских банках проблема с качеством данных худо-бедно решается, то в России с этим дела обстоят неблагополучно. Еще весной 2008 г. Банк России приступил к сотрудничеству с Европейским центральным банком по вопросам банковского надзора и внутреннего аудита в рамках проекта «Банковское регулирование и надзор (Базель II)», завершить который планируется весной 2011 г. Цель проекта -- содействие в реализации положений «Базеля» в России. В ходе экспертного анализа, определяющего соответствие актуальных внутрибанковских практик минимальным требованиям подхода, базирующегося на внутреннем банковском рейтинге (речь идет о так называемом IRB-подходе3 ), Банком России не было получено надлежащих свидетельств о наличии в подавляющем большинстве «пилотных» банков системного подхода к обеспечению качества данных. Внутреннюю документацию кредитных организаций Банк России считает слишком абстрактной: иногда даже непонятно, по какому принципу банки группируют заемщиков; не всегда они соотносят активы на балансе с обязательствами за балансом – гарантиями или кредитными линиями .4

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

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

Чтобы более предметно разобраться с проблемой качества данных, имеет смысл подробно остановиться на особенностях «партитуры» формирования банковской отчетности -- рассмотреть типовые проблемы, с которыми приходится сталкиваться при выпуске отчетности с помощью BPM-системы5.

От до -- до си

Чтобы дать наглядное представление об обобщенной картине опыта, накопленного компанией Intersoft Lab, успешно реализовавшей не один десяток проектов по внедрению BPM-системы в отечественных банках, мы решили представить ее в виде простой гаммы. Каждая «нота» озвучивает типичную проблему, связанную с обеспечением надлежащего качества данных. При этом мы постарались представить практические рекомендации, которые помогут с этими проблемами справиться.

До: ошибки в учетной политике

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

Поясним сказанное на конкретном примере -- определении норматива достаточности собственных средств (капитала) банка H1.

В соответствии с Инструкцией № 110-И при расчете норматива H1 используется величина кредитного риска по срочным сделкам КРС. Расчет величины КРС не представляет большой сложности в том случае, если банк ведет аналитический учет срочных сделок в соответствии с Положением № 302-П -- в разрезе каждого договора. Для вычисления КРС тогда достаточно информации по лицевым счетам и дополнительной информации (о группе риска, виде сделки и пр.) из данных по сделкам. Однако возможны ситуации, когда лицевые счета открываются в разрезе контрагентов. В этом случае на одном лицевом счете суммируются остатки от разных сделок различной срочности. Ситуация существенно усугубляется, если сами сделки при этом формируются не в одной учетной системе, а в нескольких.

В результате, чтобы получить информацию для расчета КРС и выпустить корректную отчетность, разработчикам BPM-систем и сотрудникам банковских IT-подразделений приходится создавать нетривиальные алгоритмы для извлечения из разных источников данных и их сверки.

Чтобы существенно упростить эту задачу, следует привести учетную политику в соответствие требованиям Положения № 302-П.

Ре: разрывы данных при изменении учетной политики

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

Например, в банке N учет основного долга по синдицированным кредитам на лицевых счетах ведется в течение нескольких лет в разрезе сроков до погашения (до 30, до 90, до 120 дней и т. д.). При этом на одних и тех же лицевых счетах отражаются остатки по разным контрагентам. После изменения учетной политики банка N основной долг для новых сделок учитывается уже и в разрезе контрагентов. Если процедуры расчета настроены на текущую учетную политику, то неизбежно выявятся расхождения между бухгалтерским и аналитическим учетом сделок.

Решение подобной проблемы может лежать как в плоскости методологии, так и в IT-области. IT-вариант предполагает выполнение «обогащения» данных, и к этому мы еще вернемся -- но немного позже.

Ми: методология расстановки признаков в карточках клиентов банка

Неполная и неточная информации о контрагенте -- ахиллесова пята при подготовке целого ряда форм отчетности. Так, для расчета некоторых форм (например, формы 0409117 «Данные о крупных ссудах» или формы 0409118 «Данные о концентрации кредитного риска») требуется однозначное определение вида деятельности клиента. На практике любое коммерческое предприятие может быть одновременно отнесено к нескольким видам деятельности (например, производству машин и оборудования, производству резиновых и пластмассовых изделий и т. д.). Как правило, коды, классифицирующие экономическую деятельность контрагента (ОКПО, ОКВЭД), устанавливаются в клиентском подразделении банка, сотрудники которого не обязаны знать инструкции по подготовке отчетности. В результате признаки, идентифицирующие вид деятельности клиента, задаются по усмотрению клиентских менеджеров.

Для обеспечения надлежащего качества данных необходимо обеспечить комплекс организационных мер, включающих:

  • выполнение регламентов работы с оперативными системами и хранилищем данных;
  • наделение сотрудников необходимыми правами и обеспечение их ответственности при заполнении сведений о контрагенте;
  • обучение сотрудников навыкам выполнения проверки и корректировки кодов.

Фа: недостаточность данных в оперативных системах

Как показало упомянутое выше анкетирование банковских бухгалтеров, большинство (60 %) опрошенных для расчета обязательных нормативов, регламентированных на основе Указания Банка России № 2324-У (это, пожалуй, одна из актуальнейших на сегодняшний день задач в области подготовки отчетности!), по-прежнему используют Microsoft Excel.

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

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

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

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

Соль: ручной ввод ряда сделок

Возвращаясь к вопросу о неполноте данных в учетных системах, отметим, что возможны ситуации, когда для ведения некоторых видов сделок (например, аваль, гарантии) нецелесообразно покупать специализированные учетные модули. Связано это с тем, что таких сделок мало, и для их регистрации достаточно средств «малой автоматизации» – Microsoft Excel. В этом случае сделки фиксируются в электронных таблицах, а проводки по лицевым счетам выполняются без привязки к сделкам. Однако формат таблиц настолько разнообразен, что выгрузка информации из них в хранилище данных практически невозможна. Поэтому для того чтобы эти сделки наравне с другими участвовали в процедурах расчета показателей отчетов, выполняется процедура обогащения данных, а в хранилища данных загружаются только лицевые счета.

Ля: ошибки бухгалтерского учета

Как известно, Положение № 302-П задает несколько десятков проверок бухгалтерского учета. Среди них: корректность остатков на «парных» счетах, остатков балансовых счетов межфилиальных расчетов, остатков балансовых счетов по учету амортизации стоимости имущества, ежедневных остатков и оборотов по символам ОПУ и т. д. Например, суммарные обороты по кредиту «пассивных» символов ОПУ должны совпадать с суммой оборотов по кредиту балансовых счетов №№ 70601, 70602, 70603, 70704 и 70605.

Все эти проверки должны быть реализованы в системе выпуска отчетности, и в случае обнаружения ошибок бухгалтерского учета необходимо внести изменения (выполнить так называемые исправительные проводки) в автоматизированные банковские системы, перегрузить данные в хранилище данных и заново выполнить проверки и расчеты.

Обычно сложности возникают, когда регламент подготовки отчетов не позволяет сделать все это вовремя. Здесь приходится оперативно вносить исправления непосредственно в данные, находящиеся в хранилище, и выпускать отчеты. Затем нужно скорректировать данные учетных систем и привести в соответствие данные в хранилище и АБС. При этом обязательно следует разработать регламенты работы с оперативными системами и хранилищем данных, наделить сотрудников соответствующими правами и обеспечить ответственность за соблюдения указанных регламентов.

Си: ошибки округления в оперативных системах

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

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

Семь бед – один ответ

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

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

Применительно к выпуску сложных форм, стоит отдельно упомянуть о технологии обогащения данных (о ней мы несколько раз говорили выше). Необходимо, чтобы решение поставщика позволяло классифицировать данные учетных систем признаками, нужными для отчетности и отсутствующими в АБС. Например, информацией по инсайдерам и аффилированным лицам. Наличие такой функциональности решает проблему отсутствия в учетных системах данных по связанным клиентам и позволяет автоматизировать выпуск таких форм, как 0409051 и 0409052 «Список аффилированных лиц», 0409157 «Сведения о крупных кредиторах (вкладчиках) кредитной организации», 0409117 «Данные о крупных ссудах», 0409118 «Данные о концентрации кредитного риска».

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

В начале 2010 г. в ОАО «ТрансКредитБанк» был выполнен проект, который обеспечил оценку возможностей интеграционной платформы Informatica PowerCenter для сбора данных в хранилище BPM-системы банка. В результате было подтверждено, что применение Informatica PowerCenter позволяет сократить цикл загрузки, очистки и проверки данных из учетных систем банках в корпоративное хранилище до уровня, соответствующего требованиям регламента подготовки данных для ежедневного расчета нормативов. Банк принял решение использовать интеграционную платформу в проекте комплексной автоматизации расчета обязательных нормативов, который выполняется специалистами компании Intersoft Lab.



1. Giovinazzo W. BI: Only as Good as its Data Quality / Information Management Special Reports – 2009, August 18.

2. Директива о требованиях к капиталу Базельского комитета (Приложение VII, Ч. 4, пункт 31).

3. IRB – Internal Ratings Based.

4. Воронова Т. Неуправляемые банки / Ведомости, 21 июля 2010 г., № 133 (2651),.

5. BPM -- от англ. Business Performance Management -- управление эффективностью бизнеса. ВРМ-системы опираются на хранилище данных и обеспечивают финансовую консолидацию, планирование и бюджетирование, управление доходностью, управление рисками и подготовку отчетности для различных регуляторов.