Skip to main content

Palm Verification

Optional feature

Palm verification is an optional feature, enabled per tenant on request. When it is off, the palm workflow steps, Trust Factors and back-office tabs are not shown.

Palm verification adds the palm as a second biometric modality next to the face. A Customer enrols both palms during onboarding and can later authenticate with either one — captured with the camera of any ordinary smartphone, no dedicated hardware. It is attractive where face authentication is not wanted or not possible: shared devices, users who do not want to show their face, or as a second, independent factor for high-value actions.

What it does​

CapabilityDescription
Both-palms enrolmentInside an onboarding workflow the User captures the left and the right palm. Each capture is checked for injection attacks, palm liveness, the palm side (the back of the hand is rejected) and which hand it is. After the first palm, the User is guided to capture the other hand.
Single-palm authenticationAn existing Customer shows either palm. The platform identifies the hand and compares it 1:1 against the same-hand palm stored for that Customer.
Palm Trust FactorsTwo configurable thresholds — palm liveness and palm matching score — decide whether a capture and a comparison are accepted.
Back-office visibilityA Palms tab shows the enrolled palms, and the Matching tab shows face and palm comparisons of an authentication case side by side.

Palm capture reuses the same protections as face capture: injection attack detection on the device and liveness evaluation on the server.

Enrolment in onboarding​

The both_palms_capture step is added to an onboarding workflow after the document and selfie captures, so that the palms are collected in the same session as the verified identity. This is what ties the palms to the person: there is no technology that can prove a palm belongs to the face on a document, so the binding comes from capturing everything in one verified session.

  1. The User captures the first palm — either hand.
  2. The capture is validated: no injection attack, liveness above the tenant's threshold, palm side facing the camera, hand identified as left or right.
  3. The User is asked to capture the other hand. A repeated capture of the same hand is rejected with an instruction to switch hands.
  4. Both palms are stored with the Digital Identity. When the identity becomes the Customer's primary identity, per-hand palm templates are created for later authentication.

A rejected capture is re-prompted with a reason the capture component shows to the User:

ReasonMeaning
dorsal_sideThe back of the hand was shown; the palm side is required.
same_hand_againThe same palm was captured twice; the other hand is expected.
liveness_below_thresholdThe palm liveness score is below the configured Trust Factor.
injection_detectedThe capture could not be trusted as a live camera capture.

Captures share the workflow's retake budget. When it is exhausted the session ends as Incomplete with the reason palm_not_captured.

Users who cannot present both hands are handled by the integrator's own user journey (for example an assisted or face-only workflow); the platform does not decide this on their behalf.

Authentication​

A palm authentication workflow consists of single_palm_capture followed by palm_matching, and is started for a known Customer (the session carries the Customer identifier, exactly as in biometric authentication by face).

  • The User shows either palm. The platform detects which hand it is and compares it against the stored template of the same hand.
  • palm_matching.result is match or no_match, judged against the palm matching score Trust Factor.
  • If the Customer has no palms enrolled, the session cannot be started — the API returns an error before any capture, so the app can fall back to another method.
  • Customers who enrolled palms only (no face) are fully supported for palm authentication.

Face and palm can be combined in one workflow; the Matching tab then shows both comparisons.

Trust Factors​

Trust FactorGroupWhat it judges
palm_liveness_thresholdPalmMinimum liveness score (0–1) of every palm capture. Captures below it are re-prompted.
palm_matching_score_thresholdPalmMinimum similarity (0–1) for palm_matching to return match.

Both are configured per Trust Factor configuration in IDV Configuration → Trust Factors, in the Palm Trust Factors section.

Data handling​

  • Palm images are stored with the Digital Identity on the Stored data tier; palm verification therefore requires that tier (see Deployment Models & Data Tiers).
  • Authentication uses palm templates derived from the Customer's primary identity, one per hand. Re-pointing the primary identity re-creates the templates, exactly as for faces.
  • Palms are not searched 1:N. There is no palm watchlist or palm blocklist; duplicity checks remain face- and document-based.
  • Anonymization removes palm images and templates together with the rest of the Customer's biometrics.

Back office​

  • Palms tab on the Digital Identity detail: the captured palms, left then right, zoomable. An authentication identity shows only the palm that was presented.
  • Matching tab: for an authentication case, a faces section, a palms section (with the hand indicated) and the session metadata. Only the modalities that were compared are shown.

Limits of the first release​

  • No palm 1:N identification and no palm blocklist.
  • One palm is matched at a time; combined two-hand matching is not offered yet.

See also​