Els Orchestrated Workflows de Didit són la manera més potent i flexible de dissenyar i desplegar recorreguts de verificació d’identitat complets i de diversos passos.
Aquesta lliçó de Didit Academy construeix un flux de treball de verificació a la consola real, des de la plantilla fins al flux publicat: triar comprovacions a cada node, regles i llindars, bifurcacions AML, nodes de webhook i reversió de versions.
Aquesta via d’integració et permet aprofitar tota la intel·ligència de la plataforma Didit V2, i crear seqüències de verificació sofisticades amb el nostre constructor visual sense codi. Defineixes la lògica una sola vegada a la Business Console, i Didit gestiona tota l’experiència de l’usuari final, la gestió d’estats i els passos condicionals.
Tria aquesta via quan necessitis una solució completa, de principi a fi, per a l’alta d’usuaris (KYC), la verificació d’edat o la reautenticació, i vulguis llançar-la ràpidament amb un esforç de desenvolupament mínim i mantenir el màxim control sobre el procés.
Mètodes d’identitat per país
A la Verificació d’identitat, obre Països i mètodes d’identificació permesos per configurar la captura de documents, la consulta sense document i les carteres d’identitat digital de cada país.
La configuració addicional conté els subtipus de document, els intents de consulta i les regles d’alternativa.
La consulta sense document utilitza els preus del servei de Validació en bases de dades de la teva organització.
Cada intent completat es cobra per separat, incloses les coincidències parcials i els casos sense coincidències: dos intents completats signifiquen dos cobraments.
Els errors de format i les fallades del proveïdor que no retornen cap resposta no es cobren.
Si diversos serveis de bases de dades responen a un mateix intent, els preus aplicables de cada servei se sumen.
El valor per defecte és un intent abans de l’alternativa, configurable d’un a cinc.
La captura de documents es cobra a part quan una consulta completada passa als documents.
Les aplicacions de producció només poden activar les carteres disponibles per a producció.
Les carteres pendents de llançament continuen desactivades.
Les aplicacions de sandbox poden provar totes les carteres del catàleg amb resultats simulats; la disponibilitat al sandbox no indica disponibilitat en producció.
Consulta Proves en sandbox per veure els escenaris de fallada de consultes i carteres.
Versionat dels fluxos de treball
Els fluxos de treball admeten versionat d’esborranys i publicació. Això vol dir que pots iterar amb seguretat sobre el teu flux de treball sense afectar les sessions en producció:
- Les versions d’esborrany es poden editar completament: afegeix, elimina o reestructura nodes lliurement
- La publicació d’un esborrany crea una versió immutable que utilitzaran les noves sessions
- Les versions anteriors es conserven, de manera que pots inspeccionar la configuració exacta utilitzada en qualsevol sessió passada
- Les sessions sempre fan referència a la versió concreta amb què es van crear, cosa que garanteix la coherència fins i tot després de publicar actualitzacions
Per fer canvis en un flux de treball publicat, crea un esborrany nou a partir de la versió publicada, edita’l i publica’l quan estigui a punt. L’historial de versions està disponible a través de la Management API.
Dues maneres de construir fluxos de treball
Didit ofereix dos enfocaments diferents per crear fluxos de treball de verificació, perquè puguis triar el nivell de complexitat que més s’ajusti a les teves necessitats:
1. Mode simple: constructor basat en plantilles
El Mode simple és ideal per començar ràpidament. Selecciona una plantilla prefabricada, activa o desactiva les funcionalitats que necessitis i ja ho tens a punt.
Ideal per a:
- Configuració i desplegament ràpids
- Fluxos de verificació estàndard
- Equips que s’inicien en la verificació d’identitat
- Casos d’ús que encaixen amb patrons habituals
Funcionament:
- Tria una plantilla de flux de treball (KYC, Verificació d’edat, etc.)
- Activa o desactiva funcionalitats (Prova de vida, Coincidència facial, AML, etc.)
- Configura els paràmetres bàsics de cada funcionalitat
- Publica i comença a verificar
2. Mode avançat: constructor visual de grafs
El Mode avançat desbloqueja tota la potència del motor d’orquestració de Didit. Construeix fluxos de verificació complexos i condicionals amb el nostre editor visual de grafs, amb nodes arrossegables, branques i lògica personalitzada.
Ideal per a:
- Recorreguts de verificació complexos amb múltiples camins
- Lògica condicional basada en dades de l’usuari o en resultats de verificació
- Regles de negoci personalitzades i branques
- Requisits de compliment de nivell empresarial
Capacitats principals:
- Editor visual de nodes: arrossega, deixa anar i connecta nodes en un llenç infinit
- Connexions intel·ligents: arrossega des del punt de connexió d’un node fins a un espai buit per crear i connectar un node nou a l’instant
- Branques condicionals: encamina els usuaris segons les dades extretes, l’estat de la verificació, el país, el tipus de document, el subtipus de document, la data d’emissió, l’edat, les rutes de resposta JSON del webhook o regles personalitzades
- Automatització d’accions: afegeix etiquetes, defineix metadades o encamina a revisió manual segons els resultats del flux
- Dreceres de teclat: desfer (Ctrl/Cmd+Z), refer (Ctrl/Cmd+Shift+Z), suprimeix (Delete/Backspace)
- Zoom i desplaçament: navega per fluxos complexos amb zoom amb la roda del ratolí i desplaçament arrossegant
Tipus de nodes del constructor de grafs
Categories de nodes de funcionalitat
Funcionalitats interactives amb l’usuari (poden iniciar un flux de treball):
- Verificació d’identitat (OCR)
- Prova de vida
- Coincidència facial
- Estimació d’edat
- Verificació de telèfon
- Verificació de correu electrònic
- Qüestionari
- Comprovant de domicili
- Document AI
- NFC / ePassport
Funcionalitats només de backend (s’executen automàticament, sense interacció de l’usuari):
- Cribratge AML (necessita un pas de Verificació d’identitat, KYB Registry o Document AI abans - vegeu Entitat cribrada)
- Validació en bases de dades (requereix primer OCR)
- Anàlisi de dispositiu i IP
Nota: les funcionalitats només de backend es marquen amb un indicador especial al constructor i s’executen automàticament, sense interacció de l’usuari, quan es compleixen les seves dependències.
La primera pestanya de configuració de cada node de funcionalitat comença amb un control Motor de verificació: executa la comprovació amb el motor propi de Didit o canvia’l a un proveïdor de tercers que connectis des del Marketplace, amb un canvi automàtic a Didit si aquest proveïdor no està disponible.
Entitat cribrada
El Cribratge AML sol saber a qui cribra gràcies al pas que hi ha just abans: la persona que un pas de Verificació d’identitat ha llegit d’un document, o l’empresa retornada per un pas de KYB Registry. Hi ha fluxos que no tenen cap dels dos. Un flux construït íntegrament amb Document AI - documents no estandarditzats, com un certificat fiscal o una escriptura de constitució notarial - ja conté el nom, la data de naixement, el número de document i el país, però sota les teves pròpies claus de camp.
La pestanya Avançat del node AML és on associes aquestes claus amb el cribratge:
- Tipus d’entitat: cribra una persona, o l’empresa que apareix en un document carregat. Un node d’empresa cerca en registres d’empreses en lloc de persones.
- Orígens dels camps: assigna cadascuna de les quatre entrades de cribratge (nom, data de naixement, país, número de document) a un camp de Document AI, a una resposta del qüestionari o a un valor que enviïs en crear la sessió (
expected_details / metadata). Un camp de Document AI que ja hagis anomenat full_name es detecta automàticament.
- Dades de cribratge incompletes: què passa quan el cribratge s’executa amb dades d’identitat incompletes. La revisió manual és el valor per defecte; tria Cap acció només quan sàpigues que el flux només conté un nom.
Hi ha dues coses que cal saber abans de confiar-hi. Sense un pas de Verificació d’identitat o de KYB Registry, el nom és obligatori: el flux no es pot publicar fins que s’hi introdueixi un valor, perquè no hi ha cerca sense nom. I la precisió de l’AML depèn directament de quants identificadors facilites: un cribratge només amb el nom és el que genera el volum de falsos positius del qual es queixen els revisors, així que mapeja la data de naixement i el país sempre que el document els contingui.
Quin registre llegeix una condició. Una condició de branca està vinculada al node de funcionalitat amb què es va construir i llegeix el resultat d’aquest node. Quan un sol node ha produït més d’un registre, la condició llegeix el més recent. Això és especialment important per a Anàlisi de dispositiu i IP: Didit registra una observació per cada dispositiu i adreça IP des d’on s’obre una sessió, de manera que un usuari que canvia de telèfon o de xarxa durant la sessió deixa diversos registres al mateix node. Una regla com IP COUNTRY is in [...] s’avalua aleshores contra l’observació més recent, la mateixa que apareix al primer lloc del panell Anàlisi de dispositiu i IP de la sessió i a la matriu ip_analyses del payload de la decisió. Les sessions amb més d’una observació porten també l’avís MULTIPLE_DEVICES_IN_SESSION, que indica que cal revisar la llista completa i no només el resultat de la branca.
Valors de país. Les condicions de país es comparen pel país en si mateix, no per la notació. Escull els països del selector de camps i Didit normalitza els dos costats de la comparació, de manera que una regla escrita en ISO 3166-1 alpha-3 (UKR) continua coincidint amb un valor capturat com a alpha-2 (UA).
Valors absents, valors buits i comparacions negatives. Un camp sense cap valor (el document no el porta, la clau de metadades no s’ha enviat, la funcionalitat no s’ha executat) només coincideix amb is empty i equals not_defined; qualsevol altra comparació - equals, contains, greater than, i també not equals i not in - no coincideix, i el node de branca passa a la branca següent. Un camp que conté una cadena buida és un valor, no un camp absent: una sessió creada amb "metadata": {"credential_state": ""} falla metadata.credential_state equals IL, però passa not equals IL, not in [IL, MA, NJ] i equals "" (is empty coincideix en tots dos casos). Per tant, una branca que aprova amb una comparació negativa aprova una sessió l’estat de la qual s’ha enviat buit, mentre que la mateixa sessió sense la clau pren la branca de reserva. Quan encaminis per not equals o not in, afegeix metadata.<key> is not empty a la mateixa branca (lògica AND) perquè tots dos casos acabin on hauria d’acabar un valor absent. Les branques s’avaluen en ordre i la primera coincidència guanya; la branca de reserva (la que no té condicions) només s’agafa quan cap altra branca no ha coincidit, així que assigna a cada node de branca una branca de reserva que acabi on vols que acabi un valor inesperat. Una sessió que arriba a En revisió sense cap avís en cap funcionalitat ha estat encaminada allà per un node d’estat del graf, no per una comprovació; la branca de reserva d’un node de branca és la causa habitual.
Metadades de la sessió. Els valors que envies a metadata en crear la sessió estan disponibles a cada branca com a metadata.<key> i es poden comparar amb un valor fix o amb un altre camp de la sessió (per exemple metadata.min_age <= Age). Els números es comparen com a números, de manera que 18 i "18" es comporten igual.
Mode sandbox / de prova. Les condicions de branca, les metadades i els nodes d’estat s’executen al sandbox exactament igual que en producció, i el sandbox mai no posa una sessió en revisió per si sol. La diferència és el document: una sessió de sandbox porta un document fabricat sense estat o regió dels EUA, així que les condicions Region no hi poden coincidir. Consulta què no conté el document fabricat per saber com provar els fluxos que depenen de l’estat.
Reenviaments. Els nodes de branca s’avaluen a cada intent, inclosos els reenviaments. Quan envies una sessió de nou per a passos específics, les branques i les accions col·locades entre aquests passos s’executen de nou mentre l’usuari els torna a completar, amb les dades del nou intent. Un usuari que es trasllada a una jurisdicció restringida entre intents és, per tant, encaminat per la branca que la cobreix, i una branca que acaba en un resultat amb estat Rebutjada finalitza allà la sessió reenviada.
Veure quina branca ha pres una sessió. Cada decisió de branca que el flux pren mentre s’executa una sessió, i cada node de resultat al qual arriba, queden registrats a la línia de temps d’esdeveniments de la sessió (Detall de la sessió a la consola > Events, i GET /v3/session/{id}/decision/?include=events). Una fila Encaminament del flux indica el node de branca, la condició que ha coincidit i el node on ha continuat la sessió, o bé diu que cap condició no ha coincidit i que s’ha seguit l’aresta de reserva del node. Una fila Resultat del flux indica el node d’estat que ha establert l’estat de la sessió. Quan un flux envia una sessió a En revisió sense que cap funcionalitat l’hagi marcat, aquestes files mostren el camí que ha seguit, incloses les arestes de reserva i el node de resultat al qual han portat. Les decisions manuals posteriors no reescriuen aquests esdeveniments del flux. La falta d’entrada és una possible causa: les condicions que exigeixen un valor metadata.* present no coincideixen quan la clau s’ha omès en crear la sessió. Les condicions que proven explícitament una entrada absent, com is_empty o equals amb not_defined, sí poden coincidir amb aquesta mateixa clau absent. L’aresta de reserva només s’agafa quan cap branca no coincideix, incloses les branques else, i porta al node connectat a la sortida per defecte. Consulta esdeveniments de la sessió per als payloads dels esdeveniments.
Plantilles de flux de treball: el teu punt de partida
Pensa en les plantilles no com a tipus rígids, sinó com a punts de partida preconfigurats i intel·ligents pensats per a casos d’ús habituals. En el mode simple, estan a punt per utilitzar-se. En el mode avançat, ofereixen una base que pots personalitzar amb àmplia flexibilitat.
Plantilles disponibles
1. Flux de treball KYC
La solució completa per a l’alta de nous usuaris i per complir plenament els requisits de KYC.
- Comença amb: Verificació principal del document d’identitat.
- Funcionalitats afegides habitualment:
[+] Prova de vida: Assegura que l’usuari és físicament present i evita la suplantació.[+] Coincidència facial 1:1: Compara biomètricament la selfie de l’usuari amb la fotografia del seu document d’identitat.[+] Cribratge AML: Comprova els usuaris contra llistes globals de sancions, PEP i mitjans adversos.[+] Verificació NFC: Afegeix una capa de seguretat de nivell governamental llegint els xips dels passaports electrònics i dels DNI electrònics.[+] Comprovant de domicili (PoA): Verifica l’adreça de residència de l’usuari.[+] Verificació de telèfon: Valida la titularitat del número de telèfon com a factor addicional.[+] Verificació de correu electrònic: Valida la titularitat de l’adreça de correu electrònic com a factor addicional.[+] Validació en bases de dades: Valida contra bases de dades oficials del govern i de crèdit.[+] Qüestionari: Recull atestacions estructurades i documents de suport mitjançant formularis personalitzables.[+] Anàlisi de dispositiu i IP: Analitza el risc de la ubicació i de la connexió.
2. Flux de treball adaptatiu de verificació d’edat
Un flux de baixa fricció i que preserva la privadesa, per a serveis amb restricció d’edat.
- Comença amb: Estimació d’edat basada en selfie.
- Lògica clau:
- Si l’edat estimada està clarament per sobre del teu llindar (per exemple, 25+ anys estimats per a un servei de 18+), l’usuari supera la verificació a l’instant.
- Si l’estimació està per sota o dins d’una “zona de marge” (per exemple, 16-20 anys estimats), pots configurar el flux de treball perquè activi automàticament una alternativa de verificació d’identitat completa per confirmar la data de naixement exacta.
- Funcionalitats afegides habitualment:
[+] Anàlisi de dispositiu i IP: Restringeix l’accés segons la ubicació geogràfica.
3. Flux de treball d’autenticació biomètrica
Una manera ràpida i segura de tornar a verificar usuaris que ja han estat registrats, sense demanar-los de nou els documents.
- Comença amb: Una prova de vida per confirmar que l’usuari és present.
- Lògica principal:
- El sistema fa una coincidència facial entre la nova selfie en directe i la plantilla biomètrica de confiança obtinguda en la verificació KYC inicial aprovada de l’usuari.
- Si l’usuari ja té una cara emmagatzemada sota el mateix
vendor_data (la cara de la prova de vida aprovada, la fotografia del passaport electrònic, el retrat del document d’identitat o una cara d’un perfil registrat), pots ometre portrait_image en crear la sessió i Didit reutilitza automàticament la cara emmagatzemada. En cas contrari, passa portrait_image (imatge codificada en Base64, màxim 2 MB); sense cap dels dos, la creació de la sessió falla amb 400.
- Funcionalitats afegides habitualment:
[+] Verificació de telèfon: Vincula l’adreça a un número de telèfon verificat.[+] Verificació de correu electrònic: Valida la titularitat de l’adreça de correu electrònic com a factor addicional.[+] Anàlisi de dispositiu i IP: Marca els intents d’inici de sessió sospitosos des d’ubicacions noves.
4. Flux de treball de verificació d’adreça
Un flux dedicat per als casos en què el comprovant de domicili (PoA) és el requisit principal.
- Comença amb: L’usuari envia un comprovant de domicili (per exemple, una factura de serveis o un extracte bancari).
- Lògica principal: La nostra IA extreu i valida el nom i l’adreça del document.
- Funcionalitats afegides habitualment:
[+] Verificació de telèfon: Vincula l’adreça a un número de telèfon verificat.[+] Verificació de correu electrònic: Valida la titularitat de l’adreça de correu electrònic com a factor addicional.[+] Anàlisi de dispositiu i IP: Compara l’adreça del document amb la geolocalització actual de l’usuari per oferir més garantia.
5. Flux de treball de verificació mitjançant qüestionari
Un flux específic per als casos en què el teu objectiu principal és recollir atestacions estructurades i documents de suport mitjançant formularis personalitzables.
- Comença amb: Qüestionari.
- Lògica principal: El sistema presenta el qüestionari configurat (seccions, contingut traduït, camps obligatoris, càrregues de fitxers).
- Funcionalitats afegides habitualment:
[+] Anàlisi de dispositiu i IP: Afegeix el context d’ubicació i de connexió als enviaments del qüestionari.
Personalització completa
Cada funcionalitat dins d’un flux de treball es pot personalitzar encara més amb paràmetres específics per adaptar-se als teus requisits exactes. Explora la configuració de cada comprovació al constructor.
Regles de construcció segons l’estat civil
En el mode avançat, pots utilitzar el camp OCR kyc.marital_status en branques condicionals i regles d’estat personalitzades. Tria el valor des del selector de camps perquè la regla utilitzi l’enumeració compatible i no text de format lliure. Si el document no proporciona l’estat civil, el valor queda buit i s’aplica la teva branca alternativa.
El copilot del flux de treball també pot crear i configurar passos de Validació en bases de dades en una sola acció. Quan li demanis que afegeixi aquesta comprovació, indica els països que necessites; la consola resol el servei compatible per a cada país i mostra la configuració desada al llenç.
Comparació entre mode simple i mode avançat
Flux d’integració
Integrar un flux de treball orquestrat és senzill. El teu servidor crea una sessió amb Didit, rep una URL única i redirigeix el teu usuari a aquesta URL. Didit gestiona la resta i notifica al teu servidor els resultats mitjançant webhooks.
Casos d’ús habituals
| Cas d’ús | Plantilla recomanada | Mode recomanat | Funcionalitats suggerides |
|---|
| Verificació d’identitat bàsica | KYC | Simple | Prova de vida, Coincidència facial |
| Alta de seguretat elevada | KYC | Avançat | NFC, Prova de vida, Coincidència facial, AML, Verificació de telèfon |
| Contingut o serveis amb restricció d’edat | Verificació d’edat adaptativa | Simple | Verificació d’identitat com a alternativa |
| Autenticació d’usuaris recurrents | Autenticació biomètrica | Simple | Anàlisi de dispositiu i IP |
| Verificació d’adreça | Comprovant de domicili | Simple | Verificació de telèfon |
| Alta en serveis financers | KYC | Avançat | Prova de vida, Coincidència facial, Comprovant de domicili, AML, Validació en bases de dades |
| Compliment normatiu específic per regió | KYC | Avançat | Encaminament condicional per país, diferents comprovacions per regió |
| Verificació basada en el risc | KYC | Avançat | Bifurcacions condicionals segons les puntuacions de risc, rutes d’escalat |
Per començar
- Ets nou a Didit? Comença amb el Mode simple i una plantilla predefinida
- Necessites personalització? Passa al Mode avançat per afegir lògica condicional
Contacta amb el nostre equip comercial per parlar de configuracions de flux personalitzades o per rebre orientació sobre la millor configuració per als teus requisits específics.
Darrera modificació el 7 de novembre del 2026
Primers passos
Integració / SDK
Verificació d'usuaris
Verificació d'empreses
Monitoratge de transaccions
Registre de canvis
