Know who they are before they arrive.
A document scan, a face match and a liveness check, from a link the subject opens on any device. The result lands on the contact record every app already reads.
Know who they are before they arrive.
Verification
Document scan, face match, and liveness check.
Two Tiers
Identity verification and compliance screening.
AML Screening
Watchlist and sanctions checks with risk scores.
Cases
A queue for flagged verifications needing a human.
Audit Trail
Every event timestamped, every reviewer named.
Verification Links
Send a link. The subject verifies themselves.
Contact Integration
The result on the record every app reads.
Verified, pending, declined, and the ones that need a human.
The verification operation at a glance, then the queue underneath it. AML hits are their own tile because they are their own decision.
Verify once. Every app knows.
A verification tool that stands on its own has to hand its answer to somebody. It verifies a person, keeps the result in its own database, and then the operator exports a file, wires an automation, or updates four systems by hand so the front desk, the door, the loyalty tier and the contract all know the same thing. Calisto Identity writes the result onto the contact record that reception, the door, the ticket desk, the help desk and the signature request already read. There is nothing to export, because there is nowhere to export it to.
0
verification tiers, identity and compliance
<0 min
end to end, in the browser
Zero
app installs for the person verifying
ID scan, selfie, face match. Under two minutes.
The subject opens a link on whatever device is in their hand. No app install, no account to create. They photograph their document, take a selfie, and the match runs. What the operator gets back is this screen: the extracted document fields, the face match score, the liveness result, the screening outcome, the captured images held redacted, and the timeline of everything that happened. An approved verification is written onto the contact record every other app already reads.
- Tier
- Identity + Compliance
- Status
- approved
- Document
- Passport
- Country
- PT
- Liveness
- passed
- Face match
- 0.97
- Verified
- Mar 14, 09:41
- Expires
- Jun 12, 09:41
- Source
- link
- Result
- clear
- Risk score
- 0.04
- Match score
- 0.00
Personal data is redacted. Reveal to view for compliance review, audited.
- created09:38:02
- approved09:41:06
- document_revealed11:20:31
A contact badge level is computed from the latest approved verification that has not expired. An expiry passes and the level drops on its own. Nothing has to be swept, and no stale flag can outlive the check it came from.
The document image, the selfie, the extracted name, the document number and the date of birth are hidden by default. Reveal shows them and writes an event, so the record of who looked sits in the same trail as the record of what was decided.
The document is read and its fields extracted, the selfie is matched against the document photo with a score, liveness confirms a person rather than a photograph of one, and on the compliance tier the screening runs. The row carries all four.
The row records which app asked for it. A check triggered from the reception board, from a shared link, from a document about to be signed or from a credential about to be issued stays distinguishable months later.
The decision arrives by signature-verified webhook. When one does not arrive, the verification can be re-read from the provider and the same row updated, so a dropped delivery is a delay rather than a verification stuck at pending forever.
Thirty, sixty, ninety, a hundred and eighty or three hundred and sixty five days, or never. The operator chooses once in settings and every verification inherits it.
Identity Check, or Identity plus Compliance.
Tier 1 is the document, the face match and the liveness result. Tier 2 is all of that plus screening against sanctions lists, politically exposed persons databases and adverse media, with a risk score and a match score written onto the same record. A front desk confirming that the guest is the guest needs Tier 1. An operator onboarding a counterparty with a compliance obligation needs Tier 2. The tier is set on the link, on the bulk run, or as the account default, and it can be changed for a single verification without changing anything else.
Every link carries its tier. Every bulk run carries its tier. The account has a default, and any single verification can leave it. A lobby check and a compliance onboarding can run side by side in the same account on the same day.
Setting up costs nothing. Creating a session costs nothing. A declined or expired session costs nothing. The metered event is an approval, deducted from the operator wallet at the moment the decision lands.
The same badge on the same contact, the same audit trail, the same visibility in every sibling app. The compliance tier adds screening to the decision; it does not create a second kind of verification.
Hand an auditor the screen you already work in.
Every event timestamped, every reviewer named, every case closed with a note. Nothing to assemble when somebody asks.
Sanctions, PEP and adverse media. One screening result.
A Tier 2 verification is screened against sanctions lists, politically exposed persons databases and adverse media sources. The outcome is clear, hit, or review, carried with a risk score and a match score on the verification itself. A hit or a score above the review threshold sends the verification to the case queue instead of approving it. Everything below the line approves, unless the operator has set the threshold to hold every compliance-tier result for a human.
Sanctions lists, politically exposed persons databases and adverse media are screened together and land as a single outcome on the verification: clear, hit, or review.
A risk score and a match score sit beside the outcome. A near-miss on a common name and a genuine list match are different numbers, and the operator sees which one they are looking at.
One threshold sends a screening to review, another declines it. Both are set in settings, so an operator with a low tolerance and an operator with a high one run the same screening against different lines.
When a name appears on a list after the fact, the screening result updates and the verification is flagged, but the decision that was already made keeps its own status and its own timestamp.
The result is not a separate compliance record filed somewhere else. It is on the row, in the detail view, in the audit trail, and in the same list an operator filters by tier and status.
A Tier 1 verification opens the same detail screen and states that no screening ran, rather than showing an empty panel that could be read as a clear result.
Every flagged verification gets a case. Every case gets a resolution.
A screening hit, a score above the review threshold, or an operator who has chosen to hold compliance-tier results puts the verification into the case queue instead of approving it. The case opens as the review control sitting on top of the full verification: the decision, the screening scores, the captured documents and the timeline. The reviewer clears and approves, keeps it in review, or declines, and the notes they write go onto the audit trail with their decision.
Opening a case opens the review control on top of the whole verification detail: the decision grid, the screening scores, the captured documents and the event timeline. Nothing has to be looked up in a second place.
Clear and approve, keep in review, or decline. Whichever the reviewer chooses is written with their notes as an event on the trail, so the resolution and the reasoning stay attached to the record they belong to.
A flagged verification stays flagged until a person acts on it. There is no timer that approves by default and no rule that quietly clears a queue nobody looked at.
Open cases show as an AML hits tile on the daily dashboard, in the error tone, so a queue that is growing is visible from the screen an operator already opens first.
Every event. Every timestamp. Every reviewer.
A verification is created. A decision arrives. A screening returns a hit. A case is opened and resolved with notes. A redacted document is revealed. A verification reaches its expiry. Each of those is a row against the verification it belongs to, with a timestamp, and each row links back to the record. This is the trail an auditor reads, and it is the same one the operator reads, because there is only one.
Created, pending, in review, approved, declined, expired, screening hit, reviewed, document revealed. Every row uses the same words the rest of the app uses, so the trail reads the same way the screens do.
Every event points back at the verification it belongs to. Reading the trail and reading the record are one movement, not an export and a lookup.
Revealing a redacted document writes a row. The audit trail therefore answers who saw the personal data, not only what the system decided about it.
A resolved case records who resolved it, when, and what they wrote. The trail carries the human decision beside the automated ones.
Send a link. The subject verifies themselves.
No app install. No Calisto account. A page that works on any device, in any browser, carrying your name and not ours.
Generate a link. Send it anywhere. The subject verifies themselves.
A link has a label and a tier, and that is the whole of it. Send it by message, put it in a booking confirmation, print it as a code on the counter. The person who opens it sees your name, gives theirs, scans a document, takes a selfie and closes the tab. They never install anything and they never create an account. The result appears in the operator's list, and the link keeps a count of how many times it has been used.
The link resolves its token and shows the label the operator gave it.
Full name and email, bound to a real contact on the spine.
The document scan and the selfie, in the browser, camera only.
The decision lands server side. The subject can shut the tab.
The person verifying never signs in to anything. The page renders outside the authenticated shell entirely, which is why it works from a text message, a booking confirmation or a printed code on a counter.
A link is not single use. It carries a label and a tier and counts how many times it has been used, so a front desk code and a one-off onboarding link can live in the same list and be told apart.
A link that has left the building can be revoked from its own row. The verifications it already produced are untouched.
The logo and the message on the capture screen come from settings, and the business name behind them is the same shared brand configuration the rest of the platform uses. The subject sees you.
The decision is delivered to a signature-verified endpoint, matched to the session, written onto the verification and pushed onto the contact. Nobody has to go and collect it.
Bulk verify takes a pasted list of contacts and a tier and starts a session for each one. Any app that renders a contact can also trigger a verification in place, without sending anyone anywhere.
The check is done and the record exists. What happens to it next is the part that matters.
Verified once. Recognised on every screen that shows them.
A verified identity here is not a row in a separate system waiting to be exported. It is a status on the contact record that reception, the door, the ticket desk, the help desk, the signature request, the payout and the schedule all already read. One person verifies once, and every screen that shows that person shows it.
Membership registration is held until the enrollee clears the required level.
The reception board holds the check-in confirm behind the same gate.
Attendee rows carry the checkmark, and an age-restricted door holds until it is met.
Issuing a keyless credential is held until the holder is verified.
A creator payout is held, and the public profile shows the checkmark.
The customer context header shows the requester level and opens the panel in place.
The contact sidebar shows the checkmark beside the name in the conversation.
The contact card shows it before a reply is written.
The prepare panel shows a level for every signer bound to a contact.
A staff lane on the schedule carries the level of the person working it.
An approved verification writes its status and its date onto the contact row. There is no export, no sync job and no webhook to build, because there is no second database to move it into.
Each app asks for the level and gets it derived from the latest approved verification that has not expired. No app keeps its own copy, so no app can hold a level that is out of date.
Blocking a step on identity is one component around the step. Reception check-in, credential issuance, membership registration, a payout and a restricted door all use the same one, at whichever level that operator required.
When a contact is not verified yet, the capture flow opens inside the app that asked. Nobody is sent to a different product to come back afterwards, and nothing is read only in the app that did not write it.
The alias index maps an email, a phone number, a chat handle or a messaging address to a single canonical contact per account. The same address seen in a different app resolves to the same person rather than creating a second one.
Each alias carries a confidence score, who or what linked it, and which app it came from. A provisional match and an exact one are distinguishable, which is what makes a merge reviewable instead of permanent.
A verification is worth what the rest of the system does with it.
The Contact
Identity → the contact record
An approved verification writes its status and its date onto the contact row itself, and the badge every app renders is derived from the latest approved verification that has not expired. Nothing is copied, so nothing can go stale.
Gated Steps
Identity → Registry · Bookings · Tickets · Access · Direct
Membership registration, reception check-in, an age-restricted door, credential issuance and a creator payout are each one component wrapped around the step, holding it until the contact meets the level that operator required.
The Checkmark
Identity → Desk · Inbox · Link · Sign · Workforce
The same inline badge renders beside a contact name in a ticket, a conversation, a contact card, a signature request and a staff lane, and clicking it opens the detail in place rather than sending anybody to another product.
Scope And Brand
Identity → Purview
The active business unit decides which verifications are visible, and the business name and brand the subject sees on the capture screen are the shared configuration, edited from inside Identity without leaving it.
The Cockpit
Identity → Today
Verified, pending and screening hits arrive as tiles on the daily dashboard, with the hits tile in the error tone, so a review queue that is filling up is visible from the first screen of the day.
Metered Usage
Identity → the operator wallet
Only an approved verification bills, captured at the moment the decision lands, in the currency the account operates in. An account whose currency cannot be resolved is not charged in a guessed one.
Where Identity touches everything else.
8 of these 12 connections are in your plan today. The rest stay visible so you know the instrument is there before you need it.
Registering a new member runs inside the verification gate, so the membership record cannot be created until the enrollee has cleared the level the operator required.
The reception board wraps the check-in confirm in the verification gate, resolving the guest through the contact the reservation already carries.
The attendee list carries a verification column resolved in one batched read per page, and an age-restricted event holds the door until the holder meets the required level.
The contact sidebar renders the checkmark beside the name and opens the verification panel in place, without leaving the conversation.
The contact card carries the same checkmark, so the person on the other end of a message is identified before a reply is written.
A staff lane on the schedule carries the verification level of the person working it, resolved through their contact record.
Three tiles roll into the cockpit from Identity itself: verified, pending, and AML hits waiting on a reviewer.
The active business unit scopes which verifications are visible, and the business name and brand on the capture screen are edited from inside Identity settings.
The customer context header carries the requester verification level, and clicking it opens the panel where an agent can trigger a fresh verification from the ticket.
Issuing a credential runs inside the verification gate, so a keyless pass is never handed to an unverified holder.
Built for these industries
2 customer types run Identity today.
No setup cost. Pay when you start using.
ID verification for hospitality and regulated venues.
Recommended for you
Use one app or many. Works well together.
Everything included in Calisto Identity.
- Two tiers: identity check, and identity plus compliance
- Document scan with field extraction: type, country, number, expiry, name, date of birth
- Selfie captured and matched against the document photo, with a score on the record
- Liveness result on the record
- Captured images stored on the verification and rendered redacted by default
- Reveal for compliance review, which writes its own audit event
- Five statuses: pending, approved, declined, in review, expired
- Expiry configurable per account, from thirty days to never
- Required document type configurable: any, passport, national ID, or driving licence
- Age threshold setting for age-gated flows
- Every verification records the app that triggered it
- Sanctions, politically exposed persons and adverse media screening on the compliance tier
- Three outcomes: clear, hit, review
- Risk score and match score written onto the verification
- Review threshold and decline threshold set per account
- Screening dashboard with clear, hit and review totals
- Case queue for every flagged verification
- Case detail is the review control on top of the full verification record
- Three resolutions: clear and approve, keep in review, decline
- Reviewer, timestamp and notes recorded on resolution
- Tier one states plainly that no screening ran, rather than showing an empty result
- Every lifecycle event as a timestamped row against its verification
- Created, pending, in review, approved, declined and expired
- Screening hit recorded as its own event without overwriting an existing decision
- Case resolution recorded as a review event
- Document reveal recorded as an event, so access to personal data is on the trail
- Every row links back to the verification it belongs to
- Registered in the manager area of the menu
- Shareable verification links with a label and a tier
- Public capture page rendered outside the authenticated shell, with no account for the subject
- Name and email bound to a real contact before capture starts
- Document and selfie captured in the browser
- Use count per link
- Revoke a link without touching the verifications it produced
- Logo and custom message on the capture screen, set in settings
- Business name and brand edited from inside Identity through the shared configuration block
- Bulk verification from a pasted list of contacts at a chosen tier
- Verification triggered in place from any app that renders a contact
- Dashboard with verified, pending, declined and screening hit totals, plus recent activity
- Verifications list filtered by status and by tier
- Verification detail with the decision grid, screening, captured documents and timeline
- Screening list with risk and match scores
- Case queue and case detail
- Audit trail
- Verification links with a creation dialog
- Bulk verify
- Reports with pass rate, total checks, tier split and a per-country table
- Settings across verification, screening, cost reporting, notifications and branding
- Inline checkmark rendered beside a contact name in any app
- Expandable panel that opens in place, never a redirect to another product
- Capture flow that opens inside whichever app asked for it
- Gate that holds a transactional step until a required level is met
- Level derived on read from the latest approved, unexpired verification
- Status and date written onto the contact record itself
- List reads batched per page, never one lookup per row
- Alias index resolving an email, phone, chat handle or messaging address to one canonical contact
- Confidence score and provenance on every alias link
- Metered per approved verification against the operator wallet
- Setup, session creation, declined and expired verifications are not charged
- Charge captured at the moment the decision lands
- Currency derived from the account operating currency and never guessed
- An unresolved currency skips the charge rather than billing in a defaulted one
- Insufficient funds is non fatal and collected on the next top up
- Usage summary by period, split by tier
- Your own list price and currency for the estimated cost figure on reports, or blank to hide it
- Notification webhook on completion and on a screening hit
- Registry (membership registration held behind the gate)
- Bookings (reception check-in held behind the gate)
- Tickets (attendee checkmarks, and an age-restricted door)
- Access (credential issuance held behind the gate)
- Desk (requester level in the customer context header)
- Inbox (the checkmark in the contact sidebar)
- Link (the checkmark on the contact card)
- Sign (a level for every signer bound to a contact)
- Direct (payout gate and the public creator profile checkmark)
- Workforce (the level of the person working a schedule lane)
- Today (verified, pending and screening hit tiles on the cockpit)
- Purview (business unit scope, and the brand on the capture screen)
Questions about Calisto Identity
A link they open on any device: a document scan, a face match and a liveness check. No app to install, which matters when the subject is a guest arriving tomorrow rather than an employee.
On the contact record every app already reads, as a verification level. That is why a booking, a rental or a door can gate on it without integrating with anything.
Yes. Gated steps are chosen per flow, so a low-value booking passes straight through and a high-value rental or a first key collection requires the check.
As you. Scope and brand are configurable, so the subject sees your business rather than a vendor they have never heard of.
Metered usage: you pay for checks performed. The pricing section on this page reads the live catalogue and is the authority.
The verification result stays on the contact and the underlying document handling follows the retention you configure. Verification outcomes export with the contact record.