Bridge Intelligence needed a payment rail for tokenized assets that regulators would trust and institutions would actually use. We built it together as a joint build partnership. It is live in production today.
The brief
Bridge Intelligence set out to connect banks, fintechs, and licensed VASPs on a single rail for tokenized assets in an emerging-markets corridor. The requirement was blunt: settlement infrastructure that a regulator could supervise natively — not a blockchain with a compliance layer bolted on afterward.
That framing shaped everything. The rail had to run on a permissioned DLT, every participant had to operate inside one trust boundary, and compliance had to be a structural property of the ledger, not a downstream reporting job.
The challenge
Most tokenization projects fail at the same seam: the gap between what the chain records and what the regulator needs to see. Public-chain designs push compliance to the edges — off-chain screening, after-the-fact reporting, manual reconciliation. Regulators are asked to trust exports. They usually don't, and the project stalls in pilot.
The harder problem is institutional heterogeneity. Banks, fintechs, and VASPs have different licenses, different obligations, and different risk appetites. Putting them on one rail means the trust model has to hold for the most regulated participant, not the least. And the design had to survive scrutiny on both sides of the Atlantic — MiCA-era expectations in Europe, an evolving US framework under the GENIUS Act.
There was no off-the-shelf answer. This had to be engineered.
What we built
Binari led architecture and built the core of the system:
- Core ledger on a permissioned DLT. Membership is licensed and verified; the trust boundary is defined at admission, not per transaction.
- Compliance-by-construction. Attribution and sanctions hooks execute on every transfer. A transaction that cannot clear compliance checks does not settle. There is no compliant-mode toggle — the rail has no other mode.
- Regulator as participant. The supervisor is designed into the network, not given a dashboard on top of it. Oversight reads the same ledger the participants write to.
- Rail services — the transfer, settlement, and participant-facing services that make the ledger usable by banks, fintechs, and VASPs with very different integration surfaces.
- Observability across the stack, so operators and participants can reason about the rail's behavior in production, not just its state.
The design principle throughout: if compliance is enforced at the point of transfer, everything downstream — reporting, audit, supervision — gets simpler. We've written up the architecture reasoning in designing a regulated payment rail.
How we worked
This was a joint build, not a vendor engagement. Bridge Intelligence brought the market, the corridor relationships, and the regulatory ground truth. Binari brought the engineering: architecture, core ledger, rail services, observability.
We ran it the way we run every engagement. A fixed-fee discovery sprint first, to pressure-test the trust model before committing to the build. Weekly demos against the real system — working software, not slideware. Full IP assignment from day one. Development and staging ran on our managed on-premise infrastructure, containerized from day one, keeping cloud spend near zero until the system was ready to promote to production.
A small senior team, accelerated by Aura OS — our internal delivery pipelines and evaluation harnesses — carried the build from architecture to production.
The outcome
The rail is live in production. Banks, fintechs, and licensed VASPs transact on tokenized assets inside one trust boundary. Every transfer carries attribution and clears sanctions screening before it settles. The regulator supervises from inside the network.
That last point is the one we'd underline. Regulated financial infrastructure that ships — and stays live — is rare. It shipped because compliance was an architectural decision made on day one, not a workstream added in month six.
If you're building a rail
Two things we'd tell anyone starting this journey:
- Design the regulator in. If supervision is an afterthought, your production launch is a negotiation. If the regulator is a participant, launch is a milestone.
- Enforce compliance at transfer time. Screening at the edges creates reconciliation work forever. Screening in the settlement path creates none.
And one honest caveat: if your asset flows work fine on existing rails and no regulatory constraint forces a new trust model, you may not need a permissioned DLT at all. We'll tell you that in the first week of discovery. See tokenization rails for how we scope these engagements.
Building settlement infrastructure for tokenized assets? Talk to us — we reply within one business day.