How a lending decision gets warranted, not just made - a credit memo automation teardown

A credit memo turns a pile of borrower paper into a decision someone signs. Spreading the operating statement, computing the ratios, drafting the recommendation: that part is mechanical and automates well. The part that does not automate well is the memo's second job, which is to make the decision defensible later, to a credit committee this month and possibly to an examiner or a plaintiff years from now.

Those are two different products. A system that produces a number is an underwriting tool. A system that produces a number plus the warrant for it, meaning the inputs, their provenance, the threshold each was tested against and why the file routed where it did, is a credit memo system. Scoping the first and discovering the second in UAT is the characteristic way this work goes wrong.

This is a teardown of the second one: the actual maths, the places that maths is softer than it looks, the regulatory ground that moved underneath all of it during 2025 and 2026, and the one architectural decision that does most of the work, which is where you put the seam between the component that extracts facts and the component that decides.

The maths is the easy part, and it is not quite as easy as it looks

Income-producing commercial real estate underwriting runs on three ratios, and the regulator publishes all three definitions.

• DSCR, the debt-service coverage ratio, is "calculated by dividing the NOI by the annual debt service requirements."¹⁰
• LTV is the loan amount over the value of the collateral, and the published definition is more particular than the arithmetic suggests: it divides the extension of credit by the market value of the property "plus the amount of any readily marketable or other acceptable non-real estate collateral," and "the total amount of all senior liens on or interests in such property(ies) should be included in determining the LTV ratio."¹⁰
• Debt yield is NOI divided by the loan amount, expressed as a percent. The handbook's own point about it is the useful one: it "provides a measurement of risk that is independent of the interest rate, amortization period, and capitalization rate," and "lower debt yields indicate higher leverage."¹⁰

Three divisions. A worked deal: net operating income of $214,000 against annual debt service of $181,000 gives a DSCR of 1.18x. A $1,460,000 loan against a $2,030,000 appraisal is 71.9% LTV, on a file with no senior liens and no other pledged collateral. The same NOI over the same loan amount is a 14.7% debt yield. Nothing there needs a model, and a model producing any of those numbers is a harder validation problem than you had.

The difficulty is one word upstream. It is NOI.

NOI is not a fact you can extract

The temptation in every document pipeline is to treat net operating income as a field: find it on the operating statement, pull it, hand it to the ratio. The OCC handbook says otherwise in a sentence worth reading twice. "Unlike cash-flow analysis, the NOI analysis may assume market vacancy rates that are above or below actual vacancy rates, and expenses that may not represent an actual or immediate cash expense, such as management fees and reserves for capital replacements."¹⁰ That is not a description of extraction.

NOI is not measured, it is constructed, using the bank's own assumptions about vacancy, management fee and replacement reserve. Those assumptions are credit policy. An agent that "extracts NOI from the rent roll" has therefore already made a policy judgment and buried it inside a scalar, and all three ratios downstream inherit it invisibly.

The honest shape is two layers. The extractor pulls line items with page citations: gross potential rent, actual vacancy, each expense line, as stated, with a pointer to where. A deterministic normalization layer then applies the bank's vacancy floor, management fee and replacement reserve as versioned policy constants, and emits NOI with the deltas it applied. When somebody asks in year three why this deal underwrote to a 5% vacancy when the rent roll showed 2%, the answer is a row rather than an archaeology project.

A deal needs two DSCRs, not one

The second thing that looks like one number and is two. The handbook: "When loan documents contain debt-service coverage covenants, the definitions of income and expenses should be clearly defined. Debt-service coverage calculations for covenant compliance may differ from the DSCR used for underwriting and risk-rating analysis."¹⁰

Underwriting DSCR is defined by credit policy. Covenant DSCR is defined by the note's own defined terms, which were negotiated, so they vary deal to deal and sometimes in ways that decide the outcome: whether a management fee is deducted, whether reserves are, whether a tenant improvement allowance is amortized. A production system carries both, with separate income and expense definitions, and runs the covenant test against terms extracted from that deal's loan agreement rather than from a global constant.

A single covenant-minimum argument with a policy default is a demo shortcut. I know, because that is what mine does: the gate fires correctly, against a number that in production would have been read out of a document, with a citation and a review path for when that extraction is ambiguous.

It also needs the test frequency and measurement period, because a trailing-twelve and an annualized-quarter test on the same property disagree routinely, and the cure rights, because a breach with a cure period is a different event from one without. The handbook lists debt yield, DSCR, LTV, LTC and minimum net worth or liquidity as the common covenants here, so there are five to model, not one.¹⁰

The ground moved, and not in the direction people assume

If you built a governance story for a lending system before 2025, you built it on two pillars. Inside twelve months one was replaced and the other was withdrawn outright, and the popular version of this story has the direction backwards.

The model risk pillar was replaced, and agentic AI was carved out of the replacement

On 17 April 2026 the Federal Reserve issued SR 26-2, which "supersedes and replaces SR letter 11-7, Guidance on Model Risk Management (issued April 4, 2011)" along with SR 21-8.¹ The OCC companion the same day, Bulletin 2026-13, rescinds OCC Bulletins 2011-12 and 2021-19, the Model Risk Management booklet of the Comptroller's Handbook, and, directly relevant here, OCC Bulletin 1997-24, "Credit Scoring Models: Examination Guidance."²

Fifteen years of doctrine, replaced in a day. Two properties of the replacement matter to anyone building with language models. First, scope. Footnote 3: "Generative AI and agentic AI models are novel and rapidly evolving. As such, they are not within the scope of this guidance." The same footnote adds that the principles do "apply to traditional statistical and quantitative models and non-generative, non-agentic AI models."¹ A request for information covering banks' use of generative and agentic AI is planned, but had not issued as of writing.²

Second, force. "This guidance does not set forth enforceable standards or prescriptive requirements; accordingly, non-compliance with this guidance will not result in supervisory criticism against a banking organization."¹ The guidance is also scoped by size: it is "expected to be most relevant to banking organizations with over $30 billion in total assets."¹

The adverse action pillar was withdrawn outright

The other pillar was the CFPB's pair of circulars on explaining an algorithmic denial: Circular 2022-03, on adverse action notification where credit decisions rest on complex algorithms, and Circular 2023-03, on adverse action notification and the proper use of sample forms. Both were withdrawn effective 12 May 2025.³

A practitioner's footnote, because this one will bite somebody. On the day I write this, the 2022-03 page is still live on consumerfinance.gov, still serving its original question and answer, with no withdrawal banner anywhere on it.⁴ A compliance engineer arriving by search cannot tell from the page that it no longer represents Bureau guidance. Check the withdrawn-guidance index, not the document.

The statute did not move at all

Here is the asymmetry the piece turns on. The guidance told you how to be defensible. It was never what made you liable.

15 U.S.C. 1691(d)(3): "A statement of reasons meets the requirements of this section only if it contains the specific reasons for the adverse action taken."⁵ Untouched.

12 CFR 1002.9(b)(2): the statement "must be specific and indicate the principal reason(s) for the adverse action," and "Statements that the adverse action was based on the creditor's internal standards or policies or that the applicant, joint applicant, or similar party failed to achieve a qualifying score on the creditor's credit scoring system are insufficient."⁷ Untouched.

The official commentary: reasons "must relate to and accurately describe the factors actually considered or scored by a creditor"; where a scoring system is used they must relate only to factors actually scored, and no factor that was a principal reason may be excluded. It is also explicit that disclosing the FCRA key factors which adversely affected a credit score does not satisfy the ECOA duty, so one denial can carry two distinct obligations.⁸ Untouched.

And the remedy survived too: actual damages, punitive damages up to $10,000 in an individual action or the lesser of $500,000 or 1 per centum of the creditor's net worth in a class action, with a five-year limitations period running from the occurrence of the violation.⁶

The practical consequence is that defensibility can no longer be outsourced to a checklist. I can find no current supervisory document describing what an adequate explanation of an agentic credit decision looks like, while the obligation to produce one is intact, carries a private right of action and runs for five years. Defensibility has to become a property of the system you build, which is an engineering problem before it is a legal one.

The seam, and what the new definition of "model" actually permits

The most load-bearing sentence in the new guidance is not in the AI footnote. It is the definition of "model."

Put that next to an architecture in which a language model extracts facts and deterministic code decides, and the consequence is direct. If DSCR, LTV and debt yield are computed by arithmetic, and the routing decision compares those results against named thresholds, then the component that made the decision is, by the agencies' own definition, not a model. The generative extractor upstream is out of scope too, for footnote 3's different reason, but it does not decide anything: it produces typed arguments a human can check against a page number in ten seconds.

This is not a loophole, and treating it as one is how you end up explaining yourself badly in a room where that is expensive. It is the correct response to where the risk sits. Splitting extraction from adjudication buys three things.

1. Reproducibility. The same inputs produce the same decision every time, with no temperature setting anywhere near the outcome.
2. Derivable reason codes. The reason a file routed as it did is a comparison between a named factor, its computed value and a stated threshold, which is already the shape an ECOA reason has to take.
3. A smaller model risk perimeter. The only component carrying model risk is the one whose output a human can verify against a source document, which is the cheap kind to control.

The counter-argument, which is a good one

The obvious objection is correct: the seam is only real if the thresholds themselves are not model-derived.

A 1.25x DSCR floor that a credit officer set from policy is a constant. A 1.25x DSCR floor that a gradient-boosted model tuned on twelve years of loss data is a model wearing a constant's clothes, and an examiner will say so, correctly. The deterministic layer's honesty depends entirely on the provenance of its numbers, and nothing about the surrounding code establishes that provenance.

So the threshold table needs the same treatment: each threshold carries its origin, whether a policy document, a committee minute or a fitted model, plus a version and an effective date. If it was fitted, that fitting is a model and belongs in the inventory with a validation record, however plain the code around it looks. The architecture moves model risk somewhere smaller and better lit. It does not evaporate it, and saying so is the difference between a defensible design and a clever one.

Why "declined per credit policy v4.1" is a void reason code

12 CFR 1002.9(b)(2) rules out two kinds of reason: the creditor's internal standards or policies, and failure to achieve a qualifying score.⁷ Those are the two things an automated decision system produces most naturally. "Declined per credit policy v4.1" is the first. "Score below cutoff" is the second. Both are insufficient, in the regulation's own word.

What the commentary requires instead is that the reasons "relate to and accurately describe the factors actually considered."⁸ So a compliant reason code has to carry the factor and its value, not the gate identifier.

A policy gate already computes everything a reason needs. This is what my engine emits when the coverage gate fires on the deal above.

{
  id: "C-21",
  name: "DSCR covenant floor",
  outcome: "escalate",
  detail: "DSCR 1.18x is below the 1.25x covenant floor - exception requires credit-officer sign-off.",
  basis: "Bank credit policy v4.1 (demo): minimum-DSCR covenant on the note"
}

Compare the alternative. A gradient-boosted underwriting model produces an attribution vector. To turn that into a statement of specific reasons, somebody has to argue that the top-ranked features are the principal reasons, that the attribution is stable enough that the same applicant gets the same explanation on a re-run, and that the feature names describe factors a human considered rather than engineered proxies. That argument is what Circular 2022-03 existed to pressure. The circular is gone; the requirement it interpreted is not. The argument still has to be made, with no circular currently in force saying what a winning version looks like.

None of which says do not use models. It says know which component produces the sentence you will have to defend, and make sure its output is something you can derive rather than interpret.

Commercial credit is a different notice regime, and the asymmetry is a design constraint

Most writing about explainability in lending is implicitly about consumer credit. Commercial is covered by ECOA too, but on different terms, and the differences change what you build.

Under 12 CFR 1002.9(a)(3), a business applicant with gross revenues of $1 million or less gets the consumer rules with modifications. An applicant above $1 million, plus trade credit and factoring, gets notice within a reasonable time, orally or in writing, and written reasons only on a written request made within 60 days of that notification.⁷

Retention matches. 12 CFR 1002.12 keeps consumer application records for 25 months. For a business applicant above $1 million in gross revenues, the creditor must retain records for at least 60 days, extending to 12 months only if the applicant asks in writing inside that window.⁹

Meanwhile the bulk reporting duty in the other direction just shrank. The section 1071 small business lending final rule of 1 May 2026 "removes the discretionary data points for application method, application recipient, denial reasons, pricing information, and number of workers," lowers the small business revenue threshold "from $5 million or less to $1 million or less," raises the origination threshold "from 100 to 1,000 covered credit transactions for each of two consecutive years," and sets a compliance date of 1 January 2028.¹²

Put the two together and a specific engineering failure appears, sharpest in the $1 million to $5 million revenue band. Dropping the small business definition to $1 million pushes those borrowers out of bulk reporting altogether, while leaving them above the $1 million line in 12 CFR 1002.9(a)(3)(ii), where denial reasons still have to be produced on written request up to 60 days after notification and the file itself need only be kept for 60 days.⁷⁹ What the rule makes you retain is the application, "any other written or recorded information used in evaluating the application," and a copy of the statement of specific reasons.⁹ Notice what is not on that list: the model version, the threshold table and the policy version that turned those inputs into that decision. So a creditor can be fully compliant on retention and still, on day 59, be unable to re-derive the reason it already gave, because the machinery moved even though the file did not.

An LTV breach is not a boolean, it is a draw on a capped budget

Here is the thing most demos get wrong, mine included. A gate that tests LTV against a 75% internal maximum returns pass or fail. But an internal limit is a choice, and what it sits under is a table rather than a single number: the interagency real estate lending standards set 65% for raw land, 75% for land development, 80% for commercial, multifamily and other nonresidential construction, and 85% for improved property, a row the OCC's own rendering of the table reads as improved commercial, multifamily and other nonresidential.¹¹¹⁰ Banks set their own limits, and those "should not exceed" the supervisory ones.¹¹ The 90% credit-enhancement expectation often quoted from that same table belongs to the owner-occupied one-to-four family row, which is the one row where no LTV limit is set at all. It is not an escape hatch on a commercial deal.

Exceeding a supervisory limit does not make a loan prohibited. It makes it a draw on an aggregate that "should not exceed 100 percent of total capital," within which loans on "commercial, agricultural, multifamily or other non-1-to-4 family residential properties should not exceed 30 percent of total capital," reported "at least quarterly to the institution's board of directors."¹¹ The OCC handbook adds that "it is prudent for the bank to consider aging of all exceptions with sufficient stratification to identify trends in volumes, loan officer, and types."¹⁰

Read that last clause with an agent in the loop: the stratification the examiner wants includes loan officer, and in an automated flow the loan officer is the agent. So an exception is not a per-run finding. It is a durable record needing the deal, the limit exceeded and by how much, the approving authority, the date opened, the capital it consumes when the limit exceeded is a supervisory one rather than an internal one, and the identity and version of the agent that originated it. A rising exception rate attributable to one agent version is exactly what an examiner will pull, and a system that cannot show that has automated origination without automating the control above it.

The audit trail, and what actually has to be in it

If reason codes must be produced at decision time and survive for years, the trace is the product. Three properties matter more than the storage choice.

• Append-only and tamper-evident. Not "we write to a table an administrator can update," which is what most implementations mean by immutable.
• Re-derivable by somebody who does not trust you. The checker recomputes the trace's integrity from the payloads themselves, without asking your service whether your service is honest.
• Sealing the inputs, not only the outputs. A trace that records the verdict but not the facts it ran on cannot answer the only question anyone asks: why this file and not that one.

The cheap version is a hash chain, and it really is cheap. In mine each entry is hash_n = sha256(seq | event | payload | prevHash) from a genesis of sixty-four zeros, with the exact payload returned to the client so the browser re-derives every hash with WebCrypto. The sealed events cover the case received, the plan, each tool invocation with its arguments and results, each gate finding, the route with the decider named, and the verdict.

One detail worth generalizing: seal a hash of the source document, not the document. The trace should prove which text was decided on without becoming a second copy of borrower financials in a system your retention policy never contemplated.

The harder property makes a trace falsifiable rather than merely present. A trace proves what happened, not that what happened is what the policy said should happen. For that you need committed cases with expected outcomes: adversarial files covering a covenant breach, a thin file with a required figure missing, and instructions injected into the case text, each carrying an expected route, re-run on every execution with expected and actual side by side. Change a threshold and the matching case visibly fails. That is the only way I know to make "the gates work" checkable by somebody who did not write them.

The failure modes worth designing against

• The model re-typing its own arithmetic. If a planner computes qualifying income then passes that figure into the next call as text, you have added a transcription step with no error bound. Derived arguments should be piped from the earlier result by the engine, never supplied by the model: in mine the argument spec carries a pipedFrom pointer and the engine prefers it over anything the planner offers.
• Abstention as a prompt instruction. "If you are not sure, say so" is a preference. A missing required fact should push onto a missing list, skip the computation, and fire a gate that routes to a human. Abstention has to be control flow, not politeness.
• Narration that can move the outcome. If the explanation is generated after the decision, recompute the route and overwrite it afterwards, so no phrasing can talk past a gate that already fired.
• Instructions arriving inside the case file. Borrower documents come from outside the bank. An instruction embedded in a rent roll has to be inert, which it is when the extractor's only output is typed arguments and the route is computed in code.
• Citing a dated regime. The governance crosswalk inside my own prototype listed SR 11-7 as the live model risk regime until writing this piece sent me to check it; it had been superseded five months earlier. Nothing flagged it, because a crosswalk is a list of names and every name on it was spelled correctly. It is a dated artifact and needs an owner and a review date like any other document.
• Borrowed thresholds presented as standards. The four-fifths rule that fair lending monitoring leans on is 29 CFR 1607.4(D), part of the Uniform Guidelines on Employee Selection Procedures: EEOC employment selection guidance, not a lending standard.¹³ It is a useful screen and a widely used convention, not a legal threshold for credit, and labelling it as one is the kind of small overclaim that costs you a technically literate reader. Same for the 0.10 and 0.25 population stability index bands, which no regulator I could find has set.
• Treating the policy layer as static. The federal interpretive layer thinned; the state layer did not. Colorado's SB 26-189, "Automated Decision-Making Technology," signed 14 May 2026, repeals and reenacts the state's earlier AI act with new requirements for automated decision-making in consequential decisions.¹⁴ Credit is one. So the policy layer has to be versioned, dated and queryable by jurisdiction: the thing most likely to change about your system in three years is not the maths.

The working version

I built the mechanism described here as an independent prototype on public rules, not as client work, largely to find out which parts of the argument survive contact with running code. Paste a commercial deal in and a language model extracts the facts into typed arguments while deterministic TypeScript computes DSCR, LTV and debt yield, runs the covenant and LTV gates and decides the route in code; with no model key configured a committed plan runs against the same engine, so the numbers are real either way. Its one committed adversarial case, a covenant breach, reports expected route against actual on every run, and the hash chain re-derives in your browser. Every simplification named above is still in there: NOI arrives as a given, the covenant floor is a constant, there is no exception register. Those are the honest edges, and where I would start building this for real.