Trust
1. Tool Overview
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. The 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 the authenticity and uniqueness of each customer or account holder 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 attempting to register with different documents and names;
Coincident biometrics associated with conflicting biographical data;
Incorrect registry updates, that 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 duplicates and fraud.
Transparency and traceability: all actions are recorded, allowing audits and ensuring confidence in decisions.
Operational agility: intuitive interface, with well-defined flows that facilitate analysts' work.
Security in decisions: offers detailed comparisons between biometric and biographical data, supporting technical and well-founded decisions.
Integration with other tools: connects with 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 the operation of Trust. They help to 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 must be replaced by (update) transactions, when two people share the same key (same CPF number, for example) but present distinct biometrics. This suggests possible inconsistency or identity swap.
3. Inconclusive Biometrics They can occur both in enroll and in must be replaced by, 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 an 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 attempt at fraud.
Types of nonconformity
These conflicts prevent the system from automatically approving the data entry. Therefore, the nonconformity needs to 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 pending biometric analysis in the group (e.g., fingerprints or face of the transaction match those of another profile).
Biographic: When there is 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 that tries 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 complete case before deciding what should happen in the database.
2.4 Transaction
In the context of Trust, a transaction is an 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 sent for an individual who was already registered in the database.
2.5 Transactions Waiting for 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 block, these transactions are automatically reprocessed. At that time, 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 the pairs of biometrics (face and fingerprints) between the transaction and the profile under analysis. Each pair is presented with a colored border, which 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 Treatment Confirmation
Choice made at the end of the analysis of a group, defining what will happen to the profiles and to the incoming transaction. The main decisions are:
Reject transaction
Unify profiles
Keep the profiles as distinct
2.8 Hierarchy and Permissions
Users have different levels of permission 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 adequate 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 existing in the database with a different key. This inconsistency may indicate a registration error, a duplicate, or even an attempt at fraud. Biometric conflicts are among the main reasons 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 taken 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 treatment 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 are in an inconclusive zone (neither with a very high nor very low score). In this case, experts compare fingerprints or facial images to determine whether they belong to the same person. The analysis is carried out independently by more than one expert and requires consensus to proceed with the treatment. The possible decisions are: compatible biometric, incompatible, or inconclusive.
3. Operational Flow
This section describes step by step the operation of the Trust tool, reflecting the real workflow of users in the analysis and treatment 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 provides access to the analyses available to a user. The information displayed 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 take you to the next available analysis. The choice of the analysis to be performed 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. The verification is done through algorithms that evaluate the consistency between the received data and the 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 logic for detecting nonconformities 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 source profile data. If there is inconsistency (for example, the submitted biometric 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. In case of doubt or uncertainty, the system does not make the decision automatically; the analysis is forwarded to human operators, supported by 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 a profile's biometric (for example, the face), but the new biometric does not match the reference profile with the same keys.
These situations prevent the automatic entry of the transaction and trigger manual analysis flows by specialists.
3.1.3 Possible analysis flows from the nonconformity
After detection of the nonconformity, the system can forward 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 a problem with the fingerprints.
Fingerprint analysis only: if the conflict is exclusively with 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, biographical analysis is not enabled due to 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 detection of a nonconformity, the corresponding group is forwarded for analysis by enabled operators. The system organizes and makes these analyses available through a specific interface, which allows controlled and ordered access to pending nonconformities for treatment.
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 group's current status. There is an administrator panel that allows configuring priority rules for certain groups or types of transactions.
Analyses can be allocated in two ways:
Automatic distribution: the system directly delivers an available analysis 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 want 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 order of priority, 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 that are already assigned to them, that is, those in which they started the biographical analysis but have not yet completed the treatment. 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 stage involves checking the similarity between facial and fingerprint records detected by the system as possible matches. The analyses are separated into two distinct interfaces: face analysis In summary, services run by APISIX can be accessed on the following default ports: 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 button Face analysis on the Trust home screen the system automatically selects the first case in the queue and opens a comparison modal, which displays side by side the facial images of the two profiles being compared, without indicating which profile they belong to.
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 through 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 subsequent stages of the flow.
Once the decision is indicated, the case will be finalized 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 is eventually open without a decision will return to the analysis queue to be forwarded 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 button Analysis fingerprints on the home screen, the system automatically selects the first case in the queue and opens a comparison modal, which displays side by side the fingerprint images of the two profiles being compared, without indicating which profile they belong to.
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 through 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 subsequent stages of the flow.
Once the decision is indicated, the case will be finalized 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 is eventually open without a decision will return to the analysis queue to be forwarded 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.
Biometric quality: 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 a few fingers may be sufficient or not, depending on quality and score.
It is important to emphasize that not always all 10 fingers will be available for analysis in Trust. The system only sends for manual verification the fingerprint pairs whose automatic comparison was not conclusive. In other words, 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 the need for manual review. Therefore, the operator may view only some pairs, such as 6 or 7 fingers, depending on biometric quality 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 state with confidence whether the fingerprints are from the same person or not.
3.4. Biographical Analysis
After the biometric analysis stage (facial and/or fingerprints), the system may forward the profile to the biographical analysis stage depending on the characteristics of the nonconformity. Biographical analysis is performed based on the comparison between the biographical data of the transaction (registration or update) and the data of the profile in the database 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 aims to highlight convergences and divergences in the data, such as name, date of birth, parentage, among others.
Handling the nonconformity
In Biographical Analysis the transaction type 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:
Base 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.
For profiles with inconclusive biometrics, the available actions are:
Base 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: equal biometrics
Red: different 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.
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
Comment field with the justification for the decisions
If there are transactions in the waiting queue for the group under analysis, they are displayed in the Blocked Transactions section. After treatment, if there are no more blocking groups, 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
Merge
For update transactions:
Reject
Merge (when the biometrics are coincident)
Keep separately (when the biometric is inconclusive)
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 from the transaction or from 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 button "Confirm treatment" is only enabled when all mandatory decisions have been made:
The decision about the relationship between profiles (unify, keep separate or reject) has been recorded.
All divergent fields 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 registering the treatment 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.
Merge: used when the transaction corresponds to a profile already existing 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 attempt at fraud.
Merge: 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 grounded based on the evidence presented by the interface.
How to insert justification
Before confirming the treatment, the operator must fill in 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 match, 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 .json keep, the profiles remain distinct and are not merged.
In addition, the system may trigger automatic mechanisms, such as the reprocessing of previously blocked transactions, if the resolution of the nonconformity allows the continuity of dependent flows.
3.6. Validation by Other Organizations
Error in the Federal Revenue 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 the ones involved for a final evaluation. This feature is configurable and may or may not be enabled in the client's 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 .json review by another organization, especially in situations that involve high-risk decisions or in which there are divergences in the biometrics or the biographical data.
How the pending item is generated and allocated
Error in the Federal Revenue pending item of validation is generated automatically 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 may 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 can also 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 taken 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 .json separate maintenance. The nonconformity status is updated to resolved, and the database profile is updated according to the approved treatment.
If the pending item is rejected: If the other organization does not validate the transaction, the group will return to the biographical analysis stage and will be allocated to a new investigator.
3.7. Process Completion
Error in the Federal Revenue process completion of nonconformity handling occurs when all analysis and decision steps are concluded, resulting in the database update and the possible reprocessing of transactions. This process is critical to ensure that the database information is always up to date and correct, reflecting all treatment decisions made during the analysis.
Automatic database update
After the completion of all nonconformity treatments, 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 deleted 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 the changes made to the database.
Reprocessing of previously blocked transactions
In some cases, transactions may have initially been blocked due to unresolved nonconformities. After the treatment of these nonconformities and the decision making, the system performs the reprocessing of these blocked transactions.
Reevaluation of transactions: Transactions that were blocked may be re-evaluated based on the new information or treatment decisions taken. If the nonconformity was resolved and the transaction is now considered valid, it will be processed and integrated into the database.
Impact on blocked transactions: The reprocessing may result in updating 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: The resolution of a nonconformity may lead to new data checks that, in turn, may generate new nonconformities. For example, when unifying two profiles, additional divergences may arise between biographical or biometric data, resulting in a new nonconformity.
Reprocessing of previous transactions: As part of the reprocessing of blocked transactions, new nonconformities may be detected in profiles or transactions that previously did not show obvious problems.
Changes in validation criteria: The database update and the reprocessing of transactions can also lead to a reassessment 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 the nonconformities registered in the system. It allows performing specific searches, detailed visualization of each nonconformity, as well as prioritization and, in some cases, the treatment itself directly through the interface.
Nonconformity Search (Transaction search)
In the panel, it is possible to search for nonconformities using specific keys, such as CPF, ID, voter registration, among others. The search returns a list of nonconformities that match the informed 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 status, 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 pending biographical analysis.
Pending approval: the biographical analysis has been performed and awaits approval from a superior organization.
In processing: the nonconformity is being processed by the ABIS, without user action required.
Accepted: the nonconformity has been resolved and the transaction was accepted in the database.
The Reset Fragment option will discard all modifications made to the fragment and return it to the state as it was extracted from the evidence.: 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 address the related nonconformities so the transaction can be unblocked.
Resent for processing: the nonconformities that were blocking the transaction have been resolved, and it was resent to the ABIS with a new transaction identifier.
Nonconformity Details
In details page of a nonconformity, the system shows:
The current status and its description.
The profiles involved in the group.
The available actions which vary according to the status.
Blocked Nonconformities
For nonconformities in the statuses Blocked .json Resent 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 feature enables more efficient action by the administrative team, ensuring agility in resolving critical cases and greater control over the nonconformity handling workflow.
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 the biometric match using the comparison modal;
Evaluate the 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 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 registrations with identical biometrics, Trust allows comparing the 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 "unify"), and before confirming the treatment. Trust displays the 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. An example involves an individual attempting to obtain a new document with different biographic information. The system detected the biometric coincidence 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 treatment is finalized.
5.FAQ
This section gathers frequently asked questions. The aim 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 this decision and may permanently block that record. If it was an incorrect rejection, the consequence may be the loss of legitimate data or the need for intervention by another body with higher permission.
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 in actions.
However, depending on the organization's flow, an impacted profile may be treated 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 safely assert that the profiles are of 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 you avoid an improper update and allow the biometrics to be collected again, possibly 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 fraud attempts. Carefully analyze the profiles' history, the biometrics and the main data. If there is clear evidence that it is the same person, unify 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 a pending item. When recording the decision, be clear and objective in the justification — this helps with traceability and future audits. Prioritize accuracy, even in seemingly simple cases.
Last updated
Was this helpful?