The Dossier entity is primarily designed for KYC (Know Your Customer) and KYB (Know Your Business) processes. Additionally, it can be used for tasks such as proof of funds verification. The Dossier entity facilitates the collection and verification of critical documentation, enabling the validation of an end user's identity, address, and specific transactions within the Alviere platform. By streamlining the authentication process, it ensures users meet compliance and security standards efficiently.

Every Dossier entity is inherently linked to an Account within the system. This intrinsic relationship ensures that each Dossier is always associated with a specific Consumer, Business or Stakeholder Account, thereby maintaining contextual relevance and coherence.

Dossier StatusesCopied!

During the lifecycle of a Dossier, it transitions through several statuses. Below is a comprehensive breakdown of each status:

Status	Description
CREATED	Initial status post-submission via the API, indicating Dossier creation.
PENDING	Dossier is currently under verification.
MANUAL_REVIEW	Dossier requires manual verification.
VERIFIED	Dossier approved and consumer identity confirmed.
REJECTED	Dossier denied due to reasons like inauthentic documents or poor photo quality.
FAILED	Dossier verification failed due to invalid document formats.
EXPIRED	Dossier's submitted document has surpassed its valid date. Consumer status reverts to PENDING_USER for resubmission of updated documentation.
DELETED	Dossier has been deleted from the system.

DocumentsCopied!

Within the Dossier entity, the Documents object plays a pivotal role. It is an array, where each object represents a specific document that is part of the Dossier. These documents are essential for the identity verification process and can vary in type, each serving a unique purpose in building a comprehensive profile of the user.

Document Types

The Documents object array can include a variety of document types. As of now, the platform supports the following document types:

Document Type	Description	Supported file types
PASSPORT	International travel document.	JPG, PNG
ID_DOCUMENT_FRONT	Front side of a government-issued identity document.	JPG, PNG
ID_DOCUMENT_BACK	Back side of the government-issued identity document.	JPG, PNG
DRIVER_LICENSE_FRONT	Front side of a driver's license.	JPG, PNG
DRIVER_LICENSE_BACK	Back side of a driver's license.	JPG, PNG
SELFIE	A self-taken photograph for facial recognition verification.	JPG, PNG
PROOF_OF_ADDRESS	Document verifying the user’s residential address.	JPG, PNG
PROOF_OF_FUNDS	Documentation proving the user’s financial capabilities.	JPG, PNG
MC_DOCUMENT_FRONT	Front side of a Matricula Consular (specific to certain countries).	JPG, PNG
MC_DOCUMENT_BACK	Back side of a Matricula Consular (specific to certain countries).	JPG, PNG
ARTICLES_OF_INCORPORATION	Registration document of a corporation.	JPG, PNG, PDF
CERTIFICATE_OF_GOOD_STANDING	Confirms a company's legal registration and compliance with its jurisdiction's requirements.	JPG, PNG, PDF
UBO_FORM		Identifies a company's Ultimate Beneficial Owners and their ownership details
INE_FRONT	Front side of a voter’s ID card (specific to certain countries).	JPG, PNG
INE_BACK	Back side of the voter’s ID card (specific to certain countries).	JPG, PNG

Integration in the Verification Process

When these documents are submitted as part of a Dossier, they undergo verification processes tailored to their type. For instance, passport verification may involve different checks compared to driver's license verification. This specificity in the verification process not only enhances the accuracy of identity verification but also aligns with international standards and best practices.

Document failed reasons

The following table contains the reasons why a Document failed to be verified.

FAIL_REASON	Description
RETAKE_BARCODE_NOT_FOUND	The document was classified as a type that contains a barcode but the barcode could not be found.
RETAKE_BARCODE_NOT_EXTRACTED	The barcode was found but could not be read.
ERROR_BARCODE_FORMAT	The barcode was read but the resulting data was not in the expected format.
ERROR_BARCODE	A problem was encountered when trying to process barcode extraction and parsing.
RETAKE_FULL_DOCUMENT	Data could not be extracted or the data was extracted, but did not pass our additional checks to ensure the extraction is accurate.
RETAKE_BACK_DOCUMENT	Data could not be extracted from the back of the document.
RETAKE_FRONT_DOCUMENT	The front of the ID document could not be extracted.
ERROR_DOCUMENT_NOT_SUPPORTED	The document may or may not be classified but it is currently not supported for extraction.
RETAKE_IMAGE_FOCUS	The image is out of focus.
RETAKE_IMAGE_GLARE	Glare was found on the document preventing extraction or authentication.
RETAKE_IMAGE_BRIGHTNESS	The image is too dark.
RETAKE_DOCUMENT_TOO_SMALL	Retake Image - Try changing from portrait to landscape mode or getting closer to the image.
RETAKE_DOCUMENT_NOT_COMPLETE	Retake Image - Ensure all four sides of the document are visible.
RETAKE_DOCUMENT_NOT_IDENTIFIED	The type of document could not be identified. This could be caused by a low-quality image or it could be a document that is not supported.
ERROR_IMAGE_FORMAT_NOT_SUPPORTED	Take a new image in a supported format.
RETAKE_IMAGE_TOO_SMALL	Take a larger image.
RETAKE_IMAGE_TOO_LARGE	Take a smaller image.
RETAKE_NO_IMAGE_FOUND	The authenticator was not able to assess the document because the input image was missing. Ensure that at least one image of an identity document was captured and submitted in the service request.
RETAKE_DOCUMENT_IMAGE_QUALITY	The authenticator was not able to assess the document because the image quality was too poor. Have the consumer capture a better quality image.
RETAKE_FIELDS_MISSING	Field comparison could not be performed because there were not enough fields on the document to perform a data comparison.
ERROR_ESF_NOT_FOUND
ERROR_TAMPERED	The Enhanced Security Feature (ESF) was found but shows evidence of tampering.
RETAKE_PORTRAIT_NOT_FOUND	Unable to get a portrait image from an ID document.
RETAKE_SELFIE_NO_FACE	Face Comparison requires two human faces; the face could not be detected in the selfie image.
RETAKE_PORTRAIT_NO_FACE	Face Comparison requires two human faces; the face could not be detected in the cropped portrait image extracted from the document or in the document itself.
ERROR_DECODING_SELFIE	Face Comparison could not be performed because there was a file decoding error with the selfie image.
ERROR_DECODING_DOCUMENT	Face Comparison could not be performed because there was a file decoding error with the cropped portrait image or the ID document image.
RETAKE_PORTRAIT_NOT_FOUND	The portrait on the document could not be located.
RETAKE_IMAGE_EXPOSURE	Retake Image
ERROR_FONT_CONSISTENCY	The fields used to determine font consistency did not return any extraction results
RETAKE_FACE_TOO_CLOSE	Face Liveness could not be performed because the distance between the face and image border is too small.
RETAKE_FACE_NOT_DETECTED	Face Liveness could not be performed because the face could not be detected in the image.
RETAKE_FACE_TOO_FAR	Face Liveness could not be performed because the facial area is not big enough for analysis.
RETAKE_FACE_ANGLE	Face Liveness could not be performed because the facial out-of-plane rotation angle is extremely large.
ERROR_DECODING_LIVENESS	Face Liveness could not be performed because there was a file decoding error.
ERROR_ENCODING_LIVENESS	Face Liveness could not be performed because there was a file encoding error.
RETAKE_MULTIPLE_FACES	Face Liveness could not be performed because there is more than one face detected in the selfie image.
RETAKE_FACE_CROPPED	Face Liveness could not be performed because the complete face is not present.
ERROR_AUTHENTICATION_TIMEOUT	The authenticator took longer to process than was allowed to ensure a quick Mobile Verify Auto response.
ERROR_AUTHENTICATION_DOCUMENT	This message is returned when an authenticity test was not applied to a document because the document doesn't have the necessary features or some design features prevent evaluation
ERROR_MRZ_NOT_FOUND	The document was expected to have an MRZ (machine readable zone) on it based on its classification but no MRZ could be found.
ERROR_MRZ_FORMAT	The MRZ (machine readable zone) was detected but was not in the proper format.
ERROR_MRZ_INVALID	The MRZ (machine readable zone) check digits are invalid.
ERROR_SERVICE_UNAVAILABLE	Service not currently available
RETAKE_DOCUMENT_TOO_CLOSE	Document Liveness could not be performed because the document is too close to the camera.
RETAKE_DOCUMENT_BORDER_TOO_SMALL	Document Liveness could not be performed because the distance between the document and image border is too small.
RETAKE_DOCUMENT_PARTIALLY_MISSING	Document Liveness could not be performed because a part of the document is not visible in the image.
RETAKE_DOCUMENT_NOT_DETECTED	Document Liveness could not be performed because the document could not be detected in the image.
RETAKE_DOCUMENT_TOO_SMALL	Document Liveness could not be performed because the document size in the image is too small.
RETAKE_MULTIPLE_DOCUMENTS	Document Liveness could not be performed because there are multiple documents in the image.
INVALID_FILE_FORMAT	The file format (pdf, image) is not supported for this Document type.

Dossier CreationCopied!

Creating a Dossier in our system begins by using the Create Dossier endpoint, where an Account's UUID is provided to link the Dossier to the respective account.

During creation, the Dossier can be designated as "primary" through a boolean parameter. This indicates that it contains essential documents for the account's onboarding, centralizing the primary set of documents for identity verification.

Dossiers can be created for Accounts in the following statuses:

• CREATED

• PENDING_USER

• ACTIVE

However, for Stakeholders, the parent Business account must also not have any of the following statuses:

• INACTIVE

• DELETED

• REJECTED

Supported Documents by Account type

This section highlights the types of documents supported for verification within the platform. Each account type supports specific documents to comply with regulatory and compliance standards. Below, you will find tables detailing the document types associated with different account types.

Account Type	Document Types
Business	ARTICLES_OF_INCORPORATION, CERTIFICATE_OF_GOOD_STANDING, UBO_FORM, ORG_CHART
Consumer	PASSPORT, ID_DOCUMENT_FRONT, ID_DOCUMENT_BACK, DRIVER_LICENSE_FRONT, DRIVER_LICENSE_BACK, SELFIE, PROOF_OF_ADDRESS, PROOF_OF_FUNDS, MC_DOCUMENT_FRONT, MC_DOCUMENT_BACK, INE_FRONT, INE_BACK
Stakeholder	PASSPORT, ID_DOCUMENT_FRONT, ID_DOCUMENT_BACK, DRIVER_LICENSE_FRONT, DRIVER_LICENSE_BACK, SELFIE, PROOF_OF_ADDRESS, PROOF_OF_FUNDS, MC_DOCUMENT_FRONT, MC_DOCUMENT_BACK, INE_FRONT, INE_BACK

Dossier updating/replacementCopied!

When a document within a dossier fails the verification process, two approaches can be taken to address the issue:

1. Updating a Document: If only a specific document within the dossier needs to be corrected or modified, the failed document can be updated individually. This targeted approach allows for efficient handling of discrepancies or errors without impacting the rest of the dossier.

2. Replacing the Entire Dossier: If multiple documents within the dossier are incorrect or if a comprehensive update is required, the entire dossier, including all its documents, can be replaced with a new dossier. This approach ensures that all verification requirements are met while maintaining consistency across the submission.

Dossiers can only be updated/replaced when all of the following conditions are met:

1. Account Status: The account must be in one of these statuses:

   1. CREATED

   2. PENDING_USER (specifically in the DOCUMENTS stage)

2. Dossier Status: The dossier must be in one of these statuses:

   1. EXPIRED

   2. REJECTED

   3. FAILED

3. (For Stakeholders only) Parent status: The parent Business account must not have any of these statuses

   1. INACTIVE

   2. DELETED

   3. REJECTED

Documents Real-Time VerificationCopied!

Feature Overview

Real-time verification is a pivotal feature in our Dossier creation process, offering immediate feedback on the documents uploaded for onboarding. This functionality contrasts with the traditional method, where Dossiers are queued for verification after completing all KYC stages.

Advantages

• Immediate User Feedback: One of the most significant advantages of real-time verification is the ability to provide instant feedback to users. As they upload their documents, any issues with the documents, such as poor image quality or incomplete information, can be immediately flagged. This immediacy allows users to rectify problems on the spot, enhancing the overall user experience and engagement.

• Improved Onboarding Process: Instant feedback during the document upload process can significantly streamline user onboarding. It reduces the chances of delays in the verification process, thereby improving acquisition numbers and overall user satisfaction.

Implementation Considerations

Real-time verification isn't universally applicable for all document types. To fully understand which documents are eligible for this feature, it is essential to consult with your Alviere program manager. They can provide detailed information about the types of documents that support real-time verification and guide you on how to best implement this feature for optimal results in your specific program.

Activation of Real-Time Verification

To leverage the real-time verification feature in the Dossier creation process, it's essential to enable the real_time_verification boolean. This activation is a crucial step when creating a new Dossier and determines whether the submitted documents will undergo immediate verification.

Outcomes of Real-Time Verification

• Successful Verification: If real-time verification is successful, the Dossier's status is updated to VERIFIED. This indicates that the documents have met all necessary criteria and are deemed acceptable for onboarding purposes.

• Verification Failure: In instances where real-time verification does not succeed, the Dossier is marked with a status of FAILED. Crucially, the Dossier entity will include a

  Documents object array, encompassing a fail_reasons array of strings. This array provides detailed explanations for the failure of each submitted document.

The inclusion of detailed reasons for verification failures is a key advantage of this feature. It not only aids users in understanding the specific issues with their documents but also streamlines the rectification process. Users can immediately address the highlighted problems, enhancing the chances of successful verification upon resubmission and significantly improving the overall efficiency of the onboarding process.

Example Scenario

Consider a Dossier containing two documents: ID_DOCUMENT_FRONT and ID_DOCUMENT_BACK. If the real-time verification of the ID_DOCUMENT_BACK encounters issues, the corresponding Document in the Dossier will have a fail_reasons array containing a specific reason such as RETAKE_BACK_DOCUMENT. This granular feedback is instrumental in guiding users to take corrective actions, like retaking and resubmitting the backside of the ID document.