Biographic Target

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

Behavior

In exception generation

Every time an exception is generated, a corresponding group is created/updated with:

• status: ANALYSIS

• target: according to the type of exception; if there is more than one exception for a given TGUID, the group's type is BIOMETRIC if there is any BIOMETRIC exception

• No priority

• Organizations: all exception organizations pointing to the group and exception with indication of origin ENTRANT or REFERENCE

In each biometric exception handling

If there is no exception group, it will be created from the exceptions' TGUIDs

Definition of Target

• If there is any BIOMETRIC_MISMATCH exception, the group will be defined as BIOMETRIC_MISMATCH

• If all the exceptions are BIOMETRIC_INCONCLUSIVE, BIOMETRIC_MISMATCH or BIOGRAPHIC:

  • BIOMETRIC_MISMATCH if there is any BIOMETRIC_MISMATCH exception

  • BIOMETRIC_INCONCLUSIVE if there is any BIOMETRIC_INCONCLUSIVE exception

  • Otherwise, the group will be of type BIOGRAPHIC

• If the exception has an associated final result, in the case where all exceptions for TGUID are handled without CSI, the group's decision will change:

  • Final result APPROVED, group's decision is changed to APPROVED

  • If the final result is REJECT, the group's decision is changed to REJECT

Biometric exception prioritization

When an exception is prioritized using the set priority endpoint, the group will also be prioritized

If all exceptions are deprioritized, the group will be deprioritized as well (using the same endpoint)

Next exception group

When the next exception group is requested, it must have:

• status ANALYSIS

• target BIOGRAPHIC, BIOMETRIC_MISMATCH or BIOMETRIC_INCONCLUSIVE

• Not be allocated to anyone

• The group must have an organization among the user's organizations

  • If an origin of the organization was not requested, the group with all organizations will be considered

  • If the requested origin is ENTRANT or BOTH, the group with the organization in the requested origin will be considered.

• Groups are ordered by priority, pending status and creation date in ascending order, by default

• The user must have biographic permission

With a selected group, the user will be allocated to that group for a given time, according to the configuration. If the configuration has value -1 the group will never be deallocated and will need to be deallocated manually through the endpoint Unlock Group.

Manual allocation and deallocation

Can be done from the endpoints Lock group and Unlock group

A group cannot be allocated if it is already allocated to another user and cannot be deallocated if it is not allocated to the provided user

For each group handling

The validations to be performed are:

• User and permissions must be provided, unless security is enabled, in which case both are provided by the token

• Timeout is zero by default, when the treatment is final and the exception is treated as APPROVE, this value is used

• Group GGUID and the group's decision status (KEEP or REJECT) are mandatory

• Group must exist and be in status/target ANALYSIS/BIOGRAPHIC, BIOMETRIC_MISMATCH or BIOMETRIC_INCONCLUSIVE

• Group must be allocated to the user

• The user must have some organization present in the group

• The user cannot have made a decision for this candidate previously

• The biometric must be allocated to the user

If the status decision is KEEP: Registration - Parameters must be provided with at least one key, biographics and labels are optional and all TGUIDs to be stored must be exceptions of the group, from the entrant or the reference

Update - the TGUIDs to be stored must be exceptions of the group, entrant and/or reference may be kept.

If all validations are approved, the user's decision, the user, comments and parameters will be saved in the group

Removal of transactions from the group under handling

To remove transactions that belong to BIOMETRIC_MISMATCH or BIOMETRIC_INCONCLUSIVE exceptions the transactions must be provided through parameters that will be removed using removeTransactions in the parameters.

In this case:

• The group must be a registration exception group

• It is not allowed to remove the entrant transaction

• The removed transactions must be from the reference transaction group of any biometric exception group inconclusive or mismatch

• Removal transactions must not conflict with retention transactions

Pending decision

If the user requests a rejection of some transaction whose organizations are not within their organizations, the group is marked with status PENDING and the group's handling is done by the endpoint treat pending group

Exception group update

• REJECT: rejects entrant and reference and deletes the references

• KEEP: keeps only reference

  • Rejects all exceptions

• KEEP: keeps the entrant

  • Rejects all exceptions

  • Deletes the references

  • Resends the entrant transaction as registration

• KEEP: reference and entrant are kept

  • All exceptions are approved

If transactions to be removed are provided, they will not be applied to the unified profile and their profiles will not be deleted

Group in pending handling

For groups whose handling decision is pending, handling is done with the endpoint of treat pending group

The validations differ from regular handling in:

• The group must be pending decision

• the user must have an organization present in all group's transactions.

If the transaction is rejected, the group returns to ANALYSIS status

If accepted, the handling will be done as described above.

Priority

When a group is prioritized or deprioritized, all exceptions for the same group are affected.