Como os gráficos de decisão transformam verificações em aprovação, revisão ou rejeição.

Um fluxo de trabalho decide um resultado em duas etapas. Primeiro, as verificações são executadas e relatam os fatos: o documento foi lido, o registro governamental correspondeu, a selfie obteve 71 pontos em comparação com a foto do registro e a tela da lista de observação encontrou uma possível correspondência. Em seguida, o gráfico de decisão do fluxo de trabalho lê esses fatos, segue os caminhos que você traçou e decide entre aprovar , revisar ou rejeitar . As verificações nunca decidem se alguém será integrado; o gráfico decide.

Manter essas etapas separadas é a parte útil. Os fatos permanecem fixos e auditáveis, e a política que os interpreta fica em um único local que você pode alterar republicando-o. Este artigo explica como funciona uma execução em Toden Fluxos de trabalho e como projetar um gráfico que encaminhe os casos certos para a pessoa certa.

O que acontece quando uma verificação termina?

Quando uma verificação atinge um estado terminal, o mecanismo inicia uma execução para ela. De acordo com a documentação de tomada de decisão (abre num novo separador) , uma execução realiza quatro tarefas:

1. Reúne os dados: o resultado da verificação, a entidade do cliente e a identidade vinculada, quaisquer resultados de triagem e os sinais de Inteligência do Dispositivo.

2. Percorre o grafo a partir do nó inicial, avaliando cada ramificação e executando cada ação.

3. Aterrissa em um nó de status terminal, que define o resultado.

4. Registra o caminho percorrido, o rastro, e envia oworkflow.run.completedwebhook.

Existe apenas uma execução por verificação, e as execuções são idempotentes, portanto, uma verificação que é repetida ou reprocessada nunca é decidida duas vezes.

Os quatro tipos de nó

Você pode construir o gráfico como uma lista de regras ordenadas simples ou em uma tela avançada. A lista de regras é adequada para a maioria das políticas de integração, que são uma sequência de declarações do tipo "se isso, então aquele resultado", com um valor padrão no final.

O que um galho pode ler

As condições leem um espaço de nomes fechado de campos, agrupados pela origem do fato:

• verification.*: o resultado da verificação, como por exemplostatus,reasonCode,assuranceLevel(chip,gov_dboudocument),facialMatch,facialConfidence,facialMatchSource,ageedocumentExpired.

• entity.*eidentity.*: o nível de risco e a disposição do cliente, bem como o estado de confiança da identidade vinculada.

• screening.*: se alguma tela da lista de observação correspondeu, se uma correspondência foi confirmada, o status de cada tipo de tela e a pontuação de correspondência mais alta.

• device.*eip.*Inteligência do dispositivo, como por exemplo, quantas outras pessoas usaram o mesmo dispositivo e se o endereço IP pertence a um centro de dados.

• email.*ephone.*Resultados da verificação de contato.

• business.*ekeyPeople.*Verificação da empresa e diligência prévia em relação aos seus principais colaboradores.

• questionnaire.<key>: respostas a qualquer questionário no fluxo.

Os operadores sãoeq,neq,gt,gte,lt,lte,in,nin,containseexists, combinado comall,anyenot.

Duas regras definem como você escreve condições. Primeiro, um campo que não existe no namespace é rejeitado na publicação, portanto, um erro de digitação é detectado imediatamente, em vez de ser apresentado como uma regra que silenciosamente nunca é correspondida. Segundo, um valor nulo resulta em falha na comparação. Se uma verificação não possui confiança aparente porque nenhuma comparação foi realizada,verification.facialConfidence gte 80é falso, não verdadeiro. Quando a ausência importa, teste-a explicitamente comexists.

O que um resultado altera e o que ele não altera.

Um nó de status define a disposição da entidade , ou seja, a decisão de conformidade relativa à pessoa ou empresa:

Ela nunca substitui o resultado da própria verificação. Uma verificação cujas verificações falharam permanece falha.checkStatusmesmo que seu gráfico o aprove, e a linha superiorstatusO sistema registra a aprovação. É assim que um auditor pode posteriormente verificar tanto a exceção quanto o fato de que ela foi anulada.

Seu servidor recebe o resultado emworkflow.run.completede emverification.status_updatedcomsource: "workflow"Sempre que o veredicto altera o status da verificação, o que você faz com ele, como conceder acesso ou manter uma conta, é uma decisão do seu código.

Um gráfico elaborado para um credor de consumo.

Considere uma instituição financeira hipotética que cadastra indivíduos na Nigéria com um fluxo de trabalho que executa AML triagem. Sua política, escrita como uma lista ordenada de regras, poderia ser a seguinte:

1. Aguarde a conclusão da triagem, até o tempo limite.

2. Sescreening.confirmedÉ verdade, declínio .

3. Sescreening.anyMatchÉ verdade, abra um caso e depois revise .

4. Severification.statusnão éVERIFIEDdeclínio .​

5. Sedevice.matchedEntitiesSe 2 ou mais, revise .

6. Severification.facialMatchSourceédocument, análise .

7. Severification.assuranceLevelestá emchipougov_dbaprovar .​

8. Caso contrário, revise .

A ordem estabelece a política. A triagem vem primeiro porque uma correspondência confirmada na lista de vigilância deve rejeitar alguém cujos documentos sejam perfeitos. A regra do dispositivo precede a aprovação porque um aparelho usado por vários outros candidatos merece ser analisado, independentemente da idoneidade da verificação individual. A Regra 6 existe porque uma selfie que corresponde apenas à foto impressa em um documento é uma evidência mais fraca do que uma correspondência com o registro governamental ou uma foto verificada do chip.

Agora, execute o teste com três candidatos:

O candidato C demonstra por que o gráfico exibe os fatos em vez de substituí-los. Se, em vez disso, sua política encaminha incompatibilidades de selfies para revisão, altere a regra 4 para rotear.verification.reasonCode eq selfie_mismatchpara revisão antes de uma recusa geral. Um revisor que aprova após analisar as fotos produz uma verificação que éapprovedcomcheckStatus: "failed"E ambas as afirmações são verdadeiras.

Toden modelos de navios, como KYC mais AML Triagem e integração por níveis de risco, que começam com um fluxograma de decisão já elaborado. Trata-se de um primeiro rascunho razoável, não de uma política que deva ser publicada sem antes ser lida.

Comportamentos que vale a pena conhecer antes de publicar

As execuções são fixadas. Uma execução usa a versão do fluxo de trabalho e o instantâneo do gráfico com os quais foi iniciada. Republicar um gráfico mais restritivo não altera uma decisão já em andamento, o que é importante quando uma execução está aguardando aprovação dos diretores de uma empresa por dias.

A triagem aguarda apenas a primeira resposta. A espera na triagem se mantém até a primeira resolução. Reavaliações posteriores são tratadas por meio de monitoramento contínuo, e não por uma nova decisão sobre a integração.

As pessoas têm prioridade sobre o gráfico. A decisão de um revisor prevalece sobre a do fluxo de trabalho. Se alguém da sua equipe tomar uma decisão enquanto a execução ainda estiver em andamento, a decisão dessa pessoa será mantida, e o veredito posterior do fluxo de trabalho não alterará o status.

Falhas no motor não são declínios. workflow.run.failedSignifica que o motor não conseguiu completar um ciclo. Trate isso como um incidente a ser investigado, nunca como uma rejeição do cliente.

As ações são efeitos colaterais. Abrir um caso ou enviar um webhook não encerra a execução. O grafo continua até atingir um nó de status, portanto, certifique-se de que todos os caminhos o façam.

Uma lista de verificação para o seu primeiro gráfico.

1. Escreva a política em frases simples antes de desenhar qualquer coisa, incluindo o resultado padrão.

2. Coloque as restrições definitivas (correspondências confirmadas na lista de observação) primeiro e as aprovações por último.

3. Para cada falha na verificação, decida se ela será rejeitada ou encaminhada para revisão e anote isso como regra.

4. Usarexistssempre que um valor ausente deva significar algo.

5. Abra um inquérito sobre os casos que necessitam de um investigador, e não apenas de uma revisão.

6. Teste cada caminho em um ambiente de teste (sandbox) com os IDs de teste publicados antes de publicar em produção.

7. Armazene oworkflowVersioncom cada resultado, para que você possa mostrar posteriormente quais regras um cliente seguiu.