Settlement-Linked Repayment: The Three Ways It Breaks and How to Tell Them Apart

Platforms that offer merchant advances describe repayment as automatic. A slice of each day's settlement is taken before the money reaches the merchant, so nobody has to remember a due date and nobody has to chase one.

It is the strongest repayment mechanism in SME credit. It is also the claim a lending partner's credit team trusts least, because they know it breaks in three specific ways. A lender funding a platform program will ask about all three before it funds the first advance. A platform that answers "repayment runs itself" has told them it has not thought about it.

This post follows one advance through all three, with the arithmetic, and ends with a table and a short exercise you can run on a live book this week.

The advance we will follow

A POS merchant settles an average of PKR 140,000 a day through the platform's terminal. The platform's lending partner offers six times that.

Term	Value
Average daily settlement	PKR 140,000
Advance	PKR 840,000
Collection	12% of each day's settlement
Daily collection	PKR 16,800
Expected tenor	50 trading days

The figures are illustrative and principal only, to keep the arithmetic visible. A live program adds the agreed fee or markup on top, and the lender prices that fee against the 50-day tenor. Hold on to that last point. It is what the first break attacks.

Break 1: the slow season

On day 20 the merchant has repaid PKR 336,000 and owes PKR 504,000. Then trade slows. Settlement falls 40%, to PKR 84,000 a day, and the 12% slice falls with it, to PKR 10,080.

At that rate the remaining PKR 504,000 takes another 50 trading days. The advance that was priced to clear in 50 days now clears in 70.

Nothing is wrong with this merchant. It is a business having a quiet month, and the mechanism is doing exactly what it should: taking less when there is less. The problem belongs to the lender. A fixed fee earned over 70 days is a lower annualised return than the same fee earned over 50, and a book where every advance drifts this way is a book priced on the wrong tenor.

The control is a minimum collection per 30 days, agreed before the first offer goes live. Assume 26 trading days in a 30-day window. Expected collection is PKR 436,800 (16,800 x 26). A floor at 70% of that is PKR 305,760. In the slow month the slice collects PKR 262,080 (10,080 x 26), so the merchant tops up PKR 43,680 at the end of the window. The tenor stops drifting past what the lender priced, and the merchant still pays less in a bad month than in a good one.

Break 2: the volume moves elsewhere

Now take a different merchant with the same advance. On day 20, settlement on the platform's terminal falls 40% to PKR 84,000 a day. Collection falls to PKR 10,080.

Look at the platform's own data. It is identical to break 1. Same drop, same day, same collection. From settlement alone you cannot tell a quiet month from a merchant who has moved card volume to a second acquirer's terminal, or started asking customers for cash. In the GCC, where merchants often hold terminals from more than one acquirer, it is usually the first. In Pakistan, it is usually the second.

The difference only shows up in a second source: the merchant's bank statement. Call the relationship between the two the capture ratio, platform settlement divided by total bank credits.

	Platform settlement (daily avg)	Bank credits (daily avg)	Capture ratio
At onboarding	PKR 140,000	PKR 200,000	70%
Break 1: slow season	PKR 84,000	PKR 120,000	70%
Break 2: volume moved	PKR 84,000	PKR 200,000	42%

In the slow season both numbers fall and the ratio holds. In a diversion the bank credits hold and the ratio drops 28 points. That one line is the whole diagnostic.

A reasonable starting rule: flag when the capture ratio falls more than 15 points below its own 90-day trailing average for two consecutive weeks. Tune it per program. Merchants with a high cash share at onboarding need a wider band.

Two things matter about what happens next. First, the flag goes to the lender's credit team, and a person decides. A dunning message sent automatically to a merchant who has just had a quiet week damages the relationship the platform owns, and the platform will not forgive the lender for it. Second, the rule needs bank statement data after disbursement, which means ongoing consent, not just the statement collected at application. Without it you can only watch settlement against its own trailing average, and you have to accept that breaks 1 and 2 look the same.

In a Trazmo program this is where DocuMind and RiskRadar sit: DocuMind reads each refreshed statement into the same line items as the application file, so the bank-credit side of the ratio is computed the same way every time, and RiskRadar watches the ratio against its trailing average. It is the same discipline as the four early warning thresholds on a term loan book, applied to the one signal a settlement-linked product adds.

Break 3: the merchant leaves

Settlement goes to zero. The capture ratio is undefined. There is nothing left to take a slice of, and no amount of monitoring changes that.

This break is decided at signing, not after it. Two things have to be in the facility documents before the first advance:

1. A fallback repayment instruction, a direct debit or standing instruction on the merchant's bank account, accepted with the advance.
2. A trigger that moves the facility from the slice to a fixed schedule, for example settlement at zero for five consecutive trading days.

When the trigger fires, the outstanding balance is already known to the rupee because every daily collection was posted to the ledger as it happened, so nobody reconstructs the account from settlement files. CollectBot runs the fixed schedule, with reminders and escalation on the lender's cadence.

Without the fallback instruction, the remaining balance is an unsecured receivable that can only be chased with reminders. That is a legitimate product. It is a different product, and it should be priced as one.

The three cases on one page

Case	Platform settlement	Bank credits	Capture ratio	Read	Action	Set before launch
Slow season	Down	Down by a similar amount	Holds	Business is quiet	Floor applies, no flag	Minimum collection per 30 days
Volume moved	Down sharply	Steady	Drops	Volume is going somewhere else	Flag to the lender's credit team	Ongoing statement consent, ratio threshold
Merchant left	Zero	Any	Undefined	Nothing left to net	Fixed schedule, collections	Fallback instruction, zero-settlement trigger

Run it on your own book this week

You do not need new tooling to find out which of the three you are exposed to.

1. List every live advance with its daily settlement for the last 90 days. Mark each one whose last 14 days sit more than 30% below its own 90-day average. That is your combined break 1 and break 2 population.
2. For each marked advance, pull the most recent bank statement you hold and compute the capture ratio now against the ratio at onboarding. A ratio that held is a slow season. A ratio that dropped is a diversion. An advance with no recent statement is a merchant you cannot classify, and that number is worth knowing on its own.
3. Check the facility documents for every live advance. Count how many carry a fallback repayment instruction and a minimum collection per 30 days. Every advance missing the first is break 3 exposure. Every advance missing the second is tenor drift you have not priced.

Three numbers come out of that: advances you cannot classify, advances showing a dropped capture ratio, and advances with no fallback. Those are the three numbers a lending partner will ask for.

If you run a platform and want to see how the rail sets these controls per program, start with embedded credit for platforms.