Design the proof journey—not just the verification screen.
VettiGuard Trust Journeys combine liveness, enrolled identity, device assurance, risk step-up, fallback, and operation binding into reusable policies for the actions your business must protect.
- Context acceptedSubject, amount, beneficiary, reference
- Live person confirmedMovement and capture quality passed
- Known identity matchedOne-to-one server-side comparison
- Approval proof issuedSingle-use and operation bound
Start with a business journey, then tune the assurance.
Templates make the intent explicit while allowing each web or mobile application to choose its own methods, fallbacks, thresholds, and session lifetime.
Customer onboarding
Progress from abuse protection to live-person and enrolled-identity evidence for remote onboarding.
customer-onboardingKYC re-verification
Confirm liveness and match an already enrolled subject before regulated or periodic re-verification.
kyc-reverificationTransaction approval
Bind a high-assurance facial or device-backed proof to the exact payment or transfer context.
transaction-approvalAccount recovery
Use enrolled identity and liveness to protect password reset, account recovery, and contact-detail changes.
account-recoveryWorkforce access
Verify staff identity before sensitive records, shift confirmation, attendance, or privileged actions.
workforce-accessNative app unlock
Prefer a device-bound biometric signature and fall back to enrolled-face verification when required.
native-app-unlockEvery journey answers five security questions.
Your backend remains authoritative. VettiGuard supplies the verification method and normalised proof required by the policy.
Who or what is acting?
Bind the journey to an opaque subject, approved application, and—where appropriate—a registered device.
What action is protected?
Use a stable action name so a proof for one workflow cannot be replayed against another.
How much assurance is needed?
Choose basic, standard, substantial, high, or device-bound assurance and step up as risk increases.
Which evidence is mandatory?
Require identity, liveness, device binding, authorization capability, or exact operation context.
What happens when it fails?
Control attempts, expiry, fallback methods, manual recovery, and whether the operation must stop.
Two backend calls surround the user verification.
Start the journey with private application credentials, execute the returned method, then verify both the response proof and the short-lived journey session.
POST /v1/journeys/start
{
"journey_key": "transaction-approval",
"subject_id": "customer-4821",
"action": "approve-transfer",
"operation_reference": "TRANSFER-12345",
"risk_level": "high"
}
POST /v1/journeys/siteverify
{
"session_token": "vg_journey_...",
"response": "vg_response_...",
"action": "approve-transfer",
"operation_reference": "TRANSFER-12345"
}Make identity and authorization part of the application workflow.
Build reusable policies for onboarding, KYC, recovery, payments, workforce operations, and app access—without exposing private verification logic to the client.