Risk

Risk is four pages in the sidebar, and they sit in that order for a reason: a payment is held, somebody asks which rule held it, and then they want to look at the rule.

Page	What it is
Risk alerts	Something was flagged. Usually already happened.
Risk review	Transactions held in under_review, waiting on a person.
Risk rules	The monitoring rules that produce both of the above.
Limits	Per-merchant transaction and velocity limits.

Risk review: the queue with a customer waiting

A transaction in under_review is a real payment, held, with a merchant and a customer both waiting. It is not a refused transaction — it has a non-terminal status precisely so that a “review” verdict has somewhere to put a payment instead of refusing one that was never recorded.

So the cost of leaving this queue is immediate and falls on someone outside the building. Work it promptly, in both directions: releasing a legitimate payment late is as much a failure as letting a bad one through, and it is the failure that generates the support ticket.

When you decide, record why. The next person seeing a similar transaction from the same merchant is reading your note.

Risk rules, and shadow mode

Rules produce alerts and holds. Each one can run in shadow mode, which means it evaluates and records what it would have done without actually doing it.

Use it. Always. A rule written against an intuition about fraud and switched straight on will hold legitimate traffic, and you will find out from the merchants it blocked rather than from the data. Shadow mode lets a rule be measured against real traffic before it refuses anything — run it, look at what it would have caught and what it would have cost, then enable it.

Switching a rule from shadow to enforcing is a change worth treating as a release: know what it will catch, know what it will cost, and know who to tell.

A rule that fires constantly is not a strict rule

It is a broken one. When everything is flagged, the queue is noise, and the real signal is reviewed with the same attention as the false one. Tune it or turn it off — a rule nobody acts on is worse than no rule, because its presence suggests somebody is checking.

Limits

Queues → Limits is a separate page from the risk rules, and that is deliberate rather than a layout accident. A limit is governed by a different permission from a risk rule, and it is dual controlled — an account that can tune risk rules often cannot touch limits at all.

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.

Limits are set against what we understand a merchant to do — their stated business model, their history, their verification. When a merchant asks for a raise, the question is not whether they want one. It 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.
• What is their dispute and failure rate?
• Is this a growing business, or an account behaving differently from how it behaved last month?

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

This platform has previously shipped a complete, well-documented risk schema that nothing called. Everything logged healthily while doing nothing, and the consequence was a configured limit that permitted any amount and a blocklisted counterparty that could be charged — with no error anywhere.

So if a limit or a rule appears to be having no effect, that is not a configuration question to shrug at. It is the most serious class of bug this system has had, and it is silent by nature. Raise it.

Alerts

Queues → Risk alerts is what the rules flagged. Mostly retrospective — it tells you something happened rather than holding it.

Work it for patterns rather than row by row. One alert is an event; the same alert across five merchants in an afternoon is an attack or a broken rule, and either way the useful action is at the pattern level.

Blocklists

A blocklisted counterparty is refused outright, with counterparty_blocklisted.

Adding one is easy and removing one is a decision, so record why it went on. A blocklist with no reasons attached becomes a list nobody dares to prune, and it will eventually be blocking somebody’s legitimate customer with no one able to say why.