Тема 7.3. Информационные технологии в банках. Дистанционное обслуживание клиентов

Автоматизированная банковская система (АБС) - аппаратно

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

- Рутинные банковские операции - обработка документов, ведение кредитных дел, межбанковские расчеты, валютно-обменные операции и т.

д.

- Накопление данных, формирование отчетности, организация внутреннего контроля

- Аналитическое обеспечение функций принятия решений руководством банка.

Начало развитию АБС за рубежом было положено в 70-х годах ХХ века. Многие АБС, созданные тогда (например, MIDAS), работают в российских и зарубежных банках по сей день. В России первые АБС появились в 80-х годах. Первоначально российские АБС создавались как учетные программы для банков, в дальнейшем их разработчики поставили перед собой задачу развития АБС как универсальных систем и успешно решили ее.

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

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

Основными составляющими программно-технической платформы являются:

- Аппаратная платформа.

- Операционная система.

- Система управления доступом к данным.

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

AS/400 - операционная система OS/400 на компьютерах IBM AS/400;

MAINFRAME - операционные системы MVS, VSE и аналогичные на компьютерах IBM/370/390 и аналогичных;

UNIX - Unix-подобные операционные системы, способные работать на различной аппаратуре;

операционные системы Windows NT, Novell NetWare и OS/2, работающие на аппаратуре Intel. Такое объединение объясняется тем, что по доступным материалам не удалось однозначно сгруппировать представленные АБС по перечисленным в данном пункте операционным системам.

Используемые для построения АБС системы управления доступом к данным делятся на две категории:

- Промышленные СУБД.

- Файловые системы, основанные на методах доступа используемой операционной системы.

Именно от типа используемой системы управления доступом к данным во многом зависят такие качества АБС, как открытость и переносимость. Кроме того, тип используемой системы управления доступом существенным образом влияет на общую стоимость АБС.

С этой точки зрения АБС, построенные на основе СУБД, обладают следующими преимуществами:

- Они поддерживают стандартный язык манипулирования данными (SQL), обеспечивая тем самым открытость.

- Легче переносятся с одной аппаратно-системной платформы на другую.

- Более просты в разработке и развитии.

- В то же время АБС на основе файловых систем:

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

- В ряде случаев могут оказаться более производительными в части доступа к данным.

- Не требуют привлечения специалистов по СУБД, что в целом также удешевляет проект.

- Более просты во внедрении и сопровождении.

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

Необходимо пояснить некоторые понятия, положенные в основу классификации. Прежде всего, следует обратить внимание на структуру АБС.

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

Обязательным элементом является базовый, основной модуль, который называется ядром АБС. Ядро АБС обеспечивает выполнение основных операций над банковскими базами данных, контролирует целостность и корректность данных, отвечает за безопасность системы в целом. Работа всех остальных модулей АБС опирается на основные операции, которые производятся в ее ядре.

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

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

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

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

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

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

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

3. Хост - терминал. В системах этого типа компьютер - клиент служит средством ввода и вывода алфавитно-цифровой информации и носит название «терминал пользователя». Центральный компьютер является местом хранения и обработки данных, а также осуществляет преобразование запросов компьютеров-клиентов и результатов их выполнения.

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

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

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

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

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

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

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

Дистанционное обслуживание клиентов - электронное расчетное обслуживание клиентов - юридических и физических лиц с использованием средств связи для передачи платежных документов от клиента в банк и различных документов и информации - из банка клиенту (так называемый КЛИЕНТ-БАНК), в том числе с использованием пластиковых карт, Интернет-технологий, а также так называемый «телефонный банкинг».

Чаще всего отдельной группой выделяются модули АНАЛИЗА ФИНАНСОВОГО СОСТОЯНИЯ банка, его клиентов и его контрагентов.

Важное значение имеет то, каким образом связаны между собой отдельные функциональные модули (автоматизированные рабочие места или АРМы) АБС. Можно выделить следующие типы связи:

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

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

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

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

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

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

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

- Первое поколение: аппаратная платформа - автономные персональные компьютеры под управлением MS-DOS; СУБД - Clipper, FoxPro, Clarion; базовый элемент технологии - бухгалтерская проводка; структура АБС - автономные АРМы, не связанные или слабо связанные по данным через обмен файлами (в том числе путем физического переноса на гибких дисках с компьютера на компьютер). Сейчас практически не встречается.

- Второе поколение: аппаратная платформа - персональные компьютеры под управлением MS-DOS, работающие в локальной сети Novell NetWare; СУБД - Clipper, FoxPro, Clarion; базовый элемент технологии - бухгалтерская проводка; структура АБС - автономные АРМы, связанные по данным через общие файлы, лежащие на сервере, и не связанные по функциям. Активно использовались в середине 90-х гг., особенно в небольших региональных банках.

- Третье поколение: аппаратная платформа - персональные компьютеры под управлением MS-DOS (MS Windows), работающие в локальной сети Novell NetWare (Windows NT); СУБД - собственная разработка на базе менеджера записей Btrieve; базовый элемент технологии - бухгалтерская проводка, реже - документ; структура АБС - автономные АРМы, сильно связанные по данным через общие структуры базы данных и слабо связанные по функциям. Технология, переходная от "файл-сервер" к "клиент-сервер". АБС этого поколения были широко распространены в середине-конце 90-х гг., в том числе в ряде крупных банков. Есть исключительно удачные реализации.

- Четвертое поколение: аппаратная платформа - персональные компьютеры под управлением MS-DOS (MS Windows), работающие в локальной сети, или же хост-компьютер с терминалами; СУБД - профессиональная реляционная (может быть постреляционная или сетевая); базовый элемент технологии - бухгалтерская проводка (реже), документ, сделка; структура АБС - автономные АРМы, сильно связанные по данным через общие структуры базы данных, в отдельных случаях связанные по функциям через общее ядро. Технология "хост-терминал" или двухуровневая "клиент-сервер". Довольно распространено.

- Пятое поколение: аппаратная платформа - персональные компьютеры под управлением MS Windows, MS-DOS, реже UNIX, в распределенной сети (WAN) с несколькими физическими серверами приложений (которые работают под многозадачными многопользовательскими ОС); СУБД - профессиональная реляционная плюс менеджер транзакций; базовый элемент технологии - документ или сделка; структура АБС - логические АРМы, сильно связанные как по данным, так и по функциям в пределах локальной сети или хоста и слабо связанные по данным в пределах распределенной сети. Технология трехуровневая "клиент-сервер" с использованием менеджеров транзакций. Единичные разработки.

- Шестое поколение: аппаратная платформа - гетерогенная сетевая среда; СУБД - профессиональные реляционные с открытым интерфейсом (возможно одновременно несколько разных СУБД); базовый элемент технологии - сделка или документ; структура АБС - логические АРМы, динамически формируемые по компонентной технологии, сильно связанные по данным и функциям в пределах всей сети intranet. Перспективная технология, появившаяся недавно. Единичные разработки.

Требования, предъявляемые к АБС.

- Функциональная полнота и производительность. Требования к функциональности АБС, в сущности, довольно очевидны:

- Поддержка корректного выполнения всех операций банка в соответствии с действующими инструкциями Банка России и правилами бухгалтерского учета.

- Поддержка корректного составления всей отчетности, требуемой действующими инструкциями Банка России, стандартами МСФО (GAAP), другими нормативными документами.

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

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

Надо только иметь в виду, что банку следует устанавливать требования к функциональности АБС исходя не из "сегодняшнего" состояния банка, а по крайней мере из расчета на то состояние, которое предполагается иметь через два года. Иными словами, необходимо спланировать или спрогнозировать набор операций, количество клиентов, объем документооборота и прочие основные характеристики банка не менее чем на два года вперед (а лучше - на пять лет).

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

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

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

Все более важной становится способность АБС работать в распределенной сетевой среде. Теперь это все чаще не просто локальная сеть: происходящие в российской банковской системе изменения объективно ведут к сокращению числа банков при одновременном росте их филиальных сетей.

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

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

Скорость работы АБС должна в идеале несколько опережать потребности банка. В современном банке на одного операционного работника приходится в среднем до 400 операций за 1 рабочий день. Функциональная полнота подразумевает, что набор модулей АБС соответствует видам операций, производимых банком, и обеспечивает полную автоматизацию деятельности банка.

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

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

- Сохранение ранее сделанных капитальных вложений при переходе на более производительный вариант аппаратной платформы.

- Возможность установки АБС как в головном офисе банка, так и в самостоятельных филиалах.

Открытость - возможность интеграции с другими информационными системами. Это качество обусловлено следующими требованиями:

- Одновременная работа на одном и том же оборудовании модулей АБС и другого программного обеспечения, разработанного банком или третьими фирмами, в том числе пакета Microsoft Office, принятого де-факто в качестве корпоративного стандарта большинством организаций.

- Информационный обмен с другими системами автоматизации, в том числе с использованием механизмов DDE.

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

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

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

Для обеспечения безотказной и надежной работы АБС применяются следующие методы:

- Оснащение аппаратурой, регулирующей скачки напряжения и обеспечивающей бесперебойное электроснабжение,

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

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

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

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

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

Способы обеспечения безопасности АБС можно сгруппировать следующим образом:

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

- Аппаратные методы предполагают наличие устройств, ограничивающих и контролирующих доступ к вводу и выводу информации (электронные ключи, анализаторы и т.п.)

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

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

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

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

2. Интеграция лучших специализированных систем различных поставщиков в единый комплекс, выполняемая силами специалистов банка или компании - системного интегратора. Этот вариант чаще всего связан с большими затратами.

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

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

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

Автоматизированные системы, решающие задачи оперативной обработки транзакций с одновременным обращением к базе большого количества пользователей, относятся к типу OLTP-систем (On-Line Transaction Processing). Мировая практика показывает, что традиционный (реляционный) метод проектирования баз данных, используемый для систем обработки транзакций, не соответствует задачам синтеза, анализа, консолидации данных.

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

Существует два подхода к их практической реализации.

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

Альтернативный подход заключается в построении многомерных структур данных на базе обычных реляционных СУБД (такой подход называют ROLAP-структурой). Этот подход не использует всех возможностей OLAP-технологий с точки зрения анализа. Многие стандартные решения в OLAP реализуются «вручную» в ROLAP-структурах. Но ROLAP- структуры предпочтительнее, так как могут сосуществовать с любой реляционной СУБД, не требуя от банка замены старой АБС.

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

Большинство российских АБС работают в двух- или трех-уровневой архитектуре «клиент-сервер». Все АБС могут работать в разных средах, среди которых доминируют Windows NT и разные варианты UNIX в качестве серверных операционных систем, но называются и многие другие, в первую очередь Novell Netware. Что касается клиентских рабочих мест, то можно назвать такие операционные системы, как DOS, разные варианты Windows, достаточно редко используемую Java и др. Среди используемых СУБД представлен практически весь спектр систем, представленных на рынке. При этом обращает на себя внимание тот факт, что пользователи ряда АБС могут использовать на выбор несколько СУБД.

Среди российских разработчиков по продажам программного обеспечения для банков (по числу инсталляций) лидируют “R-Style Software Lab.” (программа RS-Bank) и «Диасофт» (DiasoftBank 4x4, Diasoft 5NT). За ними следуют компании «Форс» (Ва-Банк), «Кворум» (Кворум), «Про- грамбанк» (Гефест), «Инверсия» (Invobank) и ряд других.

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

RS-Bank - программный комплекс производства ООО «R-Style Software Lab.» Полная версия системы RS-Bank вышла в свет в 1993 году.

RS-Bank позиционируется разработчиком как система комплексного информационного и функционального обеспечения автоматизации всего спектра банковских услуг. АБС предоставляет средства для ведения качественного внешнего (бухгалтерского) и внутреннего (управленческого) учета. С помощью OLAP-технологий в программном комплексе реализовано аналитическое ядро, представляющее собой основу функционирования и инструмент разработки аналитических подсистем(включая собственно подсистему анализа консолидированной информации).

В основу АБС RS-Bank v.5.0 положены следующие базовые концепции: модульная организация системы (разделение на фронт-, бэк-, мидл- офисы), разделение модулей на OLTP- и OLAP-приложения, принцип на-

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

DiasoftBANK (фирма-производитель ЗАО «Компания «Диасофт»). Компания «Диасофт» предлагает в настоящее время несколько вариантов комплексной автоматизации банка на базе трех линий программных продуктов, ориентирвоанных на различные технологические платформы и имеющих ряд характерны отличительных признаков.

DiasoftBank 4x4 является наиболее массовым решением, отличается относительной простотой при внедрении и эксплуатации. Базовый вариант системы работает на платформе Btrieve / Pervasive SQL. Другая версия системы - DiasoftBANK 4x4 Workflow - поддерживает работу на 5 платформах, добавив к вышеупомянутым MS SQL Server, DB/2 for AS/400, Informix, Oracle.

Решение на базе системы «Новая Афина» способно поддержать работу крупного многофилиального банка с количеством операций от 1000 в день. Мощность системы обеспечивается возможностями промышленной СУБД Oracle.

DiasoftBanking 5NT - решение для мелких и средних банков на платформе MS SQL Server или Sybase Adaptive Server.

Любой из вышеперечисленных программных комплексов, взятый за основу системы автоматизации, решает основные задачи обеспечения деятельности коммерческого банка: ведение главной книги, расчетно-кассовое обслуживание, автоматизация работы бухгалтерии, межбанковские и межфилиальные расчеты (связь с РКЦ, SWIFT и т.д.), получение финансовой и управленческой отчетности, крединое и депозитное обслуживание. Общие характеристики продуктов:

- многовалютность - позволяет работать с произвольным количеством валют в банке (при этом одна валюта выделяется в качестве национальной)

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

- многоплановость - позволяет банкам работать с произвольным количеством планов счетов.

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

«Центавр», «Гефест», «Афина» (ООО «ПрограмБанк»). Компания «ПрограмБанк» является одним из старейших разработчиков банковских систем в России, основана в 1989 году группой выпускников МФТИ, разработавших систему автоматизации для ряда крупнейших на тот момент коммерческих банков. Этот программный продукт стал прародителем ИБС «Центавр», которой пользуются сейчас около 400 банков. Такое решение оптимально для небольших банков, имеющих до 20 рабочих мест и до 1000 операций вдень.

В 1993 году была начата разработка интегрированной АБС «Афина» (ныне - ИСУБД «Новая Афина», совместная разработка с Компанией «Диасофт»), базирующейся на промышленных СУБД класса Oracle и программных платформах класса UNIX. Сегодня «новая Афина» используется в подразделениях Сбербанка РФ, Внешторгбанка РФ, МДМ - банка, а также в ряде представительств зарубежных банков. «Новая Афина» представляет собой набор автоматизированных бизнес-систем, работающих на основе универсального финансового ядра. Система реализована в архитектуре «клиент-сервер», основным объектом для работы в системе является документ - электронная копия реального финансового или учетного (административного) документа банка, паспорт сделки, свидетельство о совершении сотрудником банка определенной операции.

В 1996 году начала разрабатываться АБС «Гефест», занимающая нишу автоматизации средних по величине капитала кредитных учреждений с широкой региональной сетью филиалов и дополнительных офисов, с ежедневным документооборотом в несколько тысяч документов. Она направлена на решение задач финансового управления банком. В ее основу положена система электронного управления документооборотом с использованием СУБД Cache.

КВОРУМ (ЗАО «АО Кворум») начала создаваться в июле 1992 года одновременно с учреждением фирмы-разработчика. АБС является полнофункциональным решением, способным обеспечить эффективную автоматизацию широкого диапазона бизнес-процессов современного банка. Система КВОРУМ опирается на концепцию коллективной обработки банковских операций и основывается на принципе единой базы данных. Комплексный характер системы заключается в том, что в ней не только реализованы функции, связанные с основной деятельностью банка (операционное обслуживание, кредитование и т.д.), но и подсистемы, обеспечивающие автоматизацию внутрихозяйственной деятельности банка (учет кадров, зарплаты, основных средств и др.). Всего в состав КВОРУМ входят более 40 программных модулей.

Начиная с версии 6.0, в рамках АБС КВОРУМ поддерживаются две линии программных продуктов. Первая в качестве СУБД использует

Btrieve Record Manager, вторая работает на платформе Oracle Server. Обе линии используют одни и те же пользовательские интерфейсы. Бизнеслогика также является единой с алгоритмической точки зрения, различаясь способом реализации( в приложениях, ориентированных на Oracle, бизнеслогика реализована в виде хранимых процедур на языке PL/SQL).

С точки зрения программно-технической платформы, зарубежные банки ориентированы на крупные компьютерные системы. Несмотря на то, что наибольшее распространение в мире получили автоматизированные банковские системы на платформе AS/400, в настоящее время большинство банков предпочитают приобретать АБС на так называемых открытых платформах, в первую очередь на платформах UNIX.

Около половины западных банков предпочли АБС на основе промышленных СУБД. В то же время 75% всех (по номенклатуре, а не по количеству) АБС на платформе UNIX построено на базе именно промышленных СУБД.

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

Функциональные характеристики западных АБС также имеют существенные отличия от российских аналогов. В западных АБС, как правило, отсутствуют функции автоматизации внутрихозяйственной деятельности банка. Это объясняется сложившейся зарубежной практикой, когда АБС автоматизирует только бизнес-функции, а для автоматизации внутрихозяйственной деятельности используются специализированные системы типа R/3 фирмы SAP или PRMS фирмы Acacia Technologies. По тем же причинам в двух представленных АБС (Finance KIT и Trading Assistant) отсутствует подсистема «Главная книга», которая может быть построена на основе, например, Oracle Financials.

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

Далее рассмотрим некоторые характеристики наиболее известных на зарубежном рынке АБС.

Midas DBA, Equation DBA (Midas-Kapiti International, UK)

Эти АБС являются мировыми лидерами по количеству пользователей и количеству действующих установок. Они хорошо известны и на рынке стран СНГ (более 20 внедрений). В целом системы себя зарекомендовали как довольно «жесткие», трудно настраиваемые на особенности местного законодательства и нормативной базы. Объясняется это тем, что из рассмотренных это самые старые (в смысле используемых при разработке и программировании подходов, методов и инструментальных средств) системы - их коммерческие продажи начались в 1975 (Equation) и 1977 (Midas) г. Системы работают на платформе IBM AS/400.

Bankmaster (Kindle Banking Systems Ltd., Ireland)

Bankmaster занимает третью позицию по числу пользователей среди всех рассмотренных систем и первую позицию среди систем на платформе UNIX. Система ориентирована на небольшие и средние банки. Основными рынками сбыта системы являются Великобритания (около 25%), Африка (около 15%), Юго-Восточная Азия (20%), Ближний Восток (15%) и Северная Америка (до 7%).

Первая коммерческая система была разработана в 1980 г. для аппаратно-системной платформы ICL. В 1987 г. был выполнен перенос системы на платформу UNIX, а в 1996 г. - на платформу Windows NT. В качестве информационной основы АБС используются методы доступа операционной системы, однако, в 1994 г. была выпущена версия АБС (BANKMASTER/RS), в которой для управления данными применяется промышленная СУБД Informix.

Bankmaster - это универсальная банковская система, однако существенная доля функциональных подсистем поддерживается за счет дополнительных продуктов производителя или третьих фирм:

- Контроль позиций поддерживается системой City Dealer от MKI.

- Документарные операции - системой IBSnet.

- Официальная отчетность - системой Abacus.

- Выверка подтверждений - системой CMS.

- Выверка счетов лоро и ностро - системой Soar.

- Электронный банкинг - системой Fontis от Credo.

Розничные операции сосредоточены в отдельном продукте BRANCHPOWER, предназначенном для установки в филиалах и отделениях банка. Интеграция отделений (филиалов) с центральным офисом осуществляется по сетям АТМ или Х.25. Допускается как автономная работа отделений (филиалов), так и совместная работа в режиме клиент-сервер с использованием интерфейсного продукта Transaction Processing Gateway.

Microbanker (Citicorp IT Industries Ltd. (Citil), India)

Прообразом АБС Microbanker стала разработанная в Citibank система Cosmos, которая была переработана и перенесена на платформу UNIX. Система ориентирована на небольшие и средние банки. Основными рынками сбыта системы являются континентальная Европа, Африка, Юго-Восточная Азия и Ближний Восток. Ближайшим конкурентом Microbanker является АБС Bankmaster, хотя есть и исключения - в 1996 г. Rabobank, являющийся пользователем систем Midas и Atlas, принял решение устанавливать АБС Microbanker во все свои новые подразделения.

АБС работает на широком спектре UNIX-платформ, поддерживает алфавитно-цифровой пользовательский интерфейс и использует методы доступа файловой системы для организации информационной базы. Анонсирована работа АБС на платформах Novell Netware и Windows NT, однако реально работающих в промышленном режиме установок такого рода нет.

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

- Главную книгу.

- Обновление остатков в режиме реального времени.

- Валютный дилинг.

- Межбанковский дилинг.

- Кредиты.

- Документарные операции.

- Торговлю ценными бумагами.

Кроме того, доступен ряд дополнительных продуктов того же производителя, расширяющих функциональные возможности АБС:

- Система MoneyMaker автоматизирует фронт-офис для межбанковских операций и покрывает валютный и межбанковский дилинг, опции доходности, анализ прибылей и убытков, управление позицией, обработку лимитов и денежных потоков; планируется поддержка деривативов. Имеются интерфейсы к системам моделирования и к Reuters 2000.

- Система Customer Access Systems поддерживает электронный банкинг.

- Система Finware автоматизирует бэк-офис розничных операций и включает:

- Главную книгу.

- Кредиты.

- Ипотеку.

- Депозиты.

- Текущие и сберегательные счета.

- Безналичные расчеты и взаимозачеты.

Система обеспечивает онлайновые связи между всеми подразделениями банка, поддерживает автоматические кассовые аппараты (теллеры) и стандарты ISO для доступа к другим периферийным устройствам. В настоящее время CITIL предлагает комплекс из АБС Microbanker и Finware как интегрированное решение под торговой маркой Unified Banking Solution.

Несмотря на относительно высокие маркетинговые показатели систем IBS-90 и Abraxys, вряд ли стоит рассматривать их как серьезных кандидатов на внедрение в российских банках. Во-первых, они обладают недостаточной функциональностью. Во-вторых, фирма-производитель не имеет удовлетворительной стратегии по развитию и поддержке продукта. Функциональное развитие АБС Abraxys (развитие IBS-90 прекращено, хотя поддержка ведется) осуществляется по принципу локальных доработок для отдельных пользователей системы, которые производятся по дополнительным контрактам. Затем наиболее удачные решения включаются в новую версию системы. Характерным примером неудовлетворительности такой стратегии является факт, что в восьмой версии системы, которая планировалась к выпуску в июле 1998 г., отсутствует поддержка евро.

АБС IBIS была разработана в начале 1980 г. в лондонском Итальянском Международном банке (Italian International Bank). Производители утверждают, что система была разработана «с нуля» для платформы IBM System/38, и в этом заключается ее преимущество перед системами Midas и Equation, которые были разработаны для этой же платформы, но еще в середине 1970 г. В то же время некоторые конкурирующие производители высказывают мнение, что IBIS - это всего лишь результат переноса с платформы IBM System/3 внутрикорпоративной разработки 1970 г.

Основными рынками сбыта системы являются регионы ЮгоВосточной Азии, Восточной и континентальной Европы и, в меньшей степени, США. Обычно пользователи рассматривают IBIS как более новую и менее рискованную альтернативу системам Midas и Equation.

К 1992 г. система была перенесена на платформу IBM AS/400 и стала распространяться под маркой IBIS/AS.

Функциональное развитие системы осуществлялось в форме проектов для отдельных банков.

Для лондонского Svenska Handelsbanken была выполнена работа по переносу всех функций обработки финансовых сообщений в отдельный модуль. В результате появилась Система обработки сообщений (MPS), обрабатывающая большинство платежей в подсистемах обслуживания частных лиц и корпоративных клиентов и дилинга, обработки сообщений и подтверждений, включая он-лайновые связи с корпоративными клиентами и SWIFT.

Для Banco Espirito Santo (Лондон) был добавлен интерфейс к модулям коммерческих и синдицированных кредитов; для Ceskoslovenska Obchodni Banka разработан фронт-офис подсистемы розничных операций; с BNE Swedbank (Люксембург) был согласован проект «Управление фондами»; элементы рынка капиталов были разработаны для Bank of America. Был также выполнен большой проект по депозитам частных лиц для Union Bank of Finland.

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

- 12 пользователей оценили подсистемы «Главная книга», «Валютный дилинг», «Межбанковский дилинг» и кредитные модули как «удовлетворительные» (хотя один пользователь оценил модуль «Валютный дилинг» как «неудовлетворительный»);

- половина пользователей, использующих модуль «Фьючерсы», оценили его как «неудовлетворительный»;

- модуль «Соглашения о форвардной сделке» 57% пользователей оценили как «приемлемый»; 43% - как «неудовлетворительный»;

- модуль «Свопы» 20% пользователей оценили как «приемлемый», 80% - как «неудовлетворительный»;

- модуль «Официальная отчетность» 75% пользователей оценили как «приемлемый»; 25% - как «неудовлетворительный»;

- средства генерации отчетов 11% пользователей оценили как «хорошие»; 67% - как «приемлемые»; 22% - как «неудовлетворительные»;

- половина пользователей заявили, что они обладают системой, которая наилучшим образом отвечает их потребностям; три пользователя затруднились дать такую оценку; двое пользователей заявили, что не считают IBIS лучшим выбором, и двое - что проект по внедрению АБС завершился неудовлетворительно. Ни один из пользователей не оценил систему как «отличную»;

- в то же время, с точки зрения качества и оперативности обслуживания и поддержки, АБС IBIS выглядела лучше своих конкурентов - 22% пользователей оценили сервис как «отличный»; 56% - как «хороший» и 22% - как «адекватный».

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

В технологическом направлении были сделаны следующие усовершенствования:

- заменена система генерации отчетов;

- в систему розничных операций добавлены: поддержка прямого дебетования; поддержка регулярных платежей в адрес нескольких получателей; поддержка комиссий; интерактивный доступ к SWIFT терминалу Alliance;

- внедрен новый дилинговый модуль, который полностью заменил старую систему ввода сделок. Новый модуль является дополнением к существующим модулям поддержки бэк-офиса дилинга и расширяет их возможности в части: ввода уведомлений о сделках; улучшенной обработки кредитов с возможностью пересмотра условий, интерфейса с Reuters Dealing 2000, поддержки сенсорных экранов (touch-screens);

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

- добавлена система управления рисками, поддерживающая стандартные модели и методы, включая Value at Risk и JP Morgan’s Riskmetrics. Кроме того, систему можно использовать для анализа «Что, если».

Планируется к внедрению новый модуль «Репо», который заменит имеющийся модуль, ориентированный в основном на учет.

Система Finance KIT задумывалась как фронтальная часть бэк-офиса казначейства. Она была разработана в начале 1990 г. и получила распространение в основном в секторе корпоративного казначейства, хотя было и несколько пользователей-банков. В частности, одним из первых пользователей АБС был ABB Financial Services - банковское подразделение международной корпорации ABB Broun Group.

Первоначально в качестве платформы АБС были выбраны персональные компьютеры с операционной системой Windows и «настольной» СУБД Access фирмы Microsoft. Однако эта платформа не смогла обеспечить требуемой производительности, и к 1994 г. АБС была переписана для платформы UNIX и СУБД Sybase. В настоящее время АБС доступна на платформах Sun Solaris и HP-UX. Перенос на другие платформы или другую СУБД не планируется; версия для Windows больше не продается, но добавлена поддержка клиентских рабочих мест для Windows 95 и Windows NT.

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

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

Как фронт-офис АБС взаимодействует с продукцией третьих фирм, включая дилинговые системы, системы телефонных торгов и инструменты анализа и ценообразования - JP Morgan’s Riskmetrics, электронные таблицы, пакеты бухгалтерского учета, ценообразования валютных опционов и форвардных операций, моделирования «Что если» и ценообразования в операциях с нулевым купоном.

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

На уровне бэк-офиса Finance KIT поддерживает расчеты, клиринг и платежи. Обновление всех позиций производится в режиме реального времени. АБС имеет интерфейсы к системам официальной отчетности, согласования и выверки, а также к терминалам SWIFT. АБС не имеет собственной подсистемы «Главная книга», и должна быть сопряжена с соответствующим функционалом стороннего производителя.

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

Первая версия системы Bancs (Financial Network Services PTY Ltd., Australia) была разработана в конце 70-х гг. подразделением обработки данных State Building Society для автоматизации бэк-офиса розничного сектора. Система работала на компьютерах NCR9800 под управлением операционной системы VRX. В 1982 г. для осуществления поддержки продукта, его развития и распространения на коммерческой основе, была организована дочерняя фирма Financial Network Services, куда вошли разработчики системы. Сейчас продукт известен под двумя торговыми марками FNS и Bancs, в зависимости от используемой платформы. Система работает на широком круге аппаратных и системных средств, включая мейнфреймы IBM, DEC VAX и различные Unix-системы. Особенностью работы в распределенных средах является как возможность взаимодействия с центральной базой в оперативном режиме, так и работа в автономном режиме в случае возникновения проблем с коммуникациями.

Изначально система предназначалась для автоматизации розничных операций малых и средних объемов. Она охватывает депозиты, кредиты, поддерживает автоматические кассовые аппараты и торговые терминалы. Система не имеет «Главной книги», но имеет интерфейсы к Finance One, Oracle Financials и Peoplesoft, которые реализуют эту функцию. Документарные операции реализуются системой Intrafins. В 1995 г. была добавлена поддержка множественных лимитов, управление портфелями и проектами, автоматизация взаимозачетов, моделирование продаж.

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

Первая версия АБС Platon (IMS Business System Corp., USA) была разработана для двух находящихся в Нью-Йорке корейских банков в 1985 г. АБС написана на 4GL Progress и работает на широком круге Unix-платформ. В 1996 г. была выпущена 32-разрядная версия для платформы Windows NT, но реальных продаж пока нет. Имеются интерфейсы к СУБД ORACLE, DB2 и DB2/400.

Platon охватывает основные операции валютного и межбанковского дилинга, коммерческие и потребительские кредиты, ипотеку, прием и выпуск аккредитивов, работу со счетами ностро. АБС имеет средства обработки и передачи основных финансовых сообщений через SWIFT, CHIPS, FEDWIRE и телекс (через соответствующие интерфейсы).

Поскольку Platon имеет ограниченные возможности в части казначейства, был разработан интерфейс к системе валютного дилинга и казначейства фирмы Financial Software Systems (FSS), которая охватывает процессы фронт- и бэк-офиса.

Вначале Opics (The Frustum Group, USA) задумывался как бэк-офисная система казначейства, однако вскоре разработчики сочли необходимым добавить и функции автоматизации фронт-офиса.

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

В 1995 г. были добавлены поддержка репо и обыкновенных акций. На уровне фронт-офиса появились возможность ввода сделок и моделирование прибылей и убытков «Что, если». Кроме того, был обеспечен онлайновый интерфейс с Microsoft Office с помощью механизмов DDE. В то же время АБС не поддерживала розничных операций, синдицированных кредитов и документарных операций.

Система работала на множестве ПК-ориентированных платформ (Novell, Windows 95, Windows NT, OS/2 и Unix). Первые версии Opics использовали СУБД Sybase, но затем были добавлены средства работы с любой СУБД, поддерживающей стандарт ODBC.

К 1997 г. АБС была доработана до уровня «универсального решения» для банков, нуждающихся в поддержке как казначейских, так и розничных операций. Несмотря на то что в ряде функций (операции с драгоценными металлами, репо, фьючерсы, опционы, соглашения о форвардной ставке) Opics имеет преимущества даже перед такими общепризнанными лидерами систем банковской автоматизации, как Midas и Equation, розничный сектор имеет слабую функциональность и не способен обрабатывать большие объемы операций.

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

Первая версия АБС Olympic (ERI Bancaire SA, Switzerland) появилась в 1989 г. на платформе AS/400 как результат новой разработки, ориентированной на работу с частными лицами. Первыми рынками сбыта АБС были Швейцария и Люксембург, где Olympic конкурировала в основном с местными разработками, однако вскоре она была функционально расширена и стала конкурентом таких традиционно сильных в казначейском секторе систем, как Midas, IBIS/AS и Globus. Одним из крупных пользователей системы (700 автоматизированных рабочих мест) стала швейцарско-американская Discount Bank & Trust Company.

Olympic разработана для поддержки работы фронт- и бэк-офиса - от приема клиентских распоряжений, включая электронный банкинг, до окончательных расчетов и уведомлений. АБС поддерживает фронт-офис портфельных менеджеров и дилеров, валютный дилинг, межбанковский дилинг, ценные бумаги, свопы, фьючерсы, опционы, добавленные в 1995 г. совместно с кредитным модулем, регистрацию и учет розничных операций, документарные операции (в основном, те функции этих подсистем, которые требуются для выполнения ежедневных операций по частным банковским услугам). Кроме того, имеются интерфейсы к SWIFT и основным клиринговым системам. С точки зрения производителя Olympic - клиент-ориентированная АБС с обновлением позиций в реальном времени.

Хотя две трети банков-пользователей используют АБС именно для обслуживания частных лиц, остальные используют Olympic для поддержки всех направлений бизнеса. BPER (Люксембург), например, помимо всего прочего использует систему для обслуживания более 100 паевых инвестиционных фондов. Banque de Luxemburg использует Olympic для оказания розничных услуг, включая депозиты частных лиц, и инвестиционной деятельности, располагая примерно 500 рабочих мест, подключенных к одному компьютеру AS/400.

Типичный проект по внедрению Olympic занимает от 6 до 9 месяцев. Примерно половину этого времени занимает настройка. Система имеет центральную модель данных и около 200 настраиваемых пользовательских таблиц, которые описывают атрибуты продукта, включая авторизацию, процессы, тарифы, правила учета и отчеты.

В 1995 г. начаты работы по переносу АБС на платформу Windows NT. Система разрабатывается на языке С++ с использованием объектноориентированной технологии и концепции хранилищ данных.

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

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

АБС Symbols (System Access Pte Ltd., Singapore) сингапурской фирмы System Access является одним из самых новых предложений на рынке банковских систем. Впервые система была предложена в 1989 г., и ее первым пользователем стал Credit Suisse First Boston Bank в Сингапуре. Первая версия АБС состояла из учетного ядра и основных функциональных модулей казначейства. Производитель проводил агрессивную маркетинговую политику (от которой не отказался и сейчас), намереваясь «установить Symbols во всех главных финансовых центрах к концу 1993 г.». Первый значительный успех за границами Юго-Восточной Азии пришел в 1991 г. - был подписан контракт на 1,73 млн. долл. с Южноафриканским Standard Merchant Bank. В то время это был крупнейший пользователь Symbols, имеющий 250 рабочих мест, оснащенных терминалами Olivetty, подключенными к серверам Pyramid.

Основной причиной, по которой Standard Merchant Bank выбрал Symbols, была принятая в банке ориентация на продукцию ORACLE. Аналогичная стратегия применялась и в лондонском Standard Bank (по отношению к которому Standard Merchant Bank является дочерним). Standard Bank также оценивал Symbols, когда подбирал систему на базе ORACLE, но в конце концов предпочел АБС Globus фирмы Temenos, в основном из-за неуверенности, что производитель АБС Symbols сможет его эффективно сопровождать в данном регионе, хотя Standard Merchant Bank предлагал оказывать необходимую помощь в вопросах сопровождения АБС. Такая СУБД- ориентированная стратегия становится все более популярной, особенно при необходимости консолидировать данные из разных источников в одном хранилище. ORACLE является очевидным выбором для этого. Одновременно многие банки в Юго-Восточной Азии, Восточной Европе хотели бы иметь систему, базирующуюся на новых технологиях. System Access старается использовать в своей маркетинговой политике оба этих факта.

Ряд контрактов на поставку Symbols были инициированы фирмой ORACLE, например контракт на 2,5 млн. долл. с SKB Banka в Словении в 1995 г. По мере того как ORACLE концентрировал свое внимание на вертикальных рынках, более крупные банки становились потенциальными клиентами System Access. По мере того как System Access все более опиралась на технологии ORACLE, поддержка со стороны производителя СУБД становилась более ощутимой. Другим фактором, сближающим ORACLE и System Access, является попытка ORACLE обеспечить банковскую функциональность в «Главной книге» Oracle Financials. В итоге для Symbols и Oracle Financials были разработаны взаимные интерфейсы, а System Access получила статус партнера. Тем не менее уровень поддержки со стороны ORACLE остается сильно зависимым от конкретной страны: в некоторых странах она оказывает только маркетинговые услуги, в других - принимает участие в проектах по внедрению.

Основная деятельность System Access за границами Юго-Восточного региона осуществляется через дистрибьюторов. Наиболее продуктивным на сегодняшний день является сотрудничество с московской компанией ФОРС. В 1995 г. ФОРС заключил контракты на поставку Symbols в банки «Российский Кредит» и «Зенит». ФОРС выполнил адаптацию АБС к специфическим российским условиям; локализованная версия распространяется под маркой Symbols-R.

Значительным событием является также подписанный в начале 1998 г. контракт с банком «Петровский» в Санкт-Петербурге. Этот контракт стал частью двухлетнего российского проекта Financial Institutions Development Program, на который Международный банк реконструкции и развития выделил 9 млн. долл. ФОРС будет отвечать за внедрение Symbols. Система будет поддерживать ссуды, ценные бумаги, валютный дилинг, межбанковские ссуды, внутрирегиональные и международные платежи, управление активами и пассивами на сети филиалов и головного офиса. Тендер по выбору АБС для банка «Петровский» проводился в течение двух лет и его результат был назван руководителем европейского отделения System Access «удивительным».

System Access позиционирует АБС Symbols как решение для средних объемов операций - минимальная установка поддерживает 12 пользователей. Наличие проблем в инструментальной части и в механизмах доступа к данным производитель компенсирует возможностью приобретения АБС вместе с исходными кодами системы, возлагая тем самым ответственность за исправление ошибок и дальнейшее развитие системы на пользователя. Характерными примерами такого подхода являются банки «Российский кредит» и Staal Bankiers (Нидерланды).

Несмотря на рост числа банков-пользователей, не все происходит гладко. Внедрение Symbols бывает трудным, вплоть до отказа от использования этого продукта.

Как отмечалось ранее, Symbols целиком базируется на ORACLE. Он написан в среде разработки ORACLE и использует генератор отчетов ORACLE для того, чтобы пользователи могли создавать свои специфические отчеты и запросы к базе данных. Система может работать на любой платформе, которую поддерживает эта СУБД - другими словами, на всех платформах, отличных от AS/400. Большей частью система ориентирована на Unix платформы, но была сделана версия для Next и - в 1997 г. - для Windows NT.

АБС построена по модульному принципу. К первой версии были добавлены ссуды, документарные операции и депозиты частных лиц. Графический пользовательский интерфейс планировалось реализовать в середине 1994 г., однако он появился только в 1996 г., когда появились соответствующие возможности среды разработки ORACLE.

Также была задержана поддержка розничных операций. Она планировалась на конец 1993 г., но первая фаза была реализована в середине 1994 г. Сектор розничных банковских услуг сейчас является главной областью, на которой сфокусировано внимание производителя. Первый пилотный проект Symbols, обрабатывающий большие объемы розничных операций, был внедрен во втором полугодии 1996 г. в Mauritius Commercial Bank и International Exchange Bank на Филиппинах. Сейчас Symbols используется для поддержки сети из примерно 200 филиалов.

System Access считает, что сектор розничных банковских услуг более доходен, чем корпоративный. Такая позиция помогает привлечь интерес потенциальных партнеров, таких как ORACLE и поставщики вычислительной техники. Производитель продолжает развивать это направление, добавляя интерфейсы к автоматическим кассам, системам обслуживания пластиковых карт и пр. Было также заявлено о завершении в первом полугодии 1997 г. проекта «Кибер-банкинг», дающего возможность получения розничных банковских услуг через Интернет. Однако в начале 1998 г. этот проект находил- ся в состоянии неопределенности в связи с заявлением производителя, что Symbols не будет иметь собственных средств Интернет-банкинга, а будет взаимодействовать с системами, предлагаемыми третьими фирмами.

Другая планируемая разработка, которая так и не реализовалась - «дилерская комната». Предполагалось, что проект будет завершен к середине 1996 г. и будет включать в себя аналитику, ввод сделок, обработку лимитов и т. д. Рассматривался также проект создания хранилища данных, которое могло бы взаимодействовать как с Symbols, так и с другими АБС, предоставляя средства генерации консолидированной отчетности. Одним из средств усиления функции генерации отчетности была выбрана система поиска данных ORACLE OLAP Express Analiser, к которой был разработан интерфейс из Symbols.

В дальнейших планах производителя - добавление к системе средства интегрированного управления потоками данных с использованием ORACLE InterOffice.

Официальной датой появления системы Globus (Temenos Systems SA, Switzerland) на рынке интегрированных банковских систем считается 1988 г. Однако Globus возник не на пустом месте. Прообразом АБС была корпоративная разработка Citibank, выполненная еще в 1977 г. (АБС Cosmos). Впоследствии система переписывалась по заказу Lloyds Bank. Первая версия Globus работала под управлением операционной системы Pick на компьютерах Рг^є. С технической точки зрения Pick всегда выглядел очень привлекательно, особенно в части функциональности и дружественности пользовательского интерфейса. Тем не менее в банковской среде Pick распространения не получил. Поэтому в 1989 г. был выполнен перенос АБС Globus на платформу Unix, и тем самым существенно расширился спектр оборудования, на котором эта АБС может работать. Следует отметить, что все «метаморфозы» АБС осуществлялись под руководством и при непосредственном участии тех же специалистов, которые начинали разрабатывать АБС еще в Citibank.

GLOBUS был разработан с применением СУБД Universe фирмы VMark Software, что упрощало перенос АБС с одной платформы на другую.

К 1992 г. Globus имел 25 банков-пользователей. Примечательным является контракт с лондонским Standard Bank, подписанный в 1993 г. Информационные технологии Standard Bank ориентированы на ORACLE-технологии, и с этой точки зрения использование АБС на базе СУБД Universe не является идеальным решением. Ключевым аргументом в пользу такого выбора была открытость Universe, позволившая без затруднений организовать обмен данными между АБС Globus и ORACLE-приложениями.

Функциональное развитие АБС GLOBUS осуществляется постоянно путем включения в основной продукт отдельных разработок, выполняемых для конкретных заказчиков. Например, модуль аккредитивов был добавлен в 1992 г. по инициативе Bank Handlowy (Люксембург). В 1995 г. последовали модули синдицированных кредитов и соглашения о форвардной сделке. В 1994 г. Temenos (производитель АБС GLOBUS) купил систему Brokers’ Wonder, автоматизирующую работу с фьючерсами и опционами. Система была предназначена для настольных компьютеров и имела восемь пользователей, среди которых ABN-Amro и Bank Julius Baer (Швейцария). Сначала к этой системе был разработан интерфейс из Globus, а в 1995 г. система была инкорпорирована в Globus как стандартный модуль.

Модуль Global Information Server (GIS) был опробован в лондонском Standard Bank. Этот компонент предоставляет пользователям доступ к внешним источникам данных, а также служит для генерации отчетов из базы Globus посредством SQL-запросов и связи их с такими приложениями, как электронные таблицы и текстовые процессоры. Аналогично были разработаны интерфейсы между АБС Globus и офисным пакетом Uniplex, включающим электронные таблицы, деловой календарь, электронную почту и графику.

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

Рассматривались перспективы переноса АБС с платформы Universe на платформы СУБД ORACLE и Sybase. Однако впоследствии от этих планов отказались в основном из-за того, что VMark Software в течение последних лет существенно переработала СУБД в части интеграции с другими базами данных и механизмов обработки транзакций.

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

В марте 1997 г. была продемонстрирована версия АБС для Windows NT, однако готовый для пилотных испытаний проект, функционально идентичный UNIX-версии, появился только в начале 1998 г.

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

- оплата чеков;

- формирование постоянных распоряжений;

- платежи;

- управление счетами;

- запрос на кредитование;

- запрос курсов валют;

- оценка портфеля.

Кроме этого планируется организовать на Web-сайте производителя страницу для поддержки пользователей.

На российском рынке продвижение и сопровождение системы осуществляет фирма AviComp Services AG, бизнес-партнер разработчика Globus швейцарской фирмы Temenos Systems SA.

Итак, исходя из соображений сложности настройки и последующего сопровождения наиболее предпочтительными для внедрения в российских банках являются следующие АБС:

- Symbols (производитель System Access; поддержку в странах СНГ осуществляет НПФ ФОРС);

- Globus (производитель Temenos; поддержку в странах СНГ осуществляет AviComp).

Эти АБС в полной мере удовлетворяют современным технологическим требованиям и имеют высокие функциональные возможности. Кроме того, из всех систем на Unix-платформе только эти две имеют централизованную поддержку авторизованными организациями на территории СНГ.

Безусловный интерес также представляет АБС Olympic (производитель ERI Bancaire) - наиболее функционально развитая современная банковская система на платформе AS/400. Существенным недостатком, ограничивающим возможность ее внедрения, является отсутствие централизованной поддержки в странах СНГ региональным представителем разработчика. Тем не менее, следует учитывать наличие в России положительного опыта внедрения в одном из крупных коммерческих банков локализованной им зарубежной АБС.

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

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

Дистанционное банковское обслуживание (ДБО) имеет много форм и названий - в английском языке, например, используются термины remote banking, direct banking, home banking, internet banking, on-line banking, phone banking, mobile-banking, WAP-banking, SMS-banking, GSM-banking, TVbanking... Отличаясь в нюансах, перечисленные термины описывают особую область отношений между банком и клиентом - управление счетами на расстоянии по каналам удаленного доступа.

Услуги ДБО простираются от простейших информационных сервисов типа получения информации об остатке на счете до таких сложных форм обслуживания, как получение кредита в режиме удаленного доступа или размещение заявок брокеру на фондовом или валютном рынке. Обслуживание различных сегментов рынка требует от банков использования различных технологий, устройств и каналов доступа. Каналы доступа, т. е. средства коммуникации, которые использует клиент для управления счетами, могут быть самыми разными - банкомат, телефон, сотовый телефон с поддержкой протокола WAP или протокола обмена короткими сообщениями SMS, Интернет, сервис-центр (Call-центр), personal Digital Assistant, электронная почта, факс, специализированные интерфейсы к сервис-провайдерам типа Visa Interactive, Integrion, CheckFree. Банк, предоставляющий своим клиентам полный набор сервисов ДБО, тем самым становится телекоммуникационнофинансовым центром, в который по разным каналам стекаются распоряжения клиентов.

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

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

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

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

Предпосылки ускоренного развития систем ДБО в настоящее время заключаются в следующем:

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

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

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

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

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

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

- Стандартизация. Возникновение и утверждение стандартов в ряде областей облегчает банкам задачу создания интегрированных расширяемых решений.

- Коммодификация.

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

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

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

Во-вторых, это снижение расходов. ДБО позволяет снизить операционные издержки в десятки и сотни раз в результате снижения численности персонала и накладных расходов на управление отделениями. Если стоимость проведения простой банковской операции в отделении составляет (для западного банка) около 1 долл., то стоимость операции через систему ДБО составляет единицы или доли центов.

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

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

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

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

Есть и другой подход, при котором во главу угла ставится минимизация издержек, и с этой целью организуется отдельный «виртуальный» банк, который работает только через Интернет и другие каналы доступа. Получаемую экономию такие банки готовы разделить с клиентами: как правило, они предоставляют клиентам более высокие ставки по вкладам, чем обычные банки. Кроме того, некоторые из виртуальных банков возвращают клиентам часть комиссий за снятие денег в банкоматах, как бы компенсируя отсутствие собственной инфраструктуры. Однако в последнее время в США появились признаки замедления притока клиентов в виртуальные банки на фоне увеличившегося их оттока. Эксперты объясняют это завышенными ожиданиями в части качества сервиса в виртуальных банках, что заставляет клиентов переходить на обслуживание в обычные банки, предоставляющие услуги ДБО. Среди причин называются также низкая оценка надежности виртуальных банков, отсутствие схем гарантирования депозитов и невысокая доходность их функционирования ввиду огромных затрат на рекламу.

Как уже отмечалось, ДБО объективно требует использования автоматизированной банковской системы. Чтобы составить представление о сложности полнофункциональной системы ДБО, мы приводим ниже список требований к функциям такой системы и сервисам, которые должны предоставляться с ее помощью:

- Экстерриториальность и непрерывность работы системы. Клиенту предоставляется возможность управления средствами вне зависимости от его нахождения и времени суток.

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

- Интерактивность обслуживания. Система должна обеспечивать возможность проведения операций в режиме самообслуживания.

- Клиенту должна предоставляться возможность выбора между проведением операций в интерактивном режиме и через оператора.

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

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

- Поддержка основных систем управления персональными финансами (Quicken, Microsoft Money).

- Доступность сервисов по всем каналам и для всех ресурсов 24 часа в сутки 7 дней в неделю.

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

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

- Возможность масштабирования системы по мере увеличения числа клиентов и возрастания потока транзакций.

- Устойчивая работа в периоды пиковых нагрузок.

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

- Модульная архитектура для обеспечения перспектив долговременного развития системы.

- Высокий уровень гарантий целостности и безопасности данных и транзакций.

- Максимальная капитализация на инвестициях, сделанных финансовым институтом в другие (смежные) информационные системы.

- Интеграция с другими информационными системами, используемыми финансовым институтом, с сохранением автономного функционирования и развития этих систем.

- Возможность персонализации сервисов, реализации технологии индивидуального обслуживания.

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

- Поддержка продуктов, присущих обычным автоматизированным банковским системам, депозиты, текущие счета, ссуды и т. п.

- Работа системы ДБО в режиме доступа с рабочих мест операционистов операционных залов банка.

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

Архитектура системы ДБО, удовлетворяющая перечисленным выше требованиям, показана на рисунке.

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

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

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

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

Управление системой ДБО осуществляется с помощью набора автоматизированных рабочих мест с различной функциональностью.

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

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

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

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

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

Участник - Банк, предоставляющий своим клиентам дистанционное банковское обслуживание.

Клиент - Физическое или юридическое лицо, открывшее счет у Участника и являющееся его клиентом.

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

Расчетный Банк - Банк, ведущий счета Участников и выполняющий расчетные функции (на схеме не показан). В частном случае функции Аутсорсера и Расчетного Банка могут быть объединены и находиться в ведении Расчетного Банка.

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

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

Аутсорсер и Расчетный Банк взимают с Участника комиссионные вознаграждения за информационно-техническое и расчетное обслуживание в соответствии со своими тарифами. Участник взимает комиссионные вознаграждения с Клиентов за расчетно-кассовое и дистанционное банковское обслуживание в соответствии со своими тарифами.

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

При использовании банком услуг сторонней компании-аутсорсера банк получает значительные преимущества для обеспечения конкурентных позиций на рынке:

1. Отсутствие существенных затрат на ввод новой услуги.

2. Возможность привлечения массового клиента удобным и современным сервисом.

3. Построение зарплатных схем, основанных на ДБО и карточных продуктах.

4. Получение комиссий за обслуживание, что в настоящее время для банков становится одним из основных источников доходов.

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

6. Привлечение на обслуживание предприятий жилищно

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

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

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

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

Обеспечение безопасности при использовании системы ДБО основано на использовании механизмов контроля доступа и полномочий и включает решение следующих задач:

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

имена пользователей в системе ДБО ограничить цифровыми последовательностями.

- Аутентификация - подтверждение полномочий абонента использовать введенный им идентификатор клиента.

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

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

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

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

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

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

Защищенное локальным паролем физическое устройство, с помощью которого клиент может динамически получать код доступа в систему. Примерами токенов являются такие устройства, как Active Card и Tele I.D. Токен зарегистрирован в системе ДБО на клиента и определенным образом синхронизирован с сервером системы, что позволяет системе определить, что код был действительно получен с помощью токена клиента. Фактически токен является аналогом таблицы переменных кодов, но в отличие от нее защищен локальным паролем. Кроме генерации переменных кодов, токены могут выполнять ряд других функций, например вычислять MAC-код для передаваемых распоряжений, что обеспечивает целостность сообщений. К сожалению, известные авторам токены используют для вычисления MAC-кодов криптографические алгоритмы на симметричных ключах, что не позволяет обеспечить свойство неотрекаемости. Недостатком токенов является и их относительно высокая цена (около 50 долл. для ActivCard и 30 долл. для Tele I.D.), что ограничивает их применение для обслуживания массовой клиентуры.

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

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

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

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

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

Идеальным вариантом следует считать случай, когда спецкарточные счета ведутся в системе ДБО или когда карточная система имеет функционал ДБО.

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

- получение по всем каналам доступа информации об остатке на карт- счете и получение выписок по карточным счетам;

- пополнение карточных счетов путем перевода средств в банк- эмитент либо путем файлового обмена, если карточные счета ведутся в банке, где установлена система;

- переводы средств с карточных счетов на счета в системе ДБО и совершение платежей непосредственно со счетов платежных карт;

- оперативное уведомление держателей карт о проведении операций по ним.

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

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

Мобильный телефон фактически является симбиозом телефона и компьютера и сочетает ряд функций, которые делают его идеальной платформой для развития ДБО:

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

- функции идентификации, аутентификации и цифровой подписи;

- функции ввода и вывода информации на/с экрана, в том числе символьных данных;

- вычислительные функции (благодаря наличию процессора);

- функции хранения информации (благодаря наличию памяти);

- функции загрузки данных «по воздуху» в фоновом режиме на сотовые телефоны в режиме ожидания;

- функции активной передачи данных на сотовый телефон по Push- каналам.

В настоящий момент существует две основные разновидности мобильного банкинга с использованием сотовых телефонов: на базе протокола WAP (Wireless Access Protocol) и на базе протокола SMS (Short Message Service).

В случае WAP-банкинга сотовый телефон играет примерно такую же роль, как компьютер при Интернет-банкинге. На стороне банка устанавливается Веб-сервер, поддерживающий страницы, подготовленные в соответствии с протоколом WML (Wireless Markup Language, протокол разметки страниц, оптимизированный в соответствии с ограничениями мобильной связи). Содержание страниц передается в микробраузер сотового телефона и отображается на дисплее. Ввод данных и их передача в банк производятся, как и в случае Интернета, путем передачи формы. Очевидным преимуществом WAP-банкинга является его удобство для пользователя -- возможность навигации по сайту банка, наглядное представление и удобный ввод информации (в том числе и буквенной).

SMS-банкинг основан на использовании механизма коротких сообщений -- специального канала передачи данных, первоначально использовавшегося операторами сотовой связи для передачи служебной информации. С помощью таких коротких сообщений (длина информационного блока - 140 байтов) на сотовый телефон передается информация банка, например список счетов или выписка по счету, а в банк передаются данные, введенные клиентом. Дополнительные возможности возникают в связи с использованием таких механизмов, как передача данных на телефон, находящийся в режиме ожидания, «по воздуху» (Over the Air, OTA) и посылка сообщений (Push). При помощи OTA банк может, не приглашая клиента в офис, обновлять информацию (например, список операций) на сотовом телефоне с точностью до индивидуального клиента. Механизм Push представляет широкие возможности для построения системы нотификации, для уведомления клиентов о наступлении определенных событий (например, списании средств со счета или достижении установленного клиентом значения котировки ценной бумаги).

Технологии WAP и SMS-банкинга получают дальнейшее развитие при использовании SIM-карточек. Являясь вычислительным устройством с внутренней защищенной памятью, SIM-карточки представляют собой идеальное устройство для хранения ключевой информации и выполнения криптографических вычислений внутри защищенного устройства. Использование SIM- карточек позволяет обеспечить качественно новый уровень финансовой и информационной безопасности. Кроме того, SIM-карточки представляют хорошую платформу для хранения данных клиента (например, персонального списка операций). В сочетании с OTA-загрузкой данных это позволяет обеспечить высокий уровень персонализации услуг ДБО.

Безопасные мобильные приложения могут быть основаны не только на использовании SIM-карточек. Синергетический эффект от совместного использования смарт-карточек, выпущенных банком, и мобильного телефона представляется весьма сильным. Смарт-карточка предоставляет средство безопасного проведения финансовых операций, а мобильный телефон - гибкую и удобную платформу для использования этих сервисов. С этой точки зрения, возможно, наиболее гибкий подход состоит в добавлении к мобильному телефону второго интерфейса для смарт-карточек. Такой подход имеет ряд преимуществ, так как позволяет использовать смарт-карточки третьих производителей без использования SIM-карточки и разделяет функции операторов связи и другие приложения. Использование второго слота (в действительности, стандарт допускает до восьми слотов) является стандартом в мире GSM и позволяет использовать вторую смарт-карточку, например EMV, с помощью сотового телефона. Такая комбинация обеспечивает эффективную реализацию решений, связанных с электронной наличностью типа VisaCash.

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

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

В развитых странах перспектива быстрого распространения мобильного банкинга объясняется объективными факторами:

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

- число мобильных телефонов в настоящий момент превышает проникновение персональных компьютеров;

- проведение операций через мобильный телефон проще, чем через компьютер;

- пользователи мобильного банкинга представляют привлекательный сегмент, поскольку являются в основном молодыми и состоятельными людьми;

- при использовании Push-технологий и механизмов нотификации мобильный банкинг обеспечивает качественно новый уровень контроля состояния счетов со стороны клиента.

Перспективность сотовых телефонов как платформы для развития мобильного банкинга подтверждается анализом динамики роста числа сотовых телефонов. На конец 1999 г. доля населения, пользующегося мобильными телефонами в Европе, составила 40%, а в Финляндии -- и вовсе более 70%. Ожидается, что к 2002 г. доля мобильных телефонов превысит 100%, поскольку многие будут иметь не один телефон.

В завершение данной темы отметим, что развитие технологий мобильного банкинга еще далеко не достигло предельной точки. Изменения в области мобильной связи носят взрывной характер. Продолжается рост скорости передачи данных. С вводом Universal Moblie Telephone Services (UMTS) скорость передачи данных достигнет 144 кбит/с, а к 2005 г. ожидается дальнейший рост до 2 Мбит/с. Увеличение скорости передачи снимает ограничения на объем передаваемых данных и открывает новые возможности для развития. На волне прогресса в области мобильной связи формируется новая модель ведения бизнеса - мобильный бизнес, одной из основных составляющих которого является мобильный банкинг.

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

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

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

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

Одним из условий успешного развития электронной коммерции как B2B, так и B2C является наличие системы расчетов между сторонами. Система расчетов должна:

- поддерживать расчеты в режиме реального времени;

- поддерживаться большим числом участников, в идеале это должен быть национальный стандарт электронных расчетов;

- быть открытой системой и обеспечивать возможность присоединения новых участников;

- характеризоваться приемлемыми стоимостными параметрами как для участников, так и для клиентов;

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

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

Схематично архитектура открытой расчетной системы показана на рисунке.

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

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

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

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

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

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

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

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

Необходим как минимум следующий спектр подсистем ДБО:

- для клиентов банка - юридических лиц, в том числе и для корпоративных VIP-клиентов - «классический» «банк - клиент»;

- для клиентов банка - физических и юридических лиц - «тонкий» Ин- тернет-«банк - клиент»;

- для клиентов банка - физических и юридических лиц - компьютерная телефония, подразумевающая как только информационное (опционально), так и полноценное платежно-расчетное обслуживание;

- для банков-корреспондентов и подразделений банка (филиалов, отделений, дополнительных офисов, обменных пунктов и т. д.) - банковская расчетная система.

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

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

- отдельной подготовки администратора;

- своего собственного интерфейса и механизма привязки к базам учета в банке (например, к АБС или карточной системе);

- особого, непохожего на другие подсистемы ДБО процесса внедрения;

- отличного от других механизма администрирования, протоколирования и аудита.

В связи с этим становится очевидной необходимость использования единой комплексной системы ДБО банка, единожды интегрированной в учетные базы банка - АБС, систему частных вкладов и др.

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

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

Ниже перечислены основные задачи подсистемы «Интернет - Клиент - Банк»:

- проведение различных типов платежных документов клиентов;

- обмен сообщениями произвольного формата;

- получение выписок в различных видах и форматах, а также иной информации из банка;

- организация Интернет-коммерции как самому банку, так и любому его клиенту;

- построение расчетных и клиринговых систем в режиме реального времени;

Отличительные особенности

Для успешного внедрения подсистема «Интернет - Клиент - Банк» обладает следующими двумя основными достоинствами:

- юридическая значимость и абсолютная защищенность документооборота банка с «тонким» браузерным клиентом;

- массовость внедрения, что выражается как в абсолютной простоте инсталляции системы у клиента (максимум инсталляции должен выражаться в нажатии setup.exe), так и в низкой стоимости самой системы и владения ею.

Любая не обладающая этими двумя свойствами система «тонкого» «Интернет - клиент-Банк» обречена либо на провал, либо на перерождение в «классического» «толстого» «банк - клиента», имеющего на компьютере клиента объемное специальное программное обеспечение.

Два вышеприведенных утверждения, являющиеся, по сути, определением «Интернет - клиента - Банк», диктуют и особенности построения системы:

- минимальный объем клиентской части - только система защиты и ключи в объеме одной дискеты;

- использование только стандартного HTTP-протокола;

- использование только стандартных средств криптографии (Excellence, Lan Crypto, Верба-OW и др.). Не используется SSL или иные юридически не значимые в России протоколы. Возможность сертификации ФАПСИ;

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

- минимальный http-трафик «банк - клиента» в сеансе, возможность работы через proxy-сервер;

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

- безусловная простота и массовость внедрения;

- гибкость системы и внесение любых настроек, в том числе редакти- рование/добавление документов;

- привычный и удобный, но в то же время не громоздкий интерфейс.

Юридическая значимость работы с системой «Интернет - Клиент -

Банк»

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

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

- именно для обеспечения юридической значимости договора используются «стандартные», хорошо отработанные системы ЭЦП и шиф- рации (Excellence, Lan-Q-ypto и др.). Обязательна также возможность использования (опционально) СКЗИ, сертифицированных ФАПСИ;

- при подписании договора банк и клиент оформляют акт физической передачи ЭЦП и регистрации ключей, а также передачу одной дискеты с инсталляцией программного обеспечения (эту инсталляцию, впрочем, клиент может «скачать» и с банковского сервера -- в зависимости от того, как составлен договор);

- дальнейшая подпись клиентских документов, а также всего http- трафика от клиента в банк и обратно осуществляется при помощи переданной -- согласно акту -- ЭЦП;

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

Массовость внедрения «Интернет - Клиент - Банк», как было сказано выше, обеспечивается ценой системы и абсолютной простотой начала работы с ней или ее инсталляции.

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

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

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

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

Гибкость и масштабируемость системы обеспечивается использованием широко-распространенных технологий Интернет.

Вопросы по лекции:

1. Поясните необходимость применения автоматизированных банковских систем в деятельности коммерческого банка на современном этапе.

2. Опишите принципы классификации АБС.

3. Охарактеризуйте основные требования, предъявляемые к АБС.

4. Расскажите о задачах обеспечения безопасности информационных систем банка и основных методах их решения.

5. Раскройте понятие дистанционного банковского обслуживания. Кратко охарактеризуйте основные виды ДБО, преимущества и недостатки ДБО с точки зрения банка и клиента.

6. Назовите АБС зарубежного производства, используемые в российских кредитных организациях. Дайте их краткую характеристику.

7. Дайте сравнительную характеристику российских и зарубежных АБС и поясните преимущества и недостатки применения зарубежных АБС в российских банках.

8. Охарактеризуйте наиболее известные АБС российского производства. Какие из них применяются в коммерческих банках, расположенных в нашем регионе?

Список литературы:

1. Тютюнник А.В., Шевелев А.С. Информационные технологии в банке.- М.: Изд. Группа «БДЦ-пресс», 2003.-300 с.

2. Управление деятельностью коммерческого банка: (банковский менеджмент) : учебник / под ред. О. И. Лаврушина. М. : Юрист, 2002.- 310 с.

3. Ramakrishnan R. Database management systems/ McGraw-Hill, 1997.- 149с.

4. Экономическая информатика / Под ред. П.В.Конюховского, Д.Н.Колесова. - Спб.: Питер, 2001.- 210с.

<< | >>
Источник: Неизвестный. КОНСПЕКТ ЛЕКЦИИ ПО ДИСЦИПЛИНЕ «ДЕНЬГИ. КРЕДИТ. БАНКИ». 0000

Еще по теме Тема 7.3. Информационные технологии в банках. Дистанционное обслуживание клиентов:

  1. Тема 1. Введение в информационные технологий в финансовом менеджменте
  2. Тема 6. Особенности использования и перспективы развития информационных технологий в финансовом менеджменте
  3. Современные информационные технологии и конкурентоспособность
  4. Тема 7.3. Информационные технологии в банках. Дистанционное обслуживание клиентов
  5. Что представляют собой информационные технологии
  6. Информационные технологии
  7. 12.3. Новые информационные технологиив АСУДП предприятий
  8. 16.4. Применение информационных технологий при выполнении услуг, сопутствующих аудиту
  9. Информационные технологии в сфере розничной торговли
  10. 37. Кассовые операции банков по обслуживанию клиентов
  11. Тема 7.3. Информационные технологии в банках. Дистанционное обслуживание клиентов
  12. Новые информационные технологии в избирательной системе России
  13. Особенности использования специальных знаний в деятельности сторон и их представителей по делам о правонарушениях в сфере информационных технологий
  14. Современные информационные технологии и их роль в процессе профессиональной подготовки курсантов войск национальной гвардии РФ
- Авторское право - Адвокатура - Административное право - Административный процесс - Антимонопольно-конкурентное право - Арбитражный (хозяйственный) процесс - Аудит - Банковская система - Банковское право - Бизнес - Бухгалтерский учет - Вещное право - Государственное право и управление - Гражданское право и процесс - Денежное обращение, финансы и кредит - Деньги - Дипломатическое и консульское право - Договорное право - Жилищное право - Земельное право - Избирательное право - Инвестиционное право - Информационное право - Исполнительное производство - История государства и права - История политических и правовых учений - Конкурсное право - Конституционное право - Корпоративное право - Криминалистика - Криминология - Маркетинг - Медицинское право - Международное право - Менеджмент - Муниципальное право - Налоговое право - Наследственное право - Нотариат - Обязательственное право - Оперативно-розыскная деятельность - Права человека - Право зарубежных стран - Право социального обеспечения - Правоведение - Правоохранительная деятельность - Предпринимательское право - Семейное право - Страховое право - Судопроизводство - Таможенное право - Теория государства и права - Трудовое право - Уголовно-исполнительное право - Уголовное право - Уголовный процесс - Философия - Финансовое право - Хозяйственное право - Хозяйственный процесс - Экологическое право - Экономика - Ювенальное право - Юридическая деятельность - Юридическая техника - Юридические лица -