Settlement & Liquidity Dashboard
The morning view for a card-payments treasury and operations team: did the networks pay what they owed, what is still open and how old it is, and whether there is enough cash in the right accounts to pay merchants tomorrow.
Cash by bank, $M
Bank A · collections + operatingBank B · collections + payoutsBank C · reserveRestricted reserve
Liquidity coverage, days of payouts
CoverageTarget 3.0Limit 2.5
Open settlement exceptions, $M
Not receivedShort-paidUnidentified cash
Settlement by source
On time = share of value due in the last 5 business days that arrived on its expected date. Aging buckets are open exceptions in $K by business days outstanding; darker cells hold more money.
Oldest open exceptions
| Item | Type | Source | Amount | Age (bd) |
|---|
Account balances, end of day
How it works
- Liquidity: merchants are paid on schedule even when a network settles late, so a delay is funded from our own cash. Each evening collections are swept to the payout account, which must hold 105% of tomorrow's payouts; shortfalls are topped up from operating, then from the unrestricted reserve.
- Coverage is available cash (total less the restricted scheme reserve) divided by average daily payouts over the last 20 business days. The reserve requirement rose from $25M to $40M on 1 July, which is why coverage sits below the 3-day target for all of Q3.
- Concentration flags any bank holding more than 45% of cash.
- SQL: the KPIs are reproduced as SQLite queries (
sql/kpis.sql), and tests check that SQL and Python agree.
All data is synthetic: 6 months of settlement batches from Visa, Mastercard, Amex, ACH and RTP with realistic reference loss, late, short, split and netted payments, plus three injected incidents. Built with AI-assisted coding (Claude); the design, controls and review are my own.