The regulatory firewall between execution and the depository ledger
BDR Gate Systems sits between fund execution systems and IIDI’s depository ledger for electronic Bullion Depository Receipts traded on IIBX. It is non-custodial: it holds no metal and lends no money. It provides the controls that make the metal and the money safe to move.
The governing rule. Every figure the system displays traces to a record. Nothing is hardcoded — not a count, not a chart, not a latency number on a monitoring page. Where something cannot be measured, the system says so rather than showing a plausible constant.
What it does
Pre-Trade Gatekeeper
Six ordered checks before any order reaches the exchange: KYC, sanctions and PEP screening, position limit, leverage, capital adequacy, and available funds. Clearance is issued as a signed, single-use token bound to the specific order. The exchange adapter refuses an order without one.
Depository Bridge
Every instruction to the depository carries an idempotency key, so a retry after a lost response cannot place a second lien. Circuit breakers stop a failing dependency from consuming every worker.
Reconciliation
A three-way sweep — our ledger, the depository, the physical bar — after every state change and again end-of-day. Nine break kinds, each with a declared severity, and containment before investigation for the severe ones.
RegTech Audit
Every state change and every refusal is recorded in an append-only, hash-chained, signed log. Verification is an endpoint you run yourself against live data.
Collateral Lending
Working capital against a vaulted receipt: verify unencumbered, value live, place the lien, fund, release on repayment — with continuous mark-to-market and an audited margin process behind it.
What is deliberately not claimed
Delivery-versus-payment here is a saga with compensating transactions, not two-phase commit. 2PC requires a transaction coordinator that every participant obeys, and neither an external depository nor an external bank will enlist in ours. A claim of 2PC across those boundaries does not survive a whiteboard with a depository’s engineers.
What a saga gives instead is eventual atomicity: the outcome is either all applied or all compensated, and a step whose outcome is genuinely unknown — a call that timed out after the remote side may have acted — is marked in doubt, compensated anyway, and escalated to a human rather than guessed.
Verifiable, not asserted
| Claim | How you check it |
|---|---|
| The published permission matrix is the one enforced | One matrix is read by the API, the console and the test suite. The test report is part of the submission. |
| Audit history cannot be edited or forged | GET /api/v1/audit/verify-chain, run against live data with the super-admin credential you are issued, plus the public key to verify exports offline. |
| Illegal state transitions are refused | A PL/pgSQL trigger generated from the same edge list the service layer uses. Apply it and attempt the transition in raw SQL. |
| Settlement failures unwind completely | Failure injection drills that run on every evidence-pack generation, each recording what was injected and what was observed. |
| Latency is measured | Percentiles from real calls, with the measurement boundary stated. No fixed SLA numbers anywhere. |
Status
The platform is built and running: security spine, ledger core, pre-trade gate, DvP settlement, collateral lending, reconciliation, compliance scoring and regulatory reporting. Two external dependencies remain open and are tracked rather than assumed — IIDI’s API specification and the IFSCA filing schemas. Both are isolated behind a single adapter interface, so adopting the real ones is a class change, not a rewrite.