Ir para conteúdo principal
Todas as coleçõesDocCheck
Validation of Registration of Bettors
Validation of Registration of Bettors
Vinicius Loanga avatar
Escrito por Vinicius Loanga
Atualizado há mais de 5 meses

Guide for compliance with SPA/MF No. 722 (02/May/2024)

For the minimum compliance with the technical requirements related to the registration of Brazilian bettors, (new and pre-existing), described in SPA/MF No. 722 of May 02, 2024, published in the Diário Oficial da União on May 03, 2024 (DOU- Section 1 - Extra Edition B), Exato Digital recommends the implementation of the procedure below. If you have any questions, please contact our support at: [email protected].

1- At the time of a new registration or login of a user registered before the regulation, request at least the information below, in addition to others necessary/desired by the operator or platform. At this stage, there is still no involvement of Exato Digital and the information is being requested and captured exclusively by the platform.

  • CPF number;

  • Full name, indicating to the user that it must be the same as the on in Receita Federal, without abbreviations;

  • Date of birth, indicating to the user that it must be the same as in Receita Federal;

  • Email address, indicating to the user that it cannot be a temporary email.

  • Mobile phone with area code (Reginal and/or International code included).

2- In the form of the step above, Exato Digital recommends the use of some human interactive proof (captcha) technology, for example hCaptcha and ReCaptcha, thus making it difficult for malicious third parties to robotize registrations;

3- The platform can choose to request the user's CPF and perform the "auto-complete" of the name and date of birth, aiming at agility in the registration. Exato Digital does not recommend this approach, as it makes it easy for the malicious user to use a CPF generator and inform a document that is not theirs, increasing the risk of information theft and also the cost of integration. According to the ordinance in question, this can also be considered irregular as it will skip the step of confirming the data by the user himself. In any case, use the IdentityValidation API, in a server-side way, if the operator/platform still wishes to perform the "auto-complete" - Exato recommends the use of the masked fields returned by the API: FullNameMasked and DateOfBirthMasked to avoid malicious users using the platform to steal information;

4- The platform must carry out a basic validation of the data provided by the user before proceeding with the process, verifying that it is a CPF with valid check digits, according to this JavaScript library example, if the full name has at least two words and two characters in each word (removing white space), if the date of birth is a valid day and if the user is over 18 years old and if the email is in the correct format [An example of logic for email address validation can be found in https://www.w3resource.com/javascript/form/email-validation.php]. These validations can be done server-side or client-side (Javascript), according to the platform's preference. Exato Digital is not yet involved in this step;

5- If the data has passed the basic validation above, make a server-side* call to the IdentityValidation API, passing the CPF, full name, date of birth, email address and IP of the end user (not the IP of the platform), as well as language and security token.

6- Exato Digital's API will check the data provided by the user and return error codes and messages (one or more) that must be interpreted server-side by the platform and displayed to the user (if necessary). Exato will also return a UID of the call, that can be passed on subsequent calls in the process. Examples of possible returns:

  • CPF non-existent;

  • Name does not correspond to the CPF informed. It must be reported as at the Receita Federal;

  • Date of birth does not correspond to the CPF informed. It must be reported as in the Receita Federal;

  • CPF with death;

  • Minor's CPF.

7- Depending on what is agreed with the client, Exato Digital can also validate the user's email to identify if it is a temporary account or if the IP is on a list of proxies or in the desired location (Brazil). These validations are optional, can add some extra time to the final response time, can generate false positives (for example, in the case of VPN use by the user) and make registrations more difficult. Therefore, the operator/platform must decide carefully whether to carry them out or not;

8- If the operator/platform wishes, Exato Digital has APIs for sending SMS/WhatsApp with a security code, so that the users confirms that they are in possession of the mobile number, if this number has been requested in step #1;

9- If the API call in step #6 has returned TransactionResultTypeCode = 1 (Success), the platform must make a server-side call to the DocCheck API, passing the information below, so that the facial validation process with proof of life can be initiated, in addition to the collection of a document. This API call will return a link through which the bettor must initiate the face validation process.

Although possible, Exato Digital does not recommend the use of DocCheck without the previous steps, as this can generate a large additional cost for operators in the case of malicious users, in addition to the impossibility of the platform to collect the initial user data in its own environment/database.

  • Key Id, client's internal code within Exato Digital

  • CPF, previously collected and validated by the IdentityValidation API in step #5

  • External Id, code provided by the client, which can be any code for the client's own control

10- DocCheck can optionally validate the user's face against government bases, in addition to checking against the document informed by the user. However, this has a substantial additional cost, in addition to not fully guaranteeing the match, as it is always done by similarity. If the operator/platform wishes to carry out this additional validation, the account manager must be informed so that he can enable the functionality, in addition to informing the correct parameters;

11- If there is already a validation in the process of being reviewed (by the operator) for the user, the API will return with the code [ REQUER_VALIDACAO_MANUAL], making it impossible for the user to perform a new validation. This is important to prevent trial-and-error abuse by malicious users;

12- By activating the link generated in step #9, the user will be directed to the Exato Digital environment. In this environment, he will be guided through the process of capturing facial images and images of the identification document. This part of the process takes place in the Exata Digital environment, mainly to facilitate integration through the platform, which otherwise would have great development on its side;

13- DocCheck will perform the following validations:

  • A living person came forward to collect the face image;

  • The face of the person who presented himself is compatible with the photo of the person in the document presented;

  • The name, CPF and date of birth present in the document are compatible with the information found for that CPF in the Receita Federal;

  • The user's name is not on restricted lists ( PLDFT /AMLTF report);

Optionally, DocCheck can validate the user's face image and document against government bases (add-on). Exato Digital does not perform documentscopy of the document informed by the user, only automatic OCR;

14 - The DocCheck validation process can be followed through a WebHook URL informed to Exato Digital at the time of registration, or through pooling in the identity validation query endpoint. This endpoint takes as a parameter the value of the document_hmac_hash field returned by the generate URL API referenced in step #9

15- In the webhook request, we send all pertinent information regarding the process, and in the request header, we also send a sha256 hash. The hash is created by concatenating 5 parameters (public_key_id, cpf, identity_validation_id, status, time, secret_key), where the first 4 parameters are from the body of the webhook request, and the fifth one (secret_key) is your the individual secret key. After concatenating these 5 parameters, a sha256 hash is created and sent in the header of the webhook request.

Example:

The webhook request body is:

{

"public_key_id": "a6b1a24c-d60d-451b-b24c-be669564fec3",

"cpf": "26548587073",

"identity_validation_id": "4dcd315b-432b-411e-8aa6-468a4bb3c93f",

"status": "EM_VALIDACAO",

"time": "2024-05-15T16:15:17.1958284-03:00"

}

The hash is created by calling SHA256(“a6b1a24c-d60d-451b-b24c-be669564fec3265485870734dcd315b-432b-411e-8aa6-468a4bb3c93fEM_VALIDACAO2024-05-15T16:15:17.1958284-03:00YOUR_SECRETE_KEY_HERE")

16 - You can also send your own id to be used with the validation by providing the "external_id" field in the message body, The value of this id will be associated with the validation record and will also be used in the WebHook URL, replacing the "EXTERNAL_ID" string if it exists. For example if you provide URL https://my.system/webhook?record=EXTERNAL_ID we will replace the string in the end of the URL by the ID provided by you when initiating the validation process. .

17- Exato Digital's DocCheck never automatically disapproves the user. The user can be approved automatically, within the established tolerances, or sent for review by the operator. In case of review, the operator must make the decision to approve or reject (discard) the user through the Exato Digital control panel.

*Never make client-side calls (Javascript) to Exato Digital's APIs, as this exposes the operator's/platform's access/security token.

Isto respondeu à sua pergunta?