Every additional document upload in a retail banking or insurance journey is a conversion tax. Customers photograph passports again, wait for vendor OCR to finish and abandon when the app asks for the same proof they already gave last quarter. Fenergo’s 2025 survey of 600 senior decision-makers across banks, asset managers and fund administrators found that 70 per cent of firms lost clients in the past year because onboarding was too slow, up from 67 per cent in 2024 and 48 per cent in 2023. Average abandonment sits around 10 per cent. Average annual spend on AML and KYC operations now runs to about US$72.9 million per firm, with UK institutions reporting the highest average at US$78.4 million. Meanwhile copies of identity documents sit in vendor vaults and internal document stores, widening the blast radius when those repositories are breached. The model is expensive, leaky and increasingly out of step with what regulators and customers expect from a mobile-first relationship.
The cost of doing nothing is not only lost applications. It is repeated verification labour for products the customer already holds, inconsistent risk scores across lines of business and a compliance posture that treats every channel as if it were meeting the customer for the first time. Photo-upload KYC cannot prove that the person presenting the document today is the same person who completed the original check without another round of selfies and liveness. It cannot work cleanly when connectivity is poor. It cannot disclose “over 18 and resident in this jurisdiction” without also handing over a full scan of a passport page. For product and security leads who already run Flutter customer apps, that gap is architectural rather than cosmetic.
The hidden cost of repeat KYC uploads
Repeat KYC is the tax institutions pay for treating identity as a file rather than a signed claim. Each new product, periodic review or partner channel restarts a capture pipeline: camera permissions, image quality gates, third-party verification APIs and manual exception queues. Corporate and institutional reviews still cost thousands of dollars per client in many houses. Retail flows look cheaper per case but dominate volume. Drop-off compounds across journeys that should feel continuous: savings to mortgage, motor to home, bank to insurer within the same group.
Fraud risk concentrates in the copies. Once a high-resolution identity image leaves the device, control is contractual rather than cryptographic. Vendors retain artefacts for audit. Internal systems retain more. Lateral movement through a compromised document store yields reusable identity material. The institution also absorbs operational cost when connectivity fails in branches, on claims sites or in rural markets: the app cannot complete a live vendor check so staff fall back to paper or defer the journey. That is not a niche edge case for banks and insurers with field networks or customers who travel. It is a standing reliability problem that photo-upload pipelines were never designed to solve.
An effective response must therefore separate high-assurance identity from perpetual re-upload. The customer completes a rigorous issuance once. Subsequent presentations prove possession of signed claims without shipping fresh document images into another vault.
Signed claims on the device beat another photo upload
A verifiable credential is a set of claims an issuer signs about a subject. The holder stores it and later presents it to a verifier, which checks the issuer signature, status and binding without needing the issuer online for every check. The W3C Verifiable Credentials Data Model 2.0 became a W3C Recommendation on 15 May 2025. In parallel, OpenID for Verifiable Credential Issuance and OpenID for Verifiable Presentations, often paired with selectively disclosable formats such as IETF SD-JWT VC or ISO mdoc, give mobile wallets a practical protocol path from issuance through presentation.
Inside a Flutter customer app the pattern is concrete. After a high-assurance KYC or government-grade check, the bank or insurer (or a trusted identity partner) issues a credential into the app’s wallet module. The credential is bound to a holder key that never leaves the device’s secure hardware. Later, when a new product journey or claims step needs proof of identity, age, address or policy status, the app builds a presentation that discloses only the required claims, signs it with the device-bound key and returns it to the verifier. The verifier validates cryptography and policy locally or at the edge. No fresh passport photograph needs to enter a vendor pipeline. That is the commercial difference: one expensive issuance, many cheap presentations.
Why action is required now
Standards and regulation have moved from pilot language into delivery calendars. Regulation (EU) 2024/1183 (eIDAS 2) requires Member States to offer at least one certified European Digital Identity Wallet by the end of 2026. Private relying parties in banking and related sectors face acceptance obligations for strong customer authentication on a roughly December 2027 clock. Large-Scale Pilots such as POTENTIAL have already exercised bank account opening, SIM registration and related flows with more than a thousand successful transactions across dozens of partners. Waiting for a perfect pan-European wallet before embedding credential capability in your own Flutter app leaves you reactive when acceptance becomes mandatory and when customers expect wallet-native journeys.
Flutter teams already sit on the right substrate. iOS Secure Enclave and Keychain, Android Keystore with TEE or StrongBox and platform biometrics are mature enough for holder keys and sealed credential storage. Device attestation (Android key attestation, Apple App Attest) lets the issuer and verifier demand evidence that the binding key was born in hardware rather than in ordinary app memory. Connectivity assumptions have also shifted: field claims, branch overflow and travel corridors make offline-capable presentation a product requirement rather than a nice-to-have. Institutions that still treat KYC as “upload another JPEG” will look slow next to peers who can request three attributes and get a cryptographically checkable answer in one tap.
A pragmatic rollout that starts with issuance into the wallet
Start with a single high-value credential type rather than a full identity platform rewrite. Typical first candidates are a bank-issued KYC attestation after successful onboarding, a proof-of-address credential refreshed from a trusted source or an insurer-issued policy-holder attestation usable across claims and renewals. Issue over OpenID4VCI into the Flutter wallet. Persist the credential ciphertext in hardware-backed storage. Generate the holder binding key in the Secure Enclave or StrongBox so the private material is non-exportable. Record attestation evidence at issuance so you can prove device assurance to your own risk engine later.
Keep the first verifier internal. Use the credential to skip re-upload when an existing customer opens a second product in the same app family. Measure completion time, abandonment, exception-queue volume and vendor API cost against the legacy path. Form a compact squad that owns wallet UX, key lifecycle, revocation checks and Flutter platform security rather than scattering the work across channel teams. Success criteria should be blunt: fewer document captures per active customer, lower third-party verification spend on returning journeys and no increase in confirmed identity fraud for the scoped products.
Do not skip holder binding. A credential that can be copied between devices without cryptographic proof of possession is just a signed PDF with extra steps. Device binding plus biometric-gated key use is what turns “I have a file” into “I control the key that this issuer bound to these claims”.
Scaling to selective disclosure, offline presentation and local verification
Once issuance and internal verification work, extend the verifier surface. Selective disclosure is the privacy and data-minimisation win that photo KYC cannot offer. With SD-JWT-style credentials the wallet reveals only the digests and claim values the verifier asked for: age over threshold, jurisdiction of residence, policy active flag. The full credential subject never needs to leave the device. That shrinks data held by partners, supports purpose limitation and reduces the attractiveness of verifier-side stores as theft targets.
Offline presentation is the resilience win. Cache issuer public keys and status artefacts according to a defined freshness policy. When the customer is in a poor-signal branch, on a claims site or mid-travel, the Flutter app can still construct a presentation and a verifier app or agent device can validate signatures and device binding locally. Full revocation freshness may wait until connectivity returns, so encode risk: accept offline checks for lower-risk steps, require online status for high-risk ones and record the assurance level with the decision. Local verification is not a substitute for AML programme design. It is a way to keep low-friction journeys alive when the network is not.
Hardware-backed storage remains non-negotiable at this stage. Treat Keychain and Keystore as the seal for credential blobs. Keep signing keys non-exportable. Use attestation to detect rooted or unlocked devices against policy. Rotate or revoke on device change, biometric re-enrolment where your threat model demands it and confirmed compromise. Scale outward only after those controls are boringly reliable: partner banks inside a group, broker portals, claims partners and eventually public-sector or EUDI wallet interoperability where your markets require it.
The commercial payoff for banks and insurers
The payoff is operational and regulatory at once. Returning customers stop paying the document-upload tax. Vendor spend shifts from perpetual capture towards issuance, status and high-assurance exceptions. Data held by each relying party shrinks to the claims actually needed. Offline-capable flows protect conversion in the places photo KYC is weakest. Security leads gain a clearer story: signed claims, device-bound keys, hardware seals and auditable presentation logs beat warehouses of passport images.
For groups that span banking and insurance the same wallet module becomes a cross-franchise asset. A KYC credential issued at account opening can support an insurance quote without a second capture, subject to policy and consent. For EU-facing franchises the same investment prepares acceptance of Member State EUDI wallets and positions the institution as a relying party that already understands OpenID4VP rather than one scrambling in 2027. Talent retention follows the work: engineers who ship hardware-backed wallets and selective disclosure stay closer to the regulatory centre of gravity than teams still polishing upload forms.
Immediate next steps for product and security leads
Commission a time-boxed discovery on one Flutter customer app: map every journey that still demands a document photo from an already-verified customer. Pick one credential type and one internal verifier path. Require hardware-backed holder keys, device attestation at issuance and selective disclosure in the presentation design. Align legal and compliance early on retention, offline acceptance tiers and revocation SLAs. Stand up a joint product-security squad with authority to change onboarding UX rather than a side pilot that cannot touch production funnels.
Clinging to repeat photo-upload KYC while W3C VC 2.0 is a published Recommendation, eIDAS 2 wallets land through 2026 and private-sector acceptance deadlines approach is no longer the conservative option. Banks and insurers that put signed verifiable credentials in a Flutter wallet with hardware-backed keys and device binding cut repeat KYC friction and unlock selective, offline-capable presentations that document-copy pipelines cannot match. Those who wait will keep paying conversion and vault risk for a model the standards community has already moved past.