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

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

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

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

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

Влияние на ИТ

По требованию клиентов, режим поддержки различных ИТ-компонентов, начиная с систем обслуживания с использованием пластиковых карт, систем класса клиент — банк и заканчивая ставшей совсем уже ночной обработкой завершения операционного дня, стал 24-часовым. Само понятие операционного дня трансформировалось: если еще года три назад платежи принимали с 10 до 13 часов, то теперь повсеместно — с 9 до 17.

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

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

Концепция доменов

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

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

Объединить бизнес в рамках одной «мегасистемы» не удастся. Кто-то раньше, а кто-то позже приходит к концепции доменов — функционально законченных областей, отвечающих за обработку тех или иных операций или за предоставление определенных услуг. Объединение систем неизбежно. В центре деятельности ИТ-службы не разработка отдельных систем и даже не построение интерфейсов, а определение, какие системы и где следует развернуть и как они должны взаимодействовать. Для банковского сектора становится очевидно то, что в мире ERP поняли давно: системы у всех одни и те же (и, как правило, несовершенные). Конкурентное преимущество или проигрыш того или иного банка состоит в том, как они настроены и состыкованы.

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

Например, в обработке транзакции по кредитной карте может быть задействовано до пяти систем.

  1. Карточный "фронт-энд" или "процессинговая" система (которая может быть установлена и у "стороннего" процессора).
  2. Бэк-офисная система для расчетов в рамках международных платежных систем.
  3. АБС или "главная книга".
  4. Кредитная система (система по мониторингу кредитных рисков).
  5. CRM.

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

Вакансия на роль шины

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

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

Концентрация логики интерфейсов

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

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

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

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

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

Как начиналось у нас

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

— Руслан Бондарев, главный специалист отдела системного анализа банка «ИНГ Банк (Евразия)» и Илья Мельников, CIO «ИНГ Банк (Евразия)»

ЗАО «ИНГ Банк (Евразия)» является частью ведущей международной финансовой группы ING, поэтому, мы в своей работе руководствуемся как российским законодательством и требованиями ЦБ РФ, так и международными корпоративными стандартами и «лучшими практиками». Это означает, что в банке применяется два набора систем.

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

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

Было принято решение внедрять промышленное средство интеграции.

Инструмент интеграции

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

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

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

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

Первое решение

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

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

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

Текущее состояние и итоги

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

Благодаря PIE в нашем банке реализованы уникальные продукты для розничного рынка. Внедрена система многоканального электронного банка. Уровень «сквозной обработки» (STP) достигает 97% (при условии обработки каждой транзакции как минимум в двух — локальной и корпоративной — системах).

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

Наиболее ощутимым достижением, по всей видимости, является увеличение количества обрабатываемых транзакций примерно в три раза за два года. При этом численность персонала, задействованного в операциях (включая ИТ), выросла только на 7%!

Уроки

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

Система становится концентрацией ноу-хау банка, а также центром сосредоточения потенциальных проблем (см. врезку «Как выбирать?»).

Немного о будущем

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

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

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

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

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

Илья Мельников — CIO «ИНГ Банк (Евразия)», ilia.melnikov@ingbank.com

Руслан Бондарев — главный специалист отдела системного анализа банка «ИНГ Банк (Евразия)»

На что обратить внимание

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

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

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

Важно выявить наиболее слабое звено в системе, поскольку именно оно будет определять надежность. В нашем случае таким звеном стала одна из подсистем низкоуровневого взаимодействия от «третьего» производителя: она первоначально отказалась работать в распределенном режиме, увеличивая время восстановления всего комплекса до шести часов.

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

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

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

В нашем случае можно подчеркнуть высокую степень повторного использования ключевых компонентов документооборота — так называемых задач, которые используются в узлах UML-процессов и отвечают либо за определенные трансформации документов, либо за выполнение тех или иных процессов сторонними системами. Более 60% используемых компонентов получено в комплекте системы. В течение примерно трех месяцев работы было сформировано еще около 35% задач (у нас они разрабатываются на C++, но можно использовать Visual Basic или другой Win32-совместимый язык).

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

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

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

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

Как выбирать?

Тот, кто выбирает «шину» сейчас, наверняка находится в другой ситуации, чем мы четыре года назад. Во-первых, выросли цены (причем основные затраты приходятся на консалтинг, что умело скрывается менеджерами по продажам на начальных стадиях переговоров). Во-вторых, выбор стал многообразнее — появились представители ведущих поставщиков. В то время когда решение о выборе системы промежуточного слоя принималось в «ИНГ Банке», известный шведский поставщик был единственным, готовым предложить что-то реальное. В-третьих, конкретная ситуация может все-таки требовать «большого скачка».

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

Важнейшим является выбор партнера. Работа с крупнейшим международным поставщиком может быть почетной и выглядит привлекательной с точки зрения разделения рисков (ну какой спрос с CIO, если даже они не могут ничего сделать?), но, скорее всего, обернется мегапроектом с миллионным бюджетом и неоправданно большими затратами на консалтинг. Остановив выбор на отечественном системном интеграторе, вы наверняка столкнетесь с тем, что у него нет опыта внедрения (пилотные проекты не в счет). «Заграничные» консультанты будут стоить неимоверно дорого и предпочтут останавливаться в лучших отелях города за счет вашего банка.

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

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

Во плоти

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

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

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

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

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