Diagrama do ciclo de vida
Estados em detalhe
A alteração do estado através de
PATCH /v3/users/{vendor_data}/update-status/ ou PATCH /v3/businesses/{vendor_data}/update-status/ emite um webhook (user.status.updated / business.status.updated), para que os sistemas a jusante possam reagir em tempo real.Fases do ciclo de vida
Criação
Uma entidade é criada de uma de três formas:
- Criada automaticamente quando inicia uma sessão com um novo
vendor_data. A entidade é criada com o estadoACTIVE. - Pré-criada através da API com
POST /v3/users/create/ouPOST /v3/businesses/create/. O estado éACTIVEpor predefinição. - Criada na consola por um operador de conformidade: o estado começa em
ACTIVE, a menos que o operador especifique outro.
uuid gerado pela Didit e um identificador vendor_data que pertence ao cliente.Verificação
As sessões são associadas à entidade através de
vendor_data. Cada sessão é executada no fluxo configurado: verificação de identidade, prova de vida, correspondência facial, AML, documentos, consulta ao registo de empresas para KYB, e assim por diante.As sessões concluídas atualizam os contadores agregados da entidade:session_count,approved_count,declined_count,in_review_count- Mapa
features: o estado mais recente de cada funcionalidade em todas as sessões (por exemplo,{ "id_verification": "APPROVED", "aml": "IN_REVIEW" }) - Os campos de perfil são propagados a partir da sessão aprovada mais recente (por exemplo,
full_name,date_of_birth,portrait_image).
Utilização ativa
Quando uma entidade tiver uma ou mais sessões aprovadas, pode:
- Submeter transações que referenciem a entidade através de
vendor_datano payload da transação - Executar monitorização AML contínua: análises periódicas às listas de sanções, PEP e notícias adversas
- Reverificar de forma programada: criar novas sessões para o mesmo
vendor_dataem intervalos regulares - Agregar sinais de risco de sessões e transações
Transições de estado
As alterações de estado de uma entidade acontecem de forma automática ou manual.Transições automáticas
ACTIVE → FLAGGEDquando uma transação ultrapassa o limiar de revisão ou quando uma regra adiciona a entidade a uma lista de vigilância.ACTIVE → BLOCKEDquando uma biometria facial corresponde a uma entrada da lista de bloqueio.
USER (o vendor_data) define o estado como BLOCKED.Transições manuais acontecem quando um analista altera o estado a partir da consola ou quando chama o endpoint update-status.Cada transição emite um webhook user.status.updated ou business.status.updated.Eliminação
As entidades são eliminadas através de
POST /v3/users/delete/ ou POST /v3/businesses/delete/ (em lote). O registo da entidade é removido de forma permanente. Eliminar um utilizador elimina também todos os templates biométricos retidos para esse utilizador após a eliminação da sessão, para que a pessoa deixe de ser identificada como correspondência na deteção de duplicados e na Pesquisa facial.As sessões de verificação não são abrangidas por estes endpoints, tal como as transações. Elimine as sessões com Eliminar sessão ou Eliminar sessões em lote; as transações são eliminadas a partir da consola.Marcas temporais de atividade
As entidades registam a atividade para ajudar a identificar perfis desatualizados ou ativos:
Use estas marcas temporais para filtrar entidades inativas, agendar reverificações ou acionar a monitorização contínua.
Eventos emitidos durante o ciclo de vida
Consulte webhooks de entidades para ver a estrutura dos payloads e a semântica de entrega.
Próximos passos
Associação de vendor_data
Como o
vendor_data associa sessões, transações e entidades entre si.Operações de utilizadores
Criar, atualizar, alterar o estado e eliminar entidades de Utilizador.
Operações de empresas
Criar, atualizar, alterar o estado e eliminar entidades de Empresa.