User Guide

Terminology

Technical terms that could be difficult to understand or confusing for users and readers will appear along the guide in italics and followed by asterisk, like this*, and its meaning is described in the following table:

Term	Description
UI	User Interface: It is the means by which the user and a computer system interact, in particular the use of input devices and software like an application or a website.
API	Application Programming Interface: Software intermediary that allows the communication between two applications, delivers a request to the provider and then delivers the response back.
OCR	Optical Character Recognition: It is a technology that recognizes text within a digital image. It is commonly used to recognize text in scanned documents and images.
SDK	Software Development Kit: Set of software development tools that allows the creation of applications.
NFC	Near Field Communication: Is a method of wireless data transfer that allows devices to share data when in close proximity.
SA	Selfie Alive The SDK or verification process named Selfie Alive uses selfie photos of the user, to determine if is alive or not, or the confidence regarding its liveness. This process also allows to detect if the person is there during the process or if it is an impersonation attempt
SAP	Selfie Alive Pro The SDK or verification process named Selfie Alive Pro uses a video in which the person is requested to do certain random head movements in order to detect liveness and determine if the person is alive. It also allows to detect if a real person is there during the process or if it is an impersonation attempt. Also it is able to detect photo prints, photo replays, video replays, deepfakes and 3D masks.

Introduction

boi-Das is a Case-Management tool developed and offered by Veridas for the review of the validation processes by back-office teams.

This back-office service eases and speeds up the process of reviewing the results obtained and the data provided by the user on the validation process carried out by the Veridas identity verification service on the Veridas cloud platform.

boi-Das offers its functionalities as an UI* and an API*. Both the UI and the API allow to take decisions and actions regarding the validity of the ID document and biometrics data and results obtained on the validation processes, such as modify their status to accepted or rejected and edit the personal data obtained by using OCR* techniques.

Common Use Cases

There are different types of validation processes an agent can meet because a verification or validation process can be articulated in different forms or workflows depending on the user preferences and the security analyses required.

The stages which can conform a validation process basically depend on the evidences (photos, videos) captured by the person who did the capture process. This stages can be one or more of the following analysis processes:

• Document Verification (DOC): Analyzes the photo or photos of the identification document (front, front and back, or front, front with flash and back) captured by the user. These images of the document are analyzed in order to verify its authenticity and its security measures.
• Selfie Alive Verification (SA*): Consists on a biometric analysis of a user selfie image and gathers liveness evidence of the user performing the process.
• Selfie Alive Pro Verification (SAP*): Consists on a biometric anaysis of a user selfie image and a short video recorded by the user which is requested to perform certain random head movements.
• Video Selfie Capture (VIDEO): Analyses a user selfie video recorded by guiding it through three steps:
  • Showing the face to the camera.
  • Showing the obverse of the document.
  • Showing the reverse of the document (optional).
• NFC Capture (NFC*): Verifies the information contained in the user document chip by using NFC.

These processes always take the Document analysis step and can also take NFC, SA or SAP and Video in the following combinations:

DOC (+ NFC)	SELFIE	SA	SAP	VIDEO
X
X	X			X
X		X
X			X
X			X	X

Most common workflows

Document analysis.

The main and required stage for all the validations processes is the document analysis, which is realized in any of the possible workflows that can be executed, either combined with additional verification steps or only itself.

• DOC (+ NFC)

  When it is only required to obtain and analyze the information contained in the identity document. This requires taking a photo of the front of the document and optionally a photo of the back and also the front using the camera flash, which, if sent, strengthens the process of extracting personal data and verifying security measures.

Additionally, the NFC chip of some documents can be read in an additional verification step in the document validation process and used in the identity verification process. This option is only available for some documents.

The results of this process consist of the document verification scores, together with the personal data extracted from the document, and the images used for the analysis. All of this can be seen in the detail view of boi-Das.

Face biometry analysis.

The biometry analysis is an optional step and comprises two processes, selfie photo verification and selfie video verification. Both of them can be done isolated (just the selfie photo analysis or just the video selfie analysis) or together, by sending the selfie photo and after that the video selfie, which generates additional similarity values.

• DOC (+ NFC) + Selfie + Video

  When a Selfie image is uploaded along with the document, it is compared with the face photo on the ID the document, or with the one retrieved from the NFC chip (if this has been previously sent). If the selfie anti-spoofing feature is available, another verification can be ordered to be done, corresponding to the selfie photo spoofing detection. This way, a new score is generated which indicates the degree of similarity between the Selfie image and the ID document face photo. In the case of being uploaded the NFC chip information, the photo contained in it is also compared with the face photo on the ID document and the Selfie image, getting these two comparitions' scores instead.

  There is another option which is the Video selfie, which consists on uploading a video of the user following three steps: Show his face to the camera, show the document obverse and show the document reverse. This option generates a score indicating the similarity between the face photo image on the document (and the one contained in the NFC chip information if it is uploaded) and the user's face that appears on the video. Also a proof of life is done on the video which is used to look for liveness evidence.

  When both the Selfie and the Video selfie are uploaded, Veridas services generate the two scores determining the similarity between the face photo of the document (or the NFC chip) and the Selfie image and between the Selfie image and the user's face shown in the Video selfie.

Liveness Detection analysis.

Veridas offers two services of advanced liveness detection techniques: Selfie Alive and Selfie Alive Pro.

• DOC (+ NFC) + Selfie Alive

  Selfie Alive consists on a biometric analysis of a user Selfie images and gathers liveness evidence of the user.

  This comprobation generates a new score which indicates the confidence of the person in the photos to be alive. It also returns the score of the comparison between the Selfie image and the ID document photo (and the NFC photo if available).

• DOC (+ NFC) + Selfie Alive Pro

  To strengthen the validation process, Veridas also offers a proof-of-life check to determine if the user is a living person and is in front of the camera at that precise moment. For this, a stage called "Selfie Alive Pro" or SAP_ is carried out. The user is asked for a selfie and a video in which it has to move its head according to random indications that are different in each process.

Once this flow is carried out, facial biometric scores that contain information about the similarity between the selfie and the photo of the identity document are generated, which offer information about whether the person in the video is alive and present at the time of the test or if on the contrary, it is an impersonation attemp, or the person does not look alive.

• DOC (+ NFC) + Selfie Alive Pro + Video

  A process with Selfie Alive Pro can also include the Video stage, where the user must show his face and the obverse and reverse of his document.

  In addition to the Liveness detection score, which is strengthened with the video, this process generates an score for the biometry comparison between the Selfie image and the face in the Video selfie.

Using boi-Das

Login

Every user must log into the web console to use the UI service. Each user belongs to one of the four available groups of users which are considered as "roles": administrator, supervisor, operator or agent. Each role or group of users has different authorization permissions.

Single Sign-On

The "Login with Microsoft" button lets the user to do a single sign-on with his Microsoft account.

Multi-factor Authentication

boi-Das implements the possibility to enable a "second-factor" authentication functionality that provides more security against the bad usage of the service.

This functionality uses Google Authenticator app as a second factor.

Multi factor authentication, will be either enabled system-wide for all the users, or disabled at all.

A new input box will be added to the boi-Das login screen if MFA is enabled to introduce the OTP (one time password). This new input box will be shown after the initial username and password boxes, and only if those are correct.

First-time login

The first time a user logs in, they will need to initialize their Google Authenticator app so that boi-Das' OTP codes are computed and displayed.

To do this initialization, a QR code will be generated and shown on the screen. The user will need to scan this QR code with the Google Authenticator app and introduce in the text box below, one of the OTP codes which start being generated on the app. Since then, the app will display OTP codes for boi-Das which will be required for accessing the UI.

The QR code will only be shown the first time a user logs into boi-Das. Subsequent login attempts will only show the OTP input box.

Password reset

If you have forgotten your password, you can reset it by clicking on "Forgot password?" link. You are then required to enter your registered email address and once entered, "Reset my password" link must be clicked to proceed with the password recovery process. Then, an email notification will be sent to you with the instructions to modify the password.

Password policy

boi-Das enforce to comply with a password generation policy so the passwords associated with a user must comply with it.

This policy includes the following validation aspects as basis:

• Checks the similarity between the password and a set of attributes of the user.
• Checks whether the password meets a minimum length of eight characters.
• Checks whether the password occurs in a list of common passwords. It compares to an included list of 20,000 common passwords.
• Checks whether the password isn’t entirely numeric.

Other validation aspects can be included by configuration as it is explained in the onpremise instructions password policy. This validation aspects are the following ones:

• Checks whether the password contains the configured number of lower case characters
• Checks whether the password contains the configured number of upper case characters
• Checks whether the password contains the configured number of special characters
• Checks whether the password was already used in the last configured number of password changes.
• Checks the password is not changed in the configured time period after last change.
• Checks whether the password is expired. It must be configured the number of days the password is active.

Also, boi-Das implements a max retries check on the login. If a user tries to login a max number of times with a wrong password, his account gets blocked for a specified time.

Home Dashboard

Once a user logs in to the boi-Das UI, the dashboard that will be displayed, depends on the role of the user, because each one has different capabilities and has access to different functionalities.

• Administrator role: Access to a validations extended list view with exporting and deleting actions available. Access to the detailed visualization of a selected validation and to the application settings dashboard.

• Supervisor role: Access to a validations extended list view with exporting and deleting actions available and to the detailed visualization of a selected validation.

• Operator role : Access to a validations extended list view with exporting action available and to the detailed visualization of a selected validation.

• Agent role: Limited access to the system functionalities. Usually it will wait for new validation processes which arrive to boi-Das in a state that indicates that are waiting to be reviewed by an agent. Can not choose which validation to see.

Agent Dashboard

The agent remains waiting for new validations to come to be reviewed. It just can review the validations and log out the service.

When an agent is logged and there are no validations waiting to be attended, the following screen is displayed:

Once a validation arrives, the agent's UI automatically displays the Detailed validation Dashboard, as agents don't have access to a list of validations.

• When the validation detail view is shown, the agent have to review it and decide if this validation should be accepted, rejected or marked as inconclusive. A validation process should be marked as inconclusive when the agent has doubts about the correctness or veracity of the process, and prefers to indicate that it have to be reviewed by a supervisor.

Onboarding list Dashboard

The Onboarding list dashboard consists on a list where all the validation processes which boi-Das downloads and stores are displayed. Also, the main scores and data are shown in this list. This dashboard is available to the users with administrator, supervisor or operator role.

The administrator, supervisor and operator can do the same actions as an agent by accessing the different validations that are displayed in the lists.

Header Dashboard

The image above shows the top header bar from the Home Dashboard. Each of the elements of the bar allows to do the following specific actions:

1. Go to Home Dashboard
2. Check the boi-Das version

3. Filtering options to study a specific set of validation processes

   When this button is clicked a new dashboard is displayed consisting of:

   • Filter options: A dropdown menu which lets the user select the field to use to filter the validations search. Those options are: document number, client name, client last name, document type, contextual data or a generic search on every validation field.
   • Key word: The text which will be searched. There is an option to search by empty fields by writting null as key word and selecting the corresponding field, this way will show the validations which have the selected field empty. In the case of searching for contextual data, the structure of the keyword must be "key:value".
   • Search button: Proceed to search the validations which comply with the filtering options.

   • Close button: Close filtering options.

     
     

4. User guide button: Redirects to Boi-Das user guide.

5. Language dropdown: Shows the language which is currently being used and allows to easily switch to another one. There are three languages available: English, Spanish and Catalan

6. Dropdown menu with additional options.

   The dropdown shows the username of the logged user.

   When the dropdown menu is clicked, depending on the user roles, it displays different options.

   If the user is suprevisor it will display the following options:

   

   In the case the user has the administrator role, the dropdown menu will show the following options:

   
   • The settings option will open the appilcation settings dashboard.
   • The exit option will do the session log out

VeriSaaS connection status

Below the dashboard header there is a section containing the VeriSaaS service status connection and the validations download polling information:

VeriSaaS connection status: Indicates the VeriSaaS service connection status. Status can be one of the following:

- Available: VeriSaaS service connection is working properly.

- No available: VeriSaaS service is not reachable.

- Unknown: The connection status is unknown.

Validations download polling information: Indicates the interval between the validation requests to VeriSaaS. If the VeriSaaS connection is not available or unknown, the polling information will not be shown.

Top bar Dashboard

The administrator, supervisor and operator have access to all the validations independently of its status. The top bar allows to access to each of the validation groups in which the validations are grouped by its status:

1. List of the validations that are waiting to be reviewed. These validations need to be checked to decide if they should be accepted,rejected or marked as inconclusive.

   

2. List of the validations that were reviewed by an agent without taking a decision about whether to approve or reject the validation, so a doubtful state is selected, which implies that this validation process has to be reviewed again, this time by a supervisor, to take a decision.

   

3. List of validations that have been reviewed and approved, the results satisfy all the user criteria for a satisfactory process and the system nor the reviewer agent has detected any fraud or forgery intent.

   

4. List of validations that have been reviewed and rejected, so it is understood that the obtained results do not satisfy the criteria for a process to be approved.

   

Validations

The main dashboard validations list which an administrator, supervisor and operator user encounters when logs in boi-Das, shows a list of certain information of the validation processes which consist on the following data presented in the form of table columns:

• Date and time: Corresponds to the moment when the validation process was initiated. The list of validations is ordered by creation date, displaying either the newest first or the oldest first, and the order mode can be toggled using the button with the arrow icons.
• Validation ID: A unique identifier for each specific validation process.
• Document Number: The document identification number field extracted from the ID document in the document analysis process.
• Name and last names: Of the owner of the ID document obtained in the document analysis process.
• Document type: In the form IC_DocumentType_YYYY, indicates:
  • IC: Country issuance of the document.
  • DocumentType: the type of the document, which can be IDCard, Passport, DrivingLicense, ResidencePermit...
  • YYYY: Year of issuance.
• Main scores results:
  • Document validation: A summary score of the document authenticity and validity.
  • Selfie vs ID photo biometric: Result of the comparison between Selfie and the document photo of the ID document.
  • Selfie vs client biometric video: Result of the comparison between the Selfie and the video uploaded by the client.
• Proof of life verification: Score that indicates the confidence of the detection of liveness in the proof of live process.

Export and deletion of validations

In addition, there is an option to export or delete the validation processes. To do this, a supervisor or an administrator have to select the validations which want to be deleted or exported and click on the top corresponding button which appears when the validations are selected. In case of the users with operator role, they will only be able to export the validation processes, not delete them.

The export of a validation process can be done in two ways:

• To a PDF document containing all the details of a given validation. The PDF file obtained is a render of what can be seen in the validation detail view when a validation is reviewed, with the same format, including the images and a frame of the videos. This feature is just available if the boi-Das service has been configured to do so at deploy time. This PDF export can be configured by means of an environment variable, which activates the corresponding button when a validation is selected in the list.
• To a ZIP file containing:
  • A JSON file with the validation text data.
  • A JSON file with the activity registry.
  • A folder with the media data used in the validation process (document and selfie images, videos, video annotations, etc..), the timestamp files in case this process has been done and also the validation PDF file.

Contextual Filters

All the users can have a filter applied to the validations they have access to. These filters limit the validations to the ones that satisfy a specific value for a contextual data.

While agents can't notice this and simply receive the corresponding validations, supervisors, operators and administrators can see a "Filtered view" text on the left of the Language selection button in the Header Dashboard.

By clicking on this text, a pop-up appears that shows the configured filters for that user's view.

These filters are an option to segregate validations by user so each user can only access validations that have specific information, allowing to distribute batches of validations to certain agents. This contextual data filters can be configured via API. More information about contextual data filters configuration can be found in Contextual data filter API documentation.

Settings Dashboard

The settings dashboard allows advanced configurations in the application behaviour. The settings dashboard is only available to the users with administrator role.

To access the settings dashboard the user must click in the settings button in the dropdown menu of the header dashboard.

Currently, the settings dashboard gives access to the sepblac questions, the contextual data filters and reject reasons editors.

Top Dashboard

The settings top dashboard allows the navigation in the different settings dashboard sections by clicking in the section name.

Sepblac questions editor

The sepblac questions editor allows the visualization, addition and elimination of the active sepblac questions. The questions are separated between the document questions and the biometric questions. Each question row has an actions section with a button that allows to delete the question from the application.

By clicking in the Add button of any question section the view will display a pop-up to introduce a new question to the system. The new question will be added when the administrator clicks in the Save button. If the administrator wants to cancel the question addition, the user must click in the Cancel button.

Contextual data filter editor

The contextual data filter editor allows the visualization, addition, edition and elimination of the validations contextual data filters. The contextual data filter is composed by the filter key, the filter value, the filter condition, the filter comparison and the users affected by the filter.

The filter condition concatenates several contextual data filters together. Depending on the filter condition the contextual data filter will behave in different ways:

• If the filter condition is AND then all the key-values added in the contextual data filter must appear in the onboarding.
• In case the filter condition is an OR condition, the onboarding contextual data must have at least one of the key-values appearing in the filter to pass it.

The filter comparison will change the behaviour of the filter depending on the comparison selected. The comparison can be:

• If the filter comparison is EQUAL, then the onboardings which contain the key-value will pass the filter.
• If the filter comparison is NOT EQUAL, then the onboardings which have the key but different values to the one specified will pass the filter, and consequently shown on the onboarding list.

The filter can be deleted by clicking on the delete button that appears in the filter row.

To edit the filter, the administrator must click in the edit button that appears in the filter row. This will show a pop up with the filter elements. The administrator will only be able to change the filter value and users.

By clicking in the add button the application will show a pop up where the user will be able to create a new contextual data filter. The administrator must fill all the fields to create the filter and click in the save button. If the user wants to cancel this operation should click in the Cancel button.

Reject reasons editor

Boidas main purpose is reviewing validations and deciding its state. Validation rejection needs an explanation that is introduced by comment. The reject reasons are an alternative way to reject validations, giving predefined reasons to the agents.

The reject reason editor has two sections:

At the top of the editor we can find the "other option" section. This section contains a checkbox that allows you to activate or deactivate the "other" reason. If the "other" reason is activated, the user can introduce a custom reason during the onboarding rejection.

In case no custom reject reasons are introduced the "other" reason checkbox will be disabled and the user will not be able to introduce a custom reason during rejection.

The reject reasons editor allows the visualization, addition and elimination of custom reject reasons. Each reject reason row has an action section with a button that allows the deletion of the reject reason from the application.

By clicking the "Add" button a pop-up will be displayed to introduce a new reject reason to the system. The new reject reason will be added when the administrator introduces the reject reason and clicks on the "Save" button. If the administrator wants to cancel the reject reason addition, the user must click on the "Cancel "button.

Reject reasons editor

Boidas main purpose is reviewing validations and deciding its state. Validation rejection needs an explanation that is introduced by comment. The reject reasons are an alternative way to reject validations, giving predefined reasons to the agents.

The reject reason editor has two sections:

At the top of the editor we can find the "other option" section. This section contains a checkbox that allows you to activate or deactivate the "other" reason. If the "other" reason is activated, the user can introduce a custom reason during the onboarding rejection.

In case no custom reject reasons are introduced the "other" reason checkbox will be disabled and the user will not be able to introduce a custom reason during rejection.

The reject reasons editor allows the visualization, addition and elimination of custom reject reasons. Each reject reason row has an action section with a button that allows the deletion of the reject reason from the application.

By clicking the "Add" button a pop-up will be displayed to introduce a new reject reason to the system. The new reject reason will be added when the administrator introduces the reject reason and clicks on the "Save" button. If the administrator wants to cancel the reject reason addition, the user must click on the "Cancel "button.

Detailed validation Dashboard

By clicking on any of the Home Dashboard validation list entries, the user gets access to the details of that specific validation process record. This details include:

• Personal data extracted from the document using OCR techniques.
• Document images
• The list of the document security validation scores.
• Biometric data like the selfie and face images and video and also the list of biometric validation security scores.
• Contextual data of the device used to capture information (if provided on the validation process) as well as other useful information of the validation process like the data of the timestamping process, just in case it was done
• Comments left by the users related to the validation.
• A log of the activity and actions performed by the users who have reviewed the validation process.

Validation top bar

The image above shows the top header displayed on the validations Detail Dashboard and its parts.

1. Go to Home Dashboard
2. Current position of the Validation in relation to the list of validations available
3. Go to previous validation of the list of validations available to be reviewed
4. Go to next validation into of list of validations available to be reviewed
5. Close validation detail screen and go to Home Dashboard

Main Header

There is a common main header into details view, which is always visible independently of the active tab and the scrolling.

This main header is divided into three blocks (columns):

1. Summary of the validation: Validation ID, name, document number, date and document type.

2. Validation result and main scores:

   • Document validation: Summary of the document authenticity and validity, which takes into account all the document validation scores to inform about the degree of success in the verification process.
   • Face biometry comparison: Result of the main score for Selfie vs ID documuent face image similarity analysis which compares them and offers a score that indicates the probability for both faces of belonging to the same person.
   • Liveness detection: Indicates whether the validation process detected evidences of life succesfully or not.
   • Injection Attack Detection: This score provides a guarantee that the images have not been altered or manipulated in their travel from the capturing process to the Veridas identity verification service in the Cloud. Indicates if the integrity of the entire validation process has been satisfied or not.

   According to this results and the customer acceptance criteria, the system provides an automatic validation result on if the validation should be accepted or rejected. The recommended thresholds for the automatic acceptation and rejection of the validations are the ones in the ranges that are shown in the table below.

   Main scores	Valid (Green)	Inconclusive (Yellow)	Rejected (Red)
   Document validation	> 0.70	0.50 <= score <= 0.70	< 0.50
   Selfie vs ID photo	> 0.70	0.50 <= score <= 0.70	< 0.50
   Video vs Selfie	> 0.70	0.50 <= score <= 0.70	< 0.50
   Liveness detection	> 0.70	0.50 <= score <= 0.70	< 0.50
   Injection Attack	1	n/a (doesn't appear)	0

   Depending on the different verification processes carried out during the validation processes, some scores may not have been generated. In these cases, those scores will simply not be taken into account in the automatic validation result.

3. Available validation actions: Approve, Reject, Inconclusive.

   The agent must take into account the results described before to definitely accept or reject the validation, or he can also set it as inconclusive. In the case of a validation being set as inconclusive by the automatic system, the agent must carefully review the images and scores provided to take a decision.

   In the case of "Reject reasons" being configured by the administrator in the Settings dashboard, after clicking the reject button a popup will be shown and the agent must select one of them in order to reject the validation.

   

   If "Other reason" is marked in the Settings dashboard, after selecting it the agent will be able to write the reason.

   

   All the reasons will be available afterwards in the comments tab

   

Body (tabs)

The body of a validation detail page is divided in different sections that are visible when the corresponding tab is clicked.

In the case of Multiple Onboarding, the UI will display as many document tabs as additional documents.

Document tab

In this section, the agent can review the document validation process results:

• Personal Data: The entire list of text fields obtained from the document by using the OCR technique (on the left)

  

  By clicking on the "Edit" button, it is posible to change the OCR fields if it is necessary. This modified fields will be shown in the "Edited OCR" column and its background highlighted in red.

  

  

• The document obverse and reverse images which were uploaded during the validation process (on the right)

  

  It is also displayed a cut of the signature from the document.

  

• A form where some issues about the document can be advised.

  

• The results of document verification process (below the others)

  

  It is also possible to see a brief description of most of the scores when the mouse cursor is stopped over the scores values. The scores that appear in this tab depend on the type of document used in the validation process and the verification steps that are available for it. The description of all these different scores and the most used for each type of document can be found in Validas Scores Documentation.

Face Biometry tab

In this section, the agent can review the results of the face biometry verification processes. These processes consists -among others- on ensuring that the document that has been previously verified belongs to the person carrying out the transaction, that is, the person who appears in the selfie photo.

There are different scores that can be displayed depending on the taken validation workflow or customer journey:

• ID photo vs Selfie

  

• ID photo vs NFC Photo

  

• NFC Photo vs Selfie

  

• Selfie (or ID photo) vs Video

  

• Liveness Detection

  

  It is also visible the list of moves the user was requested to do during the challenge video

In the case of multiple onboarding, the scores are visible below the tag MULTIPLE ONBOARDING REDULTS and the title of the photo includes the number of the document:

• ID photo vs Selfie

  

Also, in case the video stage has been performed, and in case the regulation requires it and therefore, the boi-Das service is configured for it, a form will appear where the agent must perform some validations on the identity of the validation.

The last issue is only displayed when the video process consisted on "showing the document" instead of a head movements challenge video.

Validation information tab

This section contains:

• Validation timestamp:

  

  Once all the validation steps have been carried out, there is the possibility to timestamp the data used on the validation process and the results obtained. The purpose of this, is to provide a mean to verify the integrity of the process and ensure that the data of a validation process corresponds to a specific validation, time after the process has been carried out.

  This section contains the date and time when the timestamp took place and the Timestamp Authority used, which can be 'default', 'fnmt' (Fábrica Nacional de Moneda y Timbre) or 'izenpe' (Vasque Government Certification Authority).

• Contextual data: additional validation information such as the OS, gelocalization data, the device... It is an optional step for the validation process and obtaining some data requires using Veridas contextual data SDK.

  

• Validation Environment: This section will be generated and provided by vali-Das for each one of the uploaded images. It will contain Veridas sdk version metadata of the uploaded images in the onboarding process.

  

  The following information will be displayed:

  - Platform: Information about the platform: web-desktop, web-mobile, native-ios or native-android. - User Agent: Custom field with the string sent by the browser in the User-Agent header. This field will not appear when the information is not available. - SDK Information: list with names, versions and patchs of the SDK:

    - SDK Document Capture
    - SDK Photo Selfie Capture.
    - SDK Selfie Alive Capture.
    - SDK Video Selfie Capture.
    - SDK Nfc.
  

  If the fields from different images do not match or do not exists, the value will be Not available.

State Verification tab

This tab shows the result obtained of doing an identity verification of the person which is doing the Veridas validation process by using the data obtained from the ID document against a government identity verification service.

Comments tab

This tab can be used to add comments about the validation process by all the users.

PEP & AML tab

This tab shows the result of checking if the identity of users performing a Digital Onboarding process is included in a database of Sanctions, Watchlists, PEPs and Adverse Media by using the data obtained from the ID document.

Activity tab

This tab shows the history of activity and actions done by the agents, supervisors operators and administrators related to the validation process. It registers every user action related with the use and manipulation of the validation and includes the date when the action was done, the user who realized it and its role.

The possible events that can appear are:

• Validation accessed: Indicates that an user has accessed the validation so it can see its details and approve or reject the validation.
• Validation approved: Indicates that an user has reviewed the details of a validation and has marked it as approved.
• Validation rejected: Indicates that an user has reviewed the details of a validation and has marked it as rejected.
• Validation set as inconclusive: Indicates that an user has reviewed the details of a validation and has marked it as inconclusive.
• Comment added: Indicates that an user has left a comment related to the validation.
• Validation exported: Indicates that a supervisor, operator or administrator has exported the validation data.
• Validation accessed via API: Indicates that the validation has been accessed through the API.
• Validation approved via API: Indicates that the validation has been approved through the API.
• Validation rejected via API: Indicates that the validation has been rejected through the API.
• Validation set as inconclusive via API: Indicates that the validation has been set as inconclusive through the API.
• Comment added via API: Indicates that an user has left a comment related to the validation through the API.
• Validation exported via API: Indicates that a supervisor, operator or administrator has realizaed the exportation of the validation through the API.
• Validation saved: Indicates that the validation has been downloaded and saved to boi-Das.
• OCR Validation modified: Indicates that the validation's document fields obtained by OCR have been edited.
• OCR Validation modified via API: Indicates that the validation's document fields obtained by OCR have been edited through the API.
• PDF validation generated: Indicates that the PDF exportation file has been created.
• PDF validation generated via API: Indicates that the PDF exportation file has been created through the API.