Saltar para o conteúdo principal

Como funciona

Suponhamos que um utilizador A passou na verificação de utilizadores no Service X e está agora a registar-se no parceiro Service Y. Se o Service X concordar em partilhar as informações sobre A com o Service Y, tal pode ser feito da seguinte forma:
  1. Gerar token de partilha (Service X): O Service X faz uma chamada de API para gerar um share_token seguro e de curta duração para a sessão de verificação de um utilizador específico. Este token destina-se a ser utilizado apenas pelo Service Y. Consulte a Referência da API: Share Session API.
  2. Passar o token ao parceiro (Service X -> Service Y): O Service X transmite de forma segura o share_token gerado para o Service Y através de um canal de backend previamente acordado.
  3. Importar sessão (Service Y): O Service Y utiliza o share_token recebido para fazer uma chamada de API a fim de importar os dados do utilizador. Isto cria uma cópia completa da sessão de verificação, incluindo todos os documentos e verificações, no próprio ambiente do Service Y. Consulte a Referência da API: Import Shared Session API.

Opções de importação

Ao importar uma sessão, o Service Y tem controlo sobre como processar os resultados:
  • trust_review: Este parâmetro booleano determina se o Service Y confia na revisão e no estado final (Approved/Declined) do Service X.
    • true: A sessão é copiada com o estado original. O utilizador é integrado instantaneamente (ou rejeitado) no Service Y.
    • false: Os dados da sessão são copiados, mas o estado é automaticamente definido como In Review. Isto permite ao Service Y utilizar os documentos e dados recolhidos, mas realizar o seu próprio processo de revisão interna para tomar uma decisão final.
  • workflow_id: O Service Y tem de especificar qual dos seus próprios fluxos de verificação deve associar à sessão importada.
  • vendor_data: O Service Y pode atribuir o seu próprio identificador interno de utilizador à sessão importada.

Considerações importantes

  • Apenas sessões finalizadas: Um token de partilha só pode ser gerado para sessões que tenham um estado finalizado (Approved, Declined, In Review).
  • Sem duplicados: Uma sessão específica só pode ser importada uma vez numa determinada aplicação parceira. Tentativas subsequentes serão rejeitadas.

KYC reutilizável vs. partilha de KYC via API

Embora ambas as funcionalidades facilitem a reutilização de identidade, servem finalidades diferentes:

❗️ Importante: Restrições à partilha de dados

A partilha de dados pessoais de utilizadores entre diferentes organizações está sujeita a requisitos legais e regulamentares rigorosos. Antes de utilizar esta funcionalidade, a sua organização é responsável por garantir a total conformidade com todas as leis de proteção de dados aplicáveis, tais como o RGPD na União Europeia e o UK GDPR no Reino Unido. Deve:
  1. Estabelecer uma base jurídica: Garantir que dispõe de uma base jurídica legítima para partilhar os dados. Isto exige frequentemente um acordo claro de partilha de dados entre si e a organização parceira.
  2. Garantir o consentimento do utilizador: Confirmar que os seus utilizadores foram devidamente informados e consentiram na partilha dos seus dados com os seus parceiros, conforme delineado nos seus termos de serviço e na sua política de privacidade.
  3. Gerir transferências internacionais de forma adequada: Se os dados forem transferidos além-fronteiras (por exemplo, da UE para um país fora da UE), deve garantir que são implementadas salvaguardas adequadas, conforme exigido por lei.
A Didit fornece a capacidade técnica para a partilha de dados, mas a sua organização e os seus parceiros são os únicos responsáveis por todas as obrigações legais e de conformidade relacionadas com os dados que partilha. Recomendamos vivamente que consulte a sua assessoria jurídica antes de implementar esta funcionalidade.
Última modificação em 7 de novembro de 2026