How Ninth Wave built AI-powered open finance onboarding on Amazon BedrockNinth Wave 如何基于 Amazon Bedrock 构建人工智能驱动的开放金融接入服务

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.参与开放金融（即银行通过标准化 API 与第三方应用程序共享客户授权财务数据的网络）的金融机构面临着持续的集成挑战。每家银行提供的 API 都具有各自的字段名称、格式规范，且与金融数据交换（FDX）标准存在差距。验证这些 API、映射字段并评估生产环境连接的就绪状态，传统上需要跨越多个电子邮件线程和电子表格，耗费专家数周的时间。

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.Ninth Wave 为金融机构与第三方应用程序之间提供安全的数据连接，将它们与 Plaid、Finicity 和 MX 等聚合器，以及 Intuit QuickBooks、Xero 和 Sage 等会计系统相连。该系统将银行 API 标准化为 FDX 标准，使银行只需接入一次 Ninth Wave 平台，即可连接整个开放金融网络。为了进一步提高接入效率和响应速度，Ninth Wave 构建了 Compass，这是一个由 Amazon Bedrock AgentCore 提供支持的人工智能接入助手。Compass 在提供协作式自助服务体验的同时，持续满足 Ninth Wave 既定的安全和金融服务合规标准。

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.在本文中，我们将介绍 Ninth Wave 如何在 Amazon Bedrock AgentCore 上设计并部署用于受监管、特定领域工作流的多智能体系统。我们将详细剖析 Compass 背后的多智能体架构、确保每个响应基于银行自身数据的方法、在生产环境中运行的按任务模型配置，以及支持企业安全需求的更广泛的 AWS 技术栈。

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.Ninth Wave Compass 旨在通过自助服务门户提升接入体验，银行工程师、聚合器集成团队和 Ninth Wave 的接入团队可以在该门户的共享人工智能工作区中进行协作。

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.提高接入效率——简化 API 验证、字段映射和就绪状态评分，从而有效利用工程资源，加快响应速度，并保持各团队间信息的一致性和时效性。
• 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.为外部合作伙伴提供受控的人工智能体验——为银行开发人员和金融科技合作伙伴提供可靠的人工智能支持洞察，以辅助集成决策，同时继续履行 Ninth Wave 在多租户数据隔离、内容安全控制和审计日志记录方面的基本承诺。
• 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.维护金融服务合规标准——在 Compass 中持续执行 Ninth Wave 既定的安全和合规实践，包括最小权限访问、静态和传输中加密，以及符合 SOC 2 和 PCI DSS 要求。

Why multi-agent collaboration on Amazon Bedrock AgentCore为何选择 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.我们评估了在 Amazon Elastic Compute Cloud (Amazon EC2) 上自托管模型（虽然拥有完全控制权，但增加了额外开销）以及单智能体检索增强生成 (RAG) 模式（更简单，但在映射、分析、搜索和交互式问答方面的准确性较低）。多智能体架构虽然前期更复杂，但每个智能体都专注于单一任务，并拥有各自的上下文和指令提示。不存在提示词空间的竞争，且准确性会随着任务类型的增加而扩展。Amazon Bedrock AgentCore 提供了托管智能体运行时来托管和扩展这些智能体，而 Strands Agents 框架则负责编排逻辑：即意图分类以及在专家智能体之间进行路由。

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.租户级基础数据（Grounding）——在调用智能体之前，应用程序会将该银行自身的上下文组装到请求中。这实现了按租户控制每个智能体所能看到的内容，从而确保一家银行的数据不会进入另一家银行的会话中。

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.Amazon Bedrock 在单一服务下提供了托管多智能体编排、对多个模型的访问以及企业安全控制（AWS Identity and Access Management (IAM)、AWS Key Management Service (AWS KMS)、私有网络），因此团队可以专注于领域逻辑，而非大语言模型 (LLM) 基础设施。有关 AWS 区域的模型可用性，请参阅 Amazon Bedrock 中的“按 AWS 区域支持的模型”。

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.以下架构图说明了 Compass 如何端到端处理接入请求。编号步骤对应于数据在系统中的流动过程。

Figure 1: Ninth Wave Compass multi-agent AI architecture on Amazon Bedrock图 1：Amazon Bedrock 上的 Ninth Wave Compass 多智能体人工智能架构

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).第 1 步：边缘安全——流量通过 Amazon CloudFront (TLS 1.2+, HSTS) 和带有默认拒绝 Web ACL 的 AWS WAF v2 进入。由于 Compass 在同一应用程序上为外部银行开发人员和内部用户提供服务，因此每个请求在到达应用程序逻辑之前都会限定在单个租户内：AWS WAF 提供边缘层流量保护，应用程序授权将每家银行限制在其自己的接入工作区内。随后，请求被路由至内部应用程序负载均衡器 (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.第 2 步：身份验证与识别——AWS Fargate 上的 Amazon Elastic Container Service (Amazon ECS) 根据强制实施多因素身份验证 (MFA) 的 OAuth2/OIDC 身份提供商验证会话。身份提供商将银行的租户身份传递给下游服务，下游服务使用该身份来限定每个数据查询的范围。它从 AWS Secrets Manager（按环境的客户托管 KMS 密钥）检索凭证，AWS IAM 强制执行最小权限访问，AWS CloudTrail 记录受支持的 AWS API 活动。

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.第 3 步：租户级基础数据——在调用智能体之前，Compass 会从 Amazon OpenSearch Service（按租户索引）和 Amazon Simple Storage Service (Amazon S3)（按租户前缀）中获取该特定银行的上下文。引擎将银行自身的 API 文档、配置数据和之前的交互上下文组装到请求中。租户级上下文组装旨在防止一家银行的信息被包含在另一家银行的智能体会话中，即使两者共享相同的模型基础设施。

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:第 4 步：多智能体编排——基础数据请求通过跨账户 IAM 角色进入专用的 Amazon Bedrock AgentCore 运行时，该角色在账户级别将人工智能工作负载与应用程序工作负载隔离开来，以实现爆炸半径限制。构建在 AgentCore 上运行的 Strands Agents 之上的主 Compass 智能体负责分类意图，并路由至七个专家智能体之一：

• Search – ranks results across portal documentation.搜索——对门户文档中的结果进行排序。
• Documentation Q&A – answers natural-language questions grounded in Compass and FDX documentation.文档问答——回答基于 Compass 和 FDX 文档的自然语言问题。
• Document classification – classifies uploaded documentation automatically.文档分类——自动对上传的文档进行分类。
• Field mapping – aligns FDX fields to the bank’s API structure.字段映射——将 FDX 字段与银行的 API 结构进行对齐。
• Analysis – flags field-level drift, formatting issues, and naming-convention gaps.分析——标记字段级漂移、格式问题和命名规范差异。
• Interactive workflows – drives guided onboarding workflows through an AgentCore tool invocation framework.交互式工作流——通过 AgentCore 工具调用框架驱动引导式接入工作流。
• Readiness analysis – composes readiness narratives using Amazon Bedrock Knowledge Bases, the fully managed RAG capability in Amazon Bedrock.就绪状态分析——使用 Amazon Bedrock Knowledge Bases（Amazon Bedrock 中的全托管 RAG 功能）编写就绪状态叙述。

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.每个智能体都在有界的上下文窗口内运行。编排器的分类步骤有助于防止提示词稀释。映射请求不会与文档搜索竞争 Token 空间。这种分离使得系统能够扩展到新的任务类型，而不会降低现有智能体的准确性。

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.第 5 步：知识库检索——就绪状态分析是唯一一个从 Amazon Bedrock 知识库进行检索的专家智能体。这是一个经过深思熟虑的范围决策：其他智能体完全在应用程序层（第 3 步）进行基础数据处理，这使团队能够完全控制检索逻辑和排名。就绪状态分析是一个例外，因为它需要在一个庞大的 FDX 参考文档语料库中进行综合，而这些文档无法在单个请求中传递。这使得 RAG 成为该特定智能体的正确模式。

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.第 6 步：FDX 就绪状态评分——就绪状态评分是在应用程序代码中根据 OpenSearch 中的必填字段映射覆盖率确定性地计算出来的，而不是由模型估算的。与字段覆盖率挂钩的确定性计算能够以概率模型输出无法实现的方式满足审计要求。

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.第 7 步：可观测性——ECS 将按智能体的指标（调用次数、Token 使用量、延迟、成本）发送至 Amazon CloudWatch，CloudWatch 通过 Amazon Simple Notification Service (Amazon SNS) 发出警报，并为 Amazon Managed Grafana 仪表板提供数据。按智能体对指标进行维度划分，使团队能够发现单个智能体级别的回归问题，而不仅仅是将其视为系统范围的问题。

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.我们分五个重点冲刺阶段交付了 Compass，每个阶段都建立在前一个阶段的基础上。

Phase 1: AI application foundations阶段 1：人工智能应用程序基础

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.我们配置了核心基础设施：具有按租户索引的 Amazon OpenSearch Service、用于文档存储和知识库内容的 Amazon S3，以及管理专用工作负载、Bedrock 和共享服务账户堆栈的 AWS CloudFormation（使用 AWS Cloud Development Kit (AWS CDK)）。我们配置了具有按任务模型组合的 Amazon Bedrock AgentCore，并建立了用于工作负载与 AgentCore 之间通信的跨账户 IAM 角色。

Phase 2: Developer portal and onboarding automation阶段 2：开发者门户和接入自动化

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图 2：Compass 接入门户，银行开发人员使用该界面上传 API 并与人工智能智能体交互

Figure 3: The Compass onboarding dashboard, showing guided onboarding steps and progress for a bank图 3：Compass 接入仪表板，显示银行的引导式接入步骤和进度

Phase 3: AI deployment阶段 3：人工智能部署

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.我们在 Amazon Bedrock AgentCore 上部署了运行 Strands Agents 的主编排器和专家智能体，集成了租户级基础数据处理，并为就绪状态分析建立了 Amazon Bedrock 知识库。

Figure 4: The Compass knowledge base, where developers search documentation or ask questions and receive grounded answers图 4：Compass 知识库，开发人员可以在此搜索文档或提出问题，并获得有据可查的回答

Phase 4: Security hardening阶段 4：安全加固

Because Compass makes AI available to external partners, security hardening was a dedicated phase:由于 Compass 向外部合作伙伴提供人工智能服务，安全加固是一个专门的阶段：

• AWS WAF (WAFv2) with default-deny web ACLs for edge-layer traffic protection.带有默认拒绝 Web ACL 的 AWS WAF (WAFv2)，用于边缘层流量保护。
• OAuth2/OpenID Connect (OIDC) identity provider with MFA enforced.强制实施 MFA 的 OAuth2/OpenID Connect (OIDC) 身份提供商。
• AWS Secrets Manager with per-environment customer-managed AWS KMS keys.带有按环境客户托管 AWS KMS 密钥的 AWS Secrets Manager。
• Per-tenant data isolation across OpenSearch indices and S3 prefixes.跨 OpenSearch 索引和 S3 前缀的租户级数据隔离。
• 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.TLS 1.2+ (带 HSTS 的 Amazon CloudFront) 和 TLS 1.3 (内部负载均衡器)。用于静态数据的客户托管 KMS 密钥。

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.Compass 继续执行 Ninth Wave 既定的安全和合规实践，包括最小权限访问、静态和传输中加密，以及符合 SOC 2 和 PCI DSS 要求。

Phase 5: Beta launch阶段 5：Beta 版发布

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.我们于 2026 年 3 月 1 日将 Beta 客户接入实时应用程序。生产环境于 2026 年 5 月 15 日准备就绪，并于 2026 年 6 月 1 日正式全面可用。

Observability and CI/CD可观测性和 CI/CD

A multi-agent AI system requires observability at two levels: infrastructure health and agent behavior. Compass instruments both.多智能体人工智能系统需要在基础设施健康状况和智能体行为两个层面进行可观测性管理。Compass 对两者都进行了监测。

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.Amazon CloudWatch 监控基础设施：负载均衡器延迟、Amazon ECS 任务计数和 OpenSearch 集群健康状况。按环境划分的 Amazon SNS 主题将警报路由至值班团队。应用程序层自定义指标跟踪 Amazon Bedrock 调用次数、Token 使用量、延迟和成本，并按智能体进行维度划分。这种详细程度可以将问题隔离到单个智能体级别，而不仅仅是系统故障。

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.我们的持续集成和持续交付 (CI/CD) 流水线通过 GitHub Actions 运行。每次推送都会构建一个容器镜像，将其推送到 Amazon Elastic Container Registry (Amazon ECR)，注册一个新的 ECS 任务定义，并对 AWS Fargate 执行滚动部署，同时具备断路器回滚功能。断路器会自动还原未能通过健康检查的部署。当提示词或基础数据变更可能在指标反映出来之前影响智能体准确性时，这种保障措施至关重要。

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.借助 Amazon Bedrock AgentCore，Ninth Wave 通过自助服务、人工智能驱动的体验增强了其既定的接入流程。这种体验在整个集成过程中为银行、聚合器和金融科技合作伙伴提供了支持，同时提高了效率和响应速度。Compass 继续秉持 Ninth Wave 在安全、治理和金融服务合规方面的基本承诺。

Key outcomes:主要成果：

• 95 percent reduction in API mapping and analysis time – AI-enabled capabilities automate the process, improving efficiency and delivering results in minutes.API 映射和分析时间缩短 95%——人工智能驱动的功能实现了流程自动化，提高了效率，并在几分钟内交付结果。
• 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.扩展的自助服务支持——文档聊天机器人和 API Explorer 帮助外部开发人员快速获得集成问题的答案。
• 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.如今，该系统按智能体跟踪 Amazon Bedrock 调用量、Token 使用量、延迟和成本，并结合基础设施健康指标，使运营团队能够实时了解接入性能。

Figure 5: Compass conversational agent answering a bank developer’s integration question with a grounded response图 5：Compass 对话智能体正在用有据可查的回答解决银行开发人员的集成问题

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.在本文中，我们介绍了 Ninth Wave 如何构建 Compass，这是一个用于开放金融的多智能体人工智能接入系统。Ninth Wave 基于 Amazon Bedrock AgentCore 和 Strands Agents 编排框架构建了该系统，采用了按任务的模型组合、租户级基础数据处理以及企业级 AWS 安全基础。通过以自助服务人工智能体验增强其既定的接入流程，Ninth Wave 将 API 映射和分析时间缩短了 95%。

“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.”“人工智能从根本上改变了金融机构构建、集成和创新的方式，但这需要对底层基础设施的信任。Compass 代表了我们将智能、治理和自动化结合在一起的愿景——使银行能够更快地接入、降低运营复杂性，并为下一代人工智能驱动的金融服务构建所需的信任基础。”

— George Anderson, Founder and CEO of Ninth Wave—— George Anderson，Ninth Wave 创始人兼首席执行官

As a next step, explore the following resources:下一步，请探索以下资源：

• Get started with Amazon Bedrock AgentCore.开始使用 Amazon Bedrock AgentCore。
• Learn how to ground agent responses with Amazon Bedrock Knowledge Bases.了解如何使用 Amazon Bedrock 知识库为智能体响应提供基础数据。
• Read more about Agentic AI in Financial Services: Choosing the Right Pattern for Multi-Agent Systems.阅读更多关于金融服务中的智能体人工智能的内容：为多智能体系统选择正确的模式。
• Visit Ninth Wave Compass to learn more.访问 Ninth Wave Compass 了解更多信息。

About the authors关于作者