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

ИАСБП обеспечивает реализацию следующих функций :

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

2. Структура системы

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

В состав программных средств ИАСБП входят:

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

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

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

• режим "ФИНАНСОВАЯ СЛУЖБА";
• режим "СЕРВЕР ИАСБП";
• режим "СИСТЕМА КОНФИГУРАЦИИ/БЕЗОПАСНОСТИ".

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

2.2.4. Комплекс программ обслуживания базы данных
Комплекс программ обслуживания базы данных предоставляет следующие возможности:

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

2.2.5. Комплекс программ обслуживания операций с применением пластиковых карт с магнитной полосой
Комплекс программ обслуживания базы данных предоставляет следующие возможности:

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

2.2.6. Взаимодействие составных частей системы
Взаимодействие между составными частями, функционирующими на разных ЭВМ системы, осуществляется посредством сетевой операционной системы. Взаимодействие построено в соответствии с архитектурой клиент-сервер, обеспечивающей максимальное использование возможностей оборудования, высокую защищенность данных, сравнительно низкие требования к скорости передачи данных по каналам связи. Архитектура клиент-сервер подразумевает наличие в системе выделенного центра, осуществляющего обработку информации - "сервера" и множества узлов, генерирующих запросы на сервер и обрабатывающих результаты их выполнения - "клиентов".
База данных, содержащая всю информацию о всех объектах, хранится только на сервере и доступна только ему. Иными словами, база данных не разделяется в сети и модификация файлов базы происходит только под управлением процесса сервера. "Клиенты", которыми являются рабочие станции, взаимодействуют с сервером только при помощи запросов, которые передаются по сети на сервер, обрабатываются им, при необходимости модифицируя базу данных, а результаты возвращаются на рабочую станцию в виде откликов, которые интерпретируются процессами рабочих станций.
Подготовка системы к работе осуществляется лицом, получившим доступ на данные действия с уровнем полномочий не ниже старшего по смене или службой финансовой безопасности.
В рабочем режиме ИАСБП при запуске автоматически предлагает пользователям процесс "Главный диспетчер системы" как на банковских серверах, так и на всех рабочих местах операторов, службы безопасности и т.д.

3. Архитектура системы

Все компоненты программного обеспечения системы функционируют под управлением операционной системы MS-DOS, рекомендуется версия не ниже 5.0. Система поставляется в виде готовых выполняемых (.EXE) модулей, каждый из которых является функционально законченной задачей. Кроме того использован развитый механизм пакетных (.BAT) файлов автоматически выполняющих все необходимые действий при загрузке задач, архивированию и восстановлению базы данных и.т.д. Следует также помнить что большинство задач в системе используют программные оверлеи (т.е загружаются в память по частям по мере необходимости) поэтому для предотвращения потерь времени на обмен с диском необходимо предоставить свободную Ex- panded или Extended память, которая используется для временного хранения фрагментов программы выгруженных из оперативной памяти. Система также предъявляет значительные требования по свободной оперативной памяти поэтому не рекомендуется использовать большое количество резидентных программ. Более подробную информацию по этому вопросу можно прочитать в разделе касающемся конфигурации операционной системы
Все задачи входящие в систему написаны на языке "C" в рамках стандарта ANSI, в качестве компилятора использован BORLANDC++ версии 2.0 . В качестве библиотеки обеспечивающей поддержку файлов базы данных использована библиотека PARADOX ENGINE 2.0. Все программное обеспечение использует мощные инструментальные средства оригинальной разработки, организованные в виде иерархической системы библиотек, что обеспечивает высокую переносимость системы. В системе используется порядка 200 модулей, общий объем исходных текстов которых для версии 3.16 составляет около 7.5 Мегабайт. Благодаря использованию библиотеки PARADOX ENGINE файлы баз данных совместимы с системой PARADOX 3.5 что позволяет использовать ее для целей сопровождения программного обеспечения.
Взаимодействие между составными частями системы организовано с использованием низкоуровневого сетевого интерфейса обмена данными NetBIOS или IPX, который представляет собой протокол равноправного межмашинного взаимодействия, основанный на концепции виртуальной связи между компьютерами в сети, а точнее - между двумя программами (или их ветвями), выполняющимися как на разных, так и на одном компьютере сети. Протокол сетевого взаимодействия реализован драйверами собственной разработки оптимизированными с точки зрения стоимость/производительность/надежность, исходя из критерия независимости от сетевой высокоуровневой среды (нет необходимости использовать сетевую операционную систему), минимально необходимым размером кадра сетевых пакетов и на несколько доработанном отказоустойчивом распределенном алгоритме "ARQ на шаг назад", обеспечивающем надежную связь.

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

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

3.2.2. Кадры в сети
В процессе сетевого взаимодействия компьютеры в сети обмениваются информацией, которая оформляется в виде "кадров" - неделимых порций данных передаваемых от одного абонента сети к другому.
Кадры запросов
Запрос представляет кадр данных передаваемый от рабочей станции на сервер для обработки. В запросе присутствует как информация о функциональном назначении данных (код функции) так и сами данные (аргументы) необходимые для его обработки.
Кадры откликов
Отклик представляет кадр данных передаваемый от сервера на рабочую станцию и содержащий результат обработки запроса.
Служебная информация в кадрах
Как запросы так и отклики содержат служебную информацию необходимую для организации отказоустойчивого взаимодействия при помехах в сети.
Размеры кадров
Средний размер кадра для запроса в системе составляет около 800 байт, средний размер кадра отклика в системе составляет около 1200 байт, Максимальный размер кадра составляет 4096 байт.

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

3.2.4. Транзакции в системе
Процесс отсылки запроса рабочей станцией, обработки его сервером и приема отклика рабочей станцией является неделимым минимальным актом неделимым взаимодействия в системе и называется в дальнейшем "транзакция" (TRANSACTION).
Транзакция на рабочей станции
Отсылка запроса инициирует начало транзакции , с этого момента рабочая станция начинает процесс взаимодействия с сервером. В нижней строке экрана (строке помощи) появляется сообщение о том что идет транзакция, и информация о том какими клавишами инициируется повторная передача, обрыв транзакции открытие/закрытие окна состояния линии. В окне состояния линии отображается текущее состояние линии передачи данных и фиксируются все происходящие во время транзакции события. Если пользователь пытается оборвать транзакцию то система предварительно выдаст запрос на подтверждение/отмену обрыва. По завершении транзакции исчезают с экрана сообщение и окно состояния если оно присутствовало.
Процесс доставки кадра запроса на сервер
Доставленный на сервер кадр данных помещается во входную очередь где он ожидает обработки его программным обеспечением. Этот процесс протекает не зависимо от того занят сервер обработкой в данный момент какого-либо запроса или нет. Это позволяет пользователям работать независимо друг от друга.
Очередь организована в оперативной памяти и, естественно, имеет ограниченный размер (10K), который вполне достаточен для хранения нескольких кадров. Если очередь все-таки не может поместить кадр то он отвергается (теряется) что не является нештатной ситуацией так как сетевое программное обеспечение построено по отказоустойчивому алгоритму и данная ситуация исправляется при помощи повтора посылки кадра в процессе транзакции средствами рабочей станции. Это касается также случая когда из-за помех в сети кадр не доставляется до сервера (теряется в сети).
Следует помнить что начатая транзакция не считается завершенной до тех пор пока на рабочую станцию не поступит отклик от сервера. Разумеется, транзакцию можно принудительно прекратить ("оборвать") но в этом случае нет гарантий того что запрос обработан (или не обработан) сервером. Это касается также логических ошибок обработки транзакции (не нормальное завершение транзакции по программным причинам) о чем система выдаст сообщение с указанием кода ошибки, ситуаций потери электропитания на рабочей станции во время транзакции, аварийной остановки программного обеспечения системой самодиагностики.
После этого необходимо проверить при помощи анализа состояний объектов на которые должен был оказать влияние запрос был ли он обработан или нет, как правило это тоже не вызывает затруднений. Впрочем, как показывает практика, такие события крайне редки.
Прием кадров сервером
Программное обеспечение сервера обрабатывает запросы извлекая их из входной очереди по принципу "раньше пришел - раньше обслужился".
Сеансы на сервере
В процессе обработки запроса сервер располагает информацией как о пославшей его стации ("Адрес" - имя станции отправителя) так и о состоянии программного обеспечения, которое генерирует запросы от имени данной рабочей станции ("Информация о сеансе").
Сеансы на рабочей станции
Информация о сеансах поддерживается при помощи механизма регистрации/отрегис-трации рабочих станций которая протекает при помощи служебных запросов. Каждая задача запускаемая на рабочей станции имеет главное меню сети в которое появляется сразу после загрузки. Выбрав пункт "Регистрация" пользователь инициирует процесс установления сеанса с сервером. После прекращения работы пользователь должен вернутся в главное меню, что вызовет отрегистрацию машины. Таким образом если задача на рабочей станции находится в главном меню она еще (или уже) не подключена к серверу.
Входной контроль кадров сервером
Пришедший по сети кадр подвергается проверке на соответствие его стандартному формату. Если формат кадра не соответствует принятому для запроса, то он отвергается без обработки с выдачей предупреждающего сообщения.
Почтовая (синтаксическая) обработка кадра
Если формат кадра соблюдается происходит проверка согласно несколько доработанному отказоустойчивому распределенному алгоритму "ARQ на шаг назад", обеспечивающему надежную связь. Этот этап называется почтовой (синтаксической) обработкой. В случае каких-либо ошибок или несоответствий дальнейшая обработка запроса не производится, а на рабочую станцию отсылается отклик уведомляющий ее об одной из ошибок почты как о причине отказа. 3.2.4.8 Смысловая (семантическая) обработка кадра
В дальнейшем кадр проходит этап смысловой (семантической) обработки при котором программное обеспечение сервера производит обработку данных поступившего запроса. В случае противопоказаний , противоречивости , недопустимости данных или отсутствия необходимых полномочий и.т.д присылается сообщение о том, что запрос отвергнут (обработан не успешно) и по каким причинам.
Отсылка кадра отклика на рабочую станцию
Полученные в результате обработки отклики помещаются в выходную очередь (очередь доставки) и отсылаются по принципу "раньше обработан - раньше отослан". Если очередь переполнена или отклик потерян из-за помех в сети то исправить это можно повторив посылку запроса на рабочей станции во время транзакции.

3.2.5. Транзакции в режиме дублирования
В конфигурации когда работа сервера дублируется ("Сдвоенный сервер") работа комплекса несколько отличается от описанной выше. При этом в качестве центра сети используются две машины , которые работают в режиме горячего резервирования. Каждая машина в отдельности ведет свою собственную независимую копию базы данных, что обеспечивает дублирование информации. Но в системе дублируется не только файлы базы данных но процессы выполнения запросов т.е. и программное обеспечение. Система построена так что для рабочих станций безразлично дублируется работа центра или нет, так как запросы посылаются всегда одному и тому же абоненту сети. Этот сервер называется ведущим сервером ("главным" сервером). Ведущий сервер организует входную и выходную очереди так как только он принимает и отсылает отклики на рабочие станции. Благодаря этому рабочие станции взаимодействуют всегда только с одним абонентом сети - узлом с именем "BANKSERV". В режиме "одиночного сервера" это и есть собственно сервер, в режиме дублирования это есть ведущий "главный" сервер центра. Ведомый сервер взаимодействует только с ведущим сервером при помощи локальной сети посредством служебных кадров и имеет имя узла "BANKSLAV". Эти имена недопустимо использовать для рабочих станций. В случае неправильного использования зарезервированных имен система выдаст сообщение об ошибке и старта задачи не произойдет.
Взаимодействие ведущего и ведомого сервера
В режиме дублирования процесс обработки запроса на ведущем сервере происходит так же как и в одиночном режиме за исключением того, что после того как получен отклик он не помещается в выходную очередь сразу после обработки, а только после взаимодействия с ведомым сервером. После обработки запроса главный сервер отсылает кадр содержащий исходный запрос ведомому серверу, который, обработав его, возвращает ведущему серверу свой вариант отклика. Ведущий сервер сличает результаты обработки в случае если они идентичны помещает отклик в выходную очередь для передачи на рабочую станцию.
Устранение сетевых ошибок при взаимодействии серверов
Взаимодействие серверов также организовано по отказоустойчивому алгоритму, поэтому в случае если служебные кадры будут потеряны в процессе взаимодействия необходимо лишь повторить посылку с ведущего сервера на ведомый чтобы восстановить связь, для этого на ведущем сервере предусмотрена такая возможность.
Расхождение результатов обработки
В случае расхождения результатов обработки ведущий сервер выдает предупреждающий звуковой сигнал и сообщение об ошибке. После этого исходный кадр запроса и оба варианта откликов (в шестнадцатеричном виде) автоматически помещаются в специальный текстовый файл "протокола разногласий" с фиксированием даты и времени расхождения. Это теоретически может означать либо повреждение программ одного из серверов, программную ошибку, не идентичность базы данных обоих машин на момент старта. Как показывает практика наиболее часто несовпадение происходит по причине именно не идентичности баз данных на обеих машинах, что указывает на несоблюдение регламента приведения баз в соответствие всякий раз перед запуском задач серверов сети в дублированном режиме.
Разнесение во времени процессов обработки
Таким образом процесс обработки запроса в режиме дублирования ведущим и ведомым серверами не совпадает во времени : сначала запрос полностью обрабатывается ведущим сервером , потом он отсылается ведомому серверу полностью обрабатывается им после чего результат отсылается ведущему серверу который сличает результаты. 3.2.5.6 Состояния серверов
Оба сервера ведут специальные файлы статусов которые показывают текущие состояния машин. В случае нештатных ситуаций в процессе обработки на одой из машин, всегда остается не разрушенная копия базы данных на другой машине. Либо она еще не затронута запросом либо уже корректно модифицированная. Файлы состояний обеих машин помогут определить это при необходимости.
Ускоренная обработка информационных запросов
Для увеличения производительности системы в режиме дублирование применен механизм ускоренной обработки запросов не модифицирующих информацию, а лишь возвращающих ее на рабочую станцию. Эта разновидность информационных запросов называется "запросы только по чтению". Такие запросы обрабатываются только ведущим сервером и отклик на них помещается в выходную очередь минуя процесс обработки на ведомом сервере. Это позволяет обрабатывать такие запросы практически в два раза быстрее так как исключаются этапы взаимодействия и обработки на ведомом сервере.

4. Технические характеристики системы

ИАСБП обладает следующими техническими характеристиками :

• Скорость удаленной транзакции в односерверной реализации - 0.8-1.0 сек в двухсерверной реализации - 1.5-2.5 сек
• Номинальное количество документов в день - 12000
• Гарантированное время безаварийной непрерывной работы при условии бесперебойного электропитания - 16 часов. Восстановление в аварийных ситуациях при условии ежедневного архивирования базы - 100 %

• Региональная и автономная система ТУЛАКАРТ-1;
• Единый процессинговый центр ТУЛАКАРТ-2;

1. Базовый модуль
   Реализует функции ведения депозитных и кредитных договоров физических лиц и предоставляет обширный перечень операций и услуг в наличной и безналичной форме при операциях с финансовой картой. Параметрическая настройка, управление состоянием финансовых и правовых объектов, режим non-stop, производительность в пиковых нагрузках - более 10 финансовых операций в секунду (PENTIUM 90 32Mb), более 200 тысяч финансовых операций в сутки, физическое дублирование серверов банковских приложений, возможность работать в односерверном режиме. Операционная система OS/2 WARP 3.0 (4.0), СУБД ACCSYS 6.0 фирмы Copia International. Транспортный протокол TCP/IP. Операционная система клиента MSDOS 5.0 и выше.
   
2. Центр эмиссии карт
   Реализует ведение баз данных клиентов, карт, выпускает карты, определяет права доступа, реализует функции замены карт, замены ПИН, имеет интерфейс с системами DATA CARD по эмиссии пластиковых карт с магнитной полосой с эмбоссингом.
   
3. Подсистема безопасности
   Реализует функции закрытия финансово значимой информации, авторизацию клиента и клерка, функции несимметричной цифровой подписи и проверки целостности (Совместное использование MD5 и RSA). Ключи несимметричной цифровой подписи генерируются на время существования виртуального socket-канала и на устройствах длительного хранения никогда не присутствуют. Реализует функции развитого администрирования доступа к финансовым процедурам и объектам системы.
   
4. Система поддержки транзакций в торговле и сфере услуг
   Реализует механизм управления терминалами торговых точек, авторизации транзакций и расчетов в ON-LINE при подключении к серверу приложений по выделенным линиям и по коммутируемым линиям связи, используя инкапсуляцию TCP/IP over SLIP over X.25. Возможны другие механизмы сетевого взаимодействия. Поставляется в виде программы монитора для HOST платформы с ограничениями на количество подключений (минимальная поставка - монитор на 25 подключений). Стоимость программного обеспечения для клиентской части учитывается в составе поставляемого терминального оборудования.
   
5. Система поддержки QCD, ATM, финансовых терминалов
   Реализует систему управления QCD, ATM, финансовыми терминалами, авторизацию транзакций и расчетов в ON-LINE при подключении по выделенным линиям и по коммутируемым линиям связи, используя транспортный протокол TCP/IP. Поставляется в виде программы монитора для HOST платформы с ограничениями на количество подключений (минимальная поставка - монитор на 10 подключений). Стоимость программного обеспечения для клиентской части учитывается в составе поставляемого оборудования (QCD, ATM, финансовых терминалов).
   
6. Система ведения архивов
   Реализует двухуровневый (по длительности хранения и частоте доступа) механизм ведения архивов базы данных и операций. В своем составе содержит также информационно-поисковую подсистему истории транзакций физических лиц.
   
7. Система слияния данных с основным отделением
   Подсистема взаимодействия с основным отделением. Пакетный механизм синхронизации аналитического учета связанных финансовых объектов отделения и процессингового центра, обеспечивает ежесуточную сверку и генерацию сводных проводок.
   
8. Коммуникационная подсистема
   Реализована стандартными средствами доступа UNIX систем. Позволяет разделять информационные потоки, маскировать IP адреса, фильтровать пакеты, выделять приоритетные соединения. Количество одновременно обслуживаемых пользователей ограничивается лишь пропускной способностью каналов и ресурсами HOST платформы. Имеется возможность использования всего спектра средств защиты информации и авторизации доступа на транспортном уровне.
   
9. Генератор отчетов и выходных форм
   Состоит из базового набора выходных форм и интерпретатора языка построения выходных форм с синтаксисом языка C.

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

Банк "Тульский Промышленник"
Начальник отдела эксплуатации А.В. Супонин
т. (0872) 33-26-61, факс (0872) 33-26-52
E-mail salex@tprbnk.phtula.mednet.com