Quality and Sequence Control

When GBDS receives a new transaction, a quality and sequence control check is performed. This verification aims to prevent bad transactions from being inserted into the database.

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

See the MIR manual (Manual Image Review) for more information on how to handle transactions sent to it.

Verification Steps

Quality Check

The first step when receiving a new transaction is to perform a quality check by GBDS of each submitted biometric template.

If the quality of any template 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 more information.

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

Duplication Check

In this step, GBDS compares each fingerprint against the others to check for duplication.

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

Any problem identified in this step will be returned as "DuplicationIssue" by the API.

Sequence Check

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

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

In cases of amputation or temporary disability, the image may contain fewer than four fingers.

If any comparison identifies a non-match, GBDS will attempt to correct the index of the fingers that do not match and will perform a self-correction.

If there is any problem identified that GBDS cannot self-correct, or if the number of self-corrections is greater than the configured maximum, no correction will be made and the transaction will be sent to MIR.

See the GBDS configuration manual or contact the Griaule support team for more information.

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

The comparison flow for sequence check will be as follows:

Comparison Workflow

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

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

The indexes for the individual fingerprint images are:

Index	Fingerprint	Index	Fingerprint
0	Little Left	5	Right Thumb
1	Left Ring	6	Right Index
2	Left Middle	7	Right Middle
3	Left Index	8	Right Ring
4	Left Thumb	9	Right Little

Handling Anomalies

For more information about MIR and the anomaly handling processes, see the MIR manual, as mentioned above.

In this section, the quality analysis processes performed by the server will be detailed, from the moment GBDS receives the decision provided by MIR.

Transaction Approved Without Changes

Given this decision, GBDS will keep the original transaction unchanged and will continue the enrollment process. The transaction's GUID (Global Unique IDentifier) (TGUID) will remain the same for both operations (QUALITY_ANALYSIS and ENROLL).

The notification flow will be as follows:

Quality Analysis - Approved

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

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

Enrollment - Enrolled

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

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

Transaction Approved with Changes

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

The notification flow for this decision is similar to that generated by "Transaction Approved without Changes", adding the new TGUID:

Quality Analysis - Approved

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

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

Enrollment - Enrolled

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

The ENROLL will be performed for the modified transaction, so the TGUID mentioned will be the new one that was generated by the operation of QUALITY_ANALYSIS.

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

Transaction Rejected

Given the 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 record.

The notification flow will be as follows:

Quality Analysis - Rejected

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

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

Enrollment - Failed

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

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