Skip to content
Finlecy

The float you cannot see

Settlement lag is a treasury problem disguised as an operations problem. The reconciliation data already contains the answer.

AE

Ane Etxeberria

Co-founder, Chief Executive

28 Jan 2026 · 6 min read

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.

FactorEffect we observe
Day of weekFriday instructions land materially later than Tuesday ones
Cut-off proximitySubmissions near a bank's cut-off behave like the next day's batch
Counterparty bankConsistent per-institution differences of half a day or more
Batch sizeVery large files are held for review at some institutions
Month endCompression, 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

  1. 01A forward position, derived from uncleared instructions and their learned clearing distributions, rather than from a fixed per-channel assumption.
  2. 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.
  3. 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.

Finlecy, C/ Hijuela de Lojo 75, 20491 Belauntza, Guipúzcoa, Spain