Outbound Transfer Limit Breaches?

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:

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 = 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.

Columns: account_id, account_name, account_role, account_parent_role, business_day, rail_name, direction, flow_total, cap.

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).