О чем эта статья

Однажды на собеседование на enterprise архитектора мне дали тестовое задание - нарисовать верхнеуровнево как я вижу банк и как общаются компоненты внутри него. Я соорудил нечто такое. Работу я, конечно же, не получил. Схема непонятна, элементы названы не по общепринятым наименованиям, а как я их видел и в целом получилось перегружено. Эта статья призвана выполнить это тестовое задание на текущем уровне моего развития как архитектора. 

Кому будет интересно?

• Архитекторам и будущим enterprise-архитекторам.  Кругозор лишним никогда не бывает и зачастую именно кругозор позволяет архитектору прорабатывать красивые и работающие решения.

• Аналитикам и разработчикам финтеха. Чтобы понять, как ваш кусочек пазла, будь то микросервис кредитов или модуль отчетности, встраивается в общую картину банка. 

• Любопытным клиентам банков. Для понимания насколько сложна и многослойна архитектура учреждения, которая отвечает за ваши финансы и насколько хорошо они защищены. Многие технические детали могут быть непонятны, но я постарался описать все достаточно просто. 

Дисклеймер

1. Рассматриваемая ниже архитектура - это моё личное видение архитектуры «с нуля». Она не описывает конкретный банк (включая ОТП), но обобщает реальный опыт и лучшие практики. Любой ли банк так устроен? Конечно нет, но основные системы будут в том или ином виде представлены. 

2. Я описываю с чем сам работал, поэтому фокус будет на обслуживании юридических лиц, но буду  делать отсылки и к обработке данных физических лиц. 

3. Статья выйдет объемной, но обзорной. Я пробегусь по верхам всех ключевых слоев. Если вас заинтересуют детали конкретных систем и интеграций - дайте знать в комментариях! По самым востребованным темам я подготовлю отдельные, более глубокие материалы.

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

5. К вопросу о терминологии: я сознательно отошел в этой статье от строгого следования стандартам (TOGAF или более «банковской» BIAN) в именовании слоев и визуализации. Это позволило использовать более интуитивно понятные термины, которые лучше отражают суть систем, не перегружая текст формализмами. Моя цель - не создать официальный документ, а дать живое и доступное объяснение архитектуры банка. Важное замечание - от банка к банку термины могут различаться, я постарался дать наиболее общие названия. 

6. При прочтении у вас может возникнуть вопрос: не является ли эта статья попыткой переизобрести BIAN? Ответ: нет. Статья отображает мой опыт и скорее вдохновлена BIAN с маппингом его на реалии архитектуры крупных банков, которые не строились с нуля и с которыми я успел тесно поработать. 

Глава 1. Обзор архитектурных слоев

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

• Сервисы безопасности (Security Services): Защищают ваши финансы от хакерских атак, мошенничества и внутренних злоупотреблений. Это первый и главный рубеж обороны.

• Канальный слой (Channel Layer): Это «лицо» банка, системы, с которыми непосредственно взаимодействуют люди. Сюда входят интернет-банк, мобильное приложение и другие фронтенды.

• Слой бизнес-процессов (Business Services Layer, миддл слой) : «Мозги» операционных процессов. Здесь хранится и обрабатывается клиентская информация. Эти системы должны быть быстрыми и отказоустойчивыми, они тесно интегрированы с системами канального слоя. 

• Слой базовых операций (Core Operations Layer, бэк-офис): “Сердце” банка. Тяжеловесные системы, которые отвечают за обработку транзакций, ведение счетов и соблюдение финансовой отчетности. Их приоритет - абсолютная надежность и консистентность данных.

• Интеграционный слой (Integration Layer): «Кровеносная система» банка. Он связывает все вышеперечисленные слои между собой, централизует коммуникацию и упрощает внедрение новых интеграций.

Глава 2. Каналы взаимодействия с банком

А теперь давайте детально разберем, какие именно каналы используют разные группы пользователей для общения с банком.

• Клиенты (физические и юридические лица). Через веб-браузер или мобильное приложение. Это самый массовый канал, который обрабатывается системами Дистанционного банковского обслуживания (ДБО). Именно с ним сталкивается большинство пользователей ежедневно. Детально разберем его в главе 4.

• Системы клиента (B2B-интеграции). Крупным юридическим лицам часто неудобно работать через веб-интерфейс банка. У них есть свои учетные системы (например, 1С или SAP), и им критически важно интегрировать их с банком напрямую. Для этого банк предоставляет API, позволяющий клиентам работать с данными и операциями в привычном интерфейсе их собственного ПО.

• Партнеры. Это могут быть как сотрудники банка (например, менеджеры по развитию), так и представители сторонних организаций (брокеры, агентства). Их задача - привлекать новых клиентов и помогать им с оформлением, взяв на себя часть бюрократических процедур. У них свой, специальный интерфейс для работы.

• Сотрудники банка. Операционисты, менеджеры, сотрудники службы поддержки - все, кто помогает клиентам решать проблемы, обрабатывает заявки, согласовывает операции и выполняет функции, которые еще не автоматизированы. Для них существуют внутренние банковские системы (т.н. «админки»).

• POS / ATM (Торговые терминалы и банкоматы). Это специализированные каналы. POS-терминалы принимают платежи в магазинах, а ATM - банкоматы, через которые можно снять наличные или внести деньги. Они общаются с ядром банка по строго регламентированным протоколам.

Глава 3. Сервисы безопасности (Security Service): цифровой бастион банка

Рассмотрим детальнее одну из самых важных частей любого банка - бастионы защиты от внутренних и внешних угроз.

Условно все сервисы безопасности можно разделить на два больших блока:

1. Активные системы защиты: обрабатывают входящие запросы и сфокусированы на внешних угрозах.

2. Защита от мошенничества и compliance: тесно интегрированы с другими системами банка и работают с ними в тандеме, выявляя внутренние угрозы и мошенничество.

Блок 1: Активные системы защиты

Это первая линия обороны, которая работает на опережение.

• WAF (Web Application Firewall)

  • Что это: Фаервол уровня веб-приложений. Любой вызов API извне проходит через него.

  • Как работает: Анализирует HTTP-трафик, чтобы защитить приложения от атак типа SQL-инъекций (SQLi), межсайтового скриптинга (XSS), подделки межсайтовых запросов (CSRF) и других. WAF интегирован с API GateWay и через него также может ограничивать вызовы, чтобы «наружу» были доступны только разрешенные и протестированные API.

  • Проще говоря: Это умный фильтр на входе в банк, который отсеивает явно вредоносные запросы.

• IDS/IPS (Intrusion Detection/Prevention Systems)

  • Что это: Системы обнаружения и предотвращения вторжений.

  • Как работает: IPS проверяет сетевые пакеты на наличие известных атак и блокирует их в реальном времени. IDS работает в пассивном режиме, дублируя функции IPS и одновременно мониторя весь трафик для построения полной картины инцидентов и выявления сложных, многоэтапных атак. Обычно тут активно применяются ML для детектирования аномалий. 

  • Аналогия: IPS - это патрульный, который сразу останавливает нарушителя. IDS - оператор камер наблюдения, который ищет связи между событиями.

• Sandbox («Песочница»)

  • Что это: Изолированная виртуальная среда для запуска подозрительных файлов. Обычно используется как обязательный элемент при бизнес процессах, где есть необходимость скачивать или получать от клиентов файлы. 

  • Как работает: Защищает от сложных целевых атак, использующих неизвестные (0-day) уязвимости. Например, на почту сотруднику приходит письмо с вредоносным вложением. Антивирус его не распознал. Песочница автоматически запускает файл, видит, что он пытается зашифровать файлы и подключиться к серверу в другой стране, и помечает его как вредоносный для всей сети банка.

• SIEM (Security Information and Event Management)

  • Что это: Система управления событиями и информационной безопасностью.

  • Как работает: Собирает логи и события в реальном времени со всех уголков банка: серверов, сетевого оборудования, межсетевых экранов, приложений. SIEM коррелирует события по сложным правилам, чтобы выявить атаки. Пример: система замечает попытку подбора пароля к учетной записи бухгалтера, затем успешный вход с того же IP, а через минуту - запрос на массовое скачивание данных клиентов. SIEM автоматически поднимает тревогу высшего приоритета.

• DLP (Data Loss Prevention)

  • Что это: Система защиты от утечек конфиденциальных данных.

  • Как работает: Контролирует каналы передачи информации (email, мессенджеры, веб-трафик, USB-порты). Пример из жизни: при попытке отправить себе на личную почту черновик прошлой, уже согласованной к публикации статьи система заблокировала письмо, обнаружив в тексте элементы, похожие на конфиденциальные данные, и отправила инцидент на ручной разбор в отдел ИБ.

Блок 2: Защита от мошенничества и compliance

Этот блок уже ближе к бизнес-логике, но неразрывно связан с безопасностью.

• Fraud Monitoring / Anti-Fraud

  • Что это: Система мониторинга мошенничества, работающая 24/7. Обычно интегрирована напрямую с ФНС и Росфинмониторингом

  • Как работает: В реальном времени анализирует действия клиентов (платежи, входы в ДБО, карточные операции) по поведенческим моделям. Многие сталкивались с ее работой, когда «нестандартный» платеж отклонялся с одновременным звонком от службы безопасности.

• AML (Anti-Money Laundering)

  • Что это: Система противодействия отмыванию денег.

  • Как работает: Автоматически проверяет транзакции клиентов на соответствие паттернам, предписанным ЦБ и международными стандартами. Пример: система формирует оповещение, если счет нового ООО за неделю провел обороты, в 100 раз превышающие уставной капитал, с контрагентами из офшорных зон, после чего средства были обналичены.

• Risk Management (Управление рисками)

  • Что это: Комплекс систем, оценивающих риски банка.

  • Как работает: Отвечает на вопрос: «Какие потери может понести банк и с какой вероятностью?». Включает операционные риски (сбои ИТ-систем), рыночные (изменение ключевой ставки), кредитные (дефолт клиента) и риск ликвидности.

• Compliance (Комплаенс)

  • Что это: Обеспечение соответствия требованиям законодательства.

  • Как работает: Проверка контрагентов, сотрудников и транзакций на предмет санкционных списков, конфликта интересов. Также отслеживание новых законов и приведение деятельности банка в соответствие с ними.

Глава 4. Системы канального слоя (Channel Layer): лицо банка

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

• ДБО (Дистанционное банковское обслуживание). Это «рабочие лошадки» клиентского взаимодействия. Обычно существует два раздельных ДБО:

  • ДБО для юридических лиц (ЮЛ)

  • ДБО для физических лиц (ФЛ)

Это независимые системы с разным функционалом. Если клиент одновременно является и физлицом, и ИП, у него будут две разные учетные записи на двух разных порталах.

Функционал ДБО замыкает на себя основную работу клиента с банком: проведение платежей (рублевых и валютных), просмотр истории операций, заказ выписок, валютный контроль и многое другое. Подробнее об архитектуре ДБО ЮЛ можно прочитать в моих предыдущих статьях (про PCI DSS, про интегарции, общая).

ДБО на схеме растянут сразу на несколько каналов и это не случайно. ДБО отвечает за реализацию интеграций с “коробками” вроде 1с, мое дело, диасофт, контакт и многие другие. API в этом случае схоже и обычно удается реализовать универсальное API сразу для нескольких каналов взаимодействия, тем самым исключив дублирование кода. 

• Система онбординга. Задача этой системы - превратить человека «с улицы» в клиента банка. Она управляет всем процессом: от подачи заявки и открытия счета до оформления документов и организации доставки карты курьером или в офисе. Система проводит необходимые проверки (в связке с системами безопасности) и обеспечивает максимально комфортное и быстрое подключение. Важный нюанс: для стадии «пре-клиента» часто выделяется отдельный канал, работающий по более сложной архитектуре. Поскольку у такого пользователя еще нет учетной записи, этот функционал обычно вынесен в DMZ-зону (демилитаризованную зону) сети, изолированную от внутренней сети банка для дополнительной безопасности.

• Личный кабинет партнера. Это отдельная, более узкоспециализированная система, функционально близкая к онбордингу. Она позволяет партнерам банка (например, брокерам или агентам) обеспечить своим клиентам индивидуальный и удобный процесс открытия счетов, взяв на себя большую часть бюрократических процедур.

• Единый рабочий стол сотрудника. Это огромная фронтальная система - основной инструмент сотрудников банка (операционистов, менеджеров). Сюда стекается и здесь отображается функционал практически всех систем бизнес слоя и бэк-офисных (слой базовых операций) систем, которым требуется взаимодействие с человеком.

Как это работает: Каждая система бизнес слоя «выкладывает» свой интерфейсный модуль(микро фронтэнд) в Единый рабочий стол. Это позволяет сотруднику в одном месте: проверять и проводить платежи, оформлять изменения клиентских данных, выполнять маркетинговые операции, работать с заявками и многое другое

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

• Модули POS и ATM. Это специализированные системы, обрабатывающие запросы от торговых терминалов (POS) и банкоматов (ATM). Они отвечают за авторизацию операций, проверку лимитов и базовый набор функций самообслуживания. Архитектурная особенность: На схеме это не показано явно, но эти системы - исключение из общих правил. Они обычно размещаются в изолированной зоне сети (часто CDE - Cardholder Data Environment) и имеют прямые интеграции с ядром (слой базовых операций), минуя общий интеграционный слой банка. Это продиктовано требованиями стандартов безопасности (например, PCI DSS) и необходимостью обеспечения максимальной скорости и надежности обработки платежных операций.

Глава 5. Интеграционный слой  (Integration Layer). Кровеносная система банка

Интеграционный слой (Integration Layer) - это не просто набор технологий для связи систем. Это централизованный подход к разработке интеграций, управлению доступом и данным. Он предотвращает хаос прямых соединений между сотнями систем, обеспечивая безопасность, прозрачность и контроль. 

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

Единая система аутентификации (ЕСА). Так же можно встретить понятие IAM (Identity Access Management). Прямые интеграции между системами в общем случае запрещены и необходимо использовать системы интеграционного слоя. ЕСА - это «пропускной пункт» для всех межсистемных взаимодействий.

• Как это работает: Перед началом интеграции каждая система регистрируется в ЕСА и получает уникальные ключи доступа (например, client_id и client_secret). Когда системе А нужно обратиться к системе Б, она сначала запрашивает у ЕСА кратковременный токен доступа (JWT), используя свои ключи. Этот токен предъявляется при каждом вызове API. Токен имеет ограниченное время жизни и автоматически обновляется в фоне.

• Выгода: Централизованное управление правами доступа. Система не сможет “незаметно” вызвать несогласованные API и получить доступ к данным, которые, возможно, требуют более сложной архитектуры. Тем самым не будет неописанных в архитектуре интеграций и повысится общая прозрачность и безопасность. Также в случае с API Gateway мы сможем централизованно управлять потоком событий, например проверять сообщение и тротлить отдельных потребителей при высокой нагрузке, тем самым обезопасив саму систему-источник от DoS.

Для понимания роли других систем немного детализируем использование интеграционного слоя для одной интеграции - ДБО интегрируем с MDM и CRM.

Принципы проектирования: почему внутренние коммуникации изолированы

На схеме видно, что интеграционный слой используется только для связи между разными системами. Внутренние взаимодействия внутри одной системы (например, между микросервисами ДБО) используют собственный, изолированный интеграционный слой.

Почему это важно?

1. Инкапсуляция: Мы показываем вовне только те API и события, которые предназначены для внешних потребителей. Внутренняя кухня системы скрыта от посторонних глаз.

2. Отказоустойчивость: Ошибка в одном микросервисе ДБО не должна вызвать «шторм» событий и положить общую интеграционную шину, критичную для работы всего банка.

3. Масштабируемость: Интеграционные инструменты (например, Kafka) не рассчитаны на бесконечное масштабирование. Количество внутренних микросервисов может в десятки и сотни раз превышать количество крупных систем, и их трафик нужно разделять.

Детализация потоков данных: синхронные и асинхронные взаимодействия

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

Синхронное взаимодействие (через API Gateway)

• Когда используется: Для запросов, которые могут подождать, где не требуется максимальная производительность и mission-critical надежность. Например, получение справочной информации или запуск не критичного по времени процесса.

• Как работает: Запрос от системы-источника (ДБО) идет через API Gateway к системе-цели (например, MDM). Источник ждет немедленного ответа.

• Пример на схеме:Запрос на изменение данных по пользователю в синхронном режиме (ДБО -> API GW -> MDM).

Асинхронное взаимодействие (через брокеры сообщений: Kafka, MQ)

• Когда используется: Для обработки действий клиента, где важны скорость отклика и высокая отказоустойчивость.

• Как работает:

  • Через Kafka (события): Система-источник (например, CRM) публикует событие (например, «Данные клиента обновлены») в топик. Система-потребитель (ДБО) подписывается на топик, читает события и обновляет свой локальный кэш. Последующие запросы клиента обслуживаются из быстрого кэша. Минус: возможна временная неконсистентность ( eventual consistency).

  • Через MQ (задачи): Для операций, требующих гарантированной доставки и обработки. Идеально подходит для длительных процессов.

• Пример на схеме:

  • Асинхронные событийные потоки данных (MDM -> Kafka -> ДБО) - для быстрого обновления кэша.

  • Запрос на изменение данных с участием человека (ДБО -> MQ -> MDM) - обновление критичных данных, например паспортных данных, адреса, правоустанавливающих документов. В этих процессах требуется живой человек и ответ (изменение принято, отклонено, в обработке,  на согласовании) придет позже. 

  • Другим хорошим примером, не отраженным на схеме, будет проведение платежа. Платеж гарантированно попадет в АБС, а статус будет доставлен в ДБО позже, когда обработка завершится.

Подробнее про проблемы событийной интеграции можно почитать тут (про интегарции).

Глава 6. Слой бизнес-сервисов (Business Services Layer): бизнес-логика и аналитика банка

Слой бизнес-сервисов - самый разнообразный по составу систем. Здесь живут как операционные системы, напрямую поддерживающие клиентское обслуживание, так и аналитические платформы и специализированные банковские модули. Важно отметить, что состав может сильно варьироваться в зависимости от специфики банка.

Давайте кратко рассмотрим основные системы этого слоя и их функции.

Управление клиентскими данными и отношениями

• BCRM (Operational CRM)

  • Что это: Операционная CRM, отвечающая за повседневную работу с клиентом.

  • За что отвечает: Здесь хранятся заявки, история взаимодействий, информация об организации. Это - единая точка входа для сотрудника, где собрано всё о клиенте как о клиенте банка.

• MDM (Master Data Management)

  • Что это: Система управления мастер-данными.

  • За что отвечает: Хранит эталонные, проверенные данные о физическом лице: паспорт, адрес, контакты. Это - единственный источник истины о человеке, которым пользуются все другие системы (BCRM, ДБО, онбординг и многие другие).

• СПР (Система принятия решений, Scoring & Decision Engine)

  • Что это: Система скоринга и принятия решений

  • За что отвечает: Автоматизирует процесс принятия решений по кредитным продуктам. Собирает данные из других источников банка и на основе сложных вычислений определяет можно ли предложить продукт клиенту и под какой процент. Обычно работает на BPM-движках, например Comunda

• НСИ (Нормативно-Справочная Информация)

  • Что это: Централизованная система управления всеми справочниками банка.

  • За что отвечает: Хранит и распределяет общие для многих систем справочные данные: коды валют, коды стран, тарифы, справочник отделений банка, шаблоны документов.

  • Почему это важно?: Без НСИ каждая система может иметь свою версию справочника (например, код доллара USA, USD, 840), что приводит к ошибкам в отчетности и интеграциях. НСИ обеспечивает единообразие. 

• ACRM (Analytical CRM)

  • Что это: Аналитическая CRM.

  • За что отвечает: Сюда стекаются данные для анализа и построения маркетинговых стратегий. Именно ACRM позволяет реализовать индивидуальный подход, предсказывая, какой продукт предложить клиенту и когда.

  • Дискуссия: ACRM может быть частью общей CRM, но выделение ее в отдельную систему помогает четче разделить зоны ответственности: операционная работа (BCRM) vs. аналитика и маркетинг (ACRM).

Бизнес-логика и продукты

• Product Profile

  • Что это: Система управления продуктовым профилем клиента.

  • За что отвечает: Определяет, какие продукты и услуги доступны конкретному клиенту или сегменту. Позволяет другим системам понимать, что уже подключено у клиента, и учитывать это при предложении новых услуг или расчете комиссий.

• Deposit Product Factory

  • Что это: Система управления продуктами срочного привлечения.

  • За что отвечает: Позволяет клиенту оформить депозит, НСО (неснижаемый остаток), копилку для бизнеса.

• FX Payments(Валютные операции)

  • Что это: Фабрика обработки валютных платежей.

  • За что отвечает: Управляет всем жизненным циклом валютной операции: от проверки валютным контролером до подготовки документов. Имеет компонент в бэк-офисе (слой базовых операций) для взаимодействия с внешними платежными системами (SWIFT и др.).

• Limit Service (Тарифный модуль)

  • Что это: Централизованный сервис для расчета сложных тарифов и лимитов.

  • За что отвечает: Отвечает на вопрос "Сколько с клиента списать?" по сложным формулам, учитывающим операции по карте, подключенные продукты, остатки на счетах и т.д.

Документооборот и коммуникации

• ECM (Enterprise Content Management)

  • Что это: Архив документов банка.

  • За что отвечает: Сюда попадают все документы в конечном, утвержденном статусе: заявления, сканы паспортов, договоры. Ключевая особенность - системы обмениваются не файлами, а ссылками на документ в ECM. Это обеспечивает консистентность и безопасность данных при интеграциях.

• Notification (Сервис уведомлений)

  • Что это: Центральный хаб для коммуникаций с клиентом.

  • За что отвечает: Позволяет другим системам отправлять SMS, email и push-уведомления через единый интерфейс, обеспечивая согласованность и логирование всех коммуникаций.

Аналитика и данные

• DWH (Data Warehouse) и BI (Business Intelligence)

  • DWH (Хранилище данных): Самостоятельно собирает данные из всех систем банка (через ETL-процессы), очищает, структурирует и агрегирует их для глубокого анализа.

  • BI (Бизнес-аналитика): Визуализирует данные, строит отчеты, дашборды и метрики для принятия управленческих решений.

Глава 7. Слой базовых операций (Core Operations Layer, бэк-офис): транзакционное ядро банка

Слой базовых операций - это консервативное ядро банка, где живут самые надежные и транзакционные системы. Их главные приоритеты - консистентность данных и устойчивость к авариям 24/7. Изменения здесь вносятся крайне осторожно, а консистентность является ключевым требованием.

Важно: системы этого слоя часто имеют собственные интерфейсы для работы сотрудников, доступные напрямую через рабочие станции в защищенном периметре банка. Такой подход исключает необходимость создания промежуточных систем-прослоек (например, отдельного веб интерфейса для АБС), что повышает удобство работы и снижает накладные расходы. 

Ядро операционной деятельности

• АБС (Core Banking)

  • Что это: Транзакционное сердце банка. Обычно представляет собой покупное (например, ЦФТ, Temenos, Flexcube) или legacy-решение - сложную базу данных со специализированным ПО.

  • За что отвечает: Учет всех счетов, клиентов, проведение платежей, формирование лицевых счетов и проводок. Это большая и неповоротливая система, доработка которой требует много времени и ресурсов.

• Карточный процессинг (Processing)

  • Что это: Система обработки транзакций с картами.

  • За что отвечает: Авторизация, клиринг и расчеты по карточным операциям. Хранит информацию о картах, привязанных к счетам в АБС. Работает в строгом соответствии со стандартами безопасности (PCI DSS). 

  • Чуть больше про систему вы можете узнать из предыдущей статьи (обработка карточных данных)

• FX Core

  • Что это: Система, расположенная в защищенном сегменте сети.

  • За что отвечает: Обеспечивает интеграцию с внешними платежными системами (SWIFT) для проведения валютных операций. Работает в тандеме с системой слоя бизнес-сервисов FX Payments, принимая от нее подготовленные и проверенные транзакции.

• Платежные шлюзы (Payment Hubs: СБП, НСПК)

  • Что это: Специализированные шлюзы для межбанковских расчетов. 

  • За что отвечает: Обеспечивают подключение и обмен сообщениями с национальными системами (Система быстрых платежей, Национальная система платежных карт «Мир»), выступая мостом между АБС и внешним миром. В некоторых банках сюда так же вынесена логика проведения плажетей из АБС, а АБС остается только учетной книгой. 

Управление финансами и рисками банка

• Казначейство / TMS (Treasury Management System)

  • Что это: Система управления ликвидностью, рисками и активами/обязательствами самого банка.

  • За что отвечает: Размещение и привлечение средств на межбанковском рынке, управление процентным риском, работа с ЦБ. Критически важна для финансовой устойчивости.

Внутренние процессы

• ERP (Enterprise Resource Planning)

  • Что это: Система для управления внутренними процессами банка как компании.

  • За что отвечает: Учет финансов, управление персоналом (HR), закупки. Это бэк-офис для внутренней деятельности банка.

Заключение. Архитектура банка: от каналов до ядра

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

• Канальный слой должен быть быстрым и отказоустойчивым.

• Слой бизнес-сервисов - гибким, именно здесь рождается большая часть бизнес-логики и инноваций.

• Слой базовых операций - консервативным и надежным, его стабильность дороже любой новизны.

• Интеграционный слой и безопасность - это клей и броня, которые связывают все компоненты в единое целое и защищают его.

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