KYC Sem Código: Criando Fluxos de Verificação Sem Programação (PT-BR)

Um construtor de fluxo de trabalho KYC (Know Your Customer) sem código é uma interface visual para construir, testar e implantar lógica de verificação de identidade sem escrever código. A principal distinção de um painel de configuração: programabilidade. Ramificação condicional, decisões aninhadas, testes A/B e ativação de módulos com um clique permitem que uma equipe de compliance expresse sua política de risco completa visualmente — e a altere sem um deploy de código.

Essa distinção é mais importante do que parece. Os requisitos de compliance mudam. Os limites de risco se alteram. Uma nova linha de produtos precisa de um escopo de verificação diferente. Os reguladores atualizam as diretrizes. Na abordagem convencional, cada uma dessas mudanças vai para o backlog da engenharia e aguarda um ciclo de deploy. Em um modelo de fluxo de trabalho sem código, a mudança é feita em um Console, revisada pelo compliance e entra em vigor no mesmo dia.

O Workflow Orchestrator da Didit é essa camada, e é gratuito. Ele se baseia na API unificada /v3/, que os engenheiros chamam uma vez. A partir desse ponto, o que o fluxo de verificação faz é uma decisão de produto e compliance — não uma decisão de engenharia.

Principais conclusões

• Um construtor de fluxo de trabalho sem código separa a integração da configuração. Os engenheiros chamam um endpoint de API; o compliance constrói e modifica o fluxo no Console sem tocar na integração.
• A ramificação condicional e as decisões aninhadas direcionam os usuários para diferentes conjuntos de verificações com base no país, tipo de produto, valor da transação ou qualquer campo disponível no contexto da sessão.
• A ativação de módulos com um clique adiciona ou remove qualquer um dos mais de 25 módulos da Didit — documento, biometria, AML, e-mail, IP, telefone, validação de banco de dados — de um fluxo de trabalho em segundos.
• Os testes A/B em produção executam dois fluxos com tráfego real, medem as taxas de conclusão e aprovação por braço e promovem o vencedor — sem necessidade de alteração de código.
• As alterações revisadas pelo compliance significam que cada modificação em um fluxo de trabalho ativo passa por uma etapa de aprovação antes de afetar usuários reais.
• O Workflow Orchestrator é gratuito. Você paga por execução de módulo, por chamada, sem licenças de assento ou taxas de plataforma.

O que é um construtor de fluxo de trabalho KYC sem código

Um fluxo de trabalho de verificação é a sequência de verificações pelas quais um usuário passa durante o onboarding — ou em um evento de step-up posterior em seu ciclo de vida. No seu mais simples: digitalizar um documento de identidade, tirar uma selfie, comparar o rosto com o documento. No seu mais complexo: uma árvore ramificada onde usuários de jurisdições de alto risco recebem um conjunto de módulos diferente dos usuários domésticos, onde o tamanho da transação determina qual nível de liveness é executado e onde uma biometria com falha é roteada para uma fila de revisão em vez de uma recusa definitiva.

Um construtor sem código expressa essa árvore visualmente. Cada nó é uma condição ou um módulo; cada aresta é um ramo. A pessoa responsável pela política de compliance — não o engenheiro — é quem possui a lógica. Essa separação de propriedade é o ponto principal: a pessoa que entende a política de risco agora também pode alterá-la diretamente.

Ramificação condicional e decisões aninhadas

O Workflow Builder da Didit suporta ramificação multinível. Um único fluxo de trabalho pode conter:

Roteamento baseado em país. Residentes da UE seguem um caminho; residentes da LATAM, onde a validação de banco de dados contra registros locais se aplica, seguem outro. A condição de roteamento é avaliada na criação da sessão a partir do contexto da sessão.

Roteamento baseado em produto. Contas de negociação exigem documento completo mais liveness; contas poupança são liberadas com e-mail mais IP. O mesmo usuário, abrindo um produto diferente, entra em um ramo diferente — tudo dentro de um fluxo de trabalho, um workflow_id, uma integração.

Limites de valor de transação. O primeiro depósito de um usuário abaixo de um limite recebe uma verificação mais leve; qualquer valor acima aciona o fluxo completo. A condição de valor é passada no payload da sessão e avaliada pelo motor.

Roteamento de estado de falha. Uma primeira tentativa de biometria com falha é roteada para uma fila de revisão humana em vez de uma recusa definitiva. O ramo é uma condição sobre o resultado do módulo, não uma integração separada.

As condições se aninham — uma condição dentro de uma condição — para que o mapa de políticas possa ser tão granular quanto o negócio exigir. Tudo é expresso no construtor visual, não em código de backend.

Ativação de módulo com um clique

A biblioteca de módulos da Didit cobre todo o ciclo de vida de identidade e fraude: Verificação de ID, Leitura NFC, Liveness Passiva, Liveness Ativa, Face Match 1:1, Face Search 1:N, Estimativa de Idade, Triagem AML (Anti-Lavagem de Dinheiro), Monitoramento Contínuo de AML, Verificação de E-mail, Verificação de Telefone, Análise de IP, Inteligência de Dispositivo, Validação de Banco de Dados, Comprovante de Endereço, Questionários Personalizados e muito mais.

No Workflow Builder, cada módulo aparece como um cartão. Adicioná-lo a um fluxo de trabalho é um único clique. Removê-lo é um único clique. O módulo é cobrado por uso quando executado — então, adicionar um módulo a apenas um ramo significa que ele só será cobrado para usuários que alcançarem esse ramo.

Isso é mais importante quando as regulamentações mudam e uma nova verificação obrigatória deve ser adicionada em todos os fluxos de trabalho. Em uma integração baseada em código, isso é uma mudança de backend, uma revisão, um ciclo de deploy. No Workflow Builder, é ativar o módulo nos fluxos relevantes no Console e enviar para revisão de compliance. A camada de integração não se move.

Testes A/B de fluxos de trabalho em produção

O impacto na conversão das escolhas de design de verificação — documento primeiro versus selfie primeiro, três etapas versus duas, liveness ativa versus passiva — é frequentemente maior do que o esperado e geralmente não é medido. Os testes A/B integrados da Didit tornam a medição direta.

Configure uma divisão de tráfego (por exemplo, 50/50) entre duas variantes de fluxo de trabalho. Ambas são executadas em usuários reais em produção. O Console mostra a taxa de conclusão, taxa de aprovação e distribuição de decisões por braço, lado a lado. Quando você tiver confiança no vencedor, promova-o para 100% do tráfego — do Console, sem alteração de código, com uma revisão de compliance antes de entrar em vigor.

O mesmo mecanismo se aplica a mudanças impulsionadas por compliance. Uma nova verificação obrigatória sendo adicionada pode ser testada A/B contra o fluxo existente para medir o impacto na conversão antes da data de lançamento obrigatória — dando dados à equipe de produto em vez de suposições.

A API unificada /v3/: integre uma vez, itere para sempre

A arquitetura subjacente é o que torna isso prático em escala. Cada módulo, cada ramo, cada versão de fluxo de trabalho chama a mesma superfície de API /v3/. Os engenheiros chamam POST /v3/session/ com um workflow_id e redirecionam o usuário para a URL da sessão. O motor do fluxo de trabalho lida com o sequenciamento de módulos, lógica de ramificação, entrega de resultados e despacho de webhook.

Quando o compliance modifica o fluxo de trabalho, o workflow_id permanece o mesmo. Nada no lado da engenharia muda. A integração é estável; a política é ativa e mutável.

Isso também significa que a mesma integração suporta todos os módulos futuros que a Didit lançar. Ativação com um clique do Console, cobrada por uso, sem trabalho de re-integração. Novos módulos — validação de banco de dados para um novo país, um novo nível de liveness, um novo provedor de AML — aparecem no construtor e estão disponíveis para qualquer fluxo de trabalho imediatamente.

Como o Workflow Orchestrator está na mesma API /v3/ que o Transaction Monitoring, uma sessão KYC pode ser vinculada a um perfil de risco de transação na mesma referência vendor_data. A identidade estabelecida no onboarding flui diretamente para a camada de monitoramento contínuo — uma plataforma, uma integração.

Casos de uso

Fintech regulamentada lançando novos produtos. Uma nova linha de produtos com um perfil de risco de cliente diferente precisa de um escopo de verificação diferente. Crie um novo ramo de fluxo de trabalho no Console; sem necessidade de sprint de engenharia. O log de auditoria registra cada mudança com carimbo de data/hora e autor.

Compliance de VASP e exchange de cripto. As obrigações da Regra de Viagem da FATF variam por jurisdição e tipo de contraparte. Um fluxo de trabalho com ramificação baseada em país e valor aplica a política correta por categoria de transação sem lógica de backend personalizada por mercado.

Plataformas de marketplace com onboarding de dois lados. Contas de comprador e vendedor têm perfis de risco diferentes. Dois fluxos de trabalho — ou dois ramos dentro de um — com diferentes conjuntos de módulos, gerenciados no Console e com controle de versão no log de auditoria. Os engenheiros entregaram uma integração.

Operadores de iGaming. Os requisitos de jogo responsável variam por jurisdição e segmento de usuário. Testar A/B o comprimento do fluxo em relação às taxas de conclusão, com revisão de compliance controlando cada mudança, é o padrão regulatório que os reguladores na Espanha, Reino Unido e Malta esperam cada vez mais.

Perguntas frequentes

O Workflow Orchestrator é realmente gratuito?

Sim. A orquestração, ramificação, testes A/B e lógica de ativação de módulos não têm custo. Você paga por execução de módulo, por chamada, sem licenças de assento ou taxa de assinatura de plataforma.

O construtor sem código substitui nossa integração de backend?

Não — os engenheiros ainda chamam POST /v3/session/ do seu backend. O construtor configura o que o motor faz com essa chamada. Ele remove a necessidade de re-integrar quando a política muda; ele não remove o ponto de integração.

Como funcionam as mudanças revisadas pelo compliance?

Cada modificação em um fluxo de trabalho ativo no Console aciona uma etapa de revisão antes que a mudança afete usuários reais. O log de auditoria registra quem mudou o quê e quando, o que satisfaz a maioria dos requisitos de documentação de gerenciamento de mudanças regulatórias.

Posso combinar o Workflow Builder com o Transaction Monitoring?

Sim. Uma sessão KYC se vincula a um perfil de monitoramento de transações através da mesma referência vendor_data — então a identidade do onboarding flui para a camada de risco de transação pós-onboarding sem re-integração. O status AWAITING_USER no monitoramento de transações pode gerar uma sessão KYC de remediação através do mesmo motor de fluxo de trabalho.

Quantos módulos posso combinar em um fluxo de trabalho?

Não há limite rígido. Os fluxos de trabalho podem ativar qualquer combinação dos mais de 25 módulos da Didit, em qualquer ordem, com qualquer profundidade de ramificação que a política exigir.

Pronto para começar?

• Saiba mais sobre o recurso → Docs
• Veja na plataforma → Página do produto Verificação de ID
• Verifique o preço → Preços — Workflow Orchestrator gratuito, módulos cobrados por chamada
• Comece grátis → business.didit.me — 500 verificações gratuitas/mês