Sequence and Quality Control

Whenever GBDS receives a new transaction, a sequence and quality control check is performed. This verification has the purpose of avoiding bad transactions from being inserted in the database.

Any transaction rejected by the sequence and quality control is sent to MIR for manual review.

See the Manual Image Review (MIR) Manual for further information about how to deal with transactions sent to manual review.

Verification Steps

Quality Check

The first step when receiving a new transaction is for GBDS to perform a quality verification on each biometric template submitted.

If any template's quality does not reach the configured threshold, the entire transaction is sent to MIR for manual verification.

See the GBDS Configuration Manual or contact the Griaule Support Team for further information.

Any issue identified by this verification step will be returned as"QualityIssue" by the API.

Duplicities Check

In this step, GBDS compares each individual fingerprint against the other ones to check for duplicities.

If any duplicity is identified, the transaction is sent to MIR for manual verification.

Any issue identified by this verification step will be returned as"DuplicationIssue" by the API.

Sequence Check

To perform this step, GBDS requires 4-slap fingerprint images (indexes 940 and 941).

GBDS will try to segment these images and extract a pre-determined number of biometrics. Then, it will compare the segmented images against the individually captured fingerprints (usually, rolled fingerprint captures).

In cases of amputation or temporary disability, a 4-finger slap image can contain less than 4 fingers.

If any comparison in this step identifies a no match, GBDS will try to find the correct index of the non-matching finger and perform an auto-correction.

If there are any issues identified that GBDS cannot auto-correct, or the number of auto-corrections required is greater than the configured maximum, no correction is performed and the entire original transaction is sent to MIR.

See the GBDS Configuration Manual or contact the Griaule Support Team for further information.

Any issue identified by this verification step will be returned as"SequenceControlIssue" by the API.

The comparison workflow for sequence check will be the following:

Comparison Workflow

The individual fingerprint images (rolled or flat) with indexes between 0 and 3 will be compared against the segmented images from index 940.

Then, the individual fingerprint images with indexes between 6 and 9 will be compared against the segmented images from index 941.

The indexes for individual fingerprint images are:

Index	Finger	Index	Finger
0	Left Minimum	5	Right Thumb
1	Left Ring	6	Right Indicator
2	Left Middle	7	Right Middle
3	Left Indicator	8	Right Ring
4	Left Thumb	9	Right Minimum

Treating Anomalies

To see more information about the MIR tool and processes for treating anomalies, see the MIR specific manual, as mentioned above.

In this section, the server-side procedures for quality analysis will be detailed, from the moment GBDS receives the provided decision from MIR.

Transaction Approved without Changes

Given this decision, GBDS will keep the original transaction without changes and continue the enrollment procedure. The Transaction GUID (TGUID) will remain the same for both operations (QUALITY_ANALYSIS and ENROLL).

The notification flow will be the following:

Quality Analysis - Approved

The first notification will contain the status "APPROVED" for the"QUALITY_ANALYSIS" operation.

{
    "operation": "QUALITY_ANALYSIS",
    "tguid": "<tguid>",
    "status": "APPROVED"
}

Enroll - Enrolled

The second notification will contain the status "ENROLLED" for the following "ENROLL" operation.

{
    "operation": "ENROLL",
    "tguid": "<tguid>",
    "status": "ENROLLED"
}

Transaction Approved with Changes

Given this decision, GBDS will keep the changes made by the analyzer (deleted or edited images) and generate a new TGUID for the enrollment.

The notification flow for this decision will be similar to that for “Transaction Approved without Changes”, adding the new TGUID:

Quality Analysis - Approved

The first notification will contain the status "APPROVED" for the"QUALITY_ANALYSIS" operation and also include a field"newTransactionGUID" denoting the transaction was accepted with changes and pointing to the new TGUID.

{
    "newTransactionGUID": "<new_tguid>",
    "operation": "QUALITY_ANALYSIS",
    "tguid": "<original_tguid>",
    "status": "APPROVED"
}

Enroll - Enrolled

The second notification will contain the status "ENROLLED" for the following "ENROLL" operation.

The ENROLL operation will be performed for the changed transaction, so the TGUID mentioned will be the new one generated by the QUALITY_ANALYSIS operation.

{
    "operation": "ENROLL",
    "tguid": "<new_tguid>",
    "status": "ENROLLED"
}

Transaction Rejected

Given this decision, GBDS will not continue the enrollment process and will “discard” the entire transaction. The TGUID will remain the same.

The transaction history will be kept, but the profile will not be inserted into the database as an active person register.

The notification flow will be as follows:

Quality Analysis - Rejected

The first notification will contain the status "REJECTED" for the"QUALITY_ANALYSIS" operation.

{
    "operation": "QUALITY_ANALYSIS",
    "tguid": "<tguid>",
    "status": "REJECTED"
}

Enroll - Failed

The QUALITY_ANALYSIS operation result will be followed by an enrollment notification pointing to the status "FAILED" for the "ENROLL" operation.

{
    "operation": "ENROLL",
    "tguid": "tguid",
    "status": "FAILED"
}