ProntoID acts as an independent escrow agent for verified identity. We verify the person, seal the evidence and hold it — so your platform can prove a user was verified without ever storing their passport.
Most platforms treat these as the same requirement. They are not, and conflating them is where the liability comes from.
That you know something reliable about your users, and can demonstrate it afterwards.
Every stored passport is an obligation that outlives the verification it was collected for.
The same three-party structure that lawyers have used for source code, funds and deeds for decades — applied to identity.
Verifies once, deposits their identity with the custodian under their own consent, and keeps their own copy in ProntoWallet.
Holds the deposit as an independent controller, under a release schedule that binds it against every party including the platform.
Receives a signed assurance and a digest. Enough to act on, enough to prove afterwards, and nothing that identifies a person in a breach.
The term is not marketing. Identity escrow was formalised in the cryptographic literature by Kilian and Petrank at CRYPTO 1998, describing systems where a party may act pseudonymously while a designated authority retains the ability to revoke that anonymity under defined conditions. ProntoID is a commercial implementation of that structure, built for platforms that are required to know something about their users and would prefer not to hold it.
A clean split is the point of the arrangement. Ambiguity about who holds what is what turns an incident into a dispute.
| Responsibility | Sits with | Detail |
|---|---|---|
| Confirm the document is genuine | ProntoID | Document authentication, MRZ parsing against ICAO 9303 check digits, tamper detection. |
| Confirm a live person presented it | ProntoID | Biometric liveness and face match against the document portrait. |
| Store the identity document | ProntoID | Held encrypted under per-record keys. Never transmitted to the platform. |
| Hold the biometric reference | ProntoID | Retained only where a future re-binding or match is contracted for. |
| Receive the assurance | Platform | A signed statement: verified, over 18, matches this prior verification. No underlying data. |
| Store the assurance reference | Platform | An opaque token and a digest. Neither is personal data on its own. |
| Decide who may use the service | Platform | Access, eligibility and terms remain entirely the platform's call. |
| Moderate content and conduct | Platform | Escrow says who someone is. It does not say what they may do. |
| Consent to the deposit | The person | The deposit is made by the person, to ProntoID, under their own consent. |
| Withdraw consent | The person | Withdrawal is recorded as a new sealed instrument, not a silent deletion. |
| Exercise access and portability rights | The person | Exercised against ProntoID directly, as the controller of the deposited record. |
| Authorise release of the underlying identity | Release schedule | Neither the platform nor ProntoID decides unilaterally. The release schedule governs. |
Escrow tells you who someone is. It does not tell you what they may do — that judgement stays with the platform.
An escrow agent is defined by what it refuses. These are the conditions — and the one that will never be on the list.
A court order, or a lawful law-enforcement request, issued by a competent authority in a jurisdiction with which the escrow agent must comply.
A request from a supervisory authority with a stated legal basis — a media or online-safety regulator, a data protection authority, or a payment scheme exercising audit rights under its own rules.
The data subject may recall their own deposit at any time, after re-authenticating biometrically against the record they are asking for. Identity, not an email address, is the credential.
A documented dispute under the platform's own terms, limited to the specific record in issue and to the specific fields the dispute turns on. Never a bulk export.
Not for marketing. Not for analytics. Not for enrichment, model training or resale. Not because a platform would simply prefer to know. A commercial interest is not a release condition.
Every release is itself a record. A release appends a signed entry to the ledger: what was released, to whom, on what basis, and when. The log cannot be edited retroactively, which means it is as useful to the person whose identity was released as it is to the party that asked for it.
This is the part that decides whether escrow is worth paying for, or whether you should just build it yourself.
A consent record you generated, stored and control is a record you could have generated at any time. When it matters — a regulator's audit, a takedown dispute, a chargeback, a court — the first question asked of your evidence is whether you could have created it after the fact. If the answer is yes, the record does most of its work on your own side of the argument and very little on the other.
A record sealed by an independent party, at the time, over a canonical payload, with a signature you cannot produce yourself, does not have that weakness. That is the difference between a record and evidence.
How Records Are SealedConsent withdrawal follows the same path. Under GDPR Article 7(3), withdrawal operates prospectively — it does not unmake a consent that was validly given at the time. ProntoID appends a sealed withdrawal instrument referencing the digest of the original, so the trail shows both events in order without either being rewritten.
Answered here rather than in the third call, because they are the right questions and a vendor who dodges them is telling you something.
Concentration is the trade, and it is a deliberate one. The alternative is not zero risk — it is the same documents replicated across every platform a person signs up to, each with its own bucket policy, its own leavers process and its own retention drift. One custodian whose entire business is holding that data, under per-record encryption and an append-only access log, is a defensible posture. Four hundred platforms each holding a copy is not. We would rather argue the first position in front of a regulator than the second.
The deposit is scoped to what the assurance requires and no further. A platform asking for age assurance does not cause a full identity record to be retained. Retention runs against the legal basis that justified the deposit — contractual necessity for a KYC record, the statutory period for a record-keeping obligation — not against an indefinite default. Where the basis lapses, the record does. What survives is the sealed evidence that a verification occurred, which is not the same artefact as the document.
Every sealed record is verifiable without us. The signature is a detached JWS over RFC 8785 canonical JSON, checkable with a standalone verifier that depends on nothing but the public key and a P-256 implementation. A platform that has retained its dossiers can prove them in ten years to a court that has never heard of ProntoID. That is the part that matters, and it is a property of the format, not a promise from the company. Custody continuity — successor custodian, wind-down and key handling — is a contractual matter dealt with in the custody agreement.
No, and the distinction is the whole point. A processor acts on your instructions and holds your data. An escrow agent holds its own record, under its own legal basis, subject to its own duties and a release schedule that binds it against you as much as for you. ProntoID is an independent controller of the deposited identity record. That is what allows us to refuse a release you would like, and it is also what removes the record from your controllership — and from your breach surface.
Each ProntoID product is a different thing you can do with an identity you do not hold.
Bilateral, identity-verified consent for content. Both parties are verified; the release is sealed; withdrawal is appended as a new instrument rather than erasing the original.
Learn MoreThe sealed record itself. Canonical JSON, detached signature, append-only ledger, independently verifiable digest.
Learn MoreRelease conditioned on a live face match. The escrowed identity is the key to the file, not a password that can be forwarded.
Learn MoreThe depositor's own copy, held in the device secure enclave. Escrow does not mean the person loses access to their own identity.
Learn MoreThe narrowest possible beneficiary claim: over or under a threshold. The date of birth stays in escrow; the platform receives a boolean.
Learn MoreIdentity escrow is a three-party arrangement in which a person deposits their verified identity with an independent custodian, a platform receives an assurance about that person without receiving the underlying identity data, and the identity itself is released only on defined conditions. ProntoID acts as the custodian. The term comes from the cryptographic literature — Kilian and Petrank formalised identity escrow at CRYPTO 1998 — where it describes anonymity with conditional revocation.
In ordinary verification, the platform receives a result and usually also receives, or is expected to retain, the evidence behind it. In escrow, the evidence stays with the custodian and the platform holds only a signed assurance and a digest. The platform can prove a verification happened without holding anything that would be personal data in a breach.
Release follows a defined schedule: a binding legal order, a regulatory demand with a stated legal basis, a request by the data subject themselves after biometric re-authentication, or a scoped dispute under the platform's terms limited to the record in issue. Commercial interest is not a release condition. Every release is recorded as an appended entry in the ledger.
No. ProntoID acts as an independent data controller for the deposited identity record, with its own legal basis and its own duties to the data subject. This is what allows the escrow agent to decline a release, and it is what removes the identity record from the platform's controllership.
An opaque reference and a cryptographic digest of the sealed record. Neither identifies a person on its own. The platform can present the digest to demonstrate that a specific verification occurred and has not been altered, and the record can be verified independently of ProntoID.
Yes. Sealed records use RFC 8785 canonical JSON with a detached JWS signature over a P-256 key. Verification requires only the public key and a standard ECDSA implementation, so a retained dossier remains provable by any third party, indefinitely, without contacting ProntoID.
Withdrawal under GDPR Article 7(3) is prospective. It does not erase the fact that a valid consent existed at the time an act was performed. ProntoID records withdrawal as a new sealed instrument referencing the digest of the prior one, so the audit trail shows both the original consent and its withdrawal, in order, without either being falsified.
Escrow is a structural answer to obligations that require assurance about a user without requiring the platform to hold identity documents: the UK Online Safety Act, the EU Digital Services Act, the German JMStV closed-user-group requirement, 18 U.S.C. § 2257 record-keeping, payment scheme rules for high-risk content, and GDPR data minimisation under Article 5(1)(c).
ProntoID acts as an independent data controller and contractual custodian of deposited identity records. The escrow terms, release schedule, retention periods and continuity arrangements described on this page are set out in full in the custody agreement, which governs in the event of any inconsistency. This page is a description of a service, not legal advice.
Tell us what you are required to know about your users, and we will show you the smallest thing you need to hold in order to prove it.
Independent controller · Defined release schedule · Verifiable without us