For the complete documentation index, see llms.txt. This page is also available as Markdown.

Biometric Target

Documentation related to Target Biometrico and its behavior. This functionality is available only from GBDS version 5 onward.

Behavior

In any enroll/update

If a transaction does not have "origin", which means there is no label referring to an origin organization, the transaction will have, for exception purposes, origin from higher-level organizations.

Example: A transaction registered in an environment with organization ori_griaule as the highest-level organization (without a parent organization), will have ori_griaule as origin

In exception generation

CSI means Simplified Nonconformity Cycle. It is a system used to evaluate biometric data, determining whether a biometric candidate is HIT, NO_HIT, or UNCERTAIN based on specific thresholds during registration or updates. A candidate is marked as HIT if its match is above the CSI threshold, NO_HIT if it is not, and UNCERTAIN if its match is below the threshold.

  • Finger hit: all matches for fingers reach the minimum biometric count

  • Finger No Hit: all finger non-matches reach the minimum biometric count

  • Face Hit: all matches for face

  • Face No Hit: all face non-matches reach the minimum biometric count

  • Each candidate will be marked as HIT, NO_HIT, or UNCERTAIN

    • If the biometric candidate is not a match, it will be a NO_HIT

    • If the biometric candidate is a match with a value below the CSI threshold, it will be UNCERTAIN, according to the enroll/update and finger/face settings

    • If the biometric candidate matches with a value above the CSI threshold, it will be a HIT, according to the enroll/update and finger/face settings

  • Exceptions will be marked as target BIOMETRIC, BIOMETRIC_INCONCLUSIVE, BIOMETRIC_MISMATCH or BIOGRAPHIC:

Registration

Finger
Face
Exception

HIT

HIT

BIOGRAPHIC

HIT

NO HIT

BIOMETRIC_MISMATCH

NO HIT

HIT

BIOMETRIC_MISMATCH

  • Without finger or face hit and without finger or face no hit:

    • with biometric uncertainty, generates an exception BIOMETRIC

    • with biometric certainty, generates an exception BIOMETRIC_INCONCLUSIVE

Update

Finger
Face
Exception

NO HIT

NO HIT

BIOGRAPHIC

HIT

NO HIT

BIOMETRIC_MISMATCH

NO HIT

HIT

BIOMETRIC_MISMATCH

If no finger or face is considered HIT or NO_HIT:

  • with biometric uncertainty, generates a BIOMETRIC exception

  • with biometric certainty, generates a BIOMETRIC_INCONCLUSIVE exception

Next biometric

The next biometric to be evaluated will be:

  • Belonging to a candidate with exception in ANALYSIS

  • With an overall decision of UNCERTAIN

  • Not allocated to anyone

  • From an exception where the incoming transaction or the incoming and reference transaction contain a label with at least one of the organizations from the user's permission labels

    • Can be configured from the endpoint with the parameter origin

      • ENTRANT, will be filtered only by the incoming transaction

      • BOTH, will be filtered by both transactions

The list of organizations provided is hierarchical, which means that if an organization has children, all children will be considered to find exceptions. With security enabled, this list of organizations is retrieved from the user's permissions, with all permissions that start with the configured organization prefix, default "ori_".

Finger and/or face will be returned according to the user's configured permission, by default "tpca" for fingerprints and "fca" for face, or according to the request for fingerprint or face

If the "double blind" setting is enabled, the user assigned to the biometric cannot have previously decided on biometric

The order for the next biometric is decided by priority and the order provided in the endpoint. If none is provided, the default order is from oldest.

GET next biometric will return the number of biometrics available to be processed, which are

  • All UNCERTAIN of target BIOMETRIC with ANALYSIS status not decided by the user making the next biometric request, available for the organization to which the user belongs and, if requested by fingerprint or face, will be counted from the selected option

With a biometric selected, it will be allocated to the user for 5 minutes.

Manual Unlock

Can be done using the endpoint Unlock biometric

For each biometric processing

The validations to be performed are:

  • User must be provided, unless security is enabled; in that case, the user is provided by the token

  • Timeout is zero by default; when the processing is final and the exception is handled as APPROVE, this value is used

  • Required parameters: enroll TGUID, exception PGUID, decision and index

  • Exception must exist and be in ANALYSIS and in target BIOMETRIC (the other types are not handled at this stage)

  • Exception candidate must have an index and be classified as UNCERTAIN

  • The biometric candidate must be allocated to the user or not allocated to any other user

  • The user must not have made a decision for this candidate before

  • The biometric must be allocated to the user

If everything passes, the decision is marked on the candidate and the candidate is released (deallocated)

Double Blind

Double Blind
Decision

On

The decision is final when there are enough equal decisions (configured in gbds.csi.doubleBlind.threshold)

Off

Final

Final decision

If the decision is not final, the exception status is NOT_FINAL

If the decision is final and all required processing is completed:

Registration

APPROVE - No hit of finger and face reach the minimum count for registration, being considered a false positive

BIOGRAPHIC - Finger hit and face hit reach the minimum count for registration

BIOMETRIC_MISMATCH - If finger hits and face non-hits/finger non-hits and face hits reach the minimum count for registration

BIOMETRIC_INCONCLUSIVE - If all decisions are made but no conclusion is reached

Update

APPROVE - If finger hit and face hit reach the minimum count for update, being considered a false negative

BIOGRAPHIC - Finger no hit and face no hit reach the minimum count for update

BIOMETRIC_MISMATCH - If finger hits and face non-hits/finger non-hits and face hits reach the minimum count for update

BIOMETRIC_INCONCLUSIVE - If all decisions are made but no conclusion is reached (all HIT, NO_HIT or UNCERTAIN_EXPERT, but without a defined minimum value)

Priority

When an exception is prioritized or deprioritized, all exceptions for the same entrant are affected.

Last updated

Was this helpful?