Per-account, per-day, per-transfer-type cells where cumulative outbound debit exceeded the L2-configured cap. Caps are pulled from the L2 instance's LimitSchedules at schema-emit time and embedded inline in the underlying view — no JSON path lookups in the dataset SQL. Every row is one violation.
Configured Caps Outbound debit caps from the L2 instance's LimitSchedules — these are the thresholds the view below compares against:
Count of (account, day, rail_name) cells where the outbound total exceeded the L2-configured cap.
Limit Breach Detail
Each (account, day, rail_name, direction) cell where flow > cap. `direction` is Outbound (classic per-rail send cap) or Inbound (AML / structuring threshold on inbound volume — AB.1). `outbound_total` (totals on the breaching side) and `cap` shown side-by-side so the magnitude of the breach is readable in-line. Right-click any row → View Daily Statement.
**Per-direction flow cap {: #5-per-direction-flow-cap}**
> For every CurrentStoredBalance where `Limits` is set, for every `(Rail, limit, direction)` in `Limits`, for every child Account whose `Parent = this account`, when `direction = Outbound` `OutboundFlow(child, rail, businessDay)` SHOULD be ≤ `limit`; when `direction = Inbound` `InboundFlow(child, rail, businessDay)` SHOULD be ≤ `limit`.
Per-`(account, day, rail_name, direction)` cells where cumulative flow exceeded the cap. Caps come from the L2 instance's LimitSchedules and are inlined into the view as CASE branches at schema-emit time. The matview emits one row per breach per direction — the `direction` column distinguishes Outbound caps (`amount_direction = 'Debit'` transactions) from Inbound caps (`amount_direction = 'Credit'`, typical AML inbound-cap pattern). Both directions can apply to the same `(parent, rail)` pair via two LimitSchedules; the dashboard renders both on the Limit Breach sheet, distinguished by the Direction column. (Z.B 2026-05-15: keyed on `rail_name` — previously `transfer_type`. AB.1 2026-05-19: added `direction` column.)
**Action.** Either the LimitSchedule cap is too low (raise it after confirming the day's volume is legitimate) or an upstream control failed. For Outbound breaches, audit the feed for over-sent volume — downstream beneficiaries may be undercredited until reconciled. For Inbound breaches, flag the source for review per the AML / KYC policy that motivated the cap (structuring, unexpected deposits, counterparty source diligence).