Skip to main content

Flows / Features

This section contains the the following features: biometrical analysis (1:1, 1:N e FaceMatch), and custom message flow.

Biometry Flow​

It consists of using facial biometrics to validate and authenticate people in the registration process, generating an authentication score.

In this flow, facial biometrics and the CPF number presented at the time of registration are analyzed.

The Process section of the API provides information for the authentication score (1:N biometrics flow).

This flow can be divided into 2 groups:

  • Biometry
  • Biometrics + documents

Biometry​

In the biometrics group, 2 methods are used in the process: CreateProcess and GetProcess.

Use the CreateProcess method to send the image, the person's information, if you set the onlySelfie parameter to true. Setting this parameter to true is very important as it means that no documents will be sent.

The image is processed after successful upload.

Use the GetProcess method with the ID returned in the CreateProcess method to check the image analysis result.

Biometrics + documents​

In the Biometrics + documents group, 4 methods are used in the process: CreateProcess, DocumentInsert, ExecuteProcess and GetProcess.

Use the CreateProcess method to send the image, the person's information, and set the onlySelfie parameter to false. Setting the onlySelfie parameter to false means that documents will be sent using another method, described below.

Use the DocumentInsert method to send the desired documents, using the ID returned in the CreateProcess method.

Use the ExecuteProcess method to finalize and process the operation, using the ID returned in the CreateProcess method.

Use the GetProcess method with the ID returned in the CreateProcess method to check the image analysis result.

To check the document analysis result, use the GetDocuments method.

Note:

You have up to 60 minutes to enter the documents. The process return will remain at status 1 until the ExecuteProcess method is called. Otherwise the process is canceled automatically.

Important:

1) To check whether the process is complete, it is strongly recommended to use the webhook functionality for notifications (for more information, see Webhook).

If you choose not to get the webhook functionality, you can use the GetProcess method. Use the method every 2 seconds checking the status. The process is completed when the status is equal to 3.

2) The image needs to be sent in base64 (png, jpg, jpeg). If the photo is captured using the Unico SDK with Liveness, the image sent must be the Json Web Token (.jwt).

In the GetProcess method the result must be interpreted accordingly:

  • HasBiometry: If the given person has a valid biometrical face.
  • Liveness: Identifies if it is a picture spoof.
  • Score: Indicates the probability of the person in the photo being the CPF owner.
  • Status: Defines the current status of the process. The complete enumerable can be seen in Enumerables section.

Message Flow / Signature​

It consists of capturing selfies and documents through messages (SMS, email or link). The message can be sent manually through the portal or using the API.

It works by sending a link to people.

Portal​

The message flow is customizable, meaning it gives you autonomy to manage this experience. The customization and configuration of the message flow is done through a template that needs to be created and parameterized using the Portal.

In the template you can configure:

  • capture flow layout,
  • messages sent,
  • types of documents,
  • quantity and interval of sending notifications,
  • define the notification channel: email, SMS, or just generate a link (without sending SMS or email).

To generate the link for direct opening, without sending sms or e-mail, use the following endpoint:

"{{URLINSTANCE}}/Capture/SMS/Start.aspx?id={{ID}}":

Where:

Notes:

  • If the proposal and signature items are defined in the capture flow, it is necessary to have Sign contracted.

  • If you don't have a template configured, or you don't have Sign contracted, contact the CS and/or Onboarding team.

  • The link only works on mobile devices (mobile web).

  • When the browser is not supported for the SMS flow, the following message is displayed:

      “Há algo de errado na sua solicitação! 

      Para maiores informações entre em contato com a equipe de suporte.”.

For information on supported browsers, see Browsers.

Important

  • When configuring the capture flow steps on the Portal, it is important:

    1) If you are configuring all the steps, that is, Authentication, Selfie, Documents, Proposal and Signature, it is recommended to follow the following order:

    • Authentication, Selfie, Documents, Proposal and Signature.

      2) The Proposal must always be before the Signature and both must be at the end. If this order is not followed, errors may be presented in the message flow.

  • The maximum number of SMS sends is limited and can be configured. The limit is 5 messages, not counting the first shot, that is, 1 shot plus 5 new attempts (repicks) are allowed, totaling 6 shots (both SMS and email).

    Configuration is done through the Portal on the Templates screen.

###API

The Messages section of the API provides information for using the message flow (SMS or E-mail).

This flow can be divided into 2 groups:

  • Message
  • Message + Signature

Message​

In the Message group, 2 methods are used in the process: CreateMessage and GetMessage.

Use the CreateMessage method to send just the message, without the signature, set the send parameter to true. Setting this parameter to true is very important as it means that no document (PDF) to be signed will be sent.

Use the GetMessage method with the ID returned in the CreateMessage method to check the message parsing result.

Message + Signature​

In the Message + Signature group, 5 methods are used in the process: CreateMessage, DocumentMessageInsert, ResumeMessageInsert, ExecuteMessage and GetMessage.

Use the CreateMessage method to send the message by setting the send parameter to false. Setting the send parameter to false means that some type of document (PDF) to be signed and proposal summary (html) to be accepted by the client will be sent using another method, described below.

Use the DocumentMessageInsert method to send the document (PDF) to be signed, using the ID returned in the CreateMessage method.

Use the ResumeMessageInsert method to send the proposal summary (html) for acceptance by the client, using the ID returned in the CreateMessage method.

Use the ExecuteMessage method to finalize and process the operation, using the ID returned in the CreateMessage method.

Use the GetMessage method with the ID returned in the CreateMessage method to check the message parsing result.

Return GetMessage​

In the GetMessage method the result must be interpreted accordingly:

  • HasBiometry: If the given person has a valid biometrical face.
  • Liveness: Identifies if it is a picture spoof. For more information, see the Liveness section.
  • Score: Indicates the probability of the person in the photo being the CPF owner. For more information, see the Authentication Score section.
  • Status: Defines the current status of the process. The complete enumerable can be seen in Enumerables section.
  • Documentos: Documents sent by the user.
Important
  • When configuring the message flow through the Portal it is important to follow the configuration steps as listed below:

On the Templates screen, configure the steps in this order: Autenticação, Selfie, Documentos, Proposta and Assinatura..

If this order is not followed, errors may be presented in the message flow. The Proposta must always be before the Assinatura and both must be at the end.

Notice

When the browser is not supported for the SMS flow, the following message is displayed:

    “Há algo de errado na sua solicitação! 

    Para maiores informações entre em contato com a equipe de suporte.”.

Para obter informações dos navegadores suportados, consulte Browsers.

Liveness​

Liveness is a tool available on Unico Check that identifies whether an image was captured by a real person live. It detects whether the person is live when taking the selfie and not trying to send a photo of another photo, a photo of a screen, or a photo of a mask, reducing the risk of fraud.

The liveness technology is called SmartLive in Unico Check and is necessarily associated with the SDK, whose main functionality is the life proof with interaction.

Types of Liveness

  • Liveness without interaction - The system receives a simple image, without movement or user interaction during the capture.
  • Liveness with interaction - The capture is done through the SDK that asks to the user to perform specific actions, in the case of Unico Check, bringing the face closer to the screen.

How it works:

The tool uses algorithms that analyze the captured image and then can prove whether the biometric sample is a live human being or a false representation.

To use the Liveness functionality, you must request activation through your business executive.

After activating the functionality, the smartLive + SDK are inserted into the Authentication Score flow that validates the customer's identity at the time of registration. Below are the steps on how to operating the tool:

  1. The image capture (selfie);
  2. The proof that the person was live at the moment of the capture image;
  3. Sending the .JWT image to the client;
  4. Input of CPF, image in .JWT and documents in the authentication score flow. The documents are not mandatory and may or may not be sent.

Authentication Score​

The authentication score is an intelligent method of identifying people in which the probability of the person being authentic or not is evaluated with high efficiency.

Based on the face and the CPF of the customer plus the exclusive technology of Unico Check, the probability of the person corresponding to the CPF is informed. This assessment is carried out according to the level of knowledge of the person's face, added to information from the largest private biometric database in Brazil.

How it works: The score ranges from "-100" to "+100". If the score is close to "-100", the probability that the photo is not of the CPF owner is higher and may be a fraud. If the score is close to "+100", the probability of the photo being of the CPF owner is higher.

The following table provides details of each score range and the guidelines on how to use:

ClassificationScoreDescriptionRecommendation
NegativeBetween -40 and -100Provides enough evidences that the registration does not belong to the CPF ownerDeny the registration
NegativeBetween -1 and -39Provides less evidences that the person in the photo is not the owner of the CPFAssess the risks involved to make a decision
NeutralzeroDoes not provide enough evidence to conclude that the person in the photo is the owner of the CPFDeny the registration and ask the user for a new capture with the photo of the CPF owner
PositiveBetween +1 and +49Provides less evidences that the person in the photo is the owner of the CPFAssess the risks involved to make a decision
PositiveBetween +50 and +100Provides enough evidences that the registration belongs to the CPF ownerApprove the registration

Manager Mode​

The Manager Mode is a feature to handle possible dificulties in capturing pictures, especially those caused by unsatisfactory environment lighting, without causing major embarrassment to the final customer. This process does not generate biometric divergence.

Flow

By default the system is configured to use the Manager Mode automatically after the 6th picture capture valid attempt. This means that after 5 capture attempts where the system cannot identify a face, the next picture is automatically accepted without biometry and with a first registration score (+10).

The customer decides which flow the system should use when a face is not identified at the time of the picture capture. This is done through settings. Any changes to the items on the configuration screen generate logs of such changes, storing the previous and new settings, including the date and name of the person responsible for the change.

Note: To find out if the process was accepted without biometry (manager mode), use the Get Process method of the API. To do this, just check the following property:

HasBiometry - If set to "false" it means that the process was accepted without biometry (Manager Mode)

Webhook​

Webhooks create a type of connection between two systems, so that one system can receive information from the other as soon as a certain action occurs. This information is sent when the status of processes changes or an alert is triggered.

The Webhook registered on the Unico Check portal sends notification for the following statuses:

  • 2 - In divergence
  • 3 - Completed
  • 4 - Canceled
  • 5 - Error
  • For other statuses, notifications are not sent on the Webhook.

When registering a URI to receive webhooks, the Unico Check sends an HTTP request to this URI every time there is a change to an item you have subscribed to receive.

Using: To define a URI to receive webhooks, it is necessary to access the portal and set the configuration through the Configurações > Integração > Webhook.

Important

To use the webhook it is necessary to configure it on the Unico Check portal. his functionality is not used through the API.

Process Status Update Notification: Configure the webhook in according to your specifications and then link it to an API Key through the Configurações > Integração > API Key.

Suspect Person List Update Notification: Configure the webhook in according to your specifications and choose the "Sim" option in the "Notificar alterações de score suspeito" field.

Notice

Only one webhook can be configured to send notifications from a list of suspicious people.

With this feature enabled, a notification is sent whenever a positive score is reclassified to negative, or whenever a negative score is reclassified to positive, or the face is deleted at the owner's request. In case of failure, by default the service is configured to resend the notification at a certain time (defined in the settings). The first attempt occurs right after the event is triggered.

HTTP response status codes

The status codes indicate whether an HTTP request completed correctly. The answers are grouped into the following classes:

  1. Information responses (100- 199)
  2. Successful responses (200 - 299)
  3. Redirects (300 - 399)
  4. Client errors (400 - 499)
  5. Server errors (500 - 599)

HTTP responses with status 2XX or 3XX are interpreted as success and therefore the service does not send the request again.

Granting Credit to Retirees and Pensioners​

This flow is a solution added to the Unico Check in the API return for customers who request the CSs and/or Onboarding team that the SERPRO query information be enabled in the APIKey.

How it works:

The customers send the selfie and the official ID document with the photo (front and back) to Unico Check throungh the message flow.

If the information is not found in SERPRO, the return on serpro similarity is -1.

The government has been added in the API return as follows: 

{
  "HasBiometry": true,
  "Id": "11111111-1111-1111-1111-111111111111",
  "Liveness": 0,
  "Score": 95,
  "Status": 3,
  "OCRCode": 0,
  "FaceMatch": 0,
  "government": {
    "serpro": 0.92
  }
}
Important

  • It is necessary to ask the CSs and/or the Onboarding team for the information to be enabled in the API Key.

  • It's not a new flow or product, but a new return within the Unico Check API.

How to enable SERPRO similarity query in the message flows through the GetMessage::​

To enable the SERPRO similarity score in the message flow, in addition to making geolocation mandatory, follows the steps:

  1. Access the Check Portal;
  2. Access the Templates menu;
  3. Search for the desired template and then click on it to edit or click on Novo template to create a new template;
  4. On the Configuração do SMS screen, in the Consigned field, select the Yes option.

Biometric Token​

The Biometric Token is the best way to authenticate existing customers in your database to transact or access new features in your application/platform.

A check is performed to ensure that the customer performing a certain action is the same who registered using the Authentication Score.

Thus, quickly, with the little friction and with the possibility of reaching a false positive rate of 0.0001% using Smartlive, an information is returned to your application saying if the face sent and the face in the registration correspond to the same person.

Token usage examples​

  • Password recovery;
  • Any process that uses external token (corporate access, logins on websites of banks, brokerages, fintechs, etc.);
  • Unlocking cards;
  • Token installation on devices;
  • Increased transaction limits;
  • Acquisitions of high value products;
  • Payment with private label card;
  • Access to ATMs;
  • Logins to infrequently used applications;
  • Places with access control.

Token flow operation​

Note

For the token to work, it is important that the IDs generated by the CreateProcess method of the Authentication Score are stored in your database. This storage can be done in the same way as the CPF was stored.

The Biometric Token compares the image of a sent face with an existing face in your database.

The Biometric Token flow is divided into 3 steps:

  1. Sending the captured image and the Authentication Score ID​

    The application sends the captured image and the Authentication Score ID, as follows:

    • The captured image is the selfie that the user takes at the time of authentication.
    • The Authentication Score ID is the same as the one obtained when registering the person for the first time. This ID is obtained from the response of the CreateProcess method.

  2. Consistency check​

    Photo quality analysis and authentication score ID validity.

    • Quality of the sent photo: If the photo is not within the standards recommended by Unico, an error message is returned. For more information about the recommended patterns, see the section Capture Pattern.
    • Authentication Score ID Validity: It is checked that the ID format is correct (the same numerical pattern as a valid ID must be followed) and that it has a valid status.
    caution

    Only IDs with the process completed are accepted, therefore, IDs canceled or under analysis are not accepted.

  3. Comparison result​

    Comparison of the uploaded image with an existing image in your database. This comparison returns one of the following responses to your application:

    • True: the compared images correspond to the same person. That is, the person carrying out the transaction is the registered person.
    • False: Images compared do not match the same person. That is, the person carrying out the transaction is not the registered person.

Document classification​

It is a resource that aims to identify that the registered document is actually the informed document. It is a process of classifying documents according to their type.

How to use

  • Capture the image of the document (front and back) with the help of scanning tools (camera, scanner). This capture generates files of the front and back of the document.
  • Register these images in the requested spaces.
  • The classification identifies whether the person registered correctly. The documents that can be typed are CNH, CPF and ID.

OCR​

OCR, Optical Character Recognition, is a tool that converts characters from an image file, such as an image from an RG, CNH and CRM document, into a text document that can be edited.

OCR is also used to extract data from an image file. To do this, this file must have a fixed structure, that is, it must have the same format, such as the CNH (National Driving License).

OCRCode

It is a functionality that makes it possible to extract the CPF described in the document and compare it with the CPF entered.

*How the OCR works**

Below are the operating steps of the tool:

  1. When obtaining the scanned or photographed document, the OCR software analyzes the content and classifies the dark fields as text and the lighter parts as the document background;
  2. Performing image pre-processing;
  3. Character recognition converting document content into real text;
  4. Use of data converted into text to automatically fill in user registration.

Facematch​

Using FaceMatching technology, the photo taken (selfie) is compared with the photo of your identity card or other registered document. The documents for facematch are CNH and ID. So, after this analysis, the authenticity process is carried out by checking similarities in facial features, making it possible to determine whether or not it is the same person.

This feature should not be used alone as it can cause failures. You need to rely on other technologies, such as OCR and Proof of Life with interaction, to bring the necessary security to your business and your customers.

FaceMatch does not use any database for identity validation.

Any concerns?​

Missing something or still need help? If you are already a customer or partner, you can contact us through the Help Center.