Your best customer can look like fraud

The last article had a convenient feature: I could tell you that A17 was a good customer. I wrote A17.

In your exception queue, the person asking to run a large batch has not helpfully arrived labeled “whale.” They might be excellent business. They might be the next account you discuss in a loss review. Their willingness to spend a lot is not much of a tie-breaker.

I don't think “false positives are expensive” gets us very far. The useful questions are which mistakes are expensive, how much of that value your policy actually destroys, and what you can know before making the exception.

There is an awkward measurement problem here. A bad account that gets through can leave a fairly concrete bill. A good customer who leaves may give you a support ticket. Or nothing. You still have to make the decision; you just don't get equally cooperative evidence on both sides.

In the first post, we changed the amount of compute an account could consume without improving the fraud score. This time, I want to look more closely at the business we might be refusing in exchange for that protection.

Two false positives. Is that good?

Suppose Relay, our fictional inference reseller, adds a rule. In an authored set of 100 accounts, there are 90 legitimate accounts and 10 whose new funding would reverse. The rule stops eight of the latter before they incur another $1,000 each. It also refuses two legitimate customers. Everyone else receives the same treatment as before.

For the moment, I am giving you those labels. They are synthetic truth, not a claim that a merchant can audit every rejected account this cleanly.

You have prevented $8,000 of adverse compute cost. You have excluded two out of 90 good customers. Would you keep the rule?

Decision 01 / Price the error · authored counterfactual

Would you keep this rule?

Adverse accounts stopped

8

Good accounts refused

2 of 90

Adverse cost prevented

$8,000

This is a constructed 100-account example, not an observed fraud rate. The eight stopped accounts would each have cost an additional $1,000. All other treatment is unchanged.

Read the comparison without playing

Counterfactual good contribution per refused customer	Adverse cost saved	Good value lost	Net change
$100	$8,000	$200	+$7,800
$4,000	$8,000	$8,000	$0
$5,000	$8,000	$10,000	−$2,000

All three cases have the same two false positives out of 90 genuine accounts and the same eight adverse accounts stopped. The price of the errors changes, not the error count.

If those two customers would each have contributed $100 more under the old policy, the rule improves contribution by $7,800. If each would have contributed $5,000 more, it makes the business $2,000 worse. Same accounts stopped. Same fraud prevented. Same false-positive rate.

That does not make the error rate useless. It just doesn't price the errors.

The $5,000 is incremental contribution the restriction prevents, not the customer's order total, an optimistic lifetime-value estimate, or everything the customer has ever spent. In this example we use the next 30 days of useful service, after compute cost, and include the eventual loss on that period's funding. Other costs are held out of the toy.

If a customer waits, retries successfully, or uses another route you offer, you have not necessarily lost the whole amount. If the restriction makes the job impossible, recording an approved account does not mean you retained the work. That was the uncomfortable case at the end of Article 1.

I would want the false-positive analysis broken down by the customers and jobs actually affected, rather than taking the average customer value and multiplying it by a rejection count. An amount or velocity rule gives us a particular reason to check: it selects people partly on the size or pace of the business they are trying to do with us. It is not a random sample of customers.

This is not a novel complaint about payment tooling. Stripe's review guidance explicitly warns that, without a natural gap before fulfillment, manual review can create a bottleneck for good customers. The existence of the control is not enough; its effect on the customer's job matters.1

The large order is not the value estimate

There is an easy overcorrection here: the person wants to spend a lot, so let them through.

I would be fairly reluctant to make “ask for more exposure” the qualification for receiving it.

A legitimate customer's unusually large job may be worth accommodating. A fraudster's unusually large job may be exactly what you should prevent. The amount contributes to both sides of the calculation. It is not independent evidence that this will be a good customer.

Even a genuinely high-volume account can have thin margins, expensive support, or a job that disappears before a review finishes. The question is not whether they deserve a special label. It is what the alternative treatment is likely to add, after its costs, compared with the treatment they would otherwise receive.

For a fully blocked request, a deliberately simple version is:

Expected contribution from the exception = probability of good funding × contribution if good − probability of adverse funding × unrecovered cost if bad.

For an account already receiving a limited service, use the difference between treatments on each branch. Do not charge the exception for costs you already incurred, or credit it with good business you were already going to serve.

Expected value is not permission to ignore a loss limit. You can prefer an exception economically and still be unable to afford the exposure it creates. That constraint should appear beside the return, not be left for someone to remember after the approval.

Now take away the labels

The first toy let us inspect both the prevented loss and the foregone contribution. That made the calculation easy. It did not make the inputs available in a real portfolio.

Suppose the next 100 requests hit a hard limit and receive no service. You see the requests, the scores, and the limit that stopped them. You do not get to observe their outcomes under unrestricted service.

A portfolio in which most of those requests would have been good can produce that record. So can a portfolio in which most would have generated losses. The missing outcomes do not choose between the two explanations.

That is the selective-label problem: historical decisions help determine which outcomes become observable. It is a familiar issue in lending research, not a special property of AI credits.2 External history or other evidence may help. But a rejection does not become a fraud label because it was generated by a rule you trust.

In the next toy, the risk slider supplies an assumption. It does not estimate one from the blocked accounts.

Decision 02 / The unobserved customer · assumption explorer

The blocked accounts haven't answered the question.

What the merchant has observed for this new group

Requests refused

100

Unrestricted outcomes observed

0

Additional cost incurred

$0

This is a separate prospective group, not a replay of Decision 01. There are no modeled differences in the supplied decision-time signals. We are exploring unknown outcomes, not learning their risk from the refusal.

Read the expected-value example and its failure cases

For 100 refused requests, assume $400 of extra contribution per genuine completion and $1,600 of adverse cost per bad completion. The useful check retains 90% of good jobs, passes 20% of adverse jobs, and costs $25 for each request.

Assumed adverse rate	Keep restriction	Make exceptions	Check, then decide	Highest net within $20,000 EL
2%	$0	$36,000	$32,140	Make exceptions
10%	$0	$20,000	$26,700	Check
60%	$0	−$80,000	−$7,300	Keep restriction

The same blocked-account record is compatible with all three assumptions. At 10%, substituting the weak check gives only $3,100 of expected net contribution, compared with $20,000 for making the exceptions without it.

Consider the middle setting: 100 requests, a 10% adverse-funding probability, $400 of incremental contribution if a genuine customer gets useful access, and $1,600 of unrecovered compute cost if adverse funding is fully consumed.

Making all the exceptions produces $20,000 of expected incremental contribution: $36,000 from good business, less $16,000 of adverse cost.

Now suppose an additional check costs $25 per request, preserves useful completion for 90% of genuine customers, and lets 20% of adverse requests through. That produces $26,700: $32,400 of good contribution, less $3,200 of adverse cost and $2,500 to run the checks.

Those are assumptions about a check we would have to obtain, not free information that appears because the story needs a third option. The completion rate includes good customers who fail the check and those who abandon the process. Nothing in the example requires this to be a human review or a particular vendor's product.

Move the assumed adverse rate down and the additional check becomes an unnecessary expense. Move it high enough and neither route earns its risk; keeping the restriction is better. Change the check to one that deters good customers without stopping much bad funding, and its apparent advantage disappears.

We don’t necessarily need a precise fraud-rate estimate to choose between these routes. We need to know whether the uncertainty changes the decision. If the same route wins across the range we can defend, a more precise estimate of that rate may not change what we do. If the recommendation flips inside that range, we have found something worth investigating.

I want an exception route that can earn its place on those terms. Not a permanent bypass for anyone who can get the right person on a call.

The exception should have somewhere to go

For a potentially valuable customer, the next useful action might be to acquire better identity or payment evidence, verify a business relationship, fund the job differently, or establish a bounded allocation that is actually useful for the workload. Sometimes none of those is practical before the customer needs the answer.

The evaluation has to include that inconvenience. An extra check that takes too long can be a refusal with a more elaborate workflow. A fast check can still be the wrong purchase if the uncertainty it resolves rarely changes the decision.

I would start with the evidence and controls already available. Stripe, for example, explicitly presents changes to its risk settings as estimated projections of fraud and payment acceptance based on historical payment data.3 That is useful input, not a substitute for the merchant-side question of what approved access lets a customer accomplish, or what value a different policy would retain.

The case for another data source or a review step is the improvement in the resulting decision after paying for it. It should not get an automatic win because we called it “more information.”

This is also why I would record which exception was requested, what new evidence was used, what exposure was granted, and what subsequently happened. “Sales approved it” is not much of a reusable explanation. Neither is “fraud rejected it.”

That record can tell us where to investigate. It will not make a handpicked set of exceptions representative of everyone who was refused. A review queue full of customers persistent enough to appeal is still a selected group.

What I would measure before loosening it

I would pick a particular boundary rather than ask whether the business is too conservative in general.

For the requests at that boundary: what useful work does the present control prevent? What contribution could a different treatment retain? How much additional adverse cost could it create? What observation would change the decision early enough to matter?

Some of the answer may come from existing history. Some will need an assumption that deserves a range rather than a point estimate. Historical outcomes were generated under a historical policy; evaluating another policy requires care about which counterfactual those outcomes support.4

Where the range changes the recommendation, a bounded policy test may be worth the exposure: eligible population, alternative treatment, decision-time information, observation window—including customers who abandon the process.

This is not a request to buy labels by taking unlimited fraud risk. Some boundaries should stay closed. A successful test at a small line also does not establish that a much larger one is safe; that deserves a separate look.

My prior is that some of these businesses have room to serve more valuable demand without accepting a proportionate increase in losses. But I would not infer that from a whale, a persuasive exception request, or a declining fraud rate.

I would want to know what the policy costs on both sides, and which part of that answer we have actually observed.

Assumptions, arithmetic and sources

Both exercises are authored, not fitted. The first is a constructed potential-outcomes comparison for a 100-account set. Ninety accounts are genuine, ten would have adverse funding. A candidate rule prevents eight $1,000 costs and fully excludes two genuine customers; all other treatment is unchanged. The contribution difference is $8,000 minus twice the incremental contribution foregone per excluded good customer. Both labels and unrealized value are supplied by the author.

The second concerns a different group of 100 refused requests. The kept restriction earns no incremental contribution and incurs no incremental adverse cost. The risk slider supplies the unobserved probability of adverse funding under full use; it is not a score calibration or an inference from missing outcomes.

With p for adverse probability, C for good contribution, L for adverse cost, g for good completion through the extra check, b for adverse pass-through, and k for check cost per request, expected net per request is: 0 for keeping the restriction; (1 − p)C − pL for making the exception; and (1 − p)gC − pbL − k for checking first. The table multiplies each by 100. Check performance and value are homogeneous within each branch of this illustration; a merchant analysis must handle relevant heterogeneity.

The default check uses g = 90%, b = 20%, k = $25; the weak check uses 65%, 80%, $75. The check itself incurs no provider usage, but its price is charged on every request. The good-completion term includes both rejection and abandonment. The decision to check is not randomized here, and the toy establishes no empirical value of information.

All economics use the next 30 days of service and the eventual funding outcomes for that service. Contribution is after provider cost. No terminal customer value, general-equilibrium acquisition effect, recapture through another channel, operating overhead, payment fees, or recovery is modeled. These omissions are not claims that the costs are immaterial. The EL budget is an illustrative expected-loss constraint, not a capital model, tail-risk guarantee or permission to bypass mandatory controls.

There is no trained model, inferred identity, calibrated merchant PD or validated growth forecast in this page. Ground-truth revelations are teaching devices. No real customer records, employer policy details or employer efficacy figures are used.

1. Stripe: Review payments — particularly the warning about bottlenecks when fulfillment has no natural delay. Product documentation, not a measured inference-customer loss study.
2. Kilbertus et al.: Fair Decisions Despite Imperfect Predictions — selective labels and the effect of decisions on future observations; not a claim about prevalence in AI commerce.
3. Stripe: Risk setting and risk controls — explicitly labels historical-impact figures as estimated projections.
4. Coston et al.: Counterfactual Risk Assessments, Evaluation, and Fairness — distinguishes evaluation under historical decisions from counterfactual policy evaluation.

I would start with a boundary you already have. It probably exists for a reason. The question is whether there is a less expensive way to buy the same protection—and what we would need to learn before changing it.