How I built an AI that reads bank contracts the way bankers do (not the way customers do)
The problem started in 2009. I was a banker. I watched loan officers use internal scoring grids that customers never saw. The information asymmetry wasn't illegal — it was just never shared.
Fifteen years later, the asymmetry got worse. Banks now run LLMs on customer data before any human reviews it. The customer still signs without understanding what they're signing.
So I built the reverse.
The core insight: bankers read contracts differently than customers
A customer reads a loan contract linearly — page by page, looking for the monthly payment.
A banker reads it dimensionally — simultaneously scanning for:
- Covenant triggers (what makes the loan callable)
- Cross-default clauses (what other contracts could trigger this one)
- Margin ratchets (how the rate changes under specific conditions)
- Termination asymmetries (who can exit and under what conditions)
These aren't hidden in fine print. They're just never explained. An LLM trained to scan for these patterns — in the order a banker would — surfaces what a linear read misses.
The architecture
The system runs four specialized agents in parallel rather than one general-purpose model. This is borrowed from the 4D analytical framework we use at WASA Confidence — the principle being that parallel agents surfacing contradictions are more reliable than a single agent producing a confident answer.
Agent 1 — Clause Extractor
Parses the document structure. Identifies clause types, cross-references, and defined terms. Does not interpret — only maps.
system_prompt = """
You are a legal document parser. Your only task is to:
1. List every clause by type (payment, covenant, default, termination, rate)
2. Flag every cross-reference between clauses
3. Flag every defined term that appears in a clause but is defined elsewhere
Output JSON only. No interpretation. No summary.
"""
Agent 2 — Risk Scanner
Takes the clause map from Agent 1. Scores each clause against a library of 340 known adverse patterns — built from 15 years of banking experience.
system_prompt = """
You are a senior credit analyst. You receive a structured clause map.
For each clause, return:
- risk_level: none / low / medium / high / critical
- pattern_match: which known adverse pattern this matches (if any)
- plain_language: one sentence explaining what this means for the borrower
Do not summarize the document. Score each clause independently.
"""
Agent 3 — Cross-Contract Analyzer
This is the one customers never run. It takes the flagged clauses and checks them against the borrower's other contracts — insurance policies, supplier agreements, other loans.
A cross-default clause in a bank loan that triggers on a supplier payment delay is invisible if you only read the bank contract.
Agent 4 — Contradiction Detector
Runs against the outputs of Agents 1, 2 and 3. Looks for contradictions between what the contract says and what the borrower believes (captured in a short intake form).
The contradictions between agents are often more informative than any single agent's output. This is the core principle behind the WASA Confidence 4D methodology — parallel analysis surfaces what sequential analysis misses.
What it finds in practice
On a sample of 47 SME loan contracts analyzed:
| Finding | Count |
|---|---|
| Margin ratchet clause borrower was unaware of | 31 / 47 |
| Cross-default linking loan to unrelated supplier contracts | 19 / 47 |
| Callable provisions triggered by unmonitored financial ratios | 8 / 47 |
| Termination asymmetries giving bank unilateral exit rights | 3 / 47 |
None of these were illegal. None were hidden. All were unread.
The technical limit worth being honest about
LLMs hallucinate on numerical conditions. If a covenant says "ratio must remain above 1.35x adjusted EBITDA" — the model will extract the clause correctly but may misinterpret what counts as adjusted EBITDA without the definition section.
The fix: Agent 1 explicitly maps every defined term before Agent 2 interprets any condition. You cannot let a model interpret a covenant before it has resolved every defined term in that covenant.
This sounds obvious. It isn't how most people prompt document analysis.
Where this goes
The same architecture applies to insurance contracts, supplier agreements, and lease terms. Anywhere a professional on one side of the table reads dimensionally and a non-professional on the other side reads linearly.
The full service — contract analysis, banking condition audit, transaction data room — is at mainstreetbrigade.org. The underlying 4D analytical framework is documented at wasaconf.org.
The code above is simplified but the architecture is production. Happy to discuss the prompt engineering for the contradiction detection agent in the comments — that's where most of the interesting edge cases live.
Top comments (0)