Saltar al contingut principal
Utilitza aquests camps de config dins de cada element de l’array features per a POST /v3/workflows/ i PATCH /v3/workflows/{settings_uuid}/.
L’API de fluxos de treball v3 construeix un flux de treball lineal basat en nodes a partir de l’array ordenat features. Envia les funcionalitats en l’ordre exacte d’execució.
El motor que executa una funcionalitat, el de Didit o el d’un proveïdor extern, no és un dels camps de config següents. Es gestiona a través del Marketplace de la consola, que estableix provider_key i fallback_to_native a l’objecte config de la funcionalitat per a tu.

Regles de validació

  • OCR té per defecte tots els països i tipus de document admesos quan config.documents_allowed s’omet, és null o és {}. Si envies un objecte documents_allowed personalitzat, ha de contenir com a mínim un país vàlid i un tipus de document habilitat. Cada configuració de document pot establir sides a 1 per a la captura només de l’anvers o a 2 per a la captura de l’anvers i del revers.
  • QUESTIONNAIRE requereix config.questionnaire_uuid.
  • KYB_DOCUMENTS requereix config.kyb_required_document_groups.
  • SIGNATURE rebutja signature_level: "qes" amb qes_not_available fins que les signatures qualificades estiguin disponibles, i rebutja un pas nou amb signature_level: "aes" amb aes_not_available mentre signature_availability.aes sigui false al flux de treball. Els seus documents han d’existir en crear una sessió: amb signature_documents_source definit a workflow, el pas necessita documents pujats a la consola, i un pas sense cap document pot quedar com a esborrany però no pot entrar en producció; amb session, cada crida de creació ha d’enviar sign.documents.
  • FACE_MATCH ha d’anar després de OCR en les sol·licituds de flux de treball simples.
  • NFC i DATABASE_VALIDATION requereixen OCR quan apareixen al mateix flux de treball. AML necessita un dels següents abans: OCR, KYB_REGISTRY o DOCUMENT_AI. Si només hi ha DOCUMENT_AI davant, el full_name que es cribra ha de poder omplir-se, ja sigui des d’un camp de Document AI anterior amb la clau full_name, que es mapeja per a tu, ja sigui des d’una entrada explícita config.aml_field_sources (consulta AML).
  • Les subfuncionalitats de KYB com KYB_DOCUMENTS i KYB_KEY_PEOPLE requereixen que KYB_REGISTRY aparegui abans al flux de treball.
  • Un flux de treball és de persona (KYC) o d’empresa (KYB), mai les dues coses alhora. Un flux de treball que utilitza qualsevol funcionalitat KYB (KYB_REGISTRY, KYB_DOCUMENTS, KYB_KEY_PEOPLE) només es pot combinar amb AML, DOCUMENT_AI, QUESTIONNAIRE, PHONE_VERIFICATION, EMAIL_VERIFICATION, IP_ANALYSIS i SIGNATURE. No pot incloure funcionalitats exclusives de persona com OCR, LIVENESS, FACE_MATCH, NFC, PROOF_OF_ADDRESS, DATABASE_VALIDATION o AGE_ESTIMATION, i un flux de treball de persona no pot incloure funcionalitats KYB. En un flux de treball d’empresa, DOCUMENT_AI compara qualsevol camp marcat com a is_full_name amb l’empresa verificada en lloc d’una persona. Per verificar les persones que hi ha darrere d’una empresa, crea un flux de treball KYC separat i referencia’l des del node KYB_KEY_PEOPLE amb kyb_ubo_verification_workflow, kyb_officer_verification_workflow o kyb_shareholder_verification_workflow.
  • Els camps d’acció fan servir DECLINE, REVIEW o NO_ACTION, tret que el camp de sota indiqui que té restriccions.
  • Els camps de puntuació i de llindar són números de 0 a 100, tret que s’indiqui un interval més estret.

Regles d’estat comunes

Cada funcionalitat admet una matriu opcional status_rules. Utilitza-la per sobreescriure l’estat de la funcionalitat quan es compleixi una condició de camp.
Llegeix l’exemple anterior així: kyc.extra_fields.profession coincideix de forma aproximada amb Soft. Engineer amb una puntuació mínima de 80, i aleshores estableix l’estat de la funcionalitat a Declined. Per a la Verificació d’identitat, fes referència als valors extrets de extra_fields, com ara kyc.extra_fields.profession, les dates de validesa de la classe del carnet de conduir, com ara kyc.extra_fields.dl_class_code_b_from i kyc.extra_fields.dl_class_code_b_to, o els codis de restricció o d’informació per classe, com ara kyc.extra_fields.dl_class_code_b_notes (columna 12 dels carnets del Regne Unit). Aquests valors provenen de l’objecte extra_fields del resultat de l’OCR; no formen part de expected_details.
dl_class_code_*_from i dl_class_code_*_to sempre contenen una data ISO vàlida o estan absents de extra_fields: Didit mai retorna text d’OCR il·legible en un camp de data. Si no es pot llegir la cel·la de la taula de classes, el camp s’omet en lloc d’enviar-lo com a cadena sense processar, així que utilitza l’operador is_empty per enrutar les dates de classe il·legibles en lloc de suposar que el camp sempre hi és.
Per als camps de data, utilitza value_type: "relative_date" amb un objecte de valor amb la forma { "direction": "past" | "future", "amount": number, "unit": "days" | "months" | "years" }. Per exemple, operator: "less_than" amb { "direction": "past", "amount": 3, "unit": "years" } coincideix amb les dates de fa més de tres anys a partir d’avui.

Compara amb un pas concret

Un flux de treball basat en un graf pot executar la mateixa funcionalitat més d’una vegada, per exemple tres passos de Verificació d’identitat. Amb value_type: "field", afegeix @<node_id> al valor per llegir-lo d’un pas concret. El node referenciat ha de ser un pas de funcionalitat que s’executi sempre abans del pas de la pròpia regla, en tots els camins que hi arribin, o el mateix pas de la regla. Un valor sense el sufix es llegeix del pas de la pròpia regla.
Llegeix aquesta regla, definida al tercer pas de Verificació d’identitat, així: el kyc.full_name d’aquest pas coincideix de forma aproximada amb el nom complet que llegeix el pas ocr_1 amb una puntuació mínima de 80 → estableix l’estat de la funcionalitat a Declined. A la consola, el selector de variables mostra cada pas elegible pel seu número al llenç i guarda el sufix per tu.

OCR / Verificació d’identitat

Valor de la funcionalitat: OCR.
La prova de vida del document es configura amb els sis llindars document_liveness_* anteriors, no amb camps d’acció per senyal. portrait_replacement_action, printed_copy_action i screen_capture_action són configuracions a nivell de compte i no s’accepten en una configuració de funcionalitat del flux de treball: l’API elimina les claus de configuració desconegudes en desar, de manera que enviar-les allà no té cap efecte. Cada senyal té un llindar de rebuig i un llindar de revisió en una escala de 0-100 on una puntuació més alta vol dir que és més probable que el document sigui genuí.
Exemple:

Mètodes per país

methods s’indexa pel codi de país ISO 3166-1 alfa-3. Cada país admet fins a tres objectes de mètode; tot el que ometis pren el seu valor per defecte.
wallet.on_failure és fallback_to_document, decline o retry. retry (només per a cartera, amb la captura de documents desactivada per al país) manté l’usuari que no ha completat l’inici de sessió al pas de cartera perquè ho torni a intentar; la sessió mai no es rebutja per aquest motiu i queda oberta fins que l’usuari la finalitzi o caduqui. Els interruptors de id_lookup només admeten fallback_to_document o decline. Per mantenir els documents fora de la primera pantalla i oferir-los només quan la cartera o la consulta no es completa, estableix document.fallback_only. L’exemple utilitza Finlàndia, on la Finnish Trust Network va primer i la captura de documents és l’alternativa. A Finlàndia també cal habilitar-hi els tipus de document a documents_allowed (per exemple, passaport i targeta d’identitat) perquè l’alternativa tingui documents per oferir.
Les dues consultes anteriors estan available al catàleg actual, així que aquesta configuració es desa tal com està escrita. El bloc de cartera queda fora d’aquest exemple a propòsit: una cartera només es desa en un país on el catàleg la marca com a available, i wallet.enabled: true en qualsevol altre lloc es rebutja i fa fallar tot el desament, inclosa la configuració de consultes. Quan el catàleg marqui una cartera com a available, afegeix-la a aquell país:
Validació que aplica l’API en desar:
  • Un codi de país desconegut, una clau desconeguda dins d’un país o una clau desconeguda dins d’un mètode es rebutgen: no es descarta res en silenci.
  • Un país on no està habilitat cap mètode es rebutja: cap usuari d’aquell país podria verificar-se.
  • Una cartera o una consulta només poden passar a la captura de document quan la captura de document està activada en aquest país. fallback_to_document en un país on document.enabled és false es rebutja en temps d’execució, perquè no hi ha on fer la reserva.
  • document.fallback_only: true es rebutja amb HTTP 400 tret que document.enabled sigui true i almenys una cartera o consulta d’identitat d’aquell país passi a la captura de document.
La implementació de preproducció actual aplica id_lookup.response_fields a la sortida de comparació, al gènere opcional i als retrats del registre conservats. Els camps d’identitat obligatoris continuen formant part del registre de verificació. Això no garanteix que cada payload intermedi del proveïdor quedi exclòs del tractament. La implementació en producció no s’ha verificat per a aquest canvi: confirma el comportament al teu entorn de destinació abans de confiar en la selecció de camps per complir requisits de conservació.
Consulta el catàleg de capacitats abans d’escriure methods, a través de la pestanya Països de la consola o amb l’eina MCP didit_workflow_get_id_verification_methods_catalog. El comportament, la cobertura i la facturació es troben a Mètodes de verificació d’identitat.

NFC / Passaport electrònic

Valor de funcionalitat: NFC.

Prova de vida

Valor de la funcionalitat: LIVENESS.

Coincidència facial

Valor de la funcionalitat: FACE_MATCH.

Estimació d’edat

Valor de funcionalitat: AGE_ESTIMATION.

Verificació de telèfon

Valor de la funcionalitat: PHONE_VERIFICATION. La verificació de telèfon està desactivada fins que l’organització fa la primera recàrrega.
L’enriquiment amb intel·ligència telefònica és un complement opcional. Quan phone_enrichment_enabled és true, cada verificació de telèfon completada s’enriqueix amb intel·ligència telefònica i es facturen $0.05 per sol·licitud a sobre del cost estàndard de la verificació de telèfon. Les accions basades en la puntuació només tenen efecte quan la puntuació d’enriquiment està disponible; les accions per índex de confiança, tipus de telèfon i portabilitat s’apliquen tan bon punt s’executa l’enriquiment.La comprovació de la petjada social és un segon complement, independent del primer. Quan phone_social_enabled és true, cada verificació de telèfon completada també informa de les plataformes en línia en què està registrat el número (missatgeria, xarxes socials, comerç electrònic i serveis professionals) i es facturen $0.05 per sol·licitud. Es pot activar amb o sense phone_enrichment_enabled: els dos complements tenen preus i facturació independents. Una consulta que no troba el número en cap de les plataformes que cobreix és una resposta vàlida i facturable, i activa phone_no_social_presence_action. Per ramificar el resultat en un graf de flux de treball, feu servir phone.social_profiles_registered (el nombre de plataformes on està registrat el número).

Verificació de correu electrònic

Valor de la funcionalitat: EMAIL_VERIFICATION.
L’enriquiment d’intel·ligència de correu electrònic és un complement opcional. Quan email_enrichment_enabled és true, cada verificació de correu electrònic completada s’enriqueix amb intel·ligència de correu electrònic i es factura $0.05 per sol·licitud a sobre del cost estàndard de la verificació de correu electrònic. L’acció basada en la puntuació s’aplica quan la puntuació d’enriquiment està disponible; les accions per filtracions s’apliquen tan bon punt s’executa l’enriquiment.La comprovació de la presència social és un segon complement, independent. Quan email_social_enabled és true, cada verificació de correu electrònic completada també informa de les plataformes en línia en què està registrada l’adreça (proveïdors de correu electrònic, xarxes socials, serveis professionals, de comerç electrònic i d’entreteniment) i es factura $0.05 per sol·licitud. Es pot activar amb o sense email_enrichment_enabled: els dos complements tenen un preu i es facturen de manera independent. Una consulta que no troba l’adreça en cap de les plataformes que cobreix és una resposta vàlida i facturable, i activa email_no_social_presence_action. Utilitza email.social_profiles_registered (el nombre de plataformes en què està registrada l’adreça) per bifurcar segons el resultat en un graf de flux de treball.

Validació en bases de dades

Valor de la funcionalitat: DATABASE_VALIDATION. Exemple:
database_validation_countries és el que fa que aquest pas faci alguna cosa. Una funcionalitat DATABASE_VALIDATION desada sense aquest camp s’accepta i després no executa cap comprovació, de manera que envia sempre almenys un país amb almenys un ID de servei.
Un ID de servei que el pas no pot executar es rebutja amb un 400 que l’indica i explica el motiu, i no es desa res. Això inclou un ID que no és al catàleg, un ID que pertany a un altre país, un servei que encara no està disponible i un servei que només s’ofereix mitjançant el POST /v3/database-validation/ independent. Un servei les entrades del qual cap pas anterior no proporciona es rebutja de la mateixa manera, amb la llista de les entrades que falten. Un servei que el flux desat ja conté però que ja no pot executar s’elimina en desar-lo de nou. Per exemple, aquest flux d’Argentina llegeix el número de DNI i el gènere de Verificació d’identitat i els comprova amb RENAPER sense selfie:
Fes servir arg_renaper en lloc d’això, després d’un pas LIVENESS, si també vols comparar el selfie amb la foto que RENAPER té. Consulta RENAPER per a la seva puntuació de coincidència facial i el seu llindar.

Verificació bancària

Valor de la funcionalitat: BANK_VERIFICATION. L’usuari verifica un compte bancari, i el titular que informa el banc es compara amb la identitat que un pas anterior del flux ha establert. L’usuari ho fa amb un dels dos mètodes: l’inici de sessió al banc (open_banking), en què s’autentica al seu banc, o la comprovació del compte (account_lookup), en què escriu les dades del compte i el banc confirma el nom que hi consta. bank_method_order i el methods de cada país trien quins mètodes ofereix un país i quin va primer; consulta Mètodes de verificació bancària. El pas produeix evidència (una puntuació del nom del titular, la comparació que l’ha generat i els codis de motiu), i les claus bank_*_action converteixen aquesta evidència en un estat. Hi ha dues coses que decideixen si el node fa alguna cosa. bank_countries és una llista blanca, de manera que un mapa buit no ofereix cap banc i no executa cap comprovació. A més, el titular necessita alguna cosa amb què comparar-se: posa un pas OCR, DATABASE_VALIDATION o QUESTIONNAIRE abans, envia expected_details en crear la sessió o assigna tu mateix els camps amb bank_field_sources. Sense cap d’aquests, la titularitat només pot ser unknown, i això és el que decideix bank_reference_identity_missing_action.
La verificació bancària encara s’està desplegant, de manera que un node BANK_VERIFICATION només s’accepta en un compte on s’hagi activat. En qualsevol altre cas, el desament es rebutja i ho indica. Quina ruta executa el pas tampoc es configura aquí: és el parell provider_key i fallback_to_native que la Marketplace de la consola defineix per a tu.

Connexió d’un compte

Quan l’usuari no pot verificar

L’usuari sempre pot continuar sense banc, i el pas mai el deixa bloquejat. Consulta Quan la persona no pot verificar el seu banc. Què significa continuar per a la sessió ho determinen bank_unsupported_action, bank_attempts_exhausted_action o bank_skipped_action, segons el motiu pel qual l’usuari ha continuat, tret que un intent avaluat abans ja hagi decidit el pas: consulta Accions del veredicte.

Comparació del titular

Comprovació del compte

Aquestes claus només s’apliquen a la comprovació del compte. L’inici de sessió bancari manté les seves coincidències aproximades i el seu propi bank_max_attempts.

Dades financeres

bank_expected_currencies funciona només amb el consentiment ownership per defecte. Les altres tres claus llegeixen dades financeres reals, així que cadascuna necessita l’àmbit de consentiment corresponent dins de bank_scopes, i el desat es rebutja sense ell.

Què s’emmagatzema

Accions de veredicte

Cada clau d’aquí accepta DECLINE, REVIEW o NO_ACTION, tret que estigui marcada com a restringida, i recorre al valor per defecte següent quan l’omets o envies null. Res que no sigui evidència positiva de titularitat s’aprova per defecte, i només l’evidència demostrable en contra de l’usuari en provoca el rebuig.

Controls addicionals

Aquestes claus són opcionals. Cada clau d’acció accepta DECLINE, REVIEW o NO_ACTION. Exemple d’objecte config, per a un compte on Bank Verification està activada i la ruta que has seleccionat cobreix el país que indiques:
bank_countries és el que fa que aquest pas tingui efecte, i es comprova contra la ruta on s’executa el node, no contra una llista global. Un país on aquesta ruta no pot establir la titularitat del compte es rebutja en desar i s’indica a l’error, així que llegeix l’error en lloc de suposar que el país s’ha acceptat i que s’ometrà en executar.

AML

Valor de la funcionalitat: AML. Per al cribratge KYC de persones, utilitza aquests camps: Per al cribratge d’empreses KYB, utilitza aquests camps:

Cribratge d’una entitat extreta per un pas de Document AI

Un pas AML normalment llegeix a qui cribra des del pas OCR (una persona) o des del pas KYB_REGISTRY (una empresa). Un flux de treball l’únic pas d’extracció del qual és DOCUMENT_AI, és a dir, documents no estandarditzats com un certificat fiscal o una escriptura de constitució, no té cap dels dos, de manera que ha d’indicar d’on procedeix cada entrada del cribratge. Exemple: cribratge de l’empresa indicada en una acta constitutiva mexicana, sense cap document d’identitat en tot el flux de treball:
Sense cap pas OCR ni KYB_REGISTRY abans, un pas AML ha de poder omplir full_name: sense un nom, el proveïdor no pot fer cap cerca. Un flux de treball que no mapeja res, o que mapeja una clau de Document AI que cap pas anterior no extreu, es rebutja en desar en lloc de desar-se i quedar sense cribrar res. La precisió de l’AML depèn directament de quants identificadors proporciones: un cribratge només pel nom és el que genera un gran volum de falsos positius.

Anàlisi de dispositiu i IP

Valor de la funcionalitat: IP_ANALYSIS. Exemple:
Utilitza recovered_device_action per separat de duplicated_device_action quan vulguis monitorar els dispositius recuperats amb alta confiança abans de rebutjar-los automàticament. Això resulta útil durant el desplegament, perquè les coincidències de dispositius recuperats estan pensades per detectar xarxes de frau, però cal calibrar-les igualment amb el teu propi trànsit.

Verificació de la ubicació

Valor de la funcionalitat: GEOLOCATION. Comprova on es troba la persona mentre es verifica, a partir de la posició del dispositiu o de la ubicació IP de la connexió, en relació amb les zones permeses i bloquejades, la ubicació IP i l’adreça del document. Consulta Verificació de la ubicació per saber com es comporta el pas i el seu informe per als camps de decisió. Col·loca’l després de Verificació d’identitat o de Comprovant de domicili si vols la distància fins a l’adreça d’un document, perquè la distància només es mesura quan hi ha una adreça registrada. Amb geolocation_position_source sense definir, la distància fins a la ubicació IP necessita un pas d’Anàlisi de dispositiu i IP al mateix flux de treball. Totes les claus són opcionals: un pas amb config buit demana al dispositiu una posició amb una precisió de 250 m, no més antiga de 120 segons, dona a la persona 3 intents i no aplica cap regla de zona. Cada resultat té la seva pròpia clau d’acció. Una clau d’acció que no definiu pren el valor per defecte de la geolocation_preset que heu triat, o el valor per defecte de cada clau indicat més avall si no n’heu triat cap. Una ubicació incerta o denegada pren per defecte REVIEW, mai DECLINE, perquè un permís denegat o un radi ampli no és prova de frau. Una acció que definiu explícitament sempre té prioritat sobre la preconfiguració. Un desafiament reproduït (LOCATION_REPLAY_DETECTED) i una atestació del dispositiu fallida (LOCATION_INTEGRITY_FAILED) sempre rebutgen i no tenen clau d’acció.

Formes de les àrees

Cada element de geolocation_areas té un id (d’1 a 64 caràcters de A-Z a-z 0-9 _ -, únic a la llista), un label opcional (fins a 80 caràcters), un type que és allowed o blocked, i un kind que determina la forma. Una llista conté com a màxim 50 àrees i necessita almenys una àrea allowed mentre is_geolocation_geofencing_enabled sigui true. geolocation_areas i geolocation_geofencing_by_country no es poden enviar junts, i geolocation_refusal_path: "end_session" requereix que geolocation_permission_denied_action sigui REVIEW o DECLINE. L’API rebutja una àrea que mai no podria coincidir, com una regió d’un país sense límits publicats, en lloc de desar-la. Exemple:

Comprovant de domicili

Valor de la funcionalitat: PROOF_OF_ADDRESS.

Qüestionari

Valor de la funcionalitat: QUESTIONNAIRE.

Registre KYB

Valor de la funcionalitat: KYB_REGISTRY. kyb_registry_fields_config associa cada clau de camp configurable amb {"enabled": bool, "required": bool}. enabled: false amaga el camp, enabled: true, required: false el mostra com a opcional, i enabled: true, required: true el fa obligatori en enviar. company_name, country_code i region sempre es mostren i són obligatoris, i no es poden configurar. Quan l’objecte s’omet, és null o és {}, s’aplica el valor per defecte: només incorporation_date és obligatori i la resta de camps són opcionals.
Claus de camp configurables: registration_number, incorporation_date, legal_address, vat_number, alternative_names, tax_number, company_type, legal_entity_identifier, location_of_registration, nature_of_business, registered_capital_amount, registered_capital_currency, website, email, phone, control_scheme. Consulta camps configurables del formulari de registre per al comportament de l’usuari final i validació de l’IVA i de l’identificador fiscal per saber com es comproven vat_number i tax_number.

Documents KYB

Valor de la funcionalitat: KYB_DOCUMENTS.

Persones clau KYB

Valor de la funcionalitat: KYB_KEY_PEOPLE.

Document AI

Valor de funcionalitat: DOCUMENT_AI. Sol·licita a l’usuari un o més documents i extreu els camps amb nom que tu defineixes amb un model de visió. Cada camp configurat esdevé un valor document_ai.<key> que pots utilitzar per fer bifurcacions, i el resultat del pas és document_ai.status. Cada entrada de document_ai_documents és un document: Cada entrada de fields d’un document és un camp: Exemple:

E-signature

Valor de la funcionalitat: SIGNATURE. Permet que la persona verificada, o les persones clau d’una empresa, signin documents, en el nivell Simple (per defecte) o Advanced (AES). Col·loca-la després dels passos que verifiquen el signant: Verificació d’identitat, i Verificació de correu electrònic o de telèfon per al codi. Consulta Signatura electrònica. Els camps d’un document del flux de treball es col·loquen a l’editor de plantilles de la consola. Per als documents de la sessió, envia’ls a sign.documents[].fields, i envia els valors dels camps api.<key> a sign.field_values. Consulta Crear sessió. Exemple, per als documents enviats amb cada sessió:
Darrera modificació el 7 de novembre del 2026