Guía de cumplimiento AMLR: Reglamento UE 2024/1624 y APIs

La Regulación de la UE contra el blanqueo de capitales (AMLR), Reglamento (UE) 2024/1624, reúne las normas de diligencia debida con el cliente (CDD) en un único texto de aplicación directa. Obliga a las entidades de crédito y financieras, incluidos los proveedores de servicios de criptoactivos (CASP), a los proveedores de servicios de juegos de azar y a los demás sujetos obligados enumerados en el artículo 3. Entró en vigor el 9 de julio de 2024 y será aplicable a partir del 10 de julio de 2027. Hasta entonces, siguen aplicándose las leyes nacionales que transponen la directiva vigente. Esta página está dirigida a los desarrolladores e ingenieros de cumplimiento que tienen que implementar estos requisitos. Cada sección indica lo que exige el reglamento, cita el artículo y muestra el paso del flujo de trabajo de Didit, el endpoint de la API o el webhook que puedes usar para esa parte. Para la visión de negocio, consulta la página de la solución AMLR. Última revisión: 2 de octubre de 2026.

Didit proporciona las comprobaciones y las evidencias. Tú sigues siendo el sujeto obligado. Tú decides el perfil de riesgo del cliente, tú decides si das de alta al cliente y sigues siendo plenamente responsable de cualquier tarea que externalices (artículo 18). Usar Didit no hace, por sí solo, que tu empresa cumpla con AMLR. Esta página no constituye asesoramiento jurídico: confirma con tus asesores legales y tu supervisor cómo se aplica cada norma a tu negocio.

Qué exige AMLR de un vistazo

Obligación	Artículo	Dónde se encuentra en Didit
Saber cuándo se activa la diligencia debida	Art. 19	Tu propia lógica de enrutamiento y, después, una sesión por cada disparador. Consulta Cuándo se aplica la diligencia debida
Identificar al cliente y verificar su identidad	Art. 20(1)(a), Art. 22	Verificación de identidad con wallets de identidad digital o captura de documentos. Consulta Identificar y verificar a personas
Identificar a los beneficiarios finales y comprender la estructura de propiedad	Art. 20(1)(b), Arts. 51 a 53	Flujo de Verificación de empresas (KYB). Consulta Verificar empresas y beneficiarios finales
Comprobar sanciones y personas expuestas políticamente	Art. 20(1)(d) y (g), Art. 42	Análisis AML. Consulta Analizar sanciones y PEP
Supervisar la relación y mantener actualizados los datos del cliente	Art. 26	Monitorización AML continua y caducidad de documentos. Consulta Supervisar de forma continua y actualizar
Comprender el propósito de la relación y, cuando sea necesario, el origen de los fondos	Art. 25	Cuestionarios. Consulta Propósito y origen de los fondos
Supervisar las transacciones y comunicar sospechas	Art. 26(1), Art. 69	Monitorización de transacciones y gestión de casos. Consulta Supervisar transacciones y comunicar
Conservar los registros durante 5 años y, después, eliminar los datos personales	Art. 77	Configuración de retención, exportaciones y eliminación bajo demanda. Consulta Conservar registros y, después, eliminar
Incluir intervención humana en las decisiones automatizadas	Art. 76(5)	Revisión manual y actualizaciones de estado. Consulta Revisión humana de decisiones automatizadas
Gestionar las externalizaciones	Art. 18	Tu registro de externalizaciones. Consulta Externalización

Flujo de extremo a extremo

Tu backend crea una sesión, el usuario completa el flujo, Didit te notifica y tú recuperas la decisión completa. La decisión de onboarding permanece en manos de tu equipo. La monitorización continúa después del onboarding.

Cuándo se aplica la diligencia debida

El artículo 19 establece cuándo debes aplicar la diligencia debida con el cliente: cuando establezcas una relación de negocio; en una transacción ocasional de al menos EUR 10,000, ya sea en una sola operación o en transacciones vinculadas; cuando exista sospecha de blanqueo de capitales o de financiación del terrorismo, sea cual sea el importe; y cuando tengas dudas sobre los datos de identificación que ya posees. En algunos sectores se aplican umbrales de activación más bajos: EUR 1,000 para las transferencias de fondos ocasionales y para los CASP, EUR 3,000 para las transacciones ocasionales en efectivo (como mínimo, identificación y verificación) y EUR 2,000 en los juegos de azar. Un CASP debe, como mínimo, identificar y verificar al cliente en una transacción ocasional inferior a EUR 1,000. Didit no decide si se aplica un disparador. Tú enrutas por tipo de transacción e importe en tu propio código y, después, inicias el flujo correspondiente.

Requisito	Función de Didit	Endpoint o configuración
Iniciar la diligencia debida para una nueva relación de negocio (Art. 19(1)(a))	Sesión de verificación en tu flujo de onboarding	`POST /v3/session/`
Iniciar la diligencia debida cuando una transacción ocasional supera tu umbral (Art. 19(1)(b), 19(2) a 19(5))	Sesión de verificación en el flujo que elijas para ese disparador	`POST /v3/session/` con el `workflow_id` correspondiente
Detectar transacciones vinculadas que, en conjunto, superan un umbral	Reglas de velocidad en Monitorización de transacciones	`POST /v3/transactions/`, reglas
Solicitar la verificación al cliente antes de que se liquide una transacción marcada	Una acción de una regla pasa la transacción a `AWAITING_USER` y se crea una sesión de verificación vinculada	Estados de las transacciones

Un esbozo mínimo de enrutamiento para tu backend. No cubre todos los disparadores del artículo 19 (por ejemplo, participar en la constitución de una persona jurídica), y las normas sectoriales que se te apliquen pueden ser distintas:

# Illustrative only. The figures are the Article 19 thresholds in EUR.
def due_diligence_for(event) -> str:
    """Return "full_cdd", "identify_and_verify" or "none"."""
    if event.new_business_relationship or event.suspicion or event.doubts_about_identity_data:
        return "full_cdd"

    amount = event.linked_total_eur  # one operation, or linked transactions added together

    if event.sector == "casp":
        return "full_cdd" if amount >= 1_000 else "identify_and_verify"
    if event.is_transfer_of_funds and amount >= 1_000:
        return "full_cdd"
    if event.sector == "gambling" and amount >= 2_000:
        return "full_cdd"
    if amount >= 10_000:
        return "full_cdd"
    if event.is_cash and amount >= 3_000:
        return "identify_and_verify"
    return "none"


WORKFLOWS = {
    "full_cdd": "YOUR_FULL_CDD_WORKFLOW_ID",
    "identify_and_verify": "YOUR_ID_ONLY_WORKFLOW_ID",
}

Identificar y verificar a las personas

El artículo 22(1) enumera los datos que debes conservar sobre una persona física: todos los nombres y apellidos, el lugar y la fecha completa de nacimiento, las nacionalidades, el número de identificación nacional cuando proceda, el lugar de residencia habitual y, cuando esté disponible, el número de identificación fiscal. A continuación, el artículo 22(6) indica dos medios para verificar la identidad: un documento de identidad, un pasaporte o un documento equivalente, o una identificación electrónica (eID) que cumpla los niveles de garantía de eIDAS “sustancial” o “alto”, junto con los servicios de confianza cualificados pertinentes.

Datos de la decisión

La decisión que devuelve GET /v3/session/{sessionId}/decision/ incluye una entrada por cada comprobación de identidad en id_verifications[].

Dato del artículo 22(1)(a)	Campo en `id_verifications[]`	Notas
Todos los nombres y apellidos	`first_name`, `last_name`, `full_name`	Tal como aparecen en el documento o como los devuelve la wallet
Lugar y fecha completa de nacimiento	`place_of_birth`, `date_of_birth`	El lugar de nacimiento aparece cuando el documento lo incluye
Nacionalidades	`nationality`	Registra en tu propio sistema las nacionalidades adicionales que declare el cliente
Número de identificación nacional, cuando proceda	`personal_number`	Lo que contiene este campo depende del documento. Consulta el informe de Verificación de identidad
Lugar de residencia habitual	`address`, `formatted_address`, `parsed_address`	Los pasaportes rara vez incluyen una dirección. Añade Prueba de domicilio o una validación de base de datos cuando el documento no la incluya
Número de identificación fiscal, cuando esté disponible	`extra_fields.tax_number`	Solo cuando el documento lo incluye. En caso contrario, recógelo con un cuestionario

Las dos vías

Requisito	Función de Didit	Endpoint o configuración
Verificar con identificación electrónica (art. 22(6)(b))	Wallets de identidad digital. Disponibles en producción: MitID (Dinamarca), BankID Sweden, Finnish Trust Network (Finlandia), Smart-ID (Estonia, Letonia, Lituania, Bélgica) y Mobile-ID (Estonia, Lituania). European Digital Identity (EUDI) Wallet: Próximamente	Configura los métodos por país en el paso de Verificación de identidad. El resultado informa de `verification_method` y `wallet_provider`
Verificar con un documento de identidad (art. 22(6)(a))	Captura de documentos con comprobaciones de autenticidad y lectura del chip NFC para pasaportes y documentos de identidad electrónicos. Para el uso a distancia, consulta las normas en borrador que se describen más abajo	Pasos de Verificación de identidad y NFC en el flujo de verificación (workflow)
Comprobar que la persona que presenta el documento es su titular	Prueba de vida y Coincidencia facial con el retrato del documento	Pasos de Prueba de vida y Coincidencia facial. Resultados en `liveness_checks[]` y `face_matches[]`
Conservar evidencias que puedas revisar más adelante	Registro de la sesión con imágenes, datos extraídos y marcas de tiempo	`GET /v3/session/{sessionId}/generate-pdf/`, exportaciones

El nivel de garantía que informa cada wallet figura en la página de wallets de identidad digital. Determinar si un esquema concreto cumple el artículo 22(6)(b) para tu caso de uso es una evaluación que te corresponde a ti. Didit es la integración que permite a tu cliente usar la wallet; no es en sí mismo un prestador cualificado de servicios de confianza ni un esquema de eID.

Qué dicen las normas técnicas en borrador sobre la verificación a distancia

Las normas técnicas de regulación (RTS) sobre la diligencia debida con respecto al cliente previstas en el artículo 28(1) las redacta la Autoridad de Lucha contra el Blanqueo de Capitales (AMLA). El informe final de la AMLA tiene fecha del 30 de septiembre de 2026 y se anunció el 1 de octubre de 2026. Es un proyecto final presentado a la Comisión Europea. No está adoptado y no es ley. La Comisión todavía puede modificarlo, y el proyecto propone que se aplique seis meses después de su entrada en vigor. Ese proyecto trata los dos medios del artículo 22(6) como la opción por defecto. La verificación a distancia con un documento es una solución alternativa para cuando no cabe esperar razonablemente que la persona presente el documento en persona y no tiene acceso a una eID que cumpla los requisitos (artículo 7(1) del proyecto). Si usas la alternativa, el proyecto te pide que puedas justificar el motivo y demostrar a tu supervisor que la solución cuenta con salvaguardas (artículos 7(2) y 7(3) del proyecto). El proyecto es tecnológicamente neutro: no menciona ninguna técnica. Cómo se corresponden las salvaguardas del proyecto con lo que registra una sesión de Didit:

Salvaguarda del proyecto (artículo 7(2))	Qué puedes usar en Didit
Controles de que la persona que presenta el documento es su titular	Resultados de Prueba de vida y Coincidencia facial en la sesión
Imágenes, vídeo y datos de calidad suficiente para identificar a la persona	Comprobaciones de calidad de la captura durante el flujo, con advertencias en el informe
Detenerse cuando haya dudas sobre la identidad o la integridad del proceso	Advertencias y un estado de sesión `"Declined"` o `"In Review"`
Copias conservadas, con marca de tiempo y disponibles para una verificación posterior	Registro de la sesión, informe en PDF y tu configuración de retención

Registrar el motivo por el que un cliente siguió la vía del documento en lugar de la eID te corresponde a ti. Guárdalo en tu propio sistema o adjúntalo a la sesión con metadata al crearla.

Verificar empresas y beneficiarios finales

Para una persona jurídica, el artículo 22(1)(b) exige la forma jurídica y la denominación, la dirección del domicilio social, los representantes legales y, cuando estén disponibles, el número de registro, el número de identificación fiscal y el identificador de entidad jurídica. También debes identificar a los beneficiarios finales y adoptar medidas razonables para verificarlos, de modo que comprendas la estructura de propiedad y control (artículo 20(1)(b)). Un beneficiario final es una persona física que posee, directa o indirectamente, “el 25 % o más” de las acciones, de los derechos de voto o de otro derecho de propiedad (artículo 52(1)), o que controla la entidad mediante la propiedad u otros medios (artículos 51 y 53). El control se evalúa en paralelo a la propiedad.

Requisito	Función de Didit	Endpoint o configuración
Identificar a la persona jurídica y contrastarla con un registro	Verificación de empresas (know your business, KYB) con consulta al registro de empresas en el nivel Lite, Shareholders o UBOs. La disponibilidad de cada nivel varía según el país	`POST /v3/session/` con un `workflow_id` de KYB. Consulta los países compatibles
Identificar a los beneficiarios finales (UBO) con una participación del 25 % o más	Propiedad obtenida del registro cuando está disponible, confirmada y ampliada por el representante de la empresa	Umbral de UBO en Flujos de trabajo, en el flujo de KYB. Resultados en `key_people_checks[]`
Verificar la identidad de propietarios, directores y representantes	Verificaciones de identidad vinculadas: cada persona clave recibe una sesión de verificación secundaria en el flujo que elijas para cada rol	Configuración por rol en Personas clave dentro del flujo de KYB
Comparar lo que consta en el registro con lo que declara el cliente (art. 22(7), art. 24)	Partes del registro y partes declaradas mostradas una junto a otra	`key_people_checks[].registry` y `key_people_checks[].submitted` en la decisión
Analizar la empresa, sus propietarios y quienes la controlan	Análisis AML de empresas y personas	Paso AML en el flujo de KYB

Cuatro puntos que debes tener en cuenta al diseñar el proceso:

El umbral lo fijas tú. La cifra del AMLR es “el 25 % o más”, no “más del 25 %”. El umbral de UBO del flujo es configurable, así que ajústalo para que coincida y revísalo si tu política es más estricta.
Un registro no basta por sí solo. El artículo 22(7) exige consultar los registros centrales además de verificar a los beneficiarios finales. Comunicar una discrepancia al registro en un plazo de 14 días naturales (artículo 24) es un paso que te corresponde a ti.
Un resultado vacío del registro no prueba que una empresa no tenga propietarios. Es posible que un registro no contenga información sobre la propiedad de una empresa o de un país. Si no identificas a ningún beneficiario final, el artículo 22(2) te pide que lo dejes registrado y que, en su lugar, identifiques y verifiques a los altos cargos directivos.
La monitorización del registro llegará próximamente. La monitorización continua de los cambios en el registro aún no está disponible. Hasta entonces, vuelve a ejecutar la Verificación de empresas según tu calendario de actualización.

Análisis de sanciones y PEP

Debes verificar si el cliente o sus beneficiarios finales están sujetos a sanciones financieras específicas, y si personas sancionadas controlan a un cliente que sea persona jurídica o poseen más del 50 % de él (artículo 20(1)(d)). En el AMLR, las sanciones financieras específicas son las sanciones de la UE. También debes determinar si el cliente o un beneficiario final es una persona expuesta políticamente (PEP), un familiar o un allegado (artículo 20(1)(g)). Para las PEP, el artículo 42 añade la aprobación de la alta dirección, medidas para determinar el origen del patrimonio y el origen de los fondos, y una monitorización continua reforzada.

Requisito	Función de Didit	Endpoint o configuración
Analizar en el onboarding	Paso de Análisis AML en el flujo, contra listas de sanciones, de PEP y de vigilancia	Paso AML y sus umbrales en el flujo. Resultados en `aml_screenings[]`
Analizar sin un flujo alojado	Análisis independiente de una persona o de una empresa	`POST /v3/aml/`
Saber qué listas están incluidas	Base de datos de listas de vigilancia, que incluye la lista consolidada de sanciones financieras de la UE	Página de referencia
Registrar una decisión sobre cada coincidencia	Revisión de coincidencias con un `review_status` por coincidencia	`PATCH /v3/session/{sessionId}/update-aml-hit-status/`
Enviar las coincidencias de PEP y sanciones a una persona	Umbrales que pasan la sesión a `"In Review"`	Umbrales AML en el flujo y, después, revisión manual

curl -X POST 'https://verification.didit.me/v3/aml/' \
  -H "x-api-key: $DIDIT_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "full_name": "Javier Ejemplo Modelo",
    "entity_type": "person",
    "date_of_birth": "1974-01-01",
    "nationality": "ES",
    "vendor_data": "user-1234"
  }'

Registrar una coincidencia como Confirmed Match o False Positive dispara un webhook data.updated y no cambia por sí solo la decisión de la sesión. La aprobación de la alta dirección para una relación con una PEP es un proceso que te corresponde a ti: envía la sesión a revisión y deja constancia de quién la aprobó.

Monitorización continua y actualización

El artículo 26 exige una monitorización continua de la relación de negocio y mantener actualizada la información del cliente. El plazo entre actualizaciones no debe superar 1 año para los clientes de mayor riesgo ni 5 años para el resto de clientes (artículo 26(2)), y también debes actualizarla cuando cambien las circunstancias del cliente o conozcas un hecho relevante (artículo 26(3)). Las comprobaciones de sanciones deben repetirse periódicamente y, en el caso de las entidades de crédito y financieras, ante cualquier nueva designación (artículo 26(4)).

Requisito	Función de Didit	Endpoint o configuración
Volver a analizar a los clientes frente a listas de sanciones y de PEP	Monitorización AML continua con nuevo análisis diario	Actívala en el paso de AML, o por perfil con `POST /v3/users/aml-monitoring/`
Volver a analizar a las empresas	Monitorización AML continua para perfiles de empresa	`POST /v3/businesses/aml-monitoring/`
Recibir un aviso cuando un nuevo análisis cambia el resultado	Webhooks de la sesión	`status.updated` cuando cambia el estado, por ejemplo a `"In Review"`, y `data.updated`. El payload incluye `trigger: "ongoing_monitoring"`
Demostrar que la monitorización se ejecutó aunque no cambiara nada	Fecha del último análisis e historial de análisis	`last_ongoing_screening_at` en el informe AML, y la exportación del historial de análisis
Detectar documentos de identidad expirados	Monitorización de documentos	La sesión pasa de `"Approved"` a `"Kyc Expired"` y se envía un webhook `status.updated`

curl -X POST https://verification.didit.me/v3/users/aml-monitoring/ \
  -H "x-api-key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"is_enabled": true, "vendor_data_list": ["user-123", "user-456"]}'

Activar o desactivar la monitorización no genera ningún webhook propio. Una vez activada, los nuevos análisis activan los eventos habituales status.updated y data.updated.

Programa la actualización a 1 año y a 5 años en tu propio sistema

El plazo de actualización depende de la clase de riesgo que asignes, y esa decisión no se puede externalizar. Didit no almacena tu clase de riesgo ni programa la actualización periódica por ti.

Guarda la clase de riesgo y la fecha de la última actualización

Mantenlas en tu registro de cliente, junto al vendor_data que envías a Didit.

Ejecuta una tarea programada

Selecciona los clientes cuya última actualización se haya realizado hace más tiempo que el intervalo: como máximo 1 año para el riesgo alto y como máximo 5 años para el resto. Son plazos máximos, así que puedes elegir un intervalo más corto.

Crea una nueva sesión

Invoca POST /v3/session/ con el mismo vendor_data y tu flujo de actualización, y después envía al cliente la url.

Reacciona también a los eventos

Trata "Kyc Expired", un webhook de monitorización que cambie el estado de una sesión a "In Review" y un cambio que comunique el cliente como disparadores de una actualización anticipada.

Propósito y origen de los fondos

Antes de iniciar una relación de negocios o realizar una transacción ocasional, el artículo 25 te pide comprender su propósito y su naturaleza prevista. Cuando sea necesario, obtienes información sobre el propósito y la justificación económica, el volumen estimado de actividad, el origen de los fondos, el destino de los fondos y la actividad empresarial o profesión del cliente. “Cuando sea necesario” significa que el alcance se basa en el riesgo. La diligencia debida reforzada puede añadir el origen del patrimonio (artículo 34(4)).

Requisito	Función de Didit	Endpoint o configuración
Recopilar el propósito y la actividad prevista	Cuestionarios con la plantilla Purpose of Account	Paso de cuestionario en el flujo
Recopilar el origen de los fondos con documentos justificativos	Plantilla Source of Funds con carga de archivos	Paso de cuestionario en el flujo
Recopilar la profesión y el empleador	Plantilla Employment Details	Paso de cuestionario en el flujo
Que una persona lea todas las respuestas	Cuestionario configurado para dar siempre `"In Review"`	Configuración de revisión manual en el cuestionario

Las plantillas son un punto de partida. Edita las preguntas para que se ajusten a tu evaluación de riesgos y conserva las respuestas con la sesión, para que queden en el mismo registro que la comprobación de identidad.

Monitoriza las transacciones y presenta informes

La monitorización continua abarca las transacciones realizadas durante la relación, para que sigan siendo coherentes con lo que sabes del cliente (artículo 26(1)). Cuando sepas, sospeches o tengas motivos razonables para sospechar que unos fondos proceden de una actividad delictiva o están relacionados con la financiación del terrorismo, debes comunicarlo a tu Unidad de Inteligencia Financiera (UIF) conforme al artículo 69.

Requisito	Función de Didit	Endpoint o configuración
Enviar cada transacción para su evaluación	Monitorización de transacciones para fiat y cripto	`POST /v3/transactions/`
Aplicar los criterios de detección que has aprobado	Paquetes de reglas predefinidos y reglas personalizadas, cada una con un modo que tú controlas	Reglas en la consola o en la API de reglas
Recibir el veredicto	Webhooks	`transaction.created` y `transaction.status.updated`
Investigar	Alertas y casos con una cronología de cada acción	Gestión de casos en la consola
Preparar el informe	Preparación de informes para la UIF a partir de los datos del caso	Pestaña FIU reports de un caso

curl -X POST https://verification.didit.me/v3/transactions/ \
  -H "x-api-key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "transaction_id": "finance0001",
    "transaction_category": "finance",
    "transaction_details": {
      "direction": "outbound",
      "amount": "1200.00",
      "currency": "EUR"
    },
    "subject": { "entity_type": "person", "vendor_data": "user-123", "full_name": "John Doe" },
    "counterparty": { "entity_type": "person", "full_name": "Jane Doe" }
  }'

Dos límites que debes tener en cuenta:

Tú apruebas los criterios de detección. La aprobación de los criterios para detectar transacciones sospechosas o inusuales no se puede externalizar (artículo 18(3)(f)). Revisa cada regla que instales y deja constancia de esa aprobación en tus propias políticas.
Tú presentas el informe. Didit prepara los archivos del informe a partir del caso. No envía nada a ninguna UIF. La presentación la realiza tu responsable de cumplimiento a través del canal de tu UIF.

Conservar registros y luego eliminarlos

El artículo 77 establece tu obligación de conservación de registros. Debes conservar durante 5 años los documentos y la información obtenidos en la diligencia debida con respecto al cliente, los registros de tus evaluaciones de sospecha y los registros de transacciones. El plazo empieza a contar cuando termina la relación de negocios, cuando se ejecuta la transacción ocasional o cuando te niegas a establecer la relación (artículo 77(3)). Cuando vencen los 5 años, eliminas los datos personales, salvo que se aplique otra ley o una autoridad te pida conservar registros concretos durante más tiempo. El plazo empieza con un evento en tu sistema: el fin de la relación. Didit no conoce esa fecha, por lo que la retención que configures y las eliminaciones que solicites son decisiones tuyas.

Requisito	Función de Didit	Endpoint o configuración
Conservar los registros de sesión mientras dure tu obligación	Configuración de retención: un periodo de 1 mes a 10 años, o ilimitado	Business Console → App Settings → Data retention
Eliminar cuando termina tu periodo de 5 años	Eliminación de una sesión a petición	`DELETE /v3/session/{sessionId}/delete/`
Entregar un expediente a un supervisor o a un auditor	Informe en PDF por sesión y por usuario, exportación masiva en CSV	`GET /v3/session/{sessionId}/generate-pdf/`, exportaciones
Conservar la evidencia del análisis	Exportación del historial de análisis por sesión	Evidencia de la monitorización continua

Elige un periodo de retención que no pueda terminar antes de tiempo

Cuando una sesión llega al final del periodo, se elimina. Elige un periodo que cubra la duración de tus relaciones con clientes más 5 años, o déjalo ilimitado y elimina a petición.

Registra el fin de la relación

Guarda la fecha de terminación, de transacción o de rechazo en tu propio sistema. Esa fecha marca el inicio de tu periodo de 5 años.

Elimina cuando venza el periodo

Llama a DELETE /v3/session/{sessionId}/delete/ para cada sesión de ese cliente. La eliminación es irreversible y las URL de los archivos multimedia dejan de resolverse.

Los registros de auditoría y el historial de análisis no cubren por sí solos la obligación de 5 años. Los registros de auditoría están disponibles entre 30 días y 3 años según tu plan, y las ejecuciones del historial de análisis están disponibles durante dos años de forma predeterminada. Si tu política de registros depende de ellos, expórtalos a tus propios registros antes de que terminen esos periodos. Los registros de sesión sujetos a tu configuración de retención son los que corresponden al artículo 77.

Revisión humana de las decisiones automatizadas

El artículo 76(5) te permite adoptar decisiones resultantes de procesos automatizados, incluidos la elaboración de perfiles y los sistemas de IA, con tres condiciones. Los datos se limitan a los datos de diligencia debida. Cualquier decisión de establecer, rechazar o mantener una relación de negocios, de ejecutar o rechazar una transacción ocasional, o de modificar el alcance de la diligencia debida está sujeta a una intervención humana significativa. Y el cliente puede obtener una explicación de la decisión e impugnarla.

Requisito	Función de Didit	Endpoint o configuración
Enviar casos a una persona	Umbrales y ramas del flujo que terminan en `"In Review"`	Flujos
Revisar la evidencia y decidir	Revisión manual con un motivo de rechazo y notas de revisión	Consola, o `PATCH /v3/session/{sessionId}/update-status/`
Exigir un segundo revisor	Revisión de cuatro ojos en una plantilla de caso: un responsable distinto aprueba o rechaza la resolución	Gestión de casos en la consola
Explicar el resultado	Resultados de cada comprobación, advertencias y comentarios del revisor en la sesión	`GET /v3/session/{sessionId}/decision/`

curl -X PATCH https://verification.didit.me/v3/session/4c5c7f3a-.../update-status/ \
  -H "x-api-key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "new_status": "Approved",
    "comment": "Cleared after manual review by compliance team"
  }'

Un estado de sesión "Approved" o "Declined" es el resultado de las comprobaciones que configuraste. Es un factor para tu decisión de incorporar al cliente, que el artículo 18(3) deja en tus manos. Decide con tus asesores jurídicos en qué casos debe intervenir una persona y luego integra ese paso en el flujo y en tu propio back office.

Externalización

El artículo 18 te permite externalizar a un proveedor de servicios las tareas que se derivan del AMLR. Establece condiciones: notificas a tu supervisor antes de que el proveedor comience (artículo 18(1)), sigues siendo plenamente responsable de las tareas externalizadas (artículo 18(2)) y fijas las condiciones en un acuerdo por escrito y realizas controles periódicos sobre el proveedor (artículo 18(4)). El reglamento también indica que usar software de terceros, o acceder a bases de datos o servicios de análisis, cuando eres tú quien cumple el requisito, no constituye externalización (considerando 47). Que tu uso de Didit se considere externalización o no depende de cómo lo utilices. Las directrices de AMLA sobre externalización deben publicarse a más tardar el 10 de julio de 2027. Hay seis tareas que no pueden externalizarse en ningún caso (artículo 18(3)). Siguen siendo tuyas:

La propuesta y la aprobación de tu evaluación de riesgos a nivel de toda la empresa.
La aprobación de tus políticas, procedimientos y controles internos.
La decisión sobre el perfil de riesgo que se asigna al cliente.
La decisión de establecer una relación de negocio o realizar una transacción ocasional.
La comunicación de actividades sospechosas y los informes basados en umbrales a la UIF.
La aprobación de los criterios para detectar transacciones y actividades sospechosas o inusuales.

Las tareas que las rodean sí pueden delegarse: recopilar datos de identidad, realizar la verificación del documento o de la eID, reunir los datos de beneficiarios finales y las consultas a registros, la comprobación en listas de sanciones y de PEP, ejecutar la monitorización de transacciones según los criterios que aprobaste, y preparar alertas y evidencias. Qué incluir sobre Didit en tu registro de externalizaciones:

Elemento	Qué registrar	Dónde encontrarlo
Acuerdo por escrito (art. 18(4))	Tu contrato con Didit y el acuerdo de tratamiento de datos	Pide a tu representante de Didit el DPA y las medidas técnicas y organizativas
Tareas delegadas	Las comprobaciones de cada flujo de verificación (workflow) que ejecutas, por versión del flujo	Flujos de trabajo. Las sesiones y los webhooks incluyen `workflow_id` y `workflow_version`
Tareas que conservas	Las seis tareas anteriores, con su responsable en tu organización	Tus propias políticas
Cualificación del proveedor (art. 18(4))	Certificaciones y atestaciones	Certificaciones
Ubicación de los datos	Los datos se tratan y almacenan en la UE de forma predeterminada. El tratamiento dentro del país está disponible en Enterprise	Retención de datos
Controles periódicos (art. 18(4))	Tu muestreo de sesiones, exportaciones y registros de revisión, con una frecuencia acorde a lo crítica que sea la tarea	Exportaciones, registros de auditoría
Notificación al supervisor (art. 18(1))	La fecha en que notificaste a tu supervisor, antes de la puesta en producción	Es un paso tuyo. La notificación no implica que el supervisor acepte el acuerdo

Flujo de referencia

Un punto de partida para un flujo de onboarding de personas físicas. Adáptalo a tu evaluación de riesgos.

Crea el flujo

En la Business Console, abre Workflows y crea un flujo de KYC (conoce a tu cliente). Usa el editor visual si necesitas ramas por país o por resultado.

Elige los métodos de identidad por país

En el paso ID Verification, activa las wallets de identidad digital disponibles para los países en los que operas, y la captura de documentos como vía para el resto. Consulta Métodos de verificación de identidad.

Vincula el documento a la persona

Para la vía del documento, añade Liveness y Face Match, y NFC cuando el documento tenga chip.

Cubre la dirección

Añade Proof of Address para los clientes cuyo documento no incluya una.

Analiza y monitoriza

Añade AML Screening, configura los umbrales que envían una coincidencia a revisión y activa la monitorización continua.

Pregunta por el propósito y el origen de los fondos

Añade un Questionnaire a partir de las plantillas Purpose of Account y Source of Funds.

Suscríbete a los webhooks

Crea un destino de webhook suscrito a status.updated y data.updated. Consulta Webhooks.

Publica y copia el ID del flujo

Publica el flujo y usa su workflow_id cuando crees sesiones.

Crea una sesión:

curl -X POST https://verification.didit.me/v3/session/ \
  -H "x-api-key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "workflow_id": "YOUR_KYC_WORKFLOW_ID",
    "vendor_data": "user-42",
    "callback": "https://yourapp.com/callback"
  }'

Respuesta (201 Created):

{
  "session_id": "4c5c7f3a-1f82-4f3b-8d8e-1a8d2d2f9b7a",
  "session_kind": "user",
  "session_number": 1024,
  "session_token": "...",
  "url": "https://verify.didit.me/session/...",
  "status": "Not Started",
  "workflow_id": "YOUR_KYC_WORKFLOW_ID",
  "vendor_data": "user-42"
}

Redirige al cliente a url. Cuando la sesión llega a una decisión, Didit envía un webhook status.updated. Un extracto:

{
  "event_id": "9c0c8b8a-1111-4222-9333-444444444444",
  "webhook_type": "status.updated",
  "timestamp": 1774970000,
  "created_at": 1774969994,
  "application_id": "11111111-2222-3333-4444-555555555555",
  "environment": "live",
  "session_id": "aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee",
  "status": "In Review",
  "workflow_id": "66666666-7777-8888-9999-000000000000",
  "workflow_version": 4,
  "vendor_data": "user_42",
  "decision": { "...": "see /sessions-api/retrieve-session" }
}

Verifica la firma, basa la idempotencia en event_id y compara status como una cadena exacta que distingue mayúsculas y minúsculas. Los valores se enumeran en Estados de verificación. Después, lee la decisión completa con GET /v3/session/{sessionId}/decision/ y entrégala a la persona o al proceso que toma la decisión de onboarding.

Cronología

Fecha	Qué sucede
19 de junio de 2024	El AMLR, Reglamento (UE) 2024/1624, se publica en el Diario Oficial
9 de julio de 2024	El AMLR entra en vigor
30 de septiembre de 2026	AMLA fecha su informe final sobre el proyecto de normas de diligencia debida con respecto al cliente (anunciado el 1 de octubre de 2026). Presentado a la Comisión, no adoptado
10 de julio de 2027	El AMLR empieza a aplicarse. Fecha límite para que los Estados miembros transpongan la sexta Directiva contra el blanqueo de capitales, Directiva (UE) 2024/1640. Deben publicarse las directrices de AMLA sobre externalización
2028	AMLA inicia la supervisión directa de determinadas entidades financieras. La primera ronda está limitada a 40
10 de julio de 2029	El AMLR se aplica a los agentes de futbolistas y a los clubes de fútbol profesional

Preguntas frecuentes

¿Cuándo se aplica AMLR?

AMLR entró en vigor el 9 de julio de 2024 y se aplicará a partir del 10 de julio de 2027. Para los agentes de fútbol y los clubes de fútbol profesional se aplicará a partir del 10 de julio de 2029. Hasta el 10 de julio de 2027 se aplican las leyes nacionales que transponen la directiva vigente.

¿Qué diferencia hay entre AMLR, AMLD6 y AMLA?

AMLR es el Reglamento (UE) 2024/1624. Contiene las normas para las entidades obligadas y se aplica directamente, sin transposición nacional. AMLD6 es la Directiva (UE) 2024/1640. Se dirige a los Estados miembros y regula los supervisores, los registros y las sanciones, con un plazo de transposición hasta el 10 de julio de 2027. AMLA es la Autoridad de Lucha contra el Blanqueo de Capitales (Anti-Money Laundering Authority), creada por el Reglamento (UE) 2024/1620 y con sede en Fráncfort. Redacta las normas técnicas y las directrices, y supervisará directamente a un grupo seleccionado de entidades financieras a partir de 2028.

¿Sigue estando permitida la verificación remota con un documento de identidad?

Sí, con condiciones. El artículo 22(6) recoge dos medios: un documento de identidad o una eID con nivel de garantía sustancial o alto. El borrador final de las normas técnicas de AMLA, de 30 de septiembre de 2026, mantienen la verificación remota con un documento como alternativa para cuando no se pueda esperar razonablemente que la persona presente el documento en persona y no tenga acceso a una eID que cumpla los requisitos. Debes poder justificar su uso y demostrar las salvaguardas. El borrador no menciona ninguna técnica y todavía no es ley.

¿Son definitivas las normas técnicas?

No. AMLA finalizó su borrador el 30 de septiembre de 2026 y lo envió a la Comisión Europea. Solo será vinculante cuando la Comisión lo adopte y se publique en el Diario Oficial, y la Comisión puede modificarlo. El borrador propone que se aplique seis meses después de su entrada en vigor, así que todavía no hay una fecha concreta.

¿Tengo que aceptar la EUDI Wallet y Didit la admite?

El propio AMLR incluye la eID como uno de los dos medios de verificación. No obliga a todas las entidades obligadas a aceptar la EUDI Wallet. La obligación de aceptarla está en el reglamento eIDAS: las partes usuarias privadas que deban usar autenticación reforzada del usuario para la identificación en línea aceptan la wallet a petición del usuario, a más tardar 36 meses después de la entrada en vigor de los actos de ejecución, y las microempresas y pequeñas empresas están exentas. Si eso abarca tu onboarding es una cuestión para tu asesor jurídico. En Didit, la EUDI Wallet está en Coming soon. Las wallets disponibles hoy en producción son MitID, BankID Sweden, Finnish Trust Network, Smart-ID y Mobile-ID.

¿El umbral de titularidad real es del 25 % o del 15 %?

Es “el 25 % o más” de las acciones, los derechos de voto u otra participación en la propiedad (artículo 52(1)), con el control evaluado en paralelo. El artículo 52(2) permite a la Comisión fijar un umbral más bajo, de un máximo del 15 %, para categorías de entidades de mayor riesgo mediante un acto delegado. No existe ningún acto de ese tipo. En Didit, el umbral de UBO es una opción de configuración de tu flujo de verificación (workflow) de KYB.

¿Cómo implemento la actualización a 1 año y a 5 años?

Guarda la clase de riesgo del cliente y la fecha de su última actualización en tu propio sistema, ejecuta una tarea programada que seleccione a los clientes que hayan superado tu intervalo y crea una nueva sesión con POST /v3/session/ y el mismo vendor_data. Añade disparadores por eventos: un estado "Kyc Expired", un webhook de monitorización o un cambio que comunique el cliente. Las cifras de 1 año y 5 años del artículo 26(2) son plazos máximos.

¿Qué puedo externalizar?

Tareas como recopilar los datos de identidad, realizar la verificación, consultar registros, realizar el screening y ejecutar la monitorización de transacciones según los criterios que hayas aprobado. Hay seis tareas que no se pueden externalizar: aprobar la evaluación de riesgos de toda la empresa, aprobar las políticas internas, decidir el perfil de riesgo del cliente, decidir el alta del cliente, comunicar a la UIF y aprobar los criterios de detección. Sigues siendo plenamente responsable de lo que externalizas (artículo 18(2)).

¿Cómo configuro la retención para la regla de 5 años?

Los 5 años empiezan a contar cuando termina la relación, no cuando se verificó al cliente. En Business Console → App Settings → Data retention, elige un plazo lo bastante largo para cubrir la relación más 5 años, o déjalo ilimitado. Registra la fecha de finalización en tu propio sistema y invoca DELETE /v3/session/{sessionId}/delete/ cuando venza tu plazo. Exporta los registros de auditoría y el historial de screening si tu política de registros depende de ellos.

¿Usar Didit hace que cumpla con AMLR?

No. El cumplimiento es una propiedad de tu programa: tu evaluación de riesgos, tus políticas, tus decisiones y tus controles. Didit te ofrece los controles, la monitorización y las evidencias en las que se apoyan esas partes del programa. No existe ninguna certificación ni aprobación AMLR para proveedores o herramientas.

Recursos relacionados

Visión general de la solución AMLR

La visión de negocio: a quién obliga el AMLR y dónde encaja Didit.

Métodos de verificación de identidad

Captura de documentos, consulta sin documentos y wallets de identidad digital.

Wallets de identidad digital

Disponibilidad y nivel de garantía de cada wallet.

Verificación de empresas

Consultas en registros, propiedad y personas clave.

Análisis AML

Análisis de sanciones, PEP y listas de vigilancia con monitorización continua.

Monitorización de transacciones

Reglas, alertas, casos y preparación de informes para la UIF.

Cuestionarios

Plantillas sobre el propósito de la relación y el origen de los fondos.

Retención de datos

Plazos de retención y eliminación bajo demanda.

Webhooks

Tipos de eventos, payloads y verificación de firma.

Precios

Paga por cada comprobación. Consulta el precio actual de cada función.

Visión general

Precios

Flujos y verificación

Revisión y operaciones

Entidades (usuarios y empresas)

Ajustes y personalización

Seguridad y cumplimiento

Didit Academy

Recursos

Guía de cumplimiento AMLR: Reglamento UE 2024/1624 y APIs

Qué exige AMLR de un vistazo

Flujo de extremo a extremo

Cuándo se aplica la diligencia debida

Identificar y verificar a las personas

Datos de la decisión

Las dos vías

Qué dicen las normas técnicas en borrador sobre la verificación a distancia

Verificar empresas y beneficiarios finales

Análisis de sanciones y PEP

Monitorización continua y actualización

Programa la actualización a 1 año y a 5 años en tu propio sistema

Propósito y origen de los fondos

Monitoriza las transacciones y presenta informes

Conservar registros y luego eliminarlos

Revisión humana de las decisiones automatizadas

Externalización

Flujo de referencia

Cronología

Preguntas frecuentes

Recursos relacionados

Visión general de la solución AMLR

Métodos de verificación de identidad

Wallets de identidad digital

Verificación de empresas

Análisis AML

Monitorización de transacciones

Cuestionarios

Retención de datos

Webhooks

Precios

​Qué exige AMLR de un vistazo

​Flujo de extremo a extremo

​Cuándo se aplica la diligencia debida

​Identificar y verificar a las personas

​Datos de la decisión

​Las dos vías

​Qué dicen las normas técnicas en borrador sobre la verificación a distancia

​Verificar empresas y beneficiarios finales

​Análisis de sanciones y PEP

​Monitorización continua y actualización

​Programa la actualización a 1 año y a 5 años en tu propio sistema

​Propósito y origen de los fondos

​Monitoriza las transacciones y presenta informes

​Conservar registros y luego eliminarlos

​Revisión humana de las decisiones automatizadas

​Externalización

​Flujo de referencia

​Cronología

​Preguntas frecuentes

​Recursos relacionados

Visión general de la solución AMLR

Métodos de verificación de identidad

Wallets de identidad digital

Verificación de empresas

Análisis AML

Monitorización de transacciones

Cuestionarios

Retención de datos

Webhooks

Precios

Qué exige AMLR de un vistazo

Flujo de extremo a extremo

Cuándo se aplica la diligencia debida

Identificar y verificar a las personas

Datos de la decisión

Las dos vías

Qué dicen las normas técnicas en borrador sobre la verificación a distancia

Verificar empresas y beneficiarios finales

Análisis de sanciones y PEP

Monitorización continua y actualización

Programa la actualización a 1 año y a 5 años en tu propio sistema

Propósito y origen de los fondos

Monitoriza las transacciones y presenta informes

Conservar registros y luego eliminarlos

Revisión humana de las decisiones automatizadas

Externalización

Flujo de referencia

Cronología

Preguntas frecuentes

Recursos relacionados