Large-Value Reporting: Finding the Payments That Need a Second Look

Most payments are small and unremarkable. A minority are large enough that a compliance regime — and common sense — wants a human to be able to see them. KibiPay's large-value report is the mechanism that turns "payments over a threshold" from a vague policy into a concrete, queryable list.

Rows, not totals

Unlike the transactions report, which aggregates, large-value is deliberately row-level. Each result carries the fields an investigator actually needs to pull a thread: the payment id, the tenant_id, the scheme and status, the currency and amount, the client reference, and the created_at timestamp. An aggregate would tell you "there were 40 large payments"; this tells you which forty, so you can look at each.

A threshold you control

The threshold defaults to 10,000 — a familiar figure to anyone who has read a currency-transaction-reporting rule — but it is not hardcoded into the meaning of "large." It is a request parameter. Investigating a lower-value structuring pattern? Drop the threshold and re-run. Focusing on only the biggest movements? Raise it. The report is SELECT ... WHERE amount >= :threshold ORDER BY amount DESC, so results always arrive biggest-first, and the analyst reads down until the amounts stop being interesting.

Why "order by amount descending" matters

Sorting matters more than it looks. Large-value review is a triage activity: attention is finite, and the marginal value of looking at the next payment falls as the amount falls. Presenting the largest payments first means the highest-risk items are always at the top of the queue, and a reviewer who runs out of time has still seen the ones that mattered most.

Structuring: the pattern the threshold can hide

A fixed threshold has a well-known weakness — "structuring," where someone deliberately splits a large transfer into several payments each just under the line to stay off the report. That is exactly why the threshold is adjustable and why the report returns rows with a reference and a tenant_id: an analyst can lower the threshold and eyeball whether a single tenant is making a suspicious cluster of just-under-the-limit payments. The tool doesn't decide it's structuring; it gives a human the raw material to decide.

Bounded, tenant-aware, and on the replica

Like every report, large-value is capped (at 5,000 rows) so a wide date window can't try to stream the entire ledger, it can be filtered to a single tenant, and it runs against the read replica rather than the payments primary. It is available as JSON for pipelines or CSV for a spreadsheet, over the same windowed from/to interface as the rest of the report suite.

Large-value reporting isn't fraud detection on its own — the exceptions report covers the rejected-and-returned population — but it is the simplest, most defensible answer to a regulator who asks "show me the big ones." And having that answer one query away is the point.

Not a verdict, a worklist

It's worth being clear about what the large-value report is and isn't. It does not decide that a payment is suspicious, and it does not file anything with anyone — that judgement belongs to a human analyst and, where warranted, feeds the exceptions report that gathers SAR candidates. What the large-value report does is build the worklist: the defensible, repeatable answer to "show me every payment at or above this size in this window." Because the threshold is a request parameter rather than a hardcoded constant, the same report serves several jobs. Set it to a regulator's reporting floor and you have your threshold-reporting population. Drop it lower and re-run against a single tenant, and you have the raw material to eyeball whether someone is splitting a large transfer into several just-under-the-line payments. Each row carries the tenant, reference, amount and timestamp an investigator needs to pull the thread, and the whole result is capped and tenant-filterable so a wide window can't try to stream the ledger. The tool's discipline is that it answers a precise question precisely and leaves the interpretation to the person qualified to make it. And like the rest of the suite it runs against the read replica rather than the payments primary, is available as JSON for a pipeline or CSV for a spreadsheet, and takes the same windowed from/to interface — so pulling the day's large payments is a single parameterless call that never competes with processing the next one.