The Snapshot Problem
Every dominant identity vendor stops at the front door.
Identity verification, as it exists today, is a ceremony. A user shows an ID, takes a selfie, and the vendor issues a verdict. Then the ceremony ends — and the session, the call, the API token, the transaction all continue on their own trust plane, with no continued binding to the person who was proofed.
The industry calls this “reusable identity.” It is not. It is reusable enrollment. What gets reused is the record, not the person’s presence in the moment that matters.
Kenshiki Pulse is built for what happens after the ceremony ends.
The pattern: enroll once, re-match on demand, walk away
Every dominant vendor in identity verification ships the same architecture:
- Capture a government ID and a selfie at onboarding.
- Store an enrollment record — a biometric template, a device fingerprint, an account graph entry.
- On subsequent high-risk events, prompt the user for a fresh selfie and match it against the stored record.
- Return a pass/fail to the relying party. Exit the flow.
That’s it. There is no continued binding to the live web session. There is no continued binding to the voice call. There is no cryptographic anchor tying the person who logged in ten minutes ago to the person now instructing a wire transfer.
The vendors say this out loud. We are not inferring architecture — we are quoting them.
Named vendors, in their own words
CLEAR / CLEAR1
What they call it: “Reusable identity” — “verify in seconds with the snap of a selfie” (Albany Med)
What they actually bond to: Stored selfie + ID + phone + device in the CLEAR Identity Graph. Deployed inside Docusign, LinkedIn, Microsoft Entra, and Amazon Connect as a discrete ceremony.
Jumio
What they call it: “selfie.DONE” — “instantly recognizes and reverifies returning, trusted users with just a selfie — no need to rescan IDs”
What they actually bond to: Stored biometric template in the Jumio Identity Graph.
Socure
What they call it: “Selfie Reverification” — “captures a new selfie and compares it to the headshot from the previously accepted DocV transaction”
What they actually bond to: Prior DocV headshot. Requires a previous_reference_id to have anything to compare against (Socure docs).
Persona
What they call it: “Reverify” — “reverify that individual against their Account… as simple as just a selfie”
What they actually bond to: Persona Account record linked by reference ID (Persona docs).
Onfido (Entrust)
What they call it: Reverification via selfie-to-enrolled-template match
What they actually bond to: Enrolled biometric template. Ceremony ends; session continues untouched.
Incode
What they call it: “Face authentication for returning users” — “no ID scan required, just a quick selfie”
What they actually bond to: Stored Incode Identity. Post-login Action stamps claims into an Auth0 token, then walks away (Incode Auth0 docs).
Veriff
What they call it: “Biometric Authentication” — “confirms that a returning user is who they claim to be… using just a selfie”
What they actually bond to: “Face matching with AI to compare biometric templates from the authentication session to the stored biometric template from the enrolment session”.
iProov
What they call it: “Face Verifier” — “authenticate a user’s face against a pre-enrolled biometric template”
What they actually bond to: Pre-enrolled iProov template. Cloud-scored, then the answer goes to the relying party (iProov).
Every one of these is the same shape. Enroll once. Match against enrollment. Return a verdict. Exit.
What none of them do
They do not bond a live web session to the enrolled identity. After the ceremony, the session runs on cookies, TLS, and bearer tokens. If an attacker takes over the session — through a stolen token, a coached transfer, a support-desk social engineer — the identity vendor is not in the loop and cannot intervene. Incode’s own documentation says the returning-user flow “stamps claims into the ID token” and hands off. That token is now the identity as far as the application is concerned.
They do not bond a live voice call to the enrolled identity. CLEAR’s new Amazon Connect integration is the cleanest example: “a customer who calls a support line running on Amazon Connect can choose to verify their identity through CLEAR. If they opt in, they receive a secure SMS link to complete verification on their phone, and once they are verified the call is routed to an agent.” The verification happens out of band, on a different device, on a different channel. The call itself is never bonded to the identity that was just verified.
They do not detect coached takeover. When the person in front of the phone is the enrolled user, but is being manipulated by a fraudster on another line, every one of these systems returns “verified.” The ceremony passes. The wire transfer goes through. There is no rule-presentation surface, no hardware-anchored second channel, no institution-verified “never do this” to interrupt the coached instruction.
They do not preserve a chain of custody. There is no cryptographic evidence, at the moment a high-impact action is authorized, that the person who was proofed at enrollment is the same person authorizing it now. There is only a match score against a stored record — computed by the vendor, on the vendor’s cloud, for a single moment, then discarded.
What Kenshiki Pulse does instead
Pulse bonds a hardware-anchored, biometrically punctuated key to the live session and to the live call. Not a ceremony that returns a verdict — a chain of custody that persists through the moment that matters.
| Layer | Reusable-identity vendors | Kenshiki Pulse |
|---|---|---|
| Enrollment | Selfie + ID → template stored in vendor cloud | Passport-bound enrollment → hardware key on the user’s device, Face ID-protected |
| Re-authentication | Fresh selfie compared to stored template | Face ID unlock of the same hardware-bound key — no new selfie sent anywhere |
| Session binding on web | None. Session runs on cookies/TLS after verdict | Signed, session-specific WebSocket inside an E2E VPN tunnel, bonded to the hardware key |
| Call binding | Out-of-band SMS ceremony, then hand off | Live authorization broker on the enrolled device, cryptographically bound to the call’s context |
| Coached-fraud defense | None — verification passes if the real user is present | Institution-verified rule presentation on the enrolled device; the user sees what their bank actually said |
| Evidence at decision time | Match score in vendor cloud | Signed, device-computed receipt — chain of custody the relying party can verify |
| Ownership of the record | Vendor’s identity graph | The member. Kenshiki does not resell it. |
Others score continuity. Pulse records chain of custody.
Why this matters now
Every major identity vendor is converging on the same vocabulary — continuous, reusable, biometric, frictionless — while shipping the same architecture they shipped five years ago: a ceremony that ends. The result is a category-wide gap between what buyers hear and what actually gets deployed.
The buyer who thinks they are getting “continuous identity” is getting a stored template and a re-match button. The bank that thinks their high-value wire transfer is protected by biometric authentication is protected by a selfie taken ninety seconds ago, on a session the vendor no longer sees.
Meanwhile, coached fraud, session takeover, deepfake-assisted social engineering, and account-recovery attacks all target the space between the ceremonies — the space where the dominant vendors have architected themselves out of the loop.
Pulse is built for that space.
What’s next
Notes on this comparison
This page cites each vendor’s own marketing and product documentation. Product architectures evolve, and this page will be updated as they do. If you work for one of the named vendors and something is out of date, tell us — we will correct it, and we will preserve the correction history.
Nothing on this page is a claim that these vendors are bad at what they do. They are excellent at what they do. What they do is not what Pulse does.