Tokenized deposit route
Blocked pending endpoint repair.
01 The problem
Two rails. Only one of them is governed.
A fiat standing settlement instruction is a governed object: it names the beneficiary institution and account, the intermediary chain and the currency, and it changes under review. A token endpoint, as commonly handled, is a pasted string — no proven controller, no authority trail, no freshness policy, and no recorded reason for the route a payment ends up taking.
Fiat settlement instruction
What an institution already knows before releasing a fiat payment.
Beneficiary institution identified by BIC, entity by LEI.
Account and intermediary chain held under mandate.
Changes are reviewed, versioned, and recorded.
Route decisions are traceable end to end.
Token endpoint, as commonly handled
What an institution typically knows about a wallet address it was sent.
An address pasted from a message or a portal.
Controlling institution and legal entity unproven.
Authority evidence absent, stale, or unverifiable.
Custody, network, and token context left implicit.
Five questions before value moves
ControlWhich institution and legal entity control this endpoint?
AuthorityWho has authority over it — and is that evidence current?
ContextWhich wallet, custody, network, and token context applies?
FallbackWhich fiat instruction remains usable if the token route is not eligible?
EvidenceWhat recorded evidence will explain this route decision later?
The control tower makes these answers a precondition, not an afterthought. Endpoints become governed settlement instructions with an owner, an authority trail, graded policy evidence, and an explainable route decision.
02 The control moment
The beneficiary is valid. The endpoint still is not safe.
The defining moment this product exists for: identity checks pass and the fiat instruction is usable, but the requested token endpoint lacks current control evidence. The control tower blocks that route, explains the gap, selects the governed fiat fallback as the recommended route, and records why.
Instruction arrives
A tokenized-deposit settlement is requested. Institution and legal-entity identity check out; the fiat SSI is usable.
Evidence graded
Endpoint control evidence is graded against policy: the wallet allowlist is stale for this rail and the endpoint-control payload is incomplete.
Token route blocked
The route is blocked — not because the counterparty is bad, but because current control evidence does not exist.
Fiat fallback selected
The instruction is not stranded: the governed fiat SSI fallback is selected and remains traceable.
Evidence recorded
Verdict, failed checks, and audit events are recorded, and a repair task names each control to repair.
TOKEN_ROUTE_BLOCKED_FIAT_FALLBACK_SELECTED
One verdict string carries the whole story: what was blocked, what was preserved, and where the evidence lives.
Deterministic and synthetic — the same scenario replays identically, every time.
03 Demo console
The public demo console
Everything below runs in your browser: a static, deterministic model of the control workflow on synthetic data. Four operating views, three authored scenarios, three role perspectives — perspectives change the framing, they do not enforce authorization. The evidence receipt is generated client-side.
SECT demo console — synthetic session
browser-onlysynthetic dataUETR SYN-2026-000184
Guided walkthrough
step 1 of 4Beneficiary endpoint profile
Start here: the beneficiary has a valid fiat SSI, but the tokenized settlement endpoint needs identity-bound control evidence before value moves.
Evidence Receipt
Receipt IDSECT-SYN-2026-000184
Current verdictTOKEN_ROUTE_BLOCKED_FIAT_FALLBACK_SELECTED
Downloadsettlement-endpoint-evidence.json
Counterparty settlement endpoint profile
One operations surface joins the traditional settlement identity layer with the digital endpoint layer.
1. SourceInstitution, entity, endpoint and fallback SSI profile loaded.
2. ControlsFreshness, authority, custody, Travel Rule and rail policy checks.
3. DecisionApprove token rail, select fallback or hold for remediation.
4. EvidenceExportable audit trail for guided walkthrough and ops review.
Institution layer
BICMERIDEFFXXX
RoleCreditor agent and fallback SSI holder
ReachabilitySynthetic institution-reachability evidence
JurisdictionEU synthetic profile
Legal entity layer
LEI549300SYNTHETIC01
EntityNorthstar Components GmbH
Authority
MaintainerFour-eyes treasury operations
Digital endpoint
Wallet0x71...9F4A
CustodyApproved custodian, evidence required
AllowlistStale, refresh required
Endpoint ownerTreasury ops queue
Fiat fallback SSI
CurrencyEUR
AccountDE•• •••• •••• 4400
IntermediaryINTERDEFFXXX
StatusApproved fallback route
Endpoint pre-validation
Checks run before release. The product validates route readiness, not just field syntax.
Policy route decision
The control tower gives operations an auditable route verdict and repair path.
Fiat SSI fallback
Selected while endpoint evidence is repaired.
Evidence and audit pack
Exportable audit trace showing profile source, failed or passed controls, route decision and next operator action.
Scenario “approved” means the authored synthetic scenario is eligible — not a real payment or compliance authorization. Role controls are perspectives, not permissions. Nothing on this page performs a live check or leaves your browser.
04 Working application
Behind this page: a working control plane
The console above is authored proof of the workflow. The same repository ships the deeper proof: a localhost reference implementation — a SQLite-backed application that computes deterministic advisory outputs from persisted synthetic evidence. It is synthetic operational-depth proof, not a hosted product: it binds only to 127.0.0.1 on the operator’s machine, and this public page never calls it.
fields in → six checks → advisory verdict
Deterministic evaluator
A deterministic evaluator grades six policy checks — institution, legal entity, authority, allowlist, payload, fallback — from persisted synthetic fields, never from a scenario label, and returns an advisory approve, hold, or block route verdict. Unknown or unsupported input never approves; it holds.
draft → active → superseded
Endpoint profile lifecycle
Profiles carry a controlled lifecycle. Drafts are editable; activation freezes them; supersession is one atomic replacement that links the old profile to its successor. There is no delete route — superseded profiles keep their full decision and audit history.
open → evidence refresh → resolved
Repair and evidence refresh
An active profile whose latest decision is a hold can open a persisted repair task. Refreshed authority, allowlist, and payload evidence lands on the task — one live repair at a time, and out-of-order or replayed steps fail closed with no partial write.
refreshed evidence → decision v(N+1)
Deterministic revalidation
Revalidation recomputes the decision from the refreshed persisted evidence over the profile’s activation-frozen fields and records it as a new linked decision version that supersedes — never overwrites — the baseline. The same refreshed evidence always yields the same verdict.
v1 → v2 → … → vN
Append-only decision history
Decision history is append-only through the localhost application API: each revalidation records a new linked decision version, and the API exposes no overwrite path. Prior decisions stay queryable after repair, and the version chain records exactly which decision superseded which — the advisory surface promotes the latest, history keeps the rest.
schema v1 → … → v6
Fail-closed local plumbing
Nondestructive, versioned schema migrations through v6; a loopback-only HTTP boundary with strict, bounded JSON writes; structured request logs that never carry payloads; and one canonical quality gate covering the whole repository.
localhost-only
synthetic-only
advisory decisions
no authentication
no RBAC or tenancy
no live providers
no payment execution
Run it from the repository
# destructive demo reset: seed.py replaces demo-db/data/demo.sqlite # use only in a disposable checkout or after making a backup python3 demo-db/seed.py python3 demo-db/app.py --host 127.0.0.1 --port 4188 # then open 127.0.0.1:4188 in a local browser # one canonical quality gate for the whole project: python3 ci.py
05 Claim boundary
What this is — and what it is not
Claim discipline is part of the product story: a control tower that overstates its own evidence would fail its own test. Every identifier on this page is synthetic, and every capability claim is scoped to what actually runs.
This is
What actually runs, and where.
A public, static, synthetic reference demo of the control workflow.
Deterministic authored scenarios with coherent verdicts and audit trails.
A client-side synthetic evidence receipt you can download and inspect.
A localhost reference implementation in the same repository, run only by its operator.
This is not
Nothing here performs a live operation of any kind.
Not live verification of identity, authority, or wallet ownership.
Not payment execution, provider integration, or sanctions or chain screening.
Not a certification, endorsement, or production-compliance statement.
Not authentication, enforced four-eyes, RBAC, tenancy, or hosted persistence.
Public-safe wording
claim-safeSettlement Endpoint Control Tower is a synthetic reference demo. It shows how banks could pre-validate identity-bound wallet endpoints beside BIC, LEI/vLEI-style authority, fiat SSI fallback and ISO/UETR-style visibility. It does not claim live payment execution, live payment-network integration, live legal-entity or authority verification, live wallet ownership verification or production compliance. Scenario “approved” means the authored synthetic scenario is eligible, and role controls are perspectives — not authorization enforcement.