11 November 2025
Settlement lag is a financial fact, not a product feature
The days between customer debit and merchant credit are where float, suspense, and customer-fund questions actually live.
Wallet products like to describe instant payment. The ledgers describe something slower: an authorisation, a clearing file, a merchant payout batch, and a handful of returns. The financial application has to live in that slower world, because that is where customer money sits and where merchant liabilities accrue.
Settlement lag is not inherently a problem. Unexplained lag is. If payout is T+1 in the operations chapter and T+3 in the cash-flow model, the float is being counted twice or not at all. If failed payouts accumulate in a suspense account that is not in the safeguarding perimeter, the customer-fund figure in the application is incomplete.
For live or pilot wallets we sample a merchant cohort and a week of customer credits, then walk them to bank statements. The findings are usually mundane and material: a batch posted on the wrong day, a returned credit left in suspense, a promotional top-up funded from operating cash and reported as customer money.
Applicants still in design can do a paper walkthrough of the same path. It is less satisfying than a dashboard screenshot and much more useful in the financial chapters.