Beyond Consent: How Data Minimization Can Actually Work in Open Banking

Not so long ago, free, explicit, informed consent was considered the gold standard of consumer data privacy. As one of GDPR’s core legal bases for processing personal data, the consent-based access model remains widely adopted. Yet amid the rising number of high-profile breaches, users are increasingly wary of exposure, and often treat sharing personal data as the price of admission to the third-party services they want. This privacy versus function tradeoff hampers service adoption. The need of the hour is to shift from a purely consent-based model to one that prioritizes data minimization – sharing only the minimum needed to deliver the service. Modern privacy enhancing techniques can avoid exposure of underlying data, while still enabling verification, analytics, or eligibility checks. This can be game changing for data minimization goals, delivering a much stronger notion of privacy. There is little precedent though of how large scale real world solutions can be transformed with these technologies. What are these techniques and what is their promise? What kind of scenarios could they enable? Are such solutions feasible today, and what would they look like? This article answers some of these questions through a clear, accessible case study of privacy in Open Banking – a large-scale system for regulated sharing of customer financial data with third-party providers (TPPs). The context: privacy tension in open banking The context: privacy tension in open banking While open banking has the potential to drive innovation, increase competition, and deliver more personalized services to customers, opening the traditionally closed banking system is a double-edged sword. In an era that promises greater user control and privacy, today’s consent-driven workflows feel increasingly anachronistic. Permissions are often granted on an impulse, scopes are broad and long-lived to reduce “consent fatigue.” The result is large volumes of personal data collected by third parties, increasing the risk of exposure through misuse or breach. The situation gets worse when financial data is involved. Why? Because financial data reveals far more than just financial health. When users grant broad consent covering all transactions for 90 days, few truly grasp the depth of the privacy and security risks they are accepting. The financial data exposes our relationships with service providers and offers a window into nearly every facet of life – employment, travel, health, even social and political affiliations. The privacy of others we interact with is also at stake. Several recent studies, including the OECD’s Data Portability in Open Banking report and McKinsey’s Financial Data Unbound, warn that privacy concerns, particularly around legal ambiguity and data protection gaps, could become a significant barrier to open banking adoption. With data breaches occurring at an alarming rate and TPPs operating under a much lighter regulatory regime than banks, extending access to TPPs expands the attack surface and sharply increases privacy risks. Data Portability in Open Banking Data Portability in Open Banking Data Portability in Open Banking McKinsey’s Financial Data Unbound McKinsey’s Financial Data Unbound Financial Data Unbound privacy risks privacy risks The tension is also evident from the reaction to the October 2024 Consumer Financial Protection Bureau (CFPB) Dodd-Frank Act (Section 1033), open banking rule. While the move aimed to empower consumers and spur competition by unlocking financial data, the rule has been hotly debated between the bank and fintech lobbies and is currently stayed by court. Dodd-Frank Act (Section 1033), open banking rule Dodd-Frank Act (Section 1033), open banking rule stayed by court stayed by court A stronger privacy model for financial data sharing A stronger privacy model for financial data sharing To understand the privacy implications of Open Banking, it is important to first examine the nature of the information exchanged and how it is used by TPPs. Data exchanged ranges from relatively static attributes, such as identity and KYC details, to dynamic transaction histories from which insights can be derived. In many cases, producing these insights requires cross-domain aggregation – either consolidating a single user’s accounts across financial institutions or pooling data from many users to discover trends. A stronger privacy model, one that uses a strict interpretation of data minimization principle can be realized through two complementary patterns: selective disclosure and privacy-preserving aggregation: selective disclosure privacy-preserving aggregation Selective disclosure lets a user share only chosen fields from an issuer-signed credential with a specific party, while keeping all other fields hidden. Privacy-preserving aggregation enables insights to be derived combining data from multiple domains without exposing raw data to other domains or concentrating it in a single third party. Selective disclosure lets a user share only chosen fields from an issuer-signed credential with a specific party, while keeping all other fields hidden. Privacy-preserving aggregation enables insights to be derived combining data from multiple domains without exposing raw data to other domains or concentrating it in a single third party. Crypto magic at work Crypto magic at work What technologies can deliver such utility while safeguarding privacy? The answer lies in a new class of Privacy Enhancing Technologies* (PETs) – cryptographic methods that allow either verifiable claims or meaningful computation on data that remains private, distributed, or encrypted. *Though PET is a broader term, in this article it refers specifically to the subset that employs cryptography. *Though PET is a broader term, in this article it refers specifically to the subset that employs cryptography. Zero-knowledge proofs (ZKPs) allow proving knowledge of something without actually revealing it. For example, prove one is earning within a salary band without disclosing the income or the bank with which the salary account is held. Similarly, by “knowing” a statement issued by a bank, the customer can selectively disclose parts of it or make claims about it, for instance, showing only that the monthly balance exceeds a certain threshold. It could also allow a customer to synthesize information from multiple such statements, possibly issued by different banks. For example, they could issue a verifiable claim of their consolidated Debt to Income (DTI) ratio without sharing the statements. Zero-knowledge proofs Zero-knowledge proofs For more complex aggregations and insights,Secure Multiparty Computation (MPC) and Fully Homomorphic Encryption (FHE) can be used. For example, calculating a user’s financial health score across banks can be done without exposing raw income or liability data, with MPC splitting the computation across parties or FHE operating directly on encrypted information. Secure Multiparty Computation Secure Multiparty Computation Fully Homomorphic Encryption Fully Homomorphic Encryption Open banking case study Open banking case study This section provides a sketch of what a privacy-preserving Open Banking solution could look like. A full solution covering all major Open Banking use cases – likely using a combination of ZKPs, MPC, and FHE – is well beyond the scope of this article. Instead, I focus on a smaller, concrete scenario that still surfaces the core benefits and key components of such a privacy-preserving solution. Disclaimer: This is a hypothetical scenario. Bank names e.g., Emirates NBD, HSBC are illustrative and any services mentioned are imagined; no affiliation or endorsement is implied. Disclaimer: This is a hypothetical scenario. Bank names e.g., Emirates NBD, HSBC are illustrative and any services mentioned are imagined; no affiliation or endorsement is implied. Disclaimer: This is a hypothetical scenario. Bank names e.g., Emirates NBD, HSBC are illustrative and any services mentioned are imagined; no affiliation or endorsement is implied. The Scenario Motivation: Too often, a service needs a single fact, but our documents expose everything. For a student discount, we share the entire ID card; for an address proof, we attach utility bills; for a loan pre-check, we upload full bank statements. The scenario presented addresses this mismatch using selective disclosure. Motivation: Motivation: Imagine Alice, a UAE resident whose salary is paid into Emirates NBD (ENBD) and who also maintains an account at HSBC. Every month, Alice gets the familiar email from her bank: “Your statement is ready.” She downloads the PDF as usualthen notices a new banner: “Your statement is ready.” Get your Smart Statement (New!) – a monthly statement that allows you to disclose your profile and transaction selectively with third party providers (TPPs) or make verifiable claims about your income and spending. Get your Smart Statement (New!) – a monthly statement that allows you to disclose your profile and transaction selectively with third party providers (TPPs) or make verifiable claims about your income and spending. Tapping “Get Smart Statement” delivers it to UnifyPass, her national ID backed wallet, and the front end of the government-regulated Open Banking framework, built on data-minimization principles. Later, she enters a cinema for an 18+ film, buys concert tickets with a UAE-resident discount, and enrolls in an airport lounge program that requires proof of an active Visa card. Each time, her wallet discloses only the bare minimum, a la carte, from the smart statement, without initiating a new bank session, improving both convenience and privacy. Each use is also unlinkable from the last, leaving no breadcrumbs for third parties to piece together her activities These identity interactions are facilitated by FinBridge, a fintech identity broker participating in the Open Banking initiative, enabling third-party service providers to integrate with bank-issued identities. Another fintech, FinCheck, integrates with the platform and offers pre-loan eligibility checks that require minimum balance and salary verification. Alice shares her name and proves her balance and salary meet the thresholds, without disclosing exact amounts or detailed statements, to qualify for the loan. Solution building blocks This section provides an overview of the technical solution. It’s aimed at security/privacy architects, engineers building fintech solutions, and technically inclined product leaders. Where possible, I have included links to both accessible explainers and the original research/specifications. This section provides an overview of the technical solution. It’s aimed at security/privacy architects, engineers building fintech solutions, and technically inclined product leaders. Where possible, I have included links to both accessible explainers and the original research/specifications. This section provides an overview of the technical solution. It’s aimed at security/privacy architects, engineers building fintech solutions, and technically inclined product leaders. Where possible, I have included links to both accessible explainers and the original research/specifications. This section uses the standard verifiable credentials (VC) terminology: the bank is the issuer, Alice is the holder, and the TPPs are verifiers of the credentials and proofs. This section uses the standard verifiable credentials (VC) terminology: the bank is the issuer, Alice is the holder, and the TPPs are verifiers of the credentials and proofs. his section uses the standard verifiable credentials (VC) terminology: the bank is the issuer, Alice is the holder, and the TPPs are verifiers of the credentials and proofs. In this example, data minimization is achieved through the notions of selective disclosure and range proofs: Selective disclosure lets Alice reveal only specific fields from a previously issued credential (the monthly smart statement), keeping the rest hidden This is enabled by BBS+ (described below). Range proofs let her prove a hidden number satisfies bounds (also called predicates) such as salary ≥ X and balance ≥ Y, without revealing the number. This is enabled by Bulletproofs. Selective disclosure lets Alice reveal only specific fields from a previously issued credential (the monthly smart statement), keeping the rest hidden This is enabled by BBS+ (described below). Selective disclosure Range proofs let her prove a hidden number satisfies bounds (also called predicates) such as salary ≥ X and balance ≥ Y, without revealing the number. This is enabled by Bulletproofs. Range proofs predicates Both rely on ZKPs, so verifiers learn exactly what’s needed, and nothing more. Cryptographic building blocks Cryptographic building blocks Cryptography Suite: BBS+ is an unlinkable digital signature scheme, derived from BBS (Boneh, Boyen, and Shacham), with strong unforgeability and selective disclosure support. The issuer signs multiple attributes at once and later lets the holder’s wallet produce selective-disclosure proofs. These proofs, also called presentations, reveal only chosen fields to the verifier, while proving the holder possesses a valid issuer signature on the entire credential. Thus, the hidden attributes stay bound and undisclosed. The verifier can trust the revealed attributes but gains zero knowledge about the hidden ones. In the example scenario, this technique is used by Alice to selectively reveal attributes, such as name, age, account status, residence permit validity etc. to TPPs. Cryptography Suite: BBS+ BBS+ BBS+ digital signature scheme digital signature scheme BBS (Boneh, Boyen, and Shacham) BBS (Boneh, Boyen, and Shacham) Commitments: A cryptographic commitment is like a “sealed envelope” that encloses a number and may additionally allow simple arithmetic on hidden value (e.g. proving that number ≥ X) without opening the envelope. The specific commitment used here is a Pedersen commitment. Its properties are used by the Bulletproof in our example, to create proofs such as ‘salary ≥ X’. Commitments: Pedersen commitment Pedersen commitment Pedersen commitment Bulletproofs: Hidden attributes (e.g. age, salary, balance) can be accompanied by a range proof showing they meet specified bounds. A practical way to implement range proofs for this example, is using Bulletproofs: short, non-interactive, zero-knowledge proof method that proves a committed value lies within a range without revealing it. The committed value is shifted by T, the comparison threshold, so the hidden number becomes ‘attribute value – T’. Then the task is to prove that this lies in the range [0, 2^k) for some k (e.g. 64). Bulletproofs achieve this by showing the shifted value can be decomposed into a weighted sum with weights 1,2,...2^(k-1) where all coefficients are bits (0, 1). An inner-product argument compresses these per-bit checks into a tiny proof. Bulletproofs: Bulletproofs Bulletproofs Bulletproofs Bulletproofs Bulletproofs While not detailed here, it is also possible to generate a single aggregate proof that composes income and debt predicates, possibly from different issuers, into one compact verification. For example, Alice keeps Income (from ENBD) and Debt (from HSBC) hidden under their issuer-signed credentials, then generates a single aggregate proof that her Debt to Income Ratio (DTI) meets the policy. While ZKPs can handle such simple aggregations, privacy preserving aggregations and analytics are usually better handled by other PTEs such as MPC or FHE. aggregate proof Credential trust and transport Credential trust and transport The Verifiable Credentials (VC) W3C standards define the JSON data model for issuing, holding, and presenting VC artifacts. It defines how claims, metadata (issuer, subject, timestamps), and a proof (issuer’s signature) are packaged into a credential, and how a user wallet creates a Verifiable Presentation (VP) corresponding to a verifier’s request, including selective disclosure and range proofs. Popular proof formats include W3C Data Integrity (e.g., BBS+) and SD-JWT VC. Verifiable Credentials (VC) Verifiable Credentials (VC) Verifiable Credentials (VC) W3C standards W3C standards The Open Banking trust registry is an essential component that bootstraps trust between participants of the platform. It specifies who may issue what, with which keys. The VC references Decentralized Identifiers (DIDs) that resolve to DID documents published in the registry by issuers. This contains critical information such as authoritative public keys (with rotation history), link to integrity-protected credential definitions (schema, order of fields, base-derivation rules used for initializing the cryptographic suites etc.) and status lists for revocation/expiry. During verification, the verifier pulls keys from the DID doc, checks the credential’s schema against the registered definition, and consults the status entry for revocation and validity windows. Registries can also encode governance/accreditation such as “licensed banks”. The Open Banking trust registry Decentralized Identifiers (DIDs) Decentralized Identifiers (DIDs) VCs could then be exchanged over OpenID for Verifiable Credentials (OIDC for VC) which brings familiar OAuth/OIDC web flows to issuing and presenting credentials with a wallet. There are two complementary flows: OIDC4VCI between issuer and holder wallet to deliver the credential, and OIDC4VP between holder wallet and verifier to share the verifiable presentations e.g. BBS+ selective disclosure and range proofs. OpenID for Verifiable Credentials OpenID for Verifiable Credentials OpenID for Verifiable Credentials From crypto lab to real deployments From crypto lab to real deployments Here’s how performance, standards, and tooling stack up when PETs move from the lab to production. Compared to traditional digital signatures, selective-disclosure credentials such as BBS+ add modest compute and proof size overhead, typically a few KB per presentation and sub-second creation/verification on modern phones and servers. Range proofs(e.g., Bulletproofs add additional KBs and tens to hundreds of milliseconds, but remain practical for simple predicates like “salary ≥ X.” Storage/transport overhead is small relative to typical API payloads, and verification scales horizontally behind standard web services. compute and proof size overhead compute and proof size overhead add additional KBs add additional KBs On the standards front, W3C Verifiable Credentials, DID Core, W3C Data Integrity (BBS+ cryptosuite), and OIDC for Verifiable Credentials (OIDC4VCI/OIDC4VP) provide an interoperable path. There are many industry consortiums active in this space: W3C, OIDF, DIF, ToIP. Robust open-source libraries exist for BBS+ (Digital Bazaar, MATTR), Bulletproofs (Dalek/Rust), and VC/DID tooling. EU programs such as EBSI/EUDI Wallet have active pilots and production-grade flows using OIDC4VCI/OIDC4VP and VCs. Data Integrity Data Integrity Digital Bazaar Digital Bazaar MATTR MATTR Dalek Dalek EBSI EBSI EUDI EUDI While MPC and FHE are also advancing quickly and finding practical use cases, ZKPs are more battle-tested due to their use in the crypto industry. They power privacy coins like Zcash and major Ethereum zk-rollups, StarkNet, zkSync, Polygon zkEVM, that secure real users and settle meaningful value at scale. Thus a reasonable approach to transforming large scale applications such as open banking could be to start with selective disclosure and simple predicates on the current VC/OIDC stack and layer in MPC/FHE as your use cases mature. Privacy building blocks for a future web Consent alone is a blunt instrument for the delicate privacy demands of financial data sharing. Data minimization is the key to reducing concerns about personal data sharing in open banking. With a stronger privacy model supported by Privacy Enhancing Technologies (PETs), open banking could finally deliver on its promise without being overshadowed by privacy concerns. If done well, everyone in the ecosystem wins: Alice gets what she needs without oversharing, and banks and fintechs derive value from data while minimizing exposure. An enhanced privacy layer that supports selective disclosure, zero-knowledge predicate claims, and computation over encrypted or partitioned data can unlock a wide range of applications, open banking is just one of them. Similar capabilities also power privacy-preserving machine learning – enabling secure model training, inference, and data sharing across institutions without exposing the underlying data. Privacy-enhancing technologies are likely to evolve into standard building blocks of the next-generation web stack, underpinning privacy across sectors such as finance, healthcare and government and securing data-intensive AI workloads. In time, PETs could play a role in privacy and user control comparable to what TLS, DNSSEC, IPsec, and OIDC do today for secure transport and digital identity.