Os Orchestrated Workflows da Didit são a forma mais poderosa e flexível de conceber e publicar jornadas de verificação de identidade completas e com várias etapas.
Esta lição da Didit Academy cria um fluxo de verificação na consola real, desde o modelo até ao fluxo publicado: escolha de verificações em cada nó, regras e limiares, ramificação AML, nós de webhook e reversão de versões.
Este caminho de integração permite-lhe tirar partido de toda a inteligência da plataforma Didit V2, criando sequências de verificação sofisticadas com o nosso construtor visual sem código. Defina a lógica uma única vez na Business Console, e a Didit trata de toda a experiência do utilizador final, da gestão de estados e dos passos condicionais.
Escolha este caminho quando precisar de uma solução completa e de ponta a ponta para o onboarding de utilizadores (KYC), a verificação de idade ou a reautenticação, e quiser lançar rapidamente, com um esforço de desenvolvimento mínimo, mantendo o máximo controlo sobre o processo.
Métodos de identificação por país
Na 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 de cada país.
Definiçõ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 base de dados da sua organização.
Cada tentativa concluída é cobrada separadamente, incluindo correspondências parciais e sem correspondências: duas tentativas concluídas significam duas cobranças.
Erros de formato e falhas do fornecedor que não devolvem resposta não são cobrados.
Se vários serviços de base de dados responderem a uma tentativa, os respetivos preços aplicáveis são somados.
O valor predefinido é uma tentativa antes do fallback, configurável de uma a cinco.
A captura de documentos é cobrada à parte quando uma consulta concluída recorre aos documentos.
As aplicações em ambiente de produção só podem ativar carteiras disponíveis para produção.
As carteiras que aguardam lançamento permanecem desativadas.
As aplicações em sandbox podem testar todas as carteiras do catálogo com resultados simulados; a disponibilidade em sandbox não indica disponibilidade em produção.
Consulte Testes em sandbox para os cenários de falha de consulta e de carteira.
Versionamento de fluxos
Os fluxos suportam versionamento de rascunho/publicação. Isto significa que pode iterar o seu fluxo com segurança, sem afetar as sessões em produção:
- As versões em rascunho são totalmente editáveis: pode adicionar, remover ou reestruturar nós livremente
- A publicação de um rascunho cria uma versão imutável que as novas sessões vão usar
- As versões anteriores são preservadas, para que possa consultar a configuração exata usada em qualquer sessão passada
- As sessões referenciam sempre a versão específica com que foram criadas, garantindo consistência mesmo depois de publicar atualizações
Para alterar um fluxo publicado, crie um novo rascunho a partir da versão publicada, edite-o e publique-o quando estiver pronto. O histórico de versões está disponível através da Management API.
A Didit oferece duas abordagens distintas para criar fluxos de verificação, para que possa escolher o nível de complexidade que melhor se adapta às suas necessidades:
1. Modo simples: criador baseado em modelos
O Modo simples é ideal para começar rapidamente. Selecione um modelo pré-definido, ative ou desative as funcionalidades de que precisa e está pronto a avançar.
Ideal para:
- Configuração e implementação rápidas
- Fluxos de verificação padrão
- Equipas sem experiência em verificação de identidade
- Casos de utilização que seguem padrões comuns
Como funciona:
- Escolha um modelo de fluxo (KYC, verificação de idade, etc.)
- Ative ou desative funcionalidades (prova de vida, correspondência facial, AML, etc.)
- Configure as definições básicas de cada funcionalidade
- Publique e comece a verificar
2. Modo avançado: criador de grafos visuais
O Modo avançado desbloqueia todo o potencial do motor de orquestração da Didit. Crie fluxos de verificação complexos e condicionais com o nosso editor visual de grafos, com nós arrastáveis, ramificações e lógica personalizada.
Ideal para:
- Percursos de verificação complexos e com vários caminhos
- Lógica condicional baseada nos dados do utilizador ou nos resultados da verificação
- Regras de negócio personalizadas e ramificações
- Requisitos de conformidade de nível empresarial
Principais capacidades:
- Editor visual de nós: arraste, largue e ligue nós numa tela infinita
- Ligações inteligentes: arraste a partir do ponto de ligação de um nó para um espaço vazio para criar e ligar um novo nó de imediato
- Ramificações condicionais: encaminhe os utilizadores com base nos dados extraídos, no estado da verificação, no país, no tipo de documento, no subtipo de documento, na data de emissão, na idade, nos caminhos da resposta JSON do webhook ou em regras personalizadas
- Automatização de ações: adicione etiquetas, defina metadados ou encaminhe para revisão manual com base nos resultados do fluxo
- Atalhos de teclado: anular (Ctrl/Cmd+Z), refazer (Ctrl/Cmd+Shift+Z), eliminar (Delete/Backspace)
- Zoom e deslocação: navegue por fluxos complexos utilizando a roda do rato para fazer zoom e arrastando para se deslocar
Tipos de nós do criador de grafos
Categorias de nós de funcionalidades
Funcionalidades interativas com o utilizador (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
- Comprovativo de morada
- Document AI
- NFC / ePassport
Funcionalidades apenas de backend (executam-se automaticamente, sem interação do utilizador):
- Triagem AML (precisa de um passo de verificação de identidade, de registo de empresas KYB ou de Document AI antes dele; veja Entidade sujeita à triagem)
- Validação de base de dados (requer primeiro OCR)
- Análise de dispositivo e IP
Nota: As funcionalidades apenas de backend são assinaladas com um indicador especial no criador e são executadas automaticamente, sem interação do utilizador, assim que as suas dependências estiverem cumpridas.
O primeiro separador de configuração de cada nó de funcionalidade começa com o controlo Motor de verificação: execute a verificação com o motor próprio da Didit ou mude para um fornecedor de terceiros ao qual se ligue através do Marketplace, com recurso automático à Didit caso esse fornecedor esteja indisponível.
Entidade sujeita à triagem
A Triagem AML normalmente aprende quem vai ser analisado a partir do passo que a antecede: a pessoa que um passo de Verificação de identidade identificou a partir de um documento, ou a empresa que um passo de Registo KYB devolveu. Alguns fluxos não têm nenhum dos dois. Um fluxo construído inteiramente com Document AI (documentos não normalizados, como um certificado fiscal ou uma escritura de constituição notarial) já tem o nome, a data de nascimento, o número do documento e o país, mas sob as suas próprias chaves de campo.
O separador Avançado do nó AML é onde aponta essas chaves para a triagem:
- Tipo de entidade: analise uma pessoa ou a empresa indicada num documento carregado. Um nó de empresa pesquisa registos de empresas e não pessoas.
- Origens dos campos: associe cada uma das quatro entradas da triagem (nome, data de nascimento, país, número do documento) a um campo do Document AI, a uma resposta de questionário ou a um valor que envie na criação da sessão (
expected_details / metadata). Um campo do Document AI ao qual já tenha atribuído o nome full_name é reconhecido automaticamente.
- Dados de triagem incompletos: o que acontece quando a triagem é executada com menos do que uma identidade completa. A revisão manual é a predefinição; escolha Nenhuma ação apenas quando souber que o fluxo só dispõe de um nome.
Há duas coisas a saber antes de confiar nisto. Sem um passo de Verificação de identidade ou KYB Registry, o nome é obrigatório - o fluxo não pode ser publicado até que algo o preencha, porque não existe pesquisa sem nome. E a precisão da triagem AML depende diretamente do número de identificadores que fornece: uma triagem apenas com o nome é o que gera o volume de falsos positivos de que os revisores se queixam, por isso mapeie a data de nascimento e o país sempre que o documento os incluir.
Como as condições de ramificação leem os dados da sessão
Qual o registo que uma condição lê. Uma condição de ramificação está associada ao nó de funcionalidade a partir do qual foi criada e lê o resultado desse nó. Quando um único nó produziu mais do que um registo, a condição lê o mais recente. Isto é mais relevante para a Análise de dispositivo e IP: a Didit regista uma observação por cada dispositivo e endereço IP a partir dos quais uma sessão é aberta, por isso um utilizador que muda de telemóvel ou de rede a meio da sessão deixa vários registos no mesmo nó. Uma regra como IP COUNTRY is in [...] é então avaliada contra a observação mais recente - o mesmo registo que aparece primeiro no painel Análise de dispositivo e IP da sessão e no array ip_analyses do payload da decisão. As sessões com mais do que uma observação também apresentam o aviso MULTIPLE_DEVICES_IN_SESSION, que é o sinal para rever a lista completa em vez de olhar apenas para o resultado da ramificação.
Valores de país. As condições de país são comparadas com o próprio país, não com a notação. Escolha os países no seletor de campos e a Didit normaliza os dois lados da comparação, por isso uma regra escrita em ISO 3166-1 alpha-3 (UKR) continua a corresponder a um valor capturado em alpha-2 (UA).
Valores em falta, valores vazios e comparações negativas. Um campo sem qualquer valor (o documento não o inclui, a chave de metadados não foi enviada, a funcionalidade não foi executada) só corresponde a is empty e equals not_defined; todas as outras comparações - equals, contains, greater than, e também not equals e not in - não correspondem, e o nó de ramificação avança para o seu ramo seguinte. Um campo que tem uma cadeia de caracteres vazia é um valor, não um campo em falta: uma sessão criada com "metadata": {"credential_state": ""} não cumpre metadata.credential_state equals IL, mas cumpre not equals IL, not in [IL, MA, NJ] e equals "" (is empty corresponde a ambos os casos). Um ramo que aprova com base numa comparação negativa aprova, por isso, uma sessão cujo estado foi enviado vazio, enquanto a mesma sessão sem a chave segue para o ramo por defeito. Quando encaminhar com not equals ou not in, acrescente metadata.<key> is not empty ao mesmo ramo (lógica AND) para que ambos os casos terminem onde deve terminar um valor ausente. Os ramos são avaliados por ordem e o primeiro que corresponder ganha; o ramo por defeito (o ramo sem condições) só é seguido quando nenhum outro ramo correspondeu, por isso dê a cada nó de ramificação um ramo por defeito que termine onde pretende que termine um valor inesperado. Uma sessão que chega a Em análise sem aviso em nenhuma funcionalidade foi encaminhada para lá por um nó de estado do grafo, e não por uma verificação; o ramo por defeito de um nó de ramificação é a causa mais comum.
Metadados da sessão. Os valores que envia em metadata na criação da sessão ficam disponíveis em todos os ramos como metadata.<key> e podem ser comparados com um valor fixo ou com outro campo da sessão (por exemplo metadata.min_age <= Age). Os números são comparados como números, por isso 18 e "18" comportam-se da mesma forma.
Sandbox / modo de teste. As condições de ramificação, os metadados e os nós de estado funcionam no sandbox exatamente como em produção, e o sandbox nunca coloca uma sessão em análise por si só. A diferença está no documento: uma sessão de sandbox tem um documento fictício sem estado / região dos EUA, por isso as condições de Region não podem corresponder aí. Consulte o que o documento fictício não inclui para saber como testar fluxos dependentes do estado.
Reenvios. Os nós de ramificação são avaliados em cada tentativa, incluindo um reenvio. Quando devolve uma sessão para passos específicos, os ramos e as ações colocados entre esses passos são executados novamente à medida que o utilizador volta a concluir esses passos, com base nos dados da nova tentativa. Um utilizador que se muda para uma jurisdição restrita entre tentativas é, por isso, encaminhado pelo ramo que a abrange, e um ramo que termina num resultado de Recusada também termina aí a sessão reenviada.
Como ver o ramo que uma sessão seguiu. Cada decisão de ramificação que o fluxo toma enquanto uma sessão está a correr, e cada nó de resultado que atinge, ficam registados no histórico de eventos da sessão (Detalhe da sessão na consola > Eventos, e GET /v3/session/{id}/decision/?include=events). Uma linha Encaminhamento do fluxo indica o nó de ramificação, a condição que correspondeu e o nó para o qual a sessão prosseguiu - ou indica que nenhuma condição correspondeu e que foi seguida a aresta por defeito do nó. Uma linha Resultado do fluxo indica o nó de estado que definiu o estado da sessão. Quando um fluxo envia uma sessão para Em análise sem que nenhuma funcionalidade a sinalize, essas linhas mostram o percurso seguido, incluindo qualquer aresta por defeito e o nó de resultado a que conduziu. As decisões manuais posteriores não reescrevem esses eventos do fluxo. A falta de dados de entrada é uma causa possível: as condições que exigem um valor metadata.* presente não correspondem quando a chave foi omitida na criação da sessão. As condições que testam explicitamente a ausência de dados, como is_empty ou equals com not_defined, podem corresponder a essa mesma chave ausente. A aresta por defeito só é seguida quando nenhum ramo corresponde, incluindo qualquer ramo else, e conduz ao nó ligado à saída por defeito. Consulte eventos da sessão para ver os payloads dos eventos.
Modelos de fluxo: o seu ponto de partida
Pense nos modelos não como tipos rígidos, mas como pontos de partida inteligentes e pré-configurados, concebidos para casos de utilização comuns. No modo Simples, estão prontos a usar. No modo Avançado, oferecem uma base que pode personalizar em grande medida.
Modelos disponíveis
1. Fluxo KYC
A solução completa para o onboarding de novos utilizadores e para cumprir integralmente os requisitos de conhecimento do cliente (KYC).
- Começa com: Verificação de documento de identidade principal.
- Funcionalidades frequentemente adicionadas:
[+] Prova de vida: Garanta que o utilizador está fisicamente presente e evite spoofing.[+] Correspondência facial 1:1: Compare biometricamente a selfie do utilizador com a foto do seu documento de identidade.[+] Triagem AML: Verifique os utilizadores em relação às listas globais de sanções, PEP e notícias adversas.[+] Verificação NFC: Acrescente uma camada de segurança de nível governamental, lendo os chips de passaportes eletrónicos e cartões de identidade eletrónicos.[+] Comprovativo de morada (PoA): Verifique a morada de residência do utilizador.[+] Verificação de telefone: Valide a titularidade do número de telefone como fator adicional.[+] Verificação de e-mail: Valide a titularidade do endereço de e-mail como fator adicional.[+] Validação de base de dados: Valide com bases de dados oficiais do governo e de crédito.[+] Questionário: Recolha declarações estruturadas e documentos de apoio através de formulários personalizáveis.[+] Análise de dispositivo e IP: Analise o risco de localização e de ligação.
2. Fluxo adaptativo de verificação de idade
Um fluxo de baixo atrito e que preserva a privacidade, para serviços com restrição de idade.
- Começa com: Estimativa de idade com base em selfie.
- Lógica principal:
- Se a idade estimada estiver claramente acima do seu limiar (por exemplo, idade estimada de 25+ para um serviço 18+), o utilizador passa de imediato.
- Se a estimativa estiver abaixo ou dentro de uma “zona de margem” (por exemplo, idade estimada entre 16 e 20), pode configurar o fluxo para acionar automaticamente um fallback para a verificação de identidade completa, a fim de confirmar a data de nascimento exata.
- Funcionalidades frequentemente adicionadas:
[+] Análise de dispositivo e IP: Restrinja o acesso com base na localização geográfica.
3. Fluxo de autenticação biométrica
Uma forma rápida e segura de voltar a verificar utilizadores recorrentes, sem lhes pedir novamente os documentos.
- Começa com: Uma verificação de prova de vida para confirmar que o utilizador está presente.
- Lógica central:
- O sistema efetua uma correspondência facial entre a nova selfie em direto e o template biométrico de confiança da verificação KYC inicial aprovada do utilizador.
- Se o utilizador já tiver um rosto armazenado sob o mesmo
vendor_data (rosto da prova de vida aprovada, foto do passaporte eletrónico, retrato do documento de identidade ou um rosto de perfil registado), pode omitir portrait_image ao criar a sessão, e o Didit reutiliza automaticamente o rosto armazenado. Caso contrário, envie portrait_image (imagem codificada em Base64, máximo de 2 MB); sem nenhum dos dois, a criação da sessão falha com 400.
- Funcionalidades frequentemente adicionadas:
[+] Verificação de telefone: Associe a morada a um número de telefone verificado.[+] Verificação de e-mail: Valide a titularidade do endereço de e-mail como fator adicional.[+] Análise de dispositivo e IP: Assinale tentativas de início de sessão suspeitas a partir de novas localizações.
4. Fluxo de verificação de morada
Um fluxo dedicado para quando o comprovativo de morada (PoA) é o requisito principal.
- Começa com: O utilizador envia um comprovativo de morada (por exemplo, fatura de serviços públicos ou extrato bancário).
- Lógica central: A nossa IA extrai e valida o nome e a morada do documento.
- Funcionalidades frequentemente adicionadas:
[+] Verificação de telefone: Associe a morada a um número de telefone verificado.[+] Verificação de e-mail: Valide a titularidade do endereço de e-mail como fator adicional.[+] Análise de dispositivo e IP: Compare a morada do documento com a geolocalização atual do utilizador para maior garantia.
5. Fluxo de verificação por questionário
Um fluxo focado, para quando o seu objetivo principal é recolher declarações estruturadas e documentos de apoio através de formulários personalizáveis.
- Começa com: Questionário.
- Lógica central: O sistema apresenta o questionário configurado (secções, conteúdo traduzido, campos obrigatórios e carregamento de ficheiros).
- Funcionalidades frequentemente adicionadas:
[+] Análise de dispositivo e IP: Acrescente o contexto de localização e de ligação às suas submissões de questionário.
Personalização total
Cada funcionalidade dentro de um fluxo pode ser personalizada com parâmetros específicos para cumprir exatamente os seus requisitos. Explore as definições de cada verificação no construtor.
No modo Avançado, pode usar o campo OCR kyc.marital_status em ramificações condicionais e em regras de estado personalizadas. Escolha o valor no seletor de campos, para que a regra use o enum suportado em vez de texto livre. Se o documento não indicar o estado civil, o valor fica vazio e aplica-se a sua ramificação alternativa.
O copiloto do fluxo também pode criar e configurar passos de Validação de base de dados numa única ação. Quando lhe pedir para adicionar esta verificação, indique os países de que precisa; a consola resolve o serviço suportado para cada país e mostra a configuração guardada no canvas.
Comparação entre o modo simples e o avançado
Fluxo de integração
A integração de um fluxo orquestrado é simples. O seu servidor cria uma sessão com a Didit, recebe um URL único e redireciona o utilizador para esse URL. A Didit trata do restante e notifica o seu servidor dos resultados através de webhooks.
Casos de utilização comuns
| Caso de utilização | Modelo recomendado | Modo recomendado | Funcionalidades sugeridas |
|---|
| 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/serviços com restrição de idade | Verificação de idade adaptativa | Simples | Verificação de identidade como alternativa |
| Autenticação de utilizadores recorrentes | Autenticação biométrica | Simples | Análise de dispositivo e IP |
| Verificação de morada | Comprovativo de morada | Simples | Verificação de telefone |
| Onboarding de serviços financeiros | KYC | Avançado | Prova de vida, Correspondência facial, Comprovativo de morada, AML, Validação de base de dados |
| Conformidade específica por região | KYC | Avançado | Encaminhamento condicional por país, verificações diferentes por região |
| Verificação baseada no risco | KYC | Avançado | Ramificações condicionais com base nas pontuações de risco, caminhos de escalonamento |
Primeiros passos
- Novo na Didit? Comece com o modo simples e com um modelo pré-criado
- Precisa de personalização? Mude para o modo avançado para acrescentar lógica condicional
Contacte a nossa equipa comercial para discutir configurações de fluxos personalizadas ou para obter orientação sobre a melhor configuração para os seus requisitos específicos.
Última modificação em 7 de novembro de 2026
Começar
Integrar / SDKs
Verificação de utilizadores
Verificação de empresas
Monitorização de transações
Registo de alterações
