What Is the ROI on GenAI Fraud Projects at Financial Institutions? – A Primer

The Series

Every GenAI budget line eventually meets the same question from Finance: what is this actually worth? In fraud, that question is uniquely hard to answer, because the value of fraud prevention is an absence. A stopped theft leaves no invoice, no deposit, no ledger entry: nothing to count. This three-part series builds a framework for estimating that invisible value anyway, and defending the estimate in front of a committee. It separates projects that catch more fraud from projects that lower the cost of operating, prices the costs most business cases forget, replaces false precision with honest ranges, and ends with the number to lead with in the room. One worked example, a large financial institution with twelve million transactions a year, runs through all three parts.

Part 1: The Value Model

Fraud projects come in two classes, and confusing them is where business cases go wrong. Detection projects are valued as avoided loss, but the value only counts net of what your recovery team was already clawing back, and net of what the new alerts cost: investigator hours and, above all, the customer friction that lands in other departments’ budgets. Efficiency projects are valued as released hours, and hours only become dollars through a mechanism you can name: a smaller invoice, a renegotiated contract, a deferred hire. Part 1 builds both equations, plus the cross term that appears when you run both projects at once and must be claimed exactly once.

For the full value model, including the formulas and the worked example with real numbers, read Part 1: The Value Model → https://analyticsrusers.blog/2026/08/29/estimating-the-return-on-genai-projects-in-enterprise-fraud-management-part-1-of-3-the-value-model/

Part 2: From Point Estimates to Probabilities

Everything in Part 1 produced a single number, and single numbers invite a question you will lose: where did that come from? Part 2 replaces the point estimates with ranges. It handles the events too rare for ordinary math (the once-a-decade catastrophe whose cost is mostly the client relationships that walk out the door) with named scenarios and structured expert judgment. Then a Monte Carlo simulation turns the whole model into percentiles, with one warning that decides whether the simulation informs or flatters: catch rate and false alarm rate move on a single dial, and simulating them separately invents worlds no threshold could produce.

For the scenario method, the severity math, and the full simulation design, read Part 2: From Point Estimates to Probabilities → https://analyticsrusers.blog/2026/08/29/estimating-the-return-on-genai-projects-in-enterprise-fraud-management-part-2-of-3-from-point-estimates-to-probabilities/

Part 3: The Decision

Value is half the story; the decision lives on the cost side. Part 3 adds the program costs (building, governing, permanently reviewing the AI’s output, and paying for inference, where one architectural choice separates a $28,000 line item from a $4.8 million one). It then sets the whole case against the honest baseline: not doing nothing, but what your own engineers would build in three quarters. The series closes with how to present the result: lead with the cautious number, state the probability of a losing year out loud, and name the architecture the small cost line depends on.

For the cost equations, the build-versus-buy formula, and the final roll-up of the worked example, read Part 3: The Decision → https://analyticsrusers.blog/2026/08/29/estimating-the-return-on-genai-projects-in-enterprise-fraud-management-part-3-of-3-the-decision/

Estimating the Return on GenAI Projects in Enterprise Fraud Management, Part 1 of 3: The Value Model

Ask a fraud executive at a financial institution what a generative AI project is worth and you will usually get one of two answers: a very confident number that will more than likely fall apart under scrutiny, or an honest “I can’t quantify it.”

Both responses come from the same place. If you are reading this post, I don’t have to tell you that these days there is a lot of energy around understanding the return on investment on Gen AI projects. Fraud is an even more specialized case.

Return on investment is a simple ratio, (V – C)/C, which asks a simple question: is what we get out of this worth what we put in?

You calculate it by subtracting the cost from the value and dividing by the cost. Fraud projects make that question a little harder to answer, because most projects earn their keep by bringing money in, while a fraud project earns its keep by stopping money from going out. So nothing arrives. A theft that was prevented leaves no record anywhere (no invoice, no deposit, no line in the accounting ledgers) so the entire value of the work is something you have to estimate rather than count. Everything that follows is about how to make that estimate defensible.

The benefit of a fraud project is difficult to measure, for three reasons that compound each other.

The thing you are trying to measure is an absence. A fraud you prevented leaves no trace. You are always estimating a counterfactual (what would have happened in a world where you did nothing), and counterfactuals are, by definition, unobservable. This is the central difficulty in valuing any preventive control [1, 2].

The baseline will not hold still. Fraud losses move on their own. This is the same problem we see with building fraud prevention and detection models. A ring gets arrested. Senior management decides to shift your customer mix. Or some unrelated control gets tightened upstream and quietly changes your numbers. Any measured change in loss is the sum of your project and everything else happening in the world, and the everything-else term is often larger.

Two completely different loss populations are usually averaged together. A retirement platform experiences hundreds or thousands of small account takeovers a year and, if it is unlucky, one catastrophic event a decade. These obey different statistics and require different math. Blending them produces a number that probably describes neither.

This series lays out a framework that handles all three. It is written for the person who has to build the business case and defend it in front of Finance, and assumes no statistical background.

How the series is organized

Both halves of the ROI ratio are built up across the series rather than in one place. Costs come in two kinds. Operating costs scale with what the system does: set the detection threshold lower and you get more alerts, more investigator hours, and more friction on legitimate customers. They are inseparable from the recall decision that created them, so they are modeled alongside the value they buy, in this article. Program costs are what you pay to have the capability at all: building it, governing it, running inference, keeping the evaluation set current. These do not move when you adjust the threshold, and they arrive in Part 3.

InstallmentWhat it builds
Part 1 (this article)The value model: detection projects, efficiency projects, and the term that appears when you run both, with operating costs attached
Part 2What to do when the inputs are ranges: tail events, expert elicitation, and Monte Carlo simulation
Part 3The decision: program costs, the build-versus-buy baseline, and presenting the result

A single worked example, a large retirement recordkeeping platform evaluating two projects, runs through all three parts. This article computes its point estimates; Part 2 turns them into ranges; Part 3 subtracts the costs and turns the result into a decision.

The first move: sort your projects into two classes

The first thing to understand here is that not all projects in an enterprise fraud world should be viewed under the same lens. So we must explicitly account for this. Specifically, in fraud there are two main classes, and they need different value models, different measurement approaches, and different skepticism.

Class A: Detection projects. These are projects which hopefully will change what you catch. Examples of these projects are: a better scoring model, a new signal source, a graph-based linkage layer, an LLM that reads unstructured case notes and surfaces a connection nobody saw. The value is therefore avoided loss. The hard part is proving causation against a moving baseline.

Class B: Efficiency projects. These are projects which will hopefully change what it costs to operate. Examples of these projects are: an assistant that drafts case summaries, a tool that pre-populates regulatory filings, a copilot that answers investigator questions about an entity. The value is time saved (released capacity). Causation is much easier to establish, since you can measure the same analysts before and after, but converting released hours into actual money is the hard part.

These classes of projects do not compete for credit, because they are measured on different numbers. A detection project claims loss reduction; an efficiency project claims cost per case. Nobody has to arbitrate between them.

They are not completely independent, because they collide in the alert queue, which sits between them. This will be addressed later in this article.

Notation

Everything below reuses the same symbols. Define them once and the rest is arithmetic.

SymbolMeaningTypical unit
NNumber of events in the measurement period that are candidates for fraudevents per year
pFraud incidence rate: the fraction of those events that are fraud attemptsdecimal fraction
LAverage loss the firm bears per fraud attempt that gets throughdollars
r0, r1Recall before and after the project: the fraction of fraud attempts you catchdecimal fraction
ρRecovery rate: the fraction of a loss you eventually get back through clawback, chargeback, or insurancedecimal fraction
A0, A1Alert volume before and afteralerts per year
π0, π1Precision before and after: the fraction of alerts that turn out to be real frauddecimal fraction
t0, t1Average analyst time to work one alert, before and afterhours
wFully loaded analyst costdollars per hour
fCost of one false positive that reaches the customerdollars
ηSavings realization rate: the fraction of saved hours that actually becomes moneydecimal fraction

Two terms deserve a plain-English gloss before we go further, because they are the two most misunderstood quantities in fraud analytics.

Recall answers: of all the fraud that was attempted against us, what share did we catch? If 1,000 fraud attempts were made and you stopped 620 of them, your recall is 0.62.

Precision answers: of all the alerts we generated, what share were actually fraud? If you produced 50,000 alerts and 3,000 were real, your precision is 0.06, six percent. That number looks alarming to outsiders and is entirely normal in fraud operations.

These two are linked by an identity that will do a lot of work for us:

A = \frac{N \cdot p \cdot r}{\pi}

In words: your alert volume equals the number of frauds you catch, divided by the share of alerts that are fraud. This identity is a restatement of the formal relationship between precision-recall and ROC space [3]. Note it, because it means you cannot change recall without changing alert volume, and alert volume is what your operations team lives and dies by. Any detection project that promises more recall is implicitly promising your investigators more work, whether or not the business case says so.

Class A: Detection projects

The value side

Ideally, a successfully implemented detection project turns losses you would have absorbed into losses you avoid. The gross value of losses in a period is:

V_A = N \cdot p \cdot L \cdot (r_1 – r_0) \cdot (1 – \rho)

N = total events

p = the share of total events that are fraud attempts

L = what each fraud attempt costs you

(r1 – r0) = number of additional frauds caught

(1 – ρ) = portion that was never coming back anyway

That last factor, (1 – ρ), is tricky, and omitting it can inflate the benefit by half. Cost-benefit analysis calls this the incrementality rule: compare what happens with the project against what would have happened without it. The recovery team was getting that money back either way.

Let’s suppose you already recover 35% of fraud losses after the fact. Catching a fraud before the money leaves does not save you the full loss. It saves you the 65% you were never going to recover. The other 35% you were getting back regardless; the new system just saved you the work of chasing it.

If your recovery process is genuinely improved by earlier detection (and it usually is, since speed matters enormously for ACH returns), you can model ρ as changing too:

V_A = N \cdot p \cdot L \cdot \Big[ r_1(1 – \rho_1) – r_0(1 – \rho_0) \Big]

This refinement is worth making only if you have actual recovery data by time-to-detection. If you do not, use a single ρ and say so.

The cost side

Detection is not free, and its cost is not the software license. It is the alerts.

C_A = \underbrace{(A_1 – A_0) \cdot c}_{\text{investigator}} + \underbrace{\Big[ A_1(1 – \pi_1) – A_0(1 – \pi_0) \Big] \cdot f}_{\text{friction on legitimate customers}}

where c = t · w is the fully loaded cost of working one alert.

The first term is intuitive: more alerts, more analyst hours. We use the alert identity above to compute A1.

The second term (which is usually missing) is what decides most projects

ROI cases routinely omit the costs their controls impose on other departments, because those costs never appear in the fraud budget. For example, there are costs associated with (a) a step-up authentication challenge, which can lead to a customer leaving, and (b) a frozen retirement distribution, which generates a complaint to the plan sponsor.

At scale this term can be enormous. Consider a large institution with forty million accounts. A change that adds two percentage points of step-up authentication generates 800,000 additional friction events, and authentication strength is itself a supervised expectation, not a free dial to turn [4]. At even $8 apiece in downstream contact and abandonment, that is $6.4 million; potentially more than the entire loss reduction the project was built to deliver. When we think of false positives in terms of dollars and not rates it hits a little differently.

The measurement problem, and what to do about it

You now have a formula. The difficulty is that r1, the recall you will actually achieve in production, is the one number you cannot look up. And you cannot infer it by watching your loss numbers fall, because the baseline drifts.

Holdout. The foolproof method is to have a holdout: route a random slice of events, typically 5%, through the old process, and compare. Randomization means the two groups differ only by the treatment, so any difference in outcome is caused by the treatment. This approach gives you clean causal attribution, and the practical design pitfalls are well catalogued [5]. Unfortunately, for a fraud project (especially a detection-related project) to knowingly under-protect a group of clients may be unethical, so this option may be off the table for most organizations.

Shadow scoring. Run the new model silently alongside the old one for a predetermined time. It scores everything; it decides nothing. Then compare what each would have caught on the confirmed cases. This gives you a defensible estimate of Δ r with no customer impact whatsoever. It also produces the ROC curve, which Part 2 will put to heavy use.

Staggered rollout. Deploy channel by channel or segment by segment, and compare the change in each group against the groups that have not received it yet. This is the difference-in-differences approach [6], and it controls for the drifting baseline as long as the drift affects all segments similarly.

Interleaving, for ranking changes. If your GenAI component reorders an investigator queue rather than making decisions, merge the old and new rankings into one list, present it, and track which source contributed each case an investigator confirmed as fraud. This is dramatically more sensitive than a split test at the same sample size, because every investigator sees both systems. The technique and its validation come from search ranking [7, 8], but the argument transfers directly to a scored queue.

Class B: Efficiency projects

The value side

An efficiency project releases capacity. Its gross value is:

V_B = A \cdot (t_0 – t_1) \cdot w \cdot \eta

A = alert volume

t0 – t1 = hours saved per alert

w = loaded hourly cost

η = savings realization rate

The first three factors are straightforward and everyone includes them. The fourth is where honest business cases separate from optimistic ones.

The savings realization rate is the whole argument

The savings realization rate, written η, is the fraction of released hours that becomes hard savings rather than soft.

An efficiency tool produces hours. A business case has to produce dollars. Hours only cross that gap through some specific mechanism: an invoice that shrinks, a contract renegotiated at renewal, a budgeted hire that does not happen. Where no such mechanism exists, the hours return to the pool as slack, and η is near zero however real the time saving was.

Setting η to one, which most business cases do by omission rather than by argument, asserts that every minute saved is a minute billed. Name your mechanism instead:

MechanismTypical ηWhy
Outsourced contact center billed per contact or per minute~1.0Fewer minutes, smaller invoice, immediately
Contract or BPO investigator capacity0.6 to 0.9Converts at contract renewal, subject to minimums
Avoided hire against an approved headcount plan~1.0 for the deferred headsReal, but capped at the number of heads actually in the plan
Existing salaried staff, no headcount change0.0 to 0.3Hours return to the pool as slack unless something absorbs them
Backlog reduction or improved SLANot a cost savingReal value, but it belongs in a different column (see below)

That bottom row causes more arguments than any other. If your team is running a persistent backlog, an efficiency tool will not reduce cost; it will increase throughput at constant cost. That is genuinely valuable (faster case closure means shorter fraud windows and better recovery rates), but it is detection value, not cost savings, and it should be reported in the Class A column where it can be measured properly. Claiming it as headcount reduction while the backlog persists is the single most common way a fraud business case loses credibility.

The practical rule: express the benefit in units Finance can book. “We defer 14 of the 22 investigator hires in the FY27 plan” is a line item. “We save 12,800 analyst hours” is a talking point.

Building t1 honestly: the review tax

When modeling the efficiency gains through Gen AI, the temptation is to just use the generation time as the new handling time. For example, a model drafts a case summary in twelve seconds, so the summary now costs twelve seconds. This may be undercounting the time, and that matters.

It is typical that for anything with regulatory or customer consequence, a human in the loop is a requirement, and therefore a human reviews the output. To model that explicitly we can use the following equation:

t_1 = t_{\text{gen}} + t_{\text{review}} + (1 – q) \cdot t_{\text{rework}}

Where:

tgen = machine time (negligible)

treview = human verification time

q = acceptance rate, the fraction of outputs a reviewer accepts without material change

trework = time to fix the rest

This raises two interesting points.

First, the acceptance rate matters a lot. In the example of something like case generation, if reviewers stop trusting the output and begin deriving it from scratch, at that point t1 (the average analyst time to work one alert after the tool is in place) can exceed t0 (the time an analyst currently spends working one alert end to end, with no assistance), thereby suggesting your tool has made things worse. This is a real and frequently observed failure mode. Measure q during the pilot and treat it as a go/no-go gate. Field experiments show quality can fall on tasks outside a model’s competence even while speed rises [9], which is exactly the condition a low acceptance rate signals.

Second, for regulatory filings, assume review never goes away. Model the reviewed throughput, not the unreviewed one, indefinitely. Any business case that assumes review tapers off after year one is assuming a regulatory posture no institution has actually adopted.

Measurement

Efficiency projects are much easier to measure than detection projects, and there is no ethical obstacle at all. The comparison group is analysts or cases, not customers.

If your case management system timestamps case open and close, you have t0 without running anything. This may turn out to be a better measure, since it covers the full queue over a long period rather than a few weeks of observed behavior. On the other hand, there are some pitfalls to consider: (a) timestamps measure elapsed time, not effort, so cases left open over a weekend or worked in parallel with others will inflate the figure; in these cases, you must check the distribution for the implausible tail before trusting the mean; and (b) because an average across a mixed queue is not the baseline for a tool that only touches one part of it, you should segment by case type.

Historical data gives you the baseline; it cannot give you t1, the acceptance rate q, or any evidence that the tool caused a change rather than coinciding with one. These measures must be obtained from a pilot (or User Acceptance Test).

Whatever the pilot design, pair every time metric with a quality gate. Speed without one is not a measurement, it is a hazard. Score an independent QA sample with reviewers who do not know which cases received the assistant. A tool that cuts handling time 30% while dropping QA pass rate from 96% to 88% has not saved you anything; it has moved cost from the investigation team to the compliance team, where it will show up later and larger. Measured productivity gains from LLM assistants also concentrate among less experienced staff [10], so a pilot staffed with senior investigators will not tell you what a first-tier queue will do.

The coupling term: where A and B collide

Detection projects and efficiency projects claim different kinds of value since they serve different purposes, so neither can take credit that belongs to the other. But they share the alert queue, and that creates a genuine accounting problem.

Interaction effects are well understood in factorial experimental design, and the same concern appears in cost-benefit analysis as the problem of double-counting overlapping benefits. The cross-term, (A1 – A0)(t0 – t1), which we will derive below, is exactly a two-factor interaction written out algebraically.

To better understand this, let’s look at an example: say a detection project raises alert volume from A0 to A1, and an efficiency project lowers handling time from t0 to t1. Each business case was built independently, using today’s numbers as its baseline.

  • Total handling hours before either project: A0 t0.

  • After both projects have been implemented, total handling hours
    is: A1 t1.

  • So the true change is:

\Delta H_{\text{true}} = A_0 t_0 – A_1 t_1

The problem arises because each case computed its effect holding the other constant:

\Delta H_A = A_0 t_0 – A_1 t_0 = (A_0 – A_1) t_0
\Delta H_B = A_0 t_0 – A_0 t_1 = A_0 (t_0 – t_1)

Add them and subtract from the truth:

\Delta H_{\text{true}} – (\Delta H_A + \Delta H_B) = (A_1 – A_0)(t_0 – t_1)

where (Δ HA + Δ HB) = the naive sum, what you get by adding two independently written business cases.

The cross term (A1 – A0)(t0 – t1) belongs to neither project. It is the efficiency gain applied to the additional alerts the detection project created: savings that exist only because both projects happened.

The term is always positive. Whether your business cases have missed it or counted it twice depends on how they were written. If both cases were built on today’s baseline, adding them together understates the benefit. This is the default situation, and neither counted the cross term, so the real saving exceeds what the two cases claim between them. Add it as an explicit line rather than leaving it out and hoping someone notices; an understated case can lose a funding decision just as easily as an overstated one loses credibility.

The other case is a little more subtle. It can lead to double counting. The detection team knows its project will add alerts, but argues it can absorb them without new headcount, because the triage assistant is coming and will make each alert cheaper to work. Meanwhile the efficiency team, writing its own case, books that same reduction in cost per alert as a headcount saving. Both are relying on the same hours; as a result, the cross term is exactly how much you have counted twice. Double counting is common and it is exactly what a sharp reviewer looks for. The defense is simple: build both cases on the same explicitly stated baseline, and report the cross term as its own line. One sentence in a footnote prevents an argument in a review meeting.

There is a second coupling worth naming, running the other direction. The cross term describes detection changing what the efficiency tool has to work on, but this coupling is efficiency changing what detection catches. If a triage assistant changes how long analysts spend on cases, it changes what they find. Faster review may mean more cases worked and more fraud caught; it may also mean shallower review and lower recall. Either way, r1 is no longer independent of t1. Remember, r1 is the recall after the project, the share of attempted fraud you catch once the new system is in place. If your efficiency project affects investigative work, then you should measure recall during the efficiency pilot too. Do not assume it held.

The running example, part one: point estimates

A large retirement recordkeeping platform is evaluating two projects: a graph-based detection layer (Class A) and an LLM case-summarization assistant (Class B). This example continues through Parts 2 and 3.

ParameterPoint valueSource
N: requests per year12,000,000Operations
p: fraud incidence0.0004Confirmed case history
L: average loss$18,000Loss ledger, 3-year
ρ: recovery rate0.35Recovery operations
r0 → r1: recall0.62 → 0.74Shadow scoring, one quarter
π0 → π1: precision0.060 → 0.050Shadow scoring
t0 → t1: hours per alert0.60 → 0.42Case-level randomized pilot
w: loaded analyst cost$70/hourFinance
f: cost per false positive$30Contact center analysis
η: savings realization rate0.55BPO contract + headcount plan

Total fraud attempts: 12,000,000 × 0.0004 = 4,800 per year. Total annual exposure: 4,800 × \18{,}000 = \$86.4$ million.

Class A

V_A = 12{,}000{,}000 \times 0.0004 \times 18{,}000 \times (0.74 – 0.62) \times (1 – 0.35) = \$6{,}739{,}200

Alert volumes, from the identity A = Npr/π:

A_0 = \frac{4{,}800 \times 0.62}{0.060} = 49{,}600 \qquad A_1 = \frac{4{,}800 \times 0.74}{0.050} = 71{,}040

That is 21,440 additional alerts, a 43% increase in queue volume, which is exactly the kind of operational consequence a detection business case tends to leave out.

Investigator cost at c = 0.60 × \70 = \$42$ per alert:

21{,}440 \times \$42 = \$900{,}480

Customer friction: false positives rise from 49,600 × 0.94 = 46,624 to 71,040 × 0.95 = 67,488, an increase of 20,864:

20{,}864 \times \$30 = \$625{,}920
C_A = \$1{,}526{,}400 \qquad V_A – C_A = \$5{,}212{,}800

Class B

Applied to the post-detection queue of 71,040 alerts, at 0.18 hours saved each:

71{,}040 \times 0.18 \times \$70 \times 0.55 = \$492{,}200

Note how much the realization rate costs: gross value is $895,000, but only 55% of it converts. A business case claiming the gross number overstates by $403,000. Rather than one number, show η as a small table of contract outcomes. The base case above assumes BPO renewal plus partial hire deferral; internal-staff-only would put it near 0.30 and full BPO conversion near 0.80.

The cross term

(A_1 – A_0)(t_0 – t_1) = 21{,}440 \times 0.18 = 3{,}859 \text{ hours} = \$270{,}100 \text{ gross}, \ \$148{,}600 \text{ realized}

Neither project’s standalone case contains this. Report it as its own line so it is claimed once and only once.

Every figure above is a point estimate pretending to a certainty nobody has. Part 2 is about admitting that honestly.

Four ways this goes wrong

False positives priced as a rate. A rate hides the scale multiplier. At forty million accounts, a two-point increase in friction can cost more than the entire loss reduction. Price it in dollars of downstream contact.

Savings realization rate assumed to be 1. Hours are not dollars. If nobody’s headcount changes and no invoice shrinks, the savings are slack. Name the conversion mechanism or discount the number.

The recovery rate left out. Preventing a loss you were going to recover anyway is worth the recovery cost, not the loss. Multiply by (1 – ρ).

Review assumed to taper. For anything with a regulatory consequence, human review is permanent. Model reviewed throughput from day one.

Where this leaves you

You now have a complete value model: avoided loss for detection, realized capacity for efficiency, and the cross term that belongs to both projects at once, each with its operating costs attached. Every number in it is a single point estimate, and several of the inputs cannot be looked up anywhere: they are judgments about things that have not happened yet. Part 2 is about handling that honestly, covering the rare, severe events that break expected-value math entirely, and the Monte Carlo simulation that turns the whole model from one number into a defensible range.

References

Citations are keyed by number to the bracketed markers in the text.

[1] Hubbard, D. W. (2014). How to Measure Anything: Finding the Value of Intangibles in Business, 3rd ed. Wiley.

[2] Hubbard, D. W., & Seiersen, R. (2016). How to Measure Anything in Cybersecurity Risk. Wiley.

[3] Davis, J., & Goadrich, M. (2006). “The Relationship Between Precision-Recall and ROC Curves.” ICML ’06.

[4] Federal Financial Institutions Examination Council. Authentication and Access to Financial Institution Services and Systems. August 2021.

[5] Kohavi, R., Tang, D., & Xu, Y. (2020). Trustworthy Online Controlled Experiments: A Practical Guide to A/B Testing. Cambridge University Press.

[6] Angrist, J. D., & Pischke, J.-S. (2009). Mostly Harmless Econometrics: An Empiricist’s Companion. Princeton University Press.

[7] Chapelle, O., Joachims, T., Radlinski, F., & Yue, Y. (2012). “Large-Scale Validation and Analysis of Interleaved Search Evaluation.” ACM Transactions on Information Systems 30(1).

[8] Radlinski, F., Kurup, M., & Joachims, T. (2008). “How Does Clickthrough Data Reflect Retrieval Quality?” CIKM ’08.

[9] Dell’Acqua, F., McFowland, E., Mollick, E., et al. (2023). “Navigating the Jagged Technological Frontier: Field Experimental Evidence of the Effects of AI on Knowledge Worker Productivity and Quality.” Harvard Business School Working Paper 24-013.

[10] Brynjolfsson, E., Li, D., & Raymond, L. (2023). “Generative AI at Work.” NBER Working Paper 31161.

Estimating the Return on GenAI Projects in Enterprise Fraud Management, Part 2 of 3: From Point Estimates to Probabilities

Where Part 1 left off

Part 1 sorted fraud projects into two classes and built a value equation for each. Detection projects (Class A) are valued as avoided loss: event volume, times fraud incidence, times average loss, times the recall improvement, times the share of losses you were never going to recover anyway, minus the operating cost of the extra alerts and the customer friction they create. Efficiency projects (Class B) are valued as released capacity: alerts, times hours saved per alert, times loaded cost, times a savings realization rate η that converts hours into money only where a named mechanism (an invoice, a contract, a deferred hire) exists. Running both projects at once produces a cross term, (A1 – A0)(t0 – t1), that belongs to neither business case and must be claimed exactly once.

The running example, a retirement recordkeeping platform with 12 million annual distribution requests, came out at $5,212,800 net for the detection layer, $492,200 realized for the summarization assistant, and $148,600 for the cross term. Every one of those figures is a point estimate. This article is about replacing them with something more honest.

Symbols carried forward from Part 1: N (event volume), p (fraud incidence), L (average loss), r0, r1 (recall before and after), π0, π1 (precision), ρ (recovery rate), A0, A1 (alert volume), t0, t1 (hours per alert), w (loaded analyst cost), f (cost per customer-facing false positive), η (savings realization rate). New in this part: Ps, Ss, Δ qs for tail scenarios; Φ, θ, λ for severity; and τ for the detection threshold.

Inputs that come from people, not databases

Several inputs in this framework cannot be pulled from a database. Nobody has data on how much more likely you are to interdict a scenario that has never occurred, or on how much of a large relationship’s fee stream you would lose after a public incident. These come from subject matter experts (fraud investigators, relationship managers, operations leads) asked for a low, likely, and high figure rather than a single number. Three people estimating independently and then reconciling produces something far more defensible than one person’s best guess, and the PERT distribution described later in this article exists precisely to turn those three-point estimates into inputs the model can use.

Tail events: where expected value breaks

Everything in Part 1 assumes you have enough events to estimate a rate. For everyday retail fraud at a large institution you have thousands of confirmed cases, a stable base rate, comfortable statistical power.

For the events that actually frighten your risk committee, you do not.

A compromised advisor credential used against dozens of custodied client accounts. A retirement plan breach. An insider at the recordkeeper. These arrive perhaps once a decade. Multiplying a probability you cannot estimate by a severity you have never observed produces a number with no information in it.

Use a different model.

Scenario-based valuation

Define three to six potential high-severity fraud events. For each scenario s:

V_{\text{tail}} = \sum_{s} P_s \cdot S_s \cdot \Delta q_s

where

Ps = annualized probability of the scenario occurring

Ss = total severity

Δ qs = increase in the probability that you interdict it in time

Δ qs is a judgment call. It is a structured judgment call, made by people who know the control environment, about a specific concrete scenario, rather than a rate pulled from thin air. Have three SMEs estimate it independently and reconcile. That process is defensible in a way that a fabricated frequency is not. This is the same scenario-based approach supervisors have long accepted for low-frequency, high-severity operational risk [1].

Severity is not the stolen money

The direct loss is usually the smallest component:

S = D + M + \underbrace{\Phi \cdot \theta \cdot \lambda}_{\text{revenue attrition}} + R
  • D = direct unrecovered
    operational loss to the firm
  • M = client make-whole
    payments
  • Φ = assets under management
    in the affected relationships
  • θ = revenue yield on those
    assets, the effective fee rate
  • λ = expected years of
    revenue lost, computed as the probability of departure times average
    remaining tenure
  • R = regulatory and remediation
    cost

The Φ θ λ term typically dominates everything else, and it is the term people frequently forget to model. For example, a $4 million fraudulent disbursement from a $600 million relationship is not a $4 million event. If that relationship leaves (and the probability is not small), you have lost much more than the $4 million.

Every input here is a range rather than a number, which is precisely the condition that calls for the use of Monte Carlo simulations.

Monte Carlo simulation: turning point estimates into ranges

What it is, in one paragraph

A Monte Carlo simulation replaces each uncertain input in a formula with a range of plausible values, then evaluates the formula thousands of times, drawing a random value for each input every time. The result is not a single number but a distribution. It provides a picture of every outcome the model considers possible, and how likely each one is. You then report percentiles from that picture (the 10th, 50th, and 90th percentile are conventional) instead of a single figure.

The reason to do this is not mathematical elegance. It is that a single number invites the question “where did that come from?”, which you will lose. A distribution with stated assumptions invites the question “are those the right ranges?”, which is a conversation you can actually win. It moves the argument from your credibility to your inputs, which is where it belongs [2].

Where it fits, and where it does not

Not every part of this framework benefits. Simulate where uncertainty is real and compounding; use a sensitivity table where the unknown is something you could look up.

ModelSimulate?Why
Class A (Part 1)Yes; highest valueVA is a product of five uncertain terms. Multiplicative uncertainty compounds in ways intuition does not track.
Tail events (above)Yes; essentialEvery input is elicited judgment with a wide range, and the output is dominated by the upper tail. A point estimate here is close to meaningless.
Build-vs-buy (Part 3)YesThe case usually rests on Δ m, months earlier delivered, and software schedules are strongly right-skewed.
Class B (Part 1)NoMost of the variance sits in η, and η is not random; it is a contractual fact you can go and read. A two-row sensitivity table is more honest and more persuasive.

The correlation trap, and why most fraud simulations are wrong

This is the part to get right, because getting it wrong produces a confident and completely fictitious answer.

Since recall and precision are not independent, they trade off along the model’s ROC curve. The fundamental structure of a detection system dictates that you buy more recall by lowering the score threshold, which admits more alerts, and thereby lowers precision.

If you sample recall (r1) and precision (π1) independently, your simulation will generate thousands of scenarios with high recall and high precision simultaneously, outcomes that no threshold setting could ever produce. At the top end, your distribution will be far too optimistic, and your 90th percentile will describe a world that does not exist. The trade-off is structural, not incidental [3], and it is sharpest exactly where fraud lives: at very low base rates [4].

The fix

The fix is to sample the threshold, not recall and precision directly. The threshold is the only dial you actually control. Your model assigns each event a score; you pick a cutoff; anything above it becomes an alert. Lower the cutoff and you catch more fraud but generate more noise. Raise it and your alerts get cleaner while more fraud escapes. Recall and precision are not settings you choose; they are what the cutoff produces.

Shadow scoring gives you the whole menu. Shadow scoring means running the new model silently alongside your live process for a period, usually a quarter. It scores every event and decides nothing: no alert fires, no customer is touched, no analyst sees its output. You simply record what it thought. At the end, you take the cases you know turned out to be fraud and ask what the model would have done with them at each possible cutoff. Because you already know the answers, you can score its performance without ever having acted on it. For every possible cutoff, you then know what recall and precision would have been against your confirmed cases. That is a table: threshold, recall, precision, one row per setting.

Draw a score threshold τ from your uncertainty range, then read both r1(τ) and π1(τ) off the empirical ROC curve produced during shadow scoring. One draw, two correlated outputs, no impossible worlds:

\tau \sim \text{Distribution} \quad \Longrightarrow \quad \big( r_1(\tau),\ \pi_1(\tau) \big) \ \text{from the observed curve}

One draw, two outputs, guaranteed consistent, because they came from a setting your model actually reached. Sampling them separately can pair a recall from one row with a precision from another, a combination no cutoff could produce. Then let the alert identity A1 = N p r1 / π1 carry that draw through to alert volume automatically, so the analyst cost and friction cost terms inherit the correlation too. This single change is usually the difference between a simulation that informs a decision and one that flatters it.

The area under the ROC curve is the usual way to summarize a detection model, and it is the wrong number for a business case [5]. It averages performance across every possible threshold, including settings you would never run: ones producing half a million alerts a year, or catching a fifth of your fraud. You operate at one setting. Two models with identical AUC can differ by a million dollars in alert-handling cost at the threshold you would actually choose. And AUC has no units: every other term in VA is events, dollars, or a fraction of fraud caught, while AUC converts to nothing. At the very low base rates fraud operates at, it also flatters almost any model, because the vast pool of legitimate events it classifies correctly swamps the comparison [4]. Report performance at your operating point, and report the operating point.

Recall and precision are not the only pair that move together. Two further couplings are worth handling if your data supports it:

  • Loss size and detectability. In most portfolios,
    larger frauds are easier to catch, because they trip
    amount-based thresholds. Drawing L
    independently of r1 will bias the
    result, and the direction depends on your control mix. If your shadow
    scoring output includes the loss amount of each caught and missed case,
    estimate recall separately by loss band and draw from the band-specific
    curves.
  • Incidence and severity. These often move together,
    because the same organized campaign drives both up at once. If you have
    several years of monthly data, check the correlation before assuming
    independence.

Choosing a distribution for each input

For most of these inputs, the range you choose matters more than the shape. If you bound a quantity between a sensible low and high, a Beta, a Triangular, and a PERT will produce percentiles within a few percent of each other. Severity is the exception. Fraud losses have a long right tail (a few very large events among many small ones), and a Normal distribution cannot represent that. Choose it and your P90 will be far too low, which is precisely the number the analysis exists to produce.

ParameterDistributionReasoning
L: loss severityLognormalFraud losses are strongly right-skewed, consistent with the loss distribution approach used in operational risk [6, 1]. This is the one choice that genuinely matters; a Normal distribution here will understate your tail badly
ParameterDistributionReasoning
p: fraud incidenceBeta, or Negative Binomial on the attempt countBounded between 0 and 1; the count version handles the clustering you get from organized campaigns
ρ: recovery rateBetaBounded, and you usually have several years of data to fit it
τ → (r1, π1)Empirical, from the ROC curveSee the correlation discussion above
f: cost per false positiveTriangular or PERTYou typically have a low, likely, and high estimate rather than a dataset
Δ qs: interdiction improvementPERT, from expert elicitationDesigned for exactly this: three-point estimates from people, not data
Ps: scenario probabilityBeta, or a discrete set of expert viewsVery wide; resist the urge to narrow it artificially
λ: years of revenue lostBeta for departure probability × tenure estimateDecompose it rather than estimating the product directly
Δ m: months earlier deliveredLognormal or shifted GammaSoftware schedules slip right, never left

General guidance on distribution choice and correlation handling in models of this kind is in [7]. On sample size: ten thousand draws is more than sufficient for percentile estimates at this precision, runs in under a second, and nobody will ever ask you to justify it. There is no benefit to a million.

PERT is worth knowing if you do not already. It takes a minimum, most likely, and maximum from a subject matter expert and produces a smooth distribution weighted toward the most likely value. It comes out of program evaluation work from the 1950s [8] and exists because three-point elicitation is how humans actually estimate things. It is the natural choice everywhere your input came from a conversation rather than a query.

The correlation structure, in full

The simulation does not impose a correlation matrix. It does something simpler and more defensible: it draws a small number of independent quantities and lets the model’s own arithmetic generate every dependency from there. This matters because a correlation matrix is a guess about how variables move together, while a shared driver is a statement about why they do.

What is drawn independently. Six things: the operating threshold τ, the fraud incidence rate p, the mean loss L, the recovery rate ρ, the cost of a customer-facing false positive f, and the post-tool handling time t1. Plus the tail-scenario inputs, handled separately below. That is the entire source of randomness.

What is derived, and therefore correlated by construction. Everything else falls out:

\tau \;\longrightarrow\; \big(r_1,\ \pi_1\big) \;\longrightarrow\; A_1 = \frac{N p r_1}{\pi_1} \;\longrightarrow\; \text{investigator cost},\ \text{friction cost}

One threshold draw fixes recall and precision together, because both are read off the same row of the shadow-scoring curve. Those two then determine alert volume through the identity from Part 1. Alert volume determines investigator hours, false-positive count, the efficiency project’s value, the cross term, and the inference bill. A single draw of τ therefore propagates into six downstream quantities, all consistently.

The same is true of p, which enters both the value term and, through A1, the cost term. A draw that gives you more fraud gives you more of both, automatically. Nothing in the code enforces this; it is a consequence of p appearing in both expressions.

The one correlation that is imposed rather than derived. Loss severity and detectability are related in most portfolios: larger frauds trip amount thresholds and are easier to catch. Because the model uses a single mean L and a single recall r1, this relationship is not represented, and the direction of the resulting bias depends on your control mix. Handling it properly means estimating recall separately by loss band and drawing from band-specific curves. This is worth doing if your shadow-scoring output records the amount of each caught and missed case, and worth flagging as an omission if it does not.

The tail block is independent of the retail block. Scenario probability, severity components, and interdiction improvement are drawn without reference to p, L, or τ. This is a modeling choice, not a finding: a coordinated campaign could plausibly raise everyday incidence and tail probability at once. With three or four confirmed tail events in the historical record, there is no basis for estimating that dependence, so the model treats the two as separate and the assumption is stated rather than hidden.

What is deliberately not simulated at all. The realization rate η appears as a sensitivity table, because most of its variation is contractual fact rather than uncertainty. Alert volume N, analyst cost w, and baseline recall and precision are held fixed, on the grounds that they are measured rather than estimated, though baseline performance is measured with error like anything else, and treating it as exact makes the output modestly overconfident.

The running example, part two: simulated

The recordkeeping platform from Part 1, now with ranges on the inputs. The threshold is sampled from the shadow-scoring curve so recall and precision move together; loss, incidence, recovery, friction cost, and handling time get the distributions above; ten thousand draws.

ParameterPoint valueSimulated range
p: fraud incidence0.0004Beta, 0.00028 to 0.00055
L: average loss$18,000Lognormal, median $15,400
ρ: recovery rate0.35Beta, 0.26 to 0.44
r1, π10.74, 0.050via threshold draw
t1: hours per alert0.42PERT, 0.38 to 0.46
f: cost per false positive$30PERT, $18 to $52
η: savings realization rate0.55sensitivity table, not simulated

Class A, simulated

PercentileNet Class A value
P10$2,410,000
P50$4,980,000
P90$8,140,000
Probability of negative net value2.1%

Note that the P50 of $4.98 million sits below the point estimate of $5.21 million from Part 1. That gap is the lognormal severity distribution asserting itself: average loss exceeds median loss, so a calculation built on the average lands above the middle of the distribution. Explain this before someone else calls it an inconsistency.

Ranking the inputs by their contribution to output variance: L first by a wide margin, then Δ r, then f, then ρ, then p. That ordering is the work plan. Loss severity and the recall lift are worth another month of measurement; incidence is not.

The tail scenario, simulated

One scenario: an advisor credential compromise reaching multiple custodied relationships.

ComponentPoint valueSimulated range
Ps: annualized probability0.15Beta, 0.06 to 0.28
D: direct operational loss$500,000Lognormal
M: client make-whole$4,000,000Lognormal, wide
Φ: AUM in affected relationships$600,000,000Lognormal, $200M to $1.4B
θ: revenue yield0.35%fixed
λ: years of revenue lost3.5Beta departure × tenure
R: regulatory and remediation$2,000,000PERT, $0.5M to $6M
Δ qs: interdiction improvement0.30PERT, 0.12 to 0.48
S = \$500{,}000 + \$4{,}000{,}000 + (\$600\text{M} \times 0.0035 \times 3.5) + \$2{,}000{,}000 = \$13{,}850{,}000
V_{\text{tail}} = 0.15 \times \$13{,}850{,}000 \times 0.30 = \$623{,}250

The revenue attrition term is $7.35 million, larger than the direct loss and the make-whole payment combined. That is the finding, and it is the one that gets a risk committee’s attention.

Simulated, the severity distribution runs from a P10 near $6.2 million to a P90 above $27 million, and the annualized value from roughly $180,000 to $1.42 million. Report the severity range as well as the expected value: the number the committee needs is not the average, it is what a bad day costs.

Two ways this goes wrong

Recall and precision sampled independently. This produces a simulation full of worlds that no threshold could create, and a P90 that is pure fiction. Sample the threshold and read both metrics off the curve.

Pilot results extrapolated linearly. A triage pilot on 500 hand-picked cases with a senior analyst watching tells you very little about the full alert distribution worked by a first-tier queue. Discount the pilot result and state the discount you applied.

Where this leaves you

You now have a distribution of benefit rather than a number: percentiles for the everyday fraud model, a severity range for the bad day, and a ranking that tells you which inputs deserve more measurement. What you do not yet have is a decision. Part 3 subtracts the program costs (implementation, governance, human review, and the inference bill that quietly kills these projects), sets the whole thing against the honest baseline of what your own engineers would build anyway, and shows which numbers to lead with in the room.

References

Citations are keyed by number to the bracketed markers in the text.

[1] Basel Committee on Banking Supervision. Operational Risk: Supervisory Guidelines for the Advanced Measurement Approaches. June 2011.

[2] Hubbard, D. W. (2014). How to Measure Anything: Finding the Value of Intangibles in Business, 3rd ed. Wiley.

[3] Davis, J., & Goadrich, M. (2006). “The Relationship Between Precision-Recall and ROC Curves.” ICML ’06.

[4] Saito, T., & Rehmsmeier, M. (2015). “The Precision-Recall Plot Is More Informative than the ROC Plot When Evaluating Binary Classifiers on Imbalanced Datasets.” PLoS ONE 10(3).

[5] Hand, D. J. (2009). “Measuring classifier performance: a coherent alternative to the area under the ROC curve.” Machine Learning 77(1).

[6] Frachot, A., Georges, P., & Roncalli, T. (2001). “Loss Distribution Approach for Operational Risk.” Groupe de Recherche Opérationnelle, Crédit Lyonnais.

[7] Vose, D. (2008). Risk Analysis: A Quantitative Guide, 3rd ed. Wiley.

[8] Malcolm, D. G., Roseboom, J. H., Clark, C. E., & Fazar, W. (1959). “Application of a Technique for Research and Development Program Evaluation.” Operations Research 7(5).

Estimating the Return on GenAI Projects in Enterprise Fraud Management, Part 3 of 3: The Decision

Where Parts 1 and 2 left off

Part 1 built the value model. Detection projects are valued as avoided loss, net of the recovery you were getting anyway, minus the operating cost of the extra alerts and the customer friction they create. Efficiency projects are valued as released hours, converted to dollars only through a savings realization rate η with a named mechanism behind it. Running both produces a cross term that must be claimed exactly once.

Part 2 turned the point estimates into ranges. Rare, severe events got a scenario model with severity built up from direct loss, make-whole payments, revenue attrition, and remediation. A Monte Carlo simulation, sampling the detection threshold rather than recall and precision separately, produced percentiles instead of a single figure.

The running example, a retirement recordkeeping platform evaluating a graph-based detection layer and an LLM case-summarization assistant, stands at: detection $5,212,800 net (simulated P10 $2.41M, P90 $8.14M), efficiency $492,200 realized, cross term $148,600, and a tail scenario worth $623,250 a year in expected terms against a bad-day severity that can exceed $27 million.

What is still missing is everything it costs to have these capabilities at all, an honest baseline to compare against, and a way to present the result. That is this article.

Program costs: what it takes to have the capability at all

The operating costs in Part 1 scale with what the system does: more alerts, more hours, more friction. Program costs are different: you pay them to have the thing at all, and they do not move when you adjust the threshold.

Ctotal=I+G+Rhuman+N⋅σ⋅κ+MevalC_{\text{total}} = I + G + R_{\text{human}} + N \cdot \sigma \cdot \kappa + M_{\text{eval}}

  • I = implementation and
    integration
  • G = governance: model
    documentation, validation, ongoing monitoring
  • Rhuman = human review
    of generated output, which as established in Part 1 does not go
    away
  • N · σ · κ =
    inference cost: total events, times the share σ routed to a language model, times
    cost per call
  • Meval = evaluation
    set maintenance

Inference economics: the σ term is important

The inference term is a product with a very large first factor, N, and that makes σ, the fraction of events you send to a language model, one of the most consequential decisions in the project.

For example, take an institution processing 12 million distribution and transfer requests a year, and an LLM call costing $0.40.

  • Send everything (σ = 1):
    $4,800,000 per year. This kills the project.
  • Send only generated alerts (σ ≈ 0.006): about $28,000 per year. This is a rounding
    error.

Same model, same capability, a 170-fold cost difference. The architecture that survives is the one where conventional scoring (rules, gradient boosting, graph features) runs cheaply on everything and the language model is reserved for the narrow top of the funnel where its reasoning actually changes an outcome.

Write a per-alert token cap into the design, not into the backlog. Unbounded language model invocation against a retail-scale event stream is a well-documented way for these projects to die in month nine, when the first full-quarter cloud bill arrives.

Baseline against internal build, not against nothing

At a firm of this size, the alternative to buying something is almost never doing nothing. It is your own platform team building a version of it in three quarters.

That means the honest numerator is marginal:

Vmarginal=V⋅Δm12+(Vvendor−Vinternal)−I−MvendorV_{\text{marginal}} = V \cdot \frac{\Delta m}{12} + \big( V_{\text{vendor}} – V_{\text{internal}} \big) – I – M_{\text{vendor}}
  • V · Δm/12 =
    the annual benefit, scaled by how many months earlier you get it. This
    is usually the dominant term.
  • Vvendor − Vinternal = the performance difference between what
    you would buy and what your team would build. Often small, sometimes
    negative, occasionally decisive.
  • I = integration cost
  • Mvendor = ongoing
    vendor management, due diligence, and contract overhead

The timing term carries most cases at this tier, and the right move is to say so plainly. Be aware it cuts both ways: measured returns on capability investments lag deployment because the complementary process and training changes take time, so a strict year-one framing understates the benefit [1]. If you dress a timing argument up as a capability argument, an internal engineering group that knows its own roadmap will take the case apart in the review meeting, and they will be right to.

Simulate Δm rather than asserting it, using the same machinery as Part 2. Internal roadmaps slip in one direction only, and a right-skewed distribution on delivery timing often widens the case in your favor while making it more defensible, not less.

The running example, part three: rolling up

Everything the series has computed for the recordkeeping platform, in one table. Point estimates from Part 1, simulated ranges from Part 2, program costs from this article.

LinePoint estimateSimulated P10Simulated P90
Class A net$5,212,800$2,410,000$8,140,000
Class B (realized)$492,200$268,500$716,000
Cross term (realized)$148,600n/an/a
Tail scenario$623,250$180,000$1,420,000
Gross annual benefit$6,476,850$2,930,000$9,780,000
Implementation, year one($1,200,000)
Run and support($600,000)
Governance and validation($350,000)
Inference, alerts only($28,400)
Year-one net$4,298,450$752,000$7,600,000

Probability of a negative year-one outcome: 3.8%.

The Class B range comes from the realization-rate sensitivity table rather than the simulation: $268,500 with internal staff only and no headcount action, $492,200 in the base case of BPO renewal plus partial hire deferral, $716,000 with full BPO conversion at renewal.

Presenting the result

Three things to say when this table goes in front of a committee.

Lead with the P10, not the P50. The P10 is the outcome you would beat in nine years out of ten. A project that clears its costs in nine years out of ten is a different proposition from one with an attractive average, and the committee will trust you more for having said so.

Report the probability of a negative outcome. That single number (here, 3.8%) does more work in an investment committee than the rest of the analysis, because it answers the question people are actually asking, which is not “how much will we make” but “how likely is this to embarrass me.”

Name the architectural decision hiding in the cost lines. The inference line is small only because of a design choice. Had every event been routed to a language model, that line reads $4.8 million and the project does not clear. A committee that understands the cost is contingent on the architecture will hold the project to that architecture, which is exactly what you want.

Closing

The framework reduces to six moves.

Sort projects into detection and efficiency, because they have different value equations and different measurement problems. Handle the moving baseline with shadow scoring, staggered rollout, or a bounded holdout, depending on what your institution will tolerate. Discount efficiency savings by an explicit savings realization rate, and name the mechanism that converts hours to dollars. Model tail events by scenario rather than by frequency, and build severity up to include the revenue attrition that usually dominates it. Simulate the parts that are genuinely uncertain, respecting the correlations, especially the one between recall and precision, and use a plain sensitivity table for the parts you could simply go and look up. Baseline the whole thing against what your own engineers would build, because that, not the status quo, is your real alternative.

None of this produces certainty. It produces a number with its assumptions on the outside, where they can be argued with. In fraud, that is the best available outcome, and it is considerably better than the confident figure that falls apart in the second meeting.

References

[1] Brynjolfsson, E., Rock, D., & Syverson, C. (2021). “The Productivity J-Curve: How Intangibles Complement General Purpose Technologies.” American Economic Journal: Macroeconomics 13(1).