> ## 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.

# Pessoas-chave em KYB: API para UBOs e administradores

> Verifique beneficiários efetivos, acionistas e administradores num só fluxo KYB com a Didit. A partir de $2.00 por verificação, sem contratos.

**Pessoas-chave** é o modelo unificado da Didit para cada pessoa singular e entidade coletiva ligada à empresa que está a verificar: UBO, acionistas (individuais e coletivos), administradores, representantes e outras funções de dirigentes. Um único fluxo de Pessoas-chave abrange todos, com envio de verificação consoante a função e uma comparação completa, lado a lado, entre as partes obtidas do registo e as submetidas pelo utilizador.

> [!NOTE]
>
> Para a vista de Empresas sobre as pessoas-chave, em que dirigentes e UBO são agregados entre sessões, consulte [Empresas → Pessoas-chave](https://docs.didit.me/pt/entities/businesses/key-people.md).

## Como funciona

**1. Pré-preenchimento pelo registo (opcional)**

Se o fluxo ativar o pré-preenchimento pelo registo, o ecrã de Pessoas-chave é preenchido previamente com os UBO, acionistas e dirigentes disponíveis, extraídos da verificação de registo.
O utilizador final pode editar, acrescentar ou remover partes antes de submeter, mesmo quando as informações sobre a propriedade ainda estão pendentes.
Os dirigentes já recebidos continuam disponíveis enquanto o relatório de propriedade é recolhido.
Antes da submissão, os resultados tardios preenchem os campos não alterados e acrescentam pessoas em falta, sem substituir edições nem repor partes removidas.
Um editor aberto mantém-se inalterado; o pré-preenchimento adicional é aplicado depois de o candidato o fechar.
Com o pré-preenchimento pelo registo desativado, os candidatos introduzem as pessoas por si próprios, e os resultados tardios do registo não preenchem este formulário.
Os dados do registo recebidos após a submissão continuam a fazer parte das provas do registo, mas não alteram a lista de pessoas submetida nem criam automaticamente sessões de verificação filhas adicionais.

**2. Submissão a partir do fluxo alojado**

O utilizador final submete a lista final de pessoas-chave através do fluxo de verificação alojado. Por predefinição, não tem de chamar este passo diretamente: ele acontece dentro do fluxo de KYB cujo URL forneceu a partir de [Criar sessão](https://docs.didit.me/pt/sessions-api/create-session.md).
Para manter a sua própria interface, utilize os endpoints de [rascunho de interveniente](https://docs.didit.me/pt/sessions-api/kyb-create-party-draft.md) e de [submeter intervenientes](https://docs.didit.me/pt/sessions-api/kyb-submit-parties.md).

**3. Encaminhamento da verificação consoante a função**

Para cada interveniente submetido, a Didit verifica as definições de verificação configuradas para a função:

* Aplica o limiar de propriedade do fluxo: os UBO e acionistas abaixo da percentagem configurada não requerem verificação individual.
* Respeita o indicador "skip verification" definido pelo utilizador final, se a função permitir ignorar a verificação.
* Cria uma sessão filha de Verificação de utilizadores (KYC) para os intervenientes que são pessoas e requerem KYC.
* Cria uma subsessão filha de KYB para UBO que sejam pessoas coletivas, quando o KYB aninhado está ativado no fluxo.

**4. Progressão do estado**

O estado da funcionalidade Pessoas-chave passa para `Awaiting User` enquanto alguma sessão filha obrigatória ainda estiver em curso. Quando todas as sessões filhas terminam, o estado passa a `Approved`, `Declined` ou `In Review`, consoante os resultados.

## Funções recolhidas

As pessoas-chave podem ter uma ou mais das seguintes funções. Uma mesma pessoa pode ter várias ao mesmo tempo (por exemplo, administrador **e** acionista). A taxonomia completa:

| Categoria | Funções |
| - | - |
| **Propriedade** | `ubo`, `shareholder`, `beneficiary`, `settlor`, `protector`, `investor` |
| **Governação / representação** | `director`, `non_executive_director`, `chairman`, `secretary`, `representative`, `authorized_signatory`, `trustee`, `company_officer`, `founder`, `legal_advisor`, `other` |

Cada função pode ser configurada individualmente no fluxo: ativada ou desativada, obrigatória ou opcional para KYC, associada a um fluxo KYC específico e com a opção de ignorar a verificação. Consulte [Propriedade](https://docs.didit.me/pt/business-verification/ownership.md) para os detalhes do envio da verificação.

## Dados recolhidos por pessoa-chave

O fluxo alojado pede um conjunto predefinido de campos e campos personalizados adicionais configurados no fluxo. Consulte [Propriedade → Campos recolhidos](https://docs.didit.me/pt/business-verification/ownership.md#dados-recolhidos-para-cada-pessoa-chave) para a lista completa.

## Confirmação do registo

Antes do passo de Pessoas-chave, o utilizador final revê os dados da empresa extraídos da verificação de registo e pode editar opcionalmente quaisquer campos. O fluxo alojado armazena depois:

* Os **detalhes do registo** que a Didit normalizou a partir da verificação de registo (`registry_data`).
* Os **dados confirmados pelo utilizador** (`user_provided_data`), com um carimbo temporal que marca o momento em que o utilizador confirmou.
* Uma vista canónica agregada nos campos da empresa de nível superior: os dados confirmados pelo utilizador, quando existem, ou, caso contrário, os dados do registo.

Consulte [Dados da empresa → Dados do registo vs. dados fornecidos pelo utilizador](https://docs.didit.me/pt/business-verification/company-data.md#dados-do-registo-vs-dados-fornecidos-pelo-utilizador) para o modelo completo.

## Formato na resposta de decisão

Após a submissão, as pessoas-chave recolhidas aparecem na decisão de KYB em `key_people_checks[]`, repartidas por dois grupos: **registo** (o que o fornecedor divulgou) e **submetidas** (o que o administrador da empresa confirmou através do fluxo). Inclui também um `ubo_kyc_summary`, que resume o progresso do KYC dos UBO. Consulte a [referência de key\_people\_checks](https://docs.didit.me/pt/business-verification/response-schema.md#key_people_checks) completa.

## Comportamento na nova submissão

* **Pessoas-chave** e **Verificação de Registo** não podem ser submetidas de novo diretamente. Para reverificar uma pessoa específica, submeta de novo a respetiva sessão filha de KYC.
* Quando uma sessão filha de KYC é submetida de novo, o estado da funcionalidade-pai Pessoas-chave regressa automaticamente a `Awaiting User`.
* Quando a sessão filha submetida de novo termina, o estado da funcionalidade principal é novamente agregado com base nos estados de todas as sessões filhas.
* Uma sessão filha que tenha sido eliminada, ou que tenha expirado antes de a pessoa a iniciar, não pode ser submetida de novo: [regenere o interveniente](https://docs.didit.me/pt/sessions-api/regenerate-kyb-party.md) para emitir uma nova ligação para o mesmo interveniente.

## Quanto tempo dura a ligação de verificação de uma pessoa-chave

A sessão KYC filha de uma pessoa-chave segue o tempo de expiração da sessão do fluxo KYC configurado para a sua função, e não o do fluxo KYB. Se associar uma função a um fluxo KYC que permite quatro semanas, a ligação dessa pessoa continua utilizável durante quatro semanas, mesmo que a sessão empresarial esteja definida para expirar mais cedo.

O valor é uma definição por fluxo, de 1 hora a 4 semanas (`session_expiration_time`, em segundos), em *Fluxos → \[Fluxo KYC] → Definições*.

A expiração altera o que pode fazer com a parte. Uma ligação que expirou antes de a pessoa começar, como uma cuja sessão foi eliminada, pode ser reemitida com [Regenerar sessão KYC de pessoas-chave](https://docs.didit.me/pt/sessions-api/regenerate-kyb-party.md). As sessões eliminadas são elegíveis mesmo que a pessoa já tenha começado ou concluído a verificação. As sessões importadas não são elegíveis por expiração; têm de ter sido eliminadas. Uma sessão que não foi eliminada e que a pessoa já tinha começado não é elegível por expiração.

## Opções de configuração

Todo o comportamento das pessoas-chave é configurado por fluxo na Business Console:

| Definição | O que controla |
| - | - |
| **Pré-preenchimento pelo registo** | Preencher previamente o formulário de pessoas-chave com dados do registo |
| **Campos extra — pessoas** | Campos personalizados a recolher para cada parte do tipo pessoa |
| **Campos extra — empresas** | Campos personalizados a recolher para cada parte do tipo empresa |
| **Limiar de propriedade do UBO** | Percentagem mínima de propriedade para classificar alguém como UBO |
| **Limiar de propriedade do acionista** | Percentagem mínima de propriedade para classificar alguém como acionista |
| **Definições por função** | Para cada função: ativada/desativada, exigir KYC, fluxo KYC a utilizar, dispensável |
| **UBO empresarial com KYB aninhado** | Quando ativada, os UBO empresariais acionam a sua própria sessão KYB filha |
| **Reutilizar indivíduos verificados** | Ver [Reutilização de indivíduos verificados em verificações KYB](#reutilização-de-indivíduos-verificados-em-verificações-kyb) abaixo |
| **Notificar partes por e-mail** | Enviar automaticamente a cada pessoa-chave um e-mail com a respetiva ligação de verificação |

Configure em *Fluxos → \[Fluxo KYB] → Pessoas-chave* na Business Console.

## Reutilização de indivíduos verificados em verificações KYB

Quando **Reutilizar indivíduos verificados** está ativado num fluxo (o valor predefinido), uma pessoa-chave não tem de refazer o KYC sempre que aparece numa nova verificação KYB. A Didit procura um KYC **Aprovado** existente de uma verificação KYB anterior e associa-o à nova parte, em vez de criar uma nova sessão KYC filha.

> [!NOTE]
>
> Este mecanismo é distinto da [KYC reutilizável](https://docs.didit.me/pt/core-technology/reusable-kyc/overview.md), que permite a um *utilizador final* levar voluntariamente uma sessão concluída entre aplicações separadas integradas com a Didit, através de um token de partilha ou importação. A reutilização KYB desta página é automática, configurada no fluxo e limitada às pessoas-chave de uma única aplicação: não há token de partilha nem qualquer ação do utilizador final.

**Correspondência.** Um candidato é encontrado comparando o nome completo da pessoa submetida (sem distinguir maiúsculas de minúsculas, e sem espaços no início ou no fim) com as pessoas-chave das outras verificações KYB da aplicação. Não existe nenhum sinal de correspondência adicional: não é exigida nem verificada qualquer correspondência por número de documento, e-mail ou telefone. Um nome introduzido com uma grafia diferente, com um nome intermédio ou por transliteração não corresponde e, em casos raros, duas pessoas diferentes com o mesmo nome podem corresponder. Tenha isto em conta ao rever os resultados de pessoas-chave.

**Âmbito.** A correspondência abrange todas as outras verificações KYB que pertencem à *mesma aplicação*, e não apenas a verificação KYB atual nem outras aplicações da sua organização. Uma pessoa verificada como UBO na Empresa A pode ser encontrada quando mais tarde aparecer como administrador na Empresa B, desde que ambas as verificações sejam executadas na mesma aplicação.

**Estados elegíveis.** Só a verificação KYC **aprovada** mais recente de uma parte é elegível para reutilização. Uma verificação KYC **recusada** para esse nome bloqueia a reutilização por completo: a parte fica sinalizada e é pedido um novo KYC, em vez de reutilizar a recusada. Uma verificação KYC que ainda está **em análise** nunca é considerada candidato.

**Conservação de dados.** A correspondência só considera sessões KYC criadas aproximadamente no último ano e que não tenham sido eliminadas. Se a única sessão correspondente estiver fora desse período, ou se a pessoa ou a organização a tiver eliminado, a verificação não encontra nenhuma correspondência elegível e pede silenciosamente um novo KYC. Nunca falha nem bloqueia a submissão de pessoas-chave.

**Faturação.** Um KYC reutilizado não é faturado novamente. Associar uma sessão já aprovada à nova parte não tem custo adicional; é cobrado apenas uma vez, no KYC original.

```txt Example theme={null}
Company A: Jane Doe submitted as UBO, KYC approved.
Company B (same application): Jane Doe submitted as a director.
"Reuse verified individuals" is enabled, so Company B's Key People
check links Jane's existing approved KYC instead of requesting a
new one - free, and instantly Approved for that party.
```

## Próximos passos

> [card] [Propriedade](https://docs.didit.me/pt/business-verification/ownership.md)
>
> Campos recolhidos, dados personalizados e reconciliação entre registo e dados submetidos.

> [card] [Dirigentes e representantes](https://docs.didit.me/pt/business-verification/officers.md)
>
> Funções de governação no modelo de pessoas-chave.

> [card] [Esquema de resposta](https://docs.didit.me/pt/business-verification/response-schema.md#key_people_checks)
>
> Referência campo a campo de `key_people_checks[]`.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.