Os fluxos de verificação (workflows) orquestrados da Didit são a forma mais poderosa e flexível de projetar e implantar jornadas completas de verificação de identidade em várias etapas.
Nesta aula da Didit Academy, você cria um fluxo de verificação no console real, do modelo ao fluxo publicado: escolha das verificações em cada nó, regras e limiares, ramificação de AML, nós de webhook e reversão de versão.
Este caminho de integração permite que você aproveite toda a inteligência da plataforma Didit V2, criando sequências de verificação sofisticadas com nosso construtor visual no-code. Você define a lógica uma única vez no seu Business Console, e a Didit cuida de toda a experiência do usuário, do gerenciamento de estado e das etapas condicionais.
Escolha este caminho quando precisar de uma solução completa, de ponta a ponta, para onboarding de usuários (KYC), verificação de idade ou reautenticação, e quiser lançar rapidamente com o mínimo de esforço de desenvolvimento, mantendo o máximo de controle sobre o processo.
Métodos de identificação por país
Em Verificação de identidade, abra Países e métodos de identificação permitidos para configurar a captura de documentos, a consulta sem documento e as carteiras de identidade digital para cada país.
Configurações adicionais contém os subtipos de documento, as tentativas de consulta e as regras de fallback.
A consulta sem documento usa os preços do serviço de Validação de banco de dados da sua organização.
Cada tentativa concluída é cobrada separadamente, incluindo correspondências parciais e ausência de correspondência: duas tentativas concluídas significam duas cobranças.
Erros de formato e falhas do provedor que não retornam resposta não são cobrados.
Se vários serviços de banco de dados responderem a uma tentativa, os preços aplicáveis desses serviços são somados.
O padrão é uma tentativa antes do fallback, configurável de uma a cinco.
A captura de documentos é cobrada adicionalmente quando uma consulta concluída recorre aos documentos como fallback.
Aplicações de produção só podem ativar carteiras disponíveis para produção.
Carteiras aguardando lançamento permanecem desativadas.
Aplicações de sandbox podem testar todas as carteiras do catálogo com resultados simulados; a disponibilidade no sandbox não indica disponibilidade em produção.
Consulte Testes em sandbox para ver cenários de falha de consulta e de carteira.
Versionamento de fluxos
Os fluxos oferecem versionamento com rascunho e publicação. Isso significa que você pode iterar com segurança no seu fluxo sem afetar as sessões ativas:
- Versões de rascunho são totalmente editáveis: adicione, remova ou reestruture nós livremente
- Ao publicar um rascunho, você cria uma versão imutável que as novas sessões usarão
- Versões anteriores são preservadas, para que você possa inspecionar a configuração exata usada em qualquer sessão passada
- As sessões sempre fazem referência à versão específica com a qual foram criadas, garantindo consistência mesmo depois que você publica atualizações
Para alterar um fluxo publicado, crie um novo rascunho a partir da versão publicada, edite-o e publique quando estiver pronto. O histórico de versões está disponível pela Management API.
A Didit oferece duas abordagens distintas para criar fluxos de verificação, para que você escolha o nível de complexidade adequado às suas necessidades:
1. Modo simples: construtor baseado em modelos
O Modo simples é ideal para começar rapidamente. Selecione um modelo pronto, ative ou desative os recursos de que você precisa e pronto.
Ideal para:
- Configuração e implantação rápidas
- Fluxos de verificação padrão
- Equipes que estão começando com verificação de identidade
- Casos de uso que seguem padrões comuns
Como funciona:
- Escolha um modelo de fluxo (KYC, Verificação de idade etc.)
- Ative ou desative recursos (Prova de vida, Correspondência facial, AML etc.)
- Defina as configurações básicas de cada recurso
- Publique e comece a verificar
2. Modo avançado: construtor visual de grafos
O Modo avançado libera todo o potencial do motor de orquestração da Didit. Crie fluxos de verificação complexos e condicionais com nosso editor visual de grafos, com nós de arrastar e soltar, ramificações e lógica personalizada.
Ideal para:
- Jornadas de verificação complexas, com vários caminhos
- Lógica condicional baseada em dados do usuário ou em resultados da verificação
- Regras de negócio e ramificações personalizadas
- Requisitos de conformidade de nível corporativo
Principais recursos:
- Editor visual de nós: arraste, solte e conecte nós em uma tela infinita
- Conexões inteligentes: arraste a partir da alça de um nó até um espaço vazio para criar e conectar um novo nó na hora
- Ramificações condicionais: direcione usuários com base em dados extraídos, status da verificação, país, tipo de documento, subtipo de documento, data de emissão, idade, caminhos da resposta JSON de um webhook ou regras personalizadas
- Automação de ações: adicione tags, defina metadados ou encaminhe para revisão manual com base nos resultados do fluxo
- Atalhos de teclado: Desfazer (Ctrl/Cmd+Z), Refazer (Ctrl/Cmd+Shift+Z), Excluir (Delete/Backspace)
- Zoom e deslocamento: navegue por fluxos complexos rolando para dar zoom e arrastando para deslocar
Tipos de nós do construtor de grafos
Categorias de nós de recurso
Recursos interativos para o usuário (podem iniciar um fluxo):
- Verificação de identidade (OCR)
- Prova de vida
- Correspondência facial
- Estimativa de idade
- Verificação de telefone
- Verificação de e-mail
- Questionário
- Comprovante de endereço
- Document AI
- NFC / ePassport
Recursos somente de backend (executados automaticamente, sem interação do usuário):
- Análise AML (precisa de uma etapa de Verificação de identidade, KYB Registry ou Document AI antes dela; consulte Entidade analisada)
- Validação de banco de dados (exige OCR antes)
- Análise de dispositivo e IP
Observação: os recursos somente de backend são marcados com um indicador especial no construtor e são executados automaticamente, sem interação do usuário, assim que suas dependências são atendidas.
A primeira aba de configuração de cada nó de recurso começa com um controle Motor de verificação: execute a verificação com o motor próprio da Didit ou troque para um provedor terceirizado que você conecta pelo Marketplace, com fallback automático para a Didit caso esse provedor esteja indisponível.
Entidade analisada
Normalmente, a Análise AML descobre quem analisar a partir da etapa anterior: a pessoa cujos dados uma etapa de Verificação de identidade leu em um documento ou a empresa que uma etapa de KYB Registry retornou. Alguns fluxos não têm nenhuma das duas. Um fluxo construído inteiramente com Document AI (documentos não padronizados, como uma certidão fiscal ou um ato constitutivo autenticado em cartório) já contém o nome, a data de nascimento, o número do documento e o país, só que sob as suas próprias chaves de campo.
É na aba Avançado do nó de AML que você vincula essas chaves à análise:
- Tipo de entidade: analise uma pessoa ou a empresa citada em um documento enviado. Um nó de empresa pesquisa registros de empresas, e não de pessoas.
- Origens dos campos: mapeie cada um dos quatro dados de entrada da análise (nome, data de nascimento, país, número do documento) para um campo do Document AI, uma resposta de questionário ou um valor que você envia na criação da sessão (
expected_details / metadata). Um campo do Document AI que você já nomeou como full_name é reconhecido automaticamente.
- Dados de triagem incompletos: o que acontece quando a análise é executada com menos do que uma identidade completa. A revisão é o padrão; escolha Nenhuma ação somente quando o fluxo, de forma consciente, não contém nada além de um nome.
Há duas coisas que vale saber antes de depender disso. Sem uma etapa de Verificação de identidade ou de KYB Registry, o nome é obrigatório: o fluxo não pode ser publicado até que algo o preencha, porque não há busca sem nome. Além disso, a precisão da AML depende diretamente de quantos identificadores você fornece. Uma triagem feita só pelo nome é o que gera o volume de falsos positivos de que os revisores reclamam, por isso mapeie a data de nascimento e o país sempre que o documento os trouxer.
Como as condições de ramificação leem os dados da sessão
Qual registro uma condição lê. Uma condição de ramificação fica vinculada ao nó de recurso a partir do qual foi criada e lê o resultado desse nó. Quando um único nó produz mais de um registro, a condição lê o mais recente. Isso é especialmente importante na Análise de dispositivo e IP: a Didit registra uma observação para cada dispositivo e endereço IP a partir do qual uma sessão é aberta. Assim, um usuário que troca de celular ou de rede no meio da sessão deixa vários registros no mesmo nó. Uma regra como IP COUNTRY is in [...] é então avaliada com base na observação mais recente, que é o mesmo registro exibido primeiro no painel Análise de dispositivo e IP da sessão e no array ip_analyses do payload da decisão. Sessões com mais de uma observação também trazem o aviso MULTIPLE_DEVICES_IN_SESSION, que é o sinal para revisar a lista completa em vez de olhar apenas o resultado da ramificação.
Valores de país. As condições de país são comparadas pelo país em si, e não pela notação. Escolha os países no seletor de campos e a Didit normaliza os dois lados da comparação. Assim, uma regra escrita em ISO 3166-1 alfa-3 (UKR) ainda corresponde a um valor capturado em alfa-2 (UA).
Valores ausentes, valores vazios e comparações negativas. Um campo sem nenhum valor (o documento não o traz, a chave de metadados não foi enviada, o recurso não foi executado) corresponde apenas a is empty e equals not_defined. Todas as outras comparações, como equals, contains e greater than, e também not equals e not in, não correspondem, e o nó de ramificação passa para a próxima ramificação. Um campo que contém uma string vazia tem um valor, e não é um campo ausente: uma sessão criada com "metadata": {"credential_state": ""} não atende a metadata.credential_state equals IL, mas atende a not equals IL, not in [IL, MA, NJ] e equals "" (is empty corresponde aos dois casos). Por isso, uma ramificação que aprova com base em uma comparação negativa aprova uma sessão cujo estado foi enviado vazio, enquanto a mesma sessão sem a chave segue para o fallback. Quando você rotear com not equals ou not in, adicione metadata.<key> is not empty à mesma ramificação (lógica AND), para que os dois casos terminem onde um valor ausente deveria terminar. As ramificações são avaliadas em ordem e a primeira correspondência vence. A ramificação de fallback (a ramificação sem condições) é seguida somente quando nenhuma outra ramificação corresponde, por isso dê a todo nó de ramificação um fallback que termine onde você quer que um valor inesperado termine. Uma sessão que chega a Em revisão sem aviso em nenhum recurso foi encaminhada para lá por um nó de status no grafo, e não por uma verificação. A causa mais comum é a ramificação de fallback de um nó de ramificação.
Metadados da sessão. Os valores que você envia em metadata na criação da sessão ficam disponíveis para todas as ramificações como metadata.<key> e podem ser comparados com um valor fixo ou com outro campo da sessão (por exemplo, metadata.min_age <= Age). Números são comparados como números, então 18 e "18" se comportam da mesma forma.
Sandbox / modo de teste. Condições de ramificação, metadados e nós de status funcionam no sandbox exatamente como em produção, e o sandbox nunca coloca uma sessão em revisão por conta própria. A diferença está no documento: uma sessão de sandbox traz um documento fictício sem estado ou região dos EUA, então as condições de Region não podem corresponder ali. Veja o que o documento fictício não traz para saber como testar fluxos que dependem do estado.
Reenvios. Os nós de ramificação são avaliados em todas as tentativas, inclusive em um reenvio. Quando você devolve uma sessão para etapas específicas, as ramificações e ações posicionadas entre essas etapas são executadas novamente à medida que o usuário as conclui de novo, com base nos dados da nova tentativa. Assim, um usuário que se muda para uma jurisdição restrita entre uma tentativa e outra é encaminhado pela ramificação que cobre essa jurisdição, e uma ramificação que termina em um resultado Recusado encerra ali a sessão reenviada.
Como ver qual ramificação uma sessão seguiu. Cada decisão de ramificação que o fluxo toma durante a execução de uma sessão, e cada nó de resultado que ele alcança, fica registrado na linha do tempo de eventos da sessão (detalhe da sessão no Console > Events, e GET /v3/session/{id}/decision/?include=events). Uma linha Roteamento do fluxo indica o nó de ramificação, a condição que correspondeu e o nó para o qual a sessão seguiu, ou informa que nenhuma condição correspondeu e que a conexão de fallback do nó foi seguida. Uma linha Resultado do fluxo indica o nó de status que definiu o status da sessão. Quando um fluxo envia uma sessão para Em revisão sem que nenhum recurso a tenha sinalizado, essas linhas mostram o caminho percorrido, incluindo qualquer conexão de fallback e o nó de resultado ao qual ela levou. Decisões manuais posteriores não reescrevem esses eventos do fluxo. A falta de dados de entrada é uma causa possível: condições que exigem um valor metadata.* presente não correspondem quando a chave foi omitida na criação da sessão. Condições que testam explicitamente a ausência de dados de entrada, como is_empty ou equals com not_defined, podem corresponder a essa mesma chave ausente. A conexão de fallback é seguida somente quando nenhuma ramificação corresponde, incluindo qualquer ramificação else, e leva ao nó conectado à saída padrão. Veja eventos de sessão para conhecer os payloads dos eventos.
Modelos de fluxo de verificação: seu ponto de partida
Pense nos modelos não como tipos rígidos, mas como pontos de partida inteligentes e pré-configurados, criados para casos de uso comuns. No Modo Simples, eles estão prontos para uso. No Modo Avançado, oferecem uma base que você pode personalizar amplamente.
Modelos disponíveis
1. Fluxo de verificação (workflow) de KYC
A solução completa para fazer o onboarding de novos usuários e atender a todos os requisitos de conformidade de Know Your Customer (KYC).
- Começa com: verificação do documento de identidade principal.
- Recursos adicionados com frequência:
[+] Prova de vida: garante que o usuário esteja fisicamente presente e evita spoofing.[+] Correspondência facial 1:1: compara biometricamente a selfie do usuário com a foto do documento de identidade.[+] Análise AML: verifica os usuários em listas globais de sanções, de PEP e de mídia adversa.[+] Verificação NFC: adiciona uma camada de segurança de nível governamental com a leitura dos chips de passaportes e documentos de identidade eletrônicos.[+] Comprovante de endereço (PoA): verifica o endereço residencial do usuário.[+] Verificação de telefone: valida a titularidade do número de telefone como fator adicional.[+] Verificação de e-mail: valida a titularidade do endereço de e-mail como fator adicional.[+] Validação de banco de dados: valida os dados em relação a bancos de dados oficiais do governo e de crédito.[+] Questionário: coleta atestações estruturadas e documentos comprobatórios por meio de formulários personalizáveis.[+] Análise de dispositivo e IP: analisa o risco da localização e da conexão.
2. Fluxo de verificação de idade adaptativa
Um fluxo de baixo atrito, que preserva a privacidade, para serviços com restrição de idade.
- Começa com: estimativa de idade baseada em selfie.
- Lógica principal:
- Se a idade estimada estiver claramente acima do seu limiar (por exemplo, 25+ estimados para um serviço 18+), o usuário é aprovado instantaneamente.
- Se a estimativa estiver abaixo ou dentro de uma “zona de margem” (por exemplo, de 16 a 20 anos estimados), você pode configurar o fluxo para acionar automaticamente um fallback para a verificação de identidade completa e confirmar a data de nascimento exata.
- Recursos adicionados com frequência:
[+] Análise de dispositivo e IP: restringe o acesso com base na localização geográfica.
3. Fluxo de autenticação biométrica
Uma forma rápida e segura de reverificar usuários recorrentes sem pedir seus documentos novamente.
- Começa com: uma verificação de prova de vida para confirmar que o usuário está presente.
- Lógica principal:
- O sistema realiza uma correspondência facial entre a nova selfie ao vivo e o template biométrico confiável da verificação KYC inicial e aprovada do usuário.
- Se o usuário já tiver um rosto armazenado associado ao mesmo
vendor_data (rosto aprovado na prova de vida, foto do passaporte eletrônico, retrato do documento de identidade ou um rosto de perfil cadastrado), você pode omitir portrait_image ao criar a sessão, e a Didit reutiliza o rosto armazenado automaticamente. Caso contrário, envie portrait_image (imagem codificada em Base64, no máximo 2MB); sem nenhum dos dois, a criação da sessão falha com 400.
- Recursos adicionados com frequência:
[+] Verificação de telefone: vincula o endereço a um número de telefone verificado.[+] Verificação de e-mail: valida a titularidade do endereço de e-mail como fator adicional.[+] Análise de dispositivo e IP: sinaliza tentativas de login suspeitas a partir de novas localizações.
4. Fluxo de verificação de endereço
Um fluxo dedicado para quando o comprovante de endereço (PoA) é o requisito principal.
- Começa com: o envio, pelo usuário, de um documento de comprovante de endereço (por exemplo, conta de consumo, extrato bancário).
- Lógica principal: nossa IA extrai e valida o nome e o endereço do documento.
- Recursos adicionados com frequência:
[+] Verificação de telefone: vincula o endereço a um número de telefone verificado.[+] Verificação de e-mail: valida a titularidade do endereço de e-mail como fator adicional.[+] Análise de dispositivo e IP: compara o endereço do documento com a geolocalização atual do usuário para maior segurança.
5. Fluxo de verificação por questionário
Um fluxo focado para quando seu objetivo principal é coletar atestações estruturadas e documentos comprobatórios por meio de formulários personalizáveis.
- Começa com: questionário.
- Lógica principal: o sistema apresenta o questionário que você configurou (seções, conteúdo traduzido, campos obrigatórios, uploads).
- Recursos adicionados com frequência:
[+] Análise de dispositivo e IP: adiciona contexto de localização e conexão aos envios do questionário.
Personalização completa
Cada recurso de um fluxo pode ser personalizado ainda mais com parâmetros específicos para atender exatamente aos seus requisitos. Explore as configurações de cada verificação no editor.
No Modo Avançado, você pode usar o campo de OCR kyc.marital_status em ramificações condicionais e em regras de status personalizadas. Escolha o valor no seletor de campos para que a regra use o enum compatível em vez de texto livre. Se o documento não informar o estado civil, o valor fica vazio e a sua ramificação de fallback é aplicada.
O copiloto de fluxos também pode criar e configurar etapas de Database Validation em uma única ação. Ao pedir que ele adicione essa verificação, especifique os países de que você precisa; o console identifica o serviço compatível para cada país e mostra a configuração salva no canvas.
Comparação entre o Modo Simples e o Modo Avançado
Fluxo de integração
Integrar um fluxo orquestrado é simples. Seu servidor cria uma sessão na Didit, recebe uma URL única e redireciona o usuário para essa URL. A Didit cuida do restante e notifica seu servidor sobre os resultados por meio de webhooks.
Casos de uso comuns
| Caso de uso | Modelo recomendado | Modo recomendado | Recursos sugeridos |
|---|
| Verificação de identidade básica | KYC | Simples | Prova de vida, Correspondência facial |
| Onboarding de alta segurança | KYC | Avançado | NFC, Prova de vida, Correspondência facial, AML, Verificação de telefone |
| Conteúdos e serviços com restrição de idade | Verificação de idade adaptativa | Simples | Verificação de identidade como alternativa |
| Autenticação de usuários recorrentes | Autenticação biométrica | Simples | Análise de dispositivo e IP |
| Verificação de endereço | Comprovante de endereço | Simples | Verificação de telefone |
| Onboarding em serviços financeiros | KYC | Avançado | Prova de vida, Correspondência facial, Comprovante de endereço, AML, Validação de banco de dados |
| Conformidade específica por região | KYC | Avançado | Roteamento condicional por país, verificações diferentes por região |
| Verificação baseada em risco | KYC | Avançado | Ramificações condicionais baseadas em pontuações de risco, caminhos de escalonamento |
Primeiros passos
- É novo na Didit? Comece com o Modo Simples e um modelo pronto
- Precisa de personalização? Mude para o Modo Avançado para adicionar lógica condicional
Entre em contato com nossa equipe de vendas para discutir configurações personalizadas de fluxo de trabalho ou para receber orientação sobre a melhor configuração para os seus requisitos específicos.
Última modificação em 1 de novembro de 2026
Primeiros passos
Integração / SDKs
Verificação de usuários
Verificação de empresas
Monitoramento de transações
Registro de alterações
