> ## Documentation Index > Fetch the complete documentation index at: https://docs.didit.me/llms.txt > Use this file to discover all available pages before exploring further. # Construtor de fluxos: designer de fluxos KYC sem código > Crie fluxos de verificação sem código com o construtor da Didit. Arraste e solte ID, prova de vida, AML e NFC. Pague só pelos passos concluídos. 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. [Crie o seu primeiro fluxo de verificação — Didit Academy](https://www.youtube.com/embed/7-nJ3JE20i4?rel=0\&playsinline=1) 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](https://docs.didit.me/pt/integration/sandbox-testing.md) 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. *** ## Duas formas de criar fluxos 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: ![Modos simples e avançado do criador de fluxos KYC da Didit lado a lado](https://mintcdn.com/didit-0f962782/DSfxHq_ggIpqiQSG/images/workflows-simple-and-complex.jpg?fit=max\&auto=format\&n=DSfxHq_ggIpqiQSG\&q=85\&s=07f4e97f94cb1179de16732573612b6e) ### 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. ![Interface do criador de modelos do modo simples do fluxo de verificação de identidade da Didit](https://mintcdn.com/didit-0f962782/DSfxHq_ggIpqiQSG/images/workflows-simple.jpg?fit=max\&auto=format\&n=DSfxHq_ggIpqiQSG\&q=85\&s=ebe4da7cf6549793629497fb36053fe2) **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:** 1. Escolha um modelo de fluxo (KYC, verificação de idade, etc.) 2. Ative ou desative funcionalidades (prova de vida, correspondência facial, AML, etc.) 3. Configure as definições básicas de cada funcionalidade 4. 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. ![Criador visual de fluxos de verificação baseado em nós](https://mintcdn.com/didit-0f962782/z6T2GHM4Zh-iSj-K/images/node-based-workflow.png?fit=max\&auto=format\&n=z6T2GHM4Zh-iSj-K\&q=85\&s=2c0997ab8bbb09dbf7c4cb26b201eced) **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](https://docs.didit.me/pt/core-technology/id-verification/document-subtypes-id-verification.md), 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 | Tipo de nó | Cor do ícone | Descrição | Exemplos | | - | - | - | - | | **Nós de funcionalidades** | Azul | Verificações que processam os dados do utilizador | Verificação de identidade (OCR), prova de vida, correspondência facial, NFC, AML, verificação de telefone/e-mail, questionário, comprovativo de morada, Document AI, validação de base de dados, análise de dispositivo e IP, estimativa de idade | | **Nós de ramificação** | Roxo | Encaminhamento condicional com base em dados ou resultados | Encaminhar por país, pontuação de risco, tipo de documento, subtipo de documento, idade, data de emissão, meses desde a emissão, estado da verificação | | **Nós de ação** | Âmbar | Acionadores de automatização que alteram os dados da sessão ou do utilizador | Adicionar etiqueta, remover etiqueta, definir metadados, adicionar nota de revisão | | **Nós de webhook** | Ciano | Pedidos HTTP que podem enviar dados para ramificações posteriores | Enviar dados da sessão para o seu servidor, analisar respostas JSON, ramificar por caminhos como `category`, `status` ou `tags.0` | | **Nós de estado** | Verde/Vermelho/Âmbar | Resultados finais que terminam o fluxo de verificação | Aprovada, Recusada, Em análise | #### 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](#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](https://docs.didit.me/pt/console/marketplace.md), 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. 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.` 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](https://docs.didit.me/pt/integration/sandbox-testing.md#o-que-o-documento-fabricado-não-contém) 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](https://docs.didit.me/pt/sessions-api/retrieve-session.md#eventos-de-encaminhamento-do-fluxo) 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. ![Galeria de modelos de fluxo de verificação KYC do Didit para casos de utilização de KYC, KYB e verificação de idade](https://mintcdn.com/didit-0f962782/DSfxHq_ggIpqiQSG/images/workflows-template.jpg?fit=max\&auto=format\&n=DSfxHq_ggIpqiQSG\&q=85\&s=a727315368aa2f6bd096e873d7fbae6c) ### 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. *** ## Criar regras com base no estado civil 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 | Capacidade | Modo simples | Modo avançado | | - | - | - | | Seleção de modelo | ✅ | ✅ | | Ativar/desativar funcionalidades | ✅ | ✅ | | Configuração básica de funcionalidades | ✅ | ✅ | | Editor visual de grafos | ❌ | ✅ | | Ramificação condicional | ❌ | ✅ | | Automatização de ações (etiquetas, metadados) | ❌ | ✅ | | Caminhos de verificação paralelos | ❌ | ✅ | | Decisões baseadas no risco | Limitadas | ✅ Controlo total | | Suporte para anular/refazer | ❌ | ✅ | | Atalhos de teclado | ❌ | ✅ | *** ## 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. ```mermaid theme={null} sequenceDiagram participant Customer participant Client participant Server participant Didit Customer->>Client: Go to verification page Client->>Server: POST /create-verification-session Server->>Didit: POST /v3/session/ Didit-->>Server: Return new verification session Server-->>Client: Return verification session's url Client->>Customer: Redirect customer to url Customer->>Didit: Complete verification steps Didit->>Server: Send status updates Server->>Customer: Notify of status changes Customer->>Customer: Return to callback URL ``` *** ## 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 1. **Novo na Didit?** Comece com o **modo simples** e com um modelo pré-criado 2. **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. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.