config dentro de cada item do array features em POST /v3/workflows/ e PATCH /v3/workflows/{settings_uuid}/.
features ordenado. Envie as funcionalidades pela ordem exata de execução.
O motor que executa uma funcionalidade, o da própria Didit ou o de um fornecedor terceiro, não é um dos campos de configuração abaixo. É gerido através do Marketplace da consola, que define
provider_key e fallback_to_native no objeto config da funcionalidade por si.Regras de validação
OCRusa por defeito todos os países e tipos de documento suportados quandoconfig.documents_allowedé omitido,nullou{}. Se enviar um objetodocuments_allowedpersonalizado, este tem de conter pelo menos um país válido e um tipo de documento ativo. Cada configuração de documento pode definirsidescomo1para captura apenas da frente ou2para captura da frente e do verso.QUESTIONNAIREexigeconfig.questionnaire_uuid.KYB_DOCUMENTSexigeconfig.kyb_required_document_groups.SIGNATURErecusasignature_level: "qes"comqes_not_availableaté as assinaturas qualificadas estarem disponíveis, e recusa um novo passo comsignature_level: "aes", devolvendoaes_not_availableenquantosignature_availability.aesforfalseno fluxo. Os respetivos documentos têm de existir quando uma sessão é criada: comsignature_documents_sourcedefinido comoworkflow, o passo precisa de documentos carregados na consola, e um passo sem documentos pode permanecer como rascunho, mas não pode entrar em produção; comsession, cada pedido de criação tem de enviarsign.documents.FACE_MATCHtem de vir depois deOCRem pedidos de fluxo simples.NFCeDATABASE_VALIDATIONexigemOCRquando aparecem no mesmo fluxo.AMLprecisa de um deOCR,KYB_REGISTRYouDOCUMENT_AIantes de si; com apenasDOCUMENT_AIantes dele, ofull_namea analisar tem de poder ser preenchido, seja a partir de um campo do Document AI anterior já identificado comofull_name, que é mapeado automaticamente, seja a partir de uma entrada explícitaconfig.aml_field_sources(ver AML).- As sub-funcionalidades KYB, como
KYB_DOCUMENTSeKYB_KEY_PEOPLE, exigemKYB_REGISTRYanteriormente no fluxo. - Um fluxo é um fluxo de pessoa (KYC) ou um fluxo de empresa (KYB), nunca os dois. Um fluxo que use qualquer funcionalidade KYB (
KYB_REGISTRY,KYB_DOCUMENTS,KYB_KEY_PEOPLE) só pode combiná-la comAML,DOCUMENT_AI,QUESTIONNAIRE,PHONE_VERIFICATION,EMAIL_VERIFICATION,IP_ANALYSISeSIGNATURE. Não pode incluir funcionalidades exclusivas de pessoas, comoOCR,LIVENESS,FACE_MATCH,NFC,PROOF_OF_ADDRESS,DATABASE_VALIDATIONouAGE_ESTIMATION, e um fluxo de pessoa não pode incluir funcionalidades KYB. Num fluxo de empresa,DOCUMENT_AIcompara qualquer campo marcado comis_full_namecom a empresa verificada, e não com uma pessoa. Para verificar as pessoas por detrás de uma empresa, crie um fluxo KYC separado e referencie-o no nóKYB_KEY_PEOPLEusandokyb_ubo_verification_workflow,kyb_officer_verification_workflowoukyb_shareholder_verification_workflow. - Os campos de ação usam
DECLINE,REVIEWouNO_ACTION, salvo se o campo abaixo indicar que é restrito. - Os campos de pontuação e de limiar são números de
0a100, salvo se for indicado um intervalo mais restrito.
Regras de estado comuns
Todas as funcionalidades suportam um array opcionalstatus_rules. Use-o para substituir o estado da funcionalidade quando uma condição sobre um campo se verifica.
Leia o exemplo acima como:
kyc.extra_fields.profession tem correspondência difusa com Soft. Engineer com uma pontuação mínima de 80 → definir o estado da funcionalidade como Declined.
Para a Verificação de identidade, indique valores extraídos de extra_fields, como kyc.extra_fields.profession, as datas de validade da classe da carta de condução, como kyc.extra_fields.dl_class_code_b_from e kyc.extra_fields.dl_class_code_b_to, ou os códigos de restrição ou informação por classe, como kyc.extra_fields.dl_class_code_b_notes (coluna 12 das cartas de condução do Reino Unido). Estes valores vêm do objeto extra_fields do resultado do OCR; não fazem parte de expected_details.
Os campos
dl_class_code_*_from e dl_class_code_*_to contêm sempre uma data ISO válida ou estão ausentes de extra_fields. A Didit nunca devolve texto OCR ilegível num campo de data. Se a célula da tabela de classes não puder ser lida, o campo é omitido em vez de ser enviado como string bruta, por isso use o operador is_empty para encaminhar datas de classe ilegíveis em vez de assumir que o campo está sempre presente.value_type: "relative_date" com um objeto de valor da forma { "direction": "past" | "future", "amount": number, "unit": "days" | "months" | "years" }. Por exemplo, operator: "less_than" com { "direction": "past", "amount": 3, "unit": "years" } corresponde a datas com mais de três anos relativamente à data de hoje.
Comparar com um passo específico
Um fluxo em grafo pode executar a mesma funcionalidade mais do que uma vez, por exemplo três passos de Verificação de identidade. Comvalue_type: "field", acrescente @<node_id> ao valor para o ler de um passo específico.
O nó referenciado tem de ser um passo de funcionalidade que seja sempre executado antes do passo da própria regra, em todos os caminhos que lá cheguem, ou o próprio passo da regra.
Um valor sem o sufixo é lido a partir do passo da própria regra.
kyc.full_name deste passo tem correspondência difusa com o nome completo lido pelo passo ocr_1, com uma pontuação mínima de 80 → definir o estado da funcionalidade como Declined.
Na consola, o seletor de variáveis lista cada passo elegível pelo seu número no ecrã e guarda o sufixo por si.
OCR / Verificação de identidade
Valor da funcionalidade:OCR.
A prova de vida do documento é configurada com os seis limiares
document_liveness_* acima, e não com campos de ação por sinal. portrait_replacement_action, printed_copy_action e screen_capture_action são definições ao nível da conta e não são aceites numa configuração de funcionalidades de fluxo: a API remove as chaves de configuração desconhecidas ao guardar, por isso enviá-las aí não tem efeito. Cada sinal tem um limiar de recusa e um limiar de análise, numa escala de 0 a 100 em que uma pontuação mais alta significa que o documento tem mais probabilidade de ser genuíno.Métodos por país
methods é indexado pelo código de país ISO 3166-1 alfa-3. Cada país tem até três objetos de método; tudo o que omitir assume o predefinido.
wallet.on_failure pode ser fallback_to_document, decline ou retry. retry (apenas para a carteira, com a captura de documentos desativada para o país) permite que um utilizador cuja autenticação não terminou no passo da carteira tente novamente; a sessão nunca é recusada por esse motivo e mantém-se aberta até o utilizador concluir ou até expirar. As opções de id_lookup aceitam apenas fallback_to_document ou decline.
Para manter os documentos fora do primeiro ecrã e oferecê-los apenas quando uma carteira ou uma consulta não resulta, defina document.fallback_only. O exemplo usa a Finlândia, onde a Finnish Trust Network é a primeira opção e a captura de documentos é a alternativa. A Finlândia também precisa de ter os seus tipos de documento ativados em documents_allowed (por exemplo, passaporte e cartão de identidade), para que a alternativa tenha documentos para oferecer.
available no catálogo atual, por isso esta configuração é guardada tal como está escrita. O bloco da carteira foi deixado de fora deste exemplo de propósito: a configuração de uma carteira só é guardada num país em que o catálogo a marca como available, e wallet.enabled: true em qualquer outro lugar é rejeitado e faz falhar a gravação inteira, incluindo a configuração das consultas. Quando o catálogo marcar uma carteira como available, acrescente-a a esse país:
Validação que a API aplica ao guardar:
- Um código de país desconhecido, uma chave desconhecida dentro de um país ou uma chave desconhecida dentro de um método é rejeitado; nada é descartado silenciosamente.
- Um país em que nenhum método esteja ativado é rejeitado: ninguém nesse país poderia ser verificado.
- Uma carteira ou consulta só pode recorrer à captura de documentos quando a captura de documentos está ativada nesse país.
fallback_to_documentnum país ondedocument.enabledéfalseé recusado em tempo de execução, porque não há para onde recorrer. document.fallback_only: trueé rejeitado com HTTP 400, a menos quedocument.enabledsejatruee pelo menos uma carteira ou consulta de ID desse país recorra à captura de documentos.
methods, através do separador Países da consola ou com a ferramenta MCP didit_workflow_get_id_verification_methods_catalog. O comportamento, a cobertura e a faturação estão em Métodos de verificação de identidade.
NFC / Passaporte eletrónico
Valor da funcionalidade:NFC.
Prova de vida
Valor da funcionalidade:LIVENESS.
Correspondência facial
Valor da funcionalidade:FACE_MATCH.
Estimativa de idade
Valor da funcionalidade:AGE_ESTIMATION.
Verificação de telefone
Valor da funcionalidade:PHONE_VERIFICATION.
A Verificação de telefone fica desativada até que a organização conclua o primeiro carregamento de saldo.
O enriquecimento de inteligência do telefone é um complemento opcional. Quando
phone_enrichment_enabled está true, cada verificação de telefone concluída é enriquecida com inteligência do telefone e faturada a $0.05 por pedido, além do custo padrão da verificação de telefone. As ações baseadas na pontuação só são aplicadas quando a pontuação de enriquecimento estiver disponível; as ações de índice de confiança, tipo de telefone e portabilidade são aplicadas assim que o enriquecimento é executado.A verificação da presença em redes sociais é um segundo complemento, separado. Quando phone_social_enabled está true, cada verificação de telefone concluída também indica em que plataformas online o número está registado (mensagens, redes sociais, comércio eletrónico e serviços profissionais) e é faturada a $0.05 por pedido. Pode ser ativada com ou sem phone_enrichment_enabled: os dois complementos têm preço e faturação independentes. Uma consulta que não encontra o número em nenhuma das plataformas que cobre é uma resposta válida e faturável, e aciona phone_no_social_presence_action. Utilize phone.social_profiles_registered (o número de plataformas em que o número está registado) para criar ramificações com base no resultado num grafo do fluxo.Verificação de e-mail
Valor da funcionalidade:EMAIL_VERIFICATION.
O enriquecimento com informação de e-mail é um complemento opcional. Quando
email_enrichment_enabled está true, cada verificação de e-mail concluída é enriquecida com informação de e-mail e é cobrada $0.05 por pedido, para além do custo habitual da verificação de e-mail. A ação baseada na pontuação entra em vigor assim que a pontuação de enriquecimento estiver disponível; as ações de violação de dados aplicam-se logo que o enriquecimento é executado.A verificação da presença online é um segundo complemento, separado. Quando email_social_enabled está true, cada verificação de e-mail concluída indica também em que plataformas online o endereço está registado (serviços de e-mail, redes sociais, serviços profissionais, de comércio eletrónico e de entretenimento) e é cobrada $0.05 por pedido. Pode ser ativada com ou sem email_enrichment_enabled: os dois complementos têm preço e faturação independentes. Uma consulta que não encontra o endereço em nenhuma das plataformas abrangidas é uma resposta válida e cobrável e aciona email_no_social_presence_action. Utilize email.social_profiles_registered (o número de plataformas em que o endereço está registado) para criar uma ramificação com base no resultado num grafo de fluxo.Validação de base de dados
Valor da funcionalidade:DATABASE_VALIDATION.
Exemplo:
400 que o indica e explica o motivo, e nada é guardado. Isto inclui um ID que não está no catálogo, um ID que pertence a outro país, um serviço que ainda não está disponível e um serviço oferecido apenas através do POST /v3/database-validation/ autónomo.
Um serviço cujas entradas nenhum passo anterior fornece é rejeitado da mesma forma, com a lista das entradas em falta.
Um serviço que o fluxo guardado já inclui mas que já não consegue executar é removido quando voltar a guardar o fluxo.
Por exemplo, este fluxo da Argentina lê o número de DNI e o género a partir da Verificação de identidade e verifica-os na RENAPER sem selfie:
arg_renaper em alternativa, após um passo LIVENESS, para também comparar a selfie com a fotografia que a RENAPER detém.
Consulte a RENAPER para a pontuação de correspondência facial e o respetivo limiar.
Verificação bancária
Valor da funcionalidade:BANK_VERIFICATION.
O utilizador verifica uma conta bancária, e o titular da conta indicado pelo banco é comparado com a identidade que um passo anterior do fluxo estabeleceu. O utilizador faz isto por um de dois métodos: início de sessão no banco (open_banking), em que inicia sessão no seu banco, ou verificação de conta (account_lookup), em que introduz os dados da conta e o banco confirma o nome associado. bank_method_order e o methods de cada país escolhem quais os métodos que um país oferece e qual vem primeiro; veja Métodos de verificação bancária. O passo produz evidências: uma pontuação do nome do titular, a comparação que a gerou e os códigos de motivo. As chaves bank_*_action transformam essas evidências num estado.
Dois fatores determinam se o nó faz alguma coisa. bank_countries é uma lista de permissões, pelo que um mapa vazio não oferece nenhum banco e não executa nenhuma verificação. Além disso, o titular precisa de algo com que ser comparado: coloque antes do nó um passo OCR, DATABASE_VALIDATION ou QUESTIONNAIRE, envie expected_details na criação da sessão ou mapeie os campos por si com bank_field_sources. Sem nada disso, a propriedade só pode ser unknown, decisão que cabe a bank_reference_identity_missing_action.
A verificação bancária ainda está a ser implementada, por isso um nó
BANK_VERIFICATION só é aceite numa conta onde tenha sido ativado. Em todas as outras, a gravação é rejeitada e o sistema indica-o. Também não é aqui que se configura a rota que executa o passo: isso é definido pelo par provider_key e fallback_to_native que o Marketplace da consola define para si.Ligar uma conta
Quando o utilizador não consegue verificar
O utilizador pode sempre continuar sem banco, e o passo nunca o deixa bloqueado. Veja Quando a pessoa não consegue verificar o seu banco.
O que a continuação significa para a sessão é
bank_unsupported_action, bank_attempts_exhausted_action ou bank_skipped_action, consoante o motivo pelo qual o utilizador continuou, exceto se uma tentativa avaliada antes já tiver decidido o passo: consulte Ações do veredicto.
Comparar o titular
Verificação de conta
Estas chaves aplicam-se apenas à verificação de conta. A autenticação bancária mantém as suas correspondências aproximadas e o seu própriobank_max_attempts.
Dados financeiros
bank_expected_currencies funciona apenas com o consentimento predefinido ownership. As outras três chaves leem dados financeiros reais, pelo que cada uma precisa do âmbito de consentimento correspondente em bank_scopes, e a gravação é recusada sem ele.
O que é armazenado
Ações de decisão
Cada chave aqui aceitaDECLINE, REVIEW ou NO_ACTION, exceto quando estiver marcada como restrita, e recorre à predefinição abaixo quando a omite ou envia null. Nada que não seja prova positiva de propriedade é aprovado por predefinição, e só a prova demonstrável contra o utilizador leva à recusa.
Mais controlos
Estas chaves são opcionais. Cada chave de ação aceitaDECLINE, REVIEW ou NO_ACTION.
Exemplo de objeto
config, para uma conta em que a Bank Verification está ativa e a rota escolhida cobre o país indicado:
AML
Valor da funcionalidade:AML.
Para a triagem de pessoas no âmbito do KYC, use estes campos:
Para a triagem de empresas no âmbito do KYB, use estes campos:
Triagem de uma entidade extraída por um passo de Document AI
Um passo AML lê normalmente quem é alvo da triagem a partir do passoOCR (uma pessoa) ou do passo KYB_REGISTRY (uma empresa). Um fluxo cujo único passo de extração é DOCUMENT_AI, ou seja, documentos não normalizados como um certificado fiscal ou uma escritura de constituição, não tem nenhum dos dois, por isso tem de indicar de onde vem cada entrada da triagem.
Exemplo: triagem da empresa indicada numa acta constitutiva mexicana, sem nenhum documento de identificação no fluxo:
Análise de dispositivo e IP
Valor da funcionalidade:IP_ANALYSIS.
Exemplo:
recovered_device_action separadamente de duplicated_device_action quando quiser monitorizar dispositivos recuperados com elevada confiança antes de os recusar automaticamente. Isto é útil durante a implementação, porque as correspondências de dispositivos recuperados foram concebidas para detetar redes de fraude, mas ainda devem ser calibradas com o seu próprio tráfego.
Verificação de localização
Valor da funcionalidade:GEOLOCATION.
Verifica onde a pessoa se encontra durante a verificação, a partir da posição do dispositivo ou da localização IP da ligação, face às áreas permitidas e bloqueadas, à localização IP e à morada do documento.
Consulte Verificação de localização para saber como o passo se comporta e o respetivo relatório para os campos de decisão.
Coloque-o depois de Verificação de identidade ou de Comprovativo de morada se quiser a distância até à morada de um documento, porque a distância só é medida quando existe uma morada registada.
Com geolocation_position_source não definido, a distância até à localização IP exige um passo de Análise de dispositivo e IP no mesmo fluxo.
Todas as chaves são opcionais: um passo com config vazio pede ao dispositivo uma posição com precisão de 250 m, com no máximo 120 segundos, dá à pessoa 3 tentativas e não aplica nenhuma regra de área.
Cada conclusão tem a sua própria chave de ação. Uma chave de ação que não defina assume o predefinido do geolocation_preset escolhido ou, se não escolher nenhum, o predefinido por chave indicado abaixo.
Uma localização incerta ou uma recusa de localização tem por predefinição REVIEW, nunca DECLINE, porque uma permissão negada ou um raio amplo não é prova de fraude.
Uma ação que definir explicitamente prevalece sempre sobre o predefinido.
Um desafio reproduzido (LOCATION_REPLAY_DETECTED) e uma falha na atestação do dispositivo (LOCATION_INTEGRITY_FAILED) recusam sempre e não têm chave de ação.
Formas das áreas
Cada item degeolocation_areas tem um id (de 1 a 64 caracteres de A-Z a-z 0-9 _ -, único na lista), uma label opcional (até 80 caracteres), um type de allowed ou blocked, e um kind que escolhe a forma.
Uma lista tem no máximo 50 áreas e precisa de pelo menos uma área
allowed enquanto is_geolocation_geofencing_enabled for true.
geolocation_areas e geolocation_geofencing_by_country não podem ser enviados em conjunto, e geolocation_refusal_path: "end_session" exige que geolocation_permission_denied_action seja REVIEW ou DECLINE.
A API recusa uma área que nunca poderia corresponder, como uma região de um país sem limites publicados, em vez de a guardar.
Exemplo:
Comprovativo de morada
Valor da funcionalidade:PROOF_OF_ADDRESS.
Questionário
Valor da funcionalidade:QUESTIONNAIRE.
Registo de empresas (KYB)
Valor da funcionalidade:KYB_REGISTRY.
kyb_registry_fields_config mapeia cada chave de campo configurável para {"enabled": bool, "required": bool}. enabled: false oculta o campo, enabled: true, required: false mostra-o como opcional, e enabled: true, required: true torna-o obrigatório na submissão. company_name, country_code e region são sempre mostrados e obrigatórios e não podem ser configurados. Quando o objeto é omitido, null ou {}, aplica-se a predefinição: apenas incorporation_date é obrigatório e todos os outros campos são opcionais.
registration_number, incorporation_date, legal_address, vat_number, alternative_names, tax_number, company_type, legal_entity_identifier, location_of_registration, nature_of_business, registered_capital_amount, registered_capital_currency, website, email, phone, control_scheme. Consulte campos configuráveis do formulário de registo para o comportamento junto do utilizador final e validação de IVA e de número de identificação fiscal para saber como vat_number e tax_number são verificados.
Documentos KYB
Valor da funcionalidade:KYB_DOCUMENTS.
Pessoas-chave KYB
Valor da funcionalidade:KYB_KEY_PEOPLE.
Document AI
Valor da funcionalidade:DOCUMENT_AI.
Pede ao utilizador um ou mais documentos e extrai os campos que define, com um modelo de visão. Cada campo configurado torna-se um valor ramificável document_ai.<key>, e o resultado do passo é document_ai.status.
Cada entrada em
document_ai_documents é um documento:
Cada entrada em
fields de um documento é um campo:
Exemplo:
Assinatura eletrónica
Valor da funcionalidade:SIGNATURE.
Permite que a pessoa verificada, ou as pessoas-chave de uma empresa, assinem documentos, no nível Simple (predefinido) ou Advanced (AES). Coloque-a depois dos passos que verificam o signatário: Verificação de identidade e, para o código, Verificação de e-mail ou de telefone. Consulte Assinatura eletrónica.
Os campos de um documento do fluxo são colocados no editor de modelos da consola. Para documentos de sessão, envie-os em
sign.documents[].fields e envie os valores dos campos api.<key> em sign.field_values. Consulte Criar sessão.
Exemplo, para documentos enviados com cada sessão: