Saltar al contingut principal

Com funciona

Suposem que un usuari A ha superat la verificació d’usuaris a Service X i ara s’està registrant al soci Service Y. Si Service X accepta compartir la informació sobre A amb Service Y, es pot fer de la manera següent:
  1. Generar el token per compartir (Service X): Service X fa una crida a l’API per generar un share_token segur i de curta durada per a la sessió de verificació d’un usuari concret. Aquest token està destinat exclusivament a l’ús per part de Service Y. Consulta la referència de l’API: Share Session API.
  2. Passar el token al soci (Service X -> Service Y): Service X transmet de manera segura el share_token generat a Service Y a través d’un canal de backend prèviament acordat.
  3. Importar la sessió (Service Y): Service Y utilitza el share_token rebut per fer una crida a l’API per importar les dades de l’usuari. Això crea una còpia completa de la sessió de verificació, inclosos tots els documents i comprovacions, dins del propi entorn de Service Y. Consulta la referència de l’API: Import Shared Session API.

Opcions d’importació

En importar una sessió, Service Y té el control sobre com gestionar els resultats:
  • trust_review: aquest paràmetre booleà determina si Service Y confia en la revisió i en l’estat final (Approved/Declined) de Service X.
    • true: la sessió es copia amb l’estat original. L’usuari completa l’alta a l’instant (o és rebutjat) a Service Y.
    • false: les dades de la sessió es copien, però l’estat s’estableix automàticament a In Review. Això permet a Service Y utilitzar els documents i les dades recollides, però dur a terme el seu propi procés de revisió interna per prendre una decisió final.
  • workflow_id: Service Y ha d’especificar quin dels seus propis fluxos de treball de verificació vol associar a la sessió importada.
  • vendor_data: Service Y pot assignar el seu propi identificador d’usuari intern a la sessió importada.

Consideracions importants

  • Només sessions finalitzades: només es pot generar un token per compartir per a sessions que tinguin un estat finalitzat (Approved, Declined, In Review).
  • Sense duplicats: una sessió concreta només es pot importar un cop a una aplicació de soci determinada. Els intents posteriors seran rebutjats.

KYC reutilitzable vs. compartir KYC via API

Tot i que ambdues funcionalitats faciliten la reutilització de la identitat, tenen finalitats diferents:

❗️ Important: restriccions per compartir dades

Compartir dades personals d’usuaris entre diferents organitzacions està subjecte a requisits legals i regulatoris estrictes. Abans d’utilitzar aquesta funcionalitat, la teva organització és responsable d’assegurar-se que compleix plenament totes les lleis de protecció de dades aplicables, com ara el GDPR a la Unió Europea i el UK GDPR al Regne Unit. Has de:
  1. Establir una base jurídica: assegura’t de disposar d’una base jurídica legítima per compartir les dades. Sovint, això requereix un acord clar per compartir dades entre tu i l’organització sòcia.
  2. Garantir el consentiment de l’usuari: confirma que els teus usuaris han estat degudament informats i han donat el seu consentiment perquè les seves dades es comparteixin amb els teus socis, tal com s’estableix a les teves condicions del servei i a la teva política de privacitat.
  3. Gestionar les transferències internacionals adequadament: si les dades es transfereixen a escala transfronterera (per exemple, de la UE a un país no pertanyent a la UE), has de garantir que s’apliquin les garanties adequades segons exigeix la llei.
Didit proporciona la capacitat tècnica per compartir dades, però la teva organització i els teus socis són els únics responsables de totes les obligacions legals i de compliment normatiu relacionades amb les dades que compartiu. Et recomanem encaridament consultar amb el teu assessor legal abans d’implementar aquesta funcionalitat.
Darrera modificació el 7 de novembre del 2026