Leverage Points

Why adding reviewers won't fix this fraud queue

A payments company has a growing fraud-review queue. Analysts work through thousands of cases, support waits for their decisions and legitimate customers remain locked out.

The obvious proposal is to hire eight more analysts.

That would give the queue more capacity and may shrink it for a while. The bigger problem is one broad rule that creates most of the cases, while fewer than one in a hundred turns out to be fraud. Support cannot release an obviously legitimate payment, and the fraud team is judged mainly on losses prevented rather than the full cost to customers.

The queue is visible, but the broad rule is what keeps creating most of the work.

Leverage Points are places in a complex system where an intervention can produce an unusually large change in behaviour. Where you intervene can matter more than the force applied.

Changing the rule may prevent more cases from entering the queue than hiring eight people can process.

Five places to check before adding capacity

When the same problem keeps returning, look beyond the number everyone is trying to push. Check what information reaches the people making decisions, which loops keep the problem going, who can act and what the system is really trying to achieve.

1. Parameters

Hiring analysts changes capacity, while leaving the rule that creates the cases alone. Increasing a threshold, enlarging a buffer or shortening a deadline works the same way.

These settings are visible and usually easy to change. They matter, especially in an emergency, though the rest of the system often absorbs the change and keeps producing the same problem.

2. Information flows

For this queue, make sure the person who owns the rule can see whom it blocks, how long they wait and what that costs them.

Showing rule owners the customers each rule blocks incorrectly may change their decisions more than another monthly fraud total. It gives them feedback they were missing.

3. Feedback and connections

Retries can amplify a failure, while appeals and rate limits can correct or dampen it.

Retries can make overload worse. Appeals can correct false positives. Rate limits can slow a runaway loop. One small connection can decide whether an error grows, settles down or reaches the person who can fix it.

4. Rules and authority

For this policy, be clear about who can release a case, what they are allowed to do and what the team is rewarded for.

Allowing support to release a narrow class of low-risk cases changes the queue differently from asking support to escalate faster. Changing the fraud team's success measure from gross loss prevented to total expected loss alters which rules appear attractive.

5. Goals

Decide whether the queue is there to minimise fraud loss, customer harm, operating cost or some combination of them.

A system trying to prevent every possible fraud loss will behave differently from one trying to reduce the combined cost of fraud, blocked legitimate payments, support work and lost trust. The goal changes the rules, the information people see and the settings below it.

These are different places to intervene. Pick the one supported by the evidence, because a goal change is unnecessary when a capacity increase solves the urgent problem.

What changes in the review system

Hiring analysts changes a setting. It helps the team process cases faster, while leaving the rule that creates low-value work alone.

A higher-leverage experiment might:

1. Separate the broad rule's cases from genuinely high-risk cases.
2. Give its owner weekly false-positive and customer-impact data.
3. Let trained support staff release a tightly defined low-risk subset.
4. Evaluate the system using total expected loss, including customer and operating costs.
5. Run the change on a small share of traffic with an immediate rollback condition.

Fewer low-value cases give analysts more time for real risk, let support resolve a defined low-risk group and reduce the wait for legitimate customers.

The change is narrow, but it reduces the number of low-value cases entering the queue.

Why the same idea appears elsewhere

Ecology. Adding fish to a depleted lake changes a stock. If excess nutrients keep producing algae, the lake may return to the same unhealthy state. Changing the nutrient inflow or restoring a predator relationship affects how the population regulates itself. Ecosystems have no single owner or agreed goal, though, and an intervention can create consequences nobody predicted.

Software architecture. When a service collapses under load, adding more servers changes capacity. If every failed request triggers several immediate retries, the extra servers may only postpone the same failure. Waiting longer between retries, recognising repeated requests so they do not duplicate work, or refusing lower-priority work changes the link between one failure and the new demand it creates. The code change may be smaller than adding capacity while changing the system's behaviour more fundamentally.

Organisational design and law. Adding reviewers lets an approval process handle more cases without changing who can decide. Giving specialists authority to decide a limited set of cases changes the rule instead. An appeal creates a way to correct mistakes, and publishing past decisions gives later decision-makers more information. Legal systems make similar choices through limits, disclosure rules, which body may decide a case, past decisions and rights of appeal. Each change affects a different part of the process.

In each case, a small rule or feedback change can affect more behaviour than a larger capacity increase.

What to check

Use this model when:

• The same problem returns after repeated fixes.
• More capacity creates more work rather than durable relief.
• A queue grows faster than people can clear it.
• One group bears costs that another group's dashboard can't see.
• A local optimisation worsens the wider system.
• Everyone is working hard while the governing rule remains untouched.

Start with the visible symptom, then work backwards:

• Which quantity are we currently trying to push?
• What generates that quantity?
• Which feedback loop sustains it?
• Who receives the consequences, and who can see them?
• Which rule makes the present behaviour rational?
• What goal makes that rule look correct?

Start with the smallest reversible change that reaches the rule or feedback loop actually creating the problem. A broken form does not always need the organisation to rewrite its purpose.

Test high-impact changes carefully

The model is easy to misuse as permission for sweeping transformation.

Deep changes are hard to predict because they affect many other parts of the system. A new goal can redirect an entire organisation, including parts that already work. A rule that removes friction can remove protection too. Sometimes an urgent queue really does need temporary capacity.

A change that reaches many parts of the system also needs staged exposure, monitoring and an easy rollback.

There is also a hindsight problem. Once a change works, the right place to act can look obvious. Before acting, several believable explanations may compete. Treat the proposed leverage point as a hypothesis and look for evidence that could prove it wrong.

How this differs from nearby models

Theory of Constraints asks what is currently slowing progress towards a goal. Leverage Points asks where a change would alter the system's behaviour. The thing slowing progress may be the best place to act, or it may be a problem created by an earlier rule or incentive. Clearing it faster will not help for long if the system keeps recreating it.

Via Negativa asks what known harm, complexity or interference can be removed. A leverage-point change might remove something, create a way to correct mistakes, move decision-making authority or change the goal. Via Negativa suggests a kind of action; Leverage Points helps decide where that action could have the largest effect.

When repeated effort produces the same result, trace the rule, incentive or feedback loop that keeps bringing it back before adding more capacity.