Most identity questions in a working day are not regulatory. They are operational. Someone is on the other end of a chat, a call or an email, and the only thing that matters is whether they are a real person — and whether they are the person they say they are.
A support agent takes a call from someone locked out of their account. A sales team receives an enquiry from a buyer claiming to represent a company with a large budget. Two strangers arrange to meet to hand over an expensive item. In each case the same question sits underneath the conversation, unasked: is this a real person, and are they who they say they are?
The tooling built to answer that question was designed for a different problem. Full Know Your Customer onboarding exists because financial regulation requires a business to collect, verify and retain identity data. It is thorough, it is auditable, and it is entirely disproportionate for an agent who simply needs to know whether the person asking to change a payout address is the account holder.
So most teams improvise. They ask for the last four digits of a card. They ask for a mother’s maiden name. They ask the caller to email a photo of a passport — which then sits in a shared inbox, in a ticket attachment, and in someone’s downloads folder, indefinitely. Every one of those improvisations is either weak against a determined attacker, or creates a data protection liability out of proportion to the question being answered, or both.
There is a middle option: run a real identity check, and return a single answer. Not the document. Not the name. Not the date of birth. Just: verified, or not.
We call this an identity assertion. The requesting business gets the answer it needs to act on. It never touches the data underneath. This article describes how such a service works, where it fits, what regulatory weight it does and does not lift, and — because it matters more than the marketing — what it cannot do.
From a dashboard, a Slack command, a helpdesk sidebar or a single API call, the agent creates a session tied to a reference they already hold — a ticket number, a booking reference, an account ID.
A one-time link, valid for a few minutes, sent by SMS, email or read aloud as a short code. The subject opens it on their phone. Nothing to install, no account to create.
Biometric liveness, and — depending on the tier — document authenticity and a portrait match. Ten to thirty seconds, entirely inside the ProntoID environment.
The result appears in the agent’s dashboard or arrives on a webhook, keyed to the session they opened. It never travels back through the subject’s device.
Step four is not a detail. The result must never travel back through the subject. If the person being checked can see, screenshot or forward their own pass, then a fraudster can relay somebody else’s pass and the whole exercise collapses.
The answer therefore lands only in the session the agent opened, keyed to a reference the agent already held. The link itself is single-use and short-lived — a few minutes, not a few days. Those two properties, taken together, are what separate a real check from a screenshot of a green tick.
A bot check, a document check and a claim check answer three different questions and carry three different costs. Choosing the tier is the first decision.
Liveness only. No document, no identity data touched at any point.
Answers a single question: am I dealing with a live human being, and not a bot, a script or a replayed recording?
Liveness, document authenticity and a portrait match against the document.
Answers whether a real person is present and holding a genuine government-issued document that depicts them. Returns pass or fail — no name, no date of birth, no document number.
Everything in T1, evaluated against a claim the requester already holds.
The requester submits the claim before sending the link — the name and date of birth the caller has given them. The answer is match or no-match. The requester learns nothing they did not already possess.
The third tier is the interesting one. In a T2 check the requester submits what they have been told — a name, a date of birth — before the link goes out. What comes back is match or no-match. The requester ends the process holding exactly the information they started with, plus a verdict on it.
That is a predicate assertion rather than a disclosure, and it is a strong position under the data minimisation principle. It is also, in practice, the tier support teams actually need. “A real person” is rarely the problem. “The person claiming to be the account holder” is.
true and false collapse outcomes that mean very different things. A person who abandons the flow halfway through a document capture has not failed a check — they have declined to complete one, which is a distinct and highly informative signal.
In practice, abandonment is the most common non-pass outcome and the most useful fraud indicator the process produces. A session dropped immediately after the document step tends to say something a plain failure does not.
What happens to the evidence after the answer is delivered is not a footnote. It is the substance of the offer.
Captured images are destroyed on completion. Only the assertion record survives. The cleanest possible privacy story — and no evidence at all if the transaction is disputed eighteen months later.
The full evidence record is sealed cryptographically and held by ProntoID. The requester never receives it, but may request disclosure under conditions agreed in advance — fraud investigation, chargeback defence, a court order — all disclosed to the subject at the point of capture.
Escrow is the line worth understanding. It takes the requesting business’s breach exposure on identity documents to zero, while preserving the ability to defend a claim long after the conversation is forgotten. Most of the market asks businesses to choose between holding evidence and holding risk. They are separable.
An assertion model moves obligations. It does not make them disappear. Being precise about the split is what makes it defensible.
The middle column deserves attention, because it is the one most often skipped. A business that automatically refuses service on the basis of a failed check has made a fully automated decision with a significant effect on an individual — the territory of Article 22 of the GDPR. That needs contractual necessity, explicit consent, or a route to human review.
A human review route is therefore part of the product rather than an exercise left to the customer. Legitimate people fail identity checks for mundane reasons, and a system with no appeal path damages both the business deploying it and the people it turns away.
The highest-risk moment in any support queue. A locked-out customer and a social engineer look identical over a chat window.
Address changes, payout redirections, plan cancellations, adding a new device. A cheap check in front of an expensive action.
Before two strangers meet to hand over goods or cash, each can prove to the other that they are a real, document-backed person.
Impersonation of procurement staff and vendor-fraud approaches arrive through the same channels as genuine enquiries.
Confirm a real, document-backed person is behind the application, without becoming the custodian of a folder full of passport scans.
A fraud layer ahead of a stay or a rental — distinct from statutory guest registration, which is addressed separately below.
Hotel registration is often cited as the obvious low-regulation case for a lightweight check. It is the opposite. Italy, Spain, France, Portugal and others impose statutory guest identity registration with transmission to the police, and those regimes require the actual identity data — a yes/no answer satisfies none of them. An assertion check is well suited to the pre-arrival fraud layer: confirming a booking is not a stolen-card or fabricated-identity reservation before anyone arrives. Statutory registration is a separate, heavier product, and the two should not be conflated.
Identity products are frequently oversold. These are the boundaries we would want a buyer to understand before signing anything.
The assertion states that a live capture at a given moment passed the checks that were run. That is a process outcome. It reduces the probability of impersonation; it does not eliminate it.
Presentation attacks are well handled by liveness detection. A synthetic stream injected through a virtual camera is a harder, industry-wide problem, and browser-based capture has a structural ceiling here. Device signals and capture-channel attestation raise the cost of the attack rather than closing it.
Damaged documents, unusual formats, poor lighting and disability-related difficulties all produce failures for legitimate people. Any deployment needs a human fallback, which is why one is built into the flow.
Where a statute requires collection and retention of identity data — anti-money-laundering onboarding, statutory guest registration, regulated age assurance — a yes/no answer is the wrong instrument. Those needs are served by the full ProntoID verification products.
Everything above assumes the business is checking the customer. The same primitive works inverted — and the inverted case may be the larger near-term problem.
Voice-cloned calls purporting to come from a bank’s fraud department are an active and expensive form of attack, and most institutions have no credible answer for a customer who asks “how do I know you are really my bank?”
The same assertion mechanic runs in reverse: an institution issues a verifiable proof that the person contacting you is genuinely their staff member, checkable by the customer without any account or app. Same primitive, opposite direction, an entirely different buyer.
Not every identity question deserves a compliance programme. Most of them deserve thirty seconds, a clear answer, and no residue — no passport scan in a ticket attachment, no photograph of a driving licence in a shared inbox, no folder of documents that somebody will eventually have to explain to a regulator.
An assertion model gives the business the answer and leaves the data where it belongs: with a controller that is built, staffed and audited to hold it. That is a narrower promise than most identity marketing makes. It is also one that survives contact with a legal review.
The right amount of identity, at the right moment, in the right hands — and nowhere else.
It is a lightweight identity check that returns a single answer — verified or failed — rather than a set of personal data. The requesting business learns whether the person on the other end passed a live capture and, optionally, whether they match a claim already made. It never receives the document, the image or the underlying identity attributes.
Full KYC is a regulated onboarding process that collects, verifies and retains identity data because a law requires it. An assertion check answers a narrower operational question — is this a live human, and are they who they claim to be — without the requesting business collecting or storing any identity data at all.
No. Under the assertion model the requesting business receives the outcome, the assurance tier, the checks that were performed and a signed receipt. Document images and biometric data are handled by ProntoID as an independent controller and are never passed to the requester.
The result attaches to a customer record, so the requester remains a controller of that record. They need a lawful basis — legitimate interest in fraud prevention is expressly recognised in GDPR Recital 47 — a line in their privacy notice, and a human review route where a failed check would otherwise automatically deny service, in line with Article 22.
It should not, without a safeguard. A fully automated decision that significantly affects someone engages GDPR Article 22 and requires either contractual necessity, explicit consent, or a route to human review. A human review path is built into the flow rather than left to the customer to design.
No. Several European jurisdictions — including Italy, Spain, France and Portugal — impose statutory guest identity registration with transmission to the authorities, and those regimes require the actual identity data, not a yes/no answer. An assertion check is suitable as a pre-arrival fraud layer, not as a substitute for statutory registration.
Presentation attacks — a photo, a mask or a replayed video held in front of a camera — are addressed by biometric liveness detection. Injection attacks, where a synthetic stream is fed into a browser session through a virtual camera, remain a live threat across the industry. The assertion states what was observed at capture time; it is a process outcome, not a warranty of identity.
A liveness-only check takes roughly ten seconds. A check that also includes document authenticity and a portrait match runs to around thirty seconds end to end, in line with the standard ProntoID verification flow.
Regulated onboarding where identity attributes must be collected, verified and retained.
Two people meeting in person, each proving to the other that they are who they claim to be.
Cryptographic stamping and tamper-evident proof for documents and audit trails.
Talk to us about running identity assertions in your support desk, your sales flow or your first-contact process.
Swiss-operated · GDPR-aligned · No ID storage for your business