Pull to refresh

Comments 23

А можете сказать слова, какие использовались для объяснения бизнесу не искать еще одно коробочное решение, а сделать систему самим?
Отвечая на Ваш вопрос буквально — никакие. В данном проекте не требовалось объяснять бизнесу выбор того или иного варианта технической реализации проекта. Инициатива исходила от ИТ и операционных подразделений, а бизнес на первых порах не проявлял вовлечения в проекте.
В сущности, при реализации любой задачи в ИТ встает вопрос делать VS покупать. Мы всегда прорабатываем возможные варианты с различных аспектов — наличие готовых решений на рынке, стоимость внедрения и владения, гибкость и возможность дальнейшего развития… Перечень достаточно большой и часто формируется под конкретную задачу. А когда все оценено и сведено в таблицу, обычно решение о выборе варианта становится очевидным, даже для бизнеса.
В данном проекте, если рассматривать вариант интеграции существующего процессинга и АБС с помощью сторонней «коробки», предложения на рынке нет. Мы первые и, насколько мне известно — единственные, кто в принципе к данной линейке АБС в режиме Online 24x7 подключил хоть что-нибудь. Поставщик АБС был очень удивлен, узнав что у нас это получилось.
Вы уверены что это надо писать?
Вы описали тут не лучшую реализацию онланй взаимодействия АБС и Процессинга. Ладно бы это была статья из 2010 года, но сейчас же 2017!
Не позорьтесь уберите этот срам!
Теперь понимаешь, почему в одном банке платеж тебе поступает через 1-2 дня, а в другом через час после отправления. И это межбанк юр.лиц, где скорость тоже важна. Видимо, устаревшие системы и миллиардная чистая прибыль банка никак не могут сойтись друг с другом.

Ваш случай достаточно интересен, чтобы понять как там всё устроено. Не одна табличка users_balance и SQL-запросы на обновление :)

Мы постарались свои недостатки обратить в преимущества

Вы выдаете желаемое за действительное. Срамота. Видимо, банк сделал все, чтобы нормальные разрабы от него разбежались
Вы 77 раз упомянули АБС ни разу не сказав, как это расшифровывается? Изумительно!

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

Мы как раз использовали реализацию от Импэксбанка на стороне процессинга, и это нам сэкономило довольно много времени. Коллеги, которые в прошлом делали интеграцию процессинга и АБС Импэкса, серьезно помогли нам с подготовкой ТЗ для модуля NI по работе с ISO-8583 сообщениями. Если говорить про саму АБС, то решение Импекса не подходило по целому ряду критичных показателей, в серьез не рассматривали замену АБС.
за 455,50 рублей продали 7,16 Евро. Неплохо бы понять, заработал банк на такой операции или потерял. По нашим курсам на 14 июня выходит, что 7,16 евро мы продали бы клиенту за 445,35 рублей. Значит, банку повезло и он заработал 10,15 рублей.


Разве не наоборот? В первом случае на счету клиента оказалось 455,50 рублей, во втором оказалось бы меньше — 445,35 рублей, значит банку не повезло и он потерял 10,15 рублей, а клиент заработал их.
Спасибо за Вашу внимательность! Клиенту при авторизации дали на 10,15 рублей РФ больше, чем дали бы при клиринге. Значит, банк потерял, а клиент в выигрыше. В этом участке статьи есть еще одна неточность — банк Евро не продал клиенту, а купил у него. Будем инвертировать логику в статье.
Очень интересная статья, спасибо.
Во всем тексте меня много раз удивляло отношение к АБС как к чему то незыблемому, все огрехи системы надо воспринимать как должное, и даже не пытаться что то сделать с самой системой, лучше и проще построить обвязку, забирающую у системы значительную часть функционала.
Я понимаю, что вопрос, вероятно, покажется поверхностным — но АБС вообще не развивается?
В нашем случае АБС, к сожалению, довольно инертая система в плане развития. Эта интертность вытекает из нескольких источников: устаревшая архитектура самой АБС, достаточно высокий ценник на доработки, сильная связанность с АБС других систем банка. Последний момент означает, что любые изменения в АБС зачастую требуют доработок во многих системах из окружения, как транзакционных, так и отчетных. Этот пункт нас весьма раздражает и в данный момент обсуждаются идеи, как уйти от этой сильной зависимости.
АБС развивается, в первую очередь по тем продуктам, которые «живут» внутри АСБ, то есть по которым проводки формирует сама АБС, а не внешние системы.
Спасибо, aBozhiev, монументальный труд!
Вопрос: что будет с NI, если банк решит заменить АБС (гипотетически)?
Зависит от того, что будет уметь новая АБС. Если в ней будут возможности работы Online 24x7, удобный API по балансам/проводкам/холдам, рассылка событий о движениях по счетам, штатный и гибкий модуль для интеграции с процессингом, то NI отправится на свалку истории.
Гипотетическая миграция на новую АБС будет постепенной, некоторый счета из старой будут мигрированы в новую. На этапе параллельной эксплуатации обеих АБС NI сослужит добрую службу, обеспечив для всех внешних систем прозрачность расчета баланса и создания проводок.
В такой ситуации, вероятно, находятся все старые банки?
К примеру, я знаю всего один банк, который все учетные движения делает при авторизации сумм по картам, а не при клиринге, и это молодой банк (ну особо не слежу, но это подавалось как очень большое достижение).
Теперь вот еще ваш.
Вопрос в том, что Вы понимаете под термином «учетные движения». Если это бухгалтерсике проводки, то мы не делаем все проводки при авторизации. Покупки в торговых точках мы холдим на счетах клиента при авторизации, проводки формируем при клиринге. Это связано с тем, что суммы при авторизации и клиринге по таким операциям могут расходиться очень сильно. По переводам с карты на карту дисциплина крайне высокая, там можно полностью доверять сумме при авторизации, а значит можно делать проводку.
Ну, возьмем пример — гашение кредита (или кредитки). Слышал много раз (и сам сталкивался), что многие считают датой поступления дату клиринга. Даже при внесении денег в банкомате часто дата реального поступления отстает от физической операции. Например, этим грешит один банк с патриотичным названием. У него же я встречал случаи проведения платежей задним числом.
После прочтения этой статьи я понимаю, что ребята, очевидно нагородили костылей вокруг своей системы, что и вызывает подобные казусы.
Так вот, возвращаясь к примеру — такое поведение систем может вызвать невыполнение, с точки зрения банка, обязательств клиента.
Хороший пример. Взносы всегда выжны для клиентов, так как часто они делаются под платеж по кредиту. Поэтому мы делаем проводки по счетам по взносам (либо Cash-In в наш банкомат, либо входящий перевод с чужих карт) в момент авторизации.
Но в любом случае приходится подводить черту между «сегодня» и «завтра». Допустим, у вас сегодня дата планового платежа по потребительскому кредиту в нашем банке. А Вы находитесь в США, и в 19 часов вечера местного времени отправили перевод с американской карты на карту в нашем банке. У вас «сегодня», а у нас «завтра», поэтому мы засчитаем просрочку по платежу в 1 день.
В нашем банке по дебетовым картам черта между «сегодня» и «завтра» проходит в районе 22 часов вечера по Москве.
Достойная позиция, спасибо за ответ. Последний вопрос) А почему 22 часа, почему не полночь? Это тоже объясняется двухчасовым закрытием дня АСБ?
Совершенно верно, это время выбрано из-за продолжительности закрытия дня в АБС. Только оно у нас, к сожалению, занимает более двух часов. Время выбрано с таким расчетом, чтобы АБС успела открыться к началу рабочего дня наших восточных филиалов.
Спасибо за статью, интересный пример. Но часть решений вызывает, конечно вопросы :) Зачем делать новый бэк в данном случае? Почему все таки не процессинг будет мастером по остатку? Почему не поднимать данные из других бэков через какой нибудь кэшовый слой? Зачем в этот же новый бэк запихивать комиссии? Логичней имхо или в единый каталог продуктовый их запихивать, или вести в ИС, которая мастер по договору клиента (если тарифы предполагают индивидуальность).
Зачем делать новый бэк в данном случае? Почему все таки не процессинг будет мастером по остатку?

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

Почему не поднимать данные из других бэков через какой нибудь кэшовый слой?

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

Зачем в этот же новый бэк запихивать комиссии? Логичней имхо или в единый каталог продуктовый их запихивать, или вести в ИС, которая мастер по договору клиента (если тарифы предполагают индивидуальность).

Согласен, логично все комиссии собирать в единое место, там же вести тарифные планы и исключения из них. И у нас такая система есть. Вся сложность в Online 24x7. Довольно небольшой перечень систем по-настоящему могут работать в таком режиме и имеют адекватную поддержку. Наша комиссионная система так не умеет, и затраты на ее доработку в тот момент казались нерациональными. Возможно, в будущем мы это реализуем.
Спасибо за ваши комментарии.
И на первый и на второй вопрос ответ, кмк: OGG + in memory data grid. SLA в 3-4 секунды вполне дозволительный зазор в данном случае. Но да, штука дорогая. Ввод и сопровождение нового in-house бэка в ландшафт в данный момент может казаться дешевле, но на горизонте 3-5 лет ответ останется тем же? :)
Спасибо за интересную дискуссию.
OGG — это Oracle Golden Gate? Довольно дорогая штука, надо признаться. И он тоже может по какой-то причине сломаться и не обновлять данные в кеше, при этом на системе-источнике данные вполне успешно будут писаться. Да и задержка в 3-4 секунды, на мой взгляд — недопустима, мошенники не дремлют.

in memory data grid с заполнением данных на основе CDC (Change Data Capture, к которым в том числе относится и Golden Gate) — отличная штука для кеша в каналах интернет-банка (отображение балансов). Это решение не нагружает системы авторизационного контура, задержка даже в 20 секунд с обновлением там ОК, а в редких случаях падения CDC финансовых последствий не будет. Это был наш планБ на случай, если NI не потянет запрос баланса для интернет-банков в реальном времени. Но нагрузочные тесты и плавный запуск в промышленной среде показали, что с производительностью и нагрузкой проблем нет, так что этот план не понадобился.

Описанное решение работает в промышленной среде на всех клиентов уже несколько лет, и проблем не доставляет. Благодаря простой и надежной архитектуре в нем крайне мало сбоев, и случаев ошибок с расчетом балансов я не припоминаю. Повторюсь, тонкое место в этом решении — производительность, но с ней пока все очень хорошо. Количество вызовов NI API постоянно растет (новые продукты, рост числа транзакций), деградации производительности не наблюдаем.
Sign up to leave a comment.