AI Agents in Loan Verification: From Days of Paperwork to Minutes

Loan verification is the part of lending nobody writes about. It sits between the application and the decision, it is done by verification agencies and bank back offices rather than by the people who set credit policy, and it runs on email, spreadsheets, phone calls, and field executives with a folder of forms. It is also where a large share of turnaround time goes, and where AI agents can do real work without touching the credit decision itself. This post is about how we designed for that in the Kowtha Loan Verification Suite, and what an earlier project for Cumberland River Financial Group taught us about doing it under pressure.

Where the time goes

Walk through a verification request the way it happens in most agencies today.

A bank's loan officer sends an email. It may have a structured attachment, or it may be a paragraph with the applicant's name, an address, a loan reference, and a request for residence and employment verification. Someone at the agency reads it and types the details into a tracking sheet or an internal system. A coordinator decides which field executive covers that area and calls or messages them with the details. The executive visits, fills in a paper form or a generic app, takes photos on a personal phone, and sends everything back over a messaging app at the end of the day. Someone at the office checks the submission, chases missing items, and types up a report in the format that particular bank requires, because every bank has its own template. The report goes back by email. At the end of the month, someone reconciles what was done against what was invoiced, and disputes follow.

Nothing in that chain is technically difficult. The delay is the sum of the handoffs: each one waits for a person, and each one re-keys data that already existed in a previous step. Errors enter at every re-keying, and the paper and messaging-app evidence is hard to audit when a bank questions a report months later.

What an agent can and cannot do here

It is worth being precise about the boundary, because the boundary is what makes a lending automation project acceptable to a bank's risk team.

An agent is good at reading unstructured input and turning it into structured records, routing work based on rules, checking a submission against a checklist, drafting a document from structured data in a required format, and matching records across systems. Those are the paperwork steps above, and they are where the turnaround time lives.

An agent should not replace the field visit, because the visit is the verification. It should not make the credit decision, because that belongs to the bank's policy and the bank's people. And it should not create a verification record from a request it did not read confidently, because a wrong record dispatched to the wrong address wastes a field visit and, worse, produces a report a bank may act on.

Designing with that boundary in mind produces a system where the agent removes the typing and the waiting, and the humans keep the judgment. That is the shape of the Kowtha suite.

The Kowtha Loan Verification Suite

The suite covers the loan verification lifecycle from intake to invoicing for banks and financial institutions, and it is built as four connected modules that share one set of records and one audit trail.

AI intake and automation

Incoming loan request emails are read by an NLP extraction layer that identifies the applicant, addresses, loan reference, requesting bank, and the verification types required, and creates a loan record automatically. Each extracted field carries a confidence score. Requests that clear the threshold with all mandatory fields present become records and enter the dispatch workflow. Requests that do not are queued for a verification officer, who sees the original email alongside the partially extracted fields and completes or corrects them. The record is created once, with a reference back to the source email, and every downstream step reads from it rather than re-keying.

The extraction target is a fixed schema, which is what keeps the agent honest. Here is the shape, simplified:

{
  "loan_ref": { "value": "K-2291", "confidence": 0.98 },
  "bank": { "value": "Example Bank", "confidence": 0.97 },
  "applicant_name": { "value": "A. Applicant", "confidence": 0.95 },
  "verification_types": {
    "value": ["residence", "employment"],
    "confidence": 0.91
  },
  "addresses": [
    { "type": "residence", "value": "...", "confidence": 0.88 }
  ],
  "escalate": false,
  "source_message_id": "<...>"
}

If a field is missing, the schema still validates, the confidence is zero, and the request escalates. There is no path by which a guessed field becomes a dispatched visit.

Mobile field verification

Field executives use a mobile application that gives them their assigned verifications, the standardized form for each verification type, and the ability to capture borrower data, upload documents, and take photos with a geotag and timestamp applied at capture. The application works offline, which matters because field work happens in places with poor connectivity, and syncs when a connection returns. Submissions are attached to the verification record with integrity checks, and once submitted they cannot be altered by the executive. Coordinators see executive activity and progress against SLA in the portal, which replaces the phone calls and gives accountability a data source.

Verification and reporting engine

The web portal is where the verification team validates what came back from the field. Rule-based validation workflows check each submission against the requirements of the verification type and the requesting bank: mandatory photos, address match, document completeness, and consistency between the request and what was found. Exceptions are flagged for a person to resolve. Once a verification passes validation, the engine generates the report in the requesting bank's own PDF format from the structured record, so the report is produced rather than typed, and the same data can be rendered for any bank's template without rework.

Automated billing and finance workflows

Every completed verification is a billable event with a known type, bank, and pricing model. Invoices are generated from the records, reconciliation matches invoiced work to completed work automatically, and exceptions surface as a list rather than as a month-end argument. Pricing models are configurable per bank, and the billing history is retained in a form that can be audited alongside the verification records it bills for.

Design decisions that mattered

Several decisions in the suite are worth calling out because they are the ones that made the bank risk conversations short.

Human review is a requirement, not a fallback. The intake agent's escalation path is a first-class part of the design, with its own queue, its own interface, and its own metrics. Framing it this way meant the risk team saw an agent with controls, not an agent with an exception handler.

Idempotent record creation. Banks resend emails, forward threads, and reply to old requests. The intake layer keys records on the source message and the loan reference so a resend updates rather than duplicates, which prevents duplicate dispatches and duplicate invoices.

Evidence integrity over evidence volume. The value of a geotagged, timestamped, immutable photo is that a bank can trust it months later. Building capture and integrity into the mobile application was more important than any amount of reporting polish.

Offline first. A field application that requires connectivity fails exactly where verification happens. Designing the sync model up front was cheaper than retrofitting it.

One audit trail. Intake, dispatch, field submission, validation, report, and invoice all reference the same record. When a bank queries a report, the full chain is visible in one place.

Compliance scoped early. The data involved is personal and financial, and the platform was designed with access controls, encryption, and retention rules from the first architecture review, following the approach our application delivery practice uses on every engagement.

An earlier lesson: the CRFG PPP platform

Before the Kowtha suite, we built a loan processing platform for Cumberland River Financial Group during the Paycheck Protection Program. The bank needed a system to take PPP applications from small and medium-sized businesses, process them, and submit them to the Small Business Administration, and it needed it during a period when the program rules were moving and demand was immediate.

The architecture was a Django backend and a React front end on AWS, with a PostgreSQL database, a modular design, and data encryption throughout. PII was anonymized in processing, document uploads went to secure S3 storage, and role-based access control kept each role to the functions it needed. DocuSign handled signatures, address validation ran through SmartyStreets, applicant communication went through Intercom, and the SBA API integration submitted applications directly, so the workflow ran end to end without a manual hand-carry between systems.

The lesson that carried into the Kowtha work was that speed and security were not in tension. Because encryption, anonymization, and access control were part of the first design, the platform could be delivered quickly and still stand up to the scrutiny a bank applies to a system handling applicant data. That is the same reason the Kowtha suite's compliance conversations were short: the controls were already in the diagram. Our financial services page covers both projects in the context of the sector.

What to measure

A lending automation project needs a business case built on evidence, and the evidence has to be collected from the first week of production. The measures we instrument in the suite:

• Turnaround time from request received to report delivered, per bank and per verification type
• Intake escalation rate, and the reasons, so extraction can be improved where it matters
• Re-keying errors caught in validation, compared with the manual baseline
• SLA adherence per field executive and per region
• Reconciliation exceptions per billing cycle
• Report rework requests from banks

None of these require a model to interpret. They are the numbers an agency owner already cares about, and they are what turns a pilot into a rollout.

Where to start

If you run a verification agency or a lending back office and are weighing an agent project, start with the intake step. It has the clearest boundary, the most obvious re-keying cost, and a natural escalation path. Instrument the measures above before you switch anything on, so the baseline is real. Then extend into reporting, where the same structured record can replace typed reports for every bank template you support. Field mobility and billing follow once the record is the source of truth.

We are happy to walk through the Kowtha design in more detail or review a design you already have. Contact us and we will start with the process, not the model.