Mortgage and lending document extraction

The packet problem

Borrowers do not send documents one at a time. They scan two months of statements, three pay stubs and last year's W-2 into one file and upload it. docRefinery's segmentation separates a long file into the documents it contains and recognises each for what it is. A processor who disagrees with a document's type corrects it in the classification review queue, and the correction is kept on the run. The rest of the packet goes on to field extraction. Long files are the normal case here, not an exception: a thick packet goes in the same way as a single payslip.

What underwriting needs from each document in the file

Payslips and bank statements are in the 20-type catalogue; the bank statement page covers its fields and transaction tables in depth. W-2s, verifications of employment and Closing Disclosures are set up as a workflow or a custom type, trained at no charge.

The applicant changes, the payroll template does not

The applicant changes; the layout does not. Most pay stubs come from a small number of payroll providers, and each prints the same template for every employer it serves. A bank's statement looks the same every month for every customer. Some documents are fixed by regulation: employers report wages to the IRS on Form W-2, and the Closing Disclosure follows the content and model form (H-25) set out in Regulation Z. So a lender sees the same few hundred layouts across thousands of borrowers. Each is learned once and remembered after that.

Bank statements and transaction tables

Asset verification depends on tables, not single fields. docRefinery returns a statement's transactions as rows, across every page of the statement, and the Excel export puts each table on its own sheet. Your underwriters can then work out average balances, large deposits or recurring income in their own model. docRefinery does not calculate qualifying income or make credit decisions. It hands over the numbers as printed, with citations.

What a loan file gets beyond the split

Underwriting stays with your processors

Underwriting stays with people. You set confidence thresholds per field, so gross pay and closing balance can demand more than an address line. Anything below its threshold waits in the extraction review queue, with the source page beside it and the value's location highlighted. Workflow rules add checks that run on every document, such as net pay being less than gross pay or a statement period ending after it starts, and a failed rule flags the run. A field the document does not contain, like a missing year-to-date figure, comes back null instead of a guess.

Getting fields into the loan file

A whole packet can go in as one submission, and the result comes back split by document; the quickstart has the calls. Because every document shares one format under your own field names, the mapping into a loan file is done once rather than per form. There is no loan origination system connector or webhook today, so your code writes the JSON, or a processor exports it; webhooks and integrations are in design on the roadmap. Borrower income and account data rarely should leave your network, which is why Enterprise plans offer private VPC and fully air-gapped on-premises deployment, on models that run inside it.

Lenders who will not get much from it

• You need an income calculation or decisioning engine. docRefinery extracts; it does not underwrite.
• You need altered pay stubs or statements detected. Forgery and fraud detection is not offered; it is research on the roadmap.
• Your asset data already comes straight from banks as structured account data, so statements are rare.
• Most of your packets are handwritten or one-of-a-kind documents with no repeating layout.