DEV Community: IdentityGeek

VASP Meaning & Full Form: What Is a Virtual Asset Service Provider?

IdentityGeek — Thu, 17 Sep 2026 07:36:30 +0000

VASP stands for virtual asset service provider: any business that exchanges, transfers, custodies, or issues virtual assets on behalf of customers, a FATF-defined category that comes with a specific set of KYC and AML obligations attached. What counts, who's on the hook, and what compliance actually requires.

A founder building a crypto exchange, a custodial wallet, or an OTC desk runs into three different labels for what is, functionally, the same regulatory category, depending on which jurisdiction's paperwork is in front of them: a "VASP" in the FATF's own vocabulary and in most countries' implementing law, a "money services business" if the filing is FinCEN's, or a "crypto-asset service provider" if it's the EU's MiCA framework. It is easy to read one of those terms in a term sheet or a competitor's compliance page and assume it does not apply, on the theory that the business is registered under a different name. It applies anyway.

The Financial Action Task Force defines VASP status by activity, not by label: any natural or legal person conducting virtual asset exchange, transfer, safekeeping, or certain issuance-related financial services for a customer, as a business, meets the definition regardless of what the local license is called. Once a business crosses that line, the same core obligations attach no matter which word is on the registration: customer due diligence, ongoing monitoring, suspicious activity reporting, and, in most jurisdictions now, Travel Rule compliance for outbound transfers.

What Actually Makes a Business a VASP
The FATF added "virtual asset" and "virtual asset service provider" to its Glossary in the June 2019 update to Recommendation 15, extending the same AML and counter-terrorist financing measures that apply to banks and other financial institutions to businesses dealing in crypto. The Interpretive Note to Recommendation 15 sets out five activities that qualify an entity as a VASP when conducted for or on behalf of another person, as a business:

Exchange between virtual assets and fiat currencies
Exchange between one or more forms of virtual assets
Transfer of virtual assets
Safekeeping or administration of virtual assets, or of instruments enabling control over them
Participation in and provision of financial services related to an issuer's offer or sale of a virtual asset

This is deliberately activity-based rather than tied to a specific business model or technology, which is why the FATF's framing holds up across exchanges, wallet providers, and token issuers alike without needing a separate definition for each. A business that does none of these five things for another party is not a VASP, even if it touches crypto in some other capacity; a business that does even one of them, as a service to customers, is.

VASP vs. CASP vs. MSB: The Same Category, Three Different Words
The confusion is almost always terminology, not substance. Each major jurisdiction has bolted the FATF's activity-based test onto its own existing regulatory vocabulary rather than adopting "VASP" as a legal term outright.

United States: "money services business" (MSB)
The Bank Secrecy Act treats a business conducting VASP-qualifying activity involving convertible virtual currency as an MSB and requires it to register with FinCEN, per FinCEN guidance FIN-2019-G001. That federal registration sits alongside, and does not replace, the money transmitter license most states require separately.
European Union: "crypto-asset service provider" (CASP)
Since MiCA's provisions on crypto-asset services took effect, Regulation (EU) 2023/1114, Article 59 licenses the same category as a CASP. A national competent authority grants authorization, which then passports across the EU. See our deeper breakdown of what the transitional deadline meant for firms in MiCA Regulation Deadline Passed.
Most other FATF member jurisdictions: "VASP" directly
Singapore, the UAE, and most jurisdictions that have implemented Recommendation 15 without a domestic MiCA- or BSA-equivalent framework register or license the category as a VASP outright, under whatever national AML statute transposes the FATF standard locally.

Every CASP is a VASP under the FATF's definition. Every MSB dealing in convertible virtual currency is a VASP too. The regulatory label changes; the activity test that triggers it does not.

What Counts: Exchanges, Wallets, OTC Desks, ATMs, and Token Issuers
Mapped against the five FATF activities, the businesses that most often qualify as VASPs are recognizable ones. Centralized crypto exchanges and peer-to-peer trading platforms conduct both fiat-to-virtual-asset and virtual-asset-to-virtual-asset exchange. Custodial wallet providers, the kind that hold private keys on a customer's behalf rather than handing over full self-custody, fall under safekeeping and administration. OTC desks conducting large trades on behalf of clients qualify under exchange or transfer, depending on structure. Crypto ATM operators conduct exchange between fiat and virtual assets at the point of transaction. Token issuers and the platforms that run their offerings can qualify under the fifth activity, participation in an issuer's offer or sale, though the scope here is narrower and depends on what services the platform actually performs rather than simply hosting a listing.

What does not typically qualify is instructive too: a business that only develops non-custodial wallet software, without ever taking control of a user's keys or conducting transactions on their behalf, generally sits outside the definition, since it isn't conducting any of the five activities for another person. The line is control and service, not mere involvement with the technology.

Getting Licensed: What Actually Gets Filed, by Jurisdiction
In the United States, a VASP dealing in convertible virtual currency registers as an MSB with FinCEN by filing Form 107, a federal filing that records the business under the Bank Secrecy Act but does not by itself authorize it to operate. Registration is free and does not replace the money transmitter license most states require separately, each with its own application, bonding, and net-worth requirements.

In the EU, the picture is starker right now. Of the more than 1,200 crypto entities that held national VASP registrations across the EU and EEA before MiCA, only about 17% had converted to full CASP authorization by the July 1, 2026 transitional deadline (Yahoo Finance). As of the July 31, 2026 ESMA register update, 321 firms held CASP authorization (GN Crypto News), and the transitional window that let pre-existing providers keep operating under national law expired EU-wide on that date under Article 143(3) (Elliptic). A national VASP registration issued before MiCA does not convert automatically; a firm has to apply for CASP authorization separately and wait for a national competent authority to grant it, and ESMA's own statement makes clear that firms still mid-application hold no authorization to operate in the meantime.

Elsewhere, licensing generally means direct VASP registration with the national regulator implementing Recommendation 15, on terms that vary by jurisdiction far more than the US or EU frameworks do. There is no substitute for checking the specific requirements of every jurisdiction a VASP intends to serve customers in before onboarding begins there.

The Obligations That Follow: CDD, EDD, Monitoring, SARs, and the Travel Rule
Licensing is the gate. What a VASP actually has to build to stay compliant once it's through that gate is a specific, recurring set of controls.

Customer due diligence (CDD)
Identity verification at onboarding before any account can transact, the baseline every VASP needs regardless of jurisdiction. See how this applies to exchange and on-ramp onboarding specifically in Magic Link KYC/KYB.

Enhanced due diligence (EDD)
Deeper scrutiny for higher-risk customers: large transaction volumes, politically exposed persons, or customers from higher-risk jurisdictions, layered on top of AML screening in AML Screening.

Ongoing transaction monitoring
Continuous review of account activity to catch structuring, unusual counterparties, or deviations from expected behavior after onboarding, not just at the start. Covered in Transaction Monitoring.

Suspicious activity reporting
Filing with the relevant financial intelligence unit when monitoring surfaces activity meeting reporting criteria, built on the same screening and monitoring infrastructure above.

Travel Rule compliance
Collecting and transmitting originator and beneficiary information for transfers above the applicable threshold, per FATF Recommendation 16, to the counterparty VASP receiving the transfer. See how Hypersign captures this data during onboarding in Crypto Travel Rule.

In the EU specifically, MiCA layers additional onboarding and record-retention requirements on top of this baseline, five-year retention of KYC and transaction records among them, which is where a CASP-specific build becomes relevant; see what MiCA's CASP authorization deadline requires for what that adds.

Where This Leaves a VASP Building Its Compliance Stack
Not every VASP needs every piece of this on day one. Travel Rule infrastructure only matters once transfer volume with counterparty VASPs crosses the applicable threshold and cross-VASP transfers are actually part of the business; a VASP that only serves retail customers with no outbound transfers to other providers can reasonably sequence that build later. Enhanced due diligence is a trigger, not a default, applied when a customer's risk profile calls for it rather than run uniformly across every account. A VASP already operating a mature AML program under a national registration has a narrower gap to close than one building from zero, and the gap that matters most is usually whichever jurisdiction's licensing deadline is closest, not the theoretical full list of FATF obligations. The honest answer to "what do we need" is jurisdiction, volume, and risk profile specific, not a single checklist that applies identically to every VASP.

DPDP Act Compliance for Fintech KYC: What Changes, and What Your Stack Needs to Handle It

IdentityGeek — Thu, 17 Sep 2026 07:29:25 +0000

India's DPDP Act doesn't replace RBI's KYC Master Directions it runs alongside them, with a different legal basis, different retention logic, and its own penalties. Here's what that means for a fintech's KYC stack, mapped to the controls that actually satisfy it.

Most fintechs operating in India built their KYC stack around one rulebook: RBI's KYC Master Directions collect documents, verify identity, retain records for years, done. The Digital Personal Data Protection Act 2023 doesn't replace that rulebook. It runs alongside it, with its own legal basis for data collection, its own rules on consent and retention, and its own Data Protection Board that can levy penalties reaching into the hundreds of crores for non-compliance. The compliance deadline gives teams roughly 18 months to get there which sounds like a long runway until you look at what actually has to change underneath a KYC flow that was never designed for it.

Where DPDP Actually Changes Your KYC Flow

The specific obligations that touch KYC directly:

Consent has to be granular and revocable. Pre-checked boxes and bundled consent language don't satisfy DPDP. Regulatory-mandated KYC collection can rely on "legitimate use," but anything beyond it marketing, credit scoring, secondary profiling requires its own explicit, separately revocable consent.
Purpose limitation is enforced, not aspirational. Data collected to verify identity can't quietly get reused for a different purpose without fresh consent tied to that new purpose.
Retention has an expiry, not just a floor. RBI requires KYC records to be kept five years post-relationship, PMLA requires ten years for transaction records that part doesn't change. What changes is that DPDP requires deletion once the legal purpose for holding the data has genuinely ended, which means "keep everything indefinitely in the data warehouse" stops being a safe default.
Data principals get enforceable rights. Access, correction, and deletion requests need a real workflow behind them, not a support email, with a 30-day response expectation.
Vendor contracts need to name DPDP obligations explicitly. An ISO 27001 certificate on a KYC vendor's marketing page isn't a substitute for a contract that limits what that vendor can do with the data, how long they can hold it, and what happens if they're breached.

The Part That Actually Breaks Most KYC Stacks
It's rarely the consent checkbox. It's the retention logic underneath it. Most KYC systems were built to store everything, forever, because storage is cheap and deletion is risky if you get it wrong. DPDP inverts that: indefinite retention is now the risky default, and deletion has to be technically enforced, triggered by a defined event (relationship end, purpose completion, regulatory retention window closing), not left to a policy document nobody automates against. Add a vendor layer collecting biometric selfies, running liveness checks, storing documents and most fintechs discover their retention logic lives in three different systems with three different clocks.

Mapping DPDP Requirements to What a Compliant KYC Stack Needs
Rebuilding this from scratch inside an 18-month window is the hard way to do it. Here's how each requirement maps to infrastructure that should already exist in a KYC platform built for it:

Consent: purpose-based, not blanket
Consent needs to be captured per purpose identity verification, AML screening, document storage, and any marketing or secondary use each accepted or declined independently, versioned, and logged with a timestamp and cryptographic signature rather than a single "I agree" checkbox covering everything at once. When a purpose is withdrawn, systems downstream of that consent record need to actually stop processing for that purpose not just log the withdrawal and continue.

Data minimization: share less by design
The cleanest way to satisfy purpose limitation is to not hold or transmit more data than the purpose requires in the first place. Selective disclosure zero-knowledge proofs that let a verifier confirm "this user is over 18" or "this user passed KYC" without ever receiving the underlying date of birth or document scan turns data minimization from a policy commitment into a structural property of the verification itself.

Retention and deletion: enforced, not documented
Retention windows need to be configurable per data category and per regulatory regime KYC documents on one timeline, biometric templates on another, marketing consent on a third and deletion needs to execute automatically when a window closes: purge the record, anonymise what has to persist for audit purposes, fire a webhook so downstream systems know it happened, and produce a signed erasure certificate as proof. A user's deletion request should complete in seconds, not sit in a queue until the 30-day statutory deadline is nearly missed.

Vendor accountability: signed, auditable, contractual
Every webhook and API call moving verification data between systems should be cryptographically signed, session-scoped, and free of long-lived credentials sitting in a config file. And the data processing agreement with any verification vendor needs to say, explicitly, what DPDP requires it to say not rely on a certification badge to imply it.

India-specific data: handled where the regulator expects it
Aadhaar-based verification carries its own layer on top of DPDP: UIDAI's Offline Paperless KYC framework and masking norms require that only the last four digits of an Aadhaar number are ever returned to a frontend, and that Aadhaar data itself is processed and stored within India regardless of where the rest of a platform's infrastructure lives. That's a narrower, stricter requirement than general DPDP data residency, and it's easy to miss if a KYC vendor treats "data residency" as one setting instead of a per-data-category one.

Where This Gets Easier With Reusable Credentials
There's a second-order benefit that most DPDP compliance work misses: every time a user gets re-verified from scratch, that's another full set of documents collected, another consent captured, another retention clock started. A verifiable credential issued once a user passes KYC something the user holds and can present again lets a second verification event happen through selective disclosure of an already-verified claim, instead of a fresh document upload. Less new data collected per interaction means less data to justify, retain, and eventually delete which is the data minimization principle DPDP is built around, applied structurally rather than procedurally.

What This Looks Like in Practice
Hypersign's platform maps to each of these requirements directly rather than requiring a fintech to bolt DPDP logic onto an existing KYC stack:

Consent management with purpose-based granular consent (identity verification, AML screening, document storage, marketing kept independently revocable), a timestamped and cryptographically signed audit trail, and consent receipts issued as W3C Verifiable Credentials DPDP Act 2023 is a configurable jurisdiction preset alongside GDPR and eIDAS 2.0.
An identity vault with AES-256 encryption at rest, per-customer encryption keys, and access control that checks for active, purpose-matched consent before returning any record access is denied automatically if consent has been withdrawn, expired, or doesn't match the requested purpose.
A right-to-erasure engine that purges and anonymises records, fires a webhook, and issues a signed erasure certificate on request, with configurable retention windows per data category well inside the 30-day statutory response window DPDP sets for data principal requests.
Selective disclosure via zero-knowledge proofs and BBS+ signatures, so a verifier can receive a pass/fail or threshold result without the underlying document or biometric ever leaving the vault.
Aadhaar verification handled the way UIDAI requires it masked to the last four digits on return, processed and stored within India, through a licensed Sub-AUA partner for OTP-based eKYC or UIDAI's Offline Paperless KYC framework for QR/XML verification.
Signed, session-scoped API and webhook architecture HMAC-SHA256 signed callbacks, no long-lived credentials with data processing agreements in place for every sub-processor, and audit-ready SOC 2 Type I and ISO/IEC 27001:2022 controls.

None of this replaces a fintech's obligation to run its own DPDP gap analysis RBI's retention timelines, PMLA's transaction record requirements, and DPDP's purpose-based deletion still have to be reconciled against each other for a specific business. What infrastructure like this changes is how much of that reconciliation has to be built from zero versus configured against controls that were designed for exactly this overlap.

MiCA Regulation Deadline Passed: What Unlicensed Exchanges Must Fix

IdentityGeek — Wed, 16 Sep 2026 11:40:45 +0000

The MiCA CASP authorization deadline passed on July 1, 2026, and most European crypto exchanges are still unlicensed. This is a triage guide for firms mid-application or still exposed: what ESMA's wind-down statement actually requires this week, and why the AML and travel-rule infrastructure exchanges are racing to build now will need to be rebuilt again the moment inter-CASP data exchange kicks in, unless it's built on reusable credentials from the start.

If you're reading this in mid-September 2026, the MiCA transitional period isn't a future risk you're planning around. It's a deadline that closed six weeks ago, and the compliance status of your exchange changed the moment it did. Article 143(3) of the Markets in Crypto-Assets Regulation gave pre-existing crypto-asset service providers an 18-month maximum window to keep operating under national law while they pursued full CASP authorization. That window expired EU-wide on July 1, 2026 (Elliptic). From that date, Article 59 applies without exception: providing crypto-asset services to EU clients without CASP authorization is a breach of EU law, full stop.

MiCA Regulation for Crypto Exchanges: Where Enforcement Stands in August 2026

The Numbers Behind the Deadline Passing

The scale of the miss is worth sitting with. Of the more than 1,200 crypto entities that held national VASP registrations across the EU and EEA before MiCA, only about 210 had converted to full CASP authorization, what the industry commonly shorthands as a MiCA license, by the July 1 cutoff, a conversion rate of roughly 17% (Yahoo Finance). That leaves 83% of Europe's crypto firms without a MiCA license as the deadline arrived, and as that Yahoo Finance analysis put it, "the other 83% either missed the window, are mid-process with no legal standing to continue operating, or have quietly exited."

ESMA's public register is the ground truth here, and it's moving weekly. As of the July 31, 2026 update, its fourth revision since the transitional deadline, ESMA listed 321 authorised CASPs and 41 e-money token issuers, alongside 167 entities on its non-compliant register, including three new notifications from Italy's CONSOB that cycle (GN Crypto News). An earlier snapshot of 213 authorised CASPs across 23 jurisdictions had Germany leading with 55, followed by the Netherlands (26), France (19), Malta (15), and Ireland and Cyprus tied at 12 each, with the top five jurisdictions accounting for roughly 60% of all authorizations (Elliptic). That was captured before the total count passed 320, so treat it as a picture of which regulators moved first, not the current tally.

Not every firm was working against the same July 1 date, either. Several member states set shorter national transitional periods that closed months earlier: Latvia, Hungary, the Netherlands, Poland, and Slovenia cut theirs to six months, closing in mid-2025, well ahead of the EU-wide backstop (Zyphe). If your exchange operates across multiple member states, the rule is the earliest deadline among all of them governs you, not the EU-wide July 1 date. A firm that assumed it had until July 1 because that's the headline date may have already been in breach for the better part of a year in the jurisdictions that moved first.

What "Technically in Breach of EU Law" Means Day to Day

`"There is no intermediate status after July 1. A firm is either authorized under MiCA or it is in breach of EU law."

ESMA's position, as reported by Yahoo Finance`

Having submitted an application, having a hearing scheduled with your national competent authority, or being weeks from a decision doesn't change your status. Pending authorization confers no right to keep onboarding, marketing, or trading with EU clients in the interim.

For a firm in this position, the immediate reality is exposure on two fronts: to enforcement action from national competent authorities, and to a reputational signal to counterparties and clients that your exchange is operating outside its regulatory perimeter. Neither resolves until authorization is granted or you wind down.

The MiCA CASP Authorization Deadline Passed: What ESMA's July 1 Statement Changes for Firms Mid-Application

ESMA didn't wait for the deadline to pass in silence. On June 23, 2026, ahead of the July 1 cutoff, it published a public statement calling on unauthorised crypto-asset service providers to wind down in an orderly manner while safeguarding client interests (AMF France). That statement is the operative guidance for any exchange still in the queue, and it's worth reading as instructions, not commentary.

No Grace Period, No Intermediate Status
ESMA's statement instructs unauthorised CASPs to immediately stop onboarding new EU clients, stop opening new accounts, and stop all marketing and solicitation activity. Services should be limited to what's necessary to let existing clients sell or transfer their assets and close positions, an orderly exit, not a continuation of business as usual under a different label (AMF France).

Reverse solicitation is not the workaround some firms are hoping it is. Article 61 permits serving EU clients without authorization only when the client initiates contact entirely on their own, and ESMA reads that exception narrowly: any advertising, app store listing, affiliate arrangement, influencer post, or search marketing aimed at EU users breaks the exception (Elliptic). If your growth team ran a campaign targeting EU users last quarter, the clients who signed up through it don't count as reverse-solicited, regardless of how the account was technically opened.

Critically, the wind-down obligation doesn't relax AML and CFT duties. Unauthorised providers must maintain full customer due diligence, transaction monitoring, sanctions screening, and record-keeping for the entire exit period, not just during active client relationships (AMF France). You don't get to stop verifying identities just because you've stopped taking new business.

The Three Paths Left Open: Authorize, Passport, or Wind Down

For an exchange without CASP authorization today, there are exactly three viable paths, and ESMA's statement makes clear there isn't a fourth:

Complete authorization (get a MiCA license)
Finish the CASP application with your national competent authority, including documented AML controls, capital requirements, and governance. Best fit for firms with an application already in progress and the resources to see it through.

Rely on an existing CASP passport
Operate as a tied agent or through a partnership with an already-authorised CASP under MiCA's passporting provisions. Best fit for firms that can't clear authorization alone but have a credible partner relationship.

Wind down orderly
Stop onboarding and marketing immediately, close out or transfer existing positions, maintain AML obligations throughout. Best fit for firms that missed the window with no near-term path to authorization.

There's no fourth path for "keep operating quietly while the application is pending." That option closed on July 1.

What National Regulators Expect From Firms Still in the Queue

If you're mid-application, your national competent authority expects to see the same wind-down discipline ESMA describes applied to the parts of your business that fall outside what you're authorized to do today. That means: no new EU client onboarding until authorization clears, continued and demonstrable AML/CFT controls, and clear, repeated communication with existing clients about asset protection and any exit timeline that applies.

"Communicate clearly, promptly and repeatedly with clients (retail and institutional) about the measures taken to safeguard their assets and the wind-down plans."
ESMA's public statement, via AMF France

Silence, or a single blog post announcing "we're working on it," doesn't meet that bar.

One detail that catches firms off guard: if you transfer clients to an already-authorised CASP as part of a wind-down or a partnership, the receiving CASP has to run full onboarding, including fresh KYC checks, on every client it takes on (AMF France). Your existing verification records don't travel with the client. That's not a compliance footnote, it's the same reverification problem that's about to define the next section of this post.

The KYC Rebuild Trap: Why Exchanges Racing to Get Licensed Are Re-Architecting Twice

Here's the trap firms are walking into right now. Under deadline pressure, an exchange builds or buys whatever AML and KYC infrastructure clears its national competent authority's bar for CASP authorization, ships it, and treats the box as checked. Then the travel rule and inter-CASP data-exchange requirements land on top of a system that was never designed to hand data to another provider, and the exchange is back in a build cycle it thought was finished.

Why a National VASP-Era KYC Stack Doesn't Clear CASP Authorization

MiCA licensing is conditioned on demonstrating AML readiness before authorization is granted, not after. Regulators won't license a firm without proof of "robust internal controls, policies, and procedures" for managing money-laundering risk already in place (Flagright). A KYC stack built to satisfy a national VASP registration, often a lighter-touch regime with looser documentation and monitoring standards, generally doesn't clear that bar on its own. It has to be extended: five-year retention of transaction records, KYC documentation, and compliance decisions, with a complete, immutable audit trail showing who reviewed what and when (Flagright). "Audit-ready" isn't a phrase for application day. Under MiCA, it's a standing requirement.

The Travel Rule and Inter-CASP Data Exchange Nobody Budgeted For

The Crypto Travel Rule, MiCA's implementation of the FATF's Recommendation 16 standard for virtual-asset transfers, is where a lot of AML rebuilds run into their second wall. CASPs must collect and transmit originator and beneficiary information for any transfer of EUR 1,000 or more moving to another VASP, and doing that requires infrastructure to exchange that data with counterparty CASPs, either built in-house or bought as a third-party solution (Flagright). Most national-registration-era KYC systems were built to verify a user once, internally, and store the result. They weren't built to package identity data for transmission to a counterparty's compliance system on every qualifying transfer. That's a structurally different requirement, not an incremental one, and it's exactly the kind of thing that gets discovered mid-application rather than planned for at the start.

The Hidden Cost of Building AML Infrastructure Under Deadline Pressure
The real cost of racing to build this under deadline pressure isn't the first build. It's the second one. An exchange that stands up KYC and AML infrastructure fast enough to clear authorization, using whatever document-verification vendor or in-house system was quickest to integrate, is optimizing for a single checkpoint: the application review. But the travel rule's inter-CASP data-exchange requirement and the five-year audit-trail obligation both assume identity data that's portable and cryptographically verifiable at the point of transfer, not a scanned passport sitting in a centralized database that has to be manually packaged for every counterparty request.

Firms that build for the checkpoint end up re-architecting once authorization clears and the travel-rule and passporting demands start hitting in production. That's two builds, two integration cycles, and two rounds of vendor risk, all to solve what is, underneath, one problem: proving who a client is, in a form that can move with them.

Where Reusable Credentials Shorten the Path From Application to Authorization

A credential-based KYC stack collapses that two-step rebuild into one, because it's built around portability from day one rather than bolting portability on after the fact.

Verify-Once-Use-Everywhere vs. Rebuilding Onboarding From Scratch

The alternative to a document-storing, single-use verification model is one built on verifiable credentials: a user completes identity verification once, and the result is issued as a W3C-standard verifiable credential the user holds in their own encrypted vault, not a record locked inside your database (Hypersign, on Web3 KYC provider comparisons). That single credential can then be presented, with the user's consent, to any platform or counterparty that accepts it, without re-collecting documents or rerunning verification from scratch. Hypersign's own writing on this describes reusable KYC as "the practice of completing identity verification once and carrying that verified status as a portable credential presentable to any platform that accepts it," with the model already live across platforms including projects on Nibiru Chain (Hypersign). That's the claim, not the document, moving between systems, and it's the structural shift that makes inter-CASP data exchange tractable instead of a bolt-on integration project.

What a Credential-Based Stack Gets Exchanges That a Ground-Up Build Can't

Walk through what that difference looks like on a single transfer. A CASP authorised in Ireland receives a EUR 1,500 transfer instruction from a counterparty CASP in Germany, above the travel rule's EUR 1,000 threshold, so originator and beneficiary information has to move with it. Under a document-storing KYC system, clearing that request usually means a compliance analyst pulling the client's file, manually extracting the specific fields the travel rule requires (full name, wallet address, and, where the counterparty asks for it, a national ID reference), redacting everything outside that request, and sending it back, a manual step repeated for every qualifying transfer to every counterparty. Under a credential-based system, the German CASP's request specifies the exact claims it needs; the client's wallet presents only those fields from the verifiable credential already on file, cryptographically signed by the original issuer, and the Irish CASP's system checks the signature chain instead of reopening the underlying document. That's not a modest speed gain. It's the difference between a repeatable, API-level presentation and a manual compliance task redone for every counterparty request.

Concretely, a credential-based architecture changes three things a ground-up build has to solve independently:

Data doesn't sit in one custodial database. The credential is held by the user in an encrypted vault; Hypersign doesn't retain the underlying documents (Hypersign, on validator KYC). That directly narrows the single-point-of-failure exposure a centralized KYC database represents, which matters given how much scrutiny data-breach exposure at document-storing KYC vendors has drawn in this sector.
Transfer is a presentation, not a re-verification. When a client moves to an authorised CASP, or when a counterparty CASP needs originator/beneficiary proof under the travel rule, the receiving party can request a specific claim from the credential rather than triggering a full document reverification cycle.
Compliance signals travel with the credential. AML screening results and risk scores can be embedded in the credential itself, cryptographically bound so they can't be transferred between individuals, rather than living in a separate system that has to be queried and reconciled on every hop.

Mapping Verifiable Credentials to ESMA's Documented-Evidence Expectations

None of this is a substitute for CASP authorization, and it's worth being precise about that boundary: reusable credentials don't get you licensed, they change how expensive it is to build the evidence layer authorization and the travel rule both require. ESMA's expectations, and MiCA's five-year retention rule, come down to being able to show, on demand, who was verified, when, by what standard, and what happened to that verification afterward (Flagright). A verifiable credential carries that provenance natively: issuer, timestamp, and status are part of its structure, not metadata bolted onto a document scan after the fact. That's a smaller gap to close between "verified for authorization" and "auditable for the travel rule and inter-CASP exchange" than a system built around static document storage ever gets to on its own.

What Unlicensed Exchanges Should Do Now
Under the EU MiCA framework, the right next step depends on where your exchange actually sits today, mid-application or not yet in the queue, and the two paths diverge from here.

If You're Mid-Application
Stop onboarding and marketing to new EU clients immediately if you haven't already; that instruction from ESMA's statement isn't optional guidance, it's the baseline for staying inside the wind-down exception rather than active breach (AMF France). Audit your current KYC and AML stack specifically against the travel rule's inter-CASP data-exchange requirement, not just against your national competent authority's authorization checklist, because that second requirement is the one most application-stage builds haven't tested yet. If your verification data is locked in a proprietary format that can't be exported or presented to a counterparty CASP, that's the rebuild waiting for you on the other side of authorization, and it's cheaper to address now than after your license is granted.

If You Haven't Applied Yet
Don't build the AML and KYC layer to clear the application checkpoint alone. Build it to satisfy the travel rule's data-portability demands from the start, so authorization and inter-CASP readiness are the same project instead of two. Evaluate whether a credential-based vendor gets you to defensible, audit-ready MiCA compliance faster than an in-house build, and be honest about where you are in the queue: national competent authorities are processing a large backlog, and firms that haven't yet filed are, by definition, further from authorized status than the roughly one in six firms that already converted. Review Hypersign's documentation at docs.hypersign.id for the technical detail on how credential issuance and verification work, and see how a verify-once model maps onto your specific onboarding flow before you commit engineering time to a build you may have to redo.

eIDAS 2.0 Is Coming for Document-Based KYC: What a Credential-Ready Stack Actually Needs

IdentityGeek — Thu, 10 Sep 2026 10:32:47 +0000

Most KYC platforms verify a person by scanning a document: OCR the passport, check the security features, compare the photo, done. eIDAS 2.0 and the EU Digital Identity Wallet are built around a different object entirely a cryptographically signed credential that a user holds and presents, verified by checking a signature and a trust chain, not by inspecting a photo of a physical ID. Those are two different verification models, and the regulatory timeline that forces the switch is no longer theoretical.

The Timeline That Makes This Non-Optional

eIDAS 2.0 (Regulation (EU) 2024/1183) entered into force in 2024, requiring every EU Member State to offer citizens a government-backed European Digital Identity Wallet.
By the end of 2026, Member States are expected to have EUDI Wallets available, with cross-border interoperability testing already underway in several countries.
By December 2027, large regulated private-sector relying parties banks, fintechs, insurers, telecoms are required to accept the EUDI Wallet for authentication.
The EU's Anti-Money Laundering Regulation (AMLR) reaches full application on a similar 2027 timeline, and narrows the identity verification methods regulated entities can rely on to eIDAS-notified national digital ID schemes, the EU Digital Identity Wallet, or qualified trust services under eIDAS. A verification flow built entirely around scanning a passport photo isn't one of the three.

Why the Document-Scanning Model Doesn't Map to a Wallet-Based One

The EUDI Wallet doesn't hand a relying party a document image to inspect. It presents a Verifiable Credential or an mDL-style attestation issued by a trusted authority, cryptographically signed, and selectively disclosed the wallet holder controls exactly which attributes get shared for a given request. Verifying that means validating a signature and a trust chain against a registry of trusted issuers, not running OCR and a hologram check. A platform whose entire verification pipeline assumes "here is a photo of a document" as the input has nothing to do with an input that arrives as a signed credential. That's not a configuration gap. It's a different verification model, and retrofitting one onto the other under deadline pressure is a worse position than building for it now.

The parts of a KYC stack that specifically don't carry over: document image capture and OCR pipelines, physical security-feature detection (holograms, microprint), and manual document-authenticity review queues built entirely around ID photos. What does carry over and matters more under eIDAS 2.0: fraud and risk scoring, AML and sanctions screening, case management, and audit logging all of which still have to run, just against a different kind of verified input.

What a Credential-Ready Stack Needs to Support

W3C Verifiable Credentials and DID-based issuance the underlying data model the EUDI Wallet and most credential-based verification systems are built on.
Selective disclosure at the attribute level so a relying party requests and receives only the specific claim it needs (age over a threshold, KYC status, nationality) rather than a full identity document, in line with GDPR's data minimization principle that AMLR and eIDAS 2.0 both lean on.
Cryptographic trust-chain validation checking a credential's signature and issuer chain against a trust registry, instead of a human or an OCR model inspecting a document image.
Credential revocation that's checkable without contacting the issuer a relying party needs to confirm a credential hasn't been revoked in real time, without a synchronous callback to whoever issued it.
Audit trails built for verification events, not document uploads a regulator asking "how was this person verified" needs a record of which credential was presented, which claims were disclosed, and how the signature was validated not a stored copy of a passport scan.

Notably absent from what a compliant stack strictly needs: a vendor that files your relying-party registration with a national eIDAS authority for you. That registration, and the legal work of confirming your specific AMLR obligations, stays with the business relying party status isn't something infrastructure can hold on your behalf.

Where Hypersign Maps to This

A full W3C DID Core and Verifiable Credential stack (VC 1.1/2.0), with EdDSA/Ed25519, ES256K/Secp256k1, and BBS+ signature support, issuing credentials aligned with the eIDAS 2.0 framework and EUDI Wallet specification any eIDAS 2.0 compliant relying party can verify them.
Selective disclosure through zero-knowledge and BBS+ proofs, so a relying party gets a pass/fail or threshold answer age over 18, KYC passed instead of the underlying document, matching the attribute-level disclosure the EUDI Wallet is built around.
An on-chain Credential Revocation Registry using a bitstring status list, so revocation status is globally queryable in real time without a callback to the original issuer.
Reusable KYC credentials a user verified once can present that credential to any connected relying party, rather than re-running document capture at every new platform which is the same "verify once" shape eIDAS 2.0 is standardising at the EU level.
Selective disclosure explicitly built as AMLR-ready, aligned with the narrower set of verification methods AMLR permits from 2027.

What this doesn't do: register your business as a relying party with a national eIDAS authority, or make your specific AMLR gap analysis for you. Those are legal and regulatory steps a business has to complete itself. What credential-ready infrastructure changes is whether your verification pipeline can actually ingest, validate, and audit a wallet-based credential when a user shows up with one or whether that becomes a rebuild under a 2027 deadline instead of a capability you already have.

Why Compliance Kills Early-Stage Projects and How to Fix It

IdentityGeek — Tue, 08 Sep 2026 06:30:22 +0000

Compliance itself isn't the villain. The problem is a system designed for large banks being forced onto small teams who measure time in sprints, not fiscal quarters.

Innovation was never meant to wait for permission. It's supposed to be fast, chaotic, and full of discovery. But for anyone who has tried to launch a startup especially in Web3, fintech, or any regulated space there is a familiar slowdown that begins the moment compliance enters the conversation. Everything feels alive until the first "verification required" email arrives. That's when the waiting begins.

Compliance itself isn't the villain. It protects systems from fraud, builds trust between unknown parties, and ensures accountability. But the way compliance exists today feels like a relic a system designed for large banks, traditional corporations, and legal departments with infinite patience and paperwork. For small teams who measure time in sprints, this system simply doesn't fit.

The Repetition Tax

Most founders encounter the compliance disconnect the moment they try to grow. After building their MVP and testing their product, they reach the stage where partnerships or investors arrive and suddenly they're asked to complete KYB (Know Your Business) verification again and again. Each time a new partner or service provider comes aboard, the process restarts: upload documents, verify directors, prove legitimacy. It's not that startups resist compliance; they simply don't understand why they must prove the same truth multiple times to different counterparties who have no way to see each other's work.

This endless repetition creates what many founders now call the repetition tax. It isn't paid in money but in time and motivation. The same hours that could have gone into improving a product or connecting with users are swallowed by forms, follow-ups, and "under review" messages. And crucially, all this duplicated effort doesn't make the system any safer it just makes it slower.

The Security Paradox

There is a quiet irony in how the very systems meant to protect organisations often become the weakest part of the ecosystem. Most KYB and identity verification data sits in centralised databases controlled by third-party vendors. These systems hold everything: company registration documents, director IDs, legal filings all in one place, shared across every client the vendor serves. As recent breaches have demonstrated repeatedly, every centralised system becomes a target. A single compromised credential can expose thousands of companies at once. For a small startup, recovering from that kind of exposure is almost impossible.

The compliance process focused so heavily on collecting verification data that it forgot to ask the harder question: is aggregating all of that data in one place actually safe? The answer, increasingly, is no.

Compliance Fatigue: The Human Cost

Beyond the security risk, there is a quieter, more human cost. Founders now describe something called compliance fatigue the slow emotional drain that comes from doing everything right yet constantly feeling behind. Teams begin the week focused on new features and end it buried in forms. The excitement that once fuelled late nights turns into frustration. Over time, creativity disappears beneath administrative weight.

A founder in India trying to verify a contributor in Germany shouldn't have to wait two weeks for a manual review. A small Web3 DAO shouldn't need enterprise-level legal infrastructure just to onboard new members. Yet that's exactly where the digital economy stands still running analog processes while pretending to move fast.

The real cost isn't paperwork or even time. It's velocity the invisible rhythm that determines whether a startup grows or fades. Every delay chips away at confidence. Every form adds friction. Slowly, projects lose their heartbeat. Compliance doesn't destroy innovation in a single moment; it wears it down, piece by piece, until the spark is gone.

What a Better System Looks Like

The solution isn't weaker compliance it's smarter compliance. The shift required is from static databases to portable, reusable trust.

When a business completes KYB verification once and receives a cryptographically signed verifiable credential, that credential can be presented to any future partner or platform that accepts it. The next counterparty doesn't restart the process they verify the credential's authenticity in seconds and move on. The company proves its legitimacy once; every subsequent verification is a proof exchange, not a fresh submission.

This is the architecture that removes the repetition tax without removing accountability. It eliminates the centralised data aggregation that creates breach risk. It gives founders back the time they were losing to forms and follow-ups. And it preserves the trust and fraud prevention function that compliance was always supposed to serve just without the friction that made it hostile to growth.

Compliance as Guardian, Not Gatekeeper
The cultural gap between regulators and founders is real but not insurmountable. Regulators think in decades; founders think in days. Neither is wrong. But when systems designed for one world are forced onto the other, friction is inevitable and that friction has a cost that shows up in every startup that gave up because the compliance burden was too heavy.

Every project that abandons growth because verification was too slow represents more than a failed business. It's a missed idea, a lost opportunity, a piece of progress that never reached the world. Multiply that across industries, and what's at stake isn't just innovation it's the collective potential of an entire generation of builders.

Compliance was never supposed to be a bottleneck. It was designed to be a framework that kept innovation safe. Somewhere along the way, it became a gatekeeper instead of a guardian. The tools now exist to rebuild it not to make it weaker, but to make it work for the people it was always meant to serve.

OpenID Foundation Wants to Standardize US mDLs as Verifiable Credentials: What It Means for KYC Teams

IdentityGeek — Mon, 07 Sep 2026 07:26:19 +0000

Two new OpenID Foundation papers tackle a real gap: the US has no centralized trust framework for mobile driver's licenses, and financial institutions have no standard way to read one. Here's what the initiative actually proposes, and where a credential-based KYC architecture already lines up with it.

On November 7, 2025, the OpenID Foundation published two technical papers aimed at a specific, underserved problem: US mobile driver's licenses (mDLs) are issued state by state, with no shared trust framework telling a financial institution how to evaluate one. "This work is key to making deployments viable in the United States where no other trust framework exists," said George Fletcher of the OpenID Foundation. The papers "mDL Metadata Requirements to support Know Your Customer (KYC)" and "Customer Identification Program (CIP) compliance and OIDF Extended KYC Considerations" propose standardized, machine-readable metadata so a relying party can evaluate an mDL's provenance, assurance level, and compliance status programmatically, instead of state by state, implementation by implementation.

The Problem Being Solved

As the OpenID Foundation put it: "Without standardized metadata, financial institutions face fragmented implementations that increase operational risk, compliance audits, and undermine assurance for account opening processes." Every state that issues an mDL does so slightly differently. Without a common metadata layer, a bank evaluating a digital driver's license from one state has no standardized way to compare it against one from another, or to confirm how it was issued, what assurance level it meets, or whether it's still valid. That's an interoperability gap and interoperability gaps are exploitable. Identity standards architect Juliana Cafik was direct about the stakes: "fragmented standards create exploitable gaps for synthetic identities, deepfake-driven onboarding, and AI-enabled attack surrogates."

The Underlying Shift: mDLs as Verifiable Credentials

The reason this initiative matters beyond the US mDL context is the model it's built on. Treating a driver's license as a verifiable credential means restructuring identity verification around three roles issuer (the state DMV), holder (the citizen's wallet), and verifier (the bank or platform doing KYC) with cryptographic signatures doing the work a human reviewing a plastic card or a scanned PDF417 barcode used to do. A verifier doesn't inspect the document; it checks a signature chain back to a trusted issuer and reads standardized metadata about assurance level and status. That's a structural shift in what "verifying an ID" means, and it's the same shift already underway in the EU through eIDAS 2.0 and the EU Digital Identity Wallet just arriving in the US through a different standards body and a different regulatory path.

Where a Credential-Based Architecture Already Lines Up With This

Hypersign issues identity verification results as W3C Verifiable Credentials on exactly the issuer-holder-verifier model this initiative is standardizing for mDLs: a credential is issued after verification, held by the user, and checked by any relying party against a signature and an on-chain revocation registry no synchronous callback to the original issuer required. That's the same architectural shape a bank checking mDL metadata would need: a verifiable, machine-readable trust signal instead of a document inspection.

To be direct about scope: Hypersign does not today natively ingest the ISO/IEC 18013-5 mdoc wire format an mDL wallet speaks, or implement the OpenID4VP/OpenID4VCI presentation flows this specific initiative is built around. What's already in place is the credential architecture underneath document verification (currently covering 14,000+ document types across 189+ countries, including physical and scanned driver's licenses today) that produces the same kind of portable, cryptographically checkable output an mDL-as-VC framework is standardizing toward. Businesses building compliance infrastructure on that model now aren't rebuilding their verification pipeline later they're extending a wire format, not replacing an architecture.

The Fraud Problem This Is Actually Trying to Close

Cafik's warning about synthetic identities and deepfake-driven onboarding isn't abstract it's the specific failure mode fragmented, undocumented trust metadata enables. If a verifier can't confirm how a credential was issued or whether it's still valid, an attacker only needs to defeat the weakest implementation in the fragmented landscape, not the strongest. This is where the identity side of the stack has to carry equal weight to the metadata standard: deepfake detection analyzing facial geometry, texture consistency, and temporal signals to catch synthetic or manipulated faces before a credential is ever issued, plus cross-session duplicate detection that flags a document number, face hash, or device fingerprint reappearing under a different email or user ID even when each individual session looks clean on its own. Standardized credential metadata answers "is this a valid mDL." Fraud detection at the point of issuance answers "was this a real person to begin with." Both have to hold for the trust chain to mean anything.

What This Means for Compliance Teams Today

Financial institutions and other regulated verifiers don't need to wait for a finished US mDL trust framework to start benefiting from this shift. The practical move is the same one already playing out around eIDAS 2.0 in the EU: build KYC around verifiable, holder-controlled credentials and selective disclosure so a verifier receives only the specific claim it needs like age, KYC status, or document validity rather than a full document image, and design fraud detection to catch synthetic identity and deepfake attempts before a credential is ever issued, not after. When a standardized mDL trust framework does land, that KYC pipeline is extending a metadata format it's not rebuilding a verification model from scratch under deadline pressure.

Pages worth reviewing if you're evaluating this for your own stack:

Verifiable Credentials the issuer-holder-verifier architecture this initiative is standardizing mDLs toward.

Selective Disclosure & Zero-Knowledge Proofs sharing only the claim a verifier needs, not the full document.

Biometric Verification deepfake and synthetic identity detection at the point of onboarding.

Zero-Knowledge Biometric Verification, Explained

IdentityGeek — Tue, 01 Sep 2026 06:49:38 +0000

Zero-knowledge proofs let a verifier confirm a face matches an ID, or that a liveness check passed, without ever holding the raw biometric data. Here's how the mechanism actually works, what it prevents, and how close the identity industry is to shipping it in production KYC.

Every biometric verification vendor holds a face. Somewhere in its pipeline, encrypted at rest or not, sits the selfie captured at onboarding, or at minimum the feature vector extracted from it, the data a face-match algorithm needs to compare against an identity document's photo. That data has to exist somewhere for the comparison to run, or so the assumption goes, and it's the assumption behind every biometric vendor's retention policy, every breach-notification clause in a KYC contract, and every regulator's demand for encryption-at-rest audits on data GDPR already classifies as special category. Zero-knowledge proofs applied to biometric data start from a different premise: the comparison can happen and a verifier can trust the result without the verifier, or anyone downstream of the enrollment step, ever holding the raw face data that produced it.

This is a narrower and newer problem than the zero-knowledge work most identity teams have already encountered. Verifiable Credentials and Zero-Knowledge Proofs, Explained covers zero-knowledge proofs applied to a credential's fields, proving a birthdate claim without revealing the birthdate itself. Applying the same cryptographic idea to biometric data, a face template or a liveness result rather than a declared attribute, is a different and less-covered piece of the same puzzle. This post works through what zero-knowledge biometric verification actually is, how it differs from the credential-level version, and how close the identity industry actually is to shipping it in a production KYC flow rather than a research paper.

Biometric Verification vs. Zero-Knowledge Proofs: Where They Meet

Biometric verification today runs the same basic pipeline across nearly every vendor: a user captures a selfie or a short video, the system compares it against the photo on a submitted identity document, a similarity score comes back, and a liveness check confirms the person is physically present rather than a photo, a screen replay, or a synthetic video. Hypersign's own biometric verification stack runs this exact chain, face match, active and passive liveness, deepfake detection, and anti-spoofing, and so does every established competitor in the category. Nowhere in that chain does the raw face data need to stop existing after the check completes. Most vendors retain a template, a derived selfie, or both, for audit and dispute purposes, which is precisely the data a breach would expose.

A zero-knowledge proof, briefly, is a cryptographic technique that lets one party prove a statement is true to another party without revealing anything beyond the truth of that statement, covered in more depth in the post linked above. The gap this post addresses is that nearly all production zero-knowledge identity work so far proves something about a credential's declared field, age over 18, residency in a given jurisdiction, a KYC tier already reached. Proving something about biometric data itself, that a live capture matches a stored template, or that a liveness check passed, without either capture ever crossing the wire, is a different application of the same underlying math, and one that has barely reached production anywhere in the identity industry.

Hypersign sits at an unusual starting point for that gap. Its biometric verification product runs face match, liveness, and anti-spoofing in production today, and its selective disclosure layer already runs zero-knowledge threshold proofs in its KYC widget today, just over credential attributes rather than biometric templates. That is not a claim that the two are combined yet, they are not, but it is a different position than either a KYC vendor with no zero-knowledge work at all, or a cryptography project with no production biometric pipeline to attach it to.

How Zero-Knowledge Biometric Verification Actually Works

The mechanism starts at capture. Instead of transmitting a selfie or its extracted feature vector to a verifier, the system generates a cryptographic commitment to the template, a one-way binding that can be checked against later without being reversible back to the original face. BioZero, an academic protocol for on-chain biometric authentication, describes exactly this construction: homomorphic commitments paired with zero-knowledge proofs, producing an authentication decision that's publicly verifiable while the underlying biometric template stays hidden from every party, including the verifier.

At verification time, a new capture runs through a proving circuit, typically a zk-SNARK, that proves the distance between the new capture and the committed template falls under a matching threshold, without revealing either the new capture or the stored template to the party checking the proof. ZKP-Identity, an open-source attribute-verification system, builds this kind of circuit with Circom and the Groth16 proving system, a concrete example of the tooling this class of proof actually runs on rather than an abstraction. zkBiometric applies the same idea specifically to biometric identity, using RISC Zero's zkVM so a service provider can verify an identity claim without ever accessing the sensitive biometric data behind it.

Not every ZK-adjacent identity project operates at this exact layer. Rarimo's passport-zk-circuits is a real, working, open-source implementation, and it deserves credit as one, but it proves something narrower: that a passport's embedded chip signature is valid and tied to a unique identity, letting a holder skip re-scanning a physical document. That's zero-knowledge work over a document's cryptographic signature, not over a face template, a useful and shipped piece of the identity stack, just not the same proof this post is describing.

The same construction extends to liveness. A circuit can attest that a capture passed a liveness check, blink detected, head movement validated, texture and depth signals consistent with a real human, as part of the same proof, without the video or image that produced that result ever leaving the device or the verification enclave.

What This Actually Prevents

GDPR Article 9 classifies biometric data used for unique identification as a special category, subject to stricter processing conditions than ordinary personal data, precisely because it carries a risk a password does not: a face cannot be rotated after a breach the way a credential can. Every biometric vendor holding raw templates or selfies at scale is a concentrated target, and the retention itself, not just weak security around it, is the exposure. A zero-knowledge biometric proof removes that target by design, there is no centrally held template to exfiltrate, only a one-way commitment that reveals nothing about the underlying face even if it leaks.

Where This Fits with Liveness Detection and Deepfakes
As covered in Deepfakes in 2025: How Liveness Detection Stays Ahead, the raw video or image a liveness check produces is itself becoming a liability worth minimizing, not just a technical artifact to secure. Every stored liveness capture is one more piece of biometric data that could inform a future deepfake targeting the same subject, or simply another record a vendor has to defend under the same GDPR Article 9 obligations described above. A zero-knowledge liveness proof would let the pass or fail result travel to a verifier while the capture that produced it never leaves the device or the enclave it was generated in. This is a forward-looking framing rather than a description of standard practice, no major liveness engine ships this today, but it follows directly from the same commitment-and-proof mechanism already running in projects like zkBiometric.

Why This Isn't Mainstream in KYC Yet

A direct search for zero-knowledge biometric verification today surfaces academic papers, open-source repositories, and Web3-native identity projects, not a single established KYC or identity-verification vendor. None of the major players in document and biometric verification have a shipped, production zero-knowledge biometric proof in market. What exists in production lives almost entirely in on-chain identity projects, passport-zk-circuits, zkBiometric, and research work like BioZero, rather than mainstream fintech or exchange onboarding flows.

Part of the reason is operational, not just inertia. A KYC audit trail traditionally rests on a retained record a compliance team can point to later, a stored selfie, a match score, a decision log. A zero-knowledge proof, by design, discards the underlying data that produced the result, which means the industry still has to work out what a defensible audit trail looks like when the thing being audited is a cryptographic proof rather than a retained transcript. That's an open regulatory and operational question, not a solved one, and any post claiming otherwise is overselling where the category actually stands..

Where Hypersign's Two Halves Meet

Hypersign runs production biometric verification, face match, active and passive liveness, deepfake detection, and anti-spoofing, at /platform/biometric-verification. It also runs production zero-knowledge threshold proofs today through Selective Disclosure and Zero-Knowledge Age Proofs, proving a credential attribute like age or KYC tier without revealing the underlying value. Extending that same proof infrastructure to run directly over biometric template data, rather than a credential's declared field, is the next logical application of cryptography Hypersign already has live, not a new capability requiring new tooling from scratch. To be precise about where that stands today: Hypersign does not have a zero-knowledge proof running over raw biometric templates in production, and neither does any other identity verification vendor surveyed for this post. What Hypersign has is both halves of the eventual combination already shipped separately, a position closer to production than either a pure biometric vendor with no zero-knowledge work, or a zero-knowledge research project with no biometric verification pipeline to run it on.

Where This Leaves You
A zero-knowledge biometric proof lets a verifier trust that a face matched a document, or that a liveness check passed, without ever holding the data that produced that result. The cryptographic pieces, commitments, zk-SNARK circuits, proving systems like Groth16, are already running in open-source projects like zkBiometric and research protocols like BioZero. What's missing is production deployment inside a mainstream KYC flow, and a settled answer on what an audit trail looks like once the underlying capture is never retained. Evaluate any vendor's zero-knowledge biometric claims against that gap specifically: ask whether the proof runs over the biometric data itself or only over a credential's declared field, and ask what happens to the audit trail a compliance team would need six months later.

References
Primary sources for the citations above:

BioZero: Privacy-Preserving and Publicly Verifiable On-Chain Biometric Authentication (arXiv)
Academic protocol combining homomorphic commitments and zero-knowledge proofs to keep biometric templates hidden while authentication stays publicly verifiable.

passport-zk-circuits (GitHub, Rarimo)
Open-source zero-knowledge circuits proving passport chip-signature validity, cited as an adjacent but distinct document-level ZK implementation.

Regulation (EU) 2016/679, Article 9 (GDPR, EUR-Lex)
Classifies biometric data used for unique identification as a special category of personal data.