1. 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.

1.1. Verification Steps¶

1.1.1. 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 [1], the entire transaction is sent to MIR for manual verification.

[1]	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.

1.1.2. 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.

1.1.3. 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 [2]. Then, it will compare the segmented images against the individually captured fingerprints (usually, rolled fingerprint captures).

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 [3], no correction is performed and the entire original transaction is sent to MIR.

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

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

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

The comparison workflow for sequence check will be the following:

1.1.3.1. Comparison Workflow¶

The individual fingerprint images (rolled or flat) with indexes between 0 and 3 [4] 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.

[4]	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

1.2. 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.

1.2.1. 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:

1.2.1.1. Quality Analysis - Approved¶

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

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

1.2.1.2. Enroll - Enrolled¶

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

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

1.2.2. 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:

1.2.2.1. 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"
}

1.2.2.2. Enroll - Enrolled¶

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

Note

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"
}

1.2.3. Transaction Rejected¶

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

[5]	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:

1.2.3.1. Quality Analysis - Rejected¶

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

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

1.2.3.2. 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"
}