Service Description

IDV SERVICE, IDV ADD-ONS & ADDITIONAL SERVICES

All the capitalised terms not defined in the Service Description are to be read in accordance with the Agreement.

IDV SERVICE

The applicability of this section is subject to the agreed Service stipulated in the Order Form.

1. Identity Verification Configuration

Veriff’s Service shall have the configurations as stipulated in the relevant Order Form:

1.1. Expected inputs & method:

(a) Identification document photos ("Document");

(b) End User photographs ("Selfie");

(c) Audio & Video (if enabled);

(d) Technical data & other data as specified in DPA.

1.2. Service Module Checks:

(a) Instant: Faster decisions with core checks;

(b) Balanced: Fast decision with additional checks; or

(c) Custom: Based on specific Customer requirements.

1.3. Check Level Actors:

(a) Hybrid: Decisions made using inputs from a combination of verification specialist(s) and automation;

(b) Full Auto: Decisions made using automation only.

1.4. Integration types:

(a) iOS/Android SDK;

(b) Web (JS SDK); or

(c) API.

1.5. Data extraction:

VERIFICATION FLOW

2. Identification Document Photo

2.1. Except for the API integration, the End User will be required to take a photo of their identification document through the Service.

2.2. If none of the photos taken by the End User enable the identification of the End User's identification document, Veriff shall inform the Customer and the End User shall be redirected to the beginning of the verification process.

3. End User Photograph (Not applicable for “Document Only” Services)

3.1. Except for the API integration, The End User will be required to take a photograph of themselves through the Service, in accordance with the instructions provided to the End User through the Service.

3.2. Veriff shall inspect the photographs of the End User. The photograph of the End User must enable the identification of the person in the photograph. If none of the portrait photographs of the End User enables the identification of the person on the photograph, Veriff shall inform the Customer and the Customer shall redirect the End User to the beginning of the verification process.

4. Audio & Video Recording

4.1. Veriff offers audio & video recording of the End User going through the verification process. The Customer may require this functionality to be mandatory, non-mandatory or disabled. This is not applicable for API integration.

VERIFICATION CHECKS

5. Verification Checks

5.1. Veriff inspects the data submitted by the End User or otherwise collected through the Service or via API.

5.2. If and to the extent applicable, Veriff inspects the following personal data of the End User:

(a) Data available in any Third Party Site. Veriff shall automatically validate End User data against applicable Third Party Site, as part of the additional services;

(b) End User photograph and Document Photo. Veriff shall check whether the End User Photograph is taken from a real natural person and whether the Document photo is taken from a real physical document.

5.3. If applicable, Veriff will review the following data and information collected about the End User:

(a) End User's device data (i.e., device signature). The review shall take place automatically;

(b) Quality of document photos. Veriff shall review the readability of the photo of the End User's identification document;

(c) Identity. Veriff shall check the match of the End User’s portrait photograph with the facial image on the identification document with the help of specific algorithms;

(d) Document data. Depending on the selected data extraction fields (as indicated above either 0, 5, 7 or 9 fields and any additional extraction fields) in the Order Form, Veriff will check the data of the End User. 

(e) Automatic inspection of the technical data and comparison with the technical data of previous sessions from the same IP address and/or the same device (except in case of verification via API).

5.4. Inspection of the End User data must give Veriff assurance that the checked data is accurate and complete and has not been manipulated or otherwise shown differently.

5.5. In cases where the document photo and/or the portrait photograph of the End User is unclear, Veriff shall inform the Customer and the Customer shall redirect the End User to the beginning of the verification process. Whenever at least one of the photos made by the End User during the verification process is not readable and/or clear, the End User must perform through the following stages of the Verification process: taking a photo of the document and taking the portrait photograph of the End User.

VERIFF FRAUD PACKAGES

Prior to 28.09.2023 Fraud features were available for purchase individually. For upgrading to Fraud Protect or Fraud Intelligence package, please contact sales@veriff.com.

6. "Fraud Protect" Package

Veriff Fraud Protect is a core component of Veriff’s Identity Verification solution. By investigating key areas of fraud mitigation during an identity verification session, it mitigates impersonation, identity document fraud, bonus or velocity abuse and multi-accounting.

Each element, except for Crosslinks, of Fraud Protect can be opted-out of in order to suit Customer’s use-case, however having all elements of Fraud Protect activated ensures the most effective fraud protection.

Fraud Protect includes the following:

6.1. DocCheck: Provides key insights about the presented document in order to detect visible signs of physical or digital data/structural manipulation in the document.

6.2. FaceCheck: Provides key insights about the End User’s selfie biometrics in order to detect visible signs of physical or digital manipulation.

6.3. DeviceCheck: Collects and analyzes multiple signals of an End User’s device in order to help identify devices which may be abusing the Service.

6.4. FaceCheck Liveness: Using advanced passive liveness tests, this feature provides the most user-friendly way of validating whether the user is actually present and participating in the session.

6.5. FaceBlock: FaceBlock enables Customer or Veriff to add specific End Users to the FaceBlock dataset to block repeat fraud attempts within the Customer's instance of the Service. The FaceBlock dataset is Customer-specific and consists of facial biometrics extracted from blocklisted Session or portrait photographs imported using FaceBlock Import discretionarily by the Customer or from the Sessions added by Veriff based on the potential fraudulent activities End Users display when going through Customer's Service Session. Facial biometric data of each incoming Session is checked against the FaceBlock dataset, and if a match is found, the Session is declined with the reason code "Face match with blocklist". Data in the FaceBlock dataset is retained for 3 years. In the event the aggregate number of FaceBlock and FaceBlock Import faces exceeds the limits below, an additional charge will be incurred: 

• 50,000 faces with the Fraud Protect package; or
• 100,000 faces with the Fraud Intelligence package.

6.6. Restricted IP location: A check that can apply territory-specific restrictions based on the IP region. The restrictions are requested by the Customer and in case a match is found, the given Session shall be declined by Veriff with the reason code “Restricted IP location”.

6.7. Velocity Abuse

6.7.1. Velocity Abuse is a feature created to automatically deny multi-accounting. It is useful to deter the same End User from opening multiple accounts, requesting multiple loans or abusing sign-up bonuses etc.

6.7.2. If Velocity Abuse feature is enabled, then every End User can be approved just once. If the same End User submits recurring verification attempt after already being approved, the given Session shall be declined.

6.7.3. Veriff has three Velocity checks that can be activated altogether or independently from each other:

(a) Velocity/abuse duplicated user - person in the session has been previously approved in current integration;

(b) Velocity/abuse duplicated ID - document in the session has been previously approved in current integration;

(c) Velocity/abuse duplicated device - after 10th approved session submitted from the same device, all further attempts will be declined (done in order to prevent systematic identity abuse).

6.8. Risk Labels

6.8.1. Risk Labels are the most effective for sessions where Veriff has Network and Device information. Risk Labels provide a summary of associated threats/risk indicators detected during the IDV session. These risks could be broadly classified as:

(a) Document or Document holder related risks;

(b) Device and network related risks;

(c) Risks detected due to links within the same Customer’s traffic;

(d) Risks detected due to links with traffic of a different Customer within the same industry (when Industry CrossLinks is enabled).

6.8.2. These labels can be returned to the Customer for integration into their fraud/risk system strategies, giving them further control over the flow of End User onboarding.

6.8.3. Veriff shall communicate the information related to Risk Labels to the Customer through User Interface (UI).

6.9. CrossLinks

6.9.1. CrossLinks is a solution that identifies links between an incoming and an existing Session, with the aim of making sure that any risks or fraud indicators identified in a historical Session are also used to make an informed and thorough evaluation of the incoming Session. The Sessions are linked based on technical data, document information and face embeddings present within a particular Session. Veriff also generates a risk label to provide the Customer insights when the current Session is linked to a fraudulent Session.

6.9.2. CrossLinks functions with non-archived live data. 

6.10. Industry CrossLinks

6.10.1. Industry CrossLinks links and stops known fraudsters across Customers in the same industry. This is done based on the technical data, document information and face embeddings present within a particular Session.

6.10.2. Veriff will:

(a) Crosslink all Customer’s incoming Sessions for all the Customers that exist in the same “Industry” across all the existing crosslinking data points;

(b) Add an additional risk label that mentions “Session crosslinked across multiple Clients” to specifically identify that the crosslink was done across Customers.

6.10.3. No End User or Customer specific information is disclosed between the Customers apart from the risk label. Industry CrossLinks functions with non-archived live data.

7. "Fraud Intelligence" Package

7.1. Veriff’s Fraud Intelligence package enhances the Fraud Protect package with a series of valuable signals delivered as actionable intelligence to the Customer, which can be consumed into Customer’s own infrastructure and used as intelligence when setting strategies, or further investigating cases.

7.2. RiskScore: Fraud Intelligence enhances Customer’s ability to react quickly to threats by providing our proprietary RiskScore. RiskScore is an actionable, numerical (0-100) value representing the overall risk associated with Session. It is calculated based on multiple signals generated throughout the End User’s Session and tuned by Veriff’s data science team using advanced machine-learning models.

7.3. DeviceCheck over API: Device Check collects and analyzes multiple signals of End User’s device in order to help identify devices which may be abusing the Service.

7.4. FaceBlock Import: FaceBlock Import enables Customers to import previously collected portrait photographs of individuals into a Customer-specific FaceBlock dataset. Upon importing the photographs in the Service, Veriff will extract the facial biometrics and add those to FaceBlock dataset for use as part of FaceBlock Service. Limits apply to FaceBlock dataset as described at section 6.5. Data in the FaceBlock dataset is retained for 3 years.

7.5. Extended CrossLinks: Extended CrossLinks functions the same as CrossLinks. Extended CrossLinks lengthens the period of data Veriff crosslinks from live data to also archived data for the maximum of three years to broaden the ability to detect patterns.

7.6. Risk Labels over API: In addition to information related to Risk Labels communicated to the Customer through User Interface (UI), Veriff  shall send this data through Programming (API) Interfaces.

DECISION

8. Reaching the Verification Decision

8.1. After carrying out the verification process and checking the data, Veriff shall make one of the following verification decisions (each a “Verification Decision”):

(a) A positive Verification Decision: approved; the data submitted by the Customer or collected by Veriff is of sufficient quality , e.g. document photo and the End User’s portrait photograph are clear and readable, the End User’s photograph matches the image on the document, there is no suspicion of the fraud, of manipulation of the data or any other non-compliance of the submitted data, as checked by Veriff.

(b) Resubmission of a Verification Decision: resubmission; expected input is missing, poor quality of the submitted or collected data and/or the document type is not supported.

(c) A negative Verification Decision: declined; there is suspicion of fraud, manipulation of the data or any other non-compliance of the data, as checked by Veriff.

9. Communicating the Verification Decision to the Customer

9.1. Veriff shall communicate the Verification Decision to the Customer through Customer dashboard and Programming (API) interfaces.

9.2. If the Verification Decision is negative, Veriff shall communicate the reason together with the reason code to the Customer. In addition, Veriff may provide automatically extracted data, if and to the extent applicable and available. 

9.3. In case of resubmission, Veriff shall communicate the reason together with the reason code to the Customer and, if enabled, the End-User will receive a retry prompt in End-User flow.

9.4. If the Verification Decision is positive, Veriff shall communicate to the Customer the positive decision together with all relevant End-User data, if and to the extent applicable and available.

9.5. The Customer can thereafter add labels to Veriff's decision for their own internal purposes in the Customer dashboard. It is important to note that the Customer’s additions will not affect the Verification Decision.

VERIFICATION ADD-ONS

The applicability of this section is subject to the agreed Service stipulated in the Order Form.

10. Additional Data Extraction

10.1. Subject to the purchased Services stipulated in the Order Form, Veriff may also provide any of the  following document data extraction functionalities:

(a) Place of birth extraction from document;

(b) Address extraction from document;

(c) “First issue” extraction;

(d) “Place of issue” extraction;

(e) Issue Number (aka Document Discriminator Number);

(f) Foreigner status;

(g) Process number;

(h) Occupational information;

(i) Employer information;

(j) Residence permit type;

(k) Drivers license number;

(l) Extra names;
(m) Remarks.

10.2. Driver’s license category extraction from driver’s licenses. The B-, A- and AM-category extraction is applicable to document type “driving license” / “driver’s license” and only for documents which use the 1968 Vienna Convention on Road Traffic for the categories. The extraction is not applicable to other document types or to documents which do not use the pictograms for category/subcategory codes as indicated in Annex 6 of the 1968 Vienna Convention on Road Traffic. The extraction has pre-defined values, as follows:

(a) Positive - the document presented by the End User has a category marked. If the document is expired but has “category” rights, the result is still positive (this is additional to the overall linked Verification Decision and does not replace that).

(b) Negative - the document presented by the End User does not have category marked.

(c) Null - the extraction is not possible, for example, the document type is not correct, does not use the 1968 Vienna Convention on Road Traffic for the categories, does not have a category specified or any other reason.

11. Age Validation

11.1. Age Validation service checks the person's age by calculating the real age from the date of birth on the identity document. Individuals below the Customer's predefined minimum age thresholds are automatically declined.

12. INE Database Verification Check

12.1. Veriff’s INE Database Verification Check performs a check against a Third Party Site using a Third Party Site in order to validate authenticity of relevant information from the user’s INE Voter ID document. The information is cross-referenced against the INE Lista Nominal database.

13. CURP Database Verification Check

13.1. Veriff's CURP Database Verification Check performs a check against a Third Party Site using a Third Party Site in order to validate authenticity of  relevant information from the user's identification document including the CURP (Clave Única de Registro de Población) number. This information is then compared against the RENAPO (Registro Nacional de Población) database.

14. CPF Database Verification Check

14.1. Veriff’s CPF Database Verification Check performs a check against a Third Party Site in order to validate the CPF (Cadastro de Pessoas Físicas) number and additional data. The information is compared by SERPRO (Serviço Federal de Processamento de Dados; Brazilian Federal Data Processing Service) against the Brazilian Federal Revenue Department (Receita Federal do Brasil) database.

14.2. After carrying out the CPF Database Verification Check described above, Veriff shall make one of the following decisions:

(a) A positive Verification Decision where the validation of the End User’s CPF number and matching of the additional data against the database is successful.

(b) A negative Verification Decision where the validation of the CPF number and/or matching of the additional data against the database is not successful.

14.3. Where the End-User’s document does not have the CPF number the Session will be processed as a Session without the CPF Database Verification Check being applied.

15. Aadhaar Database Verification Check

15.1. Veriff’s Aadhaar Database Verification Check performs a check by using a Third Party Site.

15.2. Veriff validates the Aadhaar number extracted from an identification document, or presented by the End User, in the Session against Unique Identification Authority of India’s Central Identities Data Repository (CIDR), while retrieving additional Personal Data from the database and comparing a photograph of the End User received from the database with the photograph taken of the End User in the Session. The comparison is done using biometric information . End Users need to actively authorize Aadhaar Database Verification Check in the Verification flow for the Aadhaar Database Verification Check to be successful.

(a) In case the Aadhaar Database Verification Check is successful, the Verification Decision will be based on, and the data extraction from the identification document substituted with, data from the Unique Identification Authority of India’s Central Identities Data Repository (CIDR).

(b) in case the Aadhaar Database Verification Check is unsuccessful, the Session will be processed as a Session without the Aadhaar Database Verification Check being applied.

15.3. Aadhaar Database Verification Check is available for limited integration types.

15.4. Fraud features, including the “Fraud Protect” and “Fraud Intelligence” packages are applicable to the Aadhaar Database Verification Check only to a limited extent.

16. Name Matching Check

16.1. This check verifies whether the name extracted from the End User’s document matches with the End User’s name sent by the Customer to Veriff. 

16.2. Veriff will allow Customers to configure the Name Matching Check to either require an exact match or allow a pre-defined level of edit distance according to Levenshtein Distance.

16.3. In case there is no match between the names, Veriff will decline the session.

17. INE Biometric Database Verification Check

17.1. Veriff's INE Biometric Database Verification Check performs a check against INE (Institutio Nacional Electoral) database using FIMPE Fideicomiso, both Third Party Sites, in order to validate authenticity of the End User’s selfie image and relevant information extracted from the End User's identification document (to the extent supported by Veriff). Through FIMPE the information is received by INE’s technological platform that conducts a biometric check and returns a match to the database.

17.2. The End User passing a successful IDV with Veriff is a prerequisite for the INE Biometric Database Verification Check to run. In case the INE Biometric Database Verification Check fails, Veriff will decline the Session.

17.3. Veriff will not commence a Session with the INE Biometric Database Verification Check unless the requested consent information has been passed on to Veriff by the Customer.

17.4. The INE Biometric Database Verification Check is available for limited integration types.

17.5. The INE Biometric Database Verification Check requires a specific infrastructure corresponding to the requirements set forth by FIMPE Fideicomiso and/or INE. As stipulated in the Order Form, Veriff will charge an INE Biometric Database Verification Check implementation fee as a Service for setting up the necessary technical solutions, setting up and hosting the clusters and middleware for the secure communication solutions, on Veriff's and/or FIMPE Fideicomiso's infrastructure for the Customer to consume the service. Upon request, Veriff will provide additional information around the technical requirements and the implementation solution to be applied.

18. Registraduria Database Verification Check

18.1. Registraduria Database Verification Check performs a check against a Third Party Site in order to validate whether the End-User is not listed as deceased, the validity of their document and authenticity of the End-User’s name. The information is compared against the Colombian National Registry of Civil Status (Registraduría Nacional del Estado Civil de Colombia) database by using a Third Party Site.

18.2. In case the check has been purchased together with IDV, then the End User passing a successful IDV is a prerequisite for the Registraduria Database Verification Check to be conducted.

18.3. After carrying out the Registraduria Database Verification Check described above, Veriff shall make one of the following decisions:

(a) A positive Verification Decision where the collected data is successfully validated and matched against the data in the database.

(b) A negative Verification Decision where the collected data is not successfully validated and matched  against the data in the database.

18.4. Where the Session does not contain necessary or correct data, the Registraduria Database Verification Check will not be conducted

FRAUD ADD-ONS

The applicability of this section is subject to the agreed Service stipulated in the Order Form.

19. “Third Party” Check

19.1. Using facial vectors, Veriff shall analyze Session’s video in order to ensure that the End User was completing the Session on their own (i.e without any third party involvement).

PEP, SANCTIONS & ADVERSE MEDIA CHECKS

The applicability of this section is subject to the agreed Service stipulated in the Order Form.

20. PEP, Sanctions and Adverse Media Checks

20.1. Veriff will conduct Third Party Site Checks for the agreed Sessions provided in the Order Form. The Session can potentially include following functionalities: 

(a) PEP and/or Sanctions. Veriff runs a check on whether an End User is potentially a politically exposed person and/or whether an End User is a potential match to a record in the sanctions list. 

(b) Adverse Media. Veriff runs a check on whether an End User is a potential subject to adverse media. This encompasses media relating to accusations, arrest, trial and exoneration.

(c) Ongoing monitoring. Veriff conducts ongoing monitoring of PEP, Sanctions and Adverse Media lists.

20.2. Veriff uses a Third-Party Site (as further described in Terms of Service) which assesses multiple country-specific and international databases in order to conclude whether an End User qualifies as a politically exposed person or has record in the sanctions list. 

20.3. In order to conduct a Third Party Site Check, Veriff will send following End User’s details to the Third Party Site:

(a) First name;

(b) Last name; 

(c) Year of birth.

20.4. Third Party Site conducting the check processes the information set out in the above section and will provide a result to Veriff. Veriff will send the Third Party Site Check results to Customer via API, by using webhooks or via Veriff’s back-office. 

20.5. More information on Veriff’s external data sources may be found in Veriff’s Help Center at help.veriff.com.

BIOMETRIC AUTHENTICATION

The applicability of this section is subject to the agreed Service stipulated in the Order Form.

21. Biometric Authentication

21.1. To use Biometric Authentication the End User must first be enrolled in one of the following ways. The End User must be imported by the Customer via Biometric Authentication Migration, or have previously received a positive decision from a Biometric Enrolment flow or an Identity Verification session. The Customer must assign a universally unique identifier for the End User.

21.2. Based on the existing enrolment, the biometric data of the End User is extracted and saved to a set of biometrics.

21.3. The End User will be required to take a photo of themselves through the Service. Veriff will conduct limited automated Verification and Fraud Checks and compare the biometric data from the photo and the unique identifier to that in the set of biometrics. A Biometric Authentication Decision is issued based on the foregoing.

21.4. Veriff shall communicate the Biometric Authentication Decision to the Customer via webhook or API:

(a) A positive Biometric Authentication Decision: approved; End User’s biometric data extracted from the photo and the unique identifier matches with the biometric data from the photo and the unique identifier of the enrolment, there is no suspicion of the manipulation of the data or any other non-compliance of the submitted data. Veriff saves the biometric data of the End User to a set of biometrics.

(b) A negative Biometric Authentication Decision: declined; either (1.) the biometric data extracted from the photo does not appear to match the previously saved reference set of biometrics; (2.) there is no reference data for this End User; (3.) the unique identifier does not match; or (4.) an attempt of fraudulent behavior is detected.

21.5. Veriff also offers audio and video recording of the End User going through the Biometric Authentication. The Customer may require this functionality to be mandatory, non-mandatory, or disabled. This is not applicable for API integration.

22. Biometric Enrolment

22.1. Veriff provides the following Biometric Enrolment flow to the Customer:

(a) Except for the API integration, the End User will be required to take a photo of themselves through the Service, in accordance with the instructions provided to the End User through the Service. In case of API integration, the Customer will provide the End User photo to Veriff via a designated API connection.
(b) Veriff shall inspect the photo and biometrics of the End User:
(i) a successful enrolment: If the photo of the End User enables identification of the person in the photo, there is no suspicion of the manipulation of the data or any other non-compliance of the submitted data based on the limited Verification and Fraud Checks, then Veriff saves the biometric data of the End User to a set of biometrics. As a result, the End User is considered as enrolled for Biometric Authentication.
(ii) a failed enrolment: If the photo of the End User does not enable the identification of the person in the photo, there is suspicion of the manipulation of the data or any other non-compliance of the submitted data based on the limited Verification and Fraud Checks, then the End User is not enrolled for Biometric Authentication and Veriff shall inform the Customer. The Customer may redirect the End User to the beginning of the Biometric Enrolment flow.
22.2. Veriff also offers audio and video recording of the End User going through the Biometric Enrolment process. The Customer may require this functionality to be mandatory, non-mandatory, or disabled. This is not applicable for API integration.

23. Biometric Authentication Migration

23.1. Biometric Authentication Migration allows the Customer to migrate previously collected photos of End Users whom the Customer wants to enroll for future Biometric Authentication sessions. Veriff inspects the photo and biometrics of the End User as described in section 22.1(b).  As a result of the Biometric Authentication Migration, End Users with successful enrolment results are considered as enrolled for Biometric Authentication.

PROOF OF ADDRESS CAPTURE

The applicability of this section is subject to the agreed Service stipulated in the Order Form.

24. Proof of Address (POA) Capture

24.1. Veriff provides the end-user flow necessary to capture or upload a copy of the End-User’s proof of address document.

PROOF OF ADDRESS EXTRACTION

The applicability of this section is subject to the agreed Service stipulated in the Order Form.

25. Proof of Address (POA) Extraction

25.1. As part of Proof of Address Extraction, Veriff extracts the data from the presented, acceptable Proof of Address document, and provides the extracted data to the Customer.

25.2. The Customer may apply Name Matching Check as described above as a part of the Proof of Address Extraction whereby the name sent by the Customer to Veriff is compared against the name extracted during Proof of Address Extraction. Where the Customer does not provide the name for comparison, the Session will be processed as a Session without the Name Matching Check being applied.

25.3. The Proof of Address Extraction only supports documents with latin characters.

SSN VERIFICATION SERVICE

The applicability of this section is subject to the agreed Service stipulated in the Order Form.

26. Social Security Number Verification Service

26.1. Veriff’s Social Security Number Verification Service utilizes a Third Party Site, as part of Veriff’s sub-processor’s offering, to perform the check against a Third Party Site in order to determine the validity of the social security number based on the information provided by the Customer.

26.2. Social Security Number Verification Service is available to be used only over API and separately from the IDV Service.

AGE ESTIMATION SERVICE

The applicability of this section is subject to the agreed Service stipulated in the Order Form.

27. Age Estimation Service

27.1. Age Estimation flow. Veriff provides the following Age Estimation flow to the Customer:

(a) Except for the API integration, the End User will be required to take a photograph of themselves through the Service, in accordance with the instructions provided to the End User through the Service. In case of API integration, the Customer will provide the End User photographs to Veriff via designated API connection. 

(b) Veriff shall inspect the photograph of the End User. The photograph of the End User must enable the identification of the person in the photograph. If none of the portrait photographs of the End User enables the identification of the person on the photograph, Veriff shall inform the Customer and the Customer shall redirect the End User to the beginning of the Age Estimation process.

(c) Veriff also offers audio & video recording of the End User going through the Age Estimation process. The Customer may require this functionality to be mandatory, non-mandatory or disabled. This is not applicable for API integration.

27.2. Age Estimation checks. Veriff will estimate the following based on the photographs of the End User provided either via API or through the Age Estimation flow:

(a) End User’s age as a number;

(b) End User’s gender as a threshold from 0-1.

27.3. The age of the End User is estimated merely from the photograph of the End User. The real age of the End User can be either younger or older from the estimate provided by Veriff. If the End User with US geolocation is estimated to be younger than 13 years old, then the session is assigned for deletion.

27.4. The gender of the End User is estimated merely from the photograph of the End User. The estimated End User’s gender is delivered to the Customer as part of a threshold (i.e. a value close to “0” shows that the End User is likely a male and a value close to “1” shows that the End User is likely a female).

27.5. Fraud Checks. The following fraud checks shall also apply to the Age Estimation service:

(a) User Liveness;

(b) Network and Device Intelligence;

(c) Dynamic Fraud Checks.

27.6. Decision. After carrying out the Age Estimation checks described above, Veriff shall make one of the following decisions (each an “Age Estimation Decision”):

(a) A positive Age Estimation Decision: approved; End User’s photograph is clear and understandable, there is no suspicion of the manipulation of the data or any other non-compliance of the submitted data, Veriff was able to estimate the End User’s age and gender.

(b) Resubmission of an Age Estimation Decision: resubmission; expected input is missing, poor quality of the submitted data.

(c) A negative Age Estimation Decision: declined; the Session is deemed to have suspicious or fraudulent elements.

27.7. Communicating the Age Estimation Decision to the Customer. Veriff shall communicate the Age Estimation Decision to the Customer through Customer dashboard and Programming (API) interfaces:

(a) If the Age Estimation Decision is negative, Veriff shall communicate the reason together with the reason code to the Customer.

(b) In case of resubmission, Veriff shall communicate the reason together with the reason code to the Customer and, if enabled, the End User will receive a retry prompt in End User flow.

(c) If the Age Estimation Decision is positive, Veriff shall communicate to the Customer the positive decision together with End-User input data, as relevant, and to the extent applicable and available.

UKDIATF CERTIFIED IDENTITY VERIFICATION SOLUTIONS

The applicability of this section is subject to the agreed Service stipulated in the Order Form.

28. UKDIATF Certified Identity Verification (M1A)

28.1. Veriff provides the following UK Digital Identity and Attributes Framework (“UKDIATF”) flow to the Customer:

(a) The End User will be required to take a photograph of themselves and their UK or Ireland issued passports through the Service, in accordance with the instructions provided to the End User through the Service.

(b) Veriff shall inspect the End User’s personal data as specified in Veriff Service Description sections 5 and 6 (as applicable).

28.2. Audio and video recording is mandatory throughout the Session.

28.3. Veriff shall conduct the following registry check for the End User:

(a) CIFAS database check.

28.4. CIFAS database check. As part of CIFAS check, Veriff passes the End Users first name, last name, date of birth, document number, and address (as available) to the CIFAS database.

28.5. Reaching a Decision:

(a) A Positive Verification Decision: Veriff shall reach a positive verification decision in case the verification checks, fraud checks and the checks described in section 27.3. were all successfully passed. This also means that the End User did not have negative listings in the CIFAS database

(b) Resubmission of a Verification Decision: Veriff shall issue a resubmission in cases specified under section 8 of the Service Description.

(c) A Negative Verification Decision: Veriff shall reach a negative verification decision, if the verification checks and/or fraud checks fail or the database checks described in section 27.3 are not passed.

28.6. Communicating the Verification Decision to the Customer. All Verification Decisions shall be communicated to the Customer as described in Veriff Service Description section 9.

29. UKDIATF Certified Identity Verification (M1B)

29.1. Veriff provides the following UK Digital Identity and Attributes Framework (“UKDIATF”) flow to the Customer:

(a) Customer is required to specify the End User’s address when generating the verification session over API.

(b) The End User will be required to take a photograph of themselves and their UK or Ireland issued passports, drivers licenses or identity cards through the Service, in accordance with the instructions provided to the End User through the Service.

(c) Veriff shall inspect the End User’s personal data as specified in Veriff Service Description sections 5 and 6 (as applicable).

(d) Based on the checks described in Veriff Service Description sections 5 and 6 (as applicable), Veriff shall make intermediary decisions according to the Veriff Service Description section 8.

(e) In case the decision is a decline of the verification then it will be deemed as a final decision and it will be communicated to the Customer according to Veriff Service Description section 9.

(f) In case the intermediary decision is positive then Veriff shall continue to additional registry based verification checks of the person.

29.2. Audio and video recording is mandatory throughout the Session. 

29.3. Veriff shall pass following registry check for the End User:

(a) CIFAS database check;

(b) Electoral Roll and/or Credit History check;

(c) Politically Exposed Persons (PEP) check.

29.4. CIFAS database check. As part of CIFAS check, Veriff passes the End Users first name, last name, date of birth, document number, and address (as available) to the CIFAS database.

29.5. Electoral Roll and/or Credit History check. As part of the Electoral roll and Credit History check, Veriff passes the End User’s first name, last name, date of birth, phone number, and address (as available) to the Electoral roll and Credit History database.

29.6. Politically Exposed Persons (PEP) check. As part of the Politically Exposed Persons (PEP) check, Veriff passes the End User’s first name, last name and date of birth to the PEP database.

29.7. Reaching a Decision. Decisions for the UKDIATF Certified Identity Verification (M1B):

(a) A Positive Verification Decision: Veriff shall reach a positive verification decision in case the intermediary decision was positive and the checks described in section 29.3. were all successfully passed. This means that the End User did not have negative listings in the CIFAS database; was listed in the Electoral roll or Credit history database; was not listed as a PEP.

(b) Resubmission of a Verification Decision: Veriff shall reach a “resubmission of the verification” decision in case the expected input is missing, submitted data is of poor quality and/or the document type is not supported by UKDIATF or Customer.

(c) A Negative Verification Decision: Veriff shall reach a negative verification decision, if:

(i) Veriff reaches a negative intermediary decision as described in section 29.1(e); or

(ii) Veriff reaches a positive intermediate result as described in section 29.1(f), but one of the database checks described in section 29.3. is not passed.

29.8. Communicating the Verification Decision to the Customer. All Verification Decisions shall be communicated to the Customer as described in Veriff Service Description section 9.

30. UKDIATF Certified Identity Verification (L1B)

30.1. Veriff provides the following UK Digital Identity and Attributes Framework (“UKDIATF”) flow to the Customer:

(a) The End User will be required to take a photograph of themselves and their UK or Ireland issued passports, drivers licenses or identity cards through the Service, in accordance with the instructions provided to the End User through the Service.

(b) Veriff shall inspect the End User’s personal data and their documents photographs as specified in Veriff Service Description sections 5 and 6 (as applicable).

(c) Based on the checks described in Veriff Service Description sections 5 and 6 (as applicable), Veriff shall make decisions according to the Veriff Service Description section 8.

(d) Veriff will communicate the decision to the Customer according to Veriff Service Description section 9.

30.2. Audio and video recording is mandatory throughout the Session.

UK ELECTORAL ROLL AND CREDIT HEADER DATABASE VERIFICATION CHECK

The applicability of this section is subject to the agreed Service stipulated in the Order Form.
31. UK Electoral Roll and Credit Header Database Verification Check

31.1. Veriff's UK Electoral Roll and Credit Header Database Verification Check performs checks against Third Party Sites in order to validate if End User is present in at least one of the databases using their first name, last name, address, date of birth (if available to Veriff).
31.2. In case of a mismatch with both of the databases according to Veriff's decision logic, Veriff will decline the Session.
31.3. UK Electoral Roll and Credit Header Database Verification Check is available to be used only over API and separately from the IDV Service.