How I Would Build an SME Lending System That Never Rebuilds the Same File Twice

Direct Answer

An SME lending system that never rebuilds the same file twice separates three things the current process fuses into one document pile: verified financial facts (revenue, tax standing, ownership, existing debt, each tied to a source and a date), the interpretation run on those facts (ratios, trends, sector comparison), and each lender’s underwriting policy (risk appetite, pricing, personal guarantees). Only the policy layer is supposed to differ between banks. Today all three get rebuilt every time.

Key Takeaways

• A company applying to three banks assembles substantially the same file three times, and none of that work is reusable, not even by the company that produced it.
• The redundancy is not laziness. Anti-money-laundering rules require every regulated lender to run its own customer due diligence, so no bank can simply inherit another bank’s file.
• The reusable object is the company’s verified financial identity, not the loan application: facts, sourced and dated, that any counterparty could consume.
• Open banking already lets a business share live transaction data with more than one lender through an API. It does not yet cover tax status, ownership, or existing debt.
• The bottleneck an AI-native system should own is fact collection and provenance, not underwriting judgment: that stays with the bank.

What problem does this system actually own?

A small company shopping for financing does not have one loan application. It has the same underwriting picture, assembled from scratch, once per bank it approaches. Financial statements, a tax clearance certificate, twelve months of bank statements, proof of ownership, a description of what the loan is for, the list barely changes from Bank A to Bank B to Bank C. What changes is the portal it gets uploaded to, and the analyst who asks a slightly different follow-up question about the same numbers.

The system I would build does not touch underwriting. A bank’s risk appetite, its pricing, its comfort with a given sector: that is genuinely proprietary, and it should stay that way. What the system owns is narrower and less glamorous: it collects the facts once, keeps them current, and lets the company decide who gets to see which slice of them.

That is a coordination problem wearing a credit problem’s clothes. The company holds the facts. Three different banks each want the same facts, verified their own way, sitting in three different systems that never talk to each other. Nobody owns the version that would let a second bank trust the first bank’s work, so nobody builds it, and the company keeps re-typing its own tax number into a fourth portal.

The existing workflow I would map first

company → assembles file → bank A analyst → questions → more documents → decision
        → assembles file → bank B analyst → questions → more documents → decision
        → assembles file → bank C analyst → questions → more documents → decision

Every pass through that loop repeats the same categories of work:

1. Identity and ownership: who owns the company, who can sign for it, whether anyone on the cap table shows up on a sanctions or PEP list.
2. Tax and regulatory standing: is the company current on its filings, does it have outstanding liabilities with the tax authority.
3. Financial performance: revenue, margins, existing debt, cash flow over the recent trading history.
4. Transaction history: the actual bank statements a lender reads to sanity-check the numbers on the financial statements.
5. Use of funds and business context: why the loan exists, and what the company will do with it.

Before assuming this can be automated away, it is worth asking why each bank insists on doing its own version of steps 1 through 4. The honest answer is regulatory, not administrative. The Financial Action Task Force’s Recommendation 10 requires a regulated institution to identify and verify its own customers and their beneficial owners before entering a business relationship, rather than relying on another institution’s prior check. Every bank is independently examined on its own file, so every bank builds its own file. That is a real constraint, and any AI-native design has to work with it, not pretend it away.

Step 5, by contrast, is not a regulatory requirement at all. It is a narrative a loan officer wants to read, built from facts the company already stated somewhere in steps 1 through 4.

How the system would run

Separate the pile into three layers, because only one of them is supposed to be rebuilt at every bank.

The company’s verified financial identity is built once, from primary sources: a feed from its accounting system, a company-registry lookup for ownership and filings, a tax-authority extract for compliance status, and open-banking-consented access to transaction data. Each fact carries where it came from and when it was last confirmed, not just a number.

Under the EU’s revised Payment Services Directive, PSD2, a business can already authorise a bank or another regulated provider to read its transaction data through a secured API, on the basis of its own consent, instead of exporting statements and re-uploading them by hand. That piece of infrastructure exists and works today; it just stops at transaction data. The system I am describing extends the same idea (sourced, time-stamped, consent-scoped access) to the other fact categories a lender needs: ownership, tax standing, existing liabilities.

When the company applies to a second or third bank, it grants that bank scoped, time-boxed access to the current facts instead of assembling a new file. The bank’s own systems compute the interpretation layer from those facts, the ratios and trend lines it cares about, and apply its own policy on top. The upload portal disappears. The re-typed tax number disappears. The underwriting decision itself does not disappear, and it should not.

I made a version of this same facts-versus-interpretation split when I looked at how a CE marking system would keep a product’s technical file alive instead of reassembled per audit, and again in how a property due diligence system would gather registry records once for a professional to sign. The pattern holds here for the same reason it holds there: the facts are cheap to keep current once someone owns that job, and expensive only because right now nobody does.

What stays under human control?

The credit decision stays with the bank’s licensed credit function, in full. Nothing about a shared facts layer changes who is allowed to approve a loan, price it, or attach conditions to it: that is the policy layer, and it is supposed to stay proprietary and human.

Verifying beneficial ownership against sanctions and politically-exposed-person lists remains a regulated compliance function. It does not disappear because the facts are better organised; it runs against fresher, sourced data instead of a re-typed PDF, which is a narrower claim than “AI does compliance.”

Consent stays explicit and scoped, not blanket. The UK’s Financial Conduct Authority frames open banking as a regulated way for a customer or business to share account data with an authorised third party, on the basis of explicit consent, rather than handing that party its banking login: the company decides what a given bank sees and for how long, and that decision does not get automated away either. A facts layer that shares everything with everyone by default is not a lending system; it is a data leak with a pitch deck.

This is a designed model, not a system I have built. It stays a model until someone who actually underwrites SME loans for a living tells me where the regulatory or commercial reality breaks it.

When this is the wrong build

If a company borrows from one bank for its entire life and never shops around or refinances, the coordination cost never compounds. There is nothing to reuse, because there is only one version of the file being built, and building a shared facts object for a single relationship is overhead with no counterparty to pay it back.

It also fails where a regulator requires the bank to obtain original source documents directly, with no tolerance for a third-party-attested summary, however well sourced. In that case the system still helps, it automates the retrieval and keeps the facts current, but it does not eliminate the requirement itself, and claiming otherwise would be the kind of efficiency claim that does not survive contact with an actual compliance officer.

And it is the wrong build for anyone who reads this as “sell banks a KYC shortcut.” The commercial and regulatory question of who is trusted to hold a company’s verified facts, and under what liability, is unresolved. That question has to get answered by researching how bank compliance teams actually think about third-party attestation, not by designing around it.

How this connects to the engagement

This teardown follows the same split I used on the freight booking system that hides the coordination layer under a button and the public tender qualification system built around a company’s own capability record: find the layer that is genuinely proprietary, and stop rebuilding everything else around it.

If a version of this file-rebuilding pattern already exists in your company as PDFs and portals, describe the bottleneck. If you only want the next teardown, the newsletter is enough.

Summary

The SME loan file gets rebuilt at every bank because each institution owns its own regulatory exposure, not because the underlying facts changed. Splitting facts, interpretation, and policy makes that visible: only the third layer is supposed to differ between lenders, and today all three get rebuilt anyway. A system that collects the facts once, keeps them dated and sourced, and lets the company grant scoped access per bank removes the busywork without touching the part that should stay a bank’s own judgment call.