> ## Documentation Index > Fetch the complete documentation index at: https://docs.didit.me/llms.txt > Use this file to discover all available pages before exploring further. # Workflow Builder: diseñador de flujos KYC sin código > Crea flujos KYC sin código con el constructor visual de Didit: ID, liveness, AML, NFC y ramas. Paga solo por los pasos completados. Los flujos de verificación (workflows) orquestados de Didit son la forma más potente y flexible de diseñar y desplegar recorridos completos de verificación de identidad en varios pasos. Esta lección de Didit Academy crea un flujo de verificación en la consola real, desde la plantilla hasta el flujo publicado: cómo elegir las comprobaciones de cada nodo, reglas y umbrales, ramificaciones de AML, nodos de webhook y reversión de versiones. [Crea tu primer flujo de verificación — Didit Academy](https://www.youtube.com/embed/7-nJ3JE20i4?rel=0\&playsinline=1) Esta vía de integración te permite aprovechar toda la inteligencia de la plataforma Didit V2 y crear secuencias de verificación sofisticadas con nuestro editor visual sin código. Defines la lógica una sola vez en tu Business Console, y Didit se encarga de toda la experiencia del usuario, de la gestión del estado y de los pasos condicionales. Elige esta vía cuando necesites una solución completa de extremo a extremo para el onboarding de usuarios (KYC), la verificación de edad o la reautenticación, y quieras lanzar rápidamente con un esfuerzo de desarrollo mínimo sin renunciar al máximo control sobre el proceso. ## Métodos de identidad por país En Verificación de identidad, abre **Países y métodos de identificación permitidos** para configurar la captura de documentos, la consulta sin documento y las wallets de identidad digital de cada país. **Configuración adicional** contiene los subtipos de documento, los intentos de consulta y las reglas de respaldo. La consulta sin documento usa los precios del servicio de Validación de base de datos de tu organización. Cada intento completado se cobra por separado, incluidas las coincidencias parciales y la ausencia de coincidencias: dos intentos completados suponen dos cobros. Los errores de formato y los fallos del proveedor que no devuelven respuesta no se cobran. Si varios servicios de base de datos responden a un mismo intento, se suman los precios aplicables de esos servicios. El valor predeterminado es **un intento antes de pasar al respaldo**, configurable de uno a cinco. La captura de documentos se cobra adicionalmente cuando una consulta completada recurre a documentos. Las aplicaciones en producción solo pueden habilitar las wallets disponibles para producción. Las wallets pendientes de lanzamiento permanecen deshabilitadas. Las aplicaciones de sandbox pueden probar todas las wallets del catálogo con resultados simulados; la disponibilidad en sandbox no indica disponibilidad en producción. Consulta [Pruebas en sandbox](https://docs.didit.me/es/integration/sandbox-testing.md) para ver los escenarios de fallo de consultas y wallets. ## Versionado de flujos Los flujos admiten **versionado de borrador y publicación**. Esto significa que puedes iterar sobre tu flujo con seguridad sin afectar a las sesiones activas: * Las **versiones en borrador** son totalmente editables: añade, elimina o reestructura nodos libremente * **Publicar** un borrador crea una versión inmutable que usarán las nuevas sesiones * Las **versiones anteriores** se conservan, así que puedes inspeccionar la configuración exacta que se usó en cualquier sesión pasada * **Las sesiones siempre hacen referencia a la versión específica** con la que se crearon, lo que garantiza la coherencia incluso después de publicar actualizaciones Para hacer cambios en un flujo publicado, crea un nuevo borrador a partir de la versión publicada, edítalo y publícalo cuando esté listo. El historial de versiones está disponible a través de la Management API. *** ## Dos formas de crear flujos Didit ofrece **dos enfoques distintos** para crear flujos de verificación, de modo que puedes elegir el nivel de complejidad que se ajuste a tus necesidades: ![Modos de creación simple y avanzado de flujos KYC de Didit, uno junto al otro](https://mintcdn.com/didit-0f962782/DSfxHq_ggIpqiQSG/images/workflows-simple-and-complex.jpg?fit=max\&auto=format\&n=DSfxHq_ggIpqiQSG\&q=85\&s=07f4e97f94cb1179de16732573612b6e) ### 1. Modo simple: creador basado en plantillas El **modo simple** es ideal para empezar rápido. Selecciona una plantilla predefinida, activa o desactiva las funciones que necesites y listo. ![Interfaz del creador de plantillas en modo simple para flujos de verificación de identidad de Didit](https://mintcdn.com/didit-0f962782/DSfxHq_ggIpqiQSG/images/workflows-simple.jpg?fit=max\&auto=format\&n=DSfxHq_ggIpqiQSG\&q=85\&s=ebe4da7cf6549793629497fb36053fe2) **Ideal para:** * Configuración y despliegue rápidos * Flujos de verificación estándar * Equipos que se inician en la verificación de identidad * Casos de uso que siguen patrones habituales **Cómo funciona:** 1. Elige una plantilla de flujo (KYC, verificación de edad, etc.) 2. Activa o desactiva funciones (prueba de vida, coincidencia facial, AML, etc.) 3. Configura los ajustes básicos de cada función 4. Publica y empieza a verificar *** ### 2. Modo avanzado: creador visual de grafos El **modo avanzado** desbloquea toda la potencia del motor de orquestación de Didit. Crea flujos de verificación complejos y condicionales con nuestro editor visual de grafos, con nodos que se arrastran y sueltan, ramas y lógica personalizada. ![Creador visual de grafos de flujos basado en nodos](https://mintcdn.com/didit-0f962782/z6T2GHM4Zh-iSj-K/images/node-based-workflow.png?fit=max\&auto=format\&n=z6T2GHM4Zh-iSj-K\&q=85\&s=2c0997ab8bbb09dbf7c4cb26b201eced) **Ideal para:** * Recorridos de verificación complejos con múltiples rutas * Lógica condicional basada en los datos del usuario o en los resultados de la verificación * Reglas de negocio personalizadas y ramificaciones * Requisitos de cumplimiento de nivel empresarial **Capacidades clave:** * **Editor visual de nodos**: arrastra, suelta y conecta nodos en un lienzo infinito * **Conexiones inteligentes**: arrastra desde el conector de un nodo hasta un espacio vacío para crear y conectar un nodo nuevo al instante * **Ramas condicionales**: dirige a los usuarios según los datos extraídos, el estado de la verificación, el país, el tipo de documento, el [subtipo de documento](https://docs.didit.me/es/core-technology/id-verification/document-subtypes-id-verification.md), la fecha de expedición, la edad, las rutas de la respuesta JSON del webhook o reglas personalizadas * **Automatización de acciones**: añade etiquetas, establece metadatos o envía a revisión manual según los resultados del flujo * **Atajos de teclado**: deshacer (Ctrl/Cmd+Z), rehacer (Ctrl/Cmd+Shift+Z), eliminar (Supr/Retroceso) * **Zoom y desplazamiento**: navega por flujos complejos haciendo zoom con la rueda y desplazándote al arrastrar #### Tipos de nodos del creador de grafos | Tipo de nodo | Color del icono | Descripción | Ejemplos | | - | - | - | - | | **Nodos de función** | Azul | Comprobaciones de verificación que procesan datos del usuario | Verificación de identidad (OCR), prueba de vida, coincidencia facial, NFC, AML, verificación de teléfono/correo electrónico, cuestionario, prueba de domicilio, Document AI, validación de base de datos, análisis de dispositivo e IP, estimación de edad | | **Nodos de rama** | Morado | Enrutamiento condicional basado en datos o resultados | Enrutar por país, puntuación de riesgo, tipo de documento, subtipo de documento, edad, fecha de expedición, meses desde la expedición, estado de la verificación | | **Nodos de acción** | Ámbar | Disparadores de automatización que modifican datos de la sesión o del usuario | Añadir etiqueta, quitar etiqueta, establecer metadatos, añadir nota de revisión | | **Nodos de webhook** | Cian | Solicitudes HTTP que pueden aportar datos a ramas posteriores | Enviar datos de la sesión a tu servidor, analizar respuestas JSON, ramificar según rutas como `category`, `status` o `tags.0` | | **Nodos de estado** | Verde/Rojo/Ámbar | Resultados finales que terminan el flujo de verificación | Aprobado, Rechazado, En revisión | #### Categorías de nodos de función **Funciones interactivas** (pueden iniciar un flujo): * Verificación de identidad (OCR) * Prueba de vida * Coincidencia facial * Estimación de edad * Verificación de teléfono * Verificación de correo electrónico * Cuestionario * Prueba de domicilio * Document AI * NFC / pasaporte electrónico **Funciones solo de backend** (se ejecutan automáticamente, sin interacción del usuario): * Análisis AML (necesita un paso de verificación de identidad, registro KYB o Document AI antes; consulta [Entidad analizada](#entidad-analizada)) * Validación de base de datos (requiere OCR previamente) * Análisis de dispositivo e IP > **Nota:** las funciones solo de backend están marcadas con un indicador especial en el creador y se ejecutan automáticamente, sin interacción del usuario, en cuanto se cumplen sus dependencias. La primera pestaña de configuración de cada nodo de función empieza con un control **Motor de verificación**: ejecuta la comprobación con el motor propio de Didit o cámbiala a un proveedor externo que conectes desde el [Marketplace](https://docs.didit.me/es/console/marketplace.md), con cambio automático a Didit si ese proveedor no está disponible. #### Entidad analizada Normalmente, el análisis AML obtiene a quién analiza del paso que lo precede: la persona que un paso de **Verificación de ID** leyó de un documento, o la empresa devuelta por un paso de **KYB Registry**. Algunos flujos no tienen ninguno de los dos. Un flujo construido íntegramente sobre **Document AI** (documentos no estandarizados, como un certificado fiscal o una escritura de constitución notarial) ya contiene el nombre, la fecha de nacimiento, el número de documento y el país, solo que bajo tus propias claves de campo. En la pestaña **Avanzado** del nodo AML es donde asignas esas claves al análisis: * **Tipo de entidad**: analiza a una **persona** o a la **empresa** nombrada en un documento subido. Un nodo de empresa busca en registros de empresas, no de personas. * **Orígenes de los campos**: asigna cada una de las cuatro entradas del análisis (nombre, fecha de nacimiento, país, número de documento) a un campo de Document AI, a una respuesta de cuestionario o a un valor que envíes al crear la sesión (`expected_details` / `metadata`). Un campo de Document AI al que ya hayas llamado `full_name` se detecta automáticamente. * **Datos de cribado incompletos**: qué ocurre cuando el análisis se ejecuta con datos de identidad incompletos. La revisión es la opción predeterminada; elige *Sin acción* solo cuando el flujo, a sabiendas, no contenga más que un nombre. Conviene saber dos cosas antes de confiar en ello. Sin un paso de Verificación de identidad o de KYB Registry, el **nombre es obligatorio**: el flujo no se puede publicar hasta que algo lo rellene, porque sin nombre no hay búsqueda. Además, la precisión del análisis AML depende directamente de cuántos identificadores proporciones: un análisis solo con el nombre es lo que genera el volumen de falsos positivos del que se quejan los revisores, así que asigna la fecha de nacimiento y el país siempre que el documento los incluya. #### Cómo leen las condiciones de rama los datos de la sesión **Qué registro lee una condición.** Una condición de rama está vinculada al nodo de función a partir del cual se creó y lee el resultado de ese nodo. Cuando un mismo nodo ha producido más de un registro, la condición lee el **más reciente**. Esto importa sobre todo en **Análisis de dispositivo e IP**: Didit registra una observación por cada dispositivo y dirección IP desde los que se abre una sesión, así que un usuario que cambia de teléfono o de red a mitad de la sesión deja varios registros en el mismo nodo. Una regla como `IP COUNTRY is in [...]` se evalúa entonces con la observación **más reciente**, que es el mismo registro que aparece en primer lugar en el panel Análisis de dispositivo e IP de la sesión y en el array `ip_analyses` del payload de decisión. Las sesiones con más de una observación también llevan la advertencia `MULTIPLE_DEVICES_IN_SESSION`, que indica que debes revisar la lista completa y no solo el resultado de la rama. **Valores de país.** Las condiciones de país se comparan por el país en sí, no por la notación. Elige los países en el selector de campos y Didit normaliza ambos lados de la comparación, de modo que una regla escrita en ISO 3166-1 alfa-3 (`UKR`) sigue coincidiendo con un valor capturado en alfa-2 (`UA`). **Valores ausentes, valores vacíos y comparaciones negativas.** Un campo **sin ningún valor** (el documento no lo incluye, no se envió la clave de metadatos o la función no se ejecutó) solo coincide con `is empty` y con `equals not_defined`; cualquier otra comparación, ya sea `equals`, `contains`, `greater than` o también `not equals` y `not in`, no coincide, y el nodo de ramificación pasa a su siguiente rama. Un campo que contiene una **cadena vacía** es un valor, no un campo ausente: una sesión creada con `"metadata": {"credential_state": ""}` no cumple `metadata.credential_state equals IL`, pero sí cumple `not equals IL`, `not in [IL, MA, NJ]` y `equals ""` (`is empty` coincide en ambos casos). Por tanto, una rama que aprueba con una comparación negativa aprueba una sesión cuyo estado se envió vacío, mientras que la misma sesión sin la clave toma la rama de respaldo. Cuando enrutes con `not equals` o `not in`, añade `metadata. is not empty` a la misma rama (lógica AND) para que ambos casos terminen donde debería terminar un valor ausente. Las ramas se evalúan en orden y gana la primera que coincide; la rama de respaldo (la rama sin condiciones) se toma **solo cuando no ha coincidido ninguna otra rama**, así que dale a cada nodo de ramificación una rama de respaldo que termine donde quieras que termine un valor inesperado. Una sesión que llega a En revisión sin ninguna advertencia en ninguna función fue enrutada ahí por un nodo de estado del grafo, no por una comprobación; la causa habitual es la rama de respaldo de un nodo de ramificación. **Metadatos de la sesión.** Los valores que envías en `metadata` al crear la sesión están disponibles en todas las ramas como `metadata.` y pueden compararse con un valor fijo o con otro campo de la sesión (por ejemplo, `metadata.min_age <= Age`). Los números se comparan como números, así que `18` y `"18"` se comportan igual. **Sandbox / modo de prueba.** Las condiciones de rama, los metadatos y los nodos de estado funcionan en sandbox exactamente igual que en producción, y el sandbox nunca pone por sí solo una sesión en revisión. La diferencia está en el documento: una sesión de sandbox lleva un documento ficticio sin estado ni región de EE. UU., por lo que las condiciones de `Region` no pueden coincidir ahí. Consulta [qué no incluye el documento ficticio](https://docs.didit.me/es/integration/sandbox-testing.md#qué-no-incluye-el-documento-generado) para saber cómo probar flujos que dependen del estado. **Reenvíos.** Los nodos de rama se evalúan en cada intento, incluido un reenvío. Cuando devuelves una sesión para repetir pasos concretos, las ramas y acciones situadas entre esos pasos se vuelven a ejecutar a medida que el usuario los completa de nuevo, con los datos del intento **nuevo**. Así, un usuario que se traslada a una jurisdicción restringida entre un intento y otro se enruta por la rama que la cubre, y una rama que termina en un resultado Rechazado finaliza ahí la sesión reenviada. **Ver qué rama tomó una sesión.** Cada decisión de rama que toma el flujo mientras se ejecuta una sesión, y cada nodo de resultado al que llega, queda registrado en la cronología de eventos de la sesión (Console, detalle de la sesión > Eventos, y `GET /v3/session/{id}/decision/?include=events`). Una fila de **Enrutamiento del flujo** indica el nodo de ramificación, la condición que coincidió y el nodo al que continuó la sesión, o bien indica que **ninguna condición coincidió** y se tomó la conexión de respaldo del nodo. Una fila de **Resultado del flujo** indica el nodo de estado que fijó el estado de la sesión. Cuando un flujo envía una sesión a *En revisión* sin que ninguna función la haya marcado, esas filas muestran el recorrido que siguió, incluida cualquier conexión de respaldo y el nodo de resultado al que llevó. Las decisiones manuales posteriores no reescriben esos eventos del flujo. La falta de datos de entrada es una causa posible: las condiciones que requieren un valor `metadata.*` presente no coinciden cuando se omitió la clave al crear la sesión. Las condiciones que comprueban explícitamente la ausencia de datos, como `is_empty` o `equals` con `not_defined`, sí pueden coincidir con esa misma clave ausente. La conexión de respaldo solo se toma cuando no coincide ninguna rama, incluida cualquier rama else, y lleva al nodo conectado a la salida predeterminada. Consulta [eventos de sesión](https://docs.didit.me/es/sessions-api/retrieve-session.md#eventos-de-enrutamiento-del-flujo) para ver los payloads de los eventos. *** ## Plantillas de flujo: tu punto de partida No pienses en las plantillas como tipos rígidos, sino como **puntos de partida inteligentes y preconfigurados** diseñados para casos de uso habituales. En el modo simple están listas para usar. En el modo avanzado son una base que puedes personalizar ampliamente. ![Galería de plantillas de flujos de verificación de Didit para casos de uso de KYC, KYB y verificación de edad](https://mintcdn.com/didit-0f962782/DSfxHq_ggIpqiQSG/images/workflows-template.jpg?fit=max\&auto=format\&n=DSfxHq_ggIpqiQSG\&q=85\&s=a727315368aa2f6bd096e873d7fbae6c) ### Plantillas disponibles #### **1. Flujo de KYC** La solución completa para el onboarding de nuevos usuarios y el cumplimiento íntegro de Know Your Customer (KYC). * **Empieza con:** la verificación principal del documento de identidad. * **Funciones que se suelen añadir:** * `[+]` **Prueba de vida:** garantiza que el usuario está presente físicamente y evita la suplantación. * `[+]` **Coincidencia facial 1:1:** compara biométricamente la selfie del usuario con la foto de su documento de identidad. * `[+]` **Análisis AML:** comprueba si los usuarios figuran en listas globales de sanciones, PEP y medios adversos. * `[+]` **Verificación NFC:** añade una capa de seguridad de nivel gubernamental leyendo los chips de pasaportes electrónicos y documentos de identidad electrónicos. * `[+]` **Prueba de domicilio (PoA):** verifica la dirección de residencia del usuario. * `[+]` **Verificación de teléfono:** valida la titularidad del número de teléfono como factor adicional. * `[+]` **Verificación de correo electrónico:** valida la titularidad de la dirección de correo electrónico como factor adicional. * `[+]` **Validación en base de datos:** valida contra bases de datos oficiales del gobierno y de crédito. * `[+]` **Cuestionario:** recopila atestaciones estructuradas y documentos justificativos mediante formularios personalizables. * `[+]` **Análisis de dispositivo e IP:** analiza el riesgo de la ubicación y de la conexión. *** #### **2. Flujo de verificación de edad adaptativa** Un flujo de baja fricción y respetuoso con la privacidad para servicios con restricción de edad. * **Empieza con:** la estimación de edad a partir de una selfie. * **Lógica clave:** * Si la edad estimada está claramente por encima de tu umbral (por ejemplo, una estimación de 25+ para un servicio 18+), el usuario queda aprobado al instante. * Si la estimación está por debajo o dentro de una "zona de tolerancia" (por ejemplo, una estimación de 16-20), puedes configurar el flujo para que recurra automáticamente a la **verificación completa de identidad como alternativa** y confirme la fecha de nacimiento exacta. * **Funciones que se suelen añadir:** * `[+]` **Análisis de dispositivo e IP:** restringe el acceso según la ubicación geográfica. *** #### **3. Flujo de autenticación biométrica** Una forma rápida y segura de volver a verificar a usuarios recurrentes sin pedirles de nuevo sus documentos. * **Empieza con:** una comprobación de prueba de vida para confirmar que el usuario está presente. * **Lógica principal:** * El sistema realiza una coincidencia facial entre la nueva selfie en vivo y la plantilla biométrica de confianza obtenida en la verificación KYC inicial y aprobada del usuario. * Si el usuario ya tiene un rostro almacenado con el mismo `vendor_data` (rostro de una prueba de vida aprobada, foto de pasaporte electrónico, retrato del documento de identidad o un rostro de perfil registrado), puedes omitir `portrait_image` al crear la sesión y Didit reutiliza automáticamente el rostro almacenado. En caso contrario, envía `portrait_image` (imagen codificada en Base64, máximo 2MB); sin ninguno de los dos, la creación de la sesión falla con `400`. * **Funciones que se suelen añadir:** * `[+]` **Verificación de teléfono:** vincula la dirección a un número de teléfono verificado. * `[+]` **Verificación de correo electrónico:** valida la titularidad de la dirección de correo electrónico como factor adicional. * `[+]` **Análisis de dispositivo e IP:** marca los intentos de inicio de sesión sospechosos desde nuevas ubicaciones. *** #### **4. Flujo de verificación de domicilio** Un flujo específico para cuando la prueba de domicilio (PoA) es el requisito principal. * **Empieza con:** el usuario enviando un documento de prueba de domicilio (por ejemplo, una factura de suministros o un extracto bancario). * **Lógica principal:** nuestra IA extrae y valida el nombre y la dirección del documento. * **Funciones que se suelen añadir:** * `[+]` **Verificación de teléfono:** vincula la dirección a un número de teléfono verificado. * `[+]` **Verificación de correo electrónico:** valida la titularidad de la dirección de correo electrónico como factor adicional. * `[+]` **Análisis de dispositivo e IP:** compara la dirección del documento con la geolocalización actual del usuario para mayor seguridad. *** #### **5. Flujo de verificación con cuestionario** Un flujo centrado en tu objetivo principal es recopilar atestaciones estructuradas y documentos justificativos mediante formularios personalizables. * **Empieza con:** un cuestionario. * **Lógica principal:** el sistema presenta el cuestionario que has configurado (secciones, contenido traducido, campos obligatorios, archivos que subir). * **Funciones que se suelen añadir:** * `[+]` **Análisis de dispositivo e IP:** añade contexto de ubicación y conexión a los envíos de tu cuestionario. > **Personalización completa** > Cada función de un flujo se puede personalizar aún más con parámetros específicos para cumplir exactamente tus requisitos. Explora la configuración de cada comprobación en el editor. *** ## Crear reglas a partir del estado civil En el **Advanced Mode**, puedes usar el campo OCR `kyc.marital_status` en ramas condicionales y en reglas de estado personalizadas. Elige el valor en el selector de campos para que la regla use la enumeración admitida y no texto libre. Si el documento no indica el estado civil, el valor queda vacío y se aplica tu rama alternativa. El copiloto de flujos también puede crear y configurar pasos de **Database Validation** en una sola acción. Cuando le pidas que añada esta comprobación, indica los países que necesitas; la consola determina el servicio compatible para cada país y muestra la configuración guardada en el lienzo. *** ## Comparación entre el modo simple y el modo avanzado | Capacidad | Modo simple | Modo avanzado | | - | - | - | | Selección de plantilla | ✅ | ✅ | | Activar o desactivar funciones | ✅ | ✅ | | Configuración básica de funciones | ✅ | ✅ | | Editor visual de grafos | ❌ | ✅ | | Ramificación condicional | ❌ | ✅ | | Automatización de acciones (etiquetas, metadatos) | ❌ | ✅ | | Rutas de verificación en paralelo | ❌ | ✅ | | Decisiones basadas en el riesgo | Limitado | ✅ Control total | | Deshacer y rehacer | ❌ | ✅ | | Atajos de teclado | ❌ | ✅ | *** ## Flujo de integración Integrar un flujo orquestado es sencillo. Tu servidor crea una sesión con Didit, recibe una URL única y redirige a tu usuario a esa URL. Didit se encarga del resto y notifica los resultados a tu servidor mediante webhooks. ```mermaid theme={null} sequenceDiagram participant Customer participant Client participant Server participant Didit Customer->>Client: Go to verification page Client->>Server: POST /create-verification-session Server->>Didit: POST /v3/session/ Didit-->>Server: Return new verification session Server-->>Client: Return verification session's url Client->>Customer: Redirect customer to url Customer->>Didit: Complete verification steps Didit->>Server: Send status updates Server->>Customer: Notify of status changes Customer->>Customer: Return to callback URL ``` *** ## Casos de uso comunes
Caso de uso Plantilla recomendada Modo recomendado Funciones sugeridas
Verificación de identidad básica KYC Simple Prueba de vida, Coincidencia facial
Onboarding de alta seguridad KYC Avanzado NFC, Prueba de vida, Coincidencia facial, AML, Verificación de teléfono
Contenidos o servicios con restricción de edad Verificación de edad adaptativa Simple Verificación de identidad como alternativa
Autenticación de usuarios recurrentes Autenticación biométrica Simple Análisis de dispositivo e IP
Verificación de dirección Prueba de domicilio Simple Verificación de teléfono
Onboarding de servicios financieros KYC Avanzado Prueba de vida, Coincidencia facial, Prueba de domicilio, AML, Validación de base de datos
Cumplimiento normativo por región KYC Avanzado Enrutamiento condicional por país, comprobaciones distintas por región
Verificación basada en el riesgo KYC Avanzado Ramas condicionales según puntuaciones de riesgo, rutas de escalado
*** ## Primeros pasos 1. **¿Eres nuevo en Didit?** Empieza con el **modo simple** y una plantilla predefinida 2. **¿Necesitas personalizar?** Cambia al **modo avanzado** para añadir lógica condicional > Contacta con nuestro equipo de ventas para hablar sobre configuraciones personalizadas de flujos de trabajo o para recibir orientación sobre la mejor configuración para tus requisitos específicos. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.