.svg "ZealiD Logo New (1)"){kind=small}
Last updated: 23 September 2026
If you run onboarding, compliance or vendor procurement at an EU bank, the useful question for 2026 is not which of your processes could use a qualified electronic signature. It is which of them are forced to change by July 2027, and which are not. The honest answer is that fewer need action now than most vendors selling into your sector will tell you.
The list is well known and it has not changed much: remote identification, account opening, loan contracting, credit applications, corporate agreements, insurance and investment products, new-to-bank onboarding, customer segment changes, internal approvals, and cross-border agreements. What has changed is that these ten no longer sit on the same timeline. Three of them are now attached to a dated legal obligation. The rest are attached to internal policy or to national contract law, which means they move when you decide they move.
That distinction is the whole planning exercise, and it is the one most vendor material collapses.
| Banking process | What actually drives the requirement | Forced to change before 2027? |
|---|---|---|
| Remote identification and AML onboarding | AMLR Article 22, customer due diligence | Yes |
| Opening personal and corporate accounts | AMLR Article 22, applied at the point of relationship | Yes |
| Onboarding new-to-bank customers | AMLR Article 22 | Yes |
| Corporate contracts and multi-party legal documents | Cross-border enforceability under eIDAS Article 25(2) | Only where the counterparty is in another Member State |
| Cross-border and multi-jurisdictional agreements | eIDAS Article 25(2) | Only where enforceability is contested |
| Term loan contracting and approvals | National contract law | No |
| Lending and credit applications online | National contract law | No |
| Insurance and investment contracts | Sectoral rules, varying by Member State | No |
| Customer segment upgrades and downgrades | Internal policy | No |
| Internal documentation and approval workflows | Internal policy | No |
Seven of the ten are worth doing on efficiency grounds alone, and they were worth doing in 2020. Nothing about 2027 makes them urgent. Treat them as an operations decision with an operations business case, and stop letting a compliance deadline carry an argument it does not support.
The three processes that do change all run through the same provision. Regulation (EU) 2024/1624, Article 22, is titled "Identification and verification of the identity of customers and beneficial owners", and it sets out what an obliged entity must obtain and verify before a business relationship begins. The regulation states that it "shall apply from 10 July 2027", with a later date of 10 July 2029 for the narrow categories in Article 3, points (3)(n) and (o). For a bank, the operative date is 2027.
What matters operationally is not the signature. It is that identification becomes a logged, reproducible event rather than a folder of document scans. A bank that identifies a customer through a regulated trust service produces a verification record with a timestamp, an assurance level and a verified identity attached, as a by-product of the identification itself. A bank that collects passport images through a portal produces a folder, and has to reconstruct the rest later, under supervisory pressure, from whatever the portal happened to log.
The second-order effect is the one that shows up in the budget. An identity established once through a regulated provider is reusable. At ZealiD the identity verification and the certificate are both valid for two years, which turns a per-signature cost into an amortised one for any customer who signs more than occasionally. A browser-based verification flow is single-use by design: the customer verifies, signs, and verifies again from scratch the next time. For a bank with a multi-year customer relationship and dozens of signing events across it, that difference compounds quietly and substantially.
Wait.
That is uncomfortable advice from a company that sells digital identity infrastructure, and it is still the right answer for most banks in 2026. The obligation is genuine: regulated sectors running strong customer authentication, banking explicitly among them, will have to accept the European Digital Identity Wallet at the user's request from December 2027 under Regulation (EU) 2024/1183. What is not genuine is the idea that you can build against it today.
Distribution is unsettled. Maintenance responsibility is unsettled. Commercial models are unsettled. The technical specifications engineers would build against are still being amended, with implementing acts revising rules published barely a year earlier. An integration started now is an integration built against a rulebook that moved while it was being read.
There is also a harder problem underneath, and it is not new. Europe has run this experiment before, with the scheme meant to let any citizen log in to any Member State's public services. Eventually a Swede could authenticate to another country's tax authority. Authenticate, but not be recognised, because a Swedish personal identity number and a Lithuanian one are constructed differently and the receiving system had no way to match an authenticated person to a record it already held. The regulation now contains an article on unique identification. An article does not build the matching. Europe still has no common way to recognise the same person across borders, and the wallet inherits that on day one.
So when a vendor arrives selling wallet readiness, there is one question worth asking before any other: how does your solution match a foreign wallet user to a client record, when Europe has no shared identifier? A clear answer is worth continuing. An unclear answer tells you how ready anyone actually is.
One distinction is worth fixing now, because it is the one that gets lost most often in these conversations. Identity and signature are not the same thing. The wallet is a container, and its job is proving who someone is. A qualified electronic signature is a separate credential placed into it, and behind that signature there is still a certified provider performing the cryptography. The wallet does not remove the trust service provider from the picture. It becomes a new front door to one.
Spend attention now. Spend money later.
This is the part of the 2026 workload that is genuinely due now, and it is the part that gets skipped. DORA treats the provider behind your signatures as an ICT third-party service provider. Article 28, "General principles", requires financial entities to manage ICT third-party risk as an integral component of ICT risk within their risk management framework. Article 30, "Key contractual provisions", requires the rights and obligations of the financial entity and the provider to be clearly allocated and set out in writing.
The uncomfortable question that follows is one many banks have not asked: which company are you actually running that assessment on? A great many signing platforms and identity products are not themselves qualified trust service providers. They resell one, or they acquired one, or they sit several channel hops away from the entity that issues the qualified certificate. The name on your contract and the name on the certificate at the bottom of the stack are frequently not the same name.
That matters because the regulator's question is specific. Not "who supplied your signing tool", but "how was this particular person identified, and by whom". If your due diligence stopped at a platform that resells someone else's trust service, it stopped at the wrong company, and the answer sits with an entity you have no contract with.
Three things are worth establishing in writing about any provider before 2027, and none of them require a wallet strategy:
There are three ways to attack a signed document, and they fail at different depths. The first, that the signature is not valid, ends almost immediately: a qualified electronic signature is mathematically verifiable, and a court checks it the way it would check a seal. The second, that someone else signed later, meets the qualified timestamp, which is independent cryptographic proof of the moment of signing rather than a clock on a device that could be adjusted.
The third is the serious one: that the identity behind the account was never genuine. Here something unusual happens, and it is the single most valuable property of a qualified signature for a bank. The burden of proof lands on the trust service provider. A qualified provider must prove the registration was genuine, which is the reverse of how these disputes normally run. That is why an evidence package is retained for every registration for years, covering every check performed and every document validated, and why a person can be asked to complete a live face comparison against their original registration photograph a decade after the fact.
Read that as a liability question rather than a technical one. When a bank accepts a qualified signature, the proving, the evidence retention and the liability for the identity sit with the provider. That is the actual product. The signature is what it looks like from the outside.
The cost of getting this wrong is therefore not a fine in 2027. It is discovering, during a dispute or a supervisory review, that the evidence you assumed existed was never created, because the identification was performed by a tool that produced a result rather than a record.
A defensible position going into 2027 needs four things, and only one of them involves buying anything:
For the second and third of those, ZealiD publishes a DORA Compliance Addendum to the Service Agreement in its public repository, alongside the service conformity assessment certificates and the PKI Disclosure Statement. It is a contractual addendum rather than a full DORA readiness assessment, and it is downloadable rather than available on request, which is the practical difference when an Article 28 file is being assembled against a deadline.
For the standard behind the signatures themselves, see our explainer on what a qualified electronic signature actually is, and on what cross-border onboarding requires for identity.
Tomas Zuoza is CEO of ZealiD, a Qualified Trust Service Provider listed on the EU Trusted List, supervised by the Swedish Post and Telecom Agency (PTS) under the eIDAS regulation. He has spent over nine years at ZealiD across business development, operations, and product, leading the company through its 2020 milestone as the first EU trust service provider to issue qualified electronic signatures via fully automated, non-video registration. Before becoming CEO in 2025, he served as Chief Product Officer and COO, building ZealiD's signing infrastructure and expanding its certification portfolio to include qualified time stamps. His expertise spans GDPR, information security, and NIS2 compliance, and he now leads the development of Trust Circle, a verified workspace for professional services firms and their clients.
Stay up to date with news and trends on digital identity and Qualified Electronic Signature
