The other page asks where the bank stands today. This one asks what is left, and answers it as a list rather than a promise: nine things between a demonstrator running on one server and a licensed bank on live rails. Three of them block everything else. None of them is a research problem.
Every standard here is set against something a competitor already meets, because a roadmap that invents its own bar is a roadmap that never fails. Tick an item to see the gates move; your ticks stay in this browser and are recorded nowhere.
The gates are sequential, and that is the real content of this page. Live rails cannot be connected to a ledger whose first block says it is a demonstration, and no scheme onboards a bank that has not cleared its own security tasks. An order that looks like caution is usually just the order the dependencies impose.
Grouped by the gate they sit behind. Open any one for why it matters and what in the field already proves the standard is reachable.
Each row is something a named platform already does. That is the point: these are table stakes for a licensed core, not Meridian's own invention, and they are how an assessor will read the gap.
| What is missing | Who already has it | Gate |
|---|
The fastest way to close the nine is to break the four things that make Beit worth licensing. Each of these is running now, and each is easy to lose under delivery pressure.
The Meridian Rail Bylaws are not a document the system is measured against once at authorisation. Twenty-four rules are encoded, cited as published, each carrying the consequence the draft attaches to breach. A sweep runs hourly and on demand, and a failing rule raises an alert.
| How it is settled | Rules | What that covers |
|---|---|---|
| By machine | 21 ᛝ | R1 riba, R3 maysir, R5 the inviolable PAM, R6 no programmable control, R8 real value behind the unit; Article 8's safe-draw rule, marker-to-marker transfers and lifetime ceiling; Article 9's never-on-principal, subsistence floor and structural affordability; Article 3's two-licence principle; Article 11 detection-not-adjudication; Article 13's enforcement ladder — plus the rails themselves. |
| By human review | 3 ᚩ | R2 gharar — can the counterparty understand it? R4 maslahah — does it genuinely benefit, or extract? And Article 2's lawful-authority boundary. These report requires_review and are counted apart from the ones that passed. |
A tick against a rule nobody checked is worse than no tick. That is why the three are separated rather than folded into a single percentage — and why no language model sits behind any of these answers. A compliance control has to say why it fired, give the same answer twice on the same facts, and survive being argued with by a regulator.
It puts no dates on anything. Every item is scoped and none is estimated. Seven of the nine depend on a counterparty — a sponsor bank, a scheme, a programme manager, an acquirer, an auditor, a regulator — and a roadmap that dates work it does not control is a roadmap that is wrong on the first slip.
It does not claim the nine are sufficient. They are what is visible from here. A DFSA reviewer will add to the list, and the submission pack exists partly to find out what.
Competitor facts are claims, not audits. They come from vendor pages and one vendor-written comparison, and are reported as claims. Beit's own figures are read from its codebase and load tests on a single server. Nothing here is an independent assessment.
The bylaws are not in force. Working Draft v0.1 takes binding effect only on adoption by the incorporated entity, which has not happened. What the monitor shows is that the running system already behaves the way the draft says the rails must.