AntifrogEnquiries
SERIES / INSTALMENT 4

Bust-out.

A merchant, or an account, that behaves well for exactly as long as it takes to be trusted. What a bust-out needs, and why the chargebacks arrive after the money has gone.

Fictional scenario. Synthetic data. Your notes stay on this browser; do not enter real customer information.

The schemes so far have been things done to a merchant. A bust-out is a merchant, or a customer account, that was the scheme all along. It behaves correctly for long enough to be trusted, draws down everything that trust allows in a short window, and is gone before the consequences arrive. The consequences are disputes, and disputes take weeks.

The term comes from consumer credit, where an account is built up and then emptied. A PSP meets the merchant version: clean paperwork, modest volumes for three or four months, then a surge of sales that are never delivered, settled daily to a bank account that is closed by the time the first chargeback lands. The PSP is left holding the disputes.

What the scheme needs.

From the PSP's chair, a merchant bust-out needs four things, and three of them are decisions the PSP made.

Fast settlement. Daily payout means the money is in the merchant's account before the customer has received anything, let alone complained. A rolling reserve or a settlement delay changes the arithmetic.

A product whose delivery is later than its payment. Tickets for next month. Pre-orders. Travel. Anything where "not received" cannot be known until a date in the future.

Underwriting that stops at onboarding. A merchant reviewed once and never again can change what it sells, how much and to whom without anyone at the PSP seeing a difference until the disputes arrive.

The dispute lag. Visa’s dispute-resolution guidance describes the lifecycle: the cardholder raises it with their issuer, and the merchant and its processor learn afterwards. That lag is the window in which the scheme operates. The account version works the same way with credit lines instead of settlements.

What it looks like in your data.

A synthetic illustration. A ticketing merchant, not Brightwater, onboarded by Northbank Pay in September with a projected EUR 40,000 a month.

  • Months one to three: EUR 28,000, EUR 35,000, EUR 41,000. Dispute rate 0.2 per cent. Nothing to see, which is the design.
  • Month four: EUR 310,000 in eleven days. Average ticket rises from EUR 45 to EUR 180. Every event date is more than six weeks away.
  • Card mix changes: more foreign-issued cards, more first-time cards.
  • Refund rate goes to zero. A merchant that is leaving does not refund.
  • Settlement bank account changed on day two of month four. The old one had been on file since onboarding.
  • Support e-mail to the merchant's example.com address starts bouncing on day fourteen.
  • Disputes: three in month four. Forty-one in month five. Two hundred and ten in month six, on sales made in month four.

By month six the ratio that Northbank's acquirer, Stilling Bank, watches has moved. Mastercard's Excessive Chargeback Programme, as summarised by the processor documentation we cite, sets this month's chargebacks against last month's transactions, which is why the ratio can look benign in the surge month and alarming two months later. Visa's programme, as summarised by acquirer guidance, counts fraud reports and disputes against settled card-absent transactions monthly. Thresholds change; check the current ones with your acquirer.

What else looks like this.

A merchant that has genuinely grown. A viral product, a sold-out festival. Growth produces a volume surge and a changed card mix. It does not produce a changed settlement account, a zero refund rate and a bouncing support address.

A seasonal merchant. Ticketing and travel have months that look like surges every year. The baseline is last year's month, not last month; spike detection and seasonality is the method.

A merchant having a bad quarter honestly. An event cancelled, disputes rising, and the merchant on the phone every day asking what to do. The phone call is the difference.

Where it is usually caught.

At the dispute wave, which is to say too late for the money. The acquirer sees the ratio; the PSP sees the reserve was insufficient; the merchant's phone is disconnected.

The earlier catch is at the change, not the volume. Settlement details changed, product mix changed, average ticket tripled, refunds stopped: any one is a question, four in a fortnight is a hold. Reading a merchant before the first transaction argues that underwriting is a continuing activity, and that the review date on a merchant file is its most useful field.

The earliest catch is in the terms: a settlement delay or reserve proportionate to the delivery lag of what the merchant sells. It does not catch the scheme. It makes the scheme not worth running.

A desk card.

  • Pair every merchant's settlement speed with its delivery lag. Long lag, slow settlement.
  • Alert on changes: settlement account, product mix, average ticket, refund rate, support address.
  • Put month-four sales in a cohort and watch its disputes by month, not the portfolio ratio.
  • Compare with last year's month for seasonal merchants, not last month.
  • Give every merchant file a review date and a person.

Two ratios, two denominators, one portfolio. explains why the acquirer's view lags yours. Try the case VAMP portfolio call, where the merchant is honest and the ratio is still heading the wrong way. Look up bust-out. Part five is bonus rings, where the accounts are the scheme.

Edited 6 November 2026. Primary references are listed above; fictional scenarios are not claims about Antifrog customers or operating experience.

Fictional learning material. Any numerical examples are synthetic. Use only authorised, appropriately minimised records for workplace exercises; do not upload customer information to this learning site.