Trust

1. Overview of the Tool

Trust is a GBS tool used to resolve conflicts between biometric or biographical data that require human intervention. In these situations, a specialist analyzes the involved profiles and chooses whether to keep, merge, or reject any of them. Decisions directly affect the database, and queued transactions are only reprocessed after the case is resolved. The tool is used in different contexts, such as:

• Identity issuance: when there are registration attempts with inconsistent data;

• Banking systems: ensure that each client or account holder’s authenticity and uniqueness are guaranteed, and their identity correctly verified;

• Elections: to ensure voter uniqueness.

1.1 What does Trust solve in practice?

Trust was created to address inconsistencies that compromise the integrity of the unique database, such as:

• The same individual trying to register with different documents and names;

• Matching biometrics associated with conflicting biographical data;

• Incorrect registry updates, which diverge from the original identity.

1.2 What are the main benefits of using Trust?

Using Trust, you can have:

• Database reliability: ensures that only legitimate and consistent profiles remain, preventing duplications and fraud.

• Transparency and traceability: all actions are recorded, allowing audits and ensuring confidence in decisions.

• Operational agility: an intuitive interface, with well-defined flows that facilitate analysts’ work.

• Decision security: provides detailed comparisons between biometric and biographical data, supporting technical and well-founded decisions.

• Integration with other tools: connects to Intelligence for quick access to the transaction history.

2. Essential Concepts

In this section, you will find the main concepts and structures that make up how Trust operates. They help understand how the system organizes information, how conflicts are detected and handled, and the role of users and permissions in the decision process.

2.1 Profile

The profile represents a unique individual in the database. Each profile gathers consolidated and validated biographical and biometric data.

The database ensures that there are not two profiles with the same key or biometrics, guaranteeing uniqueness. Existing profiles are compared with the data received in a new registration to check for possible conflicts with the database rules.

2.2 Nonconformity

In the context of Trust, a nonconformity is a situation in which the data of a new registration or an update do not match the information already recorded in the database. This can happen, for example, when:

1. Same Biometrics with Different Keys (Same biometrics) This situation occurs in enroll (registration) transactions when two individuals, with the same type of key (such as CPF), but with different values, present identical biometrics (fingerprint and face), which may indicate duplicate registrations.

2. Different Biometrics with the Same Key It occurs in update (update) transactions, when two people share the same key (same CPF number, for example), but present distinct biometrics. This suggests possible inconsistency or identity mix-up.

3. Inconclusive Biometrics They can occur both in enroll and in update, in two main scenarios:

• When there is one biometric modality equal (e.g., fingerprints) and another different (e.g., face), which may indicate an attempt at fraud or the existence of identical twins.

• When the quality of the biometrics is so low that neither the system nor the experts can conclude whether they are the same or different.

4. Update Nonconformity The biometrics recorded during the update are different from the previous ones, indicating a possible identity swap or error in the process.

5. Registration Nonconformity The provided biometrics already exist in the database but are associated with another profile, which may indicate duplication or an attempted fraud.

Types of nonconformity

These conflicts prevent the system from automatically approving the data entry. Therefore, the nonconformity must be manually analyzed in Trust to decide what to do with the involved profiles, whether they should be unified, rejected, or kept separate.

The system can detect different types of nonconformity:

• Biometric: When there is a pending biometric analysis in the group (e.g., fingerprints or face of the transaction match those of another profile).

• Biographical: When there is a pending biographical analysis in the group (all biometric analyses have already been done)

• Mixed: occurs when there is a simultaneous conflict between biometric and biographical data.

2.3 Nonconformity Group (or Group)

In Trust, the group is the central unit of analysis. It is formed by all profiles and transactions related to the same nonconformity, originated by a transaction attempting to enter the database. This transaction is compared with existing profiles and, when there is a conflict, all involved are gathered into a single group to facilitate visualization and handling. The group is analyzed jointly, allowing the specialist to understand the whole case before deciding what should happen in the database.

2.4 Transaction

In the context of Trust, a transaction is the attempt to insert or update data in the GBDS database. It can refer either to the registration of a new individual or to an update of data of an individual already existing in the database.

Each transaction contains biometric information (such as fingerprints and face) and biographical information (such as name, CPF, date of birth) of an individual. The system assesses whether the provided key (e.g., CPF, Voter Registration) already exists in the database to determine whether the transaction is an update or a new registration.

There are two main forms of transaction:

• Registration: When a new individual is added to the database.

• Update: When a new transaction is submitted for an individual who was already registered in the database.

2.5 Transactions Pending Resolution

These are transactions that conflict with a profile already involved in a nonconformity group that has not yet been resolved. For this reason, they cannot be processed immediately and remain in a waiting state until the previous group is finalized.

After the resolution of the group that caused the blockage, these transactions are automatically reprocessed. At that moment, they may be accepted directly or generate a new nonconformity group, depending on the duplication result.

2.6 Biometric Comparison

The biometric comparison feature allows the operator to view side by side pairs of biometrics (face and fingerprints) between the transaction and the profile under analysis. Each pair is presented with a colored border that indicates the result of the comparison performed by the system:

• Green: high similarity between the biometrics

• Red: low similarity between the biometrics

• Gray: inconclusive result

2.7 Confirmation of Treatment

Choice made at the end of the group analysis, defining what will happen to the profiles and the incoming transaction. The main decisions are:

• Reject transaction

• Unify profiles

• Keep the profiles distinct

2.8 Hierarchy and Permissions

Users have different permission levels based on the organization to which they are linked and this affects what they can view and decide within the Trust system.

Only users with appropriate permissions can make certain changes, since some actions require validation by a higher organization, which ensures greater security and governance in decisions that affect multiple institutions.

2.9 Biometric Conflict

A biometric conflict occurs when the biometric presented in a transaction (such as fingerprints or face) differs from the biometric already registered for the same key or matches the biometric of another profile in the database with a different key. This inconsistency can indicate a registration error, duplication, or even an attempted fraud. Biometric conflicts are among the main causes that generate nonconformities and require manual analysis.

2.10 Biometric Decision

The biometric decision is the conclusion about the similarity between two biometrics. It can be made automatically by the system, based on the comparison score, or manually by experts. Very high scores indicate compatible biometrics, while very low scores indicate different biometrics. When the score is in an intermediate (inconclusive) range, expert evaluation is required. The biometric decision guides the handling of the nonconformity, indicating whether the data belong to the same person or not.

2.11 Biometric Analysis

Biometric analysis is the process of visual evaluation of the biometrics involved in a nonconformity. It occurs only when the biometrics fall into an inconclusive zone (neither a very high nor a very low score). In this case, experts compare fingerprints or facial images to determine if they belong to the same person. The analysis is performed independently by more than one expert and requires consensus to proceed with the handling. Possible decisions are: compatible biometric, incompatible, or inconclusive.

3. Operational Flow

This section describes step by step how the Trust tool works, reflecting the real workflow of users in the analysis and handling of nonconformities. It includes the detection logic, the criteria that define possible flows, and the decisions that impact the database.

3.1 Home screen

This is the screen that gives access to the analyses available to a user. The displayed information varies according to the user’s permissions (types of analysis they can perform) and the organization to which they are linked.

At the top of the screen, there are buttons that lead to the next available analysis. The choice of which analysis to perform follows the prioritization logic defined by the system settings; the operator does not select which transaction they will analyze, but rather handles the next one in the queue.

Counters are also displayed indicating how many analyses are still available for that user.

3.1.2 Detection of the Nonconformity

The Trust system detects a nonconformity when a registration or update transaction conflicts with the consolidated data in the database. Verification is done through algorithms that assess consistency between the received data and existing data, considering biometric information (such as fingerprints and face) and biographical information (such as name, date of birth and document numbers).

Detection criteria for registrations and updates

The transaction can represent:

• A new registration, when the identification key (for example, CPF or Voter Registration) does not yet exist in the database.

• An update, when the key is already registered in the database and a new transaction with the same keys is made.

The nonconformity detection logic varies according to the type of transaction:

• In the case of registration, the submitted data are compared with all existing profiles in the database, searching for biometric similarities that indicate duplication.

• In the case of update, the transaction data are compared with the data of the source profile. If there is inconsistency (for example, the biometric submitted belongs to another person), a nonconformity is generated.

Detection algorithms

The database uses matching algorithms that compare the transaction data with existing profiles. For biometrics, defined similarity thresholds are used to determine whether there is a match or not. In case of doubt or uncertainty, the system does not decide automatically; the analysis is forwarded to human operators, with the support of facial analysis and fingerprint analysis tools.

Examples of situations that generate nonconformities:

• A new registration has fingerprints that match those of an existing profile, even with different biographical data.

• An update attempts to change the biometric (for example, the face) of a profile, but the new biometric does not correspond to the reference profile with the same keys.

These situations prevent the automatic acceptance of the transaction and trigger manual analysis flows by specialists.

3.1.3 Possible analysis flows from the nonconformity

After detecting the nonconformity, the system can route the generated group to different types of biometric and biographical analysis:

• Facial analysis only: if the conflict is facial and there is no indication of issues with fingerprints.

• Fingerprint analysis only: if the conflict is exclusively in the fingerprints.

• Facial and fingerprint analysis: if inconsistencies are detected in both biometric modalities.

• Facial and/or fingerprint analysis, but without the need for data or image comparison: in some cases, even with biometric analysis required, the biographical analysis is not enabled due to the absence of conflict in the biographical data.

Biographical analysis is presented only if the system identifies divergences in the biographical data. If the biographical data are compatible and there is no risk of altering the database content, the biographical analysis step may not occur.

3.2. Access to the Analysis Queue

After detecting a nonconformity, the corresponding group is forwarded for analysis by authorized operators. The system organizes and makes these analyses available through a specific interface, which allows controlled and ordered access to pending nonconformities for handling.

3.2.1 Queue organization (prioritization and allocation)

The prioritization of analyses follows rules that consider, among other factors, the waiting time of the nonconformity and the current status of the group. There is an administrator panel that allows configuring priority rules for certain groups or types of transactions.

Analysis allocation can occur in two ways:

• Automatic distribution: the system delivers an available analysis directly to the user, according to their permission and organizational scope.

• Manual selection: the user freely chooses which nonconformity to analyze; currently, this type of selection is only possible in the administrator panel, through a direct search by the involved person’s key.

3.2.2 How the user receives an analysis

When accessing the analysis screen, the system may automatically present an available group, according to the distribution logic. Alternatively, the operator can use the search and filter resources in the administrator panel to select the analysis they wish to handle. The permissions of the organization to which the operator is linked determine which groups will be visible or available for handling.

3.2.3 Access interface: priority queue analysis and assigned analyses panel

The Trust access interface allows the operator to choose the type of nonconformity to be handled, within the specific groups they have access to. The main features of this interface include:

• Analyses of nonconformities in priority order, which include:

  • Fingerprint analysis: comparison of fingerprints to verify whether they belong to the same person.

  • Face analysis: comparison of facial images when there is uncertainty in the automatic match.

  • Biographical analysis: evaluation of conflicts between data such as name, date of birth and parentage.

  • Pending approval: cases already handled that await final confirmation by a second operator.

• Assigned analyses panel: each operator has a panel with the analyses already assigned to them, that is, those in which they started the biographical analysis but have not yet completed the handling. This panel allows resuming pending cases and ensures that the same nonconformity is not handled by more than one operator.

3.3. Biometric Analyses

The biometric analysis step involves checking similarity between facial and fingerprint records detected by the system as possible matches. Analyses are separated into two distinct interfaces: face analysis and fingerprint analysis. Each has its own flows and specific evaluation criteria.

3.3.1. Face analysis

Display criterion in face analysis (uncertainty threshold)

A case is directed for manual handling whenever the facial similarity score between two images is within an uncertainty range, that is, within an interval in which the system does not have sufficient confidence to make an automatic decision. The logic is to avoid false positives or negatives in cases of low or medium reliability.

Facial biometric comparison modal

By clicking the Face analysis button on the Trust home screen the system automatically selects the first case in the queue and opens a comparison modal that displays side by side the facial images of the two profiles being compared, without indicating to which profile they belong.

Interface operation

The face analysis interface presents the pairs of facial images to be compared. After the analysis, the operator must indicate their decision using the three buttons at the bottom of the screen, or via the corresponding shortcut keys:

• Different faces - red (key A)

• I cannot decide - gray (key S)

• Same faces - green (key D)

The operator’s decision is recorded and used in the following stages of the flow.

Once the decision is indicated, the case will be closed and the next case will be presented automatically on the operator’s screen. If there are no more cases to be handled, the corresponding message will be displayed on the screen.

To return to the home screen, just click the Trust logo in the upper left corner or on Analysis. The case that may be open without a decision will return to the analysis queue to be routed to another operator.

When marking as inconclusive

The option to mark the analysis as inconclusive should be used when the operator cannot determine with confidence whether the facial images correspond to the same person, even after detailed observation in the comparison modal. This button serves to signal that the decision cannot be made based on the presented data.

3.3.2. Fingerprint Analysis

Fingerprint biometric comparison modal

By clicking the Analysis of fingerprints on the home screen, the system automatically selects the first case in the queue and opens a comparison modal that displays side by side the images of the fingerprints of the two profiles being compared, without indicating to which profile they belong.

Interface operation

The fingerprint analysis interface presents the pairs of fingerprint images to be compared. After the analysis, the operator must indicate their decision using the three buttons at the bottom of the screen, or via the corresponding shortcut keys:

• Different fingerprints - red (key A)

• I cannot decide - gray (key S)

• Same fingerprints - green (key D)

The operator’s decision is recorded and used in the following stages of the flow.

Once the decision is indicated, the case will be closed and the next case will be presented automatically on the operator’s screen. If there are no more cases to be handled, the corresponding message will be displayed on the screen.

To return to the home screen, just click the Trust logo in the upper left corner or on Analysis. The case that may be open without a decision will return to the analysis queue to be routed to another operator.

Biometric fusion rules

The system considers multiple factors to determine whether the biometrics belong to the same person:

• Similarity threshold: comparison scores between fingerprints.

• Quality of biometrics: low-quality biometrics can make the decision difficult and justify an inconclusive status.

• Number of fingers with a “hit”: the number of matching fingers is a relevant factor for decision making. Agreement on few fingers may be sufficient or not, depending on quality and score.

It is important to emphasize that all 10 fingers will not always be available for analysis in Trust. The system only sends for manual verification the fingerprint pairs whose automatic comparison was not conclusive. That is, fingers with good quality and a very high score (indicating strong similarity) or very low (indicating strong difference) are automatically classified by the system, without need for manual review. Therefore, the operator may view only some pairs, such as 6 or 7 fingers, depending on the quality of the biometrics and the performance of the initial comparison.

When marking as inconclusive

As in facial analysis, the inconclusive button should be used when, after observing the fingerprints in the comparison modal, the operator cannot assert with confidence whether the fingerprints belong to the same person or not.

3.4. Biographical Analysis

After the biometric analysis step (facial and/or fingerprints), the system may forward the profile to the biographical analysis step, depending on the characteristics of the nonconformity. Biographical analysis is based on comparing the biographical data of the transaction (registration or update) with the data of the database profile being compared.

How to view and compare

The biographical data between profiles

The interface presents the biographical data of the transaction and the biographical data of the database profile, allowing the operator to compare the two sets of information. This view seeks to highlight convergences and divergences in the data, such as name, date of birth, parentage, among others.

During the biographical analysis, it is also possible to view the biometrics (face and fingerprints) of the involved profiles. This helps the user make a more substantiated decision if there is a need to review the biometric correspondence already analyzed previously.

Handling the nonconformity

In the Biographical Analysis the type of transaction is presented because each transaction type has specific situations that generate nonconformities:

• Registration - The nonconformity is generated when the group’s profiles present identical biometrics and different biographical keys.

• Update - The nonconformity is generated when the group’s profiles present different or inconclusive biometrics and identical biographical keys.

Each profile listed on the screen has a card with specific actions, according to the type of biometric match:

• For profiles with the same biometrics, the following actions are available:

  • Database decision: allows rejecting or unifying the profile with the incoming transaction.

  • Compare biometrics: opens a modal with the detailed comparison of the biometrics.

  • View profile in Intelligence: redirects to the profile in Intelligence.

Click "View profile in Intelligence" to check all registration data of a specific individual.

• For profiles with inconclusive biometrics, the available actions are:

  • Database decision: allows rejecting, unifying, or keeping separately (used in false positive cases).

  • Compare biometrics: opens a modal with the detailed comparison of the biometrics.

  • View profile in Intelligence: redirects to the profile in Intelligence.

In the biometric comparison modal, the similarity results between the biometrics of the incoming transaction and the selected profile are presented, with the following color code:

• Green: matching biometrics

• Red: differing biometrics

• Gray: inconclusive result

It is possible to select a specific biometric by clicking directly on it or using the index selection dropdown. The biometrics of the incoming transaction are displayed on the left and those of the selected profile on the right. From Trust version 1.1.0, these positions were reversed: the selected profile’s biometric began to be displayed on the left, while the incoming transaction’s began to appear on the right.

After performing the biometric comparison, the operator will be directed to a screen where the biographical data of the involved profiles will be displayed highlighting the divergent data. These data must be analyzed so that the correct values are maintained in the final profile.

On the confirmation screen, the following are presented:

• Profiles that will be unified

• Profiles that will be rejected

• Biographical data selected for the resulting profile

• Field for comment with the justification of the decisions

If there are transactions in queue waiting for the group under analysis, they are displayed in the Blocked Transactions section. After handling, if there are no more groups blocking, the transaction is automatically reprocessed.

Actions available by transaction type (registration or update)

The actions available on the biographical analysis screen vary according to the type of transaction that generated the nonconformity:

• For registration transactions:

  • Reject

  • Unify

• For update transactions:

  • Reject

  • Unify (when biometrics are matching)

  • Keep separately (when the biometric is inconclusive)

These actions should be chosen based on the biographical and biometric information available on the screen.

Choice of keys that will compose the final profile

The user can select, in case of divergence, which keys should prevail in the final profile. For each divergent key, it is possible to choose whether the value to be kept is that of the transaction or that of the database profile. This functionality is especially important in unification cases, where the system allows the operator to compose the unified profile with the most correct or complete data.

Rules to enable the "Confirm treatment" button

The "Confirm treatment" button is only enabled when all mandatory decisions have been made:

• The decision about the relationship between the profiles (unify, keep separate or reject) has been recorded.

• All divergent fields have had a value chosen by the operator (transaction or database).

• A textual justification, explaining the decision taken, has been entered.

Only after meeting these requirements does the system allow concluding the analysis and recording the handling of the nonconformity.

Actions available according to the transaction type

For registration transactions

• Reject: used when there is an attempt at fraud or when the transaction should not be inserted into the database.

• Unify: used when the transaction corresponds to an already existing profile in the database and the data should be consolidated.

• Keep separately: used when the biometric was marked as inconclusive and the operator identified that they are actually different biometrics.

For update transactions

• Reject: used when the data sent for update do not belong to the profile in question, or constitute an attempted fraud.

• Unify: used in cases of inconclusive biometric, when the decision is to consolidate the transaction data into the existing profile.

  

When to use each decision

The choice of action depends on the joint analysis of the biometrics (face and fingerprints) and the biographical data. For example:

• If the biometric confirms that the profiles are of the same person and the biographical data are compatible, the indicated action is unify.

• When biometrics and biographical data diverge, the system recommends keep (in registrations with different keys) or reject (in updates with the same key).

• When there is not enough certainty, especially in cases of inconclusive biometric, one may opt for keep separately (for registration) or unify with reservations (for update), depending on the context.

The decision must always be well-founded based on the evidence presented by the interface.

How to enter justification

Before confirming the treatment, the operator must fill out a justification field, explaining the reasons for the decision. This justification serves as an audit basis and must present, objectively, the elements that support the conclusion taken (e.g., divergence of biographical data, biometric correspondence, evidence of attempted fraud, etc.).

What happens when confirming the treatment

By clicking on "Confirm treatment", the system:

• Updates the nonconformity status to resolved.

• Records the decision and the justification.

• Executes the actions corresponding to the decision:

  • If it is a unification, the transaction data are consolidated into the existing profile.

  • If it is a rejection, the transaction is discarded and recorded as invalid.

  • If it is a keep separately or keep, the profiles remain distinct and are not merged.

In addition, the system may trigger automatic mechanisms, such as reprocessing of previously blocked transactions, if the resolution of the nonconformity allows the continuity of dependent flows.

3.6. Validation by Other Organizations

The validation by other organizations is necessary when there is the presence of multiple organizations responsible for handling and validating profile nonconformities. In scenarios where a profile belongs to another organization there is a need for analysis by a higher instance to confirm the veracity of a transaction. The generated pending item is directed to an organization higher than those involved for a final evaluation. This functionality is configurable and may or may not be enabled in the client environment.

When validation is necessary

Validation by other organizations occurs in the following cases:

• When a nonconformity is detected in a profile that belongs to another organization, the system triggers the need for validation by the other organizations involved.

• When the analysis of a transaction requires external confirmation or review by another organization, especially in situations that involve high-risk decisions or where there are divergences in the biometrics or biographical data.

How the pending item is generated and allocated

The pending validation is automatically generated by the system which, upon identifying that a nonconformity must be verified by another organization, creates a pending item associated with the transaction in question. The allocation of a pending item occurs according to the workflow configured for each organization, and the system will send the pending item to the responsible organization or to the operator who must perform the validation.

• Allocated pending item: As soon as the pending item is created, it is allocated to the operator or organization that must validate it.

What the first operator who handled it sees in the interface

When the first operator handles the nonconformity, they will be able to see in the interface an indication that other organizations need to validate the transaction or nonconformity. The interface offers a pending status, with information about which organization or operator must complete the validation.

• The operator will also be able to see the details of the nonconformity, with the evidence and data associated with the transaction that needs to be validated.

• If the operator does not have permission to finalize the process, they will see the option to forward the pending item to the responsible organization for completion of the validation.

What happens if the pending item is approved or rejected

Depending on the decision made by the organization that received the pending item, the following occurs:

• If the pending item is approved: The system finalizes the process and the transaction is handled according to the previous decisions, such as unification or keep separately. The nonconformity status is updated to resolved, and the database profile is updated according to the approved handling.

• If the pending item is rejected: If the other organization does not validate the transaction, the group will return to the biographical analysis step and will be allocated to a new investigator.

3.7. Process Finalization

The process finalization of handling nonconformities occurs when all analysis and decision steps are completed, resulting in the database update and possible reprocessing of transactions. This process is critical to ensure that the database information is always updated and correct, reflecting all handling decisions made during the analysis.

Automatic database update

After the completion of all nonconformity handling, the system performs the automatic database update. This includes:

• Inclusion or update of profiles: When a nonconformity is resolved, the biographical and biometric data of the affected profiles are updated in the database, according to the decisions made (unification, separate maintenance, rejection, etc.).

• Deletion of transactions: If a transaction has been rejected, it is removed from the database or marked as invalid, according to the organization’s policy.

The automatic update process is carried out without the need for manual intervention, ensuring agility and accuracy in modifications made to the database.

Reprocessing of previously blocked transactions

In some cases, transactions may have initially been blocked due to unresolved nonconformities. After handling these nonconformities and making a decision, the system performs the reprocessing of these blocked transactions.

• Re-evaluation of transactions: Transactions that were blocked may be re-evaluated based on new information or handling decisions made. If the nonconformity has been resolved and the transaction is now considered valid, it will be processed and integrated into the database.

• Impact on blocked transactions: Reprocessing may generate updates to the involved profiles, depending on the decision made during the analysis (for example, profile unification or data separation).

Possibility of generating new nonconformities from the resolution

After resolving a nonconformity, there is the possibility of new nonconformities being generated. This can occur in the following cases:

• Change of profile status: Resolving a nonconformity may lead to new checks of data that, in turn, may generate new nonconformities. For example, when unifying two profiles, additional divergences between biographical or biometric data may arise, resulting in a new nonconformity.

• Reprocessing of previous transactions: As part of reprocessing blocked transactions, new nonconformities may be detected in profiles or transactions that previously showed no evident problems.

• Changes in validation criteria: Database updates and transaction reprocessing can also lead to a re-evaluation of similarity and fusion criteria, which may generate new nonconformities when the system detects additional differences.

This continuous cycle of analysis and handling of nonconformities ensures that the database is always in compliance with quality and security standards.

3.8. Administrator Panel

The Administrator Panel is an interface dedicated to monitoring and managing nonconformities recorded in the system. It allows specific searches, detailed viewing of each nonconformity, as well as prioritization and, in some cases, the direct handling of the issue through the interface.

Nonconformity Search (Transaction Search)

In the panel, it is possible to search for nonconformities using specific keys, such as CPF, RG, voter registration, among others. The search returns a list of nonconformities that match the provided key. By clicking on one of the listed nonconformities, the system displays its details page.

Nonconformity Statuses

Each nonconformity can be in one of the following statuses, according to its stage in the treatment flow:

• Biometric analysis: pending biometric analysis in some group.

• Biographical analysis: all biometric analyses have been completed, and there is a pending biographic analysis.

• Pending approval: the biographic analysis has been performed and is awaiting approval from a higher organization.

• Processing: the nonconformity is being processed by the ABIS, without the need for user action.

• Accepted: the nonconformity has been resolved and the transaction was accepted in the database.

• Rejected: the nonconformity has been resolved and the transaction was rejected.

• Error: an error occurred while processing the nonconformity in the ABIS.

• Blocked: the transaction is linked to a group that has not yet been resolved. It is necessary to handle the related nonconformities for the transaction to be unlocked.

• Resubmitted for processing: the nonconformities that were blocking the transaction have been resolved, and it was resubmitted to the ABIS with a new transaction identifier.

Nonconformity Details

In the details page of a nonconformity, the system presents:

• The current status and its description.

• The profiles involved in the group.

• The available actions which vary according to the status.

From Trust version 1.1, it is possible to forward profiles that are in biometric analysis to biographic analysis through the “Nonconformity Details” screen. Then the nonconformity can be handled. In these cases, the system assigns the result of the biometric analysis as INCONCLUSIVE.

Blocked Nonconformities

For nonconformities in the statuses Blocked or Resubmitted for processing, the interface does not directly display the conflicting profiles. Instead, the nonconformities that are blocking the transactionare listed, and the operator can access them by clicking on each item.

When prioritizing a blocked transaction, the system also automatically prioritizes all related nonconformities that are blocking the transaction, ensuring they receive faster handling.

This functionality allows for more efficient action by the administrative team, ensuring agility in resolving critical cases and greater control over the nonconformity handling flow.

3.9. Reports

Check availability in the deployed environment.

Trust also offers a tool for visualizing charts and metrics about the environment's transaction and nonconformity history. These data enable the extraction of insights about nonconformity handling, helping supervisors and coordinators to improve the operation of Trust users.

Currently, the system provides two report categories:

• Transactions

• Nonconformities

Each category has dashboard tabs that present specific metrics and charts.

In the Transactionscategory, there is a single dashboard tab:

• General

In the Nonconformitiescategory, the following dashboard tabs are available:

• General

• Biometric Analysis

• Biometric Analysis - Comparison by user:

• Biographical Analysis

• Biographic Analysis - Comparison by user

Applying filters

All dashboards have a series of filters that directly impact the data used in metric calculations and visualization generation.

The available filters may vary between dashboards, but some examples are:

• Period: defines the date range considered in the data.

• Source label: corresponds to the label of the transaction in the GBDS.

• Origin city: corresponds to the origin city of the transaction in the GBDS.

• Transaction type: indicates the type of operation in the GBDS (registration or update).

• Biometry type: specifies the biometric modality of the data (face or fingerprint).

• User: corresponds to the user associated with the filtered data.

Metric tooltips

The metrics and charts display tooltips when hovering the mouse over elements of the dashboard. These tooltips can provide descriptions of the metrics or detail values and specific information presented in the chart.

4. Common Use Cases

This section presents real or simulated examples of using the Trust tool. The examples help consolidate understanding of the system and guide users' decisions.

Profiles with the same biometrics and different names: what to do?

The system may identify a nonconformity between two profiles with biometrics considered identical, but divergent biographic data, such as differences in the name. This is the typical case of a name change after marriage.

The analyst used Trust to:

• Verify biometric correspondence through the comparison modal;

• Assess biographic divergences directly on the analysis screen;

• Check the transaction history of each profile in Intelligence.

Manual analysis identified that the only change was from the maiden name to the married name. Based on the evidence, the decision was to reject the reference profile and accept the incoming profile.

A profile with identical biometrics but divergent biographic data: what to prioritize?

In biographic analyses of registration with identical biometrics, Trust allows comparing biographic data between the profiles in the group. When there are divergences, the analyst must choose, field by field, which information will compose the resulting profile.

This process occurs after selecting a base action (such as "merge"), and before confirming the handling. Trust displays divergent biographics side by side, and the analyst selects the correct information based on the available data and the transaction history accessible via Intelligence.

Note: The field selection functionality depends on proper integration with the system where the biographic data is stored. If it is not possible to update the biographic data, the field selection will be disabled.

Suspected fraud

Trust was designed to handle suspected fraud cases. One example involves an individual attempting to obtain a new document with different biographic information. The system detected the biometric match and generated the nonconformity for analysis.

Based on the evidence, such as transaction history and the origin of the registrations, the analyst can reject the suspicious profile, justifying their decision on the confirmation screen. If the group is blocking any transaction, it will be reprocessed automatically after the handling is finalized.

5. FAQ

This section gathers frequently asked questions. The goal is to help the user make safer decisions, avoid common mistakes, and understand the impact of their actions on the system.

1) What happens if I reject the wrong profile?

When rejecting a transaction or marking a profile as invalid, the system records that decision and may permanently block that record. If it is an incorrect rejection, the consequence may be the loss of legitimate data or the need for intervention by another agency with higher permission.

Before rejecting, carefully check all available biographic data, histories, and biometrics. When in doubt, use the pending review feature for another responsible party to review.

2) Can I undo a decision?

No. Once the decision is recorded and confirmed, it cannot be undone directly by the user. This ensures traceability and security of actions.

However, depending on the organization's flow, an impacted profile may be handled again within the pending analysis process.

3) How to interpret an inconclusive match?

A match is considered inconclusive when the biometric score is in an intermediate zone, that is, neither high enough to confidently state that the profiles belong to the same person, nor low enough to discard a relation.

In these cases:

• Check whether the image (facial or fingerprint) has sufficient quality.

• Analyze the biographic data in parallel.

• Use the zoom and side-by-side comparison features in the modal.

• If uncertainty persists, document the doubt in the justification and opt to reject the incoming profile. This way undue updates are avoided and it allows biometrics to be recollected, eventually resulting in a more assertive match.

4) How to deal with profiles that seem legitimate but do not match?

These cases are common and may involve legitimate variations or attempts at fraud. Carefully analyze the profiles' history, biometrics, and main data. If there is clear evidence that it is the same person, merge the records with the correct data.

5) What are the best practices to investigate and document a decision?

Always evaluate the set of information: biographic data, history and biometrics. Pay special attention to divergent fields, such as name, documents and date of birth. Use filters to understand the context of the transaction and, if necessary, involve other organizations via pending review. When recording the decision, be clear and objective in the justification — this helps traceability and future audits. Prioritize accuracy, even in seemingly simple cases.