Transaction limits

Queues → Limits is “what a merchant is allowed to move, and who has been stopped by it.”

Three tabs: Limits, Recent breaches, Repeat breachers.

A limit is not a risk rule

It sits under risk in the navigation because that is where an operator looks for it, but it differs in three ways that matter:

1. A different permission. merchant.limits.write, not risk.write. An account that can tune risk rules often cannot touch limits at all.
2. It is dual controlled. A second operator approves, like a pricing rule.
3. The merchant may see it. The label is customer-facing prose, not an internal note.

Hiding limits behind a tab on the rules page would mean that refusal appearing only after a click, which teaches people that the console is unreliable rather than that their role is narrow.

Zero and blank are opposites

Zero means prohibited. Blank means no ceiling.

This is the one thing on the screen that is easy to get catastrophically wrong in the safe-looking direction.

A ceiling of zero forbids the traffic entirely. An absent ceiling allows any amount. So an empty input is never submitted as zero, each field says which is which, and a limit that prohibits gets its own Prohibited pill in the table rather than rendering as “0.00” — which reads as a formatting bug and is in fact a merchant who cannot trade.

Precedence: most specific wins

Scope	Beaten by
Every merchant — the platform floor	A KYC-level limit
A KYC level — everybody at that verification level	A merchant-specific limit
One merchant	Nothing

The table shows precedence, so a global limit that appears not to be working can be explained by the merchant-scoped row three lines below it. Check that before concluding a limit is broken.

KYC-level limits count per organisation

A merchant can run several accounts under one organisation — one per app or brand — sharing a single verification. Because the verification is shared, so is the ceiling it buys:

Scope	Counted across
A KYC level	Every account in the organisation, together
One merchant	That account only
Every merchant	Each account separately

So a KYC-level limit of GHS 50,000 a month is GHS 50,000 for the organisation, not GHS 50,000 per account — otherwise ten sub-accounts would be ten times the limit, and the first thing an auditor would test. A merchant-specific limit set on one account still applies to that account alone.

When a sub-account says it is breaching a limit it has barely used, check its sibling accounts’ traffic before anything else: a KYC-level breach can be caused entirely by another account in the same organisation.

The limits table

Column	Notes
Limit	The label. “A merchant may see this label on their own limits page.”
Applies to	Scope. “Most specific wins, as with pricing.”
Ceiling	Or Prohibited, or “No amount ceiling”.
Floor	The smallest payment worth attempting.
Precedence	The resolved order.
Currency	—
State	Live, Inactive, or Retired.
In force since	—

Above it: Live limits, Prohibitions, and a total including retired rows.

Filters: Scope, and whether to include retired rows.

Creating one

“In force as soon as it is created, for every matching payment.”

Field	Notes
Label	A merchant may see this on their own limits page, “so write it for them rather than as an internal note.” e.g. “Daily collection limit — verified businesses”.
Applies to	Every merchant / A KYC level / One merchant.
Merchant	When merchant-scoped.
KYC level	Level 0 (unverified), 1, 2 or 3. “This is where a tiered product’s limits belong.”
Scope detail	Shown only for a global limit, where it says there is nothing more to choose: “a global limit applies to everybody.”
Window	Per transaction (a ceiling on one payment), Daily (calendar day), Weekly, Monthly, Rolling 24 hours, Rolling 30 days.
Direction	Collections — money in, or Payouts — money out.
Channel	Blank = every channel.
Environment	Test or live.
Currency	—
Most that can move	Blank for no amount ceiling.
Most payments	Blank for no count ceiling.
Smallest worth attempting	Per-transaction only. “Below this a transfer costs more in fees than it moves.”
Internal notes	“Not the label — this one is ours.”
Why	The audit log and the approval record.

Use one merchant for an agreed exception, not as a default. A tiered product’s limits belong on the KYC level, where every merchant at that tier gets them without anybody having to remember.

There is no edit

A limit is created or retired. Retiring sets its end date and leaves the row in place; changing one means retiring it and creating its replacement.

That is correct rather than awkward: breaches are recorded against a limit, and a limit whose ceiling changed underneath it would make every historical breach unreadable. The retired row with its original ceiling is what makes last month’s breach mean something.

Recent breaches

Who was stopped, by which limit, and for how much. Two things it is good for:

• A merchant complaining they cannot trade. Find their breach, read the limit, and you know whether the limit is wrong or the traffic is.
• Spotting a limit that is too low for the market. One merchant breaching is a merchant. Twenty merchants breaching the same global limit is a limit.

Repeat breachers

Merchants hitting a ceiling again and again. Two very different stories wear the same shape:

• A growing business whose limit has not kept up. That is a raise, and probably a KYC-level conversation.
• An account behaving differently from how it behaved last month. That is a risk conversation, not a limits one.

The report tells you which merchants to look at. It cannot tell you which story you are reading.

Raising a limit, properly

A merchant asking for a raise is not the question. The question is whether what we know about them supports it:

• Does the trading history support the new ceiling?
• Has their stated business model changed? If so, that is a KYC conversation first — see KYC.
• What is their dispute and failure rate?
• Is this a growing business, or an account behaving differently?
• Is their verification current, or has it lapsed? Check Expiring and lapsed before raising anything.

A limit raised on a phone call and approved on trust is the one that appears in an incident review.

A limit that appears to permit any amount

If a limit looks as though it is having no effect, do not assume a configuration mistake and move on. This platform has previously shipped a risk schema that nothing called — everything logged healthily while permitting any amount, with no error anywhere. It is the most serious class of bug this system has had, and it is silent by nature. Raise it.