Pagos10 min de lectura

ISO 20022 y la Nueva Intersección del Dinero: Qué Significa la Convergencia TradFi-DeFi para la Orquestación de Pagos

La convergencia TradFi-DeFi se rompe en la capa de settlement, no en la capa de datos. Las transferencias de crédito SEPA se liquidan a través de compensación neta diferida con finalidad T+1 confirmada por un mecanismo de compensación y liquidación. Las transacciones on-chain se liquidan a través de liquidación bruta atómica con finalidad determinada por la profundidad de confirmación de bloque. No son solo diferentes velocidades. Son diferentes supuestos sobre finalidad, reversibilidad y recuperación que una capa de orquestación de pagos debe resolver explícitamente antes de poder manejar cualquier modelo correctamente.

ISO 20022 proporciona un lenguaje de datos común para ambos mundos. La estructura de mensaje que transporta una transferencia de crédito SEPA pacs.008 puede, con extensiones, transportar una instrucción de transferencia on-chain. La taxonomía BankTransactionCode clasifica tipos de pago tradicionales; el estándar se está extendiendo para cubrir movimientos de activos tokenizados. El formato de datos es un problema resuelto. El modelo de orquestación no lo es.

Dos Modelos de Liquidación, Dos Supuestos de Finalidad

La compensación neta diferida funciona acumulando obligaciones compensatorias entre participantes durante el día y compensándolas en ventanas de compensación definidas. Un pacs.008 enviado a las 09:00 puede no liquidarse hasta el ciclo de compensación de las 14:00. Durante esa ventana, el pago es un reclamo, no una transferencia liquidada. El reclamo puede ser rechazado (reconocimiento negativo pacs.002), recordado (solicitud de cancelación camt.056) o devuelto después de la liquidación (pacs.004 transacción R). La finalidad es irrevocable solo después de que cierre la ventana de compensación.

La capa de orquestación debe rastrear este ciclo de vida. Un pago que ha sido enviado pero no liquidado está en un estado intermedio conocido: ENVIADO_A_COMPENSACION. Un pago que se ha liquidado es LIQUIDADO. Un pago que ha sido devuelto es DEVUELTO. El ledger debe tratar estos estados de forma distinta: no marcar el débito como final hasta que se confirme la liquidación, porque la ventana de transacciones R sigue abierta.

La liquidación on-chain es atómica y final al confirmarse. Cuando una transacción se incluye en un bloque confirmado en una cadena determinista, está liquidada. No hay intermediario. No hay ventana de compensación. No hay mecanismo para revertirla a través de un proceso estructurado de transacciones R. Solo el originador puede iniciar una nueva transacción compensatoria, que aparece en el ledger como una entrada separada, no como una reversión de la original.

El supuesto de finalidad es diferente en tipo, no en grado. La finalidad de liquidación TradFi es un constructo legal: el acuerdo de compensación, las reglas del esquema de pago y la regulación aplicable (PSD2 Art. 80-81 sobre finalidad de liquidación) definen cuándo un pago es irrevocable. La finalidad de liquidación on-chain es un constructo matemático: es la probabilidad de que el bloque que contiene la transacción sea reorganizado fuera de la cadena canónica. Para fines prácticos, se alcanza la finalidad después de un número definido de confirmaciones de bloque, pero ese número varía según la cadena, el tiempo de bloque y el apetito de riesgo de la institución.

Dónde Debe Adaptarse la Capa de Orquestación

Una capa de orquestación de pagos diseñada exclusivamente para SEPA tiene cinco supuestos integrados: la liquidación es por lotes, la finalidad proviene de una red de compensación, las transacciones R son el mecanismo de reversión, los plazos se miden en horas, y la identificación de la contraparte es mediante IBAN. Cada supuesto se rompe para la liquidación on-chain.

Lotes vs. atomicidad. El envío por lotes de SEPA requiere recopilar transferencias, construir un mensaje masivo pacs.008 y enviarlo dentro de la ventana de compensación. El envío on-chain requiere firmar una transacción y transmitirla. La capa de orquestación debe distinguir entre estos modelos de envío por tipo de instrumento. Un único marco de orquestación que trate todos los envíos de pago como envíos por lotes basados en cola introducirá latencia innecesaria para las transferencias on-chain y gestión incorrecta del ciclo de vida para las transferencias SEPA.

Confirmación de finalidad. Para SEPA, la confirmación de finalidad llega como una notificación de crédito camt.054 o un reconocimiento positivo pacs.002 de la red de compensación. Para transferencias on-chain, la confirmación de finalidad requiere monitorear la cadena hasta alcanzar la profundidad de bloque objetivo. La capa de orquestación debe sondear o suscribirse al estado de la cadena, un mecanismo que no tiene análogo en el procesamiento de SEPA. El modelo de timeout también es diferente: SEPA tiene ventanas de compensación definidas y mensajes de rechazo explícitos. Una transacción on-chain que no se confirma en un tiempo razonable no es rechazada; sigue pendiente, potencialmente atascada en el mempool, y requiere intervención manual o retransmisión con tarifas más altas.

Mecanismo de reversión. Cuando un pago SEPA debe revertirse después de la liquidación, el mecanismo estándar es pacs.004 (Devolución de Pago) o camt.056 (Solicitud de Cancelación), ambos resultando en una transacción R estructurada con un código de motivo definido, un plazo definido y un tratamiento de ledger definido (entrada de corrección según HGB §239). Para transferencias on-chain, la reversión es una nueva transacción: débito del destinatario, crédito del remitente, referencia a la transacción original en los metadatos. La reversión no está estandarizada, no se clasifica automáticamente y no está sujeta a un plazo definido por el esquema. La capa de orquestación debe manejar ambos modelos de reversión con diferente lógica de registro.

Identificación de la contraparte. SEPA utiliza IBAN como identificador de cuenta principal. Las transferencias on-chain utilizan una dirección criptográfica (hash de clave pública). Una capa de orquestación que procese ambos debe resolver el modelo de dirección: ¿es una dirección blockchain un identificador de cuenta de primera clase almacenado en el ledger, o es una propiedad del registro CDD de un cliente? La respuesta afecta la deduplicación de clientes, el monitoreo de transacciones y el screening de sanciones, todos los cuales operan sobre el modelo IBAN y deben adaptarse para la identificación basada en direcciones.

ISO 20022 como Puente

La extensibilidad de ISO 20022 lo convierte en el puente de datos natural entre modelos de liquidación. Los tipos de mensaje pacs (pacs.008 para transferencias de crédito, pacs.004 para devoluciones) ya se usan para SEPA. Las mismas estructuras de mensaje, con códigos de instrumento local que identifican el modelo de liquidación, pueden transportar instrucciones de transferencia on-chain.

La taxonomía BankTransactionCode proporciona un marco de clasificación. PMNT/RCDT/ESCT identifica una transferencia de crédito SEPA entrante. Un nuevo código, PMNT/RCDT/TKNZ (transferencia de crédito entrante tokenizada) o equivalente, en desarrollo en los grupos de trabajo de extensión de ISO 20022, identificaría una transferencia on-chain entrante usando la misma estructura Dominio/Familia/Subfamilia. El motor AML, el motor de reconciliación y la canalización de reportes que ya consumen BankTransactionCodes pueden procesar transferencias tokenizadas sin un camino de código separado, una vez extendido el conjunto de códigos.

Los 27.500 millones de dólares en activos reales tokenizados on-chain a partir del Q1 2026, con un aumento del 30% en tres meses, representan un volumen que ninguna institución puede procesar manualmente a través de workflows separados. La presión de integrar transferencias de token en canalizaciones de pago estándar ya está presente. El estándar de datos está listo. El modelo de orquestación necesita ponerse al día.

Semántica de Exactly-Once a Través de Modelos de Liquidación

La ejecución exactamente una vez es más difícil de garantizar cuando el pago cruza modelos de liquidación. Un pago híbrido (iniciar on-chain, confirmar off-chain, liquidar el neto en fiat) crea un workflow de múltiples pasos donde cada paso tiene un modelo diferente de idempotencia y reversión.

Considere: un cliente inicia una transferencia on-chain de EUR 50.000 desde su depósito en euro tokenizado a la cuenta tokenizada de una contraparte. La institución receptora desea liquidación fiat. El workflow:

Débito de la cuenta tokenizada del cliente (on-chain, atómico, irreversible una vez confirmado)
Enviar una transferencia de crédito fiat a la institución de la contraparte (SEPA, por lotes, reversible vía transacción R)
Recibir confirmación de liquidación de la red de compensación
Acreditar la cuenta fiat de la contraparte

Si el paso 2 falla después de que el paso 1 hace commit, la compensación no es una reversión del paso 1. Es un nuevo crédito on-chain para devolver los fondos. Si el paso 3 falla después de que el paso 2 se envía, la capa de orquestación debe esperar a la confirmación de liquidación o una transacción R, luego acreditar o debitar en consecuencia. El modelo de compensación requiere rastrear el estado de liquidación de ambas piernas de forma independiente.

Un motor de ejecución durable registra cada paso antes de la ejecución. Si el motor se bloquea entre el paso 1 y el paso 2, reproduce el journal al reiniciar y reanuda en el paso 2. Si el paso 2 produce una transacción R (el pago SEPA es devuelto), el motor ejecuta el manejador de compensación: un nuevo crédito on-chain al originador, registrado como una entrada de corrección en el ledger. La secuencia completa, ambas piernas, el fallo y la compensación, existe en un journal con una ID de correlación.

Compromisos

La orquestación de pagos de modelo dual introduce una complejidad operativa que los sistemas puramente centrados en SEPA evitan.

Multiplicación de modos de fallo. Cada modelo de liquidación tiene sus propios modos de fallo. Un sistema que maneja ambos debe manejar ambos conjuntos: transacciones R de SEPA, interrupciones de redes de compensación y fallos de envío por lotes por un lado; congestión de mempool, riesgo de reorganización, problemas de conectividad de nodos y fallos de resolución de direcciones por el otro. El equipo de operaciones debe estar capacitado y equipado para ambos.

Asimetría de latencia. La liquidación on-chain para algunos instrumentos toma segundos. La liquidación SEPA toma horas. Un sistema que presenta ambos como "pago" debe hacer explícita la diferencia de latencia a los clientes y a los sistemas posteriores que dependen de la confirmación de liquidación. Tratar la liquidación on-chain como un análogo SEPA rápido, usando el mismo tiempo de liquidación esperado en sistemas posteriores, producirá reportes incorrectos y cálculos de capital incorrectos.

Clasificación regulatoria. La clasificación legal de una transferencia on-chain difiere de una transferencia SEPA de maneras que afectan el tratamiento regulatorio aplicable. Bajo MiCAR, las transferencias de EMTs conllevan obligaciones AML específicas. Bajo PSD2, las transferencias fiat conllevan obligaciones diferentes. Un pago que cruza modelos (fiat adentro, token afuera, o token adentro, fiat afuera) debe clasificarse correctamente para cada pierna de forma independiente. La canalización de compliance debe manejar la clasificación regulatoria compuesta, no una única categoría por transacción.

Fernel Context

La orquestación de pagos de Fernel utiliza modelos de mensajes nativos ISO 20022 para tipos de pago SEPA, con BankTransactionCodes almacenados nativamente en lugar de traducidos a códigos propietarios. El motor de ejecución durable registra cada paso del workflow de pago, incluidos los estados del ciclo de vida de liquidación ENVIADO_A_COMPENSACION, LIQUIDADO_PENDIENTE y LIQUIDADO_DISPONIBLE, antes de la ejecución. Extender el mismo modelo de orquestación para cubrir la liquidación on-chain requiere agregar un nuevo adaptador de liquidación (monitoreo de cadena, resolución de direcciones, seguimiento de confirmaciones) sin modificar el motor de workflow o el ledger. El modelo de journal es agnóstico al modelo de liquidación por diseño: cada paso lleva su propio registro de entrada/salida independientemente de si la operación subyacente es un envío SEPA o una transmisión de cadena.

Leer más: Pagos, Orquestación de Pagos | ISO 20022: Más Allá de la Conversión de Formato de Mensaje | Entendiendo las Transacciones R de SEPA

Fuentes:

Money20/20 Europe 2026, The New Intersection of Money: Where TradFi and DeFi Converge, coautoría de Scarlett Sieber et al.
Cambridge Centre for Alternative Finance, Tokenized RWA T1 2026: 27.500 millones de dólares on-chain, +30% en 3 meses
ISO 20022 pacs.008.001.11 (Credit Transfer), pacs.004.001.11 (Payment Return): especificaciones de estructura de mensajes
ISO 20022 BankTransactionCode External Code Sets, taxonomía Dominio/Familia/Subfamilia
PSD2, Directiva 2015/2366, Art. 80-81 (Finalidad de liquidación e irrevocabilidad)
MiCAR, Reglamento (UE) 2023/1114, Art. 83 (Obligaciones AML para instrumentos de transferencia tokenizados)
EPC SCT Inst Rulebook (v2024.1): modelo de liquidación y tiempos de SEPA Instant Credit Transfer