Multi-Agent AI Banking Assistant Using Amazon Bedrock

bunq · Finance · 2026 · source Agentic: yes · promotional bias: high · source-backed · extracted with prompt 0.5.6 (schema v2)

Generated from extraction.json — do not edit by hand. Every claim cites verbatim source evidence; stated means the quote directly asserts the claim, implied means it supports it indirectly.

Problem

Domain: Banking customer support and financial-services operations

bunq needed to provide instant, multilingual, round-the-clock banking support and operational automation for 20 million users while preserving security, privacy, regulatory controls, and response quality across transaction disputes, account management, financial advice, bug reports, and feature requests.

Constraints:

• The system operates in a regulated banking environment with strict security, privacy, and compliance requirements.
• Users expect instant support across languages, time zones, mobile app surfaces, web interfaces, and support-call channels.
• The assistant must access only data relevant to each request rather than exposing broad customer or banking context.
• The architecture must support specialized banking tasks such as transaction analysis, account operations, document recognition, and multilingual support.
• The team needed rapid iteration while serving a production user base measured in tens of millions.

Architecture

bunq built Finn as an in-house multi-agent banking assistant on Amazon Bedrock, Claude models, Amazon ECS, DynamoDB, OpenSearch Serverless, S3, MemoryDB, CloudFront, WAF, CloudTrail, GuardDuty, CloudWatch, and SageMaker-hosted fine-tuned models. The system moved from a central router to an orchestrator pattern: three to five primary containerized agents handle user requests and dynamically call specialized agents as tools for transaction analysis, documentation retrieval, account operations, and complex query processing. RAG over OpenSearch grounds answers in bunq knowledge, DynamoDB and MemoryDB maintain conversation/session context, and AWS security/observability services protect and monitor the banking workload.

Diagram confidence: explicit (topology described by the source).

flowchart LR
  App["bunq app and web interface"] --> Edge["AWS WAF and CloudFront"]
  Edge --> Identity["bunq identity system"]
  Identity --> Orchestrator["Finn orchestrator"]
  Edge --> Orchestrator
  Orchestrator --> Primary["Primary agents"]
  Orchestrator --> Bedrock["Amazon Bedrock Claude models"]
  Primary --> Tools["Specialized tool agents"]
  Primary --> Bedrock
  Primary --> Dynamo["DynamoDB conversation memory"]
  Primary --> Memory["MemoryDB session store"]
  Primary --> Search["OpenSearch RAG store"]
  Tools --> Search
  Tools --> S3["S3 document storage"]
  Tools --> SageMaker["SageMaker fine-tuned models"]
  Tools --> Bedrock
  Orchestrator --> Observe["Observability and security stack"]
  Primary --> Observe
  Tools --> Observe
  S3 --> Search

Components

Data flow

A bunq user submits a natural-language request through the app or web interface. CloudFront and WAF secure traffic, bunq's identity system authenticates the user, and the Finn orchestrator running on ECS receives the request. The orchestrator sends work to a small set of primary agents, which invoke specialized tool agents when the request needs transaction analysis, documentation retrieval, account operations, or other domain-specific help. The agents call Claude through Bedrock, use OpenSearch Serverless for RAG over bunq knowledge, rely on DynamoDB and MemoryDB for conversation and session context, and write operational/security traces through CloudTrail, GuardDuty, and CloudWatch.

Why this architecture

bunq chose a managed AWS, multi-agent, agent-as-tool architecture because the original router pattern became hard to maintain as support domains and agent capabilities overlapped. Limiting orchestration to a few primary agents while allowing those agents to call specialized tool agents reduces central routing complexity, avoids a single router bottleneck, and preserves flexibility as new banking capabilities are added. Managed services also let the team focus on Finn's agent logic rather than model serving, container orchestration, vector-search scaling, and security monitoring.

Models used: Anthropic Claude models through Amazon Bedrock · Amazon SageMaker hosted fine-tuned models · Amazon OpenSearch Serverless vector search · Image recognition models or capabilities for receipt and document processing

Scale

• bunq serves 20 million users across Europe.
  “The company helps its 20 million users across Europe spend, save, budget, and invest confidently”article, stated
• Finn translates the bunq application into 38 languages.
  “Finn can translate the bunq application into 38 languages and translate speech-to-speech calls to the support team in real time.”article, stated
• The orchestrator keeps the primary-agent surface to three to five agents.
  “Routes queries to only three to five primary agents”article, stated
• The production rollout moved from concept to production in 3 months.
  “The team moved from concept to production in 3 months, starting in January 2025.”article, stated
• The launch team involved 80 people and deployed updates three times a day during initial rollout.
  “bunq brought together a team of 80 people—from AI engineers to support staff—who worked together to test, learn, and deploy updates three times a day.”article, stated
• Finn handles 97% of user-support activity, with the source reporting automation at over 82% in one bullet and 70% in another quoted outcome.
  “Finn now handles 97% of bunq’s user support activity, with over 82% fully automated. Average response times dropped to just 47 seconds”article, stated

  “Now Finn handles 97% of support with 70% fully automated and 47-second average response times.”article, stated

Alternatives considered (roads not taken)

Central router agent that sends each user query directly to a specialized sub-agent

Rejected because: The router became increasingly complex, had to predict overlapping downstream capability needs, and became a single point of failure and development bottleneck as new agents were added.

Route every possible support scenario from the orchestrator

Rejected because: bunq instead routes only to a small number of primary agents and lets those agents invoke specialized tool agents when context requires it.

Rely only on a foundation model for banking responses

Rejected because: The architecture combines Claude through Bedrock with RAG and SageMaker-hosted fine-tuned models to cover knowledge grounding and specialized banking scenarios.

Operate self-managed vector-search capacity for retrieval

Rejected because: OpenSearch Serverless automatically scales compute resources and removes search-cluster capacity management from the Finn team.

Patterns

multi-agent-orchestration (architecture)

Finn uses a hierarchical multi-agent architecture in which an orchestrator routes to a small set of primary agents and those agents dynamically invoke specialized agents as tools.

tool-use-orchestration (architecture)

Specialized banking agents are exposed as callable tools that primary agents invoke through a defined interface when they need a particular capability.

rag-retrieval (knowledge)

Finn uses OpenSearch Serverless as a vector store so agents can semantically retrieve bunq knowledge-base content before responding.

agent-memory (state)

The assistant stores conversation history and session data across DynamoDB and MemoryDB so agents can maintain context during customer interactions.

safety-policy-enforcement (governance)

The banking assistant is wrapped in security, privacy, identity, WAF, VPC, audit, threat-detection, and compliance controls rather than being allowed broad data access.

observability-tracing (operations)

Finn uses CloudTrail, GuardDuty, and CloudWatch as the monitoring, threat-detection, audit, and compliance visibility layer for the production AI system.

Tradeoffs

How to scale multi-agent routing as banking domains and capabilities expanded.

Chose A small-orchestrator plus agent-as-tool hierarchy. over A central router that directly maps every request to specialized sub-agents..

Rationale: The orchestrator reduces the central routing surface while letting domain agents make context-aware calls to specialized capabilities.

How much infrastructure to operate directly versus consume as managed services.

Chose AWS managed services for model access, container orchestration, vector search, memory, session management, monitoring, and security. over Self-managing model-serving, orchestration clusters, and search-scaling infrastructure..

Rationale: The article frames ECS, Bedrock, DynamoDB, and OpenSearch Serverless as ways to reduce operational overhead and let bunq focus on Finn's agent architecture.

How to keep customer conversations responsive while retaining durable context.

Chose A split state layer: DynamoDB for agent memory/history and MemoryDB for real-time sessions. over A single undifferentiated persistence layer for both active sessions and durable conversation memory..

Rationale: The architecture separates persistent conversation history from real-time session management, implying different latency and durability needs.

How to balance general foundation-model reasoning with domain-specific banking behavior.

Chose Claude through Bedrock plus SageMaker-hosted fine-tuned models for specialized banking scenarios. over Only using general-purpose foundation-model calls for every banking support task..

Rationale: The combined architecture lets general language understanding handle broad requests while preserving specialist models for banking-specific scenarios.

Gotchas (what bit them)

A central router became increasingly difficult to maintain as the number of specialized banking agents grew.

Root cause: The router had to encode more destination logic and retesting every path became expensive whenever new agents or capabilities were added.

Resolution: bunq replaced all-scenario routing with an orchestrator that dispatches to a small set of primary agents and lets those agents call specialized agents as tools.

Specialized-agent capabilities overlapped, so the router could not reliably know all downstream capabilities needed for a request.

Root cause: Multiple agents needed access to the same data sources and secondary capabilities, making primary-intent classification insufficient.

Resolution: Primary agents were empowered to decide when they needed specialized help and invoke tool agents dynamically.

Banking agents cannot answer by freely browsing all available customer or bank data.

Root cause: Financial-services support combines privacy, security, compliance, identity, and least-privilege data-access constraints.

Resolution: Finn processes only pertinent request data and sits behind identity, WAF, CloudFront, VPC, threat-detection, audit, and monitoring controls.

The source reports headline automation metrics but gives limited detail about AI-specific quality evaluation, rollback, hallucination handling, or user-satisfaction measurement.

Root cause: The article is an AWS/bunq success story focused on architecture and business outcomes rather than a full postmortem of operational controls.

Resolution: Treat the automation and latency metrics as reported outcomes while preserving the missing-evaluation caveat in downstream synthesis.

Evaluation

The article evaluates Finn through operational support metrics, deployment cadence, automation share, response time, language coverage, and user-support volume. It does not describe a formal offline model-evaluation harness, hallucination benchmark, or banking-risk acceptance process.

Metrics: 97% of user-support activity handled by Finn · Over 82% fully automated in one impact bullet · 70% fully automated in the quoted outcome and conclusion · 47-second average response time · 38 languages · 3-month concept-to-production timeline · 80-person cross-functional rollout team · Three deployments per day during rollout

Outcomes

• Finn now handles most user-support activity and a large majority of support interactions are reported as fully automated.
• Average response time dropped to 47 seconds.
• bunq expanded support and application access across 38 languages.
• The assistant added real-time speech-to-speech translation, image recognition for receipts/documents, and financial-insight capabilities.
• The router-to-orchestrator migration turned manual escalations into a more automated multi-agent support path.

The source reports a production banking system serving 20 million users across Europe, with Finn handling 97% of support activity, 47-second average response times, 38-language application translation, and a 3-month concept-to-production rollout by an 80-person team.