VERITAS FLEET
The bank's Rust backend — shown programme by programme, with live state read, never claimed.
Illustrated rollout concept: archive, loopback core, gated rollout — the page below reads programme state live from the fleet registry, and this drawing invents no deployment or certification.
The Veritas Bank System organisation carries 155 numbered Rust backend programmes (000–154) plus an extended card series (155–159) and named staff-console programmes. Each numbered programme is a separate repository with its own README, topics and one clearly bounded banking capability: the double-entry ledger, rail adapters, compliance screening, custody, tokenized instruments, regulatory registries, and the card stack from vault to settlement.
> fleet registry · /api/fleet/status · read at request time
contacting registry…
Live deployments — the programmes behind the registry
One rectangle per registry-listed backend deployment. Each card states what the programme is for and its functions; select a rectangle to see its declared health endpoints probed live — HTTP status and latency at request time — and to fire a fresh re-check. Nothing here is asserted without a passing probe.
How the backend is organised — animated category map
Ten rows, one per category: what sits inside it, and the control/data boundary that keeps it honest. Select any row (mouse or keyboard) to read it enlarged, with that category's programmes listed.
Full programme inventory
176 entries: 155 numbered backend programmes (000–154), 5 extended card programmes (155–159), 16 named console/customer programmes. Filter across every column; each category repeats its own animated diagram.
Verified capability evidence
Executed test suites from the extended card stack — the programmes whose behaviour was exercised end to end, as recorded in their repositories. This list states only what was run and passed; it claims nothing beyond it.
| Repository | Test executed | Result |
|---|
regulatory posture and remaining work — engineering facts and framework mapping, no certification claimed
No formal certification is held or claimed — SOC 2, ISO 27001, PCI DSS or DORA attestation all require external audits and operating evidence that does not exist yet. The platform is architected along the major frameworks and runs a set of enforced technical controls that are verifiable in the repositories today.
cargo audit · cargo deny · CI gates — dependency vulnerability scanning and license governance on every workspace; fmt/clippy/test/audit/deny gates on the first-wave workspaces; SHA256SUMS manifests and pre-push leak guards across all 151 repositories; hash-chained audit anchors (013) over the ledger entry stream; 2,141 test functions in 797 files at archive time, zero repositories without tests.
Each framework certifies operations over time: SOC 2 needs a CPA firm plus an observation window from a running system; ISO 27001 needs a documented ISMS with audit cycles; DORA is assessed by supervisors of live entities; PCI DSS needs a QSA assessment of a live cardholder-data environment. The control mapping is the head start — not the certificate.
Keep evidence-producing controls running (audit anchors, access logs, reconciliation) so an audit window has material to examine; stand up the demonstrable bank core (ledger 001 + core banking 002 + identity 006) behind the access gateway; complete the standing debt items in the fleet plan before any regulated deployment is attempted.
How the programme map covers each framework, from the platform's compliance-status record:
The minimal core (001 ledger, 002 core banking, 006 identity) runs loopback behind the access gateway; the live-state strip on the Backend tab reports which units are probed as running right now.
Gated on per-workspace integrity checks (`sha256sum -c SHA256SUMS.txt` green), deliberate write-gate configuration, replicated Postgres and a completed restore drill — per the 150-programme deployment plan.
SOC 2 / ISO 27001 / PCI DSS each require external auditors and running-system evidence; sequenced only after the demo window produces operating evidence.
Fleet badges everywhere read the registry instead of asserting health — the pattern this page applies to the whole backend map.
outline-level engineering and funding text — planned work is labelled, never claimed as shipped or committed
Rust 2024 backend engineers across the five load-bearing areas: ledger & core banking (001/002/059/104), payments & rails (007–011/018–023), compliance & fin-crime (004/005/027/070), custody & digital assets (030–043), and the card stack (152–159). Each numbered programme is small and bounded — a focused team can own a category, not the whole fleet.
Ubuntu LTS + nginx + systemd operation of the loopback fleet, Postgres replication and restore drills (056), CI-gate upkeep (cargo audit/deny/fmt/clippy), and integrity drills (`sha256sum -c SHA256SUMS.txt`) after every clone or restore.
Domain specialists to own the regulatory registries (121–150) and the framework evidence: control testing (124), records (086), regulatory-change tracking (121). This is where certification-readiness work actually lands.
Minimum showcase VPS: 4 vCPU / 8 GB / 100 GB, Ubuntu 22.04/24.04 LTS, stable Rust toolchain with build-essential/pkg-config/libssl-dev, Postgres 16 for ledger 001 + core banking 002, nginx reverse proxy with TLS, UFW permitting only 22/80/443, and every fleet service bound to loopback behind the access gateway.
Non-binding planning lines: engineering months for the five capability areas above; infrastructure (VPS + Postgres + monitoring) for the showcase window; external assurance budget for the certification path once operating evidence exists; and a themed demonstration budget for the investor showcase (the card programme's 11-scene demonstration is already scripted and tested).
155 numbered repositories with complete types, axum routes and suites; 3,117 test functions across the fleet archive; the demonstrable bank core running loopback on the live VPS; and the extended card programmes with passed end-to-end demonstration tests (see the Backend tab's evidence table).
the full programme set staged for the showcase VPS — deployment state is stated only where a probe backs it
> vps upload set · 176 programmes · 160 numbered (000–159) + 16 named consoles
counting…
| # | Programme | What it is for | Key features | Category | VPS state |
|---|
Rollout order per the deployment plan: first the demonstrable bank core (001 ledger, 002 core banking, 006 identity — already registry-listed above), then observability (029) and the audit anchor (013) before any regulated workload; the remaining programmes follow the gated full-fleet rollout described on the Regulations & Further Work tab. Nothing on this tab asserts a certification, a load-bearing deployment, or money movement.