B2B KYC - Process Automation
Create your own B2B KYC using Grut's Actions
Now that you know how to create your custom atomic blocks and workflows, you can create complex projects with our powerfull tool.
Content
Integrate with B2B data provider
Parse response
Build your rules with workflow
Putting all together
Save to your database
Deploy to production
1. Integrate with B2B data provider
For our example, we will use Consulta dados de CNPJ, a produt from ReceitaWS, a free data provider for Business from Brazil.
For that you will need to get to the API's documentation and get the code snippet from the right side.

Go to Grut's Studio and go to create workflow. Start your workflow with built-in action requests-get. Set the parameters inpt_headers and inpt_params with None. Leaver the inpt_url as we will use it later. Mark the checkbox beside the output variables to make them available for other blocks to consume.
Now give name your new block as "consulta-receitaws-free" and save it.
Test your block by running and passing the url for the endpoint.

2. Parse API's response
From Receita WS documentation page, we can check the API's response example.
{
"status": "OK",
"ultima_atualizacao": "2019-08-24T14:15:22Z",
"cnpj": "string",
"tipo": "MATRIZ",
"porte": "string",
"nome": "string",
"fantasia": "string",
"abertura": "string",
"atividade_principal": [
{
"code": "string",
"text": "string"
}
],
"atividades_secundarias": [
{
"code": "string",
"text": "string"
}
],
"natureza_juridica": "string",
"logradouro": "string",
"numero": "string",
"complemento": "string",
"cep": "string",
"bairro": "string",
"municipio": "string",
"uf": "string",
"email": "string",
"telefone": "string",
"efr": "string",
"situacao": "string",
"data_situacao": "string",
"motivo_situacao": "string",
"situacao_especial": "string",
"data_situacao_especial": "string",
"capital_social": "string",
"qsa": [
{
"nome": "string",
"qual": "string",
"pais_origem": "string",
"nome_rep_legal": "string",
"qual_rep_legal": "string"
}
],
"billing": {
"free": true,
"database": true
}
}
We can above to get all values from response as variables or parse only what we really need.
For the purpose of this project we will use Grut's automation to generate the parser. To do so, go to create-dict-to-outputs-workflow built-in Grut's workflow and run it with the following parameters:
inpt_dict_var: our example of response displayed above
inpt_name_process: parse-receitaws
inpt_email: your email/username registred in Grut's Studio
inpt_pwd: your pwssword for Grut's Studio
After your run it, you can check your parser and test it with a valid re Wesponse.
3. Build your rules with workflow
This is the most critical part, where you build the core of our KYC. We recommend you to first draw a flowchart using MIRO or similar tool to save time and get organized before coding it with Grut.
In our example we want to validate some conditions to either approve or denied a company during our KYC process. We will run a basic KYC checking status of the response from receita WS, the company's situation with brazilian IRS and the province of company, where we only want to approve those registered in São Paulo.
We've drawn the following flowchart to represent our KYC process.

Now that we have organized our decision process, we will create a new workflow. Our first block will be our new autogenerated workflow we've created here. We will check the outputs status, situacao and UF as final outputs so we can track the workflow complete response.
Add a second block, select the Gateway option and fill up the fields corresponding with the first Rule (status == 'OK').
Create the blocks for when the above condition is either True or False and you will have something like the image below.

Note that if status == 'OK' we will pass (meaning not doing anithing). If it's false, meaning status != 'OK', we will set the denied reason as "status_consulta|" and continue to check other variables. We will use it later.

Add another gateway for second rule (situacao != 'ATIVA') and fill the blocks corresponding with True and False. Do the same for the third condition (UF != 'SP').




Now that we have all possible flows for our KYC process, we concatenate possible deny reasons using generic-concatenate built-in action and check if it's empty, which means we should deny the KYC process if there are at least one reason for denial. If there are none, we should approve our KYC.
We then save our KYC workflow and test it with a valid example such as the below dict.
{"status": "OK", "situacao": "ATIVA", "uf": "SP"}
We should see a response as follows:
{
"Block 1 - aprovado": True,
"Block 2 - motivo_reprova_situacao": None,
"Block 3 - motivo_reprova_status": None,
"Block 4 - motivo_reprova_uf": None,
"Block 5 - motivos_reprova":"",
"Block 6 - reprovado": None,
"Block 7 - situacao_21":"ATIVA",
"Block 8 - status_23":"OK",
"Block 9 - uf_26":"SP"
}
You should also check if the intire workflow is working properly, validating all situations.
4. Putting all together
Last updated