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.
Breaches in Window
Count of (account, day, rail_name, direction) cells where the flow on the breaching side exceeded the L2-configured cap, across the visible date range. Zero = no rule violations in the window — the unambiguous healthy state. If the limit_breach matview hasn't refreshed since the last ETL load, the App Info sheet's matview-status table shows the lag — a stale matview can also read zero.
Configured Caps Outbound debit caps from the L2 instance's LimitSchedules — these are the thresholds the view below compares against:
DDAControl × CustomerOutboundACH: $12,000.00/day — $12,000 daily ACH outbound cap per customer DDA. Mirrors the legacy AR policy. Breaches surface on the Today's Exceptions sheet's Limit Breach check.
DDAControl × CustomerOutboundWire: $15,000.00/day — $15,000 daily wire outbound cap per customer DDA. Higher than the ACH cap because wires are typically larger but lower-volume and higher-friction (Fedwire fees, real-time settlement).
DDAControl × CustomerCashWithdrawal: $10,000.00/day — $10,000 daily cash withdrawal cap per customer DDA. Aligns with the federal currency-transaction-reporting threshold so SNB surfaces the breach for compliance review even when it's otherwise within policy.
MerchantDDAControl × MerchantPayoutACH: $50,000.00/day — $50,000 daily ACH payout cap per merchant DDA. Sized to accommodate normal small-merchant settlement volumes (a coffee shop's daily card sales rarely exceed this). Larger merchants negotiate elevated caps via SNB onboarding.
MerchantDDAControl × MerchantPayoutWire: $100,000.00/day — $100,000 daily wire payout cap per merchant DDA. Sized higher than the ACH payout cap — merchants choosing wire delivery are typically higher-volume operations where the per-transaction Fedwire cost is justified.
MerchantDDAControl × MerchantPayoutCheck: $25,000.00/day — $25,000 daily check payout cap per merchant DDA. Lower than the ACH cap because check-payout merchants are by definition lower-tech / lower-volume operations; SNB caps aggressive check issuance to surface anomalies.
DDAControl × CustomerInboundACH: $20,000.00/day — AB.1 (2026-05-19): $20,000 daily ACH inbound cap per customer DDA. AML / structuring threshold — modeled after the federal currency-transaction-reporting rule but applied to ACH inbound volume so SNB compliance surfaces aggregated deposits that approach the threshold from below. Breaches surface on the Inbound branch of the L1 Limit Breach matview (UNION ALL split) and route to the AML review queue, distinct from the operations triage queue that the Outbound payout breaches use.
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
For every CurrentStoredBalance where Limits is set, for every (Rail, limit, direction) in Limits, for every child Account whose Parent = this account, when direction = OutboundOutboundFlow(child, rail, businessDay) SHOULD be ≤ limit; when direction = InboundInboundFlow(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.
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).