АБС и процессинг – что это и как с этим жить?

Хорошо заметен рост количества финансовых проектов и стартапов. Еще больше на рынке новых идей и фантазий. Некоторые пытаются решить насущные проблемы с помощью своих проектов, а некоторые – поднять венчурный капитал. И тем и другим будет полезно узнать, что же находится внутри банков. Я расскажу очень простыми словами о ключевых системах, с которыми придется интегрироваться и жить. И несколько случаев из жизни.

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

https://t.me/bizarre_ceo – телеграм-канал

Что такое АБС?

Фактически, АБС – это большая база данных. База данных, в которой хранятся все вклады, кредиты, счета и другие банковские сущности.
На стороне этой базы зачастую реализованы стандартные Windows-формы инструментами СУДБ, которыми пользуются девочки-операционисты. Вбиваются много-много данных, нажимают "ОК" – и из принтера вылазит кредитный договор. Или любой другой.

Надо заметить, что раньше эти технологии были на 100% под DOS. Вида Norton Commander, если кто помнит. К слову, не мало банков все еще держат своих операционистов на этих интерфейсах. Работает – не трогай.

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

Подавляющее большинство АБС построено на базе СУБД Oracle. На мой взгляд, этот выбор обусловлен возможностью писать очень неоптимальный код для обработки огромных наборов данных, который в конце концов выполнится. Именно поэтому девочки-операционистки иногда просят вас "подождать минуточку, что-то зависло". В эти моменты АБС выполняет суровую PL/SQL процедуру, которая из сотен тысяч строк выдергивает вашу выписку.

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

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

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

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

Что такое Процессинг?

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

Фактически, процессинг знает о существовании карты, ее бина (номера), принадлежности и доступном лимите. Это основа. Прошла операция – лимит уменьшился или увеличился. Что интересно, по умолчанию АБС об этом ничего не знает. Все актуальные данные о состоянии карт находится именно в ПЦ.

Интересно, что в большинстве случаев процессинг ничего не знает и об овердрафтах. Есть несколько производителей. Некоторые хранят два лимита (остатка) средств, некоторые – один. Высчитывай сам в других системах.

Если банк строит овердрафт – карточки с лимитом, - то все вычисления происходят именно в АБС. И минимум на следующий рабочий день.

Каждое утро ПЦ формирует специальный файл – бинарный формат, эксель или текст, – у каждого своё. И отправляет этот файл в Банк. И опять же, зачастую именно в банк, а не АБС. А вот в банке уже специально обученный специалист загружает этот файл в АБС через интерфейс, по пути разбирая конфликты и проблемы.

Для понимания, когда операция прошла по карте и лимит в процессинге изменился – это холд/авторизация/резервирование средств.
А когда файл с этой операцией поступил в АБС – она становится проведенной по вашему расчетному счету и учтена везде документально и под отчет.

При этом, как вы могли заметить, подотчетным является именно СЧЕТ. Счет, который ведется в АБС. И к этому счету привязана карта.

Делая операцию списания в интернет-банке, платежное поручение (оно же – платежка, перевод) создается на счет. О чем ничего не знает уже процессинг.

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

К слову, все категории в выписке – фастфуд, рестораны, заправки, спа, магазины, – передаются в процессинг как Merchant Category Code. Это 4/8-значные цифры, принадлежащие к конкретной категории. Когда какое-либо заведение заказывает себе (m)POS-терминал для оплаты картами, указывается род деятельности, определяемый этим MCC. И при совершении карточной транзакции этот MCC передается из конкретного POS-терминала в Процессинг. Откуда его уже получает интернет-банк и показывает вам "Ресторан".

Можно вспомнить и о том, что некоторые хорошие продукты ДБО показывают вам название точки. Это тоже берется из POS-терминала и процессинга. У каждой точки есть уникальное название, например "ZAO 7Cont Butirskaya". На основе эвристики, ручной работы или вовлечения клиентов, вы с легкостью можете не только получить базу мерчантов и их популярности с нормальными именами аля "Седьмой Континет на Бутырской", но и обеспечить вовлечение своих пользователей в эту историю через разные варианты игрофикации.

Интеграция с АБС и Процессингом

Существуют различные подходы к этому. Не будем думать об очень грустных, но все еще существующих: например, об обмене файлами, чтобы обновить остатки клиента.

Для АБС 95% случаев – это PL/SQL.
95% для ПЦ – это xml-шлюз.

Надо сказать, что интеграция с АБС гораздо менее предсказуемая. Вы ведь тоже хотите делать классный интерфейс, быстро показывать актуальные данные и вообще строить UX так, как вы его видите? А АБС отдает так, как умеет. И получить от АБС даже 15 процедур (остатки, выписки, получение платежек и т.п.) в том виде, как вы хотите – это совсем не быстрое дело. У вас будут возникать проблемы с форматами, непрогнозируемым изменением типов приходящих полей, что-то может попросту отвалиться и никто не будет знать об этом, пока вы не скажите.

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

Давненько я и не видел удобного дебага PL/SQL-процедур. Порой ты сам ловишь ошибки, сам селектами и процедурами ищешь, что вдруг стало приходить не так. Или не приходить. Это все съедает кучу времени и сил – физических и моральных.

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

Не буду рассказывать про красные лица, раскаленные паяльники. Сдобренное обильно любовью, это было. Самое главное – почему. Один из специалистов, который разбирался в каком-то отдельном модуле АБС, отдыхал на даче. А поправить надо было срочно. Он поправил – и отправил патч своим коллегам. После него все сломалось. Полтора дня искали проблему, пока руками не перенабрали код модуля. Оказалось, как потом выяснили, правки на iPad добавили лишний UTF8-символ, который все ломал. А в АБС-то все в KOI8-R.

К слову о патчах, АБС обновляется именно патчами. Некоторые АБС за один день и успешно. Некоторые – неделю и с частичными остановками. Эти процедуры дико устарели, а про миграции никто не слышал.

Почему же так больно?

Я рассказал лишь о базовых вещах, которые встретятся на пути создания почти любого финтех-проекта. Безусловно, в МФО свои истории – там у каждого своя АБС. От этого не легче.

Помню, в 2011 чтоли году в скайп мне написал Олег Козырев, CTO Рокетбанка. В то время это был просто симпатичный лендинг и смелая идея. С таким удовольствием я рассказывал тогда Олегу все, что знал. Очень хотелось, чтобы Рокетбанк получился и доказал, что такой формат возможен. Что нужно двигаться туда. Потому что в 2011 году я все еще убеждал банкиров задуматься и делать эксперименты в развитии ДБО. Сейчас все немного изменилось, но текущая обстановка не добавляет смелости рукам менеджмента.

Вы также должны помнить, что банк – это управление рисками. Никто не даст вам просто "потыкаться" в АБС для вашего проекта. Для банка это документ, проверка СБ, согласование интеграции, выделение человека на проект. Это проект, экономику и риски которого банк должен понимать. Именно поэтому договориться с банком о партнерстве так сложно. И не меньше преград будет уже в технических вопросах.

Если у вас нет венчурного капитала, вы должны быть быстрыми. Делайте что-то параллельно, чтобы было на что покупать еду. Чтобы банку запустить что-то в коммерческую эксплуатацию, в конце концов нужно выпустить Приказ об этом. Это займет время – будьте готовы. И будьте смелыми, чтобы меняться и менять к лучшему.

https://t.me/bizarre_ceo – телеграм-канал