DAC8 ya no es principalmente una fecha futura de reporting. Desde el 1 de enero de 2026, el cambio importante para los crypto providers dentro del perímetro es que la transparencia fiscal se ha convertido en un proceso operativo de datos: identificar al usuario, establecer residencia fiscal, clasificar entidades y controlling persons, clasificar transacciones, conservar evidencia y remediar información ausente o poco fiable.
Los primeros intercambios llegan después. La arquitectura de datos tiene que funcionar ahora.
Tres ideas clave
- 2026 es un año de controles, no de espera. DAC8 exige a los providers incluidos recopilar información sobre transacciones cripto reportables de usuarios residentes en la UE desde el 1 de enero de 2026.
- El KYC existente ayuda, pero no basta por sí solo. Tax-residence self-certification, TINs, controlling-person logic, agregación de transacciones y change-of-circumstances controls crean un workflow específico de tax reporting.
- El reporting sigue sin decidir el impuesto. DAC8 hace intercambiable la información; residencia, tipo de contribuyente, actividad y derecho fiscal doméstico determinan el resultado tributario sustantivo.
Qué cambió el 1 de enero de 2026
La Comisión Europea describe DAC8 como la ampliación del intercambio automático de información fiscal a crypto-assets. Los Estados miembros debían transponer la Directiva antes de terminar 2025 y aplicarla desde el 1 de enero de 2026.
Para los Reporting Crypto-Asset Service Providers, o RCASPs, esa fecha importa porque inicia el primer reporting year.
La cronología pública sencilla —recopilar en 2026, reportar e intercambiar en 2027— es útil. Pero oculta el problema real de implementación.
Un reporte que vence el próximo año solo puede ser correcto si onboarding, sistemas transaccionales y controles de evidencia funcionan durante todo este año.
RCASP no es simplemente otro nombre para CASP
MiCA y DAC8 se solapan alrededor de los servicios cripto, pero son sistemas jurídicos diferentes.
MiCA pregunta por market authorisation, servicios regulados, conduct, requisitos prudenciales y obligaciones de productos o emisores.
DAC8 pregunta qué operadores tienen obligaciones de información fiscal, qué usuarios son reportables, qué due diligence debe realizarse y qué transacciones deben reportarse e intercambiarse.
Una autorización MiCA no completa el análisis DAC8. Del mismo modo, una obligación DAC8 no autoriza por sí sola un servicio cripto.
Esta distinción es central para construir el mapa de compliance:
licence → regulated business → operational readiness → bankability → tax position → information reporting están conectados, pero ninguno sustituye a los demás.
La identidad se convierte en identidad fiscal
El customer onboarding ordinario ya recoge información de identidad. DAC8 añade una finalidad de tax information.
Los campos de reporting de la Directiva pueden incluir nombre, dirección, residencia fiscal, TIN y fecha de nacimiento del usuario. Para entidades, el provider puede tener que identificar además controlling persons reportables y su información de residencia fiscal.
Eso significa que el provider necesita algo más que un documento que demuestre que la persona existe.
Necesita una respuesta defendible a otra pregunta:
¿En qué jurisdicción o jurisdicciones es este usuario reportable a efectos de información fiscal?
Un pasaporte puede ayudar a identificar a una persona. Por sí solo no responde dónde es residente fiscal.
La self-certification necesita un lifecycle
Una self-certification de residencia fiscal no es una casilla eterna si hechos posteriores la vuelven poco fiable.
DAC8 obliga a confirmar la razonabilidad de las self-certifications utilizando información obtenida durante customer due diligence. Para entity users, el provider también debe tratar controlling persons cuando las reglas lo exigen.
Si cambian las circunstancias de manera que una self-certification anterior pase a ser incorrecta o poco fiable, el provider no puede mantener simplemente la respuesta antigua en la base de datos. Necesita una sustitución válida o una explicación adecuada y evidencia de soporte bajo el marco de la Directiva.
Así un formulario estático de onboarding se convierte en un lifecycle control:
recopilar → validar → monitorizar cambio → remediar → evidenciar.
Los entity users complican el modelo de datos
Una cuenta de entidad no puede reducirse al nombre de la sociedad y su registration number.
El RCASP puede tener que determinar residencia fiscal de la entidad, si entra en una categoría excluida o activa y si tiene controlling persons que sean reportable persons.
La información AML/KYC puede apoyar ese análisis. La Directiva permite utilizar información relevante de customer due diligence para identificar controlling persons bajo las condiciones especificadas.
Pero el resultado de tax reporting sigue siendo una determinación jurídica separada.
Por eso un buen beneficial-ownership file y un buen tax-residence file necesitan coexistir cada vez más.
Las transacciones necesitan una taxonomía de reporting
El segundo problema operativo es el transaction ledger.
La Comisión Europea explica que el reporting DAC8 se subdivide por reportable crypto-asset e incluye información cuantitativa como importes brutos agregados de adquisiciones o disposals frente a fiat u otros reportable crypto-assets y aggregate fair market value en transferencias.
Eso exige sistemas capaces de distinguir tipos de transacción de forma consistente.
El provider debe saber, por ejemplo, si un evento es adquisición, disposal, crypto-to-crypto exchange o transfer, qué activo interviene, cómo se capturan units y value y cómo se generan agregados anuales.
Un AML transaction log puede contener información útil sin haber sido diseñado para producir esa taxonomía.
Valuation y reconciliación es donde se acumulan los errores
Un tax-reporting file se vuelve frágil cuando los valores no reconcilian entre sistemas.
El provider puede tener order data, wallet data, custody records, fiat settlement records y accounting records. Si cada sistema usa timestamps, asset identifiers o valuation conventions distintos, el reporte anual puede contener contradicciones internas aunque cada sistema parezca razonable por separado.
El control práctico no es solo data collection. Es data reconciliation.
La empresa debería poder explicar cómo una reportable transaction pasa de execution a ledger, de ledger a valuation y de valuation a annual report.
La falta de tax data puede convertirse en restricción operativa
DAC8 contiene un mecanismo de due diligence especialmente importante.
Cuando un Crypto-Asset User no aporta la información exigida después de dos recordatorios posteriores a la solicitud inicial, y nunca antes de que transcurran 60 días, el RCASP debe impedir que el usuario realice Reportable Transactions.
Esa regla no debe exagerarse convirtiéndola en una afirmación universal de que cualquier dato ausente congela inmediatamente cualquier cuenta.
Su significado es más preciso: el due diligence de información fiscal puede afectar la capacidad del usuario para continuar actividad reportable.
El provider necesita por eso reminder logic, case management, escalation y evidencia de qué sucedió y cuándo.
La mejor objeción: los providers ya hacen KYC
Sí, y eso les da una base útil.
El error es asumir que un financial-crime onboarding file responde automáticamente todas las preguntas de tax reporting.
AML/KYC se concentra en identidad, beneficial ownership, financial-crime risk, source of funds y transaction monitoring bajo su propio marco jurídico. DAC8 añade residencia fiscal, TINs, reportable-user logic, análisis fiscal de entity/control, categorización de transacciones y reporting anual.
La solución eficiente no es construir dos bases de datos de clientes sin relación.
Es reutilizar datos fiables cuando sea jurídica y técnicamente apropiado preservando la lógica legal, evidencia y ownership separados del control DAC8.
La bankability sigue separada
La readiness DAC8 de un provider puede mejorar la calidad de sus registros y demostrar mejor governance frente a contrapartes financieras.
No garantiza banking.
Los bancos analizan sus propias cuestiones AML, sanctions, operativas y de risk appetite. DAC8 no es una bank-onboarding licence, y que un banco acepte el negocio tampoco prueba su compliance DAC8.
Ambos workstreams pueden compartir datos sin compartir la decisión.
Reporting es visibilidad, no la factura fiscal
Para el usuario, esta es la distinción más importante.
Un disposal, exchange o transfer reportado no aporta a la administración todo lo necesario para calcular el impuesto. Acquisition basis, residencia del contribuyente, capacidad, exenciones, pérdidas y reglas domésticas de clasificación pueden seguir siendo relevantes.
Pero la información se vuelve más fácil de comparar con tax returns y otros registros.
Eso cambia el valor de una buena documentación. Una posición fiscal que depende de hechos debería estar respaldada por esos hechos antes de que un information mismatch genere la pregunta.
Qué necesita operativamente un RCASP
Un programa DAC8 creíble debería poder responder siete preguntas:
- ¿Qué entidades y servicios del grupo son RCASPs bajo la implementación aplicable?
- ¿Qué usuarios son reportables y dónde son residentes fiscales?
- ¿Qué entity users requieren controlling-person analysis?
- ¿Son válidas y razonables las self-certifications y se monitorizan los cambios?
- ¿Puede mapearse cada transacción relevante a la categoría y valoración exigidas?
- ¿Reconcilian los registros de provider, wallet, settlement y contabilidad?
- ¿Puede la empresa evidenciar recordatorios, remediation, cambios y los datos utilizados en el reporte final?
Eso es lo que significa que la transparencia fiscal cripto se vuelva operativa.
Fuentes
- Comisión Europea — DAC8
- EUR-Lex — Directiva (UE) 2023/2226 del Consejo
- OECD — Crypto-Asset Reporting Framework y CRS modificado
Aviso
Este artículo ofrece información general sobre transparencia fiscal y compliance operativo. No constituye asesoramiento jurídico, fiscal, regulatorio, AML ni contable. El perímetro DAC8, la transposición doméstica, filing mechanics, plazos y sanciones deben comprobarse en el Estado miembro correspondiente y frente a las actividades exactas del provider inmediatamente antes de implementar o presentar información.
