Trend lists for banking apps tend to read the same way: agentic AI, digital identity wallets, tokenised assets, post-quantum cryptography, and on down the page. The list is accurate and not very useful, because it treats each item as a separate project.
The more useful observation for 2026 is that several of these pressures land on the same part of the stack at the same time. A new kind of AI actor, a European identity regulation with a hard 2027 deadline, and an operational resilience law in force since January 2025 all touch the API layer, the identity layer and the deployment pipeline. A team that runs them as three separate workstreams usually ends up building three separate solutions to one underlying problem.
The sections below group the work the way the architecture groups it: the AI and identity layer first, then resilience and tokenisation, then the order we would put them in.
Agentic AI and digital identity: what banks are actually building
It is easy to scope agentic AI as a smarter chatbot. In a banking app the real difference is architectural, and it shows up in the parts of the system that are hardest to change.
How autonomous agents change banking app architecture
An autonomous agent does not wait for input. It can initiate a payment, run a compliance check, flag a transaction and escalate to a human reviewer inside a single workflow, with no one touching the screen. That capability lives below the interface, in the systems most banking stacks find hardest to change, which is why it behaves less like a feature and more like a new part of the platform.
The first problem is identity. Every agent inside a banking system needs its own authenticated identity, now often called a non-human identity, or NHI, with its own access controls, audit logs, session limits and revocation path. Most banking stacks were built around human users and human sessions, so this is rarely a small addition.
The second problem is accountability. When an agent approves a transaction, blocks an account or triggers an alert, there has to be a record of what it did, why, and on what data. Regulators will expect that explanation, and an audit trail added after the fact is costly and usually incomplete, so it is cheaper to design it in from the first agent.
A workable governance layer for agentic AI comes down to three things:
- a “know your agent” control that authenticates and monitors every non-human identity in the system
- human-in-the-loop thresholds that set when an agent must stop and escalate instead of acting
- a decision audit trail that is queryable, tamper-evident and available to compliance
The banks that avoid two years of retrofitting are the ones scoping this as an infrastructure change now, while the agent count is still low and the governance layer is cheap to add. It is where our AI and machine learning work usually starts: the identity, audit and escalation layer that has to sit around the model.
Putting an agent into a banking workflow?
We help banking and fintech teams design the governance layer first – non-human identity, human-in-the-loop thresholds and a decision audit trail – so agentic features ship without a compliance retrofit later.
eIDAS 2.0 and what banks must build before the 2027 deadline
The European Digital Identity Wallet (EUDIW) now has dates attached. Under eIDAS 2.0 (EU Regulation 2024/
The wallet does not behave like a document upload, which is the part that catches onboarding teams. It uses attribute-based credentials: the user shares only the data points a check needs – date of birth, nationality, proof of address – without handing over the whole document. This selective disclosure is better for privacy and structurally different from what most mobile banking apps were built to handle. Adapting an existing flow to it tends to accumulate technical debt, so a clean integration design usually pays off.
The requirements for accepting the wallet are not exotic, but each one is a deliberate decision:
- an API layer that can receive and validate EUDIW-issued credentials
- selective disclosure support built into the onboarding flow
- data minimisation policies aligned with both GDPR and eIDAS 2.0
- relying-party registration with the relevant national authority
Starting in early 2026 leaves time to test properly before the deadline.
Resilience, tokenisation and the architecture decisions that cannot wait
DORA in practice: kill switches, vendor chains, post-quantum readiness
DORA has been in force since January 2025, so most teams know the name. The gap is usually between knowing it and turning it into build decisions.
Concentration risk is the part that tends to surprise product teams. If your core runs on a single cloud provider, or a critical payment flow depends on one SaaS vendor, that dependency has to be documented, tested and mitigated. The point is not that the vendor is unreliable; DORA asks you to prove you can keep operating, or fail safely, without it.
DORA requirement | What it means in practice | Architectural response |
|---|---|---|
ICT risk management framework | A documented risk register for every technology dependency | A vendor inventory with criticality ratings |
Threat-led penetration testing | Annual TLPT for significant institutions | Red-team scope that includes AI systems |
Third-party risk management | Contractual resilience clauses with all ICT providers | Exit clauses, data portability and SLA minimums |
Concentration risk mitigation | No single point of failure in critical infrastructure | Multi-cloud or active-passive failover design |
Post-quantum cryptography | Cryptographic infrastructure has to be assessed | A migration roadmap for TLS and signing keys |
Post-quantum cryptography is the requirement teams most often underestimate. The quantum-resistant algorithms are not mandatory yet, but the assessment is in scope. Migrating from RSA or ECC to the post-quantum standards – CRYSTALS-Kyber and CRYSTALS-Dilithium – takes longer than expected, especially where certificates are embedded or held in hardware security modules. The cryptographic inventory is the slow first step, and it is worth starting before it is forced.
Kill switches and feature flags are the other concrete output. Every significant feature in a banking app should be deployable and retractable on its own, so a malfunctioning component can be isolated and disabled without taking the whole system down. Under DORA that isolation is a resilience requirement, not an optional refinement.
Real-world asset tokenisation: from pilot to production
Real-world asset tokenisation has been talked about for years; in 2026 it is moving into production, and mostly on regulated rails rather than public DeFi. The settlement plumbing tends to be ISO 20022 and permissioned ledgers wired into existing core banking, rather than a separate crypto stack.
State Street, for example, is bringing tokenised fund servicing into production through a dedicated digital-asset platform, extending its custody and administration to tokenised structures alongside traditional ones. The pattern it points to is faster settlement, less reconciliation overhead, and fractional ownership of assets that used to be out of reach for retail customers.
For a banking app this opens something new. Once a bank exposes tokenised-asset infrastructure through an API, third-party apps can offer bonds, money market funds or trade receivables inside the current-account flow, with the asset held next to the balance. There is no separate brokerage account for the customer to open and no full investment platform for the bank to build.
This is the Banking-as-a-Platform model in practice: the bank provides the regulated infrastructure, partners build the product layer on top, and the app starts to look like a financial marketplace rather than a single-institution interface.
Two things have to be in place before this works at scale: a tokenisation layer that is ISO 20022-compatible and connected to existing settlement infrastructure, and a custody model that is explicit about who holds the underlying asset and under which framework. MiCA covers some tokenised instruments and not others, so teams building these features in 2026 need asset classification settled with legal before production, not after.
What should banking apps prioritise in 2026?
The three themes are not independent. Agentic AI needs a governance layer, eIDAS 2.0 needs an identity layer, and DORA needs a resilience layer – and all three reach into the same identity, audit and deployment infrastructure. Treated as separate compliance projects, they tend to produce three overlapping solutions and close to double the spend. A single shared layer that carries identity, audit and resilience together is the more coherent build, and usually the smaller one.
A workable sequence for most organisations:
- Audit the current identity stack against EUDIW integration requirements.
- Map ICT dependencies and concentration risks for DORA.
- Define NHI governance policy before any agentic AI goes into production.
- Begin the cryptographic inventory for post-quantum migration planning.
- Assess tokenisation readiness against existing settlement and custody infrastructure.
None of these needs a full platform rebuild. What they need is a set of decisions taken now, before the architecture hardens around assumptions that later turn out to be wrong.
Mapping your 2026 banking app roadmap?
WislaCode builds regulated banking and fintech software where compliance meets architecture – DORA readiness, agentic AI governance and EUDIW integration among them. If you are sequencing the 2026 build, it is worth talking early.
How is agentic AI different from the AI banks already use?
Earlier banking AI was mostly reactive: it responded to input, flagged anomalies for a human to review, or generated recommendations. An agentic system acts on its own, initiating transactions, running multi-step compliance checks and escalating issues without waiting for a human trigger. The harder part is accountability rather than capability, because every autonomous decision needs a governance framework behind it.
How should a bank prepare its infrastructure for EUDIW integration?
Start with an audit of the existing identity verification flow to see what has to change to support attribute-based, selective-disclosure credentials. From there, build or procure an API layer that can receive and validate EUDIW-issued credentials, update data minimisation policies, and complete relying-party registration with the relevant national authority. Starting in early 2026 leaves enough time to test before the 2027 deadline.
What does DORA actually require from a banking app's architecture?
DORA requires financial institutions to document their ICT dependencies, run threat-led penetration testing, and make sure every critical third-party provider meets contractual resilience standards. In practice that means kill switches for significant features, a clear map of concentration risk across cloud and SaaS vendors, and a cryptographic inventory for post-quantum readiness. It does not prescribe specific technologies, but it does ask for evidence that the system can fail safely.
Which banking app features are moving from pilot to production in 2026?
Real-world asset tokenisation is the clearest example. State Street, for instance, is bringing tokenised fund servicing into production on a dedicated digital-asset platform. Embedded investment products, where a customer holds tokenised assets directly in a current-account interface, are the next step, enabled by Banking-as-a-Platform models that expose that infrastructure through an API to third-party developers.
Is post-quantum cryptography already a compliance requirement under DORA?
Not yet as a mandatory standard, but the assessment is already in scope. DORA's operational resilience testing covers cryptographic infrastructure, so institutions have to evaluate their current encryption and signing against post-quantum risk. Migrating from RSA or ECC to quantum-resistant algorithms typically takes 18 to 36 months in complex banking systems, so teams that delay the inventory are likely to miss the window for an orderly transition.
Do banks have to rebuild onboarding to comply with eIDAS 2.0?
In most cases a rebuild is more realistic than a patch. The wallet uses selective-disclosure credentials that are structurally different from document-upload or liveness-check flows. Adapting an existing flow without redesigning the identity layer underneath tends to create technical debt that compounds when the AMLR requirements land in the same window. A clean integration design is usually faster in the long run.
When should a team start on agentic AI governance, and who should own it?
Governance should be in place before the first autonomous agent goes live, not after. Once an agentic system is running, retrofitting audit trails, access controls and escalation logic is far more expensive than building them in. Ownership usually sits across two functions: the engineering lead for NHI identity management and audit infrastructure, and the compliance or risk function for human-in-the-loop thresholds and regulatory reporting.
