Resumen

  • Murex anunció el 23 de septiembre que MX.3 había obtenido la certificación para Google Cloud. El destino se suma a una trayectoria que ya incluía Azure y AWS. El comunicado habla de clientes que exploran la posibilidad, pero no identifica una puesta en producción, plazo de migración, precio, prueba de rendimiento ni resultado de recuperación.
  • La certificación abarata la evaluación de otra infraestructura. No traslada automáticamente posiciones, colateral, corte de mercado, permisos, acuses de interfaces ni la secuencia de cierre. La salida solo es una opción real cuando el banco puede restaurar y conciliar ese estado dentro del tiempo tolerable.

En una presentación cabe dibujar una segunda nube junto al sistema de contingencia. En la madrugada de un día de mercado, el problema es otro: decidir qué operación quedó confirmada, qué movimiento de colateral ya obliga a las partes, qué precios alimentaron la valoración y qué pagos rebasaron el punto de cancelación. Si el sistema recuperado no reproduce esas respuestas, su disponibilidad técnica no autoriza la apertura del negocio.

Esa separación da sentido al anuncio de Murex del 23 de septiembre. MX.3 quedó certificado en Google Cloud para cargas de negociación, tesorería, riesgo y poscontratación. El texto incluye cálculos intensivos de riesgo de mercado y de contraparte, además de analítica intradía. Murex dice que varios clientes están explorando la posibilidad.

La noticia prueba un destino soportado, no un viaje completado. No se nombra a un cliente de producción ni se publican duración, coste, RPO, RTO, arquitectura regional o conciliación posterior. La diferencia importa porque la continuidad de una institución reside menos en arrancar software que en recuperar un estado común y aceptado.

El tercer destino crea una opción antes que una mudanza

La historia cloud de MX.3 no empezó esta semana. Murex anunció la certificación en Azure en 2017. Su página de cloud describe soporte para AWS y Microsoft Azure, varios modelos de despliegue y una adopción gradual que pasa por prueba de concepto, desarrollo, pruebas y producción. En 2025 también comunicó un acuerdo plurianual con AWS para ampliar sus servicios gestionados.

Google Cloud añade valor opcional. Un banco que implanta MX.3 puede comparar más propuestas de infraestructura, regiones, seguridad y operación. Un cliente existente puede plantear si el desarrollo, la recuperación o una parrilla elástica de riesgo deben residir en otro proveedor. Murex gana un canal; Google accede a una carga cercana al núcleo operativo de las entidades financieras.

La opción genera beneficios sin trasladar toda la producción. Mejora la negociación comercial, vuelve desechable un entorno de prueba o permite ampliar cálculos en otro sitio. Pero las capas no son intercambiables. Mover una parrilla de cálculo no hace fungible el registro de principio a fin. Encender un sitio alternativo tampoco demuestra que contenga el libro correcto. Elección de compra y capacidad de salida no son el mismo activo.

También conviene separar modelos. El acuerdo con AWS presenta MXSaaS como un servicio gestionado por Murex desde la infraestructura hasta las actualizaciones, además de describir XVA as a Service. El anuncio de Google Cloud habla de desplegar MX.3; no anuncia MXSaaS sobre Google Cloud. Certificación, IaaS administrada por el cliente y servicio gestionado reparten de manera distinta el trabajo y la responsabilidad.

MX.3 no es un único contenedor transportable

La arquitectura publicada de MX.3 incluye capas de presentación, negocio, orquestación y servicios técnicos. La última sostiene autenticación, autorización y registro de servicios. Distintos motores atienden los cálculos; las valoraciones complejas pueden distribuirse en CPU o GPU, y Kubernetes y contenedores se emplean en riesgo de mercado y reporting.

Ese uso no convierte todo el patrimonio en una caja sellada. Una instalación veterana reúne configuraciones de productos y libros, datos de mercado y referencia, certificados, claves, permisos, conexiones, calendarios por lotes, umbrales de alerta, excepciones y conocimiento de operadores. Algunas dependencias viven en el software; otras, en licencias, contratos de datos, ventanas de liquidación o aprobaciones internas.

Hay al menos cuatro formas de portabilidad. La de infraestructura permite recrear cómputo, almacenamiento y red. La de aplicación permite ejecutar componentes y versiones soportados. La de datos conserva un estado completo, ordenado y con el mismo significado. La operativa permite que equipos distintos ejecuten, protejan, concilien y recuperen el servicio con el nuevo reparto de funciones.

La certificación aporta evidencia sólida sobre las dos primeras. Las dos últimas siguen siendo específicas de cada cliente. Dependen de qué servicios nativos adopte, cómo construya las interfaces, dónde custodie claves e historial operativo, quién posea los manuales y si el destino alternativo ha completado un ejercicio de negocio.

El activo decisivo es el último estado aceptado

Recuperar procesos no basta en mercados de capitales. Una operación duplicada exagera la exposición. Un movimiento de garantía reconocido por una parte y ausente en la otra crea una disputa. Un corte de mercado equivocado cambia valoraciones y límites. Un pago ya liberado no puede reaparecer como pendiente.

El paquete de salida debe guardar más que archivos de base de datos: punto de recuperación declarado, diarios ordenados, procedencia, mensajes en curso, acuses externos, dependencias de procesos y reglas de conciliación. Para cada objeto hay que definir la fuente autorizada y quién resuelve un conflicto. Versión, configuración, permisos y aprobaciones también forman parte del estado.

Por eso es posible recrear servidores equivalentes sin recuperar un servicio apto para operar. Bases, identidades, colas, observabilidad, custodia de claves o controles de red propios del proveedor pueden mejorar el funcionamiento diario y ampliar el trabajo de reconstrucción. Evitar toda función nativa no siempre es sensato: sacrificaría fiabilidad y productividad. Lo importante es que la dependencia tenga inventario, coste, dueño y prueba.

Un ensayo inicial puede ser acotado. Se elige un servicio importante y un fallo definido; se restaura la aplicación con sus dependencias en el destino alternativo; se conecta un conjunto controlado de datos e interfaces; se comparan posiciones, efectivo, colateral, sensibilidades, confirmaciones y contabilidad con una referencia aprobada. Se registran tiempo, intervención manual, pérdida, excepciones y autoridad de aceptación. Ese registro vale más que un diagrama con dos nubes.

La regulación pide una salida practicable

Para entidades financieras europeas dentro de su ámbito, el artículo 28 de DORA exige estrategias de salida cuando los servicios TIC sostienen funciones críticas o importantes. La terminación no debe interrumpir el negocio, impedir el cumplimiento ni perjudicar la continuidad al cliente. Los planes deben ser completos, documentados, suficientemente probados y revisados; han de identificar alternativas y permitir el traslado seguro e íntegro del servicio y los datos o su reinternalización.

DORA no certifica una arquitectura MX.3 ni aprueba un despliegue en Google Cloud. Tampoco obliga a ejecutar cada carga activamente en varias nubes. Mantiene la responsabilidad en la entidad. Que el proveedor de software soporte otro destino ayuda; no constituye la prueba de salida del banco.

El análisis del Banco de Inglaterra sobre resiliencia operativa ofrece el motivo sistémico: la externalización y la dependencia de pocos terceros crean conexiones capaces de propagar una perturbación. Otro proveedor certificado reduce concentración en el mapa de compras. La reduce en la práctica si los servicios pueden moverse o recuperarse dentro del plazo admisible.

Cada modelo operativo vuelve a repartir la responsabilidad

Murex controla la certificación del software, los patrones soportados, el empaquetado de versiones y una parte del método técnico. Google Cloud controla sus regiones, capacidad, red y productos gestionados. Un integrador puede construir la base, automatizar el despliegue y operar una parte. En un servicio gestionado, el proveedor asume más tareas cotidianas.

La institución sigue siendo dueña de la decisión de negocio. Clasifica la criticidad, fija objetivos, aprueba datos e identidad, contrata conexiones a mercados, acepta conciliaciones y responde ante consejo y supervisores. Externalizar una tarea no externaliza el significado de una posición recuperada.

La matriz de responsabilidades debe cubrir normalidad y salida. ¿Quién mantiene el código de infraestructura? ¿Quién exporta configuración, registros y pruebas? ¿Quién aporta licencias durante la transición? ¿Quién abre la red, rota claves y valida las fuentes de mercado? ¿Quién autoriza reanudar la negociación? ¿Qué ayuda sigue disponible tras la terminación? Un comunicado general no responde esas preguntas de cada cliente.

Más elección puede profundizar primero el bloqueo

La nueva certificación encierra una paradoja. Las funciones nativas aceleran la entrega y motivan la adopción; luego los datos, la seguridad y la observación quedan más unidos al proveedor. La operación normal mejora mientras aumenta el coste de reproducirla. Es un intercambio que puede ser racional, pero demuestra que el número de certificaciones no mide la salida.

El resultado inverso aparece si Murex conserva artefactos portátiles, opciones de bases soportadas, fronteras claras y pruebas operativas comunes. Cada certificación puede estandarizar la ruta. Las migraciones repetidas forman especialistas y herramientas reutilizables. El mercado debería pedir esos recibos, no contar logotipos.

El alcance revelará más que el anuncio. Un caso debe aclarar si cubre desarrollo y prueba, parrilla de riesgo, recuperación, producción o todo el frente-a-riesgo. Una recuperación debe indicar servicio, punto, tiempo y conciliación. Una salida debe añadir formatos, ayuda contractual, personal, conexiones y coste total.