La mayor parte de las iniciativas de activos digitales en banca no se detienen por la tecnología de la red, sino por la integración. Según The Financial Grid 2026, una encuesta a 638 directivos, el 88% de las instituciones financieras ha comprometido presupuesto para activos digitales, pero solo el 16% ha llegado a producción. Entre ambas cifras está, en buena medida, el trabajo de conectar lo que ocurre on-chain con los sistemas que el banco ya utiliza para operar, contabilizar y reportar.
Este artículo describe esa integración en términos prácticos: cómo se corresponden las operaciones on-chain con el core bancario, cómo se concilian los registros, cómo se generan los datos contables y fiscales y qué eventos operativos deben contemplarse.
Cómo se corresponde una operación on-chain con el core
Toda operación en la red tiene un equivalente en los sistemas del banco. El diseño de la integración consiste en definir esa correspondencia de forma explícita y sin ambigüedades.
- Identidad del cliente. La operación se asocia al cliente que el banco ya ha identificado. El KYC no cambia y no se crea una identidad paralela; las direcciones o wallets se vinculan al identificador interno del cliente.
- Cuentas. Cada wallet, individual u ómnibus, se relaciona con las cuentas del cliente o con cuentas técnicas del banco. En el modelo ómnibus, el desglose por cliente vive en el registro interno, no en la red.
- Movimientos de efectivo. Una inversión implica un cargo en la cuenta en moneda del cliente y, en su caso, una conversión a stablecoin. Ambos movimientos deben reflejarse en el core con la misma referencia de operación.
- Posiciones. Los activos digitales y las acciones tokenizadas se registran como posiciones del cliente, con cantidad, coste y valoración, de forma que aparezcan en su posición global junto al resto de productos.
La regla que ordena todo lo anterior es sencilla: los sistemas de registro del banco siguen siendo la fuente de verdad para el cliente, la contabilidad y el supervisor. La red es un registro adicional que debe cuadrar con ellos.
El problema de la conciliación
En una operativa con activos on-chain conviven tres registros: el de la red, el registro interno de la infraestructura (operaciones, posiciones y saldos por cliente) y el core bancario. Los tres deben coincidir, y en la práctica no siempre lo hacen en el mismo instante.
Las diferencias tienen causas conocidas: operaciones pendientes de confirmación, comisiones de red no imputadas, movimientos recibidos sin referencia o desfases temporales entre el cierre del core y la actividad continua de la red. La conciliación debe distinguir entre diferencias esperadas y transitorias y diferencias reales.
Por eso el enfoque correcto es que la infraestructura mantenga un historial completo de operaciones y posiciones y lo concilie de forma continua con la red, mientras el banco define los umbrales de tolerancia y el proceso de excepciones: quién revisa, en qué plazo, con qué información y cómo se documenta la resolución.
Asientos contables y valoración
El modelo contable es una decisión del banco. La infraestructura no debería imponer un tratamiento, sino generar los datos en el formato que la entidad necesita para registrar sus asientos.
Los datos mínimos por operación suelen incluir la fecha y hora de ejecución y de confirmación en la red, el cliente, el activo, la cantidad, el precio, el importe en moneda, las comisiones del banco y de la red, y las referencias cruzadas con el core. Con esa información, el área de contabilidad aplica su modelo y registra las entradas en sus propios sistemas.
La valoración requiere una política de precios definida: fuentes, frecuencia, hora de corte y tratamiento de activos con poca liquidez. Esa misma política debe aplicarse en los controles previos a la operación, en la posición que ve el cliente y en la valoración contable, para evitar discrepancias entre áreas.
Fiscalidad y reporting regulatorio
La Directiva (UE) 2023/2226, DAC8, introduce desde el 1 de enero de 2026 obligaciones de información sobre operaciones con criptoactivos. El banco necesita, por tanto, un histórico completo y trazable por cliente: adquisiciones, transmisiones, transferencias y valores en cada momento. Si ese histórico se construye desde el primer día con la granularidad adecuada, el reporting fiscal es una extracción; si no, es una reconstrucción.
Lo mismo ocurre con el reporting regulatorio. La regla de viaje del Reglamento (UE) 2023/1113 exige información de ordenante y beneficiario en las transferencias de criptoactivos, y el Reglamento (UE) 2022/2554, DORA, exige gestión y registro de incidentes y de proveedores tecnológicos. En ambos casos, el banco produce el reporting con datos que la infraestructura debe entregar completos y consistentes.
Eventos operativos que el core no conoce
La red introduce eventos sin equivalente directo en la operativa tradicional, y la integración debe darles un tratamiento explícito.
- Comisiones de red. Variables y pagadas en el activo nativo de la red. Hay que decidir quién las asume, cómo se imputan y en qué cuenta se registran.
- Confirmaciones y finalidad. Una operación enviada no está liquidada hasta que alcanza la finalidad definida. El core debe distinguir entre operación iniciada, confirmada y final.
- Transacciones fallidas. Una operación puede fallar después de haberse iniciado. Los movimientos provisionales en el core deben revertirse de forma controlada.
- Disponibilidad continua. La red opera 24/7; el core puede tener ventanas de cierre. Hay que definir cómo se registran las operaciones fuera de horario.
Por qué desplegar dentro del banco
Estas integraciones son más sencillas y más seguras cuando la infraestructura se despliega dentro del perímetro del banco. Los datos de clientes y operaciones no salen de la entidad, las claves se custodian en sus HSM y la integración se hace directamente contra el core, los sistemas de monitorización y la contabilidad, sin intermediarios externos. Los sistemas de registro del banco siguen siendo la referencia, y el banco mantiene el control operativo y regulatorio.
Por la misma razón, una prueba de concepto debería validar la integración desde el principio y no solo la operación en la red. Estos son los puntos que conviene comprobar:
- Vinculación de wallets con la identidad y las cuentas existentes del cliente.
- Reflejo de cada operación en el core con una referencia única.
- Conciliación entre la red, el registro interno y el core, con umbrales y excepciones.
- Generación de datos contables en el formato que requiere la entidad.
- Política de precios única para controles, posición del cliente y valoración.
- Histórico fiscal por cliente compatible con DAC8.
- Tratamiento de comisiones de red, fallos y finalidad.
- Custodia de claves en los HSM del banco y políticas de firma.
En Finhattan trabajamos este proceso junto al equipo del banco, siempre a partir de una prueba de concepto; los detalles están en la solución y en cómo trabajamos.
Para las entidades que quieran revisar su propio caso, es posible concertar una conversación técnica a través de contacto.