AI credit fraud looks suspiciously familiar

Suppose a customer buys $500 of AI credits, turns them into a bill from your inference provider, and later turns out not to have paid you with their own money.

The credits were prepaid. The compute was not free.

You can tighten the payment rules. You can add a spending limit. Then a good customer arrives with a large batch job and immediately needs an exception to both. The next person asking for an exception might be the reason you wrote the rule.

I designed risk-tiered ACH payment holds for Apple Card. Different product, but a familiar set of questions: how much purchasing power should a payment restore, how quickly, and what do we need to learn before restoring more?

That is why I have a fairly strong prior about prepaid inference fraud. I think a lot of the useful machinery already exists in payment risk, funds availability, and customer-level exposure management. The asset has changed. I am less convinced that the governing problem has.

This is not quite “AI fraud is solved.” I do not know the right policy for an inference provider. I do think it is worth checking whether we are asking a classifier to do the whole job.

Fine. Tighten the rule.

Here is Relay, a fictional inference reseller having an unpleasant day. Four accounts want compute. Your payment screening is already running, and you are willing to lose at most $300 of additional adverse compute cost on this group.

The scores are rankings, not probabilities. The account with the higher score looks more suspicious. A score of 65 does not mean a 65% chance of fraud.

Decision 01 / Checkout · fictional stress case

Which payments get through?

Try tightening the rule. Accepted accounts can consume their full allocation immediately. Rejected payments are not captured.

At checkout: all four accounts have passed the existing rule, which accepts scores below 90.

Account	What you know now	Payment	Score	Max. compute cost
A12	New · small job	$100	20	$80
A11	Three clean payments · expanding	$1,000	25	$800
A17	New · large batch	$2,000	65	$1,600
A03	New · rapid usage requested	$500	65	$400

Scores rank suspicion; they are not probabilities. All costs below are in provider dollars, not the retail price of credits.

The worked result below is available without JavaScript.

Read the worked result instead

A12 and A17 are legitimate. A11 and A03 have funding that later reverses. These are authored outcomes, not a sample fraud rate.

Cutoff	Good contribution	Adverse cost	Net	$300 budget
Below 90	$420	$1,200	−$780	Over
Below 60	$20	$800	−$780	Over
Below 25	$20	$0	$20	Within

Tightening from 90 to 60 prevents $400 of adverse cost and removes $400 of legitimate contribution. At 25, only the small good account remains.

A stricter threshold catches one of the attacks. It also rejects the large legitimate customer. The account with three clean payments still gets through.

Keep tightening and you can satisfy the loss budget. In this example, you are left serving the smallest customer.

That might be the best decision available. A business does not owe every prospective customer an experiment with its money. But the fraud number alone has stopped being very informative about whether the business improved.

The obvious request is for a better score. I would also like a better score. A17 and A03 have the same one, and distinguishing them would be valuable.

Until that arrives, though, why are our only choices “give both the whole allocation” and “turn both away”?

You can be wrong for less money

Keep the original payment threshold. Change the amount each accepted account can consume before the next checkpoint.

Give each account a small first allowance. When it runs out, further work waits. At the checkpoint, release more if the required conditions are met. Any adverse warning stops further consumption, just as it did under the original policy.

Same score. Same warning information. Different amount committed before the warning arrives.

Decision 02 / Availability · same four accounts

How much do you release first?

Keep the original payment cutoff of 90. Choose one initial compute allowance and one release rule for everyone. No account-specific exceptions.

Useful access: A12 can use up to $80 by hour 1. A17 needs at least $80 by hour 1 to start, and can wait until hour 24 for the rest. Every policy stops further consumption on the same warnings. A checkpoint is an automated release, not a free analyst review.

The complete example and failure cases below work without JavaScript.

Read the $100 / 24-hour example and its failure cases

With timely warnings, A03 is stopped at 2 hours and A11 at 12 hours. Each has drawn $100. A12 uses $80; A17 receives the rest at hour 24. The fixed cap and staged policy both lose $200, but they deliver different amounts of good business.

Case	Good contribution	Adverse cost	Net
Fixed $100 cap; timely warnings	$45	$200	−$155
$100 then 24h; timely warnings	$420	$200	$220
$100 then 24h; 72h warnings	$420	$1,200	−$780
$100 then 24h; indivisible A17 job	$20	$200	−$180

Under late warnings, staged release loses to the continuing cap. With the indivisible workload, it loses to accepting only A12, which contributes $20 with no adverse compute cost. The preferred policy is allowed to lose.

Timing and accounting assumptions

• All four payments occur at hour 0. The service horizon ends at hour 24, inclusive; later payment reversals are included in eventual loss.
• Available compute is drawn at each grant. This is a deliberate stress-case assumption, not an estimated consumption rate. A warning prevents subsequent grants, not already-incurred cost.
• The ordinary case gives A03 a warning at 2h and A11 at 12h. The late case changes both to 72h. Warnings precede release when simultaneous.
• A12’s useful demand is at most $80 by hour 1. A17 normally needs $80 by hour 1 and can receive the balance by hour 24. In the indivisible case it needs all $1,600 immediately and otherwise consumes nothing.
• Good funding pays for consumed work. Unused credits are not revenue in this example. Each $1 of good compute cost earns $1.25 of revenue and $0.25 of contribution. On the two adverse accounts, all current funding is ultimately reversed, so consumed compute is an unrecovered cost.
• No fees, recovery, human-review cost, future customer value, interest on held funds, or alternate routing are modeled. Prior payments on A11 are history, not additional current losses.

The useful comparison is the fixed $100 cap against the $100 allowance with a later release. At $100 with a 24-hour release checkpoint, both incur $200 of adverse compute cost. The fixed cap earns $45 of legitimate contribution; staged release earns $420. The second serves more legitimate demand because the warnings stop the bad accounts before the larger allocation becomes available.

The classifier has not become smarter. We have changed what being wrong costs.

A permanent cap and a provisional cap can look identical on the fraud dashboard while delivering very different products to a good customer. One keeps them small. The other gives them a route to more usage.

This is what interests me about the credit-risk analogy. A score helps decide who to trust. Availability policy decides how much that trust is worth, for how long, and under what conditions it should change.

There are three different quantities here

The first is the chance that the funding fails to cover the cost you are about to incur.

The second is how much additional provider cost the account can commit before you can intervene.

The third is what a good customer loses when you do not let them proceed.

Better evidence changes the first. Limits and intervention timing change the second. The product and the customer's actual job determine the third. They interact, but none can stand in for the others.

Expected-loss notation is useful here, but the notation is not the interesting part. The part worth noticing is that exposure is a decision. You cannot choose whether the card was stolen. You can choose whether being wrong about it permits another $50 or another $5,000 of compute.

You also cannot assume those two allocations are equally useful to a legitimate customer. The person running an interactive experiment may get somewhere with a small first allowance. The person with a job that must finish tonight may get nothing.

That is a product question as much as a fraud question.

Now make my policy lose

The example has been kind to staged availability in two important ways. Information arrives before the second allocation. The large legitimate customer can do useful work before receiving the whole amount.

Change either assumption in the availability toy.

Move the warnings until after the full allocation has been consumed. The hold has mostly changed the date of the loss.

Give the good customer a workload that cannot start under the smaller allowance. We can mark the account “approved,” but we have not given them a usable product.

A day is not a unit of trust. It is a period during which something useful may become observable. Waiting helps only to the extent that the information or funding protection changes before more irreversible cost is incurred.

There is another version of this problem with an even less cooperative customer. If someone needs to consume the product before they decide to abuse a dispute, delaying consumption may also delay the very event you were hoping to learn from. We do not get a free observation of their behavior while preventing them from behaving.

So I would not copy a bank's hold schedule into an API product. I would borrow the questions behind it. The Federal Reserve's description of check availability makes the timing problem explicit: funds can become available before the bank learns that a deposited check is being returned unpaid. That is a useful analogy, not a prescription for how long to hold inference credits.¹

My bet is that enough businesses have useful information arriving, and enough legitimate demand can tolerate a staged allocation, for this distinction to be worth money. The example explains why that is plausible. It does not tell us how often those conditions hold.

This is not an argument against buying a fraud model

Stripe reported in January 2026 that OpenRouter uses Radar for Fraud Teams. Start the comparison there, with the controls a real operator already uses, rather than with a fictional company that forgot to screen its payments.²

External identity and payment intelligence can change what you know before a customer has much history with you. Merchant-side usage can add information after the purchase. Both can be inputs to an exposure policy; neither makes the choice of exposure disappear.

This is particularly important for new customers. “We have never seen them” and “nobody has ever seen them” are different information sets. There may be something worth learning from outside your business before you spend your own money learning it.

But an excellent signal arriving after the expensive part of the drawdown cannot prevent that cost. A weaker signal arriving while most of the exposure is still controllable may change the decision substantially.

I would evaluate the signal and the action together: what became knowable, when did it become knowable, and how much money could we still avoid committing at that point?

That is a more useful comparison than arguing in the abstract about whether a third-party model or an internal one is better.

I would start with a control 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.

Historical replay can help with part of that. It can show when a different policy would have stopped additional compute costs. It cannot tell us exactly how a good customer would have responded to a restriction they never encountered. Rejected customers are not a conveniently labeled sample of people you were right to reject.

The result might be a different release policy, better information earlier in the process, or a reason to leave the current control alone. I do not know which we would find in your business. I do have a strong prior that this is a useful place to look.

How the example works · assumptions and sources

Relay is fictional. The four accounts are selected to expose a decision problem, not sampled to represent a merchant's fraud rate. Compute cost is 80% of retail usage. Compare legitimate contribution after compute cost with unrecovered cost on bad funding; do not count the reversed sale as revenue and then subtract its face value again as an additional loss. Fees, recovery, support costs, and future customer value are omitted and would need to be included in a merchant study.

The first experiment changes a checkout threshold. The second keeps the original scores and warning access but changes initial availability and the release checkpoint. The late-warning and indivisible-workload cases expose where the proposed advantage disappears. In the reference setting, A03’s warning arrives at 2 hours and A11’s at 12 hours. Both draw their initial allowance before either warning. The toy exposes the delivery deadlines, release rules, and arithmetic used in every comparison.

The main text does not assume that settlement guarantees protection from a later dispute. Nor does it treat every warning or dispute as proof of deliberate abuse.³ The toy uses authored adverse outcomes; an empirical study needs explicit event definitions, label timing, censoring treatment, and a common baseline.

The fictional example does not disclose a client’s data or an employer’s policy. “Token Kiting” is a series label and a timing-risk analogy, not a claim that every incident is literal check kiting. This is an argument to test, not a hold schedule to deploy.

Sources

1. Federal Reserve Board — Regulation CC overview. The historical funds-availability problem, not an inference-credit hold recommendation.
2. Stripe — OpenRouter announcement, January 29, 2026. Documents OpenRouter’s use of Radar for Fraud Teams; it is not evidence of the toy’s efficacy.
3. Stripe — How disputes work. Distinguishes early warnings from disputes and describes outcomes that can occur after a payment.