Платформа InterBank RS

Полезные материалы
Презентация
Заказать референс
Обратиться в отдел продаж

Обзор продукта

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

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

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

Системы комплекса выполнены в SOA-архитектуре и функционируют на базе промышленных серверов баз данных Oracle Database и серверов приложений, поддерживающих технологию J2EE (IBM WebSphere, Oracle WebLogic и др.), что обеспечивает значительную масштабируемость, высокую производительность и надежность. Благодаря современным методам интеграции InterBank RS органично вписывается в ИТ-инфраструктуру любого банка и легко настраивается для взаимодействия со всем применяемым программным обеспечением: с различными АБС, бэк-офисными приложениями, процессингом, НСИ, НБКИ и другими системами.

Архитектура

схема 2.jpg

InterBank RS — это централизованный программный комплекс, одна копия которого может одновременно «прозрачно» взаимодействовать со многими  автоматизированными банковскими системами (в том числе от разных производителей), установленными в удаленных друг от друга филиалах. Реализация такой возможности значительно облегчает процесс обслуживания, благодаря технологии «единого входа» (Single Sign-on).

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

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

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

Вариант развертывания комплекса InterBank RS

схема 3.jpg

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

Преимущества

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

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

    Использование кластеризации на уровне серверов приложений позволяет, помимо прочего, выполнять обновление ПО без остановки работы всего комплекса путем остановки отдельных серверов кластера в часы планового минимума нагрузок.
Безопасность
  • Безопасность хранения и передачи данных обеспечивается за счет встроенных в систему специальных механизмов системы одноразовых паролей, средств электронно-цифровой подписи (СКЗИ «Агава», «Крипто-Про CSP/TLS», «Сигнал-Ком CSP») разграничение прав на проведение операций, протоколирование всех действий клиентов и сотрудников банка и других, а также за счет защиты канала с помощью протоколов SSL/TLS.
Архитектура
  • Архитектура системы позволяет организовать безопасное взаимодействие между банком и клиентом с использованием защищенного канала обмена данными между ЛВС банка и демилитаризованной зоной (DMZ). При этом возможно использование различных схем развертывания ПО, в том числе с использованием специализированных средств, таких как IBM WebSphere MQ Series или RS-Bridge разработки компании R-Style Softlab
Производительность
  • Высокая производительность обеспечивается разделением слоя представления и слоя бизнес-логики. Процесс, обслуживающий пользовательский интерфейс часто простаивает (ожидает реакции пользователя). Поэтому один и тот же процесс, обрабатывающий бизнес-логику, может обслуживать несколько интерфейсных процессов. Таким образом, без потери количества одновременно обслуживаемых клиентов можно существенно снизить требования к аппаратной части комплекса за счет уменьшения количества процессов, обслуживающих бизнес-логику или, при желании, наоборот, повысить количество одновременно работающих пользователей без существенного увеличения требований к аппаратному обеспечению.

    Также в системе предусмотрена возможность выносить фоновые процессы (то есть те действия, которые не требуют немедленного ответа пользователю) на отдельные серверы приложений, тем самым разгружая серверы приложений, которые отвечают за взаимодействие с пользователем.
Функционирование в режиме 24х7
  • Функционирование в непрерывном режиме предусматривает возможность «горячей замены» функциональности части системы без полной остановки программного комплекса. Например, если необходимо внести изменения в экранную форму или атрибутный состав одного документа, то в момент обновления вся функциональность, не связанная с этими документами, продолжает как и прежде работать и доступна конечному пользователю (например, в процессе обновления внешнего вида экранной формы, предоставляющей список депозитов, работа с платежными документами доступна в полном объеме).
Промышленная (стандартизованная) платформа
  • Единственным языком для создания пользовательских расширений является Java.
    Таким образом, не нужно изучать новые специфические языки программирования. Исключением из этого правила можно считать встроенный в систему ЯОПУС (Язык ОПисания УСловий), который позволяет обращаться к объектам в терминах словарной системы.

    Используются стандартные технологии платформы Java.

    Причин для выбора именно Java в качестве платформы для комплекса много. Вот некоторые из них:

    • Полноценная поддержка многими ведущими производителями ПО, такими как IBM, Oracle.
    • Наличие большого разнообразия готовых серверов приложений начиная от простых Open Source (например, Tomcat) до мощных промышленных J2EE-серверов (IBM WebSphere, Oracle WebLogic и др.)
    • Совместимость с большим количеством программно-аппаратных платформ.
    Программный комплекс может работать под управлением различных серверов приложений, поддерживающих платформу J2EE (в частности, и на бесплатных, таких как Tomcat).

    Основной сервер приложений – Oracle WebLogic, резервный (в принципе можем, но на постоянной основе не поддерживаем) – IBM WebSphere. Для целей отладки при разработке может использоваться Tomcat, но его использование стоит по возможности ограничивать.
Централизация
  • Учитывая, что одной из задач системы является сбор и консолидация данных, то при проектировании и разработке предполагается, что система устанавливается централизованно, как единый инстанс (хотя и с учетом горизонтального масштабирования и георезервирования). При этом может взаимодействовать с разным количеством смежных систем.
Многоканальность
  • Обслуживание клиентов и предоставление функциональности сотрудникам банка осуществляется посредством различных каналов доступа - Интернет-клиент, Фронт-офис, кол-центр, Мобильный банк, SMS- и USSD-банкинг, платежные терминалы и банкоматы и т. д.

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

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

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

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

    • Презентационный слой разрабатывается средствами самой платформы InterBank RS. К таким каналам относятся, например, Интернет-клиент и Фронт-офис. Сюда же можно отнести SMS-банк (прикладной разбор входящих SMS – это презентационная логика для данного канала)
    • Презентационный слой разрабатывается компанией R-Style Softlab как отдельное приложение, взаимодействующее с серверной частью InterBank RS посредством API. К таким каналам следует отнести Мобильный банк.
    • Каналы, для которых презентационный слой лежит вне компетенций компании на текущий момент. Взаимодействие таких приложений с серверной частью InterBank RS происходит через API. К таким каналам относятся, например, банкоматы и платежные терминалы.
Многофилиальность
  • Система позволяет автоматизировать работу многофилиального банка. Причем как в рамках централизованной базы (ЦАБС), так и распределенной (в каждом узле своя БД). Во втором случае система обеспечивает распределенную обработку документов (пересылку документов от узла к узлу, синхронизацию состояний, синхронизацию настроек, НСИ и т. д.)

    Этот принцип действует не только для банковской части, но и для клиентской, причем как для «толстого» клиента, так и для остальных каналов (включая Интернет-клиента).

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

    • Простейший случай – унитарный банк (один узел) и его клиенты
    • Многофилиальный банк с двухуровневой структурой – Головной офис и филиалы, непосредственно подчиненные ему.
    • Группа филиалов, иерархически подчиненных друг другу («дерево»).
МногоБИКовость
  • Система позволяет одному клиенту обслуживаться в разных узлах (в разных банках). Для Интернет-клиента это, в частности, означает возможность работы со всеми филиалами банка через единую точку доступа.

    Кроме того, система позволяет также в инфраструктуре банковской группы (некоторый аналог «частного облака»), где единый инстанс InterBank RS может обслуживать не только несколько филиалов, но и даже несколько банков, каждый из которых может работать на своей собственной АБС, в том числе от разных производителей.
Мультиязычность
  • Система позволяет предоставлять внешний пользовательский интерфейс, а также хранить данные в базе на национальных языках. При этом в рамках одной установленной копии могут поддерживаться одновременно несколько национальных языков. Для перевода системы на национальный язык не требуется обращаться к разработчикам – все необходимые изменения можно выполнить в рамках внедрения системы.

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

    При этом предусмотрены механизмы как синхронного, так и асинхронного обмена данными.

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

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

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

    • очереди сообщений (решения класса MOM – message oriented middleware, например, IBM WebSphere MQ)
    • Web-сервисы
    • API, предоставляемый АБС;
    • путем прямого доступа в СУБД АБС (преимущественно с помощью хранимых процедур);
    • файловый обмен (в формате XML или другом текстовом формате)
    • АБС может функционировать на другой СУБД, нежели комплекс InterBank RS.
    • Универсальные механизмы интеграции используются как для обмена документами между InterBank RS и АБС, так и для репликации между ними нормативно-справочной информации.

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