loading
loading
Artificial Intelligence How Ninth Wave built AI-powered open finance onboarding on 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. 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. 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. 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. 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. 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: - Get started with Amazon Bedrock AgentCore. - Learn how to ground agent responses with Amazon Bedrock Knowledge Bases. - Read more about Agentic AI in Financial Services: Choosing the Right Pattern for Multi-Agent Systems. - Visit Ninth Wave Compass to learn more.
Artificial Intelligence How Ninth Wave built AI-powered open finance onboarding on 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. 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. 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. 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. 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)
document fetched 2026-09-15 02:50 · canonical https://aws.amazon.com/blogs/machine-learning/how-ninth-wave-built-ai-powered-open-finance-onboarding-on-amazon-bedrock