Murex MX.3 upgrades and the move to MXSaaS
Cohash plans and runs Murex MX.3 upgrades and helps banks decide whether to move to MXSaaS, Murex's managed service. We map version changes to your configuration, trace datamart reports, build automated regression comparing trades, valuations, cash flows and accounting entries, and set up masked environments. For MXSaaS, we define what stays with your team, rebuild interfaces for the hosted model and rehearse cut-over.
- 01Estate review
- 02Upgrade or MXSaaS decision
- 03Automated regression
- 04Datamart and interface rework
- 05Rehearse and cut over
The story
Told without the client's name or anything that could identify them.
A bank's capital markets IT group faced another large self-hosted MX.3 upgrade, and the last one had meant weeks of spreadsheet checks across trades and valuations. Nobody could say which datamart reports feeding regulatory returns would change, and keeping infrastructure and upgrade staff for MX.3 was getting harder. We documented the estate with front office, risk, operations and finance owners, then laid a self-hosted upgrade next to a move to MXSaaS. Regression was automated before cut-over, and the move to MXSaaS was rehearsed on a full copy of the book with a written split of what Murex runs and what stays with the bank.
why it was urgentOn 29 September 2025 Murex announced a multi-year AWS collaboration to scale MXSaaS, under which the MX.3 stack is managed by Murex from infrastructure to upgrades. Murex says MXSaaS offers private or public cloud hosting and DevOps-managed upgrades. Banks facing a large self-hosted upgrade now weigh it against moving to the managed service.
- openRegression for each MX.3 upgrade means weeks of spreadsheet checks across trades and valuations.
- recurringDatamart reports feed regulatory returns and nobody knows which ones change in the next version.
- blockedA test environment refresh plus masking takes longer than the testing it's for.
- openInfrastructure and upgrade staffing for MX.3 is hard to keep, and someone has asked about MXSaaS.
The estate, before and after
Before: self-hosted MX.3 with spreadsheet regression
Front office, risk and back office worked in a self-hosted MX.3 that the bank's own team ran and upgraded. Datamart extractions fed regulatory returns, and every upgrade was checked by hand on manually refreshed test copies.
Read the diagram as text
- Front office and risk → MX.3 self-hosted: trade capture
- Operations and finance → MX.3 self-hosted: back office
- MX.3 self-hosted → Datamart extractions: extraction
- Datamart extractions → Regulatory returns: report feeds
- MX.3 self-hosted → General ledger: accounting entries
- MX.3 self-hosted → Downstream interfaces: feeds
- Test environments → Spreadsheet regression: test copies
- Spreadsheet regression → MX.3 self-hosted: manual sign-off
After: MX.3 on MXSaaS with automated regression
On MXSaaS, Murex runs the MX.3 stack and its upgrades. The bank's own team keeps configuration and business testing. The automated regression pack runs on masked copies, and interfaces use whatever connectivity the hosted model supports.
Read the diagram as text
- Front office and risk → MX.3 on MXSaaS: trade capture
- Bank configuration team → MX.3 on MXSaaS: configuration
- MX.3 on MXSaaS → Datamart: extraction
- Datamart → Regulatory returns: traced reports
- MX.3 on MXSaaS → General ledger: accounting entries
- MX.3 on MXSaaS → Rebuilt interfaces: hosted connectivity
- MX.3 on MXSaaS → Masked test environments: refresh
- Masked test environments → Automated regression pack: masked copies
- Automated regression pack → Bank configuration team: explained breaks
How we run it, phase by phase.
5 phases take you from Murex MX.3 (self-hosted) to Current MX.3 or MXSaaS. Each one ends with something you can check before the next starts. As you scroll, the blocks show the estate moving across.
- phase 01
Estate review
We sit down with the front office, risk, operations and finance owners and write it all down: version, configuration, custom workflows, datamart extractions, reports, interfaces, environments.
- phase 02
Upgrade or MXSaaS decision
Set the two routes side by side, self-hosted upgrade and MXSaaS. Hosting constraints, regulatory approvals, interface changes and the tasks left with your team decide between them.
- phase 03
Automated regression
Build version-to-version comparisons of trade attributes, valuations, cash flows, risk figures and accounting entries. Agree the tolerances with risk.
- phase 04
Datamart and interface rework
Trace each datamart report to the version changes that touch it. Rebuild the extractions that break, and move interfaces onto connectivity the target hosting actually supports.
- phase 05
Rehearse and cut over
Rehearse on a full copy of the book, review only the explained breaks, then cut over at a weekend or period close with a rollback plan.
What the client got
What changed for the client once the work was done. Described, not scored: we don't publish client figures.
- result 01
Regression runs as automated comparisons
Trade attributes, valuations, cash flows, risk figures and accounting entries are compared between versions with tolerances agreed with risk, so analysts review only the explained breaks.
- result 02
Every affected datamart report has a traced change
We traced each datamart report back to the version changes and rebuilt the extractions that broke. Anything behind a regulatory return carries a business sign-off.
- result 03
The line between Murex and the bank is written down
The bank's team kept configuration decisions, interfaces and business testing. Murex took the platform and its upgrades. That split was in writing before the contract.
- result 04
Test environments refresh with masking on a set procedure
Refreshing an environment and masking its data now follows a written procedure. Testers aren't sitting around waiting for a copy of the book.
- result 05
Cut-over follows a rehearsed runbook
The runbook has real timings from the rehearsal on a full copy of the book. Cut-over is booked for a weekend or period close, and there's a rollback plan.
Risks we plan for
-
Manual regression filling the window
With spreadsheet regression, only so many test cycles fit before go-live. Automation is usually what turns two cycles into several.
-
Regulatory reports changing quietly
A datamart change can move figures in your regulatory returns, so each affected report needs a traced change and business sign-off.
-
Unclear MXSaaS boundaries
Murex manages the platform, but your team still owns configuration decisions, interfaces and business testing. Write those boundaries down before you sign.
-
Data residency and outsourcing approval
Moving MX.3 onto hosted infrastructure may need a regulator notification or internal outsourcing approval, and that sits on the critical path.
Where AI helps, and where it needs guardrails
Murex's MX.3 product page names no AI features, so we don't plan around vendor AI here. AI agents help on the upgrade work: summarizing regression breaks, tracing datamart SQL and drafting test evidence, with analysts approving every result. Any agent or MCP server touching trade data runs on masked copies under its own identity, with no write access to production books.
forward deployed engineers →What you're left with
We write these for your setup, and they're working documents. Your team should be able to keep things running from them long after we've gone.
- inventory01
Estate inventory of configuration, datamart, reports and interfaces
yours to keep - document02
Self-hosted upgrade versus MXSaaS comparison with responsibilities
yours to keep - tests03
Automated regression pack for trades, valuations and accounting
yours to keep - report04
Datamart report trace against version changes
yours to keep - document05
Environment refresh and masking procedure
yours to keep - runbook06
Cut-over runbook with rehearsal timings
yours to keep
Platforms and services on this move
Certified engineers, wherever you need them.
Some clients want a project team, some want a couple of engineers on theirs. Either works. Onsite, nearshore or offshore, with handovers across time zones that keep things moving.
Onsite
Engineers at your sites in the US
Nearshore
Overlapping hours with US teams
Offshore
Overnight progress on your backlog
All time zones
Coverage handed over across time zones
01Should we upgrade ourselves or move to MXSaaS?
It depends on your hosting and regulatory constraints, how many interfaces need to change and how much in-house MX.3 operations staff you want to keep. We lay both options out against your own estate.
02How long does an MX.3 upgrade take?
That depends on the version gap, how many custom reports and interfaces you have, when environments are free and how long regression takes. Manual regression is usually the longest part, which is why we automate it early.
03Does MXSaaS remove the need for regression testing?
No. Murex runs releases and tests the platform. Your products, configuration and reports still need checking by your own people on every upgrade.
04Can you staff Murex specialists?
Yes, we staff it too. Functional consultants, datamart developers and environment managers for MX.3, working onsite, nearshore or offshore, on contract, contract-to-hire or permanent terms.
Often on the same roadmap
On-premises Active Directory to cloud-first Microsoft Entra ID
We shrink on-premises Active Directory one application at a time, moving groups, users and app authentication to Microsoft Entra ID as each app is ready.
read the case studyAD FS federation to Entra ID authentication
Converting federated domains from AD FS to Entra ID cloud authentication, moving relying parties app by app and retiring the AD FS farm.
read the case study
Apache Airflow 2 to Airflow 3
Upgrading self-managed Apache Airflow 2, now past end of life, to Airflow 3, and fixing removed features, auth and scheduling changes before DAGs move.
read the case studyea7c44ce - 01Murex: MXSaaSmurex.com ↗
- 02Murex: Murex announces strategic multi-year AWS collaboration agreement (29 Sep 2025)murex.com ↗
- 03Murex: MX.3 integrated capital markets solutionmurex.com ↗
Planning this move?
A 30-minute working session with a senior engineer. No slides.
- The platform and the version you're on
- Where you need to get to, and by when
- What's custom: rules, plugins, integrations
- Any audit finding or deadline driving it