Four capabilities that run as one platform. A Unified Order Book that aggregates depth from centralised and decentralised venues. A Market Making Engine that fills and maintains books. A Hedging Engine that offsets exposure across venues. A Market Monitor for surveillance and market data. Underneath them, an execution and data plane that runs in our own cage space in Zurich, Frankfurt and Istanbul, engineered to stay up while markets are open — which is always.
Read this before anything else. We supply the software and the infrastructure. We do not supply capital, we are not your counterparty, and we do not hold your assets. Venue accounts, counterparty relationships and trading capital stay in your name. If you need a vendor who takes principal risk, we are the wrong supplier and we would rather you knew now.
MC Trading Infrastructure is a system we already run. It is sold on its own, and it also ships alongside our exchange product — customers who buy the White Label Crypto Exchange receive it for book-filling and hedging.
On its own, it is bought as a foundation. Banks, investment intermediaries and trading firms use it as the base layer for systems built specifically for them. Arbitrage and high-frequency desks run their own strategies on top of it, because what they need is not a strategy — they have their own — but a clean, normalised, continuously available view of many venues and a reliable way to send orders back to them.
The four capabilities are separable in the commercial conversation and integrated in the engineering. They share one market data path, one venue connectivity layer, one instrument reference model and one set of risk limits. That matters more than it sounds: a market making engine and a hedging engine that hold different opinions about your position is not an integration problem, it is a loss.
Aggregates order books from many centralised and decentralised venues into a single, deeper, higher-volume book, with book-building behaviour that is configurable and adapts to market conditions.
Fills and maintains books from day one, under limits you set.
Offsets exposure across venues as it accumulates.
Market surveillance and market data, for oversight and for research.
Venue connectivity, normalisation, capture, and the order path back out. Distributed across multiple data centres. Designed to run 24/7 without interruption.
It is not a liquidity provision service. It is not a brokerage. It is not a fund. It does not come with a book of counterparties, a credit line, or an inventory of assets. It is engineering: the machinery that a firm with capital, venue accounts and a licence uses to deploy them properly. The full split is set out in what we supply and what stays with you further down this page, and it is worth reading before you read anything else.
Aggregating order books is easy to describe and difficult to do honestly. Anyone can concatenate depth from several venues and print a larger number. The engineering is in making that number mean something.
Every venue is its own dialect. Different message schemas, different snapshot and increment semantics, different sequencing rules, different symbology, different precision for price and quantity, different tick and lot sizes, different fee schedules, different rate limits and different opinions about what a heartbeat is. A per-venue feed handler absorbs that and produces one internal representation.
Normalisation covers instrument reference data as well as prices: mapping venue symbols to one instrument identity, reconciling contract specifications on derivatives, tracking listing and delisting, and keeping the fee schedule that applies to your account tier rather than the public one.
Books are reconstructed from a snapshot plus incremental updates, with sequence numbers checked on every message. A gap in the sequence is treated as a fault, not as noise: the book is marked stale, resynchronised from a fresh snapshot, and excluded from aggregation until it is provably correct again.
The integrity checks matter more than the aggregation logic. Crossed and locked books, prices that move further in one message than the instrument plausibly can, quantities that do not reconcile against the last snapshot, feeds that are silent past their expected update interval — each is detected, each raises an alert, and each can quarantine a venue automatically rather than letting bad data flow into a price that something downstream is about to trade on.
The composed book is not a simple sum. Each contributing level can be adjusted before it is included:
Depth can be truncated, thinned or laddered per instrument. The point of aggregation is a book that behaves the way it looks.
Book-building behaviour is configuration, not a fixed strategy. Spread, displayed size, number of levels, venue weighting and the aggressiveness of refresh can all respond to conditions — realised volatility, spread regime across contributing venues, one-sided pressure, the health of the feed set, time of day. When conditions deteriorate, sensible behaviour is to widen and show less, and the system is built to do that automatically rather than waiting for someone to notice.
A decentralised venue does not have an order book to aggregate. An automated market maker has pool reserves and a price-impact curve, and turning that into ladder levels is a modelling decision that has to account for the cost of the transaction itself, block time, inclusion uncertainty and the slippage tolerance you are willing to sign. Representing that as though it were a resting limit order is how aggregated books end up promising liquidity that cannot be taken. We synthesise DEX depth explicitly and price the settlement cost into it, and we would rather show less depth that fills than more depth that does not.
When an order takes aggregated liquidity, the system slices it across contributing venues and manages the consequences: partial fills, rejections, cancel and replace, and the residual exposure created when one leg fills and another does not. Routing decisions can weigh effective price, available balance, venue health and the cost of rebalancing afterwards. Inter-venue transfer time is a real constraint, not a rounding error, and the routing model is built knowing that.
A new venue opens with an empty book, and an empty book does not attract the traders who would fill it. The Market Making Engine quotes and maintains books from the day you open, and keeps quoting afterwards under limits you set.
Quotes are derived from a reference price constructed off the aggregated view rather than from any single venue — mid or size-weighted, with venue weighting and outlier exclusion, so one thin venue cannot drag the price your engine believes in. Around that reference sit spread and size ladders, configured per instrument, with multiple levels and defined refresh and replace discipline.
Quoting accumulates inventory. Inventory is risk. The engine holds a target inventory per asset and skews its quotes to work back toward it — bidding less aggressively and offering more aggressively when it is long, and the reverse when it is short. Skew is a configured function of position against limit, not a manual intervention. When inventory approaches its limit, quoting on that side stops before the limit is breached rather than after.
Failure behaviour is where a quoting engine is actually judged. Ours is built to fail quiet: when it cannot see the market properly, it stops showing prices. An engine that keeps quoting confidently on stale data will cost you far more than one that stops too readily.
Filling your own venue's book and quoting on external venues are different problems with different risk profiles, and the engine is configured separately for each. Exchange operators generally want the first. Trading firms generally want the second. Some want both, in which case the interaction between them — your own venue's inventory feeding the hedging path on external venues — is precisely the seam that makes an integrated system worth having.
The engine runs in a dry-run mode against live market data, computing every quote and every order it would send without sending any of them. That is how parameters get validated before capital is exposed, and it is the mode we use during onboarding. Nobody should be tuning skew functions in production on day one.
The engine quotes, and it trades against real counterparties, and everything it does is a genuine order that a genuine third party can hit. It does not manufacture prints. We do not build wash trading, self-matching for volume, or any other mechanism whose purpose is to make a venue look busier than it is — not as a feature, not as a configuration option, not on request. Self-match prevention exists to stop it happening by accident.
We are explicit about this because it is a real question in this category, and because a regulated buyer needs to know the answer before procurement rather than after an inspection. If reported volume is the outcome you are buying, we are the wrong supplier.
Running a venue means taking the other side of your customers whether you intended to or not. Market making does the same thing deliberately. The Hedging Engine turns the resulting position into something someone decided, rather than something that happened.
Hedging is driven by policy set per asset and per book: target hedge ratio, thresholds at which hedging is triggered, and a deadband inside which nothing happens. The deadband is the part people underestimate. A system that hedges every small move pays fees and spread continuously and converts a manageable exposure into a certain loss. Policy defines what is worth hedging, how quickly, and at what cost ceiling.
Exposure can be offset with spot at another venue, with perpetual futures, or across a basis position. The engine chooses among the routes available to you by cost, available balance and collateral, margin requirement, funding rate on perpetuals, venue health and the state of any position already open. Where a hedge is large relative to visible depth, it is worked over time rather than sent as one order.
Hedging across venues is a capital and settlement problem as much as a trading problem. Balances are fragmented across venues. Collateral is not fungible between them. Transfers take time and are sometimes suspended. Withdrawal limits apply. Counterparty limits apply, or should. A hedging system that ignores where your capital physically is will produce instructions you cannot execute. Ours treats venue balances, collateral state and transfer latency as inputs to the decision, and raises the problem when the only correct hedge is one you are not funded for.
Hedging with a correlated instrument rather than the identical one leaves basis risk. Hedging a spot position with a perpetual leaves funding cost and the possibility of the basis moving against you. Hedging across venues leaves counterparty exposure at each of them. None of this is eliminated by software. What software can do is measure it, report it, keep it inside limits you set, and never quietly present a partially hedged position as a flat one.
Net exposure by asset and in aggregate. Hedge coverage against policy. Realised hedging cost, separated from trading P&L. Funding paid and received. Mark-to-market by venue. Reconciliation of positions against each venue's own records, continuously, because the moment your internal view and the venue's view disagree, every downstream number is wrong.
If a venue connection drops mid-hedge, the engine does not guess. On reconnection it reconciles working orders and positions against the venue before acting again, and order submission is built so that a retried instruction cannot become two hedges. Double-hedging on reconnect is a classic way to turn an outage into a position, and it is designed out rather than monitored for.
Market Monitor is the surveillance and market data side of the platform: what happened, what it should have been, and what looks wrong.
Everything the data plane sees is written down — book snapshots and increments, trades, funding rates, index and mark prices, and the venue metadata around them. Captured data is what makes a day replayable. It is what an incident review reconstructs from, what a research desk backtests against, and what settles an argument with a customer about the price at a given moment. A trading system that cannot replay yesterday cannot explain yesterday.
Composite reference prices built from multiple venues, with outlier exclusion and defined behaviour when a constituent venue goes dark or diverges. If your venue uses a mark price for valuation, margin or liquidation, the construction of that price and its behaviour under stress is a risk decision, not a display setting, and it is configured deliberately.
Monitoring of trading activity for the behaviours a regulated venue and its supervisor care about: layering and spoofing patterns, wash and self-trading, ramping and momentum ignition, quote stuffing, and activity that only looks abnormal when correlated across venues rather than within one. Alerts are configurable, triaged, assigned and closed with a written record, and the audit trail is exportable — because the point of surveillance is not the alert, it is being able to show a supervisor what you did about it.
The same platform watches itself: venue connectivity state, feed staleness and gap counts, order rejection and cancel rates, round-trip behaviour to each venue, book quality checks, engine state and limit utilisation. Operational monitoring and market surveillance sit together because most of the time the first explains the second.
Everything above depends on one thing: seeing the market accurately and getting orders back out reliably, without stopping. That plane collects data from dozens of exchanges across multiple data centres, processes it, and routes orders back to venues as fast as we can engineer it to.
We do not publish latency or throughput figures for this system, and we would be sceptical of anyone who does. A figure with no hardware specification, no network path, no venue, no instrument, no message rate and no measurement methodology is not a claim you can act on — and every published figure was measured under conditions chosen by the vendor to make it look good. It also has almost no relationship to what you will see, because in a cross-venue system the dominant term is the network path to the venue, not the vendor's internal processing.
What we offer instead is Proof of Performance: we run a live load and stress test with you, on a scenario you define, on defined hardware, and you keep the results. That includes breaking things on purpose while you watch — dropping a venue feed, failing a site, saturating a path — because the interesting question is not what the system does when everything works.
Request a Proof of Performance session
We operate our own data-centre cage space and systems in Zurich, Frankfurt and Istanbul. That is not a hosting region on someone else's console; it is our own space, our own hardware and our own network, which is what makes the layout below a design decision rather than a configuration setting.
Proximity is chosen against where a venue actually terminates its connectivity, not where its company is registered. Frankfurt is one of the densest interconnection points in Europe and does a great deal of work for European and global venue reachability; Zurich carries the Swiss footprint and the second independent site; Istanbul extends the reach eastward and gives a third failure domain that does not share a power grid, a metro fibre map or a jurisdiction with the other two. More about Cloud & Infrastructure.
Redundancy is only worth what its correlation allows. The plane is built so that the things that fail together are known:
Markets do not have a maintenance window, so the system is not designed around one. Upgrades roll through instances rather than stopping the platform. State is rebuilt from captured data and from venue reconciliation on start-up rather than assumed. Queues on the market data path are bounded, and when a downstream consumer is slower than the market, the policy for what happens is explicit and observable instead of being whatever the memory allocator decides. Clocks are disciplined across sites, so events from different venues can be ordered and compared and so a latency investigation has a common time base to work from.
The plane connects to your venue accounts using API credentials that you issue and can revoke: scoped to trading, with withdrawal permission disabled, restricted to our egress addresses. We do not need, want or ask for withdrawal rights on your venue accounts, and any vendor in this category who does should be asked why. Credential handling, rotation and separation between environments are part of the deployment design and are written down in the runbooks you receive.
We run the platform in our own cage space and operate it, and you consume it. Monitoring, upgrades, venue connector maintenance, incident response and capacity are ours. Of the three models this is the least work for you to start with, and it is the one most exchange operators take, because it does not require them to build a trading systems team.
A dedicated deployment, on hardware and network segments that are yours alone, in one or more of our locations. Chosen where isolation is a regulatory or internal-audit requirement, or where the trading model justifies dedicated resource. Data residency is decided by which of our sites it runs in, and that is a decision you make explicitly.
The platform can be deployed in your own facility or your own cage space, so that the data plane sits next to the systems that consume it. This is the model arbitrage and high-frequency desks generally want: the aggregated view and the order path in the same place as their own processes, rather than a round trip across the public internet to reach their own market data.
Hybrid arrangements are normal — collection and normalisation operated by us, strategy and execution decisions running in your environment, or the reverse.
Your side of the boundary is usually an existing order management or risk system, and the useful question is not which protocol we prefer but what yours already speaks. We treat that as a design conversation at the start of the engagement rather than a fixed menu, and we build to it. Bring your OMS, your risk system, your reconciliation process and your reporting requirements to the first technical session and we will tell you exactly what integrating them involves — including any part of it we think is a bad idea.
What is consistent across integrations: market data and order flow are separate paths; every order carries a client-supplied identifier so that a retry cannot become a second order; every state change is observable; and everything the platform does is reconcilable against the venue's own record rather than only against ours.
Staging environments run against replayed or live-mirrored market data, and the engines run in shadow mode before anything is armed. Onboarding is a sequence — connectivity, then data validation, then shadow, then small live limits, then production limits — and each step has a defined exit condition. We would rather add two weeks here than explain a position later.
Adding digital-asset execution to a supervised business, where the infrastructure has to survive internal audit, a technology risk review and, eventually, a supervisory conversation. The attraction is a system whose behaviour, limits, audit trail and failure modes can be documented and evidenced, and a supplier who will sit in the review and answer the questions rather than send a brochure.
Firms executing for clients that need one normalised view of fragmented venues, a defensible execution path and records that stand up afterwards. Fee-adjusted, executability-aware aggregation matters here more than anywhere: the difference between the price on a screen and the price a client actually achieves is the thing you will be asked to justify.
Desks that want the execution and data plane rather than a retail front end. Market data capture, normalisation, venue connectivity, order management, position and risk state — the unglamorous layer that takes a long time to build well and that nobody gets a bonus for. Your quants build strategy on top; we maintain the connectors when a venue changes its API on a Friday.
Clients in this group already have their systems, and what they buy is the plane underneath: a clean cross-venue view, deterministic data handling, a documented order path, and physical placement in facilities they can co-locate with. They run their own strategies on our infrastructure. We do not see the strategy, we do not want to, and the platform is deployed so that we do not need to.
Venues that need a book on day one, hedging of the exposure the venue takes on, surveillance for their supervisor, and market data for their own products. Customers of our White Label Crypto Exchange receive this system for book-filling and hedging as part of the platform. It is also sold to operators running someone else's exchange software.
This is the section to read twice. In this category the boundary is often left vague, and vagueness here is not a commercial convenience — it is a compliance problem for a regulated buyer, because "our vendor provides market making" is a sentence that raises questions you will have to answer precisely.
We are an engineering company. We are not a broker, not a dealer, not a liquidity provider, not a counterparty and not a custodian. We take no principal risk in your trading, we have no discretion over your capital, and we earn nothing from your order flow. Where we operate the platform for you, we operate it to your instructions, within limits you set, with a record of every parameter change and who made it.
If a supplier tells you they will "provide liquidity" for your venue, ask them three questions: whose capital, whose venue accounts, and whose regulatory permission. The answers determine what you are actually buying, and whether you are permitted to buy it.
Most sales of this platform to banks, investment intermediaries and trading firms are not sales of the product as configured. They are sales of a foundation, with a system built on it for that firm. The commercial reason we can do that is the same as the engineering reason: we wrote it, so extending it is scheduled work rather than a feature request in someone else's backlog.
What that work typically is:
Delivery follows the same sequence as the rest of our work: discovery, architecture, engineering, hardening, then operate — described in full on the Blockchain & FinTech page. Discovery produces a written scope, the constraints your regulatory position imposes, and a plain list of anything we think is a bad idea. That last item is not a formality. If there is no good version of what you are asking for, you will hear it in the first fortnight rather than in month six.
Bespoke work of this kind is decided by who does it. The core team has worked together since the 1990s — more than thirty years in computing, programming, networking and large-scale systems — and we have been building and operating crypto exchange infrastructure since 2017. It is a small senior team, and the engineers who designed the platform are the engineers who extend it. Other companies consult us on problems that require this kind of engineering. We do not publish client names: contact us and we will share relevant references under NDA.
No. We provide the software and the infrastructure, and we will operate them for you. The capital is yours, the venue accounts are yours, the counterparty relationships are yours and the positions are yours. We are not a broker, a dealer, a liquidity provider, a counterparty or a custodian, and we take no principal risk in your trading. This distinction matters commercially and it matters legally: "our vendor provides market making" is a claim your compliance function will have to unpack, and we would rather it was accurate from the start. What we provide is the machinery that turns your capital, your venue accounts and your risk appetite into a book that is quoted, maintained and hedged.
Yours, in every case. You open the accounts, you complete each venue's onboarding, and you issue the API credentials. Those credentials are scoped to trading with withdrawal permission disabled and restricted to our egress addresses, and you can revoke them at any moment without asking us. We never hold your assets, and we do not need withdrawal rights to do any part of this job. If a supplier in this category asks for withdrawal permission on your exchange accounts, that is worth a long conversation before you grant it.
That is the correct question, and it is why so much of this page is about executability rather than aggregation. Concatenating venue books produces a large number that fills badly. What we compose is fee-adjusted to your actual tier, sized to the balance and collateral you genuinely hold at each venue, weighted down as a venue's feed or rejection rate degrades, filtered so your own quotes are not counted back into your own book, and — for decentralised venues — derived from the pool's price-impact curve with settlement cost priced in rather than presented as resting limit orders. The result is often a smaller displayed book than a naive aggregation would produce. It is the one that fills.
Because they are unverifiable and, in a cross-venue system, largely beside the point. A figure without hardware, network path, venue, instrument, message rate and measurement method cannot be compared with anything, and every published figure was produced under conditions chosen to flatter it. The dominant term in real cross-venue execution is the path to the venue, which no vendor's internal benchmark tells you about. So we do the opposite: Proof of Performance is a scheduled session in which we run live load and stress tests with you, on the scenario you define, on defined hardware, including deliberate failures — a venue feed dropped, a site lost, a path saturated — while you watch. You keep the measurements and the configuration that produced them, so you can hold anything else you are evaluating to the same standard.
Detection first: sequence gaps, silence past the expected update interval, crossed or locked books, implausible price movement and rising rejection rates each raise an alert and can quarantine the venue automatically. A quarantined venue stops contributing to the composed book and stops being a hedging route, and the engines re-evaluate against the venues that remain rather than continuing on a stale picture. Position and order state are reconciled against the venue before trading resumes, and order submission is built so a retry cannot become a duplicate. API changes are our maintenance obligation, not yours — connector maintenance is part of the service, and it is one of the main reasons firms buy this layer instead of building it.
Yes, and for arbitrage and high-frequency clients that is the normal arrangement. You get the plane — normalised cross-venue data, capture and replay, venue connectivity, order management, position and risk state — and your strategies sit on top of it, either in your own environment with the platform deployed alongside, or hosted inside the platform's risk framework so that limits, kill switches and reconciliation apply to them too. Where you deploy in your own facility or co-locate with our infrastructure, we do not see your models and the deployment is designed so that we do not need to.
No, and we will not build it. Every order the engine sends is a genuine order that a genuine third party can execute against, and self-match prevention exists to stop accidental self-trading. We do not implement wash trading, print manufacturing or volume simulation as a feature, a configuration option or a favour. If inflated volume is the outcome you are buying, we are the wrong supplier, and we would rather lose the deal than have that conversation with an inspector later. The Market Monitor exists partly to detect exactly these behaviours in your own market.
No, and yes. MC Trading Infrastructure is an independent system, sold on its own to banks, investment intermediaries and trading firms, and it is also included for book-filling and hedging when a customer buys the White Label Crypto Exchange. It runs as a managed instance in our facilities, as a dedicated instance, or deployed inside your own environment or cage space where you want the data plane next to your systems. Which of those is right is usually decided by your regulatory position and where your strategies run, and it is one of the first things we work out together.
The useful first conversation is not a demonstration. It is your venue list, your instruments, where your capital sits, what your OMS speaks, what your regulatory position permits and what your risk function will insist on. From that we can tell you what this would actually look like for you, what we would build on top, and what we would not take on.
Then make us prove it. Proof of Performance runs on your scenario, on defined hardware, with failures we cause on purpose while you watch — and you keep the results.
You can also ask for the live exchange demo to see the venue product this system ships alongside. What to come back for is what we supply, and what stays with you — where the boundary between the two is set out in full.
We reply to enquiries within 2 business days.
