Java and Browsers vs Online Banking. Banks Fail…

Проблемы с Java и браузерами для интернет банкинга можно достаточно просто объяснить.
При этом ни Java ни браузеры, в этом не виноваты. Java признанный лидер среди языков программирования для банковских, финансовых и прочих enterprise решений. Основные браузеры (Chrome, Firefox, Safari) также выполняют все необходимые стандарты и современные спецификации для работы в WEB.
Проблема лежит в плоскости конкретных Интернет-банкинг решений который банки используют в настоящий момент.

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

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

Один год для программного продукта, это немалый возраст, 10 лет, целая эпоха.
Те технологии которые были доступны тогда, эволюционировали вместе со всем Интернетом (и язык Java и браузеры), и то что было нормальным и “стандартом” для того времени не может нормально существовать в более современном стеке технологий. Вспомним Windows, то ПО что прекрасно работало в Windows XP в следующих версиях (Windows 7, 8, 10) перестало работать и требовало обновления ПО до более новых версий. В Интернет-банкинге все немного сложнее.

Даже сама Oracle, владелец технологии Java перестали официально поддерживать Java Applet (https://habrahabr.ru/company/eset/blog/276087/) о чем заранее предупреждали клиентов и вендоров давая им время на адаптацию.

Каждый Интернет-банкинг подразумевает собой 3 основных компонента:
1. Сore banking. В основном back-end часть которая обеспечивает основные банковские процессы и продукты
2. Кабинеты операторов банка. Графические интерфейсы, бухгалтером, менеджеров, кассиров и тд
3. Кабинеты клиентов банка. Графические интерфейсы клиентов банка, физических и юридических лиц.

Если 1 и 2 это внутренняя кухня банков, и клиентов не особо волнует что происходит внутри, то 3 – это именно то с помощью чего клиент взаимодействует с банком в котором обслуживается.

Лет 20 назад, “клиент-банкинг”, был очень популярен но неудобен. Требовалось устанавливать специальное ПО, чаще всего только под Windows или даже DOS, с файлами ключами и прочими non-User-Friendly функциями. Про графический интерфейс я просто умолчу, это было убого.

Лет 10 назад, для того чтобы избавить клиента об необходимости устанавливать какое либо ПО, начали появляться технологии которые могли позволить загрузить в прямо в браузер клиента банка необходимое ПО и таким образом решить вопрос доступа в банк с любого компьютера и браузера. На то время с этой задачей прекрасно справлялась технология Java Applet. Это программы написанные на языке Java, могли в том числе предоставлять графический интерфейс пользователю, которые каждый раз загружаются и исполняются в среде браузера клиента. Для это браузер должен был поддерживать технологию Java Applet, и все ведущие браузеры того времени поддерживали ее. При этом не всегда Java Applet нормально работал на всех операционных системах. Обычно гарантированно отрабатывалось для Windows Internet Explorer (тот еще глюкодром).

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

Сам по язык Java также развивался и стал предлагать “из коробки” технологии которые позволяют представлять клиенту графический интерфейс пользователя прямо в браузере, но с помощью безопасной HTML разметки – Java Server Faces, Java Server Pages.
Те разработчики которые поддерживали свои продукты для клиентов – плавно мигрировали на выше перечисленные технологии представления данных или вообще перевели клиентские интерфейсы на другие графические фреймворки – Java как back-end это спокойно позволяла сделать.

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

Крупные Европейские банки и прочих развитых стран уже давно идут к модели API банкинга. Который позволяет “прикрутить” к core-banking любой графический интерфейс хоть к браузеру, хоть к мобильному приложению по принципу MVC (Model – View – Controller), где View может быть покрыт API и тогда UI реализовываться на чем угодно.

Каким может быть выход для банков?
Если есть возможность создать слой middleware, который позволит разделить core banking, то появится возможность реализовать нормальный графический интерфейс который будет работать везде.
Да это тоже требует инвестиций, но не таких как обновление всей инфраструктуры ПО на которой работает банк. В инфраструктуре банка это может быть множество ПО от разных вендоров – базы данных, карточные процессоры, бакноматные сети и тд. Очень затратно переделывать все сразу. Но можно начать с middleware как промежуточное решение, которое после миграции на новый core banking останется независимой компонентой которая по прежнему может обслуживать внешний UI, который просто не будет “знать” о том что core banking обновился.

В настоящий момент разработчикам доступна масса новых фремворков которые позволят решить эту задачу малой кровью. Не ради рекламы но просто ради информации, существует ряд вендоров которые за вменяемый бюджет могут решить эту задачу.
Например ca.com или wso2.com которые больше ориентированы на крупных игроков и стоят соответственно. Для небольших банков задачу могут решить такие проекты как https://openbankproject.com/, http://www.cyclos.org/, http://canopus.ru/ которые ориентированы на core banking. В качестве middleware слоя могу назвать наших коллег из http://kontomatik.com/, ну и само собой наш продукт SDK.finance, который при этом полностью PSD2 compliant.

Цена вопроса начинается от 20 000 $ и дальше в зависимости от запущенности ситуации со стороны банка.
По времени вполне реально уложиться в 3-6 месяцев для того чтобы выдать наружу API к которым можно «прикрутить» любой модный UI движок.