Interledger Protocol: la visión de Ripple para conectar todos los sistemas de pago

En 1974, Vint Cerf y Bob Kahn publicaron el paper que definió TCP/IP, el protocolo que haría posible que redes informáticas heterogéneas comunicaran sin necesidad de conocer los detalles internos de cada una. Cincuenta años después, Stefan Thomas y Evan Schwartz, dos ingenieros de Ripple, propusieron en octubre de 2015 un protocolo^[1] con la misma ambición pero para los sistemas de pago: Interledger Protocol. La analogía es precisa. TCP/IP no se preocupa de si los datos viajan por fibra óptica, cobre o radio. ILP no se preocupa de si el dinero está en un banco alemán, una wallet de móvil keniata o una blockchain pública. Solo necesita poder enrutar paquetes de valor de un punto a otro, a través de cualquier infraestructura intermedia.

El problema: 4.000 millones de personas atrapadas en islas financieras

El sistema financiero global no es una red. Es un archipiélago de islas que solo se comunican mediante acuerdos bilaterales costosos y procesos de liquidación lentos. Cuando un banco en España quiere enviar dinero a un banco en Filipinas, necesita una cadena de corresponsales — el banco emisor trabaja con su banco corresponsal, que contacta al corresponsal del receptor, que finalmente entrega los fondos al beneficiario. Cada salto añade tiempo, coste y opacidad. El proceso puede tardar entre 1 y 5 días hábiles y consumir entre el 2% y el 8% del importe en comisiones acumuladas.

El problema se agrava para las personas sin acceso al sistema bancario formal. Según el Global Findex del Banco Mundial (2021), aproximadamente 1.400 millones de adultos en el mundo no tienen cuenta en ninguna institución financiera formal. Para ellos, enviar dinero a través de fronteras significa acudir a agentes de Western Union o MoneyGram que cobran entre el 5% y el 10% por el servicio. El coste global promedio de una remesa internacional se situaba en el 6,3% del importe en el primer trimestre de 2024 según el Banco Mundial, más de seis veces el objetivo del 1% establecido por los Objetivos de Desarrollo Sostenible de la ONU para 2030.

La raíz técnica del problema es la ausencia de un protocolo común. Los sistemas de pago hablan lenguajes incompatibles: SWIFT usa mensajes MT y MX, las redes de móvil usan APIs propietarias, las blockchains tienen formatos de transacción completamente distintos entre sí. Interoperarlos requiere acuerdos case-by-case, integraciones a medida y meses de negociación bilateral. ILP propone resolver exactamente esto con un protocolo de enrutamiento universal que abstraiga la heterogeneidad de los sistemas subyacentes.

Qué es ILP: el protocolo de internet para el valor

Interledger Protocol es un protocolo de capa de red para pagos, análogo a IP en la pila TCP/IP. No es un ledger, no es una blockchain, no es un medio de pago en sí mismo. Es el protocolo que permite que distintos ledgers — sistemas que registran quién debe qué a quién — intercambien valor entre sí sin necesidad de integraciones bilaterales directas.

La arquitectura básica de ILP tiene tres componentes: el emisor (quien inicia el pago), el receptor (quien recibe el valor), y uno o más conectores que enrutan los paquetes de valor entre ledgers que no están directamente conectados. Los conectores funcionan como routers de internet: no necesitan conocer la ruta completa de extremo a extremo, solo saben en qué dirección reenviar el siguiente paquete según su tabla de enrutamiento.

El mecanismo de seguridad que hace posible el enrutamiento sin confianza es el HTLC — Hash Time-Locked Contract. Cuando un conector recibe un paquete ILP PREPARE, bloquea el importe equivalente en su ledger local de forma condicional: el dinero solo se libera si el receptor demuestra haber recibido el pago (presentando el preimage del hash de la condición criptográfica) antes de que expire un timeout. Si el pago no se completa, el escrow se devuelve automáticamente. Nunca hay un intermediario que custodie los fondos con discrecionalidad.

ILP v4 (ILPv4), la versión actual del protocolo desde 2017, simplificó la arquitectura respecto a versiones anteriores y definió tres tipos de paquetes: PREPARE (tipo 12, del emisor hacia el receptor, lleva el importe y la condición criptográfica), FULFILL (tipo 13, del receptor hacia el emisor, lleva el preimage que desbloquea los escrows) y REJECT (tipo 14, en cualquier dirección, señala un error o timeout). La comunicación se basa en este ciclo, que permite liquidación atómica: o todos los escrows se liberan en la cadena correcta, o ninguno.

Pagos paquetizados: cómo fluye el valor a través de ILP

El concepto de pagos paquetizados es la innovación técnica más relevante de ILP. En lugar de enviar 1.000 euros como una sola transacción monolítica, el protocolo STREAM — la capa de transporte que se ejecuta sobre ILP — divide el pago en miles de micro-paquetes, cada uno de unos pocos céntimos. Este enfoque, análogo a cómo TCP divide los datos en segmentos, tiene ventajas significativas frente a la transferencia tradicional de lump-sum.

En primer lugar, permite el control de flujo dinámico: si una ruta de conectores no tiene suficiente liquidez para procesar paquetes completos, STREAM puede ralentizar automáticamente el envío y redirigir paquetes por rutas alternativas. En segundo lugar, hace posible los micropagos en tiempo real: si el coste de cada paquete es de 0,001 euros, es posible facturar servicios por el segundo de consumo, el kilobyte descargado o la página leída. En tercero, mejora la tolerancia a fallos: si un paquete es rechazado, el sistema puede retransmitirlo sin necesidad de rehacer todo el pago.

El protocolo de direccionamiento de ILP usa un esquema jerárquico similar a los dominios de internet. Una dirección ILP tiene la forma g.es.bankA.alice o g.ph.gcash.bob, donde g. indica la red global de ILP, el segundo componente es el país, el tercero el proveedor, y el cuarto el identificador del usuario o cuenta. Los conectores mantienen tablas de enrutamiento que mapean prefijos de direcciones a conexiones con otros conectores, permitiendo que los paquetes encuentren su ruta de forma distribuida.

El coste de convertir moneda en cada salto — EUR a XRP, XRP a PHP, por ejemplo — está incorporado en el diseño del sistema. Cada conector anuncia su tasa de conversión en el paquete PREPARE, y el emisor puede comparar rutas alternativas y seleccionar la más económica antes de comprometer el pago. La competencia entre conectores que ofrecen las mismas rutas presiona los márgenes hacia abajo, de manera análoga a como la competencia entre ISPs mantiene los precios de internet controlados.

XRP como conector universal: el papel de Ripple en ILP

Aunque ILP es un protocolo agnóstico — puede funcionar con cualquier activo como puente entre conectores — XRP desempeña un papel natural en la arquitectura de Ripple y de muchos operadores de conectores comerciales. La razón es estructural: XRP tiene liquidez en cientos de mercados en todo el mundo, se liquida en 3-5 segundos, y su coste de transacción es de fracciones de céntimo. Para un conector que necesita convertir euros en pesos filipinos en tiempo real, XRP como activo puente elimina la necesidad de mantener inventarios pre-fondeados en cada par de divisas.

Este es exactamente el caso de uso de On-Demand Liquidity (ODL), el servicio de pagos transfronterizos de Ripple. ODL usa ILP para enrutar los paquetes de valor, y usa XRP como activo puente en tiempo real: el emisor convierte su moneda local a XRP en un exchange origen, XRP se transfiere vía XRPL en 3-5 segundos, y el receptor convierte XRP a su moneda local en un exchange destino. El resultado es un corredor de pago que no requiere capital inmovilizado en cuentas nostro y que opera a cualquier hora sin depender de horarios bancarios.

Es importante distinguir entre ILP el protocolo (abierto, gestionado por la Interledger Foundation, independiente de Ripple desde 2019) y la implementación específica que Ripple hace de ILP en su producto ODL. Cualquier empresa puede implementar conectores ILP sin usar XRP. Pero la combinación de ILP + XRP + XRPL es la que Ripple ha validado comercialmente con más de 200 socios activos en pagos transfronterizos.

La separación entre Ripple y la Interledger Foundation fue deliberada y estratégica. En 2019, la fundación se estableció como organización sin ánimo de lucro independiente para desarrollar el protocolo sin los conflictos de interés que conllevaría que una empresa comercial controlara el estándar. Miembros fundadores como Coil, Mozilla, Creative Commons y la propia Ripple aportaron financiación y recursos técnicos. Esta estructura espeja la relación entre Cisco Systems y los estándares de internet: Cisco construyó un negocio enorme sobre TCP/IP sin tener propiedad sobre el protocolo.

Mojaloop: ILP para la inclusión financiera

El caso de uso más concreto y verificable de ILP a escala es Mojaloop, la plataforma open-source lanzada en 2017 con financiación inicial de la Fundación Bill y Melinda Gates de cuatro millones de dólares. El objetivo del proyecto era directo: crear infraestructura tecnológica que permitiera a los países con alta tasa de desbancarización construir sistemas de pago interoperables entre múltiples proveedores financieros — bancos, operadores de dinero móvil, fintechs y cooperativas — sin que cada par de proveedores tuviera que negociar acuerdos bilaterales.

Mojaloop implementa el Level One Project, el marco de diseño de sistemas de pago para mercados emergentes desarrollado por la Fundación Gates. Los principios fundamentales del Level One Project — empuje de pagos (no tirar), liquidación diferida con posiciones deudoras limitadas, estándares abiertos — se traducen directamente en la arquitectura técnica de Mojaloop, que usa ILP como protocolo de enrutamiento entre participantes.

Tanzania fue el primer país en desplegar Mojaloop a escala nacional. El sistema, conocido como Tanzania National Payment Switch, entró en producción en 2021 y conecta en tiempo real a los principales operadores de dinero móvil del país — M-Pesa Tanzania, Tigo Pesa, Airtel Money, Halotel — con bancos comerciales. El resultado: un usuario de M-Pesa puede enviar dinero a un usuario de Airtel Money instantáneamente, algo que antes era técnicamente imposible porque cada red funcionaba como un silo cerrado. El sistema procesa más de dos millones de transacciones diarias.

Las Maldivas implementaron Mojaloop en 2022 como infraestructura del sistema de pagos del Banco Central (MMA), con el objetivo de habilitar pagos instantáneos interbancarios y reducir la dependencia del efectivo en un archipiélago donde mover dinero físico entre islas es logísticamente costoso. Rwanda, Kenya, Nigeria, Ghana y Marruecos tienen proyectos en distintas fases de implementación o piloto.

Desde la perspectiva técnica, Mojaloop despliega ILP a través de un hub central que actúa como conector entre todos los participantes del sistema. Cada institución financiera que se une al sistema implementa una API FSPIOP (Financial Services Provider Interoperability Protocol) que traduce sus operaciones internas al vocabulario ILP. El hub gestiona el Account Lookup Service (para encontrar a qué institución pertenece un número de teléfono o identificador), el Settlement Service (para liquidación diferida entre participantes) y el módulo de Quote (para acordar tipos de cambio y comisiones antes de ejecutar la transacción).

Open Payments y Web Monetization: ILP en la economía digital

Más allá de los pagos bancarios y las remesas, la Interledger Foundation ha impulsado dos estándares adicionales que extienden ILP hacia la economía digital: Open Payments y Web Monetization.

Open Payments es una especificación IETF (propuesta como RFC) que define una API REST estándar para gestionar cuentas de pago compatibles con ILP. En lugar de que cada fintech desarrolle su propia API, Open Payments define cómo crear un Payment Pointer (un identificador de cuenta legible como $wallet.example/alice), cómo autorizar pagos entrantes, cómo iniciar transferencias salientes, y cómo gestionar grants de acceso entre aplicaciones de pago. Rafiki, el software de referencia de la Interledger Foundation, implementa Open Payments para que cualquier wallet o proveedor de servicios financieros pueda convertirse en un participante ILP sin construir desde cero la infraestructura de enrutamiento.

Web Monetization es una propuesta de estándar W3C que usa ILP para habilitar micropagos de streaming entre lectores de contenido web y creadores. La idea: en lugar de anuncios o muros de pago, un sitio web puede incluir un meta tag con su Payment Pointer, y un navegador compatible puede comenzar a transmitir micropagos al creador mientras el usuario consume el contenido, a razón de fracciones de céntimo por segundo. Coil, la startup que implementó Web Monetization de forma comercial (con financiación de Ripple), cerró sus operaciones en 2023 al no alcanzar masa crítica de adopción. El estándar técnico, sin embargo, sigue en desarrollo activo en el W3C Web Monetization Working Group.

El fracaso comercial de Coil no invalida la propuesta técnica, pero ilustra el reto de adopción que enfrenta cualquier protocolo de pagos: la red necesita alcanzar un punto de masa crítica donde hay suficientes emisores y receptores para que el ecosistema sea autosutenible. Es el mismo problema que enfrentó el correo electrónico en sus primeros años, o las tarjetas de crédito en los años 60. La pregunta no es si ILP es técnicamente correcto — lo es — sino cuánto tiempo lleva construir la red de conectores y participantes.

ILP vs SWIFT vs CBDCs: la batalla por la interoperabilidad global

La interoperabilidad de sistemas de pago es hoy una prioridad política y regulatoria de primer orden. El G20, el BIS, el FMI y el FSB han identificado los pagos transfronterizos lentos y caros como un problema sistémico con consecuencias sobre el desarrollo económico y la inclusión financiera. Tres aproximaciones compiten para resolver el problema a escala global, y cada una tiene sus fortalezas y limitaciones.

SWIFT gpi (Global Payments Innovation) es la respuesta de la red bancaria establecida. Lanzada en 2017, gpi introduye tracking en tiempo real de las transferencias MT103, tiempos de liquidación más cortos (muchas en menos de 30 minutos para corredores activos) y transparencia de comisiones. Para 2023, más del 90% de los pagos SWIFT se enviaban a través de gpi. El problema: gpi mejora la red existente pero no cambia su arquitectura fundamental — los bancos corresponsales, el capital inmovilizado en cuentas nostro, la dependencia de los horarios bancarios siguen siendo los mismos. La iniciativa ISO 20022 de SWIFT, que busca estandarizar el formato de mensajes a nivel global, es complementaria a gpi pero tampoco resuelve la interoperabilidad entre sistemas no-SWIFT.

Las CBDCs interbancarias — especialmente mBridge, el proyecto del BIS con los bancos centrales de China, Hong Kong, Tailandia y Emiratos Árabes — representan otro vector. mBridge usa una plataforma DLT propia para liquidar pagos entre bancos centrales participantes en tiempo real, eliminando la necesidad de corresponsales para esas jurisdicciones. Desde la perspectiva de ILP, las CBDCs son simplemente otro tipo de ledger que puede conectarse como participante. La pregunta es si los bancos centrales optarán por construir puentes ILP a sus plataformas CBDC o por construir corredores bilaterales propios.

ILP toma una aproximación diferente: en lugar de mejorar o reemplazar los sistemas existentes, opera como una capa de enrutamiento sobre todos ellos simultáneamente. Un banco que usa SWIFT puede ser un participante ILP. Una wallet de móvil que usa una API propietaria puede ser un participante ILP. Una CBDC puede ser un participante ILP. La propuesta de valor no es sustitución sino interoperabilidad universal. Esta posición agnóstica es también su mayor debilidad competitiva: no genera urgencia en ningún actor para adoptarla si ya tiene alternativas que funcionan para su caso de uso principal.

El punto donde ILP tiene ventaja comparativa clara es en los corredores que hoy no tienen solución comercialmente viable: remesas desde economías desarrolladas hacia mercados emergentes de baja liquidez, micropagos B2B entre empresas de distintos países, y pagos entre sistemas financieros que no tienen acuerdos bilaterales directos. Son exactamente los corredores donde opera ODL de Ripple y donde Mojaloop está construyendo infraestructura.

Limitaciones actuales y los retos pendientes

Una evaluación honesta de ILP en 2024-2025 debe reconocer que el protocolo todavía no ha alcanzado la escala que sus fundadores imaginaron en el whitepaper de 2015. Varias limitaciones técnicas y de adopción explican el ritmo más lento de lo esperado.

El problema de liquidez de los conectores es el más fundamental. Para que un conector pueda enrutar pagos entre EUR y PHP, necesita tener inventario de ambas monedas o acceso inmediato a liquidez en ambos mercados. Esto tiene un coste de capital que no existe en SWIFT, donde la liquidez se gestiona a través de las cuentas nostro de los bancos corresponsales (que también tienen coste, pero distribuido entre muchas más transacciones). Para corredores de volumen bajo, el coste de capital de ser un conector ILP puede superar los beneficios frente a las alternativas establecidas.

La fragmentación del ecosistema de wallets ralentiza la adopción en el segmento de consumo. Web Monetization no prosperó comercialmente en parte porque los usuarios necesitaban wallets compatibles con ILP que no existían en número suficiente. Rafiki mejora esto al bajar el coste de implementación para nuevos participantes, pero la trayectoria de adopción sigue siendo gradual.

El marco regulatorio para operadores de conectores ILP no está definido en la mayoría de jurisdicciones. Un conector que cambia moneda y mueve valor a través de fronteras puede ser clasificado como transmisor de dinero, exchange de criptomonedas, o ninguna de las dos cosas — dependiendo de qué activos use como puente y en qué jurisdicción opere. Esta ambigüedad regulatoria desincentiva la entrada de nuevos operadores.

Finalmente, la propuesta de integración de ILP con smart contracts y Hooks de XRPL — que permitiría condiciones programables más complejas en los pagos — sigue siendo más teórica que práctica. Los Hooks de XRPL están en testnet y la combinación con ILP requeriría implementación adicional que todavía no tiene casos de uso comerciales validados.

Conclusión: el protocolo que el sistema financiero necesita pero no ha elegido todavía

Interledger Protocol es, técnicamente, la respuesta más elegante al problema de interoperabilidad de sistemas de pago. La analogía con TCP/IP no es exagerada: la arquitectura modular, el enrutamiento distribuido, el mecanismo de escrow sin custodio, y la capacidad de funcionar sobre cualquier tipo de ledger son propiedades que ninguna solución centralizada puede replicar con la misma flexibilidad.

El estado actual es el de un protocolo sólido con adopción real en nichos específicos — Mojaloop en mercados emergentes, ODL en corredores de pago seleccionados — pero lejos todavía del despliegue universal que haría de ILP la infraestructura invisible de los pagos globales. Los próximos tres a cinco años serán determinantes: si los proyectos piloto de CBDC adoptan ILP como capa de interoperabilidad, si Open Payments gana tracción en el ecosistema de neobancos y fintechs, y si los costes de los conectores bajan con el aumento de volumen, ILP podría alcanzar el punto de inflexión donde la red se autosustenta.

Para el ecosistema XRP, la evolución de ILP tiene implicaciones directas. XRP es hoy el activo puente más utilizado en implementaciones comerciales de ILP precisamente porque XRPL ofrece las propiedades que un conector necesita: liquidez global, liquidación en segundos, coste mínimo por transacción. Que el protocolo que hace posible usar XRP como puente sea un estándar abierto y no una tecnología propietaria de Ripple es la garantía de que su adopción puede crecer más rápido que la capacidad de Ripple de venderlo bilateralmente.

Preguntas frecuentes

Referencias