Verify
Customer verification with consent, review and evidence.
Identity verification as a guided journey: applicants, consent capture, provider-neutral checks and dual-controlled review, with an evidence trail you can put in front of an auditor.
The advantages
The outcomes this product is built around.
Consent before every check
No check runs without recorded consent, captured as part of the journey — so your compliance storey starts at the first click, not at the audit.
Documents stay in their region
Identity documents never leave the region they belong to. The platform holds references, not the documents themselves — your data-residency posture is structural, not promised.
Decisions you can explain
Every outcome carries its reason codes, resubmission is an explicit step, and sensitive decisions need a second, independent reviewer — no unexplained rejections.
Deletion you can prove
Retention limits are enforced by the platform, and deletion produces verifiable evidence — a stable record that the data was removed.
- matching reviewers for a business or high-risk case
- 2
- credits for an abandoned or platform-failed attempt
- 0
- at most, for a reusable identity before it expires
- 1 year
See it in the console
Real screens from the product, not mock-ups.
Every attempt and why
Each attempt with its checks and reasons, the consent it holds, the review decisions on it and whether it was billed.
Applicants and flows
Applicants are opaque references with a region and a retention period. Flows are versioned, so a change to the journey never rewrites an old attempt.
How it fits together
What happens between your request and a running resource.
An attempt binds one applicant to one flow version. Consent comes first and is checked against the applicant’s region. The checks go to a provider behind a regional boundary, and a case that needs a person goes to review, where sensitive decisions need two.
- Attempt: applicant + flow version (You)
- Consent: per purpose, per region (You)
- Regional boundary: references, not documents (The platform)
- Review: reasons, dual control (The platform)
- Checks: document · liveness · screening (Providers)
- Attempt to Consent
- Consent to Regional boundary: required
- Regional boundary to Checks
- Checks to Review: needs a person
Who it is for
The teams and situations this product was built for.
Fintech and payments
You must verify customers before they move money, with evidence for regulators.
Guided journeys with consent capture, explainable outcomes and an audit-ready trail.
Marketplaces
Sellers and buyers must be who they say they are, at scale.
Versioned flows that give every applicant the same journey and every decision a reason code.
Restricted services
Access depends on identity or age checks you cannot get wrong.
Dual-controlled review for sensitive decisions and residency rules the platform enforces.
What it does
The core capabilities, live in the product today.
Applicants and versioned flows
Each applicant moves through a versioned flow of ordered checks. Every attempt is recorded immutably, and sensitive documents never sit in the platform’s core records.
The flow is versioned, so every applicant gets the same journey and a change to the journey is itself a tracked event. Every attempt is recorded immutably, and sensitive documents stay out of the platform’s core records.
Consent and regional residency
No check runs without recorded consent, and identity documents stay inside the region they belong to — the platform holds references, not the documents themselves.
Consent is captured as a step of the journey itself, before anything runs. Documents stay in the region they belong to and the platform keeps references — so your data-residency posture is structural, not promised.
Explainable outcomes and dual control
Every outcome carries its reason codes, resubmission is an explicit step, and sensitive decisions require a second, independent reviewer.
A rejection comes with its reason codes and an explicit resubmission step, so an applicant is never turned away unexplained. The decisions you cannot afford to get wrong need a second, independent reviewer before they stand.
Retention and deletion evidence
Retention limits are enforced, and deletion produces verifiable evidence — a stable record that the data was removed, with premature deletion refused.
Set the retention limit and the platform enforces it. When the time comes, deletion produces verifiable evidence — a stable record that the data was removed — and a deletion attempted early is refused.
The ideas behind it
The words this page uses, explained once.
- Flow version
- The ordered checks an applicant goes through and the SKU it bills. A new version is a new flow; an attempt keeps the version it started on.
- Payload boundary
- Documents and images stay in the applicant’s region. The platform keeps a reference, and nothing goes to a provider without consent for that purpose in that region.
- Reusable identity
- An approved verification that a later attempt can rely on without calling the provider again, until it expires or is revoked. It bills at its own reuse rate.
In depth
The detail an evaluation asks for.
Billing only for an answer
A completed attempt bills once, whatever is retried. An attempt the applicant abandons, or one that failed because a provider was down, is never billed.
Businesses, not only people
Company registry and bank-account checks are steps in the same flows, behind the same consent rules, and a business subject always needs two reviewers.
After onboarding
Standing subscriptions re-screen an applicant at most daily against watchlists, fraud signals and transactions. A non-passing result opens one alert, and only a named reviewer with a written reason can close it.
Regulated reporting
Reporting profiles state the jurisdiction, regulator and threshold. Transfers at or above it go through the Travel Rule provider before they are acknowledged, and filing a report is a named act.
How it works
- Console
Define your journey
Versioned flows order the checks an applicant goes through, so every applicant gets the same journey.
- API
Capture consent, then check
No check runs without recorded consent; documents stay in their region while the platform keeps references.
- Console
Review the edge cases
Outcomes carry reason codes, and sensitive decisions get a second, independent reviewer.
- Audit trail
Keep the evidence
Retention is enforced, and deletion produces verifiable evidence you can put in front of an auditor.
In code
The same task in the CLI and both SDKs. Every call shown exists in the API.
prx CLI
Start an attempt, record consent, run a check and read where it stands
prx identity verify create-attempts --body '{"applicant":"prx:northwind:iam:_:applicant:15326c9b-a61f-436c-92af-62023811e9d9","flow":"prx:northwind:iam:_:verification_flow:0b171630-63aa-4c08-9029-ba6e1dafd61b"}'prx identity verify consent "$ATTEMPT" --body '{"purpose":"biometric_matching","region":"eu-central","granted_by":"driver-20433","granted_at":"2026-11-10T09:30:00Z"}'prx identity verify run "$ATTEMPT" liveness --body '{}'prx identity verify get "$ATTEMPT"TypeScript SDK
Start an attempt, record consent, run a check and read where it stands
const attempt = await client.identity.verify.createAttempts({ applicant: applicantUrn, flow: flowUrn });const id = attempt.urn.split(':').pop();await client.identity.verify.consent(id, { purpose: 'biometric_matching', region: 'eu-central', granted_by: 'driver-20433', granted_at: new Date().toISOString() });await client.identity.verify.run(id, 'liveness', {});const { state, checks } = await client.identity.verify.get(id);Python SDK
Start an attempt, record consent, run a check and read where it stands
attempt = client.identity.verify.create_attempts({"applicant": applicant_urn, "flow": flow_urn})attempt_id = attempt["urn"].split(":")[-1]client.identity.verify.consent(attempt_id, {"purpose": "biometric_matching", "region": "eu-central", "granted_by": "driver-20433", "granted_at": "2026-11-10T09:30:00Z"})client.identity.verify.run(attempt_id, "liveness", {})state = client.identity.verify.get(attempt_id)["state"]The difference
The way this job usually goes, and the way it goes here.
The usual way
With ProjectX
Consent captured somewhere, maybe, in a form nobody can find at audit time.
No check runs without recorded consent, captured as a step of the journey itself.
A rejection email with no reason and no way back.
Every outcome carries reason codes, and resubmission is an explicit step.
Identity documents copied into a database in whichever region was convenient.
Documents stay in their region; the platform holds references, not the files.
Works with your tools
Every surface below drives the same product — script it, click it, or hand it to your existing tooling.
- Console
- API
- Audit trail
Questions, answered
What does the applicant see?
A guided journey: the versioned flow orders the checks, consent is captured before anything runs, and a rejection comes with reason codes and an explicit resubmission step.
Where do identity documents go?
They stay inside the region they belong to. The platform’s core records hold references, not the documents, so residency is enforced structurally.
Who reviews the edge cases?
Sensitive decisions require a second, independent reviewer — dual control is built into the review step, not bolted on.
How long is verification data kept?
Only as long as the retention limit you set. Deletion then produces verifiable evidence, and premature deletion is refused.
How is it priced?
Per verification at published usage rates in Platform Credits, on the same invoice as the rest of the platform. The rates are on the pricing page.
Products it works with
Same platform, same console, same invoice.
Start with ProjectX today.
Create a company in minutes and add this product to your invoice at the published rate.