Rebuilding loan origination as tools that never touch a server
Credit Process Rebuild: nine browser tools that carry a loan request to the credit committee without customer data ever reaching a server. I led it as Credit Analyst & AI Implementation Lead, embedded with the credit team.
Ongoing Outcomes not yet measured are marked Pending Results.
Where this stands today
-
9 tools shipped
Browser tools running with no server, no database and no network call of any kind. -
3,923 automated checks
On the approval-presentation tool alone, none of them failing. -
6 defects
Found by review in a single change, while every one of those checks still passed.
The Situation
When a lender submits a request for a new loan, a renewal or a modification, an analyst turns it into the approval presentation, the document the credit committee decides from. Everything in between ran through a legacy Excel system: a chain of spreadsheets on a shared drive. None of it was written down, so one concept could carry two definitions in one workbook and nothing would notice.
The Local-Only Constraint came before any design: no customer data reaches a cloud service, and no tool requires a server. I treat it as the starting point. The reasoning behind it is a threat model, an account of what an attacker could reach, and not an IT preference.
Exhibit 1 The constraint is about concentration, not connectivity
Compromise one machine, then switch to a central server and compromise that.
View the data
| Machine compromised | Local-only (today) | With a central server |
|---|---|---|
| Analyst 1 workstation | 8 | 8 |
| Analyst 2 workstation | 8 | 8 |
| Analyst 3 workstation | 8 | 8 |
| Analyst 4 workstation | 8 | 8 |
| Analyst 5 workstation | 8 | 8 |
| Analyst 6 workstation | 8 | 8 |
| Central server | No server | 48 |
Why the constraint rules out a server
The case for a server is convenience, and its cost is that it puts every file in one place. A compromised workstation yields only what that analyst could already open from the shared drive. A compromised server yields every customer. Its service account has to read all of them, so it bypasses the shared drive’s permissions by design.
A server would also turn a document on the shared drive into a formal internal service. At a regulated institution that means risk assessment, sign-off and examiner scrutiny. Three conditions would reverse the decision: outside access, routine editing of one file by several people at once, or access control finer than the shared drive allows. None is true today.
What I Did
I started with a current-state assessment of credit origination. I mapped where it broke down across intake, documentation and risk presentation, then laid out a phased delivery roadmap. Alongside it I do standard analyst work, assessing credit risk and spreading financials. Spreads lay a borrower’s statements out year by year in one standard format.
I’m rebuilding origination as nine browser tools. Each is a single file opened from the shared drive. No server, no database, no network. Together they cover the path from the lender’s request to the committee: intake, importing the spreads, reading tax returns, and building the approval presentation. Keeping data local is the main security control, so it is not left to memory. An automated check blocks any release in which a shipped file makes a network call or loads anything from outside.
Two pieces of the rebuild are process design, and the first is the Three-Stage Review. The approval presentation used to be produced by doing three things at once: filling in the figures, working out why they look the way they do, and checking the result. Every question the analyst could not answer stopped the analysis for a call to the lender who wrote the deal. The Three-Stage Review separates the three: fill the figures, analyze the why, then review. Questions only the lender can answer are saved up and asked in one call at the end.
Exhibit 2 Same file, same five questions, one phone call instead of five
Play one file through each process.
View the data
| Part of the file | Kind of work | Question for the lender | Before: interleaved | After: three stages |
|---|---|---|---|---|
| Part A | Fill the figures | None | 1 | 1 |
| Part A | Analyze the why | 1 | 2 | 5 |
| Part A | Review | 2 | 4 | 9 |
| Part B | Fill the figures | None | 3 | 2 |
| Part B | Analyze the why | None | 5 | 6 |
| Part B | Review | None | 8 | 10 |
| Part C | Fill the figures | None | 6 | 3 |
| Part C | Analyze the why | 3 | 7 | 7 |
| Part C | Review | 5 | 11 | 11 |
| Part D | Fill the figures | 4 | 9 | 4 |
| Part D | Analyze the why | None | 10 | 8 |
| Part D | Review | None | 12 | 12 |
How lender questions are batched, and why
Each lender question is marked where it arises, so none is lost before the call.
The cost being cut is the lender’s time, which is the scarcer resource. A change that saves the analyst an hour but costs the lender two is a net loss.
The second is a rule built into the tax-document tool. The tool reads a business tax return and produces an income statement for that customer, with debt-service coverage: the cash available to pay debt, divided by the debt payments due. The rule is that in a credit file a wrong number costs more than a missing one. A missing number is visibly missing. A wrong one is what everybody works from.
So the tool refuses a scanned, image-only return (a picture of each page, with no text to read) and says why, instead of guessing at it. A line whose description is scrambled is held for review. The reading step sits behind a pluggable interface, so a vendor-approved method can drop in later.
Exhibit 3 Three returns in, three different answers out
Choose a document to hand the tool.
View the data
| Line | Electronically filed return | Scanned, image-only return | Export with a scrambled line |
|---|---|---|---|
| What the tool finds | Text layer present | No text layer | One description unreadable |
| Answer | Extracted | Refused, by name | Extracted, one line held |
| Gross receipts | $412,300 | Not read | $412,300 |
| Cost of goods sold | −$171,900 | Not read | −$171,900 |
| Repairs and maintenance | −$18,450 | Not read | Line 19 (description unreadable): $18,450, held for review |
| Depreciation (added back) | +$22,100 | Not read | +$22,100 |
| Cash available for debt service | $244,050 | Not computed | Pending |
| Debt-service coverage | 1.38× | Not computed | Not computed |
What the tool does with a return it cannot read
The refusal names the problem and points the analyst to the route that works. Character recognition could turn the image into numbers, but they would only look like figures. A scrambled line keeps its amount, flagged for review, and is never attached to the nearest plausible label.
The current stage is the AI Integration Phase. Its first piece is a prototype policy assistant: analysts ask about the bank’s credit policy in plain language. It answers 90% of queries directly, and on the rest it identifies the correct policy section every time. It is pending compliance review.
What Changed
Request completion has gone from days to hours. Roughly 90% of the repeatable work is now automated, so analysts spend their time on judgment calls.
Nine tools have shipped. 3,923 automated checks cover the approval-presentation tool alone, and none fail. A second program, the fault injector, plants the faults those checks exist to catch and confirms each check fails. Nine architecture decisions are written down, each with the alternative it was chosen over.
Pending Results Lender callbacks per file and the rate of corrected figures in a finished approval presentation have no before-and-after measurement I would stand behind. They stay labeled, not estimated, until there are numbers.
What I Learned
A test suite that passes tells you the tests passed and nothing else. I learned that from one change to the spreads import. It generalized the import so a new kind of financial tab could reuse the code the existing tabs used. It worked, and every check passed. A code review of that same change still found six defects. Two of them would have corrupted figures on their way into a credit decision.
Exhibit 4 3,923 checks passing, and six defects none of them could see
Each square is one automated check on the approval-presentation tool.
View the data
| Defect | Would reach figures | Assertions failing on it | What review found |
|---|---|---|---|
| Sheet-type check read the whole sheet, not just the header rows | Yes | 0 of 3,923 | A block of round four-figure expense amounts looks to it like a row of years, so two properties’ figures would land under one year, one silently overwriting the other. |
| Data migration checked its copy by comparing the data with itself | Yes | 0 of 3,923 | A comparison that could not fail was the only safeguard before deleting the analyst’s hand-entered grid. |
| A refusal with no place on screen to show it | No | 0 of 3,923 | The tool declined, and the analyst would never have seen why. |
| A rule that had quietly stopped being true for one sheet type | No | 0 of 3,923 | The rule still read correctly, but the condition underneath it had changed meaning. |
| A condition rewritten into a form that read the same | No | 0 of 3,923 | It changed behavior while appearing only to fix a fifth case. |
| Three messages to the analyst showing an internal code | No | 0 of 3,923 | An internal code appeared where the analyst expected a name. |
The two that would have reached real figures
The check that decides what kind of sheet the tool is looking at read the whole sheet instead of just the header rows. To it, a block of round four-figure expense amounts looks like a row of years. A real sheet would have been classified wrongly and handed to a parser that sorts columns by year. Two properties’ figures would then land under one year, one silently overwriting the other. The survivor would merge into that company’s real multi-year trend.
The second was in the data migration, which moves old data into the new format. Before deleting the original, it checked the copy by comparing the data with itself. That comparison could not fail, and it was the only safeguard before the analyst’s hand-entered grid was deleted.
What matters more than the six: the checks, the fault injector and I were all satisfied. Reading the change as prose was the only thing left that caught them. I write the tests and I still need the review.
Where Else This Applies
Learning why a constraint exists before designing around it. Healthcare, legal and defense work runs under rules that outsiders read as obstruction. Often the rule protects something real. Knowing which is the difference between negotiating a constraint and building within it.
Batching questions for the person whose time is scarce. Any workflow where one role waits on another’s answers has this problem. Judge a redesign by total interruptions across everyone involved, not by hours saved for whoever designed it.
The refusal rule. Any process that turns documents such as claims, invoices, applications and filings into figures somebody decides from must choose between producing a number and admitting it cannot. A system that guesses reads exactly like one that knows, until someone checks an output that has already been acted on.