How Ninth Wave’s Compass uses multi‑agent AI on Bedrock to speed up open‑finance onboarding
According to Artificial Intelligence, Ninth Wave launched Compass, an AI‑enabled onboarding assistant built on Amazon Bedrock AgentCore, to automate the messy process of connecting bank APIs to the open‑finance network. The move matters because banks traditionally spend weeks mapping their proprietary API fields to the Financial Data Exchange (FDX) standard, a bottleneck that slows product rollout for fintech partners.
What Compass does for open‑finance onboarding
Compass sits behind a self‑service portal used by bank engineers, aggregator teams, and Ninth Wave’s own onboarding staff. Its primary job is to take a bank’s API specification, validate it against FDX, suggest field mappings, flag format gaps, and generate a readiness score that can be audited. All of this happens while keeping each bank’s data isolated from every other tenant. The portal also lets users ask natural‑language questions about the documentation, run searches, and follow guided workflows that drive the onboarding steps to completion.
How the multi‑agent architecture works
The system follows a classic intent‑based routing pattern. An orchestrator first classifies a user request – search, field‑mapping, document classification, etc. – and then hands the request off to a specialist agent that has a dedicated prompt and a clean context window. Because each agent only sees the tokens needed for its task, there is no competition for prompt space and the output stays predictable. Before an agent runs, a “tenant‑scoped grounding” step pulls the bank’s own API docs, prior interactions, and configuration data from per‑tenant Amazon OpenSearch indices and S3 prefixes, then injects that into the request. This guarantees that one bank’s information never leaks into another bank’s session, even though all agents share the same underlying model infrastructure.
The specialist agents cover:
- Search across portal docs
- Documentation Q&A grounded in Compass and FDX docs
- Automatic classification of uploaded files
- Field‑mapping between bank API fields and FDX
- Analysis of drift, formatting, and naming gaps
- Interactive workflow driving
- Readiness analysis that pulls from a Bedrock knowledge base (the only RAG‑style agent)
Readiness scores are not guessed by a model; they are computed deterministically from field‑coverage metrics stored in OpenSearch, which satisfies audit requirements that a probabilistic output cannot meet.
Why Ninth Wave chose multi‑agent over single‑agent or self‑hosted models
The team evaluated three options:
| Approach | Control | Operational overhead | Accuracy for mapping & analysis |
|---|---|---|---|
| Self‑hosted models on EC2 | Full (you own the hardware and model) | High – you must manage scaling, security patches, and GPU costs | Variable – depends on how you tune prompts and manage context |
| Single‑agent Retrieval‑Augmented Generation (RAG) | Moderate – you control the single prompt and retrieval pipeline | Low – simpler wiring, but one prompt must handle every task | Lower – the prompt must juggle search, mapping, Q&A, which leads to token dilution and poorer results |
| Multi‑agent Bedrock AgentCore (Compass) | Managed – Bedrock supplies the runtime and model selection per task | Moderate – you configure orchestration and per‑task models, but Bedrock handles scaling and security | Higher – each specialist stays within a bounded context, so token usage is efficient and accuracy scales with the number of agents |
Self‑hosting gave the team absolute control but required a dedicated team to patch OS, manage GPU fleets, and enforce encryption across accounts. A single‑agent RAG pattern was attractive for its simplicity but performed poorly on the nuanced field‑mapping and analysis steps, where the model had to keep track of many technical terms. The multi‑agent design required more upfront work – defining intents, writing seven specialist prompts, and wiring the orchestration – but it let Ninth Wave match lightweight models to high‑volume tasks and reserve larger reasoning models for the handful of complex steps. Amazon Bedrock AgentCore supplied a managed runtime, IAM‑based isolation, and built‑in observability, which let the team focus on domain logic instead of LLM ops.
What the trade‑offs really mean for banks and fintech partners
The headline is that banks can now get a readiness narrative in days rather than weeks, but the benefit comes with a few caveats. First, the system still relies on a set of pre‑selected models that Bedrock makes available in each AWS region; if a bank’s data residency requirement forces them into a region without the needed model, they would need to fall back to a less capable option. Second, the per‑tenant grounding step pulls the bank’s documentation into the request each time, so large API specs can increase token usage and cost – the team monitors token counts per agent in CloudWatch, but cost spikes are possible during bulk uploads. Third, the deterministic readiness score is transparent, yet it only reflects field‑coverage; deeper semantic gaps that a model might flag are left to the analyst’s judgment. Finally, because the agents are managed by Bedrock, banks are dependent on AWS’s service‑level agreements and the continuity of the specific models used; a model deprecation would require a re‑training of the specialist prompts.
For fintech partners, the biggest win is a consistent, self‑service experience. They no longer need to chase down bank contacts for field‑by‑field clarification; the portal’s Q&A agent can answer “What does this error code mean?” in real time, grounded in the bank’s own docs. However, partners must still handle authentication via OAuth2/OIDC with MFA, and they need to respect the tenant isolation – a shared login cannot be used across multiple banks without proper scoping.
A quick test you can run today
If you have access to an AWS account with Bedrock enabled, try reproducing a tiny slice of Compass:
- Create a simple OpenSearch index and upload a mock bank API spec (a few JSON fields).
- Spin up a Bedrock AgentCore runtime and define two agents – one for search and one for field‑mapping – using the
anthropic.claude-v2model for search andmeta.llama-2-13b-chatfor mapping. - Write an intent classifier that looks for the keywords “search” or “map”.
- Invoke the orchestrator with a request like “Map the field
acct_balanceto the FDX equivalent.” The grounding step should fetch your mock spec from OpenSearch and pass it to the mapping agent. - Observe the token usage and latency in CloudWatch; compare it to a single‑agent RAG call that tries to do both search and mapping in one prompt. You’ll see the multi‑agent call stays within a tighter token budget and returns a cleaner answer.
Running this mini‑setup gives you a feel for how intent routing and tenant‑scoped grounding keep the context small and the output reliable – the same principles that let Ninth Wave cut onboarding weeks down to days.
