New execution venues rarely fail because the technology didn’t work. They fail because of a protocol that didn’t reflect how the instrument actually trades. A give-up workflow nobody owned until the first break. A surveillance architecture bolted on after launch, discovered to be inadequate during an examination rather than before one.
None of those are engineering problems. They are judgment problems, and judgment in institutional markets is expensive to acquire. It is generally purchased with someone’s career.
That is the reason OMeT was assembled the way it was.
The failure modes are predictable. Avoiding them is not.
Consider four places where a new venue typically breaks.
The protocol doesn’t match the trade. OTC derivatives do not all behave like screen-traded futures. Size moves through negotiation. Liquidity is relationship-mediated before it is ever anonymous. A venue that models its execution protocol on a continuous limit order book, because that is the architecture most readily available, will produce a technically correct system that institutional participants decline to use. Recognizing this in advance requires someone who has worked a desk and knows what a counterparty will and will not put on a screen.
Post-trade is treated as downstream. Execution is the visible part. Clearing submission, allocation, affirmation, and the exception handling around all three are where operational risk actually concentrates. A venue that designs its matching logic first and its post-trade integration second inherits every mismatch between the two. Getting the sequencing right requires operations and systems architecture experience, specifically the kind earned by having been responsible for a break at 6pm on a settlement date.
Surveillance is designed for the platform rather than the examination. A CFTC-regulated Swap Execution Facility operates under an explicit regulatory obligation: monitoring, recordkeeping, communications capture, audit trail. Building those capabilities is not difficult. Building them so that they produce the evidence a regulator will ask for, in the form the regulator expects, is a different exercise. It requires people who have sat on the receiving end of a request.
Risk and credit controls arrive last. Pre-trade credit checking, limit enforcement, and kill-switch architecture are straightforward to specify and easy to under-scope. The cost of under-scoping them does not appear during normal conditions. It appears during the session where conditions are not normal.
Each of these is a known failure mode. Each is documented. And venues continue to walk into them, because knowing that a risk exists is not the same as knowing what it feels like in practice.
Experience as a design constraint
The leadership and engineering teams at OMeT bring over 250 years of combined derivatives experience across trading, sales, brokerage, risk management, and systems architecture.
The number is worth stating precisely because of how easily it is misread. It is not a credential. It does not, by itself, tell you anything useful. What matters is the composition and where it gets applied.
The functions listed above map directly onto the failure modes. Trading and brokerage experience informs protocol design. Risk management experience informs the controls architecture. Systems architecture experience informs how those two are reconciled rather than layered. Sales experience informs what institutional adoption actually requires, which is a different question from what a platform is capable of.
In practice this means design decisions are argued rather than assumed. When a protocol question arises, the people in the conversation have traded the instrument, brokered it, risk-managed it, and built systems for it. The disagreement between those four perspectives is the useful part. It surfaces the operational consequence of a design choice while the choice is still cheap to change.
That is what the experience buys. Not authority, and not a shortcut. A conversation in which the relevant objection gets raised early.
Why this was assembled rather than assembled-around
There is a version of this business that starts with a technology thesis and recruits domain expertise afterward, as validation. That produces a platform with advisors.
OMeT was built the other way. The market problem came first: a specific structural gap in institutional OTC execution that practitioners had observed from inside the market. The organization was then assembled to address it, which meant hiring for the disciplines the problem required rather than the disciplines a technology roadmap required.
The technology decisions follow from the same logic. Matching infrastructure is built on an enterprise-grade GMEX foundation, integrated into global post-trade pipes, because a proven engine connected to the rails institutions already use is a solved problem, and engineering effort is better spent where the problem is not solved.
OMeT is a market-infrastructure company. The distinction is not branding. Infrastructure carries an obligation that a product does not: it has to work under examination, under stress, and under the operational assumptions of institutions that did not build it. Meeting that obligation is a function of who is making the decisions.
Architected by market practitioners. Enterprise-grade institutional discipline.
