What does Consent Verification actually prove?
It proves the user actively presented the exact text the merchant submitted, creating a verifiable evidence record that the user approved a specific action: a withdrawal, payout change, device change, account recovery, or any merchant-defined event. The evidence bundle carries the captured artefact, matched OCR output, timestamp, session metadata, and a tamper-evident hash.
How is this different from liveness?
Liveness confirms the person is live on camera. It does not confirm what the person authorised. Consent Verification adds the authorisation layer by verifying a transaction-specific physical artefact carrying merchant-submitted text. Motion-based prompts are replayable by injection tools; a physical note with dynamic text is mathematically harder to fake in real-time.
How does it resist video-injection and deepfake attacks?
Two layers. First, capture requires a physical artefact with dynamic merchant-submitted text rendered in real-time lighting, shadow, grain, and hand interaction. Second, when face is enabled, the face layer applies iBeta PAD Level 2-tested passive and active liveness. The combined pipeline blocks the majority of replay, emulator, and virtual-camera injection attempts.
Can the consent text be customised?
Yes. Merchants submit the exact text per transaction via REST API, 4 to 400 characters, with dynamic tokens (transaction ID, amount, date, merchant-defined fields) substituted at request time. Pre-configured templates support onboarding, payout, recovery, and device-change flows.
Can face capture be required, optional, or prohibited?
All three. Face-required for high-risk actions (crypto withdrawals, payout changes), face-optional for mid-risk step-ups, and face-prohibited where biometric-consent law (BIPA, TDPSA, Washington MHMDA) makes face capture undesirable. Configurable at account level with per-transaction override.
What if the user cannot handwrite the note?
Three fallbacks: the user may print the text and present the printed copy; type the text in a merchant-provided form and present the typewritten output; or the merchant may switch to face-match-only at a lower assurance level. Accessibility accommodations are configurable per jurisdiction.
Where is data processed and what retention applies?
Data is processed in the merchant-selected region — EU (Frankfurt, Dublin), UK (London), US (Virginia, Oregon), APAC (Singapore, Tokyo, Mumbai), or MENA (Bahrain) — and does not leave that region by default. Retention is client-configurable 30 days to 10 years. DPA and SCC on request.
Can Consent Verification deploy on-premises or private cloud?
Yes. Consent Verification is a first-party Shufti capture technology: Shufti owns the OCR stack, face-match stack, and policy engine end-to-end, and they run on infrastructure the customer can isolate. Supported models include regional public cloud, dedicated private cloud, on-premises, and air-gapped deployment for regulated environments.
Which certifications apply?
PCI DSS applies at company level to cardholder-data handling. ISO 27001 and SOC 2 Type II scope and current status are confirmed on request under NDA. iBeta PAD Level 2 applies to the live-face-match component when face is enabled. ETSI conformity for electronic identification is in progress. DHS RIVR 2025 applies upstream to Shufti document verification, which Consent Verification can be layered onto.