The float you cannot see
Settlement lag is a treasury problem disguised as an operations problem. The reconciliation data already contains the answer.
Ane Etxeberria
Co-founder, Chief Executive
Ask a treasury team what their cash position is and you will get an accurate answer. Ask what it will be on Thursday and the answer gets noticeably less confident, because between here and Thursday sits an unknown quantity of money that has been instructed but has not moved.
That quantity is not actually unknown. It is sitting in the reconciliation system, in the set of ledger entries with no clearing record yet. It is simply that almost nobody connects the two.
Two questions, one dataset
Reconciliation asks: which instructions have not cleared? Treasury asks: how much cash is in flight and when will it land? These are the same query with a different aggregation.
An unmatched ledger entry that is three days old is, to operations, a potential break. To treasury it is a known outflow with a probability distribution over its landing date. Both readings are correct and each is incomplete without the other.
Learn the distribution rather than assuming it
The usual approach to forecasting settlement is a fixed assumption per channel: SEPA credit transfers clear next day, card settlements land at T+2. These assumptions are approximately right, which is the most dangerous thing an assumption can be.
Actual clearing is a distribution, and it varies by more factors than most models capture.
| Factor | Effect we observe |
|---|---|
| Day of week | Friday instructions land materially later than Tuesday ones |
| Cut-off proximity | Submissions near a bank's cut-off behave like the next day's batch |
| Counterparty bank | Consistent per-institution differences of half a day or more |
| Batch size | Very large files are held for review at some institutions |
| Month end | Compression, then a queue, then a catch-up |
None of this needs a model to discover. It needs the historical record of instruction-to-clearing time, which the reconciliation system generates as a by-product of doing its job, bucketed by the factors above.
Lag drift is an early warning
Once you have a baseline distribution per source, the useful signal is not any individual late payment. It is a shift in the distribution.
An acquirer that has paid on T+2 for eighteen months and pays on T+4 twice in one week has changed something. It might be a system migration on their side, a new risk hold, or a genuine liquidity problem. From your position you cannot tell which — but you can tell that it happened, on the second occurrence rather than at month end, and you can ask.
By the time a settlement delay shows up as a break, it has already been a cash-flow fact for several days.
Three things worth building
- 01A forward position, derived from uncleared instructions and their learned clearing distributions, rather than from a fixed per-channel assumption.
- 02A per-source lag baseline with an alert on distributional shift, not on individual late items — one late file is noise, a moved median is information.
- 03An ageing view that treasury and operations both read, so that the same uncleared item is visible as a cash-flow input and as a potential break at the same time.
The third is the one that changes behaviour. In most organisations the reconciliation queue and the cash forecast live in different tools, owned by different people, updated on different schedules. The data underneath is identical. Merging the view costs very little and removes an entire category of surprise — the one where operations knew on Monday about something treasury discovered on Thursday.
Keep reading
Operations
The 3% problem
Match rate is the metric everyone reports and the one that tells you least. What matters is the shape of what did not match.
7 min read
Engineering
camt.053 in practice
The schema is public, the standard is well written, and the files will still surprise you. Eleven things that actually break parsers.
9 min read
Engineering
Where rules-only matching stops
A well-written rule set gets you to about 92%. The remaining 8% is not more rules — it is a different class of problem.
8 min read