Who it’s for

You are either standing up a market that does not exist yet, or replacing a programme that has become the reason nothing changes. In both cases the binding constraint is rarely the matching logic. It is that every new instrument class, every session pattern and every fee schedule turns into a software project with a vendor queue in front of it.

Mehrex is asset-agnostic. Equities, fixed income, derivatives — futures and options — rights and ETFs run on one matching model, and so do the markets that are not securities at all: certificates, warehouse receipts, metal parcels, fractional precious metals. What changes between them is the instrument definition — lot size, tick table, session schedule, settlement arrangement — not the engine. A new market or a new instrument is a configuration change, not a software change.

What that means in operation

• Instruments, tick tables, lot sizes, price bands and trading calendars are maintained in the browser and published as versioned reference-data bundles that take effect without an engine restart.
• Session timetables automate the trading day: exact times, chained transitions that fire when the preceding session completes, or randomized windows for auction uncrossings as an anti-gaming measure. Manual operator commands always take precedence.
• Corporate actions — share increases and decreases, dividend adjustments, reference-price corrections and instrument-metadata updates — are applied safely between sessions, in the end-of-day maintenance window.
• Every market-affecting action carries maker–checker (four-eyes) approval and role-based access, with an audit trail recording who requested it, who approved it and what the system did. That trail is the same sequenced journal that records the trading itself.

You already have the members, the clients and the flow. What you do not have is a venue of your own, and the reason is usually not appetite — it is that a venue has to answer two questions convincingly on day one: whose order is this, and what stops it from being too large.

Mehrex answers both structurally rather than by policy. Identity is taken from the authenticated session and never from the message body, and risk is evaluated before an order can reach the book.

Identity, enforced by the engine

• A three-tier Firm / Node / User hierarchy, with a Role on every User. A Firm is the membership under which business is routed; a Node segments that business, for example by clearing arrangement; a User is a desk, an algorithmic flow or a gateway session, and belongs to exactly one Node.
• End clients are registered against exactly one broker, and every client-account order carries the client’s identity. The engine refuses orders from unknown or inactive users, and client-account orders for a client that is missing, inactive or belongs to another broker — before anything reaches the market.
• Named risk profiles — reusable limit sets assigned per clearing member, firm, client, instrument or market, with a configurable default as fallback. Limit changes apply immediately, without a restart.
• Message throttling per User, enforced at the engine’s entry point rather than in a gateway, so the limit holds uniformly across every connectivity channel.

Two ways in, one set of controls

Member firms can trade from the bundled Client Trading Front-End on day one, with nothing to build and short onboarding, or integrate their own order-management system over the trading API or the FIX 4.4 gateway. Both paths converge on the same ingress and are subject to identical risk controls, so a firm that upgrades from the front-end to an API integration does not move to a different rule set.

An alternative trading venue usually begins as an argument that has to be won: a new asset class, a different market structure, a business case that nobody will fund at full scale until it has traded. The cost of being wrong needs to be small, and the cost of being right must not be a rebuild.

So start with a handful of instruments on a single commodity server. Independent instruments never contend with each other, and order books distribute across servers as the instrument count grows from five to five thousand. The configuration surface is the same at both ends of that range: sessions, tick tables and risk profiles are configuration whether you run five instruments or five thousand, so the pilot is not the thing you later throw away.

Room to differ, and room to grow

• The matching algorithm is pluggable per instrument. Price–time priority is the default; pro-rata and other schemes can be introduced for specific instrument classes without disturbing the rest of the market.
• Sub-millisecond to low-millisecond typical order round-trips on commodity server hardware — no exotic hardware, no specialised network cards, no kernel tuning. The matching path is entirely in memory, with no I/O and no locks on the critical path.
• Latency percentiles are measured continuously and exposed to the operator’s monitoring dashboard, so a claim about performance is something you can check rather than something you have to accept.
• Per-day session overrides and instrument-level schedules make room for illiquid instruments, scheduled call auctions and listings that do not behave like the rest of the book.