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

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

1. Обеспечение максимальной надежности

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

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

2. Обеспечение "прозрачного" выполнения всех корректных банковских операций

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

3. Совместная работа валютного и рублевого управлений банка

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

4. Связь с филиалами

Сейчас в России имеется много банков, обладающих обширной сетью филиалов. Филиалам необходимо обмениваться информацией. Современные банки вынуждены идти навстречу клиенту и ускорять прохождение информации из филиала в филиал. Кроме того, жизнь требует усиливать контроль за деятельностью филиалов со стороны центрального отделения для постоянной корректировки финансовой политики банка в целом. Все это вызывает необходимость в непрерывной (on-line) связи между филиалами для мгновенного прохождения сумм и для контроля базы данных филиала. В идеале в каждом регионе у банка должна быть единая база данных для всех филиалов этого региона, и базы данных различных регионов должны быть связаны между собой (и очень желательно в режиме on-line). По мнению автора, при использовании программных комплексов, имеющихся на отечественном рынке банковских приложений, возможность построения такой банковской сети представляется чистой утопией. Единственным реальным средством собрать такую структуру и обеспечить ее функционирование является монитор транзакций или аналогичное программное обеспечение промежуточного слоя (middleware). При этом сама по себе проблема скоростной связи, например, в Москве, где, по разным оценкам, "крутится" от 60% до 70% российских денег, практически решена силами таких фирм, как "Голден Лайн", "Макомнет" и др. Тем более досадно, что ни одна известная автору отечественная банковская система не в состоянии использовать возможности, предоставляемые современной технологией связи. Уходящее поколение банковских систем просто создавалось в расчете на иные экономические и технические условия эксплуатации. И решения, заложенные в эти программные комплексы, не дают им вобрать в себя новые подходы к межфилиальному взаимодействию.

5. Открытость алгоритмов обработки данных

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

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

6. Безопасность и контроль прав доступа

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

Отдельным вопросом является защита от программиста-злоумышленника. В банке, распределенном по различным территориям и работающем в единой базе данных, среди работников могут оказаться разные люди. Выпускник ВМК МГУ или МФТИ, работающий операционистом в банке, теперь обычное явление. Принципиальным является требование невозможности создания злоумышленником программы на рабочем месте, получающей доступ к базе данных. Весь контроль обязан происходить в серверной части комплекса, и ни один пользователь не должен иметь прямого доступа к серверу или базе данных. Программист-злоумышленник, создавший программу для взлома системы, не должен иметь возможности доступа к информации без знания пользовательских паролей. Необходимо было также предусмотреть возможность установки стандартного программного обеспечения (например SunScreen фирмы Sun Microsystems), защищающего сеть от диверсий на уровне сетевых протоколов - от прослушивания сети и от попыток получить несанкционированный доступ под видом другого пользователя или даже драйвера. Эта проблема возникает в связи с тем, что финансовые центры все чаще становятся участниками всемирной сети Internet, что имеет и некоторые негативные последствия для них, а именно - возникновение вероятности проникновения злоумышленников в корпоративную сеть. Для борьбы со злоумышленниками используются возможности систем защиты корпоративных сетей.