Resumen

  • IBM presentó dos funciones en beta: Digital Asset Haven totalmente local y un adaptador ISO 20022 para el registro blockchain compartido de Swift. En la modalidad local, solución y gestión de llaves permanecen en IBM Z o LinuxONE del cliente.
  • Swift opera la capa compartida, los bancos conservan activos y financiación, y la liquidación final continúa fuera del registro mediante infraestructuras existentes. Autorizar, aceptar en el registro y liquidar son actos distintos.
  • El comprador debería exigir una cadena de comprobantes que una política, firma, transformación del mensaje, aceptación, reintentos y momento de irrevocabilidad. La soberanía de un componente no describe la del servicio completo.

La novedad comercial no es otra cartera digital. Es la posibilidad de que una entidad regulada mantenga dentro de su perímetro el software que decide una transacción y el material criptográfico que la firma. IBM dice que la versión local de Digital Asset Haven se instala en el centro de datos del cliente, sin nube pública, sobre IBM Z o LinuxONE. Incluye HSM Crypto Express, separación de entornos y ceremonias de llaves con documentación auditable.

Eso delimita una responsabilidad concreta. El banco puede gobernar quién administra la plataforma, quién aprueba, qué política se ejecuta y dónde reside la llave. No conviene ampliar la afirmación: la oferta está en beta y no trae una fecha de disponibilidad general, un precio, un volumen de producción ni métricas de transacciones bancarias reales.

La segunda beta conecta ese recinto local con una infraestructura ajena. El adaptador toma mensajes ISO 20022 y los vincula a transacciones en el registro compartido de Swift. Digital Asset Haven aporta carteras, firma, reglas y conectividad con Hyperledger Besu. La ventaja es operativa: el banco puede conservar vocabulario, datos y controles ya integrados en sus procesos.

Swift, sin embargo, opera el registro. Las entidades mantienen sus propios activos y financiación; la capa compartida valida y sincroniza compromisos. Swift comunicó en julio que el registro estaba preparado para uso inicial y que diecisiete bancos de seis continentes se disponían a pilotar transacciones en depósitos tokenizados. Su página actual enumera las entidades. Es una prueba de coordinación sectorial, no de adopción general ni de rentabilidad demostrada.

Luego llega el límite decisivo. IBM explica que los activos pueden moverse todo el día antes de que la liquidación final ocurra en sistemas existentes. Swift dice que la liquidación permanece fuera del registro. El registro puede ordenar un compromiso de pago sin convertirse en el lugar donde ese compromiso adquiere finalidad jurídica y económica.

No hay un único “hecho de pago”

Dentro del banco debe quedar un comprobante de intención: solicitante, propósito, versión de política, aprobadores, llave HSM, firma y cualquier excepción. La localización mejora la custodia de esa prueba. No garantiza que la persona correcta tuviera mandato ni que la orden haya salido del banco.

En el siguiente tramo se necesita otro comprobante. Debe vincular la huella del mensaje ISO 20022 con la transacción enviada, registrar la transformación, conservar el identificador de idempotencia y distinguir rechazo, espera, reintento y aceptación. Si una respuesta se pierde, el sistema debe saber si vuelve a consultar el mismo compromiso o crea otro.

La liquidación exige una tercera prueba: infraestructura utilizada, posición debitada o acreditada, hora de finalidad y punto de no retorno. Los PFMI de CPMI-IOSCO piden reglas claras para esos momentos porque el riesgo existe tanto si se liquida en los libros de la propia infraestructura como en los de un tercero.

Separar los comprobantes evita una ilusión frecuente. Una orden firmada puede no llegar a Swift. Una orden aceptada por Swift puede esperar a que abra o se recupere el sistema de liquidación. Una operación reintentada puede quedar duplicada. Un panel que etiqueta todos esos estados como “completado” convierte la integración en una caja negra.

Un idioma común no reparte las pérdidas

ISO 20022 reduce fricción al ofrecer estructuras e identificadores conocidos. No decide por sí solo si había fondos suficientes, si un control de cumplimiento era correcto, cuándo surge la finalidad en cada jurisdicción ni quién responde por un estado dividido. El formato puede llevar evidencia; no puede sustituir el acuerdo institucional que le da efecto.

También debe leerse con cuidado la cifra de disponibilidad de IBM. El 99,999999 % corresponde a mediciones y proyecciones internas para una configuración detallada de LinuxONE, z/VM, OpenShift, Operations Manager, GDPS y DS8000. No es un resultado de punta a punta para adaptador, Swift, banco corresponsal, RTGS y beneficiario. Cada capa necesita su propio denominador y su propia obligación de recuperación.

IBM afirma que las modalidades SaaS, híbrida y local comparten arquitectura, API y flujos. Eso puede evitar reescribir aplicaciones. La salida comercial se prueba trasladando llaves, políticas, expedientes de excepciones y comprobantes a otra modalidad, no comparando nombres de API.

Frontera de evidencia

El estado beta, el despliegue local, el adaptador y la cifra condicionada proceden del comunicado de IBM, la nota técnica-comercial y la página de Digital Asset Haven. El reparto operativo se documenta en el anuncio de julio de Swift y su página del registro. El marco independiente está en los PFMI y el informe BIS/CPMI sobre tokenización. La cadena de comprobantes es una prueba editorial.