Diagrama del cicle de vida
Estats en detall
Canviar l’estat mitjançant
PATCH /v3/users/{vendor_data}/update-status/ o PATCH /v3/businesses/{vendor_data}/update-status/ emet un webhook (user.status.updated / business.status.updated) perquè els sistemes posteriors puguin reaccionar en temps real.Fases del cicle de vida
Creació
Una entitat es crea de tres maneres:
- Creada automàticament quan inicies una sessió amb un
vendor_datanou. L’entitat es crea amb estatACTIVE. - Creada prèviament mitjançant l’API amb
POST /v3/users/create/oPOST /v3/businesses/create/. L’estat per defecte ésACTIVE. - Creada a la consola per un operador de compliment: l’estat comença com a
ACTIVE, tret que l’operador especifiqui una altra cosa.
uuid generat per Didit i un identificador vendor_data que pertany al client.Verificació
Les sessions s’associen a l’entitat mitjançant
vendor_data. Cada sessió passa pel flux de treball configurat: verificació d’identitat, prova de vida, coincidència facial, AML, documents, consulta al registre per a KYB, etc.Les sessions completades actualitzen els comptadors agregats de l’entitat:session_count,approved_count,declined_count,in_review_count- El mapa
features: l’estat més recent de cada funcionalitat en el conjunt de sessions (p. ex.{ "id_verification": "APPROVED", "aml": "IN_REVIEW" }) - Els camps del perfil es propaguen des de l’última sessió aprovada (p. ex.
full_name,date_of_birth,portrait_image).
Ús actiu
Quan una entitat té una o més sessions aprovades, pots:
- Enviar transaccions que facin referència a l’entitat mitjançant
vendor_dataal payload de la transacció - Executar monitoratge AML continu: reescanejos periòdics de les llistes de sancions, PEP i mitjans adversos
- Reverificar segons un calendari: crear noves sessions per al mateix
vendor_dataa intervals regulars - Agregar senyals de risc entre sessions i transaccions
Transicions d'estat
Els canvis d’estat de l’entitat es produeixen automàticament o manualment.Transicions automàtiques
ACTIVE → FLAGGEDquan una transacció supera el llindar de revisió o una regla afegeix l’entitat a una llista de vigilància.ACTIVE → BLOCKEDquan una biometria facial coincideix amb una entrada d’una llista de bloqueig.
USER (el vendor_data) estableix l’estat a BLOCKED.Les transicions manuals es produeixen quan un analista canvia l’estat des de la consola o quan crides l’endpoint update-status.Cada transició emet un webhook user.status.updated o business.status.updated.Eliminació
Les entitats s’eliminen mitjançant
POST /v3/users/delete/ o POST /v3/businesses/delete/ (en lot). El registre de l’entitat s’elimina de manera permanent. En eliminar un usuari, també es purga cada plantilla biomètrica conservada per a aquest usuari després de l’eliminació de les sessions, de manera que la persona deixa de coincidir en la detecció de duplicats i en la Cerca facial.Aquests endpoints no cobreixen les sessions de verificació ni les transaccions. Elimina les sessions amb Eliminar sessió o Eliminar sessions en lot; les transaccions s’eliminen des de la consola.Marques de temps d’activitat
Les entitats registren l’activitat per ajudar-te a identificar perfils inactius o actius:
Fes servir aquestes marques de temps per filtrar entitats inactives, programar reverificacions o activar el monitoratge continu.
Esdeveniments emesos durant el cicle de vida
Consulta els webhooks d’entitats per a les estructures de payload i la semàntica de lliurament.
Següents passos
Vinculació de vendor_data
Com
vendor_data vincula sessions, transaccions i entitats entre si.Operacions amb usuaris
Crear, actualitzar, canviar l’estat i eliminar entitats d’usuari.
Operacions amb empreses
Crear, actualitzar, canviar l’estat i eliminar entitats d’empresa.