ТЕХНОЛОГИИ: Где деньги: Особенности банковских ИТ-решений

Одна из отечественных компаний-разработчиков банковского ПО опубликовала среднестатистические показатели своих заказчиков. Оказывается, крупный российский банк, обслуживающий физических лиц, имеет в среднем двести одновременно работающих сотрудников, более двадцати филиалов, около двухсот тысяч клиентов, семьсот тысяч счетов и обрабатывает транзакции по тремстам тысячам пластиковым картам. А если учесть необходимость соответствия российской специфике, которая выражается, например, в чехарде нормативных документов от ЦБ, МНС и других уважаемых государственных структур[Так, год назад панику среди банкиров посеяло распоряжение контролирующих органов о переводе всей бухгалтерии на Международные стандарты финансовой отчетности (МСФО)], то на выходе получим техническое задание для разработки информационной системы, обеспечивающей работу отечественного банка. Очевидно, что стандартные варианты автоматизации, применяемые в промышленности или торговле (ERP, CRM), здесь не годятся. «Финансовые супермаркеты» нуждаются в особых системах, мультифункциональных монстрах, которые смогут обработать огромные потоки разноформатных данных, связать множество филиалов и дополнительных офисов в единый финансовый организм, исключить возможность малейшей ошибки (ведь речь идет о чужих деньгах!) и полностью адаптироваться к специфике конкретного банка.

Спрос рождает предложение, а потому в России уже существует рынок банковских программных комплексов. Зарубежные продукты (Midas DBA, Bankmaster, Olympics, Symbols, Globus и др.) популярностью у отечественных банков не пользуются, - во-первых, из-за высокой цены (до нескольких миллионов долларов за одно внедрение) и, во-вторых, из-за особенностей отечественной финансовой системы. Прежде всего, отличаются принципы формирования отчетности - одной из главных функций банковского ПО. Даже прошлогодний переход российских банков на МСФО не способствовал снижению пресловутой национальной «специфичности». Дело в том, что учет в организациях по-прежнему ведется по правилам Центробанка, а отчетность по МСФО составляется из отчетности ЦБ позднее - методом трансформации. Кроме того, западные продукты не рассчитаны на постоянное внесение изменений из-за обновления законодательства - ведь «у них» правила игры не меняются каждый год.

В России автоматизированные банковские системы (АБС) серийно выпускают десятки компаний, из которых можно выделить нескольких лидеров: R-Style Softlab, БИС, «Диасофт», «Инверсия», «Кворум», «ПрограмБанк», «Форс» и ЦФТ[Имена некоторых компаний представляют собой аббревиатуры. БИС - Банковские информационные системы, БИФИТ - Банковские и финансовые интернет-технологии, ЦФТ - Центр финансовых технологий]. Вышеперечисленные фирмы в основном оказывают услуги крупным и средним банкам. На уровне же малых и средних банков широко распространены собственные разработки, зачастую написанные «по подобию» серийных продуктов. Например, в 2004 году уникальные системы для кредитования физических лиц использовали 21,56% российских банков, а для работы с частными вкладами - 21,96%.

Максимальные доли серийного решения в этих сферах достигают только 14,06% и 15,64% соответственно[Данные исследования, проведенного «Аналитическим банковским журналом»]. О стоимости своих решений компании говорить не любят, так как слишком много факторов влияют на конкретное предложение: требуемая функциональность, характеристика банка, степень доработки системы под заказчика, объем консалтинговой поддержки и т. д. Можно лишь отметить, что стоимость одной лицензии на АБС в минимальной конфигурации, базирующейся на дешевой СУБД (промышленные системы вроде Oracle - самый дорогой вариант, используемый для автоматизации крупных организаций), колеблется от 300 до 1000 долларов.

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

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

обследование бизнес-процессов;

адаптация как системы (например, содержащихся в ней шаблонов отчетности) под специфику банка, так и ряда старых технологий банка под АБС;

конвертация данных в новую систему;

обучение персонала;

в ряде случаев необходимость разработки шлюзов для взаимодействия с другими ИТ банка (наличие приложений от разных производителей в рамках одного предприятия в фольклоре ИТ-специалистов называется «зоопарком ПО»);

тестовый период эксплуатации.

Понятно, что при одновременном внедрении всех модулей на банковский ИТ-департамент (да и на другие службы) обрушивается куча разнообразных проблем, могущих привести к катастрофическим последствиям, которые, кстати, ощутят на себе и клиенты. Кроме того, для автоматизации отдельных функций банки иногда прибегают к сторонним продуктам. Например, часто применяется специализированное решение для интернет-банкинга (вроде iBank 2 от БИФИТ) или для биржевой торговли («Инвестор» от «Инист»).

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

У отечественных банков, выходящих на региональные рынки (чем сегодня в той или иной степени озабочены все крупные финансовые организации), возникают еще и проблемы обеспечения совместимости ПО и обмена данными со своими филиалами. Самая частая причина несовместимости систем в головном и дополнительных офисах - политика продвижения на рынке путем поглощения мелких банков-аборигенов, работающих на другой АБС. Если руководство не стремится к централизации управления в головном офисе, то каждому филиалу достается собственная система (центр может просто разослать копии своей АБС[Обычно тиражируются небольшие АБС. Некоторые из продуктов даже позиционируются как оптимальные для распространения по филиалам (например, RS-Bank на платформе Pervasive)]), а обмен данными сводится к пересылке бумажных носителей или файлов. Такой способ требует наименьших затрат, и это, пожалуй, его единственное достоинство. Управляемость же банков в этом случае минимальная. Обслуживая клиентов, филиал даже не имеет сведений о реальном состоянии счетов, по крайней мере до очередного сеанса связи.

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

Вариант «попроще» - с концентрацией филиальных АБС в одном месте. Филиалу достается программный клиент для удаленного доступа сотрудников к своей АБС и обмена данных с головным офисом. Для реализации этого варианта банку придется сформировать единый ВЦ и организовать дублируемые каналы широкополосной связи (чтобы филиалы имели доступ к собственным АБС).

Рассмотрим модульную структуру систем на примере 5NTe Bank (в частности, ее модулями пользуются Газпромбанк и Внешторгбанк), в которой весь спектр банковских операций разнесен по следующим блокам:

корпоративное обслуживание;

розничное обслуживание;

операции на финансовых рынках;

удаленное обслуживание;

обязательная и аналитическая отчетность;

управленческий учет и бюджетирование.

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

Ритейл-модуль - один из самых сложных по структуре. Это связано с обилием разноплановых направлений, которые он призван автоматизировать: потребительские кредиты, депозиты, переводы, обмен валюты, коммунальные платежи и т. д. Если рассмотреть структуру на примере RS-Retail, то там каждому из предлагаемых финансовых продуктов соответствует отдельное приложение, автоматизирующее тот или иной набор операций.

Автоматизированное рабочее место (АРМ) сотрудника, обслуживающего физических лиц (контролера, кассира, бухгалтера), создается из нескольких приложений. То есть в АРМ сосредотачивается весь спектр возможностей, необходимых пользователю, и в этом случае сотрудник фронт-офиса (то есть корпоративного подразделения, взаимодействующего с клиентами[Другое подразделение - бэк-офис - отвечает за учет совершаемых операций]) может даже не знать, как именно осуществляется в его банке бухгалтерский учет. Он должен только уметь приветливо улыбаться и вносить данные в нужные поля (тут, впрочем, он может воспользоваться подсказками системы). Вообще, независимо от концепции системы, почти все розничные решения призваны свести труд оператора к минимуму.

Архитектура учета в системе розничного обслуживания у разных продуктов может быть разной. Например, в 5NTe RETAIL она построена на двух базовых элементах: договоре и операциях. Последние регламентируются понятиями жизненного цикла и календаря. Договора связывают со счетами, клиентами и друг с другом, и в них определяются все положения об оказании той или иной услуги. Операция - это элементарное, настраиваемое действие обработки документа сотрудником. Доступ к изменению настроек документов на разных этапах исполнения разграничен дополнительным элементом концепции - жизненным циклом операции. Данные о периодических операциях (таких как начисление процентов) записываются в другом элементе - календаре событий.

Особым видом работы с частными клиентами является выдача кредитов. Не случайно в RS-Bank этот функционал даже не включен в розничный модуль, а перемещен в отдельный блок RS-Loans. От системы требуется поддержка самых разных видов кредитования: ипотечного, потребительского (которое, в свою очередь, делится на несколько подвидов, в зависимости от покупаемого товара), овердрафтного[Уход «в минус» картсчета в пределах установленного лимита] и др. Разумеется, можно предложить клиенту занять деньги на что угодно, однако каждый создаваемый подвид кредита нуждается в своей настройке.

В настоящее время банки озабочены проблемой скоринга, то есть регулирования кредитных рисков (невозврата, досрочного погашения, нерегулярных взносов и т. д.). Проверка потенциального заемщика тоже осуществляется автоматически[Задачи скоринга усложняются при реализации маркетинговых программ привлечения заемщиков. В частности, недавно один крупный банк в своем рекламном ролике предложил клиентам писать в графе «цель кредита» - просто «деньги». Для скоринга это означает изъятие одного из важных начальных условий задачи]. В ряде серийных продуктов содержатся интегрированные скоринг-системы, но абсолютное большинство банков пишут их под себя самостоятельно, потому что схема принятия решения о выдаче кредита у каждой организации своя. Есть и независимые разработчики таких решений, среди которых у нас наиболее известны EGAR (EGAR Application Scoring) и BaseGroupLabs (Deductor: Credit).

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

О возможностях управления счетом по компьютеру, мобильному телефону или КПК наслышаны, наверное, уже все. Да и любителей оформлять сделки и совершать покупки, не вставая с дивана, становится все больше. Неудивительно, что и на рынке приложений для удаленного банкинга (прежде всего, через Интернет) имеется неплохой выбор. Здесь помимо модулей АБС есть множество продуктов от независимых производителей. Яркий пример такого решения - iBank 2, детище компании БИФИТ. В этом программном комплексе, который установлен более чем в ста банках (в том числе в Банке Москвы и Газпромбанке), собраны практически все существующие технологии. Так, в едином информационном пространстве iBank 2 работают подсистемы

интернет-банкинга: управление банковскими счетами и пластиковыми картами в онлайн-режиме;

PC-банкинга: модификация классической схемы «клиент-банк», при которой клиенту нужно закачивать дистрибутив размером около 1 Мбайт;

мобильного банкинга: с установкой клиента-мидлета для КПК и смартфонов;

WAP-банкинга: получение данных о реквизитах банка, курсах валют, текущих остатках, выписках за определенный период, а также пополнение и блокировка карт, WAP-платежи;

SMS-банкинга: в случае iBank 2 только информационный сервис[Постепенно получают распространение системы управления счетом путем отсылки формализованных SMS (например, этот сервис реализован у Rapida)];

телефонного банкинга: получение данных о текущих остатках, выписки за период по факсу, пополнение и блокирование карты (модуль работает на платформе Intel Dialogic).

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

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

Представление об эффективности подобных систем дают результаты испытаний, проведенных компанией «Диасофт» для своего карточного модуля (табл. 2). В модель был включен сервер со следующими характеристиками: процессор Pentium 4 Xeon 2,4 ГГц, 8 Гбайт ОЗУ, Windows 2000, MS SQL 2000 Enterprise Edition. База данных имитировала структуру банка, имеющего 50 филиалов, 300 тысяч клиентов, 1,2 млн. счетов (30% в иностранной валюте), 350 тысяч карт, 12 млн. документов и 8 млн. карточных транзакций.

На субмодули, отвечающие за работу банка с картами, возложено очень много функций, а потому они часто подразделяются на отдельные программные компоненты. Нынешнее карточное приложение будет неконкурентоспособным без возможностей реализации зарплатных проектов и поддержки эквайринга[Эквайринг - деятельность кредитной организации, включающая расчеты с предприятиями торговли/услуг по операциям, которые совершаются с использованием банковских карт] для сотрудничества с торгово-сервисными сетями. Еще одно ценящееся на рынке свойство - поддержка максимального числа форматов обмена данными с фронт-офисными системами отечественных банков. В частности, карточный модуль 5NTe Retail поддерживает форматы WAY4 (ПЦ Банка Москвы, Мастер-Банка, МДМ-Банка, Экспобанка и др.), TPII (ПЦ Газпромбанка) Base24 (ПЦ STB Card Импэксбанка и др.), ACM (Автобанк-Никойл), 3Card-F (Union Card), ОСТ24.

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

Аналогичные случаи бывали и в России. В сентябре 2003 года банкоматы Сбербанка по всей стране начали добросовестно списывать средства со счетов по результатам транзакций, «забывая» выдать наличные пользователям. Причина - техническое переоснащение головного ПЦ банка в Москве. В декабре 2004 года произошла еще одна крупная ошибка в системе того же банка, которая привела к «двойным платежам», то есть повторному списыванию средств после оплаты покупки или выдачи наличных с кредитки[«Двойные платежи» - самое частое последствие сбоев в карточной системе].

Об устройстве и функционировании IT-решений для банковской сферы знать интересно и полезно, но в силу нелюбви финансовых учреждений к разглашению технических деталей своей деятельности многие занимательные подробности остаются в узком кругу посвященных. Разумеется, мы постараемся извлечь их на свет собственными силами, но если читатели «Компьютерры», знающие о жизни банков не понаслышке, захотят нам помочь, их помощь будет принята с благодарностью. Напомним, что редакция читает все письма, приходящие на адрес inform@computerra.ru