Банк теряет деньги не там, где медленно считает отчёты, а там, где мошенник успевает вывести средства на дроп-счёт быстрее, чем сработает проверка. Пакетная сверка раз в сутки обнаруживает фрод, когда деньги уже ушли. Потоковая обработка на Apache Kafka меняет арифметику: транзакция и события счёта анализируются в момент возникновения, а не через часы. Ниже — открытый разбор того, что на этом инструменте делают банки публично. Это не кейс KT.Team, а обзор практик со ссылками на источники.
Какой бизнес-результат получает банк
Главный результат — окно реакции сжимается с часов до миллисекунд и секунд. Krungsri (Bank of Ayudhya), один из крупнейших банков Таиланда, на потоковой архитектуре Apache Kafka детектирует и блокирует мошеннические операции менее чем за 60 секунд — именно в том окне, в которое скамеры обычно успевают увести деньги на mule-счёт (Kai Waehner). Confluent в разборе антифрод-сценариев приводит EVO Banco, который при переходе на real-time-потоки снизил еженедельные потери от фрода на 99% (Confluent).
Второй результат — управляемая стоимость и скорость доставки. У Krungsri офлоад данных с мейнфрейма через Kafka снизил нагрузку (и счёт) на core-banking, а время вывода проекта в прод сократилось с 4–6 месяцев до 6–8 недель за счёт переиспользования одной потоковой шины вместо точечных интеграций (Kai Waehner).
Почему именно потоковая модель, а не «быстрее гонять батч»
Антифрод — это не «один платёж против правила». Это последовательность: инициирование операции, расчёт риск-скоринга, вызов SCA-челленджа, списание. SoftwareMill описывает, как в Kafka каждый такой шаг становится отдельным инспектируемым событием — `TransactionInitiated`, `RiskScoreCalculated`, `SCAChallengeTriggered`, `TransactionSettled` (SoftwareMill). Модель потребляет эти события на лету, а не ждёт ночного среза. Confluent формулирует это как анализ «миллисекунда за миллисекундой» при способности держать миллиарды событий в сутки без потери скорости (Confluent).
Replay: тот же поток работает на аудит
Ключевое свойство Kafka для финансов — это append-only-лог: события хранятся упорядоченной последовательностью с точными таймстемпами и удерживаются настраиваемый срок. Это даёт реконструкцию состояния счёта на любой момент в прошлом, даже если текущее состояние уже изменилось (SoftwareMill). Для банка это два процесса по цене одного: тот же неизменяемый журнал, на котором работает антифрод, отвечает на вопросы регулятора и разбор спорных операций — почему транзакция была одобрена, какие фрод-сигналы оценивались, в каком состоянии был клиент в тот момент.
Replay даёт ещё одно практическое следствие: после сбоя или отставания потребитель «догоняет» лог без потери данных, а новую версию антифрод-модели можно проверить, перепрогнав её по историческому потоку реальных событий перед выкаткой в прод.
Типовая архитектура из публичных внедрений
Картина повторяется у разных банков. Источник истины — core banking и карточный процессинг; из них события снимаются через Change Data Capture (у Krungsri это IBM CDC) и публикуются в Kafka. Поверх — потоковая обработка (Kafka Streams / ksqlDB / Apache Flink): обогащение, агрегация по окну, вызов ML-модели скоринга. Решение о блокировке или челлендже возвращается в операционный контур за секунды. Krungsri при этом работает в гибриде: on-prem core плюс облачные ML-модели и мобильные приложения, и архитектура удовлетворяет требованиям Банка Таиланда по безопасности и приватности данных (Kai Waehner).
На что смотреть при проектировании
- Минимальная модификация ядра. CDC снимает события рядом с core banking, не переписывая его. Бизнес-логика антифрода живёт в отдельных потоковых сервисах, а не в монолите процессинга — это и есть слабая связанность и отчуждаемость.
- Exactly-once и порядок. Для денежных событий критичны идемпотентность и сохранение порядка в рамках ключа (счёта), иначе двойное списание или гонка состояний.
- Retention под аудит. Срок хранения лога и compaction задаются под регуляторные требования; на Confluent Platform добавляются Audit Logs и RBAC (SoftwareMill).
- PII в потоке. Маскирование и контроль чувствительных полей до того, как они уйдут потребителям.
Вывод по бизнес-процессу
Меняется сам процесс контроля операций: вместо «ночь → сверка → расследование постфактум» — «событие → скоринг в потоке → блокировка или челлендж в том же окне, пока деньги не ушли». Один append-only-лог обслуживает оба контура: оперативный антифрод за миллисекунды и доказуемый аудит через replay. Это сокращает прямые потери от фрода и одновременно снимает отдельную нагрузку на подготовку данных для регулятора — без отдельной аудиторской подсистемы.
Схема (текстом)
Core banking + карточный процессинг → CDC → топики Kafka (события счетов и транзакций, append-only). От топиков две ветви из одного лога: (1) поток в реальном времени → обработка (Streams/Flink/ksqlDB) → ML-скоринг → решение «block / SCA-challenge» обратно в операционный контур за секунды; (2) тот же лог с настроенным retention → replay → аудит, разбор споров, валидация новой модели на исторических событиях.
