Build vs Buy: Should Your Bank Build Its Own Credit Analysis AI?

Build if you underwrite more than roughly 3,700 commercial files a year, already run a platform engineering function, and your differentiation lives in credit policy rather than extraction. Buy if extraction is a cost line. Below that volume our five-year model puts build at $5.66m against $2.46m — a 2.3x gap.

Key facts

• Extraction accuracy is the part that commoditises. YuSight reports 95.2% extraction accuracy against a manual benchmark. That number took a specialist team years to reach and it is also the number that general-purpose models are closing on fastest. Anything you build whose value proposition is "we read numbers off PDFs" is a depreciating asset. What does not commoditise is provenance, calibration and the audit record around the number.
• Engineering labour is the whole build case. BLS puts the mean annual wage for Software Developers (15-1252) at $148,100 across employment of 1,687,890, Data Scientists (15-2051) at $126,800, Computer and Information Systems Managers (11-3021) at $192,160, and Credit Analysts (13-2041) at $100,850 with a median hourly wage of $40.15 (BLS, *Occupational Employment and Wage Statistics*, Table 1, May 2025). Every line in the build model below is one of these four numbers times a headcount.
• Buying does not transfer accountability. Interagency third-party guidance expects risk management "commensurate with the bank's risk profile and complexity as well as the criticality of the activity supported by the third party" (OCC Bulletin 2023-17, 6 June 2023). A vendor absorbs the engineering, not the supervisory conversation.
• Model risk guidance no longer answers this question for you. OCC Bulletin 2026-13 defines a model as "a complex quantitative method, system, or approach that applies statistical, economic, or financial theories to process input data into quantitative estimates" and states that "Generative AI and agentic AI models are novel and rapidly evolving. As such, they are not within the scope of this guidance" (OCC Bulletin 2026-13, 17 April 2026; Federal Reserve SR 26-2). The guidance is "expected to be most relevant to banking organizations with over $30 billion in total assets."
• Most of the market has not automated the top end at all. The FDIC found "a mere 1 percent" of large banks would auto-approve a large loan (FDIC, *Small Business Lending Survey*, Section 3). You are not late.

What are you actually deciding to build?

This is where most build business cases go wrong, and it happens in the first meeting. Someone demonstrates a foundation model reading a tax return correctly and concludes that the build is a quarter of work. It is — for one of nine components.

A build scoped to rows one and two ships in a quarter and produces a demo. A build scoped to all nine is a platform, and it is the second one you are actually being asked to approve.

What is the genuine case for building?

Made properly, because it is often the right answer.

1. The break-even is real and it is not that high. The arithmetic below puts it at roughly 3,700 commercial files a year. Vendor pricing scales with volume; a build team does not. Above that line, every additional file is nearly free to a built system and priced to a bought one.

2. Your differentiation is in credit policy, and policy is the expensive half. Extraction gets a number off a page. Deciding whether the owner's $180,000 salary is compensation or distribution, how a related-party rent is treated in the consolidation, and which add-backs survive into your DSCR definition — that is your credit policy, and no vendor will encode it better than you. If you believe your underwriting is a competitive advantage, you should be suspicious of outsourcing the layer that expresses it.

3. You already own the most valuable asset in the problem. A bank with ten years of manually spread files has a labelled dataset — source document to final spread, decided by a credit professional — that nobody can buy. That asset makes your build cheaper and better than a generic one, and it is the single strongest argument for building that most banks never notice they have.

4. Concentrated document mix weakens the maintenance argument. The case against building leans hard on format drift. If 80% of your files come from twelve accounting firms in three states, your format universe is small and slow-moving, and the drift tax you have been warned about is a fraction of what a national vendor carries.

5. No third party in the critical path. No concentration risk finding, no exit plan to write, no vendor roadmap to wait on, no data leaving your perimeter. Under OCC Bulletin 2023-17, a critical third-party arrangement is a supervised topic with real documentation weight. Building removes that conversation entirely.

6. You control the roadmap. When your policy committee changes the leverage definition, you ship it in a sprint rather than filing an enhancement request and waiting two quarters.

What is the genuine case for buying?

1. Format drift is a permanent function, not a project. Bank statement layouts change, tax forms are revised annually, accounting packages alter their export defaults, and every one of those events breaks something at 6pm on a Friday with files in the queue. The build cost you can estimate. The run cost is the one that gets underestimated, and it never ends.

2. Model churn forces regressions you may not be able to run. The foundation model you built on gets deprecated, repriced or superseded. Swapping it is a full regression against a labelled golden set. If you did not build that set — and step eight is the one most internal builds skip — you cannot swap safely, which means you are locked to a model you do not control anyway.

3. Extraction accuracy erodes as a moat. Getting from 85% to 95% is a genuine engineering achievement today. It is also the part of the stack improving fastest for everyone, including your competitors who did nothing. Build for a moat that lasts five years, not for the current gap.

4. The last five per cent is most of the work, and it is the five per cent that matters. Handwritten annotations on a management account. A scanned fax of a 1065. Multi-column statements where the prior-year figure sits closer to the label than the current-year one. A footnote that redefines the revenue line above it. Two related entities with names differing by one word. Clean documents are solved; credit files are not clean.

5. The documentation burden is real even though genAI sits outside the model perimeter. Out of scope for SR 26-2 does not mean out of scope for internal control, and an examiner will still ask who validated the output, how you monitor drift, and what happens when it is wrong. A vendor amortises that documentation across its customers. You amortise it across yourself. What examiners actually ask is in how to evaluate AI underwriting software for examiner readiness.

6. Key-person risk is the failure mode nobody models. Two engineers understand the pipeline. One takes a job at a fintech. This is not hypothetical and it is not insurable.

7. Citation and audit infrastructure is nobody's favourite sprint. It is unglamorous, it does not demo well, and it is deprioritised in internal builds with total reliability. It is also the part that decides whether your credit team trusts the output and whether your examiner accepts it.

What does five years cost? The build model

Profile. A US bank, roughly $8bn in assets, 1,200 commercial credit files a year, an existing data platform team, no prior document AI in production. Fully loaded cost is BLS mean annual wage × 1.35 for benefits, payroll tax and overhead.

Software Developer (15-1252) $148,100 x 1.35 = $199,935 → $200,000 Data / ML Engineer (15-2051) $126,800 x 1.35 = $171,180 → $171,000 Engineering Manager (11-3021) $192,160 x 1.35 = $259,416 → $259,000 Credit Analyst SME (13-2041) $100,850 x 1.35 = $136,148 → $136,000

Year 1 — delivery

Years 2–5 — run and evolve, per year

Five-year build = $1,423,500 + ($1,059,500 x 4) = $1,423,500 + $4,238,000 = $5,661,500

The line most build cases omit: the delay. Fourteen months to production means fourteen months of benefit not received. At 3 analyst-hours saved per file — the spreading slice alone, timed in how much analyst time automated spreading saves — and a loaded analyst hourly rate of $40.15 × 1.35 = $54.20:

3 hours x 1,200 files = 3,600 analyst-hours per year 3,600 x $54.20 = $195,120 per year of benefit 14 months of delay = $195,120 x 14/12 = $227,640 forgone

Keep it as a separate line rather than adding it to the total — it is an opportunity cost, not a cash cost, and mixing the two is how these models lose their credibility in front of a CFO.

What does five years cost? The buy model

Same profile, same volume. Enterprise platform licence, implementation, and the internal cost of owning a vendor relationship — which is not zero and is routinely modelled as zero.

Year 1 : 280,000 + 150,000 + 68,000 + 50,000 + 35,000 = $583,000 Year 2 : 294,000 + 153,000 = $447,000 Year 3 : 308,700 + 153,000 = $461,700 Year 4 : 324,135 + 153,000 = $477,135 Year 5 : 340,342 + 153,000 = $493,342 Five-year buy = 583,000 + 447,000 + 461,700 + 477,135 + 493,342 = $2,462,177

The comparison, and the break-even

Five-year build : $5,661,500 → $943.58 per file over 6,000 files Five-year buy : $2,462,177 → $410.36 per file over 6,000 files Ratio : 5,661,500 ÷ 2,462,177 = 2.30x

Now solve for the volume at which they meet. Build cost is essentially fixed across a wide range — the same team maintains a pipeline processing 1,200 files or 4,000. Buy cost has a fixed part (implementation plus internal ownership) and a variable part (the licence, which scales with volume).

Buy fixed over 5 years = 150,000 + (153,000 x 5) = $915,000 Buy licence over 5 years = $1,547,177 at 1,200 files/year = $1,289.31 per file-year Buy(V) = 915,000 + 1,289.31 x V Set Buy(V) = Build = 5,661,500 1,289.31 x V = 5,661,500 − 915,000 = 4,746,500 V = 4,746,500 ÷ 1,289.31 = 3,681 files per year

Break-even is about 3,700 commercial files a year.

That is a genuinely useful number and it does not point where a software vendor would prefer. Below roughly 3,700 files a year, buying wins on cost and wins harder on risk. Above it, the build case starts paying for itself on cost alone — before you count the strategic arguments, which is where it gets stronger still.

What does each option actually give you?

Which institution profile should choose which?

What breaks first in a home-built extraction pipeline?

In roughly the order it happens, from teams that have done it:

1. A new statement format, usually within eight weeks of go-live. A regional bank changes its PDF layout and a quarter of your files stall.
2. Entity mapping on the first genuinely multi-entity file — a holding company, an operating company, a real-estate LLC and a trust, with documents that name none of them consistently.
3. Confidence calibration. Scores exist but nobody validated what they mean, so the exception queue is tuned by guesswork and either floods or leaks.
4. Provenance. Built as a v2 feature, so reviewers cannot cheaply verify a figure, so they re-perform the work, so the time saving evaporates and adoption stalls. The reasons this specific failure is fatal are set out in what financial spreading is.
5. Regression testing. No golden set, so nobody can prove a change did not break something, so changes slow to a crawl.
6. The engineer leaves.

Note that only the first is an AI problem. The rest are product and platform problems, which is precisely why "we have good ML people" is not on its own an argument for building.

If you build anyway, do these six things

A CTO who reads the arithmetic above and still decides to build is often right. Six things separate the builds that work from the ones quietly retired in year three:

1. Build the labelled golden set first, before the extractor. Three thousand documents with verified ground truth. It is your regression harness, your calibration data, and your only defence when you need to swap models.
2. Scope all nine components in the business case, or scope two and call it a pilot — but do not scope two and call it a platform.
3. Build provenance in the first sprint, not the eighth. Every figure carries document, page and coordinates from day one. Retrofitting it is close to a rewrite.
4. Calibrate confidence and publish the band table. If a 0.94 does not mean 94%, every downstream threshold decision is guesswork. The tuning arithmetic is in human-in-the-loop credit review.
5. Staff the run function on day one, not at handover. A build team that disbands at go-live leaves a system that degrades from month two.
6. Name the person who fixes it at 6pm on Friday. Write the name down. If you cannot, you have answered the build-versus-buy question without meaning to.

The wider programme context — where this layer sits relative to your LOS, and why extraction alone caps your speed-up regardless of who builds it — is in underwriting automation in commercial lending. The vendor landscape, if you go that way, is compared in best commercial loan underwriting software and Ocrolus vs Docsumo vs YuSight.

FAQ

What does it cost to build credit analysis AI in-house?

On our model — a US bank at 1,200 commercial files a year — about $1.42m in year one and roughly $1.06m a year to run, giving $5.66m over five years. The largest line is engineering labour, and the most underestimated is the ongoing run cost rather than the initial build.

How long does an in-house build take to reach production?

Twelve to eighteen months for something a credit team will actually use, against eight to sixteen weeks to configure a bought platform. The first working extractor arrives in a quarter; entity mapping, provenance, calibration, the exception queue and regression testing are what consume the rest of the year.

What breaks first in a home-built extraction pipeline?

A new document format, usually within eight weeks of go-live. After that: entity mapping on multi-entity files, uncalibrated confidence scores, provenance retrofitted too late, and the absence of a regression suite. Only the first of those is an AI problem — the rest are product engineering.

At what volume does building become cheaper than buying?

Roughly 3,700 commercial files a year on our model, because build cost is largely fixed while licence cost scales with volume. That number is sensitive to how your vendor prices, so recompute it with a real quote before you take it to a steering committee.

Should we build if credit underwriting is our competitive advantage?

Probably build the policy layer, and probably not the extractor. Your differentiation lives in recasting rules, normalisation and the decision logic — not in reading a number off a page. Buying the commodity half and owning the differentiated half is the option most banks never explicitly consider.

Does buying transfer the regulatory risk to the vendor?

No. Interagency third-party guidance expects risk management commensurate with the criticality of the activity, which means diligence, contractual controls, monitoring, an exit plan and annual review. A vendor absorbs the engineering. The supervisory conversation stays with you.

Does SR 26-2 apply to a credit analysis AI we build ourselves?

Possibly not, and that is not the relief it sounds like. OCC Bulletin 2026-13 and SR 26-2 place generative and agentic AI outside their scope and are aimed mainly at institutions above $30bn in assets. Falling outside the model perimeter moves the question to internal control and safety and soundness: who validated the output, and can you evidence it.

Is a hybrid — buy extraction, build the policy layer — actually viable?

Yes, and it is the answer for most regional banks. The integration contract is narrow: documents in, structured financials with citations out, then your normalisation, your ratios and your decision logic on top. It requires a vendor with a real API rather than only a user interface, which is a question worth asking in the first demo.

How do we know whether our extraction accuracy is good enough to build on?

Test it the way you would test a vendor: a labelled sample of your own documents, field-level ground truth, accuracy reported per field class rather than as one blended number, and separately for clean and degraded documents. A single headline accuracy figure — anyone's, including 95.2% — tells you almost nothing without the test set behind it.

Key takeaways

• On 1,200 commercial files a year, five-year build cost is $5.66m against $2.46m to buy — a 2.3x gap, driven by engineering labour and the run function rather than the initial build.
• Break-even is roughly 3,700 files a year. Above it the build case pays for itself on cost alone; below it, buying wins on cost and wins harder on risk.
• A build scoped to classification and extraction ships in a quarter. A build scoped to entity mapping, normalisation, provenance, calibration, the override queue, regression testing and drift maintenance is a platform.
• The strongest genuine build arguments are volume, a differentiated credit policy, ten years of your own labelled spreads, and a concentrated document mix. Take them seriously.
• The strongest genuine buy arguments are permanent format drift, model deprecation, the documentation burden, and the fact that extraction accuracy is a commodity that erodes as a moat.
• The hybrid — buy the extraction and provenance layer, build the policy and decision layer — is right for more regional banks than currently choose it.
• If you build: golden set first, provenance in sprint one, calibrated confidence, a staffed run function, and a named person for 6pm on Friday.

Watch YuSight spread a real balance sheet — [book a live demo](https://yuverse.ai/yusight).