Compass от Ninth Wave: мультиагентный онбординг банков на Amazon Bedrock AgentCore

Что мешает банкам подключаться к open finance

Open finance — это сеть, в которой банки делятся с третьими приложениями финансовыми данными клиента по его разрешению через стандартизированные API.

Проблема здесь не в отсутствии интерфейсов, а в их разнобое: каждый банк публикует API со своими именами полей, форматами и пробелами относительно стандарта Financial Data Exchange (FDX).

Проверка таких API, сопоставление полей и оценка готовности к продакшен-подключению традиционно требовали недель работы специалистов — через почтовые цепочки и электронные таблицы.

Что такое Ninth Wave и Compass

Ninth Wave обеспечивает безопасную передачу данных между финансовыми организациями и сторонними приложениями, подключая их к агрегаторам, включая Plaid, Finicity и MX, и к учётным системам Intuit QuickBooks, Xero и Sage.

Система нормализует банковские API к стандартам FDX: банку достаточно один раз интегрироваться с платформой Ninth Wave, чтобы получить доступ ко всей сети open finance.

Поверх этой платформы компания собрала Compass — AI-ассистента онбординга на Amazon Bedrock AgentCore: банковские инженеры, интеграционные команды агрегаторов и команда онбординга Ninth Wave работают в одном self-service рабочем пространстве.

Три требования, заданные до начала работы

Первое — ускорить онбординг: упростить валидацию API, маппинг полей и оценку готовности, чтобы инженерные ресурсы расходовались экономно, ответы приходили быстрее, а информация у команд оставалась согласованной и актуальной.

Второе — дать управляемый AI внешним партнёрам: разработчики банков и финтех-компаний должны получать надёжные подсказки для решений об интеграции, не теряя изоляцию данных между клиентами (multi-tenant), контроль безопасности контента и журналирование аудита.

Третье — сохранить отраслевые стандарты: least-privilege доступ, шифрование данных в покое и при передаче, соответствие требованиям SOC 2 и PCI DSS.

Почему выбрана мультиагентная архитектура

Команда сравнивала два более простых варианта: самостоятельно размещённые модели на Amazon Elastic Compute Cloud (Amazon EC2), которые дают полный контроль ценой дополнительной эксплуатационной нагрузки, и единственный агент с паттерном Retrieval Augmented Generation (RAG), который проще, но менее точен в маппинге, анализе, поиске и интерактивных вопросах.

Мультиагентная схема оказалась дороже на старте, но каждый агент в ней занят одной задачей со своим контекстом и своим инструкционным промптом: промпты не конкурируют за место, а точность растёт вместе с числом типов задач.

Рантайм для размещения и масштабирования агентов предоставил Amazon Bedrock AgentCore, а оркестрацию — классификацию намерения и маршрутизацию между специалистами — взял на себя фреймворк Strands Agents.

Три решения, определившие архитектуру

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

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

Замыкание контекста на арендатора: перед вызовом агента приложение собирает в запрос контекст конкретного банка, поэтому данные одного банка не попадают в сессию другого.

Как запрос проходит через систему

Трафик входит через Amazon CloudFront (TLS 1.2+ и HSTS) и AWS WAF v2 с правилами default-deny; каждый запрос ограничен рамками одного арендатора ещё до прикладной логики, после чего маршрутизируется на внутренний Application Load Balancer с TLS 1.3.

Аутентификация построена на Amazon Elastic Container Service (Amazon ECS) на AWS Fargate: сессии проверяются у провайдера идентичности OAuth2/OIDC с обязательной многофакторной аутентификацией, а идентичность банка передаётся дальше по сервисам и определяет область каждого запроса к данным.

Секреты хранятся в AWS Secrets Manager с управляемыми заказчиком ключами AWS KMS, доступ ограничен через AWS IAM, а поддерживаемые действия AWS API фиксирует AWS CloudTrail.

Контекст банка собирается из Amazon OpenSearch Service, где у каждого арендатора свой индекс, и из Amazon Simple Storage Service (Amazon S3) с отдельными префиксами, а сам запрос уходит в выделенный рантайм Amazon Bedrock AgentCore через кросс-аккаунтную роль IAM — AI-нагрузки отделены от прикладных на уровне аккаунта.

Основной агент Compass на Strands Agents классифицирует намерение и передаёт запрос одному из семи специалистов: поиск по документации портала, ответы на вопросы по документации Compass и FDX, автоматическая классификация загруженных документов, сопоставление полей FDX со структурой API банка, анализ смещений полей, проблем форматирования и соглашений об именовании, интерактивные сценарии онбординга и анализ готовности.

Знаниевую базу Amazon Bedrock использует только анализ готовности: ему нужно синтезировать выводы по корпусу справочных документов FDX, слишком большому для одного запроса, тогда как остальные агенты замкнуты на контекст приложения — такое разделение даёт команде полный контроль над логикой поиска и ранжирования.

Оценка готовности по FDX считается детерминированно в коде приложения по покрытию обязательных полей в OpenSearch, а не оценивается моделью: результат, привязанный к покрытию полей, удовлетворяет требованиям аудита, чего вероятностный вывод модели дать не может.

Наблюдаемость и выпуск

Amazon CloudWatch собирает метрики по каждому агенту — число вызовов, расход токенов, задержку и стоимость — и одновременно следит за инфраструктурой: задержкой балансировщика нагрузки, числом задач ECS и состоянием кластера OpenSearch.

Алерты уходят в темы Amazon Simple Notification Service (Amazon SNS) для дежурной команды, а метрики приложения попадают на дашборды Amazon Managed Grafana; разбивка по агентам позволяет находить регрессии у отдельного специалиста, а не только на уровне всей системы.

Выпуск идёт через GitHub Actions: каждый push собирает образ контейнера, отправляет его в Amazon Elastic Container Registry (Amazon ECR), регистрирует новое определение задачи ECS и выполняет rolling-развёртывание на AWS Fargate с откатом по circuit breaker, если проверки здоровья не проходят.

Compass выпустили за пять спринтов: бета-клиенты начали работать на живом приложении 1 марта 2026 года, продакшн-среда была готова 15 мая 2026 года, а общая доступность наступила 1 июня 2026 года.

Что получилось

Заявленный результат — сокращение времени на маппинг и анализ API на 95 %: AI-возможности автоматизируют процесс и выдают результат за минуты.

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

«AI фундаментально меняет то, как финансовые организации строят, интегрируют и внедряют инновации, но это требует доверия к инфраструктуре», — приводит слова основателя и CEO Ninth Wave Джорджа Андерсона (George Anderson) публикация AWS.

Compass продолжает принятые в Ninth Wave практики безопасности и соответствия: least-privilege доступ, шифрование в покое и при передаче, соответствие требованиям SOC 2 и PCI DSS.

Материал подготовили Шон Келли (Shawn Kelly), инженер-программист и руководитель направления AI в Ninth Wave, и Йеша Триведи (Yesha Trivedi), архитектор решений AWS.