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 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 a new transaction is received is for GBDS to perform a quality check on 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 issue 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 duplicates.

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

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

Sequence Check

To perform this step, GBDS requires simultaneously captured slapped fingerprint images (4-slap fingerprint) (indices 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 mismatch, GBDS will try to correct the index of the mismatching fingers and perform a self-correction.

If there is any identified issue 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 issue identified in this verification step will be returned as "SequenceControlIssue" by the API.

The comparison flow for sequence checking will be as follows:

Comparison Workflow

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

Then, the individual fingerprint images at indices between 6 and 9 will be compared against the segmented images at index 941.

The indices for the individual fingerprint images are:

Index	Fingerprint	Index	Fingerprint
0	Left Little	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 anomaly handling processes, see the MIR manual, as mentioned above.

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

Approved Transaction Without Changes

Given this decision, GBDS will keep the original transaction unchanged and continue the enrollment process. The GUID (Global Unique IDentifier) of the transaction (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 "QUALITY_ANALYSIS".

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

Enrollment - Enrolled

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

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

Approved Transaction With Changes

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

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

Quality Analysis - Approved

The first notification will contain the status "APPROVED" for operation "QUALITY_ANALYSIS" and will include the new field "newTransactionGUID" indicating 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 "ENROLL".

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

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

Rejected Transaction

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" for the operation "QUALITY_ANALYSIS".

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

Enrollment - Failed

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

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