The Motivation

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.

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. With open banking — the practice of sharing financial data with third-party services via APIs — this tendency to overshare gets amplified. 

The Vision

Explicit and informed user consent has long been considered the gold standard in consumer data privacy.  However, in open-banking context a combination of broad consents and API access to third party providers, results in over disclosure. 

Bank ID completely turns around this data exchange pattern by allowing the user to control every aspect of the financial data sharing with third party providers (TPPs). It has these unique features: 

• No direct bank access to TPP. 

• Explicit user action vs. one time consent. 

• Allows aggregation of user credentials from multiple sources (banks). 

• Allows user to selectively disclose information from available credentials. 

• No additional trusted party or broker. 

The remarkable aspect of Bank ID is that the above features are achieved without adding any trusted intermediary or broker. The user acts as their own information broker. 

The Benefits

Compared to existing deployed open-banking solutions such as India's Account Aggregator (Sahmati system), Bank ID has following distinct advantages. 

Enhanced Privacy through Selective Disclosure

1. Rather than sharing full financial records, it allows sharing of granular information.  

2. Allows making a claim sourcing information from multiple financial documents with possibly different issuers. 

3. Creating proofs that they satisfy some criteria (e.g. salary > X, balance > Y) without revealing actual values.

Key benefit: User has fine grain control over information flow thereby fulfilling the TPP request with minimum data exposure. 

Enhanced Privacy through Credential Exchange

The Bank ID credential exchange. 

1. Bank sharing credentials such as a "SmartStatement" at regular intervals with the user. 

2. TPPs making information request requiring some claims and proofs from the user. 

3. The user creating these claims and proofs using the stored credemtials without contacting the issuing bank(s). 

4. The TPP is able to verify the claims/proofs without needing to contact the issuing bank(s)

Key benefit: This interaction model breaks the direct link between TPPs and banks for accessing private data. It requires explicit user action for each data request. This means there is no dependency on banks or trusted intermediaries and these parties are unaware of any user interactions with TPPs. 

For more details on business context and the value proposition, please review the Bank ID FAQs

The Technology

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. 

The current version of Bank ID is heavily based PETs known as Zero-Knowledge Proofs (ZKPs). These techniques 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. 

Table 1: Core cryptographic building blocks enabling privacy-preserving data sharing in Bank ID

The Verifiable Credentials (VC) W3C standards is used to 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.

VCs are then 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.

The Difference

Several Self-Sovereign Identity (SSI) and decentralized identity solutions have advanced the idea of user-controlled digital identity. However, many of these approaches have overengineered the decentralization and privacy aspects in ways that reduce the practical utility of these frameworks while also making them significantly more complex to implement, govern, and regulate.

This has often involved rejecting familiar trust mechanisms such as X.509 certificates, requiring entirely new trust frameworks and consortium models, and designing privacy architectures with little scope for auditing — making them difficult to align with the realities of regulated Open Banking ecosystems.

Similarly, requiring complete unlinkability across every user interaction, even between a user and the same TPP, may be attractive as a privacy ideal, but can conflict with legitimate needs around fraud prevention, customer support, regulatory compliance, and ongoing KYC obligations.

Managing credential revocation in a privacy-preserving manner has also remained a persistent challenge. Revocation mechanisms can themselves introduce privacy risks if they enable correlation or tracking of credential usage across services.

Bank ID addresses these challenges through a more pragmatic approach to privacy-preserving identity. We focus on user control and data minimization without forcing banks, TPPs, or regulators to abandon the trust infrastructure, governance models, and operational workflows they already understand. Our goal is not decentralization for its own sake, but a privacy-preserving financial identity framework that is practical, deployable, auditable, and usable at scale.

Bank ID is also designed specifically for the financial sector from the ground up. This is reflected not only in its support for compliance, auditability, and regulated trust models, but also in the way critical operational workflows — such as recovery, revocation, customer support, and lifecycle management — are handled in a manner aligned with real-world banking requirements.