Уровни зрелости архитектуры банка. От Дискет до ИИ

Кому будет интересна эта статья?

Всем кому интересно историческое развитие архитектуры в финтехе и кому интересен наш взгляд как она дальше может развиваться в эпоху применения ИИ во всех сферах нашей жизни. 

Об авторах

Свиридов Александр — Архитектор в ОТП банке, до этого работал в Сбере, ВТБ, Газпроме, более 15 лет в IT. 

Толстихин Сергей — Архитектор в Рольф. До этого — главный архитектор в ОТП банке, так-же работал архитектором в Райфайзен банке и Сбербанке.

Введение

Когда мы с Сергеем обсуждали мою предыдущую статью(Как устроен финтех изнутри), всплыл вопрос: а как вообще понять, насколько банк зрел в плане архитектуры? У Сергея возникла идея привязать этапы развития архитектуры банка в целом именно к развитию интеграционного слоя. Именно он показывает, способен ли банк быстро и надёжно передавать данные между своими частями или всё держится на честном слове и ручной работе. Так родилась идея этой статьи.

Зрелость интеграционного слоя — это самый точный и измеримый показатель зрелости всей архитектуры банка. Без налаженных связей между системами даже самый современный core-банкинг превращается в изолированный остров.

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

Сразу важное уточнение: мы описываем усреднённый путь, подсмотренный в топ-10 российских банков — где-то лично, где-то по рассказам коллег. Одни проскочили уровни за считанные годы, другие до сих пор сидят на первом. 

Уровень 0: Досистемная эра. «Где карту открывали, туда и идите»

конец 1990 и начало 2000 гг.

В конце 1990-х банковская автоматизация только набирала обороты. Внутри отдельного филиала уже могли работать электронные проводки и простенькая АБС(решения на Clarion (DiasoftBANK 4×4) или на Btrieve (RS-Bank)), но за его пределами царил «гибридный» документооборот. Сведение бухгалтерских книг между офисами происходило путём физической перевозки дискет, флешек или все еще бумажных реестров. Даже обязательную отчётность в ЦБ зачастую отправляли на дискетах и это в середине 2000-х. Каналы связи были медленными, модемы — ненадёжными и о шифровании трафика между площадками задумывались далеко не все.

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

Из-за этих ограничений и родилась позже легендарная фраза «где карту открывали, туда и идите». Это не было вредностью сотрудника у него просто не было физической возможности увидеть данные из другого офиса.

Проблемы такого подхода были очевидны всем: дорогая поддержка разношёрстного «зоопарка», мучительный аудит, полное отсутствие клиентоориентированности. Но с точки зрения архитектуры главная характеристика этой эпохи — интеграционной платформы не существовало как класса. Её роль выполняли курьеры, модемы и человеческая память.

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

Уровень 1: Эпоха ESB. Порядок через централизацию

2005–2015 гг.

К середине 2000-х ситуация, описанная на предыдущем уровне, стала критической. На руках у банков — десятки разнородных «коробок», написанных в разное время, разными людьми и на разных языках. Где-то COBOL, где-то Delphi, где-то самописный Java. Слияния и поглощения только усугубили этот зоопарк: после очередной сделки банк мог получить в наследство сразу четыре-пять различных АБС. Переписать всё с нуля — значит потерять миллионы и парализовать бизнес на годы. Нужно было решение, которое бы «подружило» системы, не заставляя их меняться. Им стала ESB (Enterprise Service Bus) и построенный вокруг неё архитектурный стиль SOA.

Главным героем эпохи на российском рынке стала IBM WebSphere — не просто шина, а целая экосистема с брокерами, очередями, менеджерами и серверами приложений которая умела главное: содержать сложную логику трансформации данных и гарантировать доставку сообщений. Схема была простой: к каждой legacy-системе дописывался адаптер, который с одной стороны общался с шиной, а с другой — напрямую лез в базу данных или работал с проприетарным протоколом древнего монолита. Шина же становилась универсальным переводчиком, например: забирала из системы А текстовый файл, преобразовывала в XML, дозапрашивала данные из систем Б и В, сверялась со справочником в системе Г и упаковывала результат для системы Д. Без переписывания самих «коробок». Таким образом, банк впервые получал единый, контролируемый канал передачи данных между всеми своими частями.

Внедрение ESB немедленно отразилось на клиентском опыте. Легендарная фраза «где заявку оформляли, туда и идите» начала постепенно уходить в прошлое. «Ренессанс Кредит» на фоне внедрения SOA к 2011 году подключил к шине 15 систем, которые взаимодействовали через 150 переиспользуемых сервисов; в пиковый сезон шина прокачивала до 250 000 сообщений в день. Именно это (вместе с заменой АБС с диасофт на FIS Profile) позволило банку создать комбинированный продукт «кредит + карта» всего за два месяца — неслыханная для того времени скорость. УРСА Банк, в свою очередь, сумел подружить пять разных АБС в единый работающий организм, обеспечив устойчивость банка в целом. Подобных историй успеха в то время было множество, и банки один за другим вставали на рельсы SOA.

Однако к 2015 году эйфория спала. Умная шина оказалась палкой о двух концах. Во-первых, она превратилась в единую точку отказа: сбой в одном месте валил весь банк. Во-вторых, поддержка и развитие такой архитектуры требовали огромных команд дорогих специалистов, понимающих хитросплетения брокеров, очередей и отказоустойчивых кластеров. В-третьих, каждый новый проект требовал длительного цикла согласования изменений в канонической модели данных (CDM) и в логике самой шины. Централизованная «умная» труба стала «бутылочным горлышком», в котором тонули инновации. Неудивительно, что вскоре мир начал разворот к противоположному принципу — «глупый канал, умные конечные точки», но об этом в следующем уровне.

Уровень 2: Эпоха Agile трансформации. Хаос

2015-2020 гг.

Путь отказа от умной ESB тернист и сложен, и каждый банк проходил его по-своему. Всё сильно зависело от масштаба, наличия денег на глобальную трансформацию «сразу» и необходимости резких перемен. Кто-то начинал Agile-трансформацию и постепенно перестраивал архитектуру. Кто-то «выкидывал» старую архитектуру и, разом наняв больше двух тысяч специалистов, строил новую рядом, с нуля, а то-то до сих пор активно использует покупные коробочные решения. Но если банк хотел быть гибким и быстрым в условиях меняющегося рынка, трансформация была неизбежна.

К середине 2010-х большинство жило в похожих условиях: большая коробка интернет-банка (покупная вроде BIFIT или самописная), монстр-монолит на уровне мидл-слоя вроде Oracle Siebel CRM или Dynamics CRM, процессинг, АБС и прочие монолитные системы. От совсем древних монолитов многие уже избавились, но пришло понимание: развитие по «водопаду», отлично работавшее в SOA, больше не отвечает требованиям рынка. Коробочные решения развивались медленно, дорого и с непредсказуемыми сроками.

Agile-трансформация и микросервисы оказались неразрывно связаны: без одного достичь другого практически невозможно. Здесь железно работает закон Конвея: «Организации проектируют системы, которые копируют структуру коммуникаций в этой организации». Пять продуктовых команд — пять сервисов, общающихся через Kafka. Две команды, которые не общаются, — два сервиса с разными моделями данных для одного и того же клиента.

Громадные монолиты вроде Siebel распиливаются на десятки систем. Логика связи из IBM MQ — «умного» канала с гарантированной доставкой — мигрирует в сами микросервисы, и взаимодействия идут уже по принципу «умная точка, глупый канал»: RabbitMQ, Kafka или прямые HTTP-вызовы.

Казалось бы — рай. Всё распилено, команды автономны, новые продукты можно выводить быстро. Но в этом хаосе проявляется фундаментальная проблема: управлять этим невозможно. Один пользовательский запрос проходит через десяток сервисов, и восстановить его путь — нетривиальная задача.

Безопасность тоже рассыпалась. В монолите был один периметр, в микросервисах — десятки и сотни. И, например, неконтролируемая передача SAD при точечных интеграциях вела к многомиллионным штрафам и потере доверия клиентов (статья про SAD и PCIDSS).

Контроль над архитектурой в таких условиях остаётся лишь формальным — через ADR (Architecture Decision Records) на архитектурных комитетах, которые никто не проверяет в реальном времени. Единственное реальное ограничение — фаерволлы: открыл доступ между двумя узлами, и всё, дальше делай что хочешь. При прямых интеграциях ничто не мешает разработчикам проигнорировать согласованные 10 RPS и пустить 10 000 000, положив критичную систему банка.

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

Уровень 3: Централизованный интеграционный слой

2020–2025 гг.

Прежде чем перейти к централизованному интеграционному слою, стоит упомянуть альтернативный путь — Service Mesh. Концепция «умная сеть, глупые конечные точки» выглядит элегантно: все микросервисы общаются через единую инфраструктуру с mTLS-шифрованием, динамическим сервис-дискавери, тонким разграничением доступа и многими другими плюсами из “коробки”. Казалось бы — идеальное решение! Однако на практике банков, которые перевели бы на Service Mesh значительную часть своего ландшафта я не встречал. Сбер, Альфа-Банк и многие другие применяют эту технологию, но в масштабах отдельных крупных систем, а не как единый всеохватывающий слой. Архитектура, основанная на Service Mesh — это сложно, дорого и требует совершенно иной культуры разработки. 

Мы наконец приходим к той архитектуре, которая была рассмотрена в прошлой статье(Как устроен финтех изнутри). Вызовы децентрализации обязывают банк создавать единый интеграционный слой между слоями и там, где это возможно, отказываться от прямых интеграций между системами.

Вкратце механика такая: разворачиваются отказоустойчивые, геораспределённые кластеры для Kafka, MQ и API GW. Добавляются инструменты автоматизации заведения и доработки API, очередей и топиков. Сверху — мониторинг, троттлинг и непрерывный аудит через гибкую ролевую модель, завязанную на единую систему аутентификации(UAS).

Примерно по такому пути с 2020 по 2024 год шёл Россельхозбанк с платформой App.Farm, Альфа-банк, ВТБ и многие зарубежные. 

В такой архитектуре условный аналитик CRM уже не гадает, откуда и как взять нужные данные для нового бизнес-процесса, не бегает к синьорам других команд за информацией. Вместо этого на консоли можно находит нужные источники данных и парой кликов запускает процесс доступа. Банк чётко видит потоки данных между системами, аудит становится делом минутной выгрузки.

Однако есть у этой схемы и минусы, которые не позволяют однозначно утверждать, что все должны стремиться именно к этому уровню. Централизация по умолчанию создаёт точки отказа и в процессах, и в системах. Эти точки можно обложить «соломкой», но полностью избавиться от них нельзя. Без автоматизации процесса управления заведением новых потоков данных и правок существующих минусов становится слишком много: отдельная огромная команда, которая вручную правит очереди, топики и API, вернёт нас в ту же пропасть «бутылочного горлышка», что и в эпоху ESB. Применять этот уровень нужно с умом и с правильной подготовкой.

Уровень 4: AI-Assisted — платформа самообслуживания и Internal Developer Platform

2025 – настоящее время

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

Ровно эту боль и начал закрывать AI-Assisted подход. Искусственный интеллект здесь не заменяет архитектора или разработчика, а снимает с него рутину. Мы с Сергеем видим в этом естественную эволюцию Уровня 3: если интеграционный слой уже цифровизирован и все артефакты живут в машиночитаемом виде, почему бы не позволить ИИ управлять ими?

Ключевые элементы этого уровня это:

• Self-Service с каталогами API, очередей и топиков и AI-проводником. Разработчик заходит на внутренний портал, описывает на естественном языке, какие данные ему нужны, и AI-агент сам находит подходящий endpoint, генерирует контракт, предлагает политики безопасности и создаёт черновик Pull Request’а. Никакого ручного поиска по докам и долгих переписок с владельцами систем.

• GitOps. Все контракты хранятся в Git. Изменения проходят через автоматические проверки: линтеры, тесты на обратную совместимость, соответствие банковским стандартам. Ручное вмешательство нужно только для финального аппрува.

• AI-генерация кода и документации. Интеграционные адаптеры, конфигурации маршрутов и архитектурные диаграммы формируются автоматически на основе контракта. Документация всегда актуальна, потому что генерируется заново при каждом изменении.

• AI-аудит и подсказки. Система сама подсказывает если новый контракт дублирует уже существующий, доработка нарушает SLA или противоречит регуляторным требованиям.

AI-Assisted уровень — это не серебряная пуля, а логичное продолжение курса на прозрачность и контролируемую автоматизацию. Он закрывает остаточную рутину и готовит почву для следующего шага — где ИИ перестанет быть помощником и станет ядром архитектуры. Но об этом в следующем уровне.

Уровень 5. AI First и AI Native подходы в финтехе

возможное будущее

Представьте себе банк, разорванный между двумя реальностями. С одной стороны — CORE-слой: жёсткая регуляторика, обязательные отчёты перед ЦБ, 850П с серьезными требованиями по отказоустойчивости и доступности. С другой — взрывной рост AI-агентов. Это напряжение и есть точка рождения AI-Native архитектуры.

Ключевой сдвиг по сравнению с предыдущим уровнем: на AI-Assisted помогал разработчику. Здесь агенты действуют автономно. Product owner описывает задачу на естественном языке, а AI-агенты сами проектируют, тестируют и выкатывают функционал клиенту. Разработчик из «писателя кода» превращается в куратора домена: пишет промпты, следит за инфраструктурой и вмешивается, только когда что-то пошло не так.

Интеграционный слой при этом не исчезает — он мутирует. Превращается в стандартизированную среду, которую многие уже называют AI Fabric: единый, управляемый слой, предоставляющий доменно-ориентированные потоки данных AI-агентам без необходимости перестраивать интеграции под каждую модель. Это смена того, как банковские данные производятся, передаются и потребляются — через событийно-ориентированную архитектуру и data mesh, а не точечные интеграции.

Плюсы захватывают дух: скорость вывода продуктов становится недостижимой для конкурентов на старых архитектурах, стоимость разработки падает, а команда из 5 кураторов может управлять ландшафтом, который раньше требовал 200 разработчиков.

Но минусы столь же серьёзны. Первый — проблема общей семантики. Если AI-агенты получают доступ к разрозненным данным, они галлюцинируют и ломаются. Второй — объяснимость и аудит. Когда AI-агент принимает решение о кредитной заявке, регулятор захочет знать, на каком основании. Каждое решение агента должно прозрачно трассироваться и аудироваться. 

Наш с Сергеем прогноз: AI-агенты займут весь канальный слой и мидл-слой банка, но CORE и безопасность останутся под контролем человека. Это не «чёрный ящик», а система с прозрачными стеклянными стенами, где видно каждое действие, но выполняют эти действия не люди. Формирование систем и интеграций между ними будет происходить при помощи ИИ — быстро, без участия дорогостоящей разработки, но под надзором инженера-куратора.

Заключение. Отсутствующий интеграционный слой — венец развития?

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

Скоро ли банк придёт к тому, что 5-6 менеджеров, разбирающихся в домене, заменят команды разработки из тысяч людей? Сергей уверен, что да и скоро. Я чуть более скептичен и считаю, что спешить тут нельзя. Финтех — это не про edge-технологии и молниеносное следование трендам, а про надёжность и доверие людей. 

Но оба мы согласны с тем, что вместо того чтобы вручную настраивать очереди и контракты, человек станет тем, кто задаёт правила игры: определяет границы автономии агентов, выстраивает прозрачную систему аудита и следит, чтобы ИИ не превратился в чёрный ящик без объяснений. Доменную логику и ответственность за решения ИИ не заменит — потому что расписываться перед ЦБ придётся человеку. По крайней мере пока сам аудитор не перешел на AI-Native. 

Фраза «где карту открывали, туда и идите» ушла в прошлое. Когда-нибудь уйдёт и фраза «сделайте ADR и согласуйте с десятком команд». Интеграционный слой перестанет быть проблемой — и это финал нашей эволюции.