Commercial Credit Agent Blueprint

Somewhere in every credit committee, a member taps a figure in the memo and asks the only question that matters: where did that number come from? In a good shop the officer can answer — the statement, the page, the line. In most shops the honest answer involves a spreadsheet someone built in March, a PDF that has been through two inboxes, and a pause that lasts a beat too long. The memo is the bank's memory of why it lent. When its figures cannot be walked back to the borrower's own documents, the memory is folklore.

This open blueprint, the Commercial Credit Agent, is built around that tap on the page. It takes a commercial loan application, spreads the borrower's financial statements into the bank's template, computes the ratios, tests the file against lending policy, and drafts the committee memo. One rule hangs over the whole design: the model never computes a number. Every figure in the file is either read from a borrower document with a pointer to its page and line, or computed in code from figures that were. The agent assembles and drafts. The credit officer and the committee decide — nothing in this system approves credit.

Every figure arrives with its address

An application opens with a checklist, and the checklist is not generic: it is generated from the facility type, so a term loan, a revolver and a construction facility each ask for their own documents on top of the base file, and every item cites the policy rule that required it. Documents land in storage with their hash recorded at intake, and every later read re-verifies the bytes against that hash.

Extraction is where most lending automation quietly goes wrong, so the contract here is blunt: a value comes out of a document carrying its document, its page and its line, or it does not come out at all. A batch with a value missing its provenance is rejected whole, in code. That sounds severe until you price the alternative — a spread with one unaccountable figure in it is a memo waiting for the committee member's tap.

Spreading without sleight of hand

Spreading is the unglamorous centre of credit work: three years of statements, in whatever shape the borrower's accountant produced them, mapped onto the bank's standard lines. The template here is data — a fixed taxonomy for the balance sheet, income statement and cash-flow statement — and every extracted value is mapped onto its line across all periods at once.

Two habits keep the spread honest. A statement line the taxonomy does not map is carried into the spread as a named unmapped entry, with its values and provenance, instead of being dropped or quietly folded into a line it does not belong to. And adjustments — the add-backs every credit officer argues for — are records, not edits: each names the line, the period, the amount, a coded reason and a written reason, the document that justifies it, and who proposed it. The unadjusted view is never touched; the adjusted view is derived from it. When a corrected statement is filed for a period, the spread rests on the new version and says so, and the superseded version stays retrievable. Nothing about a borrower's history gets silently rewritten.

The third answer: not computable

From the spread, a computation engine derives the measures a credit officer quotes — liquidity, leverage, coverage, profitability, cash flow, and the combined view across borrower and guarantors, with intercompany items eliminated as named, reasoned records rather than netted away. Money is decimal arithmetic throughout, and recomputing the same spread returns the same computation pack, byte for byte.

The discipline that matters most is what happens when a figure cannot be derived. It is recorded as not computable, naming the missing input. The sample borrower in the blueprint — a mid-market manufacturer seeking a term loan — filed statements with no cash-flow page, so its cash-flow measures say exactly that, naming depreciation and amortisation as the absent input. Nothing is zero-filled. Nothing is estimated. A gap in the file reads as a gap in the file.

Policy testing inherits the same honesty. Lending policy is a versioned pack of coded tests — leverage ceilings by borrower segment, minimum coverage, concentration against the bank's capital, document completeness, age limits on statements and appraisals — and each test returns pass, fail, or the third answer: not evaluable, because the figure it reads could not be computed or the document it ages is not on file. A coverage ratio the statements cannot support is never a silent pass. And the version discipline is strict: a file is judged under the one pack version pinned when it was evaluated, and its report stays on the record untouched. When the pack tightened its minimum coverage from 1.25 to 1.35, a borrower standing at exactly 1.30 failed the new pack and kept its passing report under the old one — because a policy change should never silently re-judge a credit already in flight.

A memo that can be refused

The memo draft is assembled from the file's artefacts — request, borrower overview, financial analysis, strengths, risks and mitigants, policy exceptions — with its header pinning the exact spread, computation pack and policy report it was drafted from. The recommendation section is a placeholder. That is deliberate: the memo states facts and policy outcomes, and the recommendation is the credit officer's to make.

Before a draft may be stored at all, a verifier walks every number in its text and tables and traces each one — to the computation pack, to a spread line, to a policy threshold, to a stated fact of the file. One figure that does not trace — altered by a cent, transposed, invented — and the memo is refused storage, with the offending figures named. The exceptions section is checked the same structural way: it must account for every non-pass outcome in the pinned policy report, in full, so an exception cannot be dropped or softened on the way into the memo. Whichever profile drafts the prose, the verifier decides whether the memo exists.

Past the draft, people take over in the open. The credit officer's gate and the committee's decision are recorded acts; an adverse decision carries coded reasons, the way adverse-action rules require. And the work continues after closing: covenants written into the loan are re-tested on schedule against fresh financials as they arrive, so a covenant is a living test on current numbers, not a clause checked once against the statements that happened to be in the file at approval.

What it will not do

It will not approve credit, price it, or soften a policy outcome, and its judgement aids stop where a bank's own substance begins. The statement reader it ships with is a reference extractor for the documents it generates; a real borrower's statements arrive in far more shapes than any one reader covers, and production extraction is integration work a deployment does with the bank's own document flow. The risk-rating scorecard is a coded stand-in for the bank's own model. What the blueprint does claim is narrower and, we think, more useful: that the chain from a borrower's page to a committee's figure can be kept unbroken, in code, at every step — so the tap on the memo always has an answer.

Work with us

If your lending team's analysts spend their days spreading statements and rebuilding figures that a committee then has to take on trust, that chain is buildable — provenance on every figure, policy as versioned code, a verifier between the draft and the file. Bring the problem through Trida AI's intake and we will scope what a credit agent inside your lending operation should, and should not, be allowed to touch.

Get the Code on GitHub: github.com/tridaai/blueprint-commercial-credit