Edit account template · MerchantDDA

An AccountTemplate declares a Role that exists as many instances rather than as a singleton. It's the L2 model's way of saying: this role isn't one specific account — it's a class of accounts. The canonical example is the customer subledger: every customer gets their own Account row (cust-001, cust-002, cust-003…) but they all carry role: CustomerSubledger, and rails / chains / limit-schedules reference the role — never the individual account ids.

Why declare it at all? Two reasons:

• Intent signal. Without a template, a second Account sharing a role looks like a mistake. With one, the validator + dashboards know the role is expected to fan out across many instances.
• Shared structural defaults. The template's parent_role wires every instance up to the same control account for L1 limit-breach roll-ups (e.g. all CustomerSubledgers roll up under CustomerLedger). Setting it once on the template saves repeating it on every individual account.

How instances get created: the operator either hand-writes each Account with the matching role:, or uses the template's instance_id_template / instance_name_template str.format strings (placeholders {role} and {n}) for programmatic synthesis — the demo seed pipeline reads those templates to materialize realistic counts of subledgers / merchant DDAs / per-counterparty accounts.

Common patterns: customer subledgers (one per customer), merchant DDAs (one per merchant), per-product fee accumulation accounts, per-counterparty external accounts. Anything where the institution holds many ledger positions that play the same role in flow.

Required: role (the role name every instance will carry — also the AccountTemplate's addressing key) and scope (internal for institution-side, external for counterparty-side). parent_role is strongly recommended whenever instances should be subject to a daily-cap LimitSchedule anchored on a control role.