Saltar al contenido principal

Cómo funciona

Supongamos que un usuario A superó la verificación de usuario en Service X y ahora se está registrando en el socio Service Y. Si Service X acepta compartir la información sobre A con Service Y, el proceso es el siguiente:
  1. Generar el token para compartir (Service X): Service X llama a la API para generar un share_token seguro y de corta duración para la sesión de verificación de un usuario concreto. Este token está destinado exclusivamente a Service Y. Consulta la referencia de la API: Share Session API.
  2. Enviar el token al socio (Service X -> Service Y): Service X transmite de forma segura el share_token generado a Service Y a través de un canal de backend acordado previamente.
  3. Importar la sesión (Service Y): Service Y usa el share_token recibido para llamar a la API e importar los datos del usuario. Esto crea una copia completa de la sesión de verificación, con todos los documentos y comprobaciones, dentro del propio entorno de Service Y. Consulta la referencia de la API: Import Shared Session API.

Opciones de importación

Al importar una sesión, Service Y decide cómo gestionar los resultados:
  • trust_review: este parámetro booleano determina si Service Y confía en la revisión y en el estado final (Approved/Declined) de Service X.
    • true: la sesión se copia con su estado original. El usuario queda dado de alta (o rechazado) al instante en Service Y.
    • false: los datos de la sesión se copian, pero el estado se establece automáticamente en In Review. Así, Service Y puede usar los documentos y datos recopilados, pero llevar a cabo su propio proceso de revisión interna para tomar una decisión final.
  • workflow_id: Service Y debe indicar cuál de sus propios flujos de verificación (workflows) se asocia a la sesión importada.
  • vendor_data: Service Y puede asignar su propio identificador interno de usuario a la sesión importada.

Consideraciones importantes

  • Solo sesiones finalizadas: solo se puede generar un token para compartir en sesiones con un estado finalizado (Approved, Declined, In Review).
  • Sin duplicados: una sesión concreta solo se puede importar una vez en una aplicación asociada determinada. Los intentos posteriores se rechazarán.

KYC reutilizable frente a compartir KYC mediante API

Aunque ambas funciones facilitan la reutilización de la identidad, tienen propósitos distintos:

❗️ Importante: restricciones al intercambio de datos

Compartir datos personales de usuarios entre distintas organizaciones está sujeto a estrictos requisitos legales y regulatorios. Antes de usar esta función, tu organización es responsable de garantizar el pleno cumplimiento de todas las leyes de protección de datos aplicables, como el RGPD en la Unión Europea y el UK GDPR en el Reino Unido. Debes:
  1. Establecer una base jurídica: asegúrate de contar con una base jurídica legítima para compartir los datos. Esto suele requerir un acuerdo claro de intercambio de datos entre tu organización y la organización asociada.
  2. Garantizar el consentimiento del usuario: confirma que tus usuarios han sido debidamente informados y han dado su consentimiento para que sus datos se compartan con tus socios, según lo establecido en tus términos de servicio y tu política de privacidad.
  3. Gestionar adecuadamente las transferencias internacionales: si los datos se transfieren entre países (por ejemplo, de la UE a un país fuera de la UE), debes garantizar que existan las salvaguardas adecuadas que exige la ley.
Didit ofrece la capacidad técnica para compartir datos, pero tu organización y tus socios son los únicos responsables de todas las obligaciones legales y de cumplimiento relacionadas con los datos que compartan. Te recomendamos encarecidamente consultar con tu asesor jurídico antes de implementar esta función.
Última modificación el 1 de noviembre de 2026