Open finance onboarding is a grind of field mapping, API validation, and readiness scoring. Banks expose APIs with their own naming and gaps relative to the FDX standard, so every integration means weeks of specialist work. Ninth Wave built Compass, an AI assistant on Amazon Bedrock AgentCore, to turn that into a self-service portal where bank engineers and fintech partners collaborate in a shared workspace.
Why a single agent wasn’t enough
The team evaluated self-hosted models on EC2 and a single-agent RAG pattern. Self-hosting gave control but added overhead; a single agent was simpler but less accurate across mapping, analysis, search, and Q&A. The multi-agent route is more complex upfront, but each specialist keeps its own context and prompt. No competing for token space, and accuracy scales with task types.
Three design decisions matter here. Intent-based routing classifies once and sends the request to the right specialist. Per-task model selection matches lightweight models to high-volume tasks and higher-reasoning models to mapping and analysis. Tenant-scoped grounding assembles each bank’s own context before an agent runs, so one bank’s data never leaks into another’s session.
The architecture in practice
Compass runs seven specialist agents behind a primary orchestrator built on the Strands Agents framework. Search ranks portal docs, documentation Q&A answers grounded questions, document classification sorts uploads, field mapping aligns FDX fields to the bank’s API, analysis flags drift and formatting gaps, interactive workflows drive guided onboarding, and readiness analysis composes narratives using Amazon Bedrock Knowledge Bases.
Only readiness analysis uses RAG retrieval. The other six agents are grounded at the application layer, which gives the team full control over retrieval logic and ranking. Readiness analysis needs to synthesize across a corpus of FDX reference documents too large for a single request, so RAG fits there specifically.
The readiness score itself is computed deterministically in application code from field mapping coverage, not estimated by a model. That satisfies audit requirements in a way a probabilistic output cannot.
Security and observability as first-class concerns
Compass serves external bank developers and internal users on the same application, so every request is scoped to a single tenant before it reaches logic. Traffic passes through CloudFront and AWS WAF, then an internal load balancer. ECS on Fargate validates sessions against an OAuth2/OIDC provider with MFA, and the tenant identity flows downstream to scope every data query.
AI workloads run in a separate AWS account via a cross-account IAM role, which contains blast radius. Per-agent metrics go to CloudWatch, with alerts through SNS and dashboards in Managed Grafana. Dimensioning by agent lets the team spot regressions at the individual agent level rather than only system-wide.
What this means for builders
The pattern here is not “add an AI chatbot to onboarding.” It’s a deliberate split: deterministic scoring for auditability, RAG only where a corpus is too large to pass inline, and tenant-scoped grounding as a hard boundary. That’s a useful template for any regulated workflow where multiple parties share model infrastructure.
For teams thinking about agent orchestration, the tradeoff is real. Multi-agent systems cost more to build and operate than a single RAG endpoint. But when task types have different accuracy requirements and context windows are finite, separation pays off. The same logic applies to execution models for process orchestration: how much you can trust the orchestrator depends on how cleanly you’ve bounded what each component does.
The five-sprint delivery shows this doesn’t have to be a big-bang rewrite. Foundations first, then portal and automation, then agent integration, then hardening, then production rollout. Each phase built on the last without waiting for a perfect architecture.
Sources
AI-assisted summary compiled from the sources above, reviewed by a human before publishing.