Panorama y formato del examen
El Certified Cryptoasset AFC Specialist (CCAS) de ACAMS es una certificación de nivel especialista para profesionales que trabajan con riesgos de delito financiero relacionados con criptoactivos y activos digitales. El programa establecido abarca tres áreas: criptoactivos y blockchain; fundamentos AML para criptoactivos y blockchain; y programas de gestión de riesgos.
Según la información disponible para esta guía, el formato establecido del examen es de 100 preguntas en 175 minutos y ACAMS lo lista actualmente solo en inglés. Esta preparación en español no significa que el examen oficial esté disponible en español. Confirma con ACAMS el formato, el idioma, las tarifas y las reglas de inscripción antes de reservar.
Nota de versión, verificada el 11 de octubre de 2026: ACAMS anunció materiales, cursos y un examen rediseñados para el 19 de noviembre de 2026. Esa actualización aún no está vigente en la fecha de verificación de esta guía. El rediseño anunciado contempla cuatro cursos; no se presentan aquí como contenido ya disponible ni se les atribuyen ponderaciones. Confirma qué versión corresponde a tu fecha de examen.
Los conceptos siguen un orden de lo técnico a lo aplicado: primero, cómo se mueve el valor; después, cómo interpretar expectativas y diferencias jurisdiccionales; por último, cómo investigar y gestionar riesgos de manera proporcional. Son materiales editoriales de estudio, no preguntas reales ni una reproducción del examen.
Áreas de estudio
- Comprender qué demuestra una transacción en la cadena y qué requiere investigación adicional.
- Relacionar las expectativas FATF con la jurisdicción, el rol y la actividad de la entidad.
- Combinar evidencia on-chain y off-chain para elegir controles y pasos investigativos razonables.
Consulta la página oficial del CCAS de ACAMS para verificar los detalles vigentes.
Mapa de las áreas de estudio
| Área | Alcance | Prioridad de estudio sugerida |
|---|---|---|
| Criptoactivos y blockchain | Transacciones, wallets, direcciones, exchanges, stablecoins, DeFi, NFT, contratos inteligentes, custodia y movimiento de valor on-chain. | Comprende la mecánica antes de interpretar el riesgo: distingue lo observable en la cadena de lo que solo puede inferirse. |
| Fundamentos AML para criptoactivos y blockchain | Estándares FATF para activos virtuales, VASP, Travel Rule, sanciones, delitos precedentes y diferencias entre jurisdicciones. | Relaciona cada expectativa con el rol, el producto, la actividad y la jurisdicción del caso; no conviertas estándares en leyes universales. |
| Programas de gestión de riesgo para criptoactivos y blockchain | Evaluación de riesgos, incorporación de clientes, screening de wallets, analítica, monitoreo, investigaciones, reportes, gobernanza, registros y pruebas. | Practica decisiones proporcionales que integren evidencia on-chain y off-chain. Las prioridades son editoriales; ACAMS no proporciona aquí porcentajes oficiales por área. |
60 conceptos para estudiar con aplicación práctica 1–10
1. Blockchain como registro compartido
Criptoactivos y blockchain
Una blockchain mantiene un registro de operaciones compartido entre participantes y actualizado mediante reglas de consenso. Según la red, las transacciones pueden ser visibles públicamente y difíciles de modificar una vez confirmadas, pero el registro no explica automáticamente quién controla cada dirección ni el motivo económico de una operación. Para evaluar riesgo, empieza por separar los datos registrados de las conclusiones que requieren contexto adicional.
Ejemplo: Un analista ve una transferencia entre dos direcciones públicas. Puede verificar el movimiento y sus datos técnicos, pero necesita otras fuentes para atribuir las direcciones a un cliente.
Error frecuente: Error frecuente: tratar un registro transparente como si revelara identidades e intenciones. La cadena documenta operaciones; la atribución y la interpretación requieren evidencia adicional.
2. Componentes de una transacción
Criptoactivos y blockchain
Los campos de una transacción dependen de la red. En una red compatible con EVM, la dirección de destino puede ser un contrato y el campo de valor corresponde al activo nativo; los movimientos de tokens pueden producirse durante la ejecución. Para reconstruir la operación, distingue la instrucción enviada, el resultado registrado en el comprobante de ejecución y los movimientos sustentados por los datos del contrato, los registros de eventos y las trazas disponibles. Una instrucción no demuestra por sí sola que la operación se completó.
Ejemplo: Una transacción exitosa en Ethereum tiene valor nativo cero, pero ejecuta un intercambio de tokens mediante un contrato. El analista revisa el resultado y los movimientos de los tokens correspondientes, en lugar de clasificarla como una operación sin valor.
Error frecuente: Error frecuente: interpretar el campo de valor nativo o la dirección de destino como un resumen de todos los movimientos económicos. Una llamada contractual puede producir transferencias de tokens que requieren analizar la ejecución.
3. Direcciones y seudonimato
Criptoactivos y blockchain
Una dirección identifica un destino o una fuente dentro de una red, pero normalmente no muestra por sí misma el nombre de su controlador. La seudonimia puede ser debilitada por datos de exchanges, registros de clientes o patrones de uso, aunque la confianza de una atribución depende de la calidad y actualidad de esas fuentes. Trata la dirección como un identificador técnico, no como una identidad confirmada.
Ejemplo: Una dirección recibe fondos de muchas contrapartes. El investigador compara los movimientos con registros de una plataforma antes de asociarla con una cuenta concreta.
Error frecuente: Error frecuente: llamar al titular de la dirección por el nombre de quien recibió fondos en una plataforma cercana. Una relación técnica no confirma control ni identidad.
4. Modelos UTXO y de cuentas
Criptoactivos y blockchain
En un modelo UTXO, una transacción consume salidas no gastadas completas y crea nuevas salidas. Si el valor utilizado supera el pago y la tarifa, una salida puede devolver el remanente como cambio a quien realiza la operación. En un modelo de cuentas, el protocolo actualiza saldos y otros elementos del estado asociados a cuentas. Estas diferencias determinan cómo se reconstruyen los flujos. Identificar una salida como cambio requiere evidencia; no basta con que sea la salida restante.
Ejemplo: Una transacción de Bitcoin consume una salida previa y crea dos nuevas. Una coincide con una factura conocida; la otra es candidata a cambio. El analista consulta los registros de la wallet antes de atribuir esa segunda salida al pagador.
Error frecuente: Error frecuente: asignar una persona distinta a cada entrada o salida, o identificar automáticamente una salida como cambio. La estructura UTXO describe cómo se gastan y crean salidas, pero no confirma por sí sola quién controla cada una.
5. Confirmaciones y finalidad
Criptoactivos y blockchain
Una transacción puede aparecer en un bloque y recibir confirmaciones adicionales conforme la red incorpora más bloques. La confianza práctica en que el registro no cambiará aumenta, pero la finalidad depende del diseño de la cadena y de sus condiciones. Para controles operativos, diferencia entre una operación observada, confirmada y considerada suficientemente estable según la política aplicable.
Ejemplo: Un exchange detecta un depósito aún no confirmado. Mantiene el saldo sin habilitar el retiro hasta cumplir su criterio operativo para esa red.
Error frecuente: Error frecuente: asumir que una transacción visible en pantalla ya es irreversible. La visibilidad inicial no equivale necesariamente a la finalidad que requiere el servicio.
6. Wallets y claves
Criptoactivos y blockchain
Una wallet administra claves que permiten autorizar operaciones; normalmente no almacena monedas como si fueran archivos dentro del dispositivo. La clave privada o el mecanismo que la protege es crítico porque puede habilitar el control sobre los activos. Para AML, la existencia de una wallet no identifica a su operador: importa quién controla las claves y cómo se demuestra ese control.
Ejemplo: Un cliente muestra una aplicación de wallet, pero el equipo solicita información sobre quién controla la clave antes de clasificarla como propia.
Error frecuente: Error frecuente: decir que la wallet contiene los criptoactivos. El estado relevante se registra en la red; la wallet gestiona credenciales para interactuar con él.
7. Custodia y wallets autogestionadas
Criptoactivos y blockchain
En una solución custodial, un proveedor controla o administra claves por cuenta de clientes. En una wallet autogestionada, el usuario mantiene el control de sus credenciales, aunque la implementación concreta puede variar. La distinción ayuda a identificar intermediarios y puntos de control, pero no determina por sí sola el riesgo ni la legalidad de una transferencia.
Ejemplo: Un cliente retira activos desde una plataforma a una wallet que declara controlar. La entidad documenta la naturaleza de la dirección según sus procedimientos.
Error frecuente: Error frecuente: presumir que una wallet autogestionada es ilícita o que una custodial es segura por definición. El control técnico es solo un factor de evaluación.
8. Exchanges y puntos de conversión
Criptoactivos y blockchain
Un exchange puede facilitar conversiones, compraventa o transferencias entre usuarios, monedas y redes. Los puntos de entrada y salida entre dinero fiduciario y criptoactivos suelen aportar datos de cliente y operación útiles para relacionar actividad on-chain con información off-chain. Sus funciones y obligaciones dependen del producto y de la jurisdicción; no todos los servicios que parecen similares tienen el mismo rol regulatorio.
Ejemplo: Un cliente deposita fondos en una plataforma y luego retira a una dirección externa. El investigador revisa registros de cuenta y datos de la transferencia.
Error frecuente: Error frecuente: usar «exchange» como sinónimo de cualquier servicio cripto. Primero determina qué actividad realiza la entidad y en qué contexto.
9. Stablecoins y su mecanismo
Criptoactivos y blockchain
Las stablecoins buscan mantener un valor de referencia mediante distintos mecanismos, como reservas, reglas algorítmicas u otros arreglos. Estabilidad buscada no significa ausencia de riesgo: importan la estructura, la administración, la liquidez, la posibilidad de rescate y las redes utilizadas. Identificar el mecanismo ayuda a explicar cómo puede moverse valor y qué controles o contrapartes intervienen.
Ejemplo: Una empresa recibe una stablecoin en una red y luego la canjea mediante un proveedor. El análisis registra tanto el movimiento on-chain como el rescate.
Error frecuente: Error frecuente: considerar que todas las stablecoins son equivalentes o que su nombre garantiza un valor constante. El diseño y las condiciones de uso pueden diferir.
10. Contratos inteligentes
Criptoactivos y blockchain
Un contrato inteligente es código desplegado en una blockchain que define funciones y condiciones de ejecución. En redes como Ethereum, una función normalmente necesita ser activada mediante una transacción, directamente o a través de otro contrato; cumplir una condición de tiempo o precio no garantiza por sí solo que se ejecute. La operación también puede fallar o revertirse. Analiza qué función se activó y cuál fue su resultado antes de describir los movimientos de activos.
Ejemplo: Un contrato en Ethereum permite retirar activos después de una fecha determinada. La condición temporal ya se cumplió, pero todavía no se ha ejecutado una transacción de retiro. El analista distingue la posibilidad de retirar de un movimiento de fondos efectivamente realizado.
Error frecuente: Error frecuente: pensar que el contrato ejecuta una transferencia automáticamente en cuanto se cumple una condición. Debe existir el mecanismo de activación correspondiente, y la ejecución debe completarse conforme a las reglas del contrato y de la red.
60 conceptos para estudiar con aplicación práctica 11–20
11. Funciones y participantes en DeFi
Criptoactivos y blockchain
DeFi comprende servicios financieros que utilizan contratos y activos digitales, con distintos grados de administración y control. En un protocolo de préstamos, los proveedores de liquidez aportan activos, los prestatarios asumen deudas y pueden aportar garantías, los oráculos suministran datos como precios y los liquidadores ejecutan mecanismos previstos para posiciones que incumplen las condiciones de garantía. La gobernanza puede modificar determinados parámetros. Identificar estas funciones permite explicar el movimiento de valor antes de evaluar su riesgo.
Ejemplo: Tras una caída del precio de la garantía, una posición pierde activos mediante una liquidación. El analista revisa la deuda, los datos de precio utilizados y la función ejecutada para comprobar si el movimiento corresponde al mecanismo del protocolo.
Error frecuente: Error frecuente: interpretar toda salida de activos como un retiro voluntario del usuario o una sustracción. En DeFi, el movimiento también puede resultar de una liquidación u otra función contractual; hay que reconstruir la operación.
12. Exchanges descentralizados y pools
Criptoactivos y blockchain
Algunos exchanges descentralizados utilizan pools de liquidez y contratos que calculan intercambios según reglas programadas, en lugar de emparejar órdenes de la manera habitual de una plataforma centralizada. El rastro puede mostrar interacciones con contratos y cambios de activos sin revelar directamente quién controla cada posición. Reconstruye las funciones del protocolo antes de atribuir pagos o contrapartes.
Ejemplo: Un cliente intercambia dos tokens a través de un pool. La herramienta registra una interacción contractual, que el investigador contextualiza con la actividad del cliente.
Error frecuente: Error frecuente: interpretar la dirección del contrato como el beneficiario final de cada intercambio. El contrato ejecuta la operación; no necesariamente representa una persona.
13. Puentes entre cadenas
Criptoactivos y blockchain
Un puente facilita el movimiento de valor o la representación de activos entre redes mediante mecanismos que pueden incluir custodios, contratos u operadores específicos. Una transferencia entre cadenas puede cambiar el formato del activo y fragmentar el rastro analítico. Identifica cómo funciona el puente y si existe una relación verificable entre la operación de origen y la de destino antes de afirmar que se trata del mismo flujo.
Ejemplo: Una transferencia sale de una red y aparece una representación del activo en otra. El analista investiga el mecanismo del puente para relacionar ambos registros.
Error frecuente: Error frecuente: asumir que cualquier entrada similar en la segunda cadena corresponde al mismo activo y usuario. La relación necesita datos del mecanismo y del caso.
14. Mixers y herramientas de privacidad
Criptoactivos y blockchain
Algunos servicios o técnicas dificultan relacionar entradas y salidas mediante la agrupación de fondos u otros mecanismos de privacidad. Una interacción puede justificar investigación, pero no demuestra por sí sola lavado de activos ni permite necesariamente reconstruir toda la ruta. Evalúa la exposición, la confiabilidad de la atribución y el contexto. Si existe una posible coincidencia con sanciones aplicables, activa la revisión correspondiente sin esperar a demostrar una finalidad delictiva: las obligaciones de sanciones son distintas de la conclusión sobre criminalidad.
Ejemplo: Una plataforma estadounidense recibe una alerta sobre un retiro solicitado hacia una dirección publicada por OFAC como identificador de una persona bloqueada y etiquetada como servicio de mezcla. El equipo verifica la coincidencia y la vigencia de la designación antes de procesar el retiro y aplica el procedimiento de sanciones correspondiente.
Error frecuente: Error frecuente: concluir que toda herramienta de privacidad demuestra lavado o, en el extremo contrario, esperar a probar un delito antes de revisar una posible restricción de sanciones. La evaluación de sospecha y el cumplimiento de sanciones responden a preguntas diferentes.
15. NFT y activos no fungibles
Criptoactivos y blockchain
Un NFT suele representar un token único o distinguible dentro de una red, aunque lo que representa y los derechos asociados pueden estar definidos fuera de ella. Las ventas, regalías y transferencias pueden generar actividad económica susceptible de análisis. Distingue el token, el contenido o derecho relacionado, el precio y las contrapartes antes de evaluar el propósito de una operación.
Ejemplo: Una cuenta compra un NFT a un precio inusual y luego lo transfiere a otra dirección. El analista revisa el historial y la relación entre las partes.
Error frecuente: Error frecuente: suponer que el registro del token confirma por sí solo la propiedad de todo contenido asociado o el valor económico declarado.
16. Tokenización
Criptoactivos y blockchain
La tokenización crea una representación digital de un activo, derecho o interés, pero la existencia del token no resuelve automáticamente qué derechos legales representa ni cómo se ejercen. Para el análisis AFC, identifica el activo subyacente, el emisor, las condiciones de transferencia y los intermediarios. La clasificación y las obligaciones pueden variar según la estructura y la jurisdicción.
Ejemplo: Una entidad ofrece tokens vinculados a un activo fuera de la cadena. El equipo estudia los documentos de emisión antes de describir qué adquirieron los clientes.
Error frecuente: Error frecuente: tratar todos los tokens como si tuvieran el mismo propósito y régimen. La tecnología de registro no determina por sí sola su naturaleza jurídica.
17. Modelos de custodia: multifirma y MPC
Criptoactivos y blockchain
Un esquema multifirma exige varias firmas válidas generadas con claves distintas según una condición de autorización. En una implementación de MPC para firma por umbral, los participantes utilizan partes del material secreto para producir conjuntamente una firma sin reunir la clave privada completa. Ambos mecanismos pueden distribuir el control técnico, pero no equivalen por sí solos a aprobaciones administrativas ni garantizan independencia entre responsables. Evalúa quién controla las claves o participaciones, cómo se autorizan retiros y qué facultades existen para recuperación y cambios de acceso.
Ejemplo: Un custodio utiliza multifirma de dos de tres claves. El auditor comprueba la condición técnica y verifica si una misma persona puede acceder a dos claves, porque en ese caso podría autorizar una operación sin participación independiente de otro responsable.
Error frecuente: Error frecuente: considerar que dos aprobaciones internas demuestran multifirma o MPC, o que varias claves garantizan segregación. Las autorizaciones administrativas y el mecanismo criptográfico son controles diferentes; su eficacia depende del acceso real y de su aplicación.
18. Actividad on-chain y actividad fuera de la cadena
Criptoactivos y blockchain
No toda actividad económica relacionada con criptoactivos se registra directamente en una blockchain. Una plataforma puede mantener saldos internos o compensar operaciones entre clientes sin generar una transacción por cada movimiento. Por eso, el historial público puede no reflejar la relación completa entre cuentas, instrucciones y beneficiarios; complementa el análisis con registros internos y documentación pertinente.
Ejemplo: Dos clientes transfieren saldo dentro de un exchange. No aparece una operación pública entre sus direcciones, así que el investigador consulta los libros internos.
Error frecuente: Error frecuente: considerar que la ausencia de una transacción pública significa que no hubo movimiento de valor. Puede existir actividad registrada solo en sistemas internos.
19. Forks y reorganizaciones de cadena
Criptoactivos y blockchain
El término fork puede referirse a una bifurcación del protocolo, como un cambio de reglas, o a ramas competidoras de la cadena que pueden surgir bajo las mismas reglas. Una reorganización ocurre cuando la red adopta una secuencia de bloques distinta de la previamente reconocida. Las transacciones de los bloques desplazados pueden desaparecer temporalmente del historial vigente y algunas pueden reincorporarse después. Estos eventos afectan las confirmaciones y la cronología; no implican por sí solos que una operación sea ilícita.
Ejemplo: Un depósito figuraba en un bloque que después fue desplazado por una reorganización. El equipo verifica si la transacción quedó incluida en la cadena vigente, continúa pendiente o fue sustituida, y actualiza su estado antes de acreditar el depósito según su política.
Error frecuente: Error frecuente: asumir que todo fork cambia las reglas o que una transacción desplazada desapareció definitivamente. Es necesario distinguir el tipo de bifurcación y comprobar el estado actual de la operación.
20. Tarifas y congestión de red
Criptoactivos y blockchain
Las tarifas y los tiempos de inclusión dependen del diseño de la red, la demanda y sus mecanismos de priorización. La congestión puede llevar a retrasar operaciones o transmitir versiones de reemplazo con tarifas diferentes. Para analizar el comportamiento, distingue las operaciones ejecutadas de los intentos pendientes, fallidos o reemplazados. Una tarifa alta o una demora pueden tener una explicación técnica y no establecen por sí solas intención ilícita.
Ejemplo: Durante una congestión en Ethereum, un cliente transmite varias versiones con el mismo emisor, nonce, destinatario e importe, pero con tarifas mayores. El analista comprueba cuál quedó incluida en la cadena vigente y no contabiliza todas las versiones como transferencias independientes ejecutadas.
Error frecuente: Error frecuente: sumar todos los intentos como movimientos completados o interpretar una tarifa elevada como prueba de evasión. El resultado debe verificarse según las reglas de la red y analizarse junto con el contexto.
60 conceptos para estudiar con aplicación práctica 21–30
21. Estándares FATF y derecho interno
Fundamentos AML para criptoactivos y blockchain
FATF establece estándares internacionales contra el lavado de activos y el financiamiento del terrorismo y la proliferación. No son, por sí solos, leyes directamente aplicables a cada entidad: las jurisdicciones los incorporan mediante sus propios marcos. Para responder un caso normativo, identifica primero qué jurisdicción rige, qué actividad se realiza y qué norma local concreta convierte una expectativa en obligación.
Ejemplo: Un proveedor opera en dos países con implementaciones distintas. El equipo contrasta la expectativa FATF con las normas vigentes de cada jurisdicción.
Error frecuente: Error frecuente: presentar una recomendación FATF como una obligación legal idéntica en todos los países. La implementación, el alcance y los plazos pueden variar.
22. Evaluación funcional del estatus VASP
Fundamentos AML para criptoactivos y blockchain
La definición de VASP de FATF comprende personas físicas o jurídicas que realizan como negocio determinadas actividades para otra persona o por cuenta de ella. Estas incluyen intercambio, transferencia, custodia o administración de activos virtuales, así como determinados servicios financieros relacionados con su oferta o venta por un emisor. No basta con poseer criptoactivos ni con adoptar una etiqueta comercial: identifica el servicio efectivo y luego verifica su tratamiento en la jurisdicción aplicable.
Ejemplo: Una empresa se presenta como proveedor de software, pero custodia las claves de clientes y ejecuta sus órdenes de transferencia a cambio de una comisión. El equipo analiza esas funciones de servicio, no solo el nombre comercial, para evaluar su posible estatus VASP bajo el marco pertinente.
Error frecuente: Error frecuente: clasificar a una entidad únicamente por su nombre o por el hecho de usar criptoactivos. La prestación de actividades comprendidas como negocio y para terceros es central en la definición FATF; la clasificación legal requiere revisar la norma local.
23. Perímetro regulatorio y grado de control
Fundamentos AML para criptoactivos y blockchain
En DeFi, que las operaciones se ejecuten mediante contratos inteligentes no determina por sí solo el perímetro regulatorio. Examina si existen propietarios u operadores que prestan servicios comprendidos y mantienen control o influencia suficiente sobre ellos, por ejemplo mediante facultades administrativas relevantes. La mera publicación de código, sin prestación de servicios ni intervención operativa, no convierte automáticamente al desarrollador en VASP. La clasificación exige analizar las funciones reales y el marco aplicable.
Ejemplo: Un desarrollador publica código y no participa después en el servicio. Otra empresa opera la interfaz, cobra comisiones y conserva una clave que permite modificar funciones críticas del protocolo. El equipo no trata ambos roles como equivalentes: examina la actividad y las facultades de cada actor antes de evaluar obligaciones.
Error frecuente: Error frecuente: concluir que todo desarrollador es VASP o que ningún servicio DeFi puede tener un operador regulado. Ni escribir código ni usar automatización resuelve por sí solo la clasificación.
24. Enfoque basado en riesgo
Fundamentos AML para criptoactivos y blockchain
El enfoque basado en riesgo ajusta la intensidad de las medidas a los riesgos identificados, en lugar de aplicar una respuesta idéntica a toda persona, producto o transferencia. La evaluación debe considerar contexto, exposición y controles disponibles, y documentar por qué la medida elegida es adecuada. Una señal aislada orienta el análisis; no reemplaza la valoración conjunta de los factores relevantes.
Ejemplo: Dos clientes usan el mismo servicio, pero tienen perfiles y patrones distintos. La entidad determina controles diferenciados y documenta la razón de cada decisión.
Error frecuente: Error frecuente: interpretar «basado en riesgo» como libertad para omitir controles sin explicación. La proporcionalidad requiere una evaluación fundamentada y medidas coherentes.
25. Debida diligencia y beneficiario final
Fundamentos AML para criptoactivos y blockchain
La debida diligencia comprende, conforme al marco aplicable, identificar al cliente, verificar su identidad mediante fuentes confiables e independientes y comprender el propósito y la naturaleza de la relación. En una persona jurídica, el beneficiario final es la persona física que en último término la posee o controla; identificar una sociedad intermedia no completa ese análisis. También corresponde adoptar las medidas pertinentes para verificar al beneficiario final y relacionar el uso previsto de los criptoactivos con el perfil del cliente.
Ejemplo: Una empresa solicita una cuenta institucional y presenta como accionista a otra sociedad. El equipo analiza la cadena de propiedad hasta identificar a las personas físicas pertinentes, obtiene respaldo de su identidad y control según las reglas aplicables y contrasta el uso previsto de la cuenta con la actividad comercial declarada.
Error frecuente: Error frecuente: confundir identificar con verificar o tratar a una sociedad intermedia como beneficiario final. El análisis debe buscar a las personas físicas pertinentes y sustentar la información con medidas de verificación adecuadas.
26. Personas expuestas políticamente
Fundamentos AML para criptoactivos y blockchain
Una persona expuesta políticamente (PEP) es alguien a quien se confían o se han confiado funciones públicas prominentes. El estándar FATF distingue las PEP extranjeras de las nacionales y las de organizaciones internacionales: para las extranjeras prevé medidas adicionales, como aprobación de la alta gerencia, establecimiento del origen del patrimonio y de los fondos y monitoreo reforzado; para las otras categorías, esas medidas adicionales se vinculan con relaciones de mayor riesgo. La obligación doméstica debe verificarse en la jurisdicción. La condición de PEP no demuestra conducta ilícita ni exige rechazo automático.
Ejemplo: Un VASP cuya normativa incorpora esas medidas evalúa la solicitud de una persona que ejerce como ministro en otro país. Examina el origen del patrimonio y de los fondos, obtiene la aprobación pertinente y establece el monitoreo requerido, sin asumir que el cargo prueba un delito.
Error frecuente: Error frecuente: tratar todas las categorías de PEP como si tuvieran idénticos requisitos o rechazar al cliente por su condición. Deben distinguirse la categoría, las medidas exigidas y los demás factores de riesgo.
27. Propósito de la Travel Rule
Fundamentos AML para criptoactivos y blockchain
La Travel Rule recoge la expectativa FATF de obtener y conservar la información requerida sobre el ordenante y el beneficiario en las transferencias comprendidas. Cuando intervienen proveedores de origen y destino, también contempla la transmisión segura de esa información al proveedor receptor y su conservación por este. Los deberes concretos dependen de la implementación local y del rol de cada entidad. La información puede intercambiarse por un canal separado: no se exige que los datos personales se publiquen en la blockchain.
Ejemplo: Dos VASP gestionan una transferencia cubierta por sus reglas aplicables. El proveedor de origen obtiene y valida los datos exigidos según su rol, los transmite por un canal seguro separado de la transacción on-chain y conserva los registros correspondientes. El receptor obtiene y conserva la información que le corresponde.
Error frecuente: Error frecuente: pensar que los datos de la Travel Rule deben quedar visibles en la cadena o que existe una obligación idéntica para cualquier transferencia mundial. Hay que distinguir el intercambio de información, el movimiento del activo y el alcance legal aplicable.
28. Travel Rule y diferencias jurisdiccionales
Fundamentos AML para criptoactivos y blockchain
Las jurisdicciones pueden implementar la Travel Rule en momentos distintos y con diferencias de alcance. La ausencia de requisitos equivalentes para una contraparte extranjera no elimina las obligaciones de una entidad que ya está sujeta a ellos. Identifica los deberes propios y los de la contraparte, su capacidad de intercambiar información y las medidas exigidas cuando faltan datos. La decisión de ejecutar, suspender o rechazar debe respetar el marco aplicable; una política interna no puede dispensar una obligación legal.
Ejemplo: Un VASP obligado a transmitir datos prepara una transferencia saliente hacia una contraparte cuya jurisdicción aún no implementa requisitos equivalentes. Antes de autorizarla, evalúa si una vía alternativa de intercambio aprobada permite cumplir sus obligaciones. Si no es posible, aplica el tratamiento previsto por sus reglas, en lugar de considerar la transferencia exenta por la situación de la contraparte.
Error frecuente: Error frecuente: suponer que la falta de implementación en el país receptor exonera al proveedor de origen. También es incorrecto presumir una respuesta universal: el tratamiento de la brecha depende de los requisitos aplicables.
29. Transferencias hacia wallets autogestionadas
Fundamentos AML para criptoactivos y blockchain
En una wallet autogestionada, el usuario conserva la capacidad de autorizar operaciones sin delegar la custodia a un proveedor. Si una transferencia involucra esa wallet, puede no existir un VASP contraparte con quien intercambiar información, pero el proveedor que sí interviene debe evaluar sus propios deberes de diligencia, información y registro. Las verificaciones de control de una dirección dependen del marco y del riesgo. Una prueba técnica de acceso a una clave no demuestra por sí sola identidad, propiedad jurídica ni licitud de los fondos.
Ejemplo: Durante una revisión prevista en sus procedimientos, un VASP recibe del cliente un mensaje firmado válidamente con la clave de la dirección de retiro. Trata la firma como evidencia de acceso a esa clave, no como prueba concluyente de que el cliente sea el propietario jurídico de los activos o de que su origen sea lícito.
Error frecuente: Error frecuente: considerar ilícita toda wallet autogestionada o asumir que una firma válida resuelve toda la debida diligencia. La ausencia de un proveedor custodio y la evidencia de acceso a una clave son hechos distintos del propósito y del origen de los fondos.
30. Nexo de sanciones y jurisdicción
Fundamentos AML para criptoactivos y blockchain
Las obligaciones de sanciones dependen del régimen aplicable, sus nexos jurisdiccionales y las personas o actividades cubiertas. Una conexión técnica con una dirección de riesgo puede activar revisión, pero no siempre basta para concluir que existe una obligación de bloquear o rechazar. Identifica qué régimen se aplica, qué relación está probada y qué instruye la ley y la política de la entidad.
Ejemplo: Una plataforma detecta una transferencia vinculada indirectamente con una dirección incluida en una lista. Determina primero qué régimen es aplicable y qué evidencia respalda el vínculo.
Error frecuente: Error frecuente: aplicar las reglas de una jurisdicción como si fueran universales. Las obligaciones de sanciones pueden variar por país, régimen y nexo relevante.
60 conceptos para estudiar con aplicación práctica 31–40
31. Regla de propiedad del 50 % de OFAC
Fundamentos AML para criptoactivos y blockchain
Según la regla de propiedad del 50 % de OFAC, una entidad poseída directa o indirectamente, en un 50 % o más de manera agregada, por una o más personas bloqueadas se considera bloqueada aunque no aparezca nombrada por separado. Deben analizarse tanto la propiedad como las personas que la mantienen; una persona sujeta a alguna sanción no necesariamente está bloqueada. El control sin la propiedad correspondiente no produce por sí solo ese efecto bajo esta regla. Los criterios de otros regímenes, incluidos los de la UE y el Reino Unido, deben analizarse por separado.
Ejemplo: Un VASP constituido en Estados Unidos identifica que una empresa cliente no listada pertenece directamente en un 30 % a una persona bloqueada y en un 25 % a otra persona bloqueada. La propiedad agregada es del 55 %: la empresa se considera bloqueada bajo la regla de OFAC, aunque no figure individualmente en la lista.
Error frecuente: Error frecuente: revisar cada participación por separado, confundir cualquier sanción con bloqueo o trasladar el criterio de OFAC a otros regímenes. La agregación corresponde a la propiedad de personas bloqueadas, y las reglas sobre control pueden diferir.
32. Atribución de direcciones en screening de sanciones
Fundamentos AML para criptoactivos y blockchain
La atribución vincula una dirección con una persona o entidad. En el análisis de sanciones, distingue una dirección publicada por una autoridad de una etiqueta o inferencia de un proveedor analítico. Revisa la fuente, la red, la actualidad y la confianza de la atribución, así como la naturaleza del vínculo observado. La proximidad gráfica no demuestra por sí sola control ni una operación prohibida; tampoco la ausencia de una dirección en una lista garantiza que no pertenezca a una persona sancionada. Ante una coincidencia confirmada que active una obligación legal, aplica la medida correspondiente sin esperar prueba de un delito.
Ejemplo: Una alerta conecta la dirección de un cliente con una dirección oficialmente listada mediante dos saltos y un exchange custodial. El investigador verifica qué demuestra esa ruta: la dirección del exchange puede representar actividad de numerosos usuarios, por lo que la conexión no identifica por sí sola al cliente como contraparte de la persona sancionada.
Error frecuente: Error frecuente: tratar toda etiqueta o cercanía gráfica como una coincidencia legal confirmada. El error opuesto es seguir investigando indefinidamente cuando la evidencia ya confirma una coincidencia que exige actuar conforme al régimen aplicable.
33. Delitos precedentes y señales de actividad
Fundamentos AML para criptoactivos y blockchain
Un delito precedente es una actividad delictiva que puede generar bienes susceptibles de lavado, según la legislación aplicable. Los criptoactivos pueden recibir, transferir o convertir esos bienes, pero un patrón de transacciones no demuestra por sí solo el delito que los originó ni quién lo cometió. Las tipologías sirven para formular hipótesis que deben contrastarse con el perfil del cliente, la cronología, el origen de los fondos y evidencia externa.
Ejemplo: Un VASP observa numerosos depósitos de particulares seguidos de conversiones y retiros rápidos. Además, recibe denuncias documentadas que vinculan la cuenta con una posible plataforma de inversión fraudulenta. El equipo investiga el fraude como posible delito precedente y corrobora las denuncias y los flujos, sin considerar que el patrón aislado demuestra el delito.
Error frecuente: Error frecuente: llamar «delito precedente» a una conducta transaccional inusual o asignar un delito concreto solo por fragmentación o rapidez. La señal describe actividad; el delito precedente requiere una hipótesis sobre la actividad delictiva generadora de los bienes.
34. Riesgos de financiamiento del terrorismo y proliferación
Fundamentos AML para criptoactivos y blockchain
El financiamiento del terrorismo puede utilizar fondos de origen lícito o ilícito para apoyar a terroristas, organizaciones terroristas o actos terroristas. El financiamiento de la proliferación se relaciona con recursos destinados a facilitar actividades vinculadas con armas de destrucción masiva y sus medios de entrega. Los estándares FATF en esta última materia incluyen evaluar el riesgo de incumplimiento, falta de implementación o evasión de sanciones financieras dirigidas relacionadas con la proliferación. No basta con valorar montos: deben analizarse actores, destino, propósito y medidas aplicables en la jurisdicción.
Ejemplo: Un VASP observa aportes pequeños provenientes de salarios a una campaña cuyas publicaciones verificables anuncian apoyo a un grupo designado por terrorismo en el régimen aplicable. Investiga el destino de los recursos y las obligaciones pertinentes: ni el origen lícito ni el bajo monto eliminan el riesgo.
Error frecuente: Error frecuente: descartar financiamiento del terrorismo porque los fondos provienen de ingresos legítimos o tratar terrorismo y proliferación como riesgos idénticos. Cada uno requiere analizar sus elementos y el régimen aplicable, sin convertir una señal aislada en prueba de delito.
35. Decidir si corresponde un reporte de actividad sospechosa
Fundamentos AML para criptoactivos y blockchain
El deber de presentar un reporte de actividad sospechosa depende del criterio establecido por la jurisdicción y de los hechos disponibles. Una alerta no exige automáticamente reportar, pero tampoco es necesario probar el delito o concluir toda la investigación si ya se alcanzó el criterio aplicable. La persona responsable debe evaluar y documentar la decisión, respetar el momento y los plazos exigidos y determinar si procede aportar información adicional después. Los procedimientos internos organizan ese cumplimiento; no sustituyen la norma.
Ejemplo: Después de contrastar transferencias, datos del cliente y documentos externos, la persona responsable determina que los hechos ya alcanzan el criterio de reporte aplicable. Presenta el reporte conforme a los requisitos pertinentes, aunque aún no conozca el destino final de todos los activos, y continúa la investigación para evaluar información adicional.
Error frecuente: Error frecuente: reportar toda alerta sin evaluación o esperar certeza sobre el delito antes de reportar. La decisión depende del criterio legal correspondiente, no de una prueba definitiva ni de un plazo universal.
36. Confidencialidad y prevención del aviso indebido
Fundamentos AML para criptoactivos y blockchain
El aviso indebido al cliente, conocido como tipping-off, puede consistir en revelar que se presentó un reporte de actividad sospechosa o divulgar información relacionada que la normativa protege. El estándar FATF contempla prohibiciones de divulgación, cuyo alcance concreto se establece en el derecho interno. Distingue esas restricciones de la confidencialidad general del expediente: no toda pregunta al cliente ni toda comunicación sobre una revisión está prohibida. Limita el acceso interno a quienes lo necesitan por sus funciones y utiliza comunicaciones autorizadas.
Ejemplo: Tras la presentación de un reporte, un cliente pregunta por una solicitud de documentos. El personal utiliza una respuesta autorizada para explicar qué documentación se necesita, sin confirmar la existencia del reporte ni revelar información restringida conforme a la normativa aplicable.
Error frecuente: Error frecuente: revelar un reporte para justificar una revisión o asumir que toda solicitud de información constituye aviso indebido. La comunicación debe respetar el alcance de las restricciones legales y permitir la diligencia legítima sin divulgar información protegida.
37. Países bajo monitoreo reforzado de FATF
Fundamentos AML para criptoactivos y blockchain
La inclusión de una jurisdicción en una lista de monitoreo reforzado señala deficiencias estratégicas que requieren atención, pero no impone por sí sola debida diligencia intensificada automática para toda relación ni una salida indiscriminada del mercado. Valora la exposición concreta, las relaciones y las medidas vigentes. La respuesta debe ser contextual, proporcional y coherente con las obligaciones locales.
Ejemplo: Un cliente tiene actividad comercial en un país bajo monitoreo reforzado. La entidad evalúa sus transacciones y controles, sin rechazarlo únicamente por esa ubicación.
Error frecuente: Error frecuente: convertir la inclusión en una lista de FATF en una regla universal de rechazo o de debida diligencia reforzada para todos.
38. Conflictos entre requisitos transfronterizos
Fundamentos AML para criptoactivos y blockchain
Una transferencia internacional puede involucrar distintas normas sobre AML, privacidad, localización de datos y sanciones. No presupongas que una obligación en un país resuelve automáticamente el tratamiento permitido en otro. Identifica las entidades y jurisdicciones involucradas, consulta los equipos pertinentes y aplica procedimientos que gestionen el conflicto sin abandonar los deberes que sí sean aplicables.
Ejemplo: Un proveedor necesita transmitir datos de una transferencia a una contraparte extranjera. Revisa las reglas de ambos países y utiliza el procedimiento aprobado para resolver la solicitud.
Error frecuente: Error frecuente: enviar o retener información sin comprobar los requisitos aplicables a cada jurisdicción. La transferencia de datos exige contexto jurídico y operativo.
39. Conservación de registros
Fundamentos AML para criptoactivos y blockchain
Los registros permiten reconstruir decisiones, operaciones y controles, pero los tipos de documentos exigidos y sus periodos de conservación dependen de la jurisdicción y del marco aplicable. En un entorno cripto puede ser necesario preservar referencias de transacción, datos de clientes, análisis y decisiones de alerta. Define qué conservar, quién puede acceder y cómo asegurar integridad según las reglas pertinentes.
Ejemplo: Una investigación se cierra con una decisión de no escalar. El equipo conserva el análisis, las fuentes consultadas y la justificación de acuerdo con su política aplicable.
Error frecuente: Error frecuente: asumir un plazo de conservación universal o guardar únicamente la operación on-chain. Los requisitos y los registros necesarios varían según el caso.
40. Funciones de emisores y proveedores de stablecoins
Fundamentos AML para criptoactivos y blockchain
Una stablecoin puede involucrar emisores, administradores de reservas, distribuidores, plataformas de negociación y proveedores de servicios. Las responsabilidades de cada actor no se determinan solo por el token ni son idénticas en todas las jurisdicciones. Identifica quién emite, canjea, distribuye o presta servicios y qué función cumple en el flujo para analizar el marco aplicable.
Ejemplo: Un cliente compra una stablecoin en una plataforma y luego la canjea con un proveedor distinto. El análisis separa los roles antes de valorar controles y obligaciones.
Error frecuente: Error frecuente: atribuir al emisor todas las funciones del ecosistema o asumir que cualquier token estable tiene el mismo marco regulatorio.
60 conceptos para estudiar con aplicación práctica 41–50
41. Evaluación de riesgos de la entidad
Programas de gestión de riesgo para criptoactivos y blockchain
Una evaluación de riesgos de toda la entidad identifica cómo sus clientes, productos, geografías, canales y operaciones pueden exponerla a delitos financieros. Debe reflejar las actividades reales y orientar prioridades y controles, no limitarse a una plantilla anual. Actualízala cuando cambien productos, redes, amenazas o hallazgos para que las decisiones de primera línea y de dirección respondan al perfil vigente.
Ejemplo: Una plataforma incorpora retiros a una nueva red. El equipo actualiza su evaluación y determina qué cambios necesita el monitoreo.
Error frecuente: Error frecuente: tratar la evaluación como un documento estático que no influye en controles. Su valor está en conectar riesgos observados con decisiones y recursos.
42. Factores de riesgo y segmentación
Programas de gestión de riesgo para criptoactivos y blockchain
La segmentación permite comparar clientes y operaciones con características pertinentes, como producto, canal, geografía y comportamiento. Ningún factor aislado debería reemplazar el análisis del conjunto: una dirección de riesgo, por ejemplo, puede ser más o menos significativa según el uso y la exposición. Define categorías comprensibles y revisa si diferencian riesgos útiles sin introducir supuestos injustificados.
Ejemplo: El equipo distingue clientes minoristas de negocios institucionales y ajusta escenarios de monitoreo al comportamiento esperado de cada grupo.
Error frecuente: Error frecuente: usar un único factor, como país o volumen, para asignar automáticamente el riesgo total. La segmentación debe considerar varios elementos y contexto.
43. Riesgo inherente y riesgo residual
Programas de gestión de riesgo para criptoactivos y blockchain
El riesgo inherente describe la exposición antes de considerar controles; el riesgo residual es el que permanece después de evaluarlos. Separarlos ayuda a decidir si un producto necesita medidas adicionales o si las existentes reducen suficientemente la exposición. No confundas una actividad compleja con una falla de control: evalúa por separado las características del servicio y la efectividad de sus mitigaciones.
Ejemplo: Un servicio permite transferencias entre cadenas, lo que eleva la exposición inherente. El equipo analiza cómo los controles de trazabilidad afectan el riesgo residual.
Error frecuente: Error frecuente: llamar alto al riesgo residual solo porque el producto es complejo, sin valorar los controles. También es erróneo suponer que controles documentados eliminan el riesgo.
44. Controles proporcionales
Programas de gestión de riesgo para criptoactivos y blockchain
Un control proporcional responde a la naturaleza y magnitud del riesgo, a la información disponible y a las obligaciones aplicables. Puede consistir en pedir contexto, aplicar monitoreo, limitar una función o escalar una decisión, según el caso. Documenta la relación entre hallazgo, riesgo y medida elegida; ni la acción más restrictiva es automáticamente la más adecuada ni la más simple basta siempre.
Ejemplo: Una alerta muestra exposición indirecta sin otra anomalía. El investigador obtiene contexto y aumenta la revisión, en vez de cerrar o rechazar automáticamente.
Error frecuente: Error frecuente: tratar la máxima restricción como respuesta siempre más segura. Una medida debe ser eficaz, justificable y proporcional a los hechos.
45. Incorporación de clientes
Programas de gestión de riesgo para criptoactivos y blockchain
La incorporación comprende identificar al cliente y verificar su identidad con información y fuentes adecuadas al riesgo y a los requisitos aplicables. También permite comprender qué servicio solicita, el propósito de la relación y el uso esperado de la cuenta. Para clientes institucionales, incluye entender su actividad, estructura de propiedad y control, y determinar y verificar al beneficiario final cuando corresponda. Esta información proporciona una referencia para el monitoreo posterior; las brechas relevantes deben aclararse antes de habilitar el servicio, conforme al marco aplicable.
Ejemplo: Una empresa solicita una cuenta para invertir su tesorería, pero describe un flujo esperado de cobros y pagos por cuenta de terceros. Antes de habilitarla, el equipo aclara la función de la empresa, el propósito de la cuenta y los riesgos y requisitos de la actividad prevista.
Error frecuente: Error frecuente: limitar la incorporación a recopilar documentos. Verificar la identidad y comprender el propósito y el comportamiento esperado son tareas distintas y complementarias.
46. Screening de wallets
Programas de gestión de riesgo para criptoactivos y blockchain
El screening de wallets evalúa direcciones en la red correspondiente frente a listas, atribuciones y datos de exposición para identificar resultados que ameriten revisión o medidas aplicables. Debe distinguirse la coincidencia de una dirección concreta de una etiqueta analítica sobre su posible controlador o actividad. Su eficacia depende de la cobertura, calidad y actualización de las fuentes y de los parámetros utilizados. El resultado debe evaluarse con criterios documentados; una atribución de riesgo no demuestra por sí sola la identidad o la conducta del cliente.
Ejemplo: Al revisar un retiro, la herramienta etiqueta la dirección de destino como asociada a un servicio de riesgo. El analista confirma la red y la dirección, revisa la fuente y la fecha de la atribución y evalúa el contexto antes de decidir el escalamiento o las medidas aplicables.
Error frecuente: Error frecuente: considerar suficiente una coincidencia parcial de caracteres para identificar una dirección, o tratar una etiqueta como prueba de quién la controla. La dirección debe verificarse en la red correspondiente y la atribución debe evaluarse según su evidencia y grado de confianza.
47. Agrupación de direcciones y atribución
Programas de gestión de riesgo para criptoactivos y blockchain
Las herramientas analíticas pueden agrupar direcciones según patrones y otras señales para formular hipótesis sobre control común o actividad relacionada. Una agrupación no equivale necesariamente a una identificación verificada: la metodología, la fuente y el nivel de confianza son importantes. Registra qué dato respalda la atribución y evita convertir una inferencia probabilística en un hecho definitivo.
Ejemplo: Una herramienta agrupa varias direcciones como un posible servicio común. El investigador revisa la metodología y busca corroboración antes de asociarlas con un cliente.
Error frecuente: Error frecuente: presentar una etiqueta o agrupación de proveedor como prueba concluyente de identidad. La inferencia debe describirse con su grado de confianza.
48. Exposición directa e indirecta
Programas de gestión de riesgo para criptoactivos y blockchain
La exposición directa describe un flujo observado entre la dirección analizada y una contraparte identificada o atribuida. La exposición indirecta describe un vínculo reconstruido a través de direcciones, operaciones o servicios intermedios. Su interpretación depende de la calidad de la atribución, la secuencia de las operaciones y el método utilizado para asignar los flujos, especialmente cuando existen otras entradas de fondos. La distancia técnica no determina por sí sola el origen jurídico de los activos, el control de las direcciones ni la intención del cliente.
Ejemplo: En un depósito a la wallet de un cliente, la herramienta identifica una ruta previa desde una dirección atribuida a un robo, con dos direcciones intermedias. El investigador verifica la atribución, la secuencia y los montos, considera otras entradas en esas direcciones y busca contexto del cliente antes de decidir si escala el caso.
Error frecuente: Error frecuente: atribuir todo un depósito a la fuente inicial solo porque existe una ruta indirecta, o descartar el vínculo por tener varios saltos. La relevancia depende de la evidencia, del método de análisis y del contexto, no únicamente de la cantidad de intermediarios.
49. Monitoreo transaccional y comportamiento esperado
Programas de gestión de riesgo para criptoactivos y blockchain
El monitoreo transaccional busca detectar actividad que se aparta de lo esperado o combina señales relevantes. Los escenarios deben relacionarse con los riesgos de productos y clientes, y actualizarse cuando cambian los patrones. Una desviación genera una alerta para investigar; no determina por sí sola que exista sospecha suficiente ni que corresponda reportar bajo la ley local.
Ejemplo: Un cliente normalmente realiza pagos a proveedores y comienza a enviar activos a muchas direcciones nuevas. El sistema genera una alerta para revisar el cambio.
Error frecuente: Error frecuente: interpretar una alerta como hallazgo probado. El monitoreo identifica casos que necesitan análisis, no reemplaza la evaluación investigativa.
50. Clasificación y priorización de alertas
Programas de gestión de riesgo para criptoactivos y blockchain
La clasificación de alertas ayuda a asignar atención según riesgo, urgencia y evidencia inicial. Debe combinar criterios coherentes y permitir que señales relevantes se escalen sin depender de un único puntaje automático. Una alerta de menor prioridad aún necesita un tratamiento conforme al procedimiento; la priorización organiza recursos, pero no debe convertirse en una razón para ignorar indicios pertinentes.
Ejemplo: Dos alertas tienen puntajes similares. Una corresponde a un retiro pendiente hacia una dirección vinculada, mediante evidencia corroborada, a un robo reciente; la otra, a un aumento de volumen consistente con ventas documentadas del cliente. Conforme al procedimiento, el supervisor prioriza la revisión del retiro pendiente y documenta el motivo, sin considerar demostrado que el cliente participó en el robo.
Error frecuente: Error frecuente: asumir que el puntaje del sistema decide por completo el resultado. La revisión humana y el contexto siguen siendo necesarios.
60 conceptos para estudiar con aplicación práctica 51–60
51. Plan de investigación
Programas de gestión de riesgo para criptoactivos y blockchain
Una investigación eficaz convierte una alerta en preguntas verificables: qué actividad ocurrió, quién podría controlarla, qué explicación es plausible y qué evidencia falta. Define pasos y fuentes antes de cerrar una hipótesis, y registra qué resultados la confirman o debilitan. Un plan ordenado reduce decisiones precipitadas y evita ampliar la indagación sin una razón relacionada con el caso.
Ejemplo: Ante depósitos inusuales, el investigador formula preguntas sobre el origen, la ruta y el propósito, y consulta registros de la cuenta y fuentes on-chain.
Error frecuente: Error frecuente: buscar únicamente información que confirme la sospecha inicial. Una investigación sólida también busca hechos que puedan refutarla o explicar la actividad.
52. Corroboración on-chain y off-chain
Programas de gestión de riesgo para criptoactivos y blockchain
Los datos on-chain muestran operaciones registradas; los datos off-chain pueden aportar identidad, instrucciones, relaciones comerciales y contexto. La corroboración compara ambas fuentes y examina si se apoyan o contradicen entre sí. Una atribución analítica gana solidez cuando coincide con información independiente, pero cada fuente tiene límites: registra su procedencia y separa hechos observados de inferencias.
Ejemplo: La cadena muestra un retiro y los registros internos identifican la cuenta solicitante. El equipo compara horarios y datos antes de atribuir la operación.
Error frecuente: Error frecuente: considerar que dos fuentes repiten el mismo dato y por eso se corroboran. La independencia, la calidad y el alcance de cada fuente importan.
53. Escalamiento interno y gestión del caso
Programas de gestión de riesgo para criptoactivos y blockchain
El escalamiento interno traslada un caso al responsable con facultades para adoptar la decisión requerida. El expediente debe distinguir hechos, inferencias y brechas de información, e identificar las decisiones pendientes, los responsables y las acciones de seguimiento. El eventual reporte se determina conforme al marco jurisdiccional aplicable; escalar no equivale a reportar ni libera al equipo de dar seguimiento. El circuito interno debe permitir cumplir los plazos y demás obligaciones legales, sin retrasarlos por aprobaciones o asignaciones pendientes.
Ejemplo: Un analista identifica retiros a contrapartes no declaradas y documentos que no explican su finalidad. Registra las evidencias y las brechas, remite el expediente al responsable autorizado y verifica su recepción. El registro del caso identifica quién decidirá el eventual reporte y quién dará seguimiento a las medidas aprobadas.
Error frecuente: Error frecuente: considerar resuelto un caso porque se envió a otra área. Un escalamiento eficaz requiere un responsable definido, seguimiento y constancia de la decisión y de las acciones resultantes.
54. Monitoreo continuo y actualización del perfil
Programas de gestión de riesgo para criptoactivos y blockchain
El monitoreo continuo compara la actividad real con el perfil del cliente y con los riesgos identificados durante la relación. Los cambios de producto, volumen, contrapartes o propósito pueden justificar una revisión del perfil y de los controles. Define eventos que activen actualización y conserva el razonamiento; una incorporación correcta no garantiza que el comportamiento futuro siga siendo coherente.
Ejemplo: Una empresa empieza a operar con nuevos países y aumenta sustancialmente sus retiros. El equipo revisa el perfil y ajusta la evaluación si los hechos lo justifican.
Error frecuente: Error frecuente: considerar el proceso de conocimiento del cliente como una verificación única. El riesgo puede cambiar durante toda la relación.
55. Gobernanza y responsabilidades
Programas de gestión de riesgo para criptoactivos y blockchain
La gobernanza establece quién identifica riesgos, aprueba controles, investiga alertas y supervisa la eficacia del programa. Las responsabilidades deben corresponder al nivel de decisión y contar con recursos, escalamiento e información suficientes. Una política formal no demuestra por sí sola que la dirección supervise el programa o que las decisiones se ejecuten consistentemente.
Ejemplo: La dirección recibe informes de alertas pendientes y deficiencias de control. Asigna responsables y revisa el avance de las acciones correctivas.
Error frecuente: Error frecuente: asumir que el área de cumplimiento es la única responsable del riesgo. La gobernanza requiere responsabilidades claras en las funciones pertinentes.
56. Eficacia de diseño y eficacia operativa
Programas de gestión de riesgo para criptoactivos y blockchain
La eficacia de diseño pregunta si un control puede abordar el riesgo previsto; la eficacia operativa pregunta si se ejecuta de forma consistente y produce evidencia de su aplicación. Un control puede estar bien diseñado pero fallar en la práctica, o ejecutarse correctamente y ser insuficiente para el riesgo. Distinguir la causa ayuda a escoger entre rediseñar, capacitar, corregir procesos o reforzar la supervisión.
Ejemplo: El monitoreo genera alertas pertinentes, pero los analistas las cierran sin explicar su decisión. El hallazgo apunta a una falla operativa, no necesariamente a parámetros mal diseñados.
Error frecuente: Error frecuente: cambiar la herramienta ante cualquier hallazgo. Primero determina si el defecto está en el diseño del control o en su ejecución.
57. Pruebas y aseguramiento de controles
Programas de gestión de riesgo para criptoactivos y blockchain
Las pruebas comprueban si los controles están diseñados para los riesgos relevantes y si funcionan en las operaciones reales. Una prueba útil define alcance, muestra y criterios antes de revisar evidencias, y documenta limitaciones y hallazgos. La frecuencia y metodología dependen del programa y del marco aplicable; no basta con confirmar que existe una política o que el sistema estuvo encendido.
Ejemplo: El equipo toma una muestra de alertas cerradas y verifica si cada decisión tiene análisis, fuentes y aprobación cuando corresponde.
Error frecuente: Error frecuente: llamar prueba efectiva a una revisión superficial de políticas. Evaluar controles requiere evidencia de diseño y de ejecución.
58. Calibración y calidad de los modelos
Programas de gestión de riesgo para criptoactivos y blockchain
Los parámetros, reglas y modelos de monitoreo influyen en qué actividad se alerta y cuál podría pasar inadvertida. La calibración debe considerar riesgos relevantes, calidad de datos, resultados de investigaciones y posibles puntos ciegos. Revisa cambios y desempeño con criterios documentados; reducir alertas sin comprobar qué señales se pierden puede mejorar la carga operativa y, a la vez, debilitar la cobertura.
Ejemplo: Una actualización reduce las alertas duplicadas, pero el equipo prueba también escenarios de riesgo para confirmar que no desaparezcan señales importantes.
Error frecuente: Error frecuente: medir calidad solo por la cantidad de alertas. Menos alertas no significa mejor monitoreo si disminuye la detección pertinente.
59. Gestión de proveedores y herramientas externas
Programas de gestión de riesgo para criptoactivos y blockchain
Una entidad que utiliza analítica, screening u otros servicios externos sigue necesitando entender su cobertura, limitaciones, actualizaciones y dependencia operativa. Evalúa cómo el proveedor obtiene datos y comunica cambios, y define controles para errores, interrupciones y resultados dudosos. La herramienta apoya decisiones; no sustituye la responsabilidad interna de validar sus resultados y mantener procedimientos adecuados.
Ejemplo: Un proveedor cambia su método de atribución de direcciones. La entidad revisa el impacto, documenta la evaluación y ajusta procedimientos si resulta necesario.
Error frecuente: Error frecuente: tratar una herramienta reconocida como fuente infalible. Los resultados dependen de datos y métodos que deben comprenderse y supervisarse.
60. Remediación y respuesta ante incidentes
Programas de gestión de riesgo para criptoactivos y blockchain
La respuesta ante una deficiencia o incidente debe contener el riesgo, preservar información relevante, asignar responsables y corregir la causa, no solo cerrar el hallazgo visible. Define medidas inmediatas y acciones duraderas, con fechas y una comprobación posterior. La intensidad depende del impacto y del marco aplicable; documenta decisiones y escala cuando se afecten activos, datos, clientes o controles críticos.
Ejemplo: Una falla de integración impide revisar algunos retiros. El equipo evalúa el alcance, activa controles alternativos, conserva los registros y verifica la reparación.
Error frecuente: Error frecuente: marcar una acción como resuelta tras instalar un arreglo. La remediación requiere comprobar que la causa quedó atendida y que el control opera.
Plan de estudio en seis pasos
Fuente oficial y nota editorial
Fuente oficial consultada: ACAMS, Certified Cryptoasset Anti-Financial Crime Specialist Certification (CCAS), https://www.acams.org/en/certifications/certified-cryptoasset-anti-financial-crime-specialist-certification-ccas. Información de versión verificada el 11 de octubre de 2026 según el dossier de referencia. Las prioridades de estudio son editoriales, no ponderaciones oficiales. Esta guía es material independiente y no contiene preguntas reales del examen.