MX.3 upgrades where the regression differences get explained.
We help banks upgrade Murex MX.3, plan moves to MXSaaS, rebuild the datamart and interface layer around it, and staff the MX.3 specialists that are hard to find on short notice.
Cohash works on Murex MX.3, the integrated capital markets platform used for trading, risk, processing and finance.
We plan and test MX.3 upgrades, prepare moves to MXSaaS, Murex's vendor-managed SaaS that Murex is building out with AWS, document and rebuild datamart extractions and interfaces, and supply MX.3 functional and technical specialists on contract or permanent terms.
you probably need this if
The last MX.3 upgrade overran because nobody could explain thousands of regression differences.
Datamart reports go to regulators and their lineage lives in one person's head.
The board wants a view on MXSaaS. Nobody has an inventory of the bank's customizations.
29 Sep 2025AWS collaboration for MXSaaS Multi-year global agreement with AWS to expand MXSaaS. source ↗
09 Jul 2026Murex AI Research Research program on AI in capital markets, feeding MX.3 development. source ↗
23 Sep 2026Google Cloud partnership Murex and Google Cloud announced a strategic partnership for capital markets. source ↗
today · Oct 22, 2026
the story · murex mx.3 estate
From the first call to a setup your own team can run.
Here's what usually prompts a call about your Murex MX.3 estate, what we do about it and in which order, and where you end up.
01 · where it hurts02 · what we change03 · how it runs04 · where you end up
incident board · murex mx.3 estate3 open
openThe last MX.3 upgrade overran because nobody could explain thousands of regression differences.
recurringDatamart reports go to regulators and their lineage lives in one person's head.
blockedThe board wants a view on MXSaaS. Nobody has an inventory of the bank's customizations.
exposure
MX.3 upgrade planning and testingMXSaaS readinessDatamart and reportingInterfaces and integrationSpecialist staffing
CAL
startrehearsehandover
Estate inventory
Regression baseline
Upgrade or MXSaaS plan
Cut-over and handover
we are here
ready to hand over
Sign-off is based on differences that have been explained.
Leadership decides on MXSaaS with a counted list of changes and testing effort.
Estate inventory of modules, environments, interfaces and datamart extractions
Regression baseline with differences grouped by cause
chapter 01 · where it hurts
Why teams reach out
The last MX.3 upgrade overran because nobody could explain thousands of regression differences.
Datamart reports go to regulators and their lineage lives in one person's head.
The board wants a view on MXSaaS. Nobody has an inventory of the bank's customizations.
chapter 02 · what we change
How we solve it
MX.3 upgrade planning and testing
MXSaaS readiness
Datamart and reporting
Interfaces and integration
Specialist staffing
chapter 03 · how it runs
Our approach
Estate inventory
Regression baseline
Upgrade or MXSaaS plan
Cut-over and handover
chapter 04 · where you end up
What changes
Sign-off is based on differences that have been explained.
Leadership decides on MXSaaS with a counted list of changes and testing effort.
Estate inventory of modules, environments, interfaces and datamart extractions
Regression baseline with differences grouped by cause
what we do
Our Murex MX.3 work
5 kinds of Murex MX.3 work, each run by engineers who have done it on live tenants.
Upgrade plans built around your regression pack, with differences grouped by cause (static data, curves, rounding, configuration) so specialists look at real breaks first.
An inventory of customizations, interfaces and datamart reports that changes when Murex runs the platform and upgrades are DevOps-managed.
Datamart extraction definitions documented and lineage drawn from MX.3 tables to risk, finance and regulatory outputs.
Feeds to market data, confirmations, payments and the general ledger rebuilt on a supported pattern, with owners and failure handling per feed.
MX.3 functional consultants, datamart developers, environment engineers and testers, onsite in the US or from nearshore and offshore teams across time zones.
capability 01 / 05in production
CAL
MX.3 upgrade planning and testing
Upgrade plans built around your regression pack, with differences grouped by cause (static data, curves, rounding, configuration) so specialists look at real breaks first.
MX.3 functional consultants, datamart developers, environment engineers and testers, onsite in the US or from nearshore and offshore teams across time zones.
We pieced these together from Murex MX.3 situations that come up a lot. They're patterns. You won't find a specific client in them.
case file 01
An MX.3 upgrade with thousands of unexplained regression differences
composite · not a client story
Beforethe situation
The previous MX.3 upgrade produced thousands of regression differences, and the team signed off after weeks of manual review. The next upgrade is planned and the same specialists are already overloaded.
What we dothe work
We rerun the baseline on the current version, then group the post-upgrade differences by cause: static data, curve setup, rounding or a real configuration change. Specialists look at the real breaks first, and we keep the expected-difference rules for next time.
Afterwhere you end up
Sign-off is based on differences that have been explained. The next upgrade starts with a baseline and rule set you can reuse.
case file 02
MXSaaS on the agenda and no list of what's custom
composite · not a client story
Beforethe situation
Leadership wants a recommendation on MXSaaS. The bank runs self-hosted MX.3 with local scripts, custom datamart extractions and interfaces that read the database directly.
What we dothe work
We inventory every customization, extraction and interface, then mark which fit a vendor-managed platform and which need rework. The cost of that rework and testing goes into our recommendation.
Afterwhere you end up
Leadership decides on MXSaaS with a counted list of changes and testing effort.
We don't start a step until the last one has produced something you can check.
step 01
Estate inventory
We document versions, modules, environments, interfaces and datamart extractions, with an owner for each.
step 02
Regression baseline
We run regression on the current version to set a baseline. After the upgrade, the differences are grouped by cause.
step 03
Upgrade or MXSaaS plan
From the inventory and the baseline we write the upgrade or MXSaaS plan: which customizations stay, which interfaces change and how long testing takes.
step 04
Cut-over and handover
We're there for the cut-over weekend. Afterwards you keep the documented datamart lineage, the interface runbooks and the regression pack.
ai on murex mx.3
Where AI fits on Murex MX.3, and where it needs guardrails.
Murex has no named AI features for MX.3 on its public site. It did launch Murex AI Research on 9 July 2026, to study AI in capital markets and inform MX.3's development. Until something ships, AI works around MX.3: explaining datamart reports, triaging regression results, documenting configuration.
AI agentasks for data or an action
Scoped identityonly the access it needs
MCP serverthe one door into the platform
Logged, approveda person signs off on writes
Murex MX.3does the work
Murex doesn't currently publish an official MCP server, so agents should work on read-only datamart copies or reporting extracts with a dedicated service account, never write to trading or settlement flows, and log every query. Any action in MX.3 itself stays with a person.
Murex AI Research
It's a research program run with universities. It covers modelling, pricing, risk, operations, post-trade and finance, and what it finds feeds MX.3's roadmap. We follow what it publishes. Then we ask your Murex account team what reaches the product and when.
Datamart and report lineage
AI can read datamart extraction definitions and reports and draft lineage from MX.3 tables to regulatory and risk outputs. Before anyone relies on it during an upgrade, we check each lineage against the actual extraction.
Regression triage for upgrades
An upgrade regression pack throws up thousands of differences. We have AI group them by likely cause, such as static data, curves or rounding. Then specialists go straight to the real breaks.
Configuration documentation
Workflow, static data and pricing setups tend to live in a few people's heads. Export the configuration and AI can draft documentation from that. A functional consultant corrects it and approves it.
Where MX.3 sits between the trading desk and the ledger
Trades and market data come into MX.3 to be valued, risked and processed. Datamart extractions feed risk, finance and regulatory reporting, and interfaces send settlements and accounting entries out.
These are working documents, written against your configuration, so your team can run them without us.
inventory01
Estate inventory of modules, environments, interfaces and datamart extractions
yours to keep
tests02
Regression baseline with differences grouped by cause
yours to keep
tests03
Upgrade or MXSaaS plan with testing durations from real runs
yours to keep
document04
Datamart lineage from MX.3 tables to regulatory and finance outputs
yours to keep
runbook05
Interface runbooks with owner and failure handling per feed
yours to keep
talent and delivery · murex mx.3
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
24-hour coverage · US Central time
OnsiteUS business hours
Nearshoreoverlapping US hours
Offshoreovernight progress
Combinedhandover, not hand-off
00:0006:0012:0018:0000:00
roles we staff
MX.3 front office functional consultant
MX.3 back office and processing consultant
MX.3 datamart developer
MX.3 environment and DevOps engineer
MX.3 regression test analyst
due diligence · murex mx.3
Questions to ask any partner, including us.
Put these to anyone bidding on your Murex MX.3 work. The ones who've done it answer differently from the ones who've read about it.
Q1
How will you explain regression differences, and who signs them off?
Upgrades stall on differences nobody can explain. Group them by cause, name an owner for each group, and sign-off gets a lot shorter.
Q2
Which of our datamart extractions feed regulatory reports?
A broken extraction after an upgrade becomes a reporting problem. Lineage needs mapping before the window.
Q3
What do we still own if we move to MXSaaS?
Murex runs the platform and the upgrades. Configuration decisions, testing and interfaces stay with the bank, and somebody there has to own them.
Q4
How do you vet MX.3 specialists without a public certification?
Murex trains clients through its Center of Expertise but publishes no certification, so screening has to test module and version experience directly.
Q5
Which interfaces read the MX.3 database directly?
Direct database reads are the first thing to break on an upgrade or a move to SaaS.
01How long does an MX.3 upgrade take?
It depends on how far apart the versions are, how much custom configuration and datamart content you run and how long a full regression cycle takes on your data. We time a regression cycle early and plan the rest around it.
02What changes if we move to MXSaaS?
Murex runs the platform on private or public cloud and handles upgrades through DevOps. Your team still owns configuration decisions, testing, interfaces and the datamart reports other people rely on, and all of that has to fit Murex's release rhythm.
03Do your consultants hold a Murex certification?
Murex doesn't publish a public certification program. It trains client staff through the Murex Center of Expertise. We screen MX.3 specialists by the modules and versions they've worked on and test that in interviews.
04Can you run MX.3 regression testing for us?
Yes. We build or extend the regression pack and run it in your test environments. Your specialists sign off once we've explained the differences.
05Do you also work on Calypso?
Yes. Some banks run both, and we have a separate Nasdaq Calypso page.
services
Related services
Projects on Murex MX.3 usually end up touching one of these, so they're worth a look.
