Three phases with named people on both sides, a written market-model specification before any commercial commitment, and a testing programme that your member firms complete alongside you.
Market infrastructure has a reputation for multi-year programmes priced in the tens of millions, where the venue ends up adapting its market to the software. Three things are deliberately different here.
Mehrex is licensed per venue, and the platform arrives complete — matching engine, Control Panel, client front-end, risk, clearing and market data. There is no separate integration programme to buy before the venue can be operated and traded.
New instruments, sessions, risk profiles and asset classes are configuration changes made in the Control Panel — versioned, approved under four-eyes control and applied without downtime. The work that usually consumes the schedule is not on the critical path.
The market model is described in your terms first and mapped onto configuration second. Where something genuinely is not standard, we say so in the workshop and price it separately, rather than discovering it in testing.
Each phase ends in something you can hold: a specification, a configured environment, a live market with a support arrangement behind it.
We map your instruments, sessions, tick tables, risk regime and settlement arrangements onto the platform’s configuration — and tell you plainly what is standard and what is not.
The workshop is run with your market operations, compliance and technology people in the same room, and it produces a document rather than a slide deck. Where your market model needs something the platform does not do today, you hear it at that point — not after a contract is signed.
A structured customer-testing programme for you and your members: conformance against the trading and market-data interfaces, dress rehearsals, and release notes for every change.
Configuration is done in the Market Control Panel, the same tool your operations team will use in production. There is no separate implementation language and no bespoke build to maintain afterwards, and every change to the test environment arrives with release notes.
Named technical account management for functional queries, a separate channel for live incidents, and any production incident reproducible exactly from the journal.
Go-live is a scheduled event with a rehearsed fallback position. After it, functional questions and live incidents travel on separate channels, so a question about tick tables never queues behind an outage.
A venue is not live when the engine is running. It is live when member firms can trade on it and their back offices can book the results. The customer-testing programme therefore runs on both sides of the membership boundary.
Each firm proves its integration against the interfaces it will use before it is admitted: new order, cancel, cancel/replace and mass cancel against the trading interface; snapshot, incremental refresh and instrument definitions against market data. Firms on the bundled front-end have nothing to build, but still work through the market’s session and order rules.
Full trading days in the test environment, covering the opening auction, the closing auction and volatility auctions — including randomized transition windows, so members meet the behaviour they will actually see in production rather than a tidy fixed schedule.
Every change to a test or production environment is accompanied by release notes. Firms integrating over the trading API or the FIX 4.4 gateway are told what changed before it changes, not after something behaves differently.
The platform is delivered with structured documentation rather than a knowledge-transfer workshop and a wiki. Each guide has a reference, an intended audience and a version history.
| Reference | Document | Audience | Availability |
|---|---|---|---|
| MEX-ENG-DEL-002 | Guide to the Mehrex Trading System | Evaluators, market operations, compliance | Available on request |
| MEX-OPS-DEL-001 | Guide to Market Configuration and Management | Market operations | Provided during engagement |
| MEX-MKD-DEL-001 | Guide to Market Data Services | Market-data consumers, vendors | Provided during engagement |
| MEX-API-DEL-001 | Guide to Trading Services and API Reference | Member firms, integrators | Provided during engagement |
| MEX-CON-DEL-001 | Guide to Connectivity and Customer Testing | Member firms, integrators | Provided during engagement |
Your instruments, tick tables, calendars, session timetables and risk profiles, loaded and running — not an empty installation with a configuration guide next to it. Members connect to it for conformance and rehearsals, and your operations team learns the Control Panel on it before it matters.
A named point of contact for functional queries and technical advice, who knows your configuration — not a queue. The same arrangement continues after go-live, alongside a separate channel for live incidents.
Support for a trading venue is usually a negotiation over what probably happened. Here it is not, because operator actions travel the same sequenced, journaled path as orders: any production incident can be reproduced exactly from the journal, with the same trades, the same book states and the same sequence numbers.
How a session type behaves, how to configure a corporate action, what a reject reason means, how a member should model something in the API. Handled by technical account management, not by an incident queue.
Live service only, with agreed response targets, an owner for the duration of the incident, and a post-incident report that cites the journal rather than reconstructing events from logs and recollection.
On any internal inconsistency the affected market segment halts rather than emit an incorrect trade. That makes the worst realistic outcome a stopped market with an exact record of why — fail-stop, never fail-wrong.
Most of the risk in a venue launch sits on your side of the boundary, and it is better said plainly at the start.
Someone with the authority to settle how the market actually works: which sessions, which order types and validity combinations, what the tick table is, what happens at the close. Configuration is quick. Unresolved disagreement about the model is not, and it is the most common cause of delay we see.
Mehrex clears and nets; it does not settle. We need the people who operate your CSD, registry or banking integration early enough to agree the shape of the netting output and trade-capture records they will consume, rather than discovering it during rehearsals.
A firm that has not completed conformance cannot be admitted. Firms using the bundled front-end have very little to do; firms integrating an order-management system need developer time booked in advance, and securing that time is yours to do, not ours.
None of this is unusual and none of it is billable. It is simply the part of the timetable we cannot compress for you.
A live demonstration runs about an hour: the order book, the Control Panel, an auction uncrossing, and a replay of the journal that produced it.