Settling across traditional and tokenized rails without fragmentation.

Two settlement worlds, one broker

Most brokers still settle client money and collateral entirely through banking and PSP rails: wire transfers, card rails, e-wallet integrations, correspondent banking. That's not changing anytime soon.

But it's no longer the whole picture. A growing number of brokers are being asked to accept, hold, or move value on tokenized rails too — stablecoin deposits, on-chain settlement for certain counterparties, tokenized collateral arrangements. Client demand is pulling brokers toward it whether or not the back office is ready.

The natural response is to bolt on a second system. Keep the existing banking rail as-is, stand up a separate stack for the tokenized side — different ledger, different reconciliation job, different compliance workflow — and connect the two with whatever integration glue is fastest to ship.

That works, for a while. Then it doesn't.

Why parallel silos fail quietly

Two settlement stacks means two sources of truth. Collateral held on one rail isn't visible to the risk engine reasoning about the other. A position hedged with tokenized collateral looks, to the traditional-rail ledger, like it's uncollateralized — because as far as that ledger knows, it is.

Reconciliation doubles. Instead of one process confirming that client money matches obligations, you run two, and then a third process to confirm the first two agree with each other. Every seam between systems is a place where a number can be right in one place and stale in the other.

Client money oversight is the sharpest version of this problem. Regulators and internal risk committees want one answer to "where is client money and what does it back." Two ledgers that don't share a data model can't give that answer without a manual bridge — and a manual bridge is itself a control weakness, not a control.

None of this shows up as an outage. It shows up as slow reconciliation, as edge cases in month-end audits, as risk reports that need a footnote explaining why two numbers that should match don't quite. Fragmentation is a tax you pay continuously, not an event.

The design answer: rail as adapter, not architecture

The alternative is to stop treating the settlement rail as an architectural decision at all. It's a plumbing decision.

One settlement layer. One ledger of record for client money and collateral, regardless of which rail moved the value in or out. One reconciliation process, whose job is unchanged whether it's confirming a wire or confirming a stablecoin transfer — it's still just confirming that the ledger's entries match what actually settled. One audit trail, so "show me everything that touched this account" doesn't require querying two systems and merging the output by hand.

The rail itself becomes an adapter underneath that layer: a module responsible for translating a settlement instruction into whatever a specific rail requires, and translating rail confirmations back into ledger events in the same event format the rest of the system already uses. Adding a new rail means writing a new adapter. It does not mean duplicating the ledger, the reconciliation logic, or the reporting layer.

Ledger of record  <- adapter -  banking / PSP rail
Ledger of record  <- adapter -  stablecoin / tokenized rail
Ledger of record  <- adapter -  [next rail]

Same ledger. Same reconciliation. Same audit trail. The rail is an implementation detail, not a second system to maintain in parallel.

Where this stands today

To be direct about it: this is where settlement infrastructure is heading, not a description of a finished product available off the shelf today. Traditional-rail settlement is mature across the industry. Treating tokenized rails as first-class adapters into a single ledger, rather than a bolted-on side system, is the direction ModernMarkets is building toward on its roadmap. We're not going to describe it as live when it isn't.

What's worth saying plainly is why the direction matters regardless of timeline: fragmentation cost doesn't wait for you to be ready. Brokers are being asked about tokenized settlement now, and the ones improvising a second stack today are the ones who'll have the most unwinding to do later.

What to evaluate in any vendor's settlement story

A few questions cut through the marketing on this topic, from any vendor:

Is there one ledger, or one ledger per rail? If collateral held on different rails lives in different systems, ask how risk and reporting reconcile them today, not eventually.

Does adding a rail mean a new integration or a new architecture? If it's the latter, the fragmentation problem is baked in from day one.

What does an audit trail look like across rails? A single, chronological, queryable record beats two records and a reconciliation spreadsheet, every time.

Ask these questions of your current provider before you ask them of the next one. The answers tell you whether you're building toward one settlement layer or accumulating a second one by accident.