Summary

  • Murex announced on 23 September that MX.3 had achieved certification on Google Cloud, adding a deployment option to a cloud programme that already included Azure and AWS. The release says clients are exploring the possibility; it does not name a production go-live, migration timetable, price or recovery result.
  • Certification lowers the cost of considering another infrastructure. It does not reproduce the last accepted positions, collateral, market-data cut, permissions, interfaces, reconciliations or end-of-day sequence. A bank owns a usable exit option only when those elements can be restored and tested within its service tolerance.

A recovery diagram can gain a new destination in an afternoon. A live capital-markets book cannot. Before the opening bell, a bank may need prices from several vendors, validated curves, positions from multiple desks, collateral movements, limits, venue connections, payment instructions and accounting feeds to agree on the same business date. The order matters. So does the last accepted state. A green box labelled “Google Cloud” does not say which copy wins when two ledgers disagree.

That is the useful way to read Murex’s 23 September announcement. MX.3 has achieved certification on Google Cloud. The combination is presented for trading, treasury, risk and post-trade operations, including computationally heavy market-risk, counterparty-risk and intraday analytics. Murex says multiple clients are exploring the possibility of running the platform there.

The event is meaningful, but narrower than the language of cloud choice can sound. No production customer is named. The release supplies no migration duration, commercial terms, benchmark, recovery point, recovery time or exit test. It establishes a supported destination. It does not establish that a particular institution can reach it with its business state intact.

A third destination is an option, not an exercised route

Google Cloud is not MX.3’s first encounter with public infrastructure. Murex announced Azure certification in 2017. Its current cloud programme page describes support for AWS and Microsoft Azure, multiple deployment models and a phased path from proof of concept through development and testing to production. In 2025, Murex also announced a multi-year AWS agreement tied to its managed-services programme.

Google Cloud therefore adds option value. A bank evaluating a new MX.3 estate has another credible bidder for infrastructure, regions, security controls and operating services. An existing customer can ask whether a development grid, disaster-recovery environment or elastic risk workload belongs on a different provider. Murex gains another partner through which to sell and support the platform. Google gains access to a workload that sits close to the operating core of financial institutions.

None of those benefits requires live portability. Procurement leverage can improve even if production never moves. Development and test environments can become more disposable even if the books of record stay where they are. A risk grid can burst elsewhere without making the whole front-to-back estate fungible. “Choice” has several economic levels, and the announcement does not collapse them into one.

The distinction also matters for managed service. Murex’s AWS release says MXSaaS is managed by Murex from infrastructure through upgrades and separately describes XVA as a Service. The Google release says MX.3 can be deployed on Google Cloud; it does not say MXSaaS is now offered there. Certification, customer-managed infrastructure and a productised managed service allocate operations and liability differently. Buyers should not import the service boundary of one into the announcement of another.

MX.3 is a business sequence, not a portable container

The MX.3 architecture description explains why. The platform has presentation, business, orchestration and technical layers. Its technical layer handles functions such as authentication, authorization and service registry. Calculation services use different technologies, and intensive pricing or risk jobs can run across CPU or GPU grids. Kubernetes and containers are used for market-risk and reporting workloads.

That last fact is useful but easy to overextend. Containerising some compute does not turn the entire estate into a sealed object that can be lifted between providers. A production implementation includes configuration accumulated over years, reference and market data, books and portfolios, interfaces, certificates, keys, batch schedules, alert thresholds, user entitlements, exception queues and people who know why one process must wait for another. Some dependencies are technical. Others are contractual or institutional.

Portability therefore has at least four layers. Infrastructure portability asks whether compute, storage and network resources can be recreated. Application portability asks whether supported MX.3 components and versions operate correctly. Data portability asks whether the complete, ordered state can be exported, transferred and reconstituted without losing meaning. Operating portability asks whether teams can run, reconcile, secure and recover the service under the alternative arrangement.

Certification is strong evidence for part of the first two layers. It is not evidence for the last two in a specific bank. Those depend on choices made after the product arrives: which managed services are adopted, how interfaces are built, where keys and observability histories live, who owns runbooks, and how often the alternative is tested.

The valuable asset is the last accepted state

Capital-markets recovery is not satisfied by bringing processes back online. The recovered system has to know which business facts were accepted before the interruption. A position imported twice can inflate exposure. A collateral movement acknowledged by one side but absent from another can generate a dispute. A market-data snapshot from the wrong time can change valuation and limits. A payment released after the cut-off cannot be treated like an unsent instruction.

The exit package must therefore preserve more than database files. It needs a declared recovery point, ordered journals, source identifiers, pending-message states, interface acknowledgements, job dependencies and reconciliation rules. It should explain which external systems are authoritative for each object and who may resolve a conflict. It must also retain evidence that operators used the correct configuration, permissions and software release.

This is where a second cloud can remain nominal. A bank may be able to provision equivalent servers while lacking a repeatable way to recover the full business service. Provider-specific databases, identity products, queues, monitoring, encryption-key custody or network controls can speed ordinary operation and deepen the reconstruction task. Avoiding every native service is not automatically sensible; it can sacrifice reliability and engineering productivity. The relevant bargain is whether the added dependence is documented, priced and exercised.

The minimum credible rehearsal starts with a frozen scenario. Choose an important service and a defined disruption. Restore the application and its dependencies on the alternative destination. Reconnect a controlled set of data and interfaces. Reconcile positions, cash, collateral, sensitivities, confirmations and accounting outputs against an approved reference. Record elapsed time, manual intervention, data loss, exceptions and the people who accepted the result. A slide showing two clouds is not a substitute.

Regulation makes the exercise explicit, not automatic

For in-scope European financial entities, DORA Article 28 gives this distinction legal weight. Where ICT services support critical or important functions, firms must maintain exit strategies that avoid business disruption, regulatory impairment and harm to service continuity. Exit plans must be comprehensive, documented, sufficiently tested and periodically reviewed. Firms must identify alternatives and plan the secure, integral transfer of services and data or their reintegration in-house.

DORA does not certify a Murex architecture or approve a Google Cloud deployment. Nor does it demand that every workload run actively on several providers. It places responsibility on the financial entity to know how it can leave an arrangement. That is more demanding than knowing that the software vendor supports another destination.

The Bank of England’s work on operational resilience adds a system-level reason for the same discipline: outsourcing and dependence on a small number of third parties can transmit operational disruption across firms. An additional certified provider may reduce concentration in a procurement map. It reduces practical concentration only if important services can be moved or restored within a tolerable period.

Responsibility changes at each operating model

Murex controls the software certification, supported deployment patterns, release packaging and parts of the technical operating model. Google Cloud controls its infrastructure, regions, capacity, network and managed products. A systems integrator may build the landing zone, automate deployment and operate part of the stack. In a managed service, Murex or another provider may assume more day-to-day work.

The institution still owns the business-service decision. It classifies criticality, sets recovery objectives, approves data and identity design, contracts market-data and venue connections, accepts reconciliations and answers to its board and supervisors. Outsourcing tasks does not outsource the meaning of a recovered position.

That boundary should be visible in a responsibility matrix that covers normal operation and exit. Who maintains infrastructure code? Who can export configuration and logs? Who supplies licenses during transition? Who rotates keys, opens network paths and validates market feeds? Who decides that the recovered ledger is fit for trading? Who supports a move after termination, and for how long? A partnership announcement answers none of these customer-specific questions, and should not be expected to.

Cloud choice can increase lock-in before it reduces it

The paradox is that a new supported provider can initially increase dependence. Teams adopt the new environment because its services make delivery faster. Data flows, security controls and monitoring become better integrated with that provider. The implementation is more reliable in ordinary conditions and more expensive to reproduce elsewhere. This can be a rational trade, but it means certification alone is a poor measure of exit cost.

The effect can also run the other way. If Murex maintains portable deployment artifacts, supported database choices, clear component boundaries and common operational evidence, each additional certification may standardise the path. Repeated customer migrations can create a skilled partner market and reusable tooling. The market should look for those receipts rather than treating the partner logos as the outcome.

The most revealing evidence will be scope. A named go-live should say whether it covers development and test, an elastic risk grid, disaster recovery, production or the whole front-to-back-to-risk estate. A recovery claim should state the business service, recovery point, elapsed time and reconciliation result. An exit claim should include data formats, contractual assistance, staffing, interface work and cost—not merely successful infrastructure provisioning.