• Карты, счета, 2 баланса
    0
    Спасибо за интересную дискуссию.
    OGG — это Oracle Golden Gate? Довольно дорогая штука, надо признаться. И он тоже может по какой-то причине сломаться и не обновлять данные в кеше, при этом на системе-источнике данные вполне успешно будут писаться. Да и задержка в 3-4 секунды, на мой взгляд — недопустима, мошенники не дремлют.

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

    Описанное решение работает в промышленной среде на всех клиентов уже несколько лет, и проблем не доставляет. Благодаря простой и надежной архитектуре в нем крайне мало сбоев, и случаев ошибок с расчетом балансов я не припоминаю. Повторюсь, тонкое место в этом решении — производительность, но с ней пока все очень хорошо. Количество вызовов NI API постоянно растет (новые продукты, рост числа транзакций), деградации производительности не наблюдаем.
  • Карты, счета, 2 баланса
    0
    Зачем делать новый бэк в данном случае? Почему все таки не процессинг будет мастером по остатку?

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

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

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

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

    Согласен, логично все комиссии собирать в единое место, там же вести тарифные планы и исключения из них. И у нас такая система есть. Вся сложность в Online 24x7. Довольно небольшой перечень систем по-настоящему могут работать в таком режиме и имеют адекватную поддержку. Наша комиссионная система так не умеет, и затраты на ее доработку в тот момент казались нерациональными. Возможно, в будущем мы это реализуем.
  • Про Agile, Scrum и командную работу. Как устроены процессы развития продуктов в Альфа-Лаборатории
    +1
    Интересует ответ на вопрос «бывает ли такое, что это разные приложения?»
    Ну и интернет-банк и бек-офис — неужели это и правда одно приложение?
  • Про Agile, Scrum и командную работу. Как устроены процессы развития продуктов в Альфа-Лаборатории
    0
    Обычно в банке бизнес-продукт реализуется в нескольких приложениях. Те же депозиты — это фронт, интернет-банк, бек офис. Разработчики и аналитики продуктовой команды способны одинаково эффективно делать доработки во всех системах, реализующих продукт? Специализация по приложениям/технологиями не мешает этому?
  • Про Agile, Scrum и командную работу. Как устроены процессы развития продуктов в Альфа-Лаборатории
    +1
    Составы команд варьируются в зависимости от потребностей создаваемого продукта, но практически всегда это “полный стек”, необходимый для доработки или разработки продукта.


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

    Мы как раз использовали реализацию от Импэксбанка на стороне процессинга, и это нам сэкономило довольно много времени. Коллеги, которые в прошлом делали интеграцию процессинга и АБС Импэкса, серьезно помогли нам с подготовкой ТЗ для модуля NI по работе с ISO-8583 сообщениями. Если говорить про саму АБС, то решение Импекса не подходило по целому ряду критичных показателей, в серьез не рассматривали замену АБС.
  • Карты, счета, 2 баланса
    +2
    Отвечая на Ваш вопрос буквально — никакие. В данном проекте не требовалось объяснять бизнесу выбор того или иного варианта технической реализации проекта. Инициатива исходила от ИТ и операционных подразделений, а бизнес на первых порах не проявлял вовлечения в проекте.
    В сущности, при реализации любой задачи в ИТ встает вопрос делать VS покупать. Мы всегда прорабатываем возможные варианты с различных аспектов — наличие готовых решений на рынке, стоимость внедрения и владения, гибкость и возможность дальнейшего развития… Перечень достаточно большой и часто формируется под конкретную задачу. А когда все оценено и сведено в таблицу, обычно решение о выборе варианта становится очевидным, даже для бизнеса.
    В данном проекте, если рассматривать вариант интеграции существующего процессинга и АБС с помощью сторонней «коробки», предложения на рынке нет. Мы первые и, насколько мне известно — единственные, кто в принципе к данной линейке АБС в режиме Online 24x7 подключил хоть что-нибудь. Поставщик АБС был очень удивлен, узнав что у нас это получилось.