Skip to main content
Identity in open banking is the verified link between a person and their bank account. Because banks hold KYC-verified (Know Your Customer) identity data — confirmed name, address, date of birth — open banking APIs allow downstream services to leverage that verification without repeating it. Trust infrastructure is the set of agreements, standards, and technical controls that allow institutions to share data and rely on each other’s verification. Without trust infrastructure, every participant in the chain must verify everything independently. With it, a verification performed by a bank can be accepted by a lender, landlord, or employer — reducing friction, cost, and time.

​
Why is bank-held identity valuable?

Banks verify identity as a regulatory obligation. Before opening an account, they confirm the customer’s name, address, date of birth, and right to reside — using government-issued documents and electronic verification databases. This is KYC, and it is the most rigorous identity verification most people undergo. This creates a unique asset: bank-verified identity is already paid for, already maintained, and already trusted by regulators. Open banking APIs allow this identity asset to be used as a foundation for downstream services. Three practical applications:
  • Account ownership verification. Confirm that a person is the named holder of a specific bank account. Used in lending, payroll, and onboarding.
  • Name matching. Compare the name on a bank account against a name provided in an application. Replaces manual document checks in landlord referencing, employment verification, and government services.
  • Income and employment verification. Confirm that regular salary credits appear in the account, from an identifiable employer, at a stated frequency. More reliable than payslips because it comes directly from the bank.
The significance of bank-verified identity is that it sits upstream of most other verification methods. A payslip can be forged. A utility bill proves an address, not a person. A bank account with KYC verification proves both.

​
What is trust infrastructure and why does it matter?

Trust infrastructure is the framework that allows one organisation to accept another’s verification. It has three components:

​
Standards

Agreed data formats, API specifications, and identity schemas that allow interoperability. In UK open banking, these are defined by the Open Banking Implementation Entity (OBIE) standards and PSD2 regulatory technical standards. Without standards, every integration is bespoke. With standards, a data product provider can connect to multiple banks using the same API specification. Contracts that define liability, data handling obligations, and consent requirements between parties. When a lender relies on a bank’s KYC data accessed through open banking, the legal agreement defines who is liable if the identity data is wrong. These agreements typically cover: data accuracy warranties, processing limitations, breach notification requirements, and indemnity structures.

​
Technical controls

The authentication, encryption, and access management systems that enforce the trust model. Strong Customer Authentication (SCA) under PSD2 ensures the customer actively authorises data access. TLS encryption protects data in transit. OAuth 2.0 token-based access ensures the data product provider can only access what the customer consented to. Identity, consent, and data access form a dependency chain:
  1. Identity verification — the customer proves who they are (via bank authentication / SCA)
  2. Consent grant — the verified customer explicitly agrees to share specific data for a stated purpose
  3. Data access — the data product provider accesses only the data covered by the consent, for the verified customer
If identity verification fails, consent is invalid (you cannot consent on behalf of someone else). If consent is invalid, data access is unauthorised. The chain must hold at every link. This dependency is why consent design and identity design must be considered together. A consent flow that does not properly verify the customer’s identity is a regulatory breach waiting to happen.

​
What are the levels of identity assurance?

Not every use case requires full KYC-level identity assurance. Different applications need different levels:
LevelWhat it confirmsUse casesEvidence required
Account existenceA bank account with the given sort code and account number existsPayment initiation, direct debit setupAPI check only
Account ownershipThe named person is the holder of the accountPayroll verification, landlord referencingName match against bank-held data
Identity verificationThe person’s name, address, and date of birth match bank-held KYC recordsLending onboarding, government services, regulated client verificationFull KYC data match via API
Financial identityThe person’s income, employer, and financial behaviour patterns are confirmedMortgage applications, credit decisioning, affordability assessmentsTransaction data analysis plus identity verification
Designing for the minimum necessary assurance level reduces data access scope, improves consent rates, and limits regulatory exposure. A landlord referencing product does not need financial identity — account ownership is sufficient.

​
What does decentralised identity mean for open banking?

Decentralised or self-sovereign identity (SSI) is an emerging model where individuals hold their own verified identity credentials rather than relying on institutions to store and share them. In this model:
  • A bank verifies a customer’s identity and issues a digital credential
  • The customer stores the credential in a digital wallet
  • When a lender needs identity verification, the customer presents the credential directly — without the bank being involved in the transaction
This changes the trust model. Instead of institution-to-institution data sharing (with all the consent, liability, and API complexity that entails), the customer becomes the intermediary. The bank’s role shifts from data provider to credential issuer. Practical implications for builders:
  • SSI is not yet mature enough for production use in most regulated markets
  • The technical standards (W3C Verifiable Credentials, DID methods) exist but adoption is early
  • Regulatory frameworks have not yet adapted to credential-based identity models
  • The transition from institution-held to customer-held identity will be gradual, not a switch
  • Builders should design systems that can support both models — API-based data sharing today, credential-based verification when the infrastructure matures

​
Common mistakes

  • Conflating authentication with identity. Authentication proves someone can access an account (they have the password). Identity proves who they are. A fraudster with stolen credentials can authenticate but is not the verified identity.
  • Over-collecting identity data. Requesting full KYC data for a use case that only needs account ownership verification increases data scope, regulatory burden, and customer friction.
  • Building without a trust model. If you cannot document who trusts whom, what each party is liable for, and what happens when verification is wrong, you do not have trust infrastructure — you have an API integration.
  • Assuming bank data is always correct. Banks hold KYC data, but that data can be out of date. A customer who moved address six months ago may still show their old address in bank records.
  • Ignoring the consent dependency. Identity verification and consent are sequential dependencies. Skipping or weakening either one invalidates the entire data access chain.
  • Treating decentralised identity as production-ready. SSI standards exist but the ecosystem — wallets, issuers, verifiers, regulatory acceptance — is not yet mature for regulated financial services at scale.

​
Key takeaways

  • Bank-held identity is the most rigorous and widely available identity verification. Open banking makes it accessible to downstream services.
  • Trust infrastructure requires three components: standards, legal agreements, and technical controls. Missing any one breaks the chain.
  • Identity, consent, and data access form a dependency chain. Each link must hold for the system to work.
  • Design for the minimum necessary assurance level. Not every use case needs full KYC verification.
  • Decentralised identity is emerging but not yet production-ready in regulated markets. Design systems that can support both models.