Объединение банков.
Как эффективно интегрировать системы
Как эффективно интегрировать системы
Георгий Скрипников
Генеральный директор
группы компаний MobilPay
группы компаний MobilPay
Нелегкий выбор интеграции
Объединение банков в стране стало перманентным, как революция у Троцкого. Этот процесс, помимо решения чисто технических вопросов оптимизации ИТ-инфраструктуры, затрагивает и множество налаженных в банках процедур и схем оказания финансовых услуг, организацию работы ИТ-специалистов и бизнеса банка в целом. Гарантом успеха здесь является принятие руководством банка эффективных решений с минимальными рисками временной дезорганизации работы объединяемых банков и потери части их достижений.
Объединение банков в стране стало перманентным, как революция у Троцкого. Этот процесс, помимо решения чисто технических вопросов оптимизации ИТ-инфраструктуры, затрагивает и множество налаженных в банках процедур и схем оказания финансовых услуг, организацию работы ИТ-специалистов и бизнеса банка в целом. Гарантом успеха здесь является принятие руководством банка эффективных решений с минимальными рисками временной дезорганизации работы объединяемых банков и потери части их достижений.
Решение оставить или «выбросить» стабильно работавшую систему всегда означает риск. Есть ли способ его избежать?
Как правило, в банках исторически накапливается достаточно пестрый «зоопарк» систем разнообразных поставщиков, и каждый поставщик по понятным причинам старается доказать, что его система самая лучшая и именно она должна остаться в объединенном банке. Но, как известно, во всем есть свои плюсы и минусы. Потому решение оставить или «выбросить» ту или иную стабильно работавшую систему всегда означает риск потери каких-то плюсов с приобретением минусов. Есть ли способ этого избежать?
Очевидно, что анализируя работающие в объединяемых банках системы, руководство банка прежде всего сравнивает однотипные системы по тому функционалу, который они обеспечивают. Однако объективность оценки в этом случае довольно затруднительна, потому что каждый поставщик стремится доказать функциональную полноту своей системы. Экспертиза в данном случае столь же малоэффективна, поскольку, как всегда, главное скрыто в деталях.
Очевидно, что анализируя работающие в объединяемых банках системы, руководство банка прежде всего сравнивает однотипные системы по тому функционалу, который они обеспечивают. Однако объективность оценки в этом случае довольно затруднительна, потому что каждый поставщик стремится доказать функциональную полноту своей системы. Экспертиза в данном случае столь же малоэффективна, поскольку, как всегда, главное скрыто в деталях.
Процесс должен быть гибким и не одноразовым
Принципиально новый подход к решению вопросов интеграции был предложен и осуществлен компанией MobilPay при объединении банков РНКБ и Крайинвестбанка, Бинбанка и МДМ-банка (вместе с Москомприватбанком и др. банками, входящими в холдинг). А сейчас встал вопрос об интеграции систем объединяющихся банков БФК-Открытие и Бинбанка.
Начну с того, что наша стратегическая концепция любого такого объединения – интеграция систем должна быть процессом гибким и не одноразовым.
Что это значит? И что для этого нужно?
Во-первых, это значит, что развитие комплексной системы банка происходит постоянно, и добавляемые или модернизируемые компоненты/системы должны интегрироваться в общую систему банка в любом случае, а не только при объединениях, давая заметный ожидаемый результат. Во-вторых, при объединении банков задача усложняется только количеством компонент и наличием «похожих» компонент, различных во множестве деталей. Именно это множество деталей, как правило, очень важных для хорошей работы системы, и вызывает основные споры и колебания при принятии решений. Как избежать здесь зависимости от «человеческого фактора», есть ли способ сделать этот процесс объективным?
Прежде всего уместно задать вопрос: кто будет «главным интегратором», т. е. кто готов в конечном счете отвечать за результат работы интегрированной системы? Для этого следует посмотреть функционал мониторинга – если не всей комплексной системы банка, то хотя бы одного из каналов обслуживания клиента. В банке на сегодняшний день их всего четыре: оперкассы, система дистанционного банковского обслуживания через банкоматы и платежные терминалы (ДБО), интернет-банк и мобильные приложения. Канал ДБО в нашем случае самый показательный.
Сейчас в банках наметились попытки выстроить в рамках концепции омниканального обслуживания «единый канал» с целью объединить информацию о клиенте и его услугах, дать клиенту возможность выполнения услуг в различных каналах обслуживания по единым правилам и т. д. Но в такую омни-систему невозможно заложить специфику работы каждого канала со своими устройствами и возможностями. Поэтому первый уровень интеграции комплексной банковской системы выглядит так: сначала омни-сис-тема ведения общих реестров (клиентов, банковских услуг, выполненных операций, условий оказания услуг и т. д.), а далее – четыре канала обслуживания клиентов со своим мониторингом, диагностикой проблемных ситуаций и управлением обслуживания клиентов. И у каждого канала – свои устройства и средства управления, своя интегральная ответственность за все выполненные в канале операции, за обработку сбоев и гарантированную сохранность данных, своя статистика и аналитика операций и т. д. И каждый из этих каналов использует собственные системы управления эксплуатацией входящих в него компонент/систем.
Теперь рассмотрим канал ДБО как самый технически сложный из-за большой степени автоматизации обслуживания клиентов и использования достаточно сложных технических устройств. В работе данного канала – системы ДБО банка – участвуют:
Взаимодействие этих систем с учетом всевозможных сбоев, наличия весьма сложных параметров платежных операций, необходимости считывания ряда исходных данных, полученных от поставщика услуг (например, считывания QR-кода квитанции или полученных от поставщика данных о начислениях и задолженности) – довольно сложный процесс, который должен контролироваться от начала до конца, без тупиковых ситуаций, с автоматической обработкой всех сбойных ситуаций, с обеспечением безопасности и защитой интересов банка и клиента. Кроме того, процесс должен быть удобным, динамичным, легко развиваемым, устойчивым и т. д., и т. п.
Нужно ли говорить, что поставщики ПО для всех компонент/систем ДБО стараются максимально удовлетворить бизнес банка в обеспечении сразу всех этих требований – по мере своих сил и возможностей. Именно в деталях этого обеспечения и кроются трудности в принятии решения: какой системе, какому поставщику ПО отдать предпочтение?
Принципиально новый подход к решению вопросов интеграции был предложен и осуществлен компанией MobilPay при объединении банков РНКБ и Крайинвестбанка, Бинбанка и МДМ-банка (вместе с Москомприватбанком и др. банками, входящими в холдинг). А сейчас встал вопрос об интеграции систем объединяющихся банков БФК-Открытие и Бинбанка.
Начну с того, что наша стратегическая концепция любого такого объединения – интеграция систем должна быть процессом гибким и не одноразовым.
Что это значит? И что для этого нужно?
Во-первых, это значит, что развитие комплексной системы банка происходит постоянно, и добавляемые или модернизируемые компоненты/системы должны интегрироваться в общую систему банка в любом случае, а не только при объединениях, давая заметный ожидаемый результат. Во-вторых, при объединении банков задача усложняется только количеством компонент и наличием «похожих» компонент, различных во множестве деталей. Именно это множество деталей, как правило, очень важных для хорошей работы системы, и вызывает основные споры и колебания при принятии решений. Как избежать здесь зависимости от «человеческого фактора», есть ли способ сделать этот процесс объективным?
Прежде всего уместно задать вопрос: кто будет «главным интегратором», т. е. кто готов в конечном счете отвечать за результат работы интегрированной системы? Для этого следует посмотреть функционал мониторинга – если не всей комплексной системы банка, то хотя бы одного из каналов обслуживания клиента. В банке на сегодняшний день их всего четыре: оперкассы, система дистанционного банковского обслуживания через банкоматы и платежные терминалы (ДБО), интернет-банк и мобильные приложения. Канал ДБО в нашем случае самый показательный.
Сейчас в банках наметились попытки выстроить в рамках концепции омниканального обслуживания «единый канал» с целью объединить информацию о клиенте и его услугах, дать клиенту возможность выполнения услуг в различных каналах обслуживания по единым правилам и т. д. Но в такую омни-систему невозможно заложить специфику работы каждого канала со своими устройствами и возможностями. Поэтому первый уровень интеграции комплексной банковской системы выглядит так: сначала омни-сис-тема ведения общих реестров (клиентов, банковских услуг, выполненных операций, условий оказания услуг и т. д.), а далее – четыре канала обслуживания клиентов со своим мониторингом, диагностикой проблемных ситуаций и управлением обслуживания клиентов. И у каждого канала – свои устройства и средства управления, своя интегральная ответственность за все выполненные в канале операции, за обработку сбоев и гарантированную сохранность данных, своя статистика и аналитика операций и т. д. И каждый из этих каналов использует собственные системы управления эксплуатацией входящих в него компонент/систем.
Теперь рассмотрим канал ДБО как самый технически сложный из-за большой степени автоматизации обслуживания клиентов и использования достаточно сложных технических устройств. В работе данного канала – системы ДБО банка – участвуют:
- Банкоматы и платежные терминалы, депозитарные машины и т. п. (далее – АТМ). Каждый терминал обладает набором специальных, технически сложных устройств от разных производителей оборудования;
- Процессинг обработки карточных операций (своих и «чужих» банковских карт).
- Платежно-интеграционный сервер (хаб), обеспечивающий, в частности, онлайн-платежи;
- АБС банка (главная финансово-бухгалтерская компонента во всех каналах).
- CRM-система работы с банковскими продуктами, клиентами и партнерами банка;
- Вспомогательные системы банка (call-центр, инкассация и др.).
- Биллинговые онлайн-системы провайдеров услуг (таких как Билайн, МТС, Мегафон и др.);
- Биллинговые онлайн-системы агрегаторов платежных услуг (таких как «Элекснет», ФСГ и др.);
- Онлайн- и офлайн-системы прямых поставщиков услуг (ДПУ-услуг), в т. ч. госуслуг и услуг бюджетных организаций;
- Офлайн-системы поставщиков регулярных услуг (университеты, школы, детские сады, фитнес-центры, страховые компании, негосударственные пенсионные фонды и многие другие).
Кроме того, эта система ДБО взаимодействует также с внешними системами, среди которых:
Взаимодействие этих систем с учетом всевозможных сбоев, наличия весьма сложных параметров платежных операций, необходимости считывания ряда исходных данных, полученных от поставщика услуг (например, считывания QR-кода квитанции или полученных от поставщика данных о начислениях и задолженности) – довольно сложный процесс, который должен контролироваться от начала до конца, без тупиковых ситуаций, с автоматической обработкой всех сбойных ситуаций, с обеспечением безопасности и защитой интересов банка и клиента. Кроме того, процесс должен быть удобным, динамичным, легко развиваемым, устойчивым и т. д., и т. п.
Нужно ли говорить, что поставщики ПО для всех компонент/систем ДБО стараются максимально удовлетворить бизнес банка в обеспечении сразу всех этих требований – по мере своих сил и возможностей. Именно в деталях этого обеспечения и кроются трудности в принятии решения: какой системе, какому поставщику ПО отдать предпочтение?
При слиянии банков приходится сравнивать поставленные им компоненты/системы с учетом важных деталей их реализации
Заметим при этом, что поставленные в банк компоненты/системы быстро устаревают, требуется постоянное их развитие: появляются новые устройства (например, АТМ с ресайклингом), новые услуги (например, платежи бюджетным организациям), банкноты и монеты нового образца и карты, новые технологии (например, бесконтактные карточные платежи) и т. д. От поставленных компонент/систем требуется оперативное реагирование и модернизация. Как правило, чем больше поставщик ПО, тем медленнее он реагирует. Иногда поставщик буксует в ожидании новой версии ПО другого поставщика (например, ПО процессинга для АТМ с ресайклингом). Естественно, что при слиянии банков приходится сравнивать различные поставленные в свое время этим банкам компоненты/системы с учетом важных технических деталей их реализации.
На банкоматах и платежных терминалах устанавливается мультивендорное ПО МР-Terminal, объединяющее все функции эмулятора DDC/NDC и агента платежного хаба
Практика – критерий истины
Известно, что практика есть критерий истины. Чтобы «капитально» решить все описанные выше проблемы, мы предлагаем банкам не только теоретически правильный, но и проверенный на практике путь: осуществить стыковку (взаимодействие) ныне работающих в банках систем и затем провести оптимизацию работы ДБО на основе реального опыта работы этой системы и сравнительных оценок, а главное – с сохранением всех ранее накопленных полезных качеств в системах ДБО объединяемых банков. Для этого предпринимаются следующие шаги:
На банкоматах и платежных терминалах устанавливается мультивендорное ПО МР-Terminal, объединяющее все функции эмулятора DDC/NDC и агента платежного хаба, вместе с сертифицированным ядром МР-EMV и компонентой МР-Guard для централизованного контроля и синхронизации ПО, экранов и настроек на удаленных банкоматах и платежных терминалах.
Серверные платежные приложения MobilPay, e-Kassir, AnyWay и т. п. интегрируются и работают параллельно как виртуальные сервера на одном или нескольких серверных компьютерах, сохраняя все свои плюсы и минусы работающих систем в этих банках.
Известно, что практика есть критерий истины. Чтобы «капитально» решить все описанные выше проблемы, мы предлагаем банкам не только теоретически правильный, но и проверенный на практике путь: осуществить стыковку (взаимодействие) ныне работающих в банках систем и затем провести оптимизацию работы ДБО на основе реального опыта работы этой системы и сравнительных оценок, а главное – с сохранением всех ранее накопленных полезных качеств в системах ДБО объединяемых банков. Для этого предпринимаются следующие шаги:
ПО MobilPay обеспечит единый мониторинг, диагностику и автоматизированное управление системой
- Сервер MobilPay обеспечивает общее управление всеми АТМ и интеграцию со всеми другими системами объединенного банка, которые по тем или иным причинам окажутся полезными в общей (комплексной) системе ДБО объединенного банка.
- При этом ПО MobilPay обеспечит единый мониторинг, диагностику и автоматизированное управление системой, включая управление сервисным и инкассационным обслуживанием, управление движением наличности в ДБО объединенного банка, централизованный контроль и обновление ПО на всех банкоматах и терминалах, рабочих станциях операторов ДБО-МР и т. д.
- ПО MobilPay обеспечит также работу омни-системы для интеграции ДБО-МР с другими каналами обслуживания клиентов банка (оперкассы, интернет-банк и мобильные приложения).
На схеме такой интеграции систем в банке розовым цветом выделены компоненты, участвующие в интеграции комплексной системы ДБО банка: АТМ и некоторые серверы ДБО (имеющиеся у банков серверы платежных транзакций и сервер интеграции систем с использованием набора веб-сервисов API).
Такая схема интеграции систем банка обеспечивает минимальные риски принимаемого решения:
Возникает вопрос: могут ли другие поставщики ПО для системы ДБО обеспечить такую же безопасную интеграцию систем с последующей их оптимизацией на основе анализа практической работы комплексной системы?
- В переходный период проведения интеграции продолжают работать все системы банка и услуги клиентам, бухгалтерия и бизнес продолжают работать по наработанным процедурам (договорам, проводкам, сверкам операций и т. д.).
- Одновременно вся система работает под общим мониторингом, диагностикой и автоматизированным управлением эксплуатацией на базе инструментов ПО MobilPay (при этом не отключаются другие инструменты, например, мониторинг Proview и т.п.).
- Далее осуществляется спокойная оптимизация работы системы: настраиваются наиболее эффективные каналы прохождения транзакций в системе, удаляются дублирующие элементы, унифицируются и настраиваются общие параметры услуг (комиссии, диалоги с клиентом и т. п.). Все это делается, опять же, не нарушая полноты и качества клиентского обслуживания.
- В полную силу внедряется омни-система унификации и интеграции ДБО с другими каналами обслуживания клиентов объединенного банка (необходимые веб-сервисы для такой интеграции уже разрабатывались для омни-системы Бинбанка).
Возникает вопрос: могут ли другие поставщики ПО для системы ДБО обеспечить такую же безопасную интеграцию систем с последующей их оптимизацией на основе анализа практической работы комплексной системы?
Сервер MobilPay обеспечивает общее управление всеми АТМ и интеграцию со всеми другими системами объединенного банка
Конечно, не все поставщики ПО смогут обеспечить такие требования банка. Но банк вправе запросить у всех поставщиков ПО для систем ДБО предложение по интеграции с обязательным требованием обеспечить общую конечную ответственность за работу канала ДБО и за сохранение всех достигнутых в объединяемых банках плюсов. И посмотреть результат.
Резюмируя обсуждаемые в данной статье вопросы, можно сказать, что существующие на данный момент предложения ПО для систем ДБО, по крайней мере на примере ПО MobilPay, обеспечивают достаточный уровень возможностей для интеграции и оптимизации системы из поставленных банкам компонент. А предложенный путь реализации процесса интеграции позволяет решить задачу с минимальными рисками и снижением зависимости принимаемых решений от человеческого фактора, а главное – с сохранением всех уже имеющихся достижений в работающих системах ДБО объединяемых банков. Последнее – очень важно для бизнеса банка.
Необходимо подчеркнуть также еще одну важную деталь: ПО MobilPay является полностью отечественным программным обеспечением с регистраций всех лицензионных прав, включая компоненту EMV для работы с чиповыми картами, сертифицированное ПО для банкоматов и терминалов на соблюдение стандартов безопасности PA DSS и процессинговых протоколов NDC/DDC.
Резюмируя обсуждаемые в данной статье вопросы, можно сказать, что существующие на данный момент предложения ПО для систем ДБО, по крайней мере на примере ПО MobilPay, обеспечивают достаточный уровень возможностей для интеграции и оптимизации системы из поставленных банкам компонент. А предложенный путь реализации процесса интеграции позволяет решить задачу с минимальными рисками и снижением зависимости принимаемых решений от человеческого фактора, а главное – с сохранением всех уже имеющихся достижений в работающих системах ДБО объединяемых банков. Последнее – очень важно для бизнеса банка.
Необходимо подчеркнуть также еще одну важную деталь: ПО MobilPay является полностью отечественным программным обеспечением с регистраций всех лицензионных прав, включая компоненту EMV для работы с чиповыми картами, сертифицированное ПО для банкоматов и терминалов на соблюдение стандартов безопасности PA DSS и процессинговых протоколов NDC/DDC.
Вместо послесловия. Три вопроса о ПО
Некоторые общие разумные требования к компонентам системы ДБО, помогающие принять правильные решения, освещены ниже.
1. Какое ПО нужно ставить на АТМ?
Безусловно, оно должно обеспечить работу с процессингом и платежным хабом, а также централизованную удаленную поддержку этого ПО в условиях постоянного развития и усовершенствования. Отсюда – обязательное наличие следующего полного комплекта:
ПО XFS для работы с устройствами АТМ + ПО для работы с процессингом по протоколам DDC/NDC + ПО EMV для работы с чиповыми картами + ПО управления АТМ + ПО управления платежными операциями ДБО + ПО мониторинга и диагностики устройств АТМ + ПО удаленной поддержки и обновления ПО для АТМ.
Устанавливать все эти программы желательно в комплексе, с поддержкой единого поставщика этого банкоматного ПО.
Заметим, что в ряде банков используется разделение банкоматного ПО на агента процессинга (например, эмулятора NDC) и агента платежного хаба (стыкуемого с эмулятором, например, через Web-Exit). Это приводит к последующему «раздвоению» ответственности за наличные и безналичные операции ДБО и к усложнению общих процедур обработки финансовых результатов. Не говоря уже о невозможности обеспечить реальный анализ доступности услуг и их недоступности по конкретным техническим причинам из-за негарантированной доставки сообщений процессингу в рамках протоколов DDC/NDC. Опять же, такой «гибрид» компонент от разных поставщиков делает иллюзорным эффективное динамичное развитие банкоматного ПО, общую ответственность и поддержку ПО в условиях бурного развития устройств на рынке. Пример тому – АТМ с ресайклингом.
2. Какое ПО нужно ставить на платежно-интеграционный сервер (хаб)?
Такое ПО должно обеспечивать не только полный набор платежных услуг (с массой специфических, объективно существующих сложностей и требований бизнеса), но и средства самостоятельного добавления услуг со всеми нюансами, а также автоматическое встраивание добавленных услуг в меню, во все процедуры проводки и сверки операций, в мониторинг и диагностику, в аналитические и статистические отчеты, в специальные отчеты регуляторов (например, отчет ЦБ-260) и т. д. В нем должен быть высокоуровневый дизайнер, позволяющий специалистам бизнеса банка по данному каналу обслуживания клиентов самостоятельно (без программирования) расширять набор услуг ДБО различной сложности.
Такое ПО должно обеспечивать самостоятельное подключение новых онлайн-поставщиков и агрегаторов услуг, других платежных хабов и платежных систем (например, динамически расширяющихся услуг Федеральной системы «Город»). Иными словами, это ПО должно предоставлять инструмент для подключения и настройки реальных шлюзов, шин и внешних систем без программирования. В противном случае это для банка не только деньги, но и время внедрения новых возможностей и дополнительная зависимость от аутсорсинга доработок ПО и сопровождения новаций.
Некоторые общие разумные требования к компонентам системы ДБО, помогающие принять правильные решения, освещены ниже.
1. Какое ПО нужно ставить на АТМ?
Безусловно, оно должно обеспечить работу с процессингом и платежным хабом, а также централизованную удаленную поддержку этого ПО в условиях постоянного развития и усовершенствования. Отсюда – обязательное наличие следующего полного комплекта:
ПО XFS для работы с устройствами АТМ + ПО для работы с процессингом по протоколам DDC/NDC + ПО EMV для работы с чиповыми картами + ПО управления АТМ + ПО управления платежными операциями ДБО + ПО мониторинга и диагностики устройств АТМ + ПО удаленной поддержки и обновления ПО для АТМ.
Устанавливать все эти программы желательно в комплексе, с поддержкой единого поставщика этого банкоматного ПО.
Заметим, что в ряде банков используется разделение банкоматного ПО на агента процессинга (например, эмулятора NDC) и агента платежного хаба (стыкуемого с эмулятором, например, через Web-Exit). Это приводит к последующему «раздвоению» ответственности за наличные и безналичные операции ДБО и к усложнению общих процедур обработки финансовых результатов. Не говоря уже о невозможности обеспечить реальный анализ доступности услуг и их недоступности по конкретным техническим причинам из-за негарантированной доставки сообщений процессингу в рамках протоколов DDC/NDC. Опять же, такой «гибрид» компонент от разных поставщиков делает иллюзорным эффективное динамичное развитие банкоматного ПО, общую ответственность и поддержку ПО в условиях бурного развития устройств на рынке. Пример тому – АТМ с ресайклингом.
2. Какое ПО нужно ставить на платежно-интеграционный сервер (хаб)?
Такое ПО должно обеспечивать не только полный набор платежных услуг (с массой специфических, объективно существующих сложностей и требований бизнеса), но и средства самостоятельного добавления услуг со всеми нюансами, а также автоматическое встраивание добавленных услуг в меню, во все процедуры проводки и сверки операций, в мониторинг и диагностику, в аналитические и статистические отчеты, в специальные отчеты регуляторов (например, отчет ЦБ-260) и т. д. В нем должен быть высокоуровневый дизайнер, позволяющий специалистам бизнеса банка по данному каналу обслуживания клиентов самостоятельно (без программирования) расширять набор услуг ДБО различной сложности.
Такое ПО должно обеспечивать самостоятельное подключение новых онлайн-поставщиков и агрегаторов услуг, других платежных хабов и платежных систем (например, динамически расширяющихся услуг Федеральной системы «Город»). Иными словами, это ПО должно предоставлять инструмент для подключения и настройки реальных шлюзов, шин и внешних систем без программирования. В противном случае это для банка не только деньги, но и время внедрения новых возможностей и дополнительная зависимость от аутсорсинга доработок ПО и сопровождения новаций.
Программное обеспечение MobilPay можно назвать «базовым ПО для интеграции систем ДБО» при объединении банков
Это ПО должно обеспечивать не только оперативный «ручной» мониторинг и диагностику проблемных ситуаций в системе ДБО, но и автоматическую генерацию рутинных инцидентов с автоматизированным процессом оформления сервисных заявок и контролем их выполнения – так называемый инцидент-менеджмент. По существу, стыкуемый с системой сервисной организации и контролирующий выполнение ею SLA-условий сервисного обслуживания АТМ.
ПО должно обеспечивать автоматический сбор, анализ и прогнозирование движения наличных средств в устройствах АТМ и в ДБО в целом (с учетом специфических дней и самообучением прогнозирования), контроль за загрузкой кассет и управление инкассацией (с учетом ресурсов и реальных ситуаций, снижением фондируемой наличности и т .д.).
В конечном счете ПО платежно-интеграционного сервера (хаба) должно обеспечить и ведение единой базы данных по всем событиям и операциям в системе ДБО как для наличных, так и безналичных, и нефинансовых клиентских операций. И еще – 24х7 отказоустойчивость и простую масштабируемость (расширение устройств АТМ).
Возникает вопрос, есть ли хоть одна система ДБО, имеющая такое полноценное ПО? Оказывается, есть, и называется – MobilPay. И это не рекламная акция – приведенный выше набор требований к системе реально работает в ряде банков РФ. В том числе в Бинбанке, РНКБ, ТКБ и др.
Более того, ПО MobilPay обеспечивает варианты «виртуального» объединения банков, когда одна система ДБО обслуживает несколько банков (или филиалов) в режиме коллективного пользования. В этом смысле ПО MobilPay можно было бы назвать «базовым ПО для интеграции систем ДБО» при объединении банков, содержащим необходимый и достаточный набор серверных инструментов интеграции (приведенных на схеме рис.).
ПО должно обеспечивать автоматический сбор, анализ и прогнозирование движения наличных средств в устройствах АТМ и в ДБО в целом (с учетом специфических дней и самообучением прогнозирования), контроль за загрузкой кассет и управление инкассацией (с учетом ресурсов и реальных ситуаций, снижением фондируемой наличности и т .д.).
В конечном счете ПО платежно-интеграционного сервера (хаба) должно обеспечить и ведение единой базы данных по всем событиям и операциям в системе ДБО как для наличных, так и безналичных, и нефинансовых клиентских операций. И еще – 24х7 отказоустойчивость и простую масштабируемость (расширение устройств АТМ).
Возникает вопрос, есть ли хоть одна система ДБО, имеющая такое полноценное ПО? Оказывается, есть, и называется – MobilPay. И это не рекламная акция – приведенный выше набор требований к системе реально работает в ряде банков РФ. В том числе в Бинбанке, РНКБ, ТКБ и др.
Более того, ПО MobilPay обеспечивает варианты «виртуального» объединения банков, когда одна система ДБО обслуживает несколько банков (или филиалов) в режиме коллективного пользования. В этом смысле ПО MobilPay можно было бы назвать «базовым ПО для интеграции систем ДБО» при объединении банков, содержащим необходимый и достаточный набор серверных инструментов интеграции (приведенных на схеме рис.).
ПО MobilPay позволяет настраивать выполнение той или иной платежной услуги через выгодного для банка «посредника»
3. Какое ПО различных поставщиков можно интегрировать с этим «базовым ПО»?
Собственно, любых, например, E-Kassir, ЦФТ, AnyWay и т. п. При этом объединенный банк сохранит все возможности этих платежных хабов, все реализованные и внедренные услуги и качества (параметры, настройки и схемы выполнения) услуг, все их возможности мониторинга и диагностики. Более того, ПО MobilPay позволяет настраивать (оптимизировать) выполнение той или иной платежной услуги через выгодного для банка «посредника» (канал, хаб), гибко перераспределяя пути выполнения операций в системе ДБО. И оставаясь при этом «генеральным ответственным» за все операции ДБО в целом!
Важно подчеркнуть, что ПО MobilPay в принципе способно обеспечить все перечисленные выше «непростые» технические требования к интеграции систем объединяющихся банков.
Собственно, любых, например, E-Kassir, ЦФТ, AnyWay и т. п. При этом объединенный банк сохранит все возможности этих платежных хабов, все реализованные и внедренные услуги и качества (параметры, настройки и схемы выполнения) услуг, все их возможности мониторинга и диагностики. Более того, ПО MobilPay позволяет настраивать (оптимизировать) выполнение той или иной платежной услуги через выгодного для банка «посредника» (канал, хаб), гибко перераспределяя пути выполнения операций в системе ДБО. И оставаясь при этом «генеральным ответственным» за все операции ДБО в целом!
Важно подчеркнуть, что ПО MobilPay в принципе способно обеспечить все перечисленные выше «непростые» технические требования к интеграции систем объединяющихся банков.
Задать вопрос компании