Sasquatch National Bank — Institution Tour

Generated from the L2 institution YAML (l2.yaml). Point RECON_GEN_DOCS_L2_INSTANCE at a different YAML and re-run the docs build to regenerate this tour against another institution.

Sasquatch National Bank's combined treasury + merchant-acquiring view. SNB runs a Cash Management Suite (CMS) for commercial customer DDAs and ZBA cash concentration, AND a merchant-acquiring service that processes card-network sales for retail merchants and pays them out via ACH / wire / check. The L2 instance below covers both surfaces in one model — the L1 dashboard renders treasury invariants (drift, overdraft, limit breach), the L2 flow-tracing dashboard surfaces merchant-acquiring pipeline structure (XOR payout vehicles, TransferKey-grouped settlement cycles, external card-network aggregation).

---

At a glance

What	Count
Singleton accounts (SNB's GL + external counterparties)	16
Account templates (per-customer / per-merchant shapes)	3
Rails (money-movement primitives)	29
Transfer Templates (multi-rail bundles)	3
Chains (parent → child firing rules)	5
Limit Schedules (per-account / per-rail caps)	7

The diagrams below show how these pieces connect. Per-entity descriptions live on the dedicated subpages — that prose IS the source of truth for how SNB treats each entity.

---

Topology — accounts + rails

Every Rail draws an edge between its source-role account and its destination-role account. Single-leg rails draw a self-loop on the leg- role account. Internal SNB accounts are blue; external counterparties are orange.

---

Topology — account templates + rails

Same shape as the accounts view above, but the nodes are AccountTemplate roles rather than singleton Accounts. Each template is one role × N node (the dashed border marks "many instances at runtime"); rail edges connect templates whose roles the rail's source_role / destination_role / leg_role references. Singleton-only rails (no template touched) drop out — this is the template-shape skeleton, not the full topology.

---

Topology — chains (parent → child firings)

Chains declare that when one Rail or Transfer Template fires, another SHOULD fire too. Solid edges are required (validator catches a missing firing); dashed edges are optional. XOR groups capture "any one of these MUST fire — pick the right child by metadata".

---

Topology — account hierarchy (rollup)

How the singleton accounts and templates roll up. Each edge points from a child to its parent — the singleton Account whose role matches the child's parent_role. Solid-bordered nodes are 1-of-1 singletons; dashed-bordered × N nodes are templates that materialize many instances at runtime (e.g. one CustomerDDA per customer, all rolling up to the DDAControl GL).

---

Per-entity reference

Pick a primitive to walk its full inventory + descriptions:

• Accounts — singletons + templates with descriptions.
• Rails — every money-movement primitive with shape, aging caps, posted requirements, metadata keys.
• Transfer templates — multi-rail bundles.
• Chains — required (singleton-children) + XOR (multi-children) firings.
• Limit schedules — daily flow caps.

---

How the dashboards read this

• L1 Reconciliation Dashboard — surfaces the L1 invariant violations against the data this L2 declares: drift, overdraft, limit breach (using the Limit Schedules above), stuck pending / unbundled (using the Rails' aging caps), supersession audit.
• L2 Flow Tracing — walks the Rails / Chains / Transfer Templates diagrams above against runtime activity, surfacing declared-but-never-fired rails, chain orphans and unmatched transfer types.
• Investigation — questions over the leaf-account / external- counterparty graph above (recipient fanout, volume anomalies, money trail, account network).
• Executives — coverage / volume / money-moved scorecard rolled up across SNB's account roster.

For a per-app sheet-by-sheet walkthrough, see the Walkthroughs section.

See it live — the bundled spec_example institution rendered as the live HTMX dashboards.