AI-native
AI-native Banking
Internet banking changed access for customers. Mobile and omnichannel changed convenience. Now, agents are changing the interface to money itself.
Each of the shifts above asked the same question of every bank: can your architecture adapt, or must it be replaced? Branch-based banks that treated the websites only as a peripheral addition struggled with internet banking. Those that treated web as their only real interface, and mobile as a peripheral addition, struggled in the app stores. For the same reason, banks that treat AI as a bolt-on to their web and mobile experience will struggle with agents.
Banks need a new perspective when adapting AI: not seeing it as an addition to their digital banking services, but as a fundamental architectural change. This is the only way they can be ready for the five levels of agentic banking.
The Five Levels of Agentic banking
- L1
Remove friction from digital journeys - L2
Conversational banking over real data - L3
Persistent financial memory and context - L4
Delegated actions with limits and approvals - L5
Proactive financial guidance and NBAs
Unless a platform’s architecture is AI-native, there will be a limit to how AI can be an interface for it. We can think about agentic banking as having levels. Without the right foundations supporting the climb, the upper levels will be out of reach. An agent that can only talk is a demonstration, not a service. Banking becomes useful when an agent is grounded in real data, real memory, and the ability to act on the customer's behalf. It helps to have a shared way of describing how far along that path a bank actually is. This ladder runs from removing friction to acting before the customer asks, and the distance between its levels depends on whether the architecture was built to support delegation at all. Here is what each level looks like for one customer, Sarah, opening a business account.
01. Friction removal
Sarah fills out an application. AI pre-fills what it can from her personal account and public records. Nothing is being decided yet; typing is simply being removed. Most banks are here.
02. Conversational discovery
Sarah stops comparing product tables and just describes what she needs: "$8k monthly revenue, need to separate business and personal, want a debit card, don't need checks." The right account tier surfaces itself. Only a few banks are here.
03. Financial memory
It is tax season. Sarah asks, "What do I need for my accountant?" The bank already knows her structure, her revenue pattern, and her categories, because that context persisted. She does not re-explain her business. Very few banks are here.
04. Delegated execution.
Sarah says, "Move 30% of every deposit to my tax savings account." It happens every time money arrives, inside limits she set once. Almost no bank does this consistently today.
05. Proactive anticipation
In March: "Based on your Q1 deposits, you're tracking 22% higher than last year. We've raised your tax savings transfer to 35% to avoid an underpayment penalty." The bank acts on the pattern before she asks. This doesn't exist anywhere yet.
Most banks sit at Level 1 or 2. They won’t reach 4 and 5 by having a better agent. Climbing to the higher levels depends on something else: whether the bank has journeys and data that were designed for delegation before delegation was ever asked for.
This is what the Plumery’s digital banking development platform has at its origin: an architecture that has always enabled banks to be AI-native, for all five levels of agentic banking.
A foundation layer for the agentic banking era
Plumery wasn’t retrofitted for AI. It was designed around journeys, data and rules rather than screens viewed by humans. That is also what an agent needs. So when agents arrived as a new way to reach the bank, there was nothing to pivot. The work of making banking legible to something that isn't a human clicking a mouse or tapping a phone screen was already done.
From day one, a journey in Plumery is defined once and rendered wherever it is needed: a web app, a mobile app, an open banking partner. None of those channels are wired into the legacy core directly. They are surfaces over a common foundation. It is a headless platform, separating what a bank does from where it is experienced by a customer.
An agent is simply the newest surface over the same journeys, one that calls a capability instead of tapping a button.
No AI feature was added to accomplish this. It is the architecture we started with.
The right ingredients for AI are in the architecture
AI-native architecture is built with a different set of ingredients to what most platforms are made with. It is not simply a chatbot or agent bolted onto a core that was never designed to be acted on (although this is what most vendors speak of when they talk about “AI in banking”). The fundamental ingredients a platform needs to be AI-native are the same ones that made it multi-channel in the first place.
Headless and API-first.
Every journey, every piece of data, every rule is available through an interface, not locked inside a visual screen. With these ingredients, a channel is not a product; it is one more consumer of the same foundation. Web, mobile, open banking, and agents are all front ends over one set of capabilities.
Great DevEx and AgentEx.
As agents write more software, a platform needs to be as legible to an agent as it is to a developer. The same journeys, data, and rules a developer builds against are the ones an agent can discover, reason over, and extend. Developer experience and agent experience are now the same investment.
Journeys as reusable capabilities
Onboarding, servicing, lending, and payments are defined once as callable capabilities, rather than rebuilt for each channel. The journey a customer taps through on mobile is the exact one an agent calls, with the same logic and data behind it.
Ownership
SaaS and white-label hand a bank someone else's product with its logo on it: fast to launch, hard to truly control. To be AI-native, the bank should keep control of the code, the journeys, and the roadmap. Now that agents increasingly build software, controlling the platform they build on is the difference between compounding an asset and renting one.
For Plumery, these ingredients enable AI to become a new entry layer
Agents are becoming a new storefront for banking. A customer's own AI assistant, an in-app copilot, a partner's agent: each is a new way in, and each expects to act rather than simply offer information.
The AI-native Engagement Layer is where that happens with Plumery. It exposes the bank's existing journeys as capabilities an agent can call, while the web and mobile flows of those journeys keep running unchanged. Nothing is rebuilt for agents. The same foundation gains one more front end.
Underneath it sits a customer-context layer, a source of truth for who the customer is and what they have done, so that an agent acts on real accounts and persistent memory rather than a fresh guess each session. And because the model best suited to the job today will not be the best in two years, the bank stays free to bring whichever models and agents it trusts, reaching the bank's capabilities through open MCP and CLI tools rather than a wrapper it cannot swap out.
The Structural Advantage
AI raises the bar on correctness. When a coding agent can compress months of delivery into days, the value moves to the architecture underneath it, because in banking the output must still be auditable, tested, and correct enough to ship. Clean, headless architecture is what lets agents move quickly without leaving the bank a mess it cannot maintain.
That is the job of the AI Workbench, the builder-facing half, delivered as a platform (PaaS) rather than a product (SaaS). It sits on a banking-grade Internal Developer Platform (IDP): the golden paths, templates, pipelines, and environments a bank would otherwise spend years assembling, offered as a service so teams build on day one instead of building the thing they build on. Because software is increasingly written by agents, that IDP is designed for two audiences at once: a great developer experience (DevEx) and an equally deliberate agent experience (AgentEx). The same paved roads a person follows are the ones an agent discovers and follows too.
It is where both product people and engineers turn intent into shippable banking software: specs, plans, previews, tests, and reviewer-ready evidence in one place instead of scattered across tools. It starts by assisting the work and is built to evolve toward agentic delivery, where more of the building is done by agents. Those agents run through an omni-harness that puts Claude Code, Codex, or your custom built coding agents behind one workflow, and the human's role becomes steering and approval rather than typing. None of it requires a replatform or a core replacement.
One platform, a few clear layers the bank owns, each exposed through open interfaces so that people and agents reach them the same way:
 Layer |  What it is |  How it’s reached |
|---|---|---|
| Experience | Headless journeys delivered across web, mobile, and open banking | SDKs for web & mobile, REST APIs, design system |
| Agent Tools | MCP and CLI tools that let agents discover and call the bank's capabilities | MCP servers, CLI, agent API |
| Journeys | Onboarding, servicing, lending, and payments as reusable, callable capabilities defined once | Journey API, OpenAPI catalog, Webhooks/Events |
| Customer Context | A persistent source of truth so agents act on real accounts and real memory | Data Mesh API, event streams, Digital Twin |
| PaaS & Workbench | Assisted today, agentic tomorrow: the DevEx + AgentEx platform the bank and its agents build on | Omni-harness (Claude Code, Codex, Custom agents,..), IDP golden paths, CLI, SDK, CI/CD |
The next generation of banking will not be agents bolted onto a legacy core. It will be architecture.
FAQ
What does "AI-native" actually mean for a bank?
An AI-native platform exposes a bank's customer journeys as reusable capabilities that any AI agent can use.
Some banking platforms may claim to be AI-native because they are connected to a large language model. That is not the same thing as being architecturally ready for AI.
To be genuinely ready, a bank needs a platform that does not need to be redesigned when a bank wants to shift from entry level AI capabilities, like friction removal and information retrieval, to more developed AI capabilities, such as the ability to execute tasks on behalf of the customer.
How can banks use AI to improve customer engagement?
AI can improve customer engagement by removing friction, automating tasks for customers, providing personalised financial guidance, and helping customers discover the right products based on their context.
Exactly what AI can do will depend on the underlying architecture of a digital banking platform, for instance, whether AI can recommend savings products based on a customer's description of what they need, or based on the customer's accounts and activity, or whether it can set up regular deposits at the customer's request.
A platform's architecture will determine how much an agent can know about a customer, how many banking journeys an agent can perform on behalf of that customer, and whether it can take initiative to act independently (and responsibly) in that customer's best interest.
How does Plumery support responsible AI?
Responsible AI is primarily supported by architecture. Plumery's platform exposes the same journeys a customer accesses through web and mobile, so each journey has the usual in-built measures for security, audit, authorisation and compliance, regardless of whether an agent is calling a journey or a customer is navigating it manually.
So opening an account, making a payment or applying for a loan should follow exactly the same rules regardless of whether the request comes from a mobile app, a relationship manager or an AI assistant.
Plumery also allows for AI to be informed by a customer context layer, with an event-driven data mesh that ensures every transaction, balance, and customer event streams in real time, giving any AI agent live context instead of stale batch data.
Regarding AI-assisted and agentic building of banking services, Plumery offers an SDLC that has access to all our knowledge and best practices for architecture. This ensures your developers and agents are not only building fast, but building reliably.
How should banks approach AI adoption?
Many banks may begin AI adoption with isolated AI tools: a chatbot for customers, a coding assistant for developers, and so on.
Those initiatives can create value, but they are early steps, and they don’t progress the bank meaningfully towards a more agentic platform.
The longer-term opportunity is created when you have architecture that allows any new AI capabilities to be adopted. This is possible when you have a platform designed around reusable journeys and customer context that allows banks to change AI models and provide them with greater scope to act on behalf of the customer, without rebuilding the foundational digital banking experience each time.
Plumery’s platform is MCP-compatible, so you’ll always be able to use any model or agent – even the ones that aren’t yet on the market.