Ninth Wave 如何在 Amazon Bedrock 上构建 AI 驱动的开放金融接入系统

参与开放金融的金融机构——即银行通过标准化 API 与第三方应用共享经客户授权的金融数据的网络——持续面临集成难题。每家银行的 API 都使用各自的字段名称、格式约定，并且相对于 Financial Data Exchange（FDX）标准存在不同程度的缺口。验证这些 API、映射字段并评估其生产连接就绪度，传统上需要专家通过电子邮件往来和电子表格投入数周时间。

Ninth Wave 为金融机构与第三方应用之间提供安全的数据连接服务，将其连接至 Plaid、Finicity 和 MX 等聚合平台，以及 Intuit QuickBooks、Xero 和 Sage 等会计系统。该系统将银行 API 规范化为 FDX 标准，使银行只需接入一次 Ninth Wave 平台，即可连接整个开放金融网络。为进一步提升接入效率和响应速度，Ninth Wave 构建了 Compass——一款由 Amazon Bedrock AgentCore 驱动、支持 AI 的接入助手。Compass 提供协作式自助体验，同时继续满足 Ninth Wave 已建立的安全标准和金融服务合规要求。

本文介绍 Ninth Wave 如何在 Amazon Bedrock AgentCore 上为受监管、领域特定的工作流设计并部署多智能体系统。我们将讲解 Compass 背后的多智能体架构、如何让每一项回答基于银行自身数据、生产环境中的按任务模型配置，以及支持企业安全要求的更广泛 AWS 技术栈。

战略要求

Ninth Wave Compass 的设计目标是通过自助门户优化接入体验，让银行工程师、聚合平台集成团队与 Ninth Wave 接入团队在共享的 AI 赋能工作区中协作。

该项目有三项要求：

• 提高接入效率 – 简化 API 验证、字段映射和就绪度评分流程，高效利用工程资源，加快响应速度，并确保各团队之间的信息一致且保持最新。
• 向外部合作伙伴提供受治理的 AI 体验 – 为银行开发者和金融科技合作伙伴提供可靠的 AI 支持洞察，以辅助集成决策，同时延续 Ninth Wave 对多租户数据隔离、内容安全控制和审计日志的一贯承诺。
• 维持金融服务合规标准 – 在 Compass 中继续实施 Ninth Wave 已建立的安全与合规实践，包括最小权限访问、静态与传输中加密，以及符合 SOC 2 和 PCI DSS 要求。

为什么选择 Amazon Bedrock AgentCore 上的多智能体协作

我们评估了在 Amazon Elastic Compute Cloud (Amazon EC2) 上自托管模型的方案，它能够提供完全控制，但也带来了额外运维开销；还评估了单智能体检索增强生成（RAG）模式，该方案更简单，但在映射、分析、搜索和交互式问答等任务上的准确性较低。多智能体架构的前期复杂度更高，但每个智能体都专注于单项任务，并拥有独立的上下文和指令提示词。它们不会争夺提示词空间，准确性也能随任务类型数量扩展而提升。Amazon Bedrock AgentCore 提供托管式智能体运行时，用于承载和扩展这些智能体；而 Strands Agents 框架则负责处理编排逻辑，包括意图分类以及不同专家智能体之间的路由。

以下三项设计决策定义了该架构：

• 基于意图的路由 – 编排器仅对用户意图分类一次，并将请求路由给合适的专家智能体。每个智能体的上下文窗口保持清晰，输出也保持可预测。
• 按任务选择模型 – 轻量级模型处理高吞吐量任务，更强推理能力的模型处理映射、分析和交互式问答。我们依据任务复杂度匹配模型能力，而不是将所有请求都路由至同一个模型。
• 租户范围内的上下文注入 – 在调用智能体之前，应用会将该银行自身的上下文组装到请求中。这使系统能够按租户控制每个智能体可见的信息，确保一家银行的数据不会进入另一家银行的会话。

Amazon Bedrock 在单一服务中提供托管式多智能体编排、多模型访问和企业级安全控制（AWS Identity and Access Management (IAM)、AWS Key Management Service (AWS KMS) 和私有网络），因此团队可以专注于领域逻辑，而不必处理大语言模型（LLM）基础设施。有关模型在不同 AWS 区域的可用性，请参阅 Amazon Bedrock 中按 AWS 区域列出的受支持模型。

解决方案概述

下图展示了 Compass 如何端到端地处理接入请求。编号步骤对应系统中的数据流。

图 1：Amazon Bedrock 上的 Ninth Wave Compass 多智能体 AI 架构

步骤 1：边缘安全 – 流量通过 Amazon CloudFront（TLS 1.2+、HSTS）和配置默认拒绝 Web ACL 的 AWS WAF v2 进入。由于 Compass 在同一应用中同时服务外部银行开发者和内部用户，因此每个请求在到达应用逻辑之前都会被限定至单个租户：AWS WAF 提供边缘层流量防护，而应用授权将每家银行限制在其自身的接入工作区中。随后，请求会路由至内部 Application Load Balancer（TLS 1.3）。

步骤 2：身份验证和身份标识 – 运行在 AWS Fargate 上的 Amazon Elastic Container Service (Amazon ECS) 会针对强制启用多因素身份验证（MFA）的 OAuth2/OIDC 身份提供商验证会话。身份提供商会将银行的租户身份传递至下游服务，后者使用该身份限定每一次数据查询的范围。系统从 AWS Secrets Manager 获取凭证（每个环境使用客户自主管理的 KMS 密钥），AWS IAM 强制实施最小权限访问，AWS CloudTrail 则记录受支持的 AWS API 活动。

步骤 3：租户范围内的上下文注入 – 在调用智能体前，Compass 会从 Amazon OpenSearch Service（每租户索引）和 Amazon Simple Storage Service (Amazon S3)（每租户前缀）获取对应银行的上下文。该引擎会将银行自身的 API 文档、配置数据和过往交互上下文组装进请求。租户范围内的上下文组装旨在防止一家银行的信息被纳入另一家银行的智能体会话，即使二者共享同一模型基础设施。

步骤 4：多智能体编排 – 带有上下文的请求通过跨账户 IAM 角色进入专用的 Amazon Bedrock AgentCore 运行时。该角色在账户级别将 AI 工作负载与应用工作负载分离，以实现爆炸半径隔离。构建于运行在 AgentCore 上的 Strands Agents 的 Primary Compass Agent 会对意图进行分类，并将请求路由到以下七类专家智能体之一：

• 搜索 – 对门户文档中的结果进行排序。
• 文档问答 – 基于 Compass 和 FDX 文档回答自然语言问题。
• 文档分类 – 自动对上传的文档进行分类。
• 字段映射 – 将 FDX 字段与银行的 API 结构进行匹配。
• 分析 – 标记字段级偏差、格式问题和命名约定缺口。
• 交互式工作流 – 通过 AgentCore 工具调用框架驱动引导式接入工作流。
• 就绪度分析 – 使用 Amazon Bedrock Knowledge Bases 生成就绪度说明；这是 Amazon Bedrock 的全托管 RAG 功能。

每个智能体都在受限的上下文窗口内运行。编排器的分类步骤有助于避免提示词稀释。字段映射请求不会与文档搜索争夺 token 空间。正是这种分离使系统能够扩展至新任务类型，而不会降低现有智能体的准确性。

步骤 5：知识库检索 – 就绪度分析是唯一从 Amazon Bedrock 知识库检索内容的专家智能体。这是有意为之的范围决策：其他智能体完全在应用层（步骤 3）完成上下文注入，让团队能够完全控制检索逻辑和排序。就绪度分析是例外，因为它需要综合 FDX 参考文档语料库中的信息，而该语料库过大，无法在单次请求中传入。因此，对于这个特定智能体而言，RAG 是合适的模式。

步骤 6：FDX 就绪度评分 – 就绪度评分由应用代码根据 OpenSearch 中所需字段的映射覆盖率进行确定性计算，而非由模型估算。与字段覆盖率绑定的确定性计算能够以概率模型输出无法做到的方式满足审计要求。

步骤 7：可观测性 – ECS 将每个智能体的指标（调用次数、token 使用量、延迟、成本）发送至 Amazon CloudWatch，后者通过 Amazon Simple Notification Service (Amazon SNS) 触发告警，并为 Amazon Managed Grafana 仪表板提供数据。按智能体维度划分指标，使团队能够在单个智能体层面检测回归问题，而不仅仅将其视为系统范围的问题。

智能体行为和安全约束在应用层按智能体实施。这使团队能够调整某个智能体的范围和输出边界，而不会影响其他智能体。

实施历程

我们通过五个聚焦的冲刺阶段交付了 Compass，每个阶段都建立在前一阶段的基础上。

阶段 1：AI 应用基础设施

我们部署了核心基础设施：Amazon OpenSearch Service 的每租户索引、用于文档存储和知识库内容的 Amazon S3，以及通过 AWS CloudFormation（使用 AWS Cloud Development Kit (AWS CDK)）管理专用工作负载、Bedrock 和共享服务账户中资源栈的能力。我们使用按任务配置的模型组合配置了 Amazon Bedrock AgentCore，并建立了用于工作负载与 AgentCore 通信的跨账户 IAM 角色。

阶段 2：开发者门户与接入自动化

我们构建了供银行工程师和聚合平台合作伙伴使用的门户界面，其中包括自动化映射指南生成、接入脚本编写以及定制品牌的合作伙伴门户。

图 2：Compass 接入门户，银行开发者使用该界面上传 API 并与 AI 智能体交互

图 3：Compass 接入仪表板，展示银行的引导式接入步骤和进度

阶段 3：AI 部署

我们在运行于 Amazon Bedrock AgentCore 的 Strands Agents 上部署了主编排器和专家智能体，集成了租户范围内的上下文注入，并为就绪度分析搭建了 Amazon Bedrock 知识库。

图 4：Compass 知识库，开发者可在其中搜索文档或提问，并获得有依据的回答

阶段 4：安全加固

由于 Compass 向外部合作伙伴开放 AI 能力，安全加固被设置为独立阶段：

• 配置默认拒绝 Web ACL 的 AWS WAF（WAFv2），用于边缘层流量防护。
• 强制启用 MFA 的 OAuth2/OpenID Connect（OIDC）身份提供商。
• AWS Secrets Manager 配合每环境客户自主管理的 AWS KMS 密钥。
• 跨 OpenSearch 索引和 S3 前缀的每租户数据隔离。
• 在应用层按智能体应用行为和安全约束。
• TLS 1.2+（启用 HSTS 的 Amazon CloudFront）和 TLS 1.3（内部负载均衡器）。使用客户自主管理的 KMS 密钥保护静态数据。

Compass 延续了 Ninth Wave 已建立的安全和合规实践，包括最小权限访问、静态与传输中加密，以及符合 SOC 2 和 PCI DSS 要求。

阶段 5：Beta 发布

我们于 2026 年 3 月 1 日将 Beta 客户接入上线应用。生产环境于 2026 年 5 月 15 日准备就绪，并于 6 月正式全面可用。

Financial institutions participating in open finance (the network where banks share customer-authorized financial data with third-party applications through standardized APIs) face a persistent integration challenge. Every bank exposes APIs with its own field names, formatting conventions, and gaps relative to the Financial Data Exchange (FDX) standard. Validating those APIs, mapping fields, and scoring readiness for production connectivity has traditionally required weeks of specialist effort across email threads and spreadsheets.

Ninth Wave provides secure data connectivity between financial institutions and third-party applications, connecting them to aggregators such as Plaid, Finicity, and MX, and accounting systems including Intuit QuickBooks, Xero, and Sage. The system normalizes bank APIs to FDX standards so that a bank integrates once to the Ninth Wave platform and reaches the entire open finance network. To further enhance onboarding efficiency and responsiveness, Ninth Wave built Compass, an AI-enabled onboarding assistant powered by Amazon Bedrock AgentCore. Compass provides a collaborative, self-service experience while continuing to meet Ninth Wave’s established security and financial-services compliance standards.

In this post, we describe how Ninth Wave designed and deployed a multi-agent system on Amazon Bedrock AgentCore for a regulated, domain-specific workflow. We walk through the multi-agent architecture behind Compass, the approach to grounding each response in the bank’s own data, the per-task model configuration running in production, and the broader AWS stack that supports enterprise security requirements.

Strategic requirements

Ninth Wave Compass was designed to enhance the onboarding experience through a self-service portal where bank engineers, aggregator integration teams, and Ninth Wave’s onboarding team collaborate in a shared, AI-enabled workspace.

The project had three requirements:

• Improve onboarding efficiency – Streamline API validation, field mapping, and readiness scoring to make efficient use of engineering resources, accelerate response times, and maintain consistent, up-to-date information across teams.
• Deliver a governed AI experience to external partners – Provide bank developers and fintech partners with reliable AI-supported insights for integration decisions while continuing Ninth Wave’s foundational commitment to multi-tenant data isolation, content-safety controls, and audit logging.
• Maintain financial-services compliance standards – Continue Ninth Wave’s established security and compliance practices within Compass, including least-privilege access, encryption at rest and in transit, and alignment with SOC 2 and PCI DSS requirements.

Why multi-agent collaboration on Amazon Bedrock AgentCore

We evaluated self-hosted models on Amazon Elastic Compute Cloud (Amazon EC2), which offered full control at the cost of additional overhead, and a single-agent Retrieval Augmented Generation (RAG) pattern, which was simpler but less accurate across mapping, analysis, search, and interactive Q&A. Multi-agent architecture was more complex upfront, but each agent stays focused on a single task with its own context and instruction prompt. There’s no competing for prompt space, and accuracy scales with the number of task types. Amazon Bedrock AgentCore provided the managed agent runtime to host and scale these agents, while the Strands Agents framework handles the orchestration logic: intent classification and routing between specialists.

Three design decisions defined the architecture:

• Intent-based routing – The orchestrator classifies user intent once and routes to the right specialist. Each agent’s context window stays clean, and outputs stay predictable.
• Per-task model selection – Lightweight models handle high-volume tasks, and higher-reasoning models handle mapping, analysis, and interactive Q&A. We match model capability to task complexity rather than routing everything through one model.
• Tenant-scoped grounding – Before an agent is invoked, the application assembles that bank’s own context into the request. This gives per-tenant control over what each agent sees, so one bank’s data does not enter another bank’s session.

Amazon Bedrock provides managed multi-agent orchestration, access to multiple models, and enterprise security controls (AWS Identity and Access Management (IAM), AWS Key Management Service (AWS KMS), private networking) under a single service, so the team can focus on domain logic rather than large language model (LLM) infrastructure. For model availability by AWS Region, refer to Supported models by AWS Region in Amazon Bedrock.

Solution overview

The following architecture diagram illustrates how Compass processes an onboarding request end to end. The numbered steps correspond to the data flow through the system.

Figure 1: Ninth Wave Compass multi-agent AI architecture on Amazon Bedrock

Step 1: Edge security – Traffic enters through Amazon CloudFront (TLS 1.2+, HSTS) and AWS WAF v2 with default-deny web ACLs. Because Compass serves external bank developers alongside internal users on the same application, every request is scoped to a single tenant before it reaches application logic: AWS WAF provides edge-layer traffic protection, and application authorization restricts each bank to its own onboarding workspace. Requests then route to an internal Application Load Balancer (TLS 1.3).

Step 2: Authentication and identity – Amazon Elastic Container Service (Amazon ECS) on AWS Fargate validates sessions against an OAuth2/OIDC identity provider with multi-factor authentication (MFA) enforced. The identity provider carries the bank’s tenant identity through to downstream services, which use it to scope every data query. It retrieves credentials from AWS Secrets Manager (per-environment customer-managed KMS keys), AWS IAM enforces least-privilege access, and AWS CloudTrail records supported AWS API activity.

Step 3: Tenant-scoped grounding – Before invoking an agent, Compass fetches that specific bank’s context from Amazon OpenSearch Service (per-tenant indices) and Amazon Simple Storage Service (Amazon S3) (per-tenant prefixes). The engine assembles the bank’s own API documentation, configuration data, and prior interaction context into the request. Tenant-scoped context assembly is designed to prevent one bank’s information from being included in another bank’s agent session, even though both share the same model infrastructure.

Step 4: Multi-agent orchestration – The grounded request crosses into a dedicated Amazon Bedrock AgentCore runtime via a cross-account IAM role, which separates AI workloads from application workloads at the account level for blast-radius containment. The Primary Compass Agent, built on Strands Agents running on AgentCore, classifies intent and routes to one of seven specialists:

• Search – ranks results across portal documentation.
• Documentation Q &A – answers natural-language questions grounded in Compass and FDX documentation.
• Document classification – classifies uploaded documentation automatically.
• Field mapping – aligns FDX fields to the bank’s API structure.
• Analysis – flags field-level drift, formatting issues, and naming-convention gaps.
• Interactive workflows – drives guided onboarding workflows through an AgentCore tool invocation framework.
• Readiness analysis – composes readiness narratives using Amazon Bedrock Knowledge Bases, the fully managed RAG capability in Amazon Bedrock.

Each agent operates within a bounded context window. The orchestrator’s classification step helps prevent prompt dilution. A mapping request doesn’t compete for token space with a documentation search. This separation is what allows the system to scale to new task types without degrading existing agent accuracy.

Step 5: Knowledge base retrieval – Readiness analysis is the one specialist that retrieves from an Amazon Bedrock knowledge base. This is a deliberate scope decision: the other agents are grounded entirely at the application layer (Step 3), which gives the team full control over retrieval logic and ranking. Readiness analysis is the exception because it needs to synthesize across a corpus of FDX reference documents too large to pass in a single request. This makes RAG the right pattern for that specific agent.

Step 6: FDX readiness score – The readiness score is computed deterministically in application code from required-field mapping coverage in OpenSearch, rather than estimated by a model. A deterministic computation tied to field coverage satisfies audit requirements in ways that a probabilistic model output cannot.

Step 7: Observability – ECS emits per-agent metrics (invocation count, token usage, latency, cost) to Amazon CloudWatch, which fires alerts through Amazon Simple Notification Service (Amazon SNS) and feeds Amazon Managed Grafana dashboards. Dimensioning metrics by agent allows the team to detect regressions at the individual agent level rather than only as a system-wide problem.

Agent behavior and safety constraints are enforced at the application layer on a per-agent basis. This gives the team the ability to tune scope and output boundaries for one agent without affecting the others.

Implementation journey

We delivered Compass in five focused sprints, each building on the previous one.

Phase 1: AI application foundations

We provisioned the core infrastructure: Amazon OpenSearch Service with per-tenant indices, Amazon S3 for document storage and knowledge base content, and AWS CloudFormation (using the AWS Cloud Development Kit (AWS CDK)) managing stacks across dedicated workload, Bedrock, and shared-services accounts. We configured Amazon Bedrock AgentCore with a per-task model mix and established cross-account IAM roles for workload-to-AgentCore communication.

Phase 2: Developer portal and onboarding automation

We built the portal interface that bank engineers and aggregator partners interact with, including automated mapping-guide generation, onboarding scripting, and custom-branded partner portals.

Figure 2: The Compass onboarding portal, the interface bank developers use to upload APIs and interact with AI agents

Figure 3: The Compass onboarding dashboard, showing guided onboarding steps and progress for a bank

Phase 3: AI deployment

We deployed the primary orchestrator on Strands Agents running on Amazon Bedrock AgentCore and the specialist agents, integrated tenant-scoped grounding, and stood up an Amazon Bedrock knowledge base for readiness analysis.

Figure 4: The Compass knowledge base, where developers search documentation or ask questions and receive grounded answers

Phase 4: Security hardening

Because Compass makes AI available to external partners, security hardening was a dedicated phase:

• AWS WAF (WAFv2) with default-deny web ACLs for edge-layer traffic protection.
• OAuth2/OpenID Connect (OIDC) identity provider with MFA enforced.
• AWS Secrets Manager with per-environment customer-managed AWS KMS keys.
• Per-tenant data isolation across OpenSearch indices and S3 prefixes.
• Application-layer behavioral and safety constraints applied per agent.
• TLS 1.2+ (Amazon CloudFront with HSTS) and TLS 1.3 (internal load balancer). Customer-managed KMS keys for data at rest.

Compass continues Ninth Wave’s established security and compliance practices, including least-privilege access, encryption at rest and in transit, and alignment with SOC 2 and PCI DSS requirements.

Phase 5: Beta launch

We onboarded beta clients onto the live application on March 1, 2026. The production environment was ready May 15, 2026, with general availability on June 1, 2026.

Observability and CI/CD

A multi-agent AI system requires observability at two levels: infrastructure health and agent behavior. Compass instruments both.

Amazon CloudWatch monitors infrastructure: load-balancer latency, Amazon ECS task count, and OpenSearch cluster health. Per-environment Amazon SNS topics route alerts to the on-call team. Application-layer custom metrics track Amazon Bedrock invocation count, token usage, latency, and cost, dimensioned by agent. This level of detail isolates issues to the individual agent level rather than only as a system failure.

Our continuous integration and continuous delivery (CI/CD) pipeline runs through GitHub Actions. Each push builds a container image, pushes it to Amazon Elastic Container Registry (Amazon ECR), registers a new ECS task definition, and performs a rolling deploy to AWS Fargate with circuit-breaker rollback. The circuit-breaker automatically reverts deployments that fail health checks. This safeguard matters when prompt or grounding changes can affect agent accuracy before metrics surface it.

Results

With Amazon Bedrock AgentCore, Ninth Wave enhanced its established onboarding process with a self-service, AI-enabled experience. This experience improves efficiency and responsiveness while supporting banks, aggregators, and fintech partners throughout the integration process. Compass continues Ninth Wave’s foundational commitment to security, governance, and financial-services compliance.

Key outcomes:

• 95 percent reduction in API mapping and analysis time – AI-enabled capabilities automate the process, improving efficiency and delivering results in minutes.
• Enhanced onboarding collaboration – A centralized, AI-enabled workspace improves coordination, information consistency, and responsiveness across participating teams.
• Expanded self-service support – Documentation chatbots and the API Explorer help external developers quickly obtain answers to integration questions.
• More efficient readiness scoring – Automated capabilities provide faster, more consistent assessments while optimizing engineering resources.
• Partner self-service – A custom-branded developer portal is available for each bank to invite aggregators and fintech partners to self-serve.

Today the system tracks Amazon Bedrock invocation volume, token usage, latency, and cost by agent, alongside infrastructure-health metrics, giving the operations team real-time visibility into onboarding performance.

Figure 5: Compass conversational agent answering a bank developer’s integration question with a grounded response

Conclusion

In this post, we described how Ninth Wave built Compass, a multi-agent AI onboarding system for open finance. Ninth Wave built it on Amazon Bedrock AgentCore and the Strands Agents orchestration framework, with a per-task model mix, tenant-scoped grounding, and an enterprise AWS security foundation. By enhancing its established onboarding process with a self-service AI experience, Ninth Wave achieved a 95 percent reduction in API mapping and analysis time.

“AI fundamentally changes how financial institutions build, integrate, and innovate, but it requires trust in the underlying infrastructure. Compass represents our vision for bringing intelligence, governance, and automation together – enabling banks to onboard faster, reduce operational complexity, and build the trusted foundation required for the next generation of AI-powered financial services.”

— George Anderson, Founder and CEO of Ninth Wave

As a next step, explore the following resources:

---

About the authors

Shawn Kelly

Shawn is a Software Engineer and AI Lead at Ninth Wave, where he leads the team behind Ninth Wave Compass, the company’s multi-agent AI onboarding platform for open finance. His work centers on applying Amazon Bedrock and agentic AI to the regulated, domain-specific challenge of connecting financial institutions to the open finance network.

Yesha Trivedi

Yesha is a Solutions Architect at AWS. She works with SMB and enterprise financial services companies to architect production AI systems, multi-agent platforms, cloud migrations, and modern application workloads on AWS. She has over five years of experience helping organizations in regulated industries design for scale, security, and compliance.