Advanced: decentralised identity and AI in eKYC.

Verifiable credentials and decentralised identifiers

In most eKYC today, every institution checks the same person's documents again. Decentralised identity, often called self-sovereign identity, takes a different approach: a trusted organisation checks the person once and gives them a signed digital credential, which they keep in a wallet and show to others when they choose.

The W3C Verifiable Credentials Data Model 2.0 (a W3C Recommendation since May 2025) describes the roles:

• the issuer, which makes claims about a subject and signs them into a credential, for example a bank or a government registry;
• the holder, who keeps credentials and creates presentations from them, usually the person the credential is about;
• the verifier, which receives a presentation and checks it;
• a verifiable data registry, which publishes what verifiers need, such as issuers' public keys, schemas and revocation lists.

The standard lists trusted databases, government identity databases and distributed ledgers as possible registries. A blockchain is one option, not a requirement.

Decentralised identifiers (DIDs), a W3C Recommendation since 2022, are identifiers like did:example:123456789abcdefghi that their controller can prove control of without asking a central authority. Each resolves to a DID document listing public keys and ways to interact. Many DID methods use a distributed ledger, but not all. The W3C list of DID methods accepts any that meet a minimum bar; being listed is not an endorsement of trust.

How credentials move. The OpenID Foundation finalised two protocols in 2025: OpenID for Verifiable Credential Issuance and OpenID for Verifiable Presentations. Both work with several credential formats: W3C credentials, the ISO mobile document (mdoc) format from the mobile driving licence standard ISO/IEC 18013-5, and SD-JWT, published as IETF RFC 9901 in November 2025. The SD-JWT credential profile was still an IETF draft in October 2026.

Two privacy terms matter. Selective disclosure lets the holder share only some claims, such as a name but not an address. Unlinkability means different verifiers, or the issuer and a verifier together, cannot correlate the same person's presentations. RFC 9901 itself says its salted-hash approach cannot stop an issuer and a colluding verifier linking presentations; only zero-knowledge techniques can.

One more point for KYC teams: the standard states that a credential being verifiable does not make its claims true. Verification checks the signature; whether to trust the issuer is the verifier's business decision.

Hyperledger Indy and AnonCreds as a worked example

Hyperledger Indy is open-source software for a distributed ledger built specifically for decentralised identity. Its project documentation describes the ledger as public permissioned: anyone can read it, but only approved nodes run it and only authorised roles (trustees, stewards and endorsers) may write to it. It reaches agreement with a fault-tolerant consensus protocol among those nodes.

What goes on the Indy ledger is narrow and public by design:

• DIDs and their verification keys, and key rotations;
• schemas, the list of fields a type of credential contains;
• credential definitions, the issuer's public keys for a schema;
• revocation registries, which let a verifier check whether a credential has been revoked.

There is no transaction type meant for a holder's personal details. The credentials themselves, with names, dates of birth and so on, stay in the holder's wallet.

AnonCreds is the credential format that grew up with Indy. Its specification, a version 1.0 draft that no longer depends on Indy, describes two features that matter for privacy:

• The holder never shows the signed credential itself, only a derived presentation, and a hidden "link secret" ties their credentials together without being revealed.
• Zero-knowledge predicates let the holder prove something about a number without revealing it. The specification's own example is proving that someone is over 18 from a date of birth, without sharing the date.

A real deployment. The Government of British Columbia in Canada built OrgBook BC on Indy and related tools. The provincial business registry issues verifiable credentials for registered organisations, and other regulators issue permits and licences into it. The provincial government reported over 1.4 million active legal entities and over 3.8 million credentials as of June 2021.

Status, as at October 2026. In September 2024 the Linux Foundation launched LF Decentralized Trust as an umbrella for the Hyperledger projects, and the Hyperledger name continues for many of them. Indy is a graduated project, still maintained, though its node software's last release was in February 2024; the older Indy SDK is deprecated. The related Aries project was archived in 2025, with its main frameworks moving to the OpenWallet Foundation and its messaging specifications to the Decentralized Identity Foundation. Check the current status of any project before building on it.

Blockchains and personal data

A blockchain is designed so that entries cannot be changed or deleted. Data protection law gives people the right to have data corrected and erased. Those two facts collide.

The European Data Protection Board adopted final Guidelines 02/2025 on processing personal data through blockchain technologies in July 2026. Its main points:

• Choosing a decentralised design is not a reason to ignore the GDPR, and technical impossibility cannot be used to justify non-compliance.
• Once on a chain, data stays there with no practical way to delete or change it.
• In the EDPB's words, "encrypted personal data is still personal data", and even strong encryption will eventually be broken.
• Hashes on a chain are also personal data; an unsalted hash is generally not enough on a public chain. Where something must be recorded, prefer a proof that the data exists, and keep the data itself off-chain.
• Organisations should document why a blockchain is needed at all and whether a permissioned design would do. If there is no way to meet retention and erasure duties, nothing personal should go on the chain at all.
• Even metadata such as wallet addresses can be personal data.

France's data protection authority, the CNIL, reached similar conclusions in 2018.

What good identity design does. The W3C DID standard tells implementers that DID documents on public registries must contain no personal data, so that the right to be forgotten can still work. Indy's ledger holds only keys, schemas, credential definitions and revocation data, and AnonCreds treats the registry as storage for public objects only.

That does not make such a design automatically compliant. A public DID that belongs to a person may itself be personal data, and fields on the ledger can be misused. The EDPB expects a data protection impact assessment and a deliberate decision about what, if anything, goes on the chain.

The EU wallet and what this means for KYC

The European Digital Identity Wallet. The 2024 revision of the EU eIDAS Regulation requires each member state to offer a wallet that lets people request, store, combine and present identity data and other attested attributes (electronic attestations of attributes), which they alone control, with selective disclosure. The Regulation says issuers must not be able to track how a credential is used afterwards, and that privacy-preserving techniques should ensure unlinkability where identification is not needed; its recitals mention zero-knowledge proofs. The wallet's application code must be open source, its use is voluntary and it is free for individuals.

The wallet's Architecture and Reference Framework (version 3.0, July 2026) requires wallets to support the ISO mdoc and SD-JWT credential formats, with W3C credentials optional, and uses the OpenID protocols for issuance and presentation. Its trust model is based on public-key certificates and trusted lists, not on a blockchain. It also notes that linkability by an issuer cannot be fully removed with salted hashes, that zero-knowledge proofs are the only full fix, and that no specific scheme had been selected.

What it means for KYC. A reusable credential sounds like the end of repeated onboarding, but the rules have not changed:

• Responsibility stays with you. Under FATF Recommendation 17, an institution may rely on a regulated third party, but ultimate responsibility for due diligence remains with the institution. A credential from an issuer that is not regulated for due diligence does not fit that reliance model.
• Verifiable is not the same as true. You still decide which issuers to trust and at what assurance level, as the FATF's 2020 Guidance on Digital Identity describes.
• Revocation and recovery need design: revocation checks can leak privacy if they call the issuer, and a lost phone or key needs a recovery path that does not hand the identity to an attacker.
• The FATF's 2020 guidance mentions decentralised digital identity only as an emerging way to give people more control over their data; it does not endorse any architecture.

Banks in the EU will have to accept the wallet when a customer chooses it, from roughly the end of 2027. That is the most concrete route by which reusable credentials will reach KYC.

AI in eKYC and the EU AI Act

AI already runs through eKYC. The FATF's 2020 guidance lists AI for checking whether a government document is genuine and video for remote liveness, and its 2021 report on new technologies notes that combining official identity documents with biometrics can make checks more robust. The same report names explainability as a key challenge and says human review remains very important.

The EU AI Act (Regulation (EU) 2024/1689) draws a line that matters for eKYC:

• Biometric verification is the automated one-to-one comparison that confirms a person is who they claim to be, as in a selfie-to-document match. AI used solely for this is excluded from the high-risk list.
• Remote biometric identification, recognising people from a database without their active involvement, usually at a distance, is high-risk, and for some uses an identification must be confirmed by two people before action is taken.
• Some practices are prohibited outright, including untargeted scraping of facial images to build recognition databases, and biometric categorisation that infers race, political views, religion or sexual orientation.
• In the credit context, AI for creditworthiness is high-risk, but systems used to detect financial fraud are carved out.

The exclusion for verification does not take it outside data protection law. Biometric data is sensitive personal data under the GDPR and under Kenya's Data Protection Act.

Timing. The AI Act's prohibitions have applied since 2 February 2025. A 2026 amending regulation (the "digital omnibus") moved the main obligations for high-risk systems listed in Annex III to 2 December 2027.

Human oversight. For high-risk systems the Act requires effective human oversight and awareness of automation bias, the tendency to accept a machine's answer. That principle is worth applying to every eKYC decision, high-risk or not.

In Kenya: the Data Protection Act, 2019 treats biometric data as sensitive personal data and gives people the right not to be subject to a decision based solely on automated processing that significantly affects them, with the right to ask for a new decision not based solely on automated processing. A 2019 government taskforce on distributed ledgers and artificial intelligence recommended using citizen identity for KYC and a digital identity service, but these were recommendations, not adopted policy. The Kenya National AI Strategy 2025–2030 contains no specific provisions on eKYC or biometrics. Check the current position.

Your certificate of completion

Enter your name as you want it to appear, then save the certificate as a PDF. In the print window, choose Save as PDF. A certificate is issued once per completion of the course.

Saolix does not record who takes this course, so it cannot verify these certificates. The certificate confirms completion of a free self-paced course and is not an accredited qualification.