Europe’s bunq has built one of the deepest production deployments of agentic AI in retail banking, even if you haven’t heard of the neobank. 

That may be about to change. Netherlands-based bunq, founded in 2012, is ambitious. It already has 20 million users across Europe and plans to expand into the United States and Mexico.

bunq describes itself as “the world’s first GenAI-powered bank.”

That’s a big claim, but it’s built on strong foundations. Its user service agent Finn handles 97% of user interactions, and autonomously resolves 87% of user queries; maintaining a striking 90% user approval rating. 

How did it do it and what does it look like under the hood? Who better to ask than bunq’s Benjamin Kleppe, who wrote Finn’s first lines of code. 

The Stack’s Kiera Fields joined the bank’s machine learning engineering lead at AWS’s airy Amsterdam headquarters, to unpack Finn’s ongoing evolution. 

We unpacked the re-engineering of bunq’s platform, how it tackled escalating token costs; built a hub-and-spoke multi-agent framework; its database decisions across a highly disciplined AWS foundation, and more. 

Rebuilt from scratch three times

Delivering Finn has been an intense iterative journey, Kleppe told The Stack: “We have actually rebuilt Finn’s architecture from scratch three times.”

bunq started small with its initial sandbox, with the aim of solving repetitive support tasks. It was, he explained, an isolated layer hosted as Python containers on Amazon ECS, sitting on top of bunq’s existing infrastructure. 

It brought bunq’s automation rate to roughly 30% and proved the value, but a prototype sitting on the periphery will always hit a wall in user experience.

His team then moved Finn closer to the application layer. It was still external but could now call core backend APIs directly. This pushed automation rates much higher, but bunq hit a ceiling regarding security and deep context. 

He says “We excluded certain actions to keep our users safe” – but that meant the AI couldn't fully close the loop on complex requests.

The bank then made a massive architectural shift. 

It migrated Finn’s multiagent logic out of the external Python environment and embedded it directly into bunq’s core banking backend, which runs primarily on PHP. Finn now lives natively in the exact same environment where financial transactions are validated: “Finn can now also carry out actions in your name, and Finn can authenticate as you whilst you are talking to it, so it can access exactly the same data as you can at that point” he says.

“We’re very aligned culturally”

Transitioning a multi-agent Python microservices architecture into a monolithic PHP backend sounds like a significant engineering lift.

Kleppe told The Stack that it took about three months. He says the bank paired its machine learning engineers directly with core backend engineers, QA, and product owners to get a joined-up approach: “We're all very aligned culturally. By working very well together, this was done very fast.”

Perhaps counter-intuitively, working in a heavily regulated space helps, he said: “We map out what we can and cannot do, and our engineers work very fast with our compliance and legal teams, [who] also work really fast.

“By involving all these departments at the start of the process, you can just move way faster. As with any other application, we really try to define the scope of what it can and cannot do, get our approvals for that part of the application, and then once we see very high accuracy rates,  then we can make a point to further expand the control of these applications…”

An MVC pattern and AWS everything!

bunq anchors its core infrastructure entirely within AWS. 

Several years ago it migrated off a legacy self-hosted MySQL instance to Amazon Aurora to manage its relational transactional and user data. 

Compute operations are handled via Amazon EC2 and ECS, while Amazon OpenSearch provides the vector similarity search infrastructure required to index and retrieve data from the bank's internal knowledge bases. 

The platform routes system logs and event data through an analytics and monitoring suite comprising Amazon Redshift, Athena, and CloudWatch. 

This foundational data layer ensures that high-volume financial transactions remain decoupled from, yet instantly accessible to, the bank’s broader automated machine learning pipelines, Kleppe explains. 

A multiagent framework

To scale its generative AI platform, Finn, from an isolated customer-facing chat tool into an integrated backend system, bunq relies on Amazon Bedrock for managed model inference – and structured an “Agent-as-a-Tool” architecture on it to mitigate latency headaches and escalating token costs.

“We went through a whole bunch of optimisations in terms of cost earlier this year,” he says, “costs were exponentially growing, which was getting in the way of our scalability, but we got it very well under control at the moment.

"Fixes included things like heavy serialisation, and also surprisingly, introducing the concept of sub agents really helped both with quality of responses, suppressing the cost and also making it even faster to answer.”

Its multiagent framework now uses a large model like Claude Opus, as a central orchestrator to manage conversation state and high-level logic.

It then delegates  narrow operational tasks to smaller, more cost-effective sub-agents like Claude Sonnet.

Aurora and OpenSearch

Supported by AWS-backed open-source project Valkey for asynchronous task queuing and short-lived memory storage, this setup allows specialized sub-agents to operate their own tasks.

Such as?

“For example, a research agent can find a missing payment. To find [one]  you have to look through a ton of data, which is all bloating the context…”

In short, bunq’s orchestrator model spins up a sub-agent like this which is designed exclusively to query Amazon Aurora, skim monetary accounts, parse card registries, and run vector similarity searches via Amazon OpenSearch, where the bank’s internal knowledge base is indexed. 

The sub-agent isolates the missing transaction, distills the finding down to a clean, highly synthesised snippet, and passes only that relevant context back to the Orchestrator. The Orchestrator then reviews the snippet and delivers a natural response to the user. 

More broadly, the system architecture relies on a highly scalable, clean Model-View-Controller (MVC) pattern originally laid down by its CEO. 

By keeping coding standards incredibly strict and prioritising a clear separation of concerns, bunq can continuously layer new machine learning models directly into the backend environment where user transactions live.

Fresh iterations coming regularly

bunq continues to iterate. It just launched a new version of Finn internally that is moving directly into its engineering cycles too, with an “end-to-end feedback loop.”

For example, when a user flags a bug in production, Finn handles the initial intake, requests clarifying screenshots from the user, and validates the error against bunq’s log infrastructure. The bank is approaching a phase where Finn locates the source of the bug in the codebase, writes the necessary patch, runs automated QA testing, and submits the proposed fix directly to its developers as a pull request.

Auditability of agent behavior is critical, he says.

Kleppe explains: “We want every action by the agents to be traced, but also we want to make sure that we know who triggered the agent at what time. What did this agent do? What tools did it use? Did it change anything? 

There’s still improvements to make but Kleppe is excited by the capabilities emerging in AI every week. Meanwhile, bunq’s underlying structural elasticity and standardised AWS architecture means it can create new regional instances automatically that inherit the bank's native security frameworks, automated audit trails, and multi-language support structures without requiring code migrations or foundational re-engineering. 

Who said Europe’s not innovating?

Delivered in partnership with AWS.

The link has been copied!