Deterministic Document Parsing vs. Probabilistic AI

Deterministic vs. Probabilistic Document Parsing in Underwriting

Underwriting involves making sense of everything in the financing package: bank statements, tax returns, financial statements, sometimes years of them. Historically, processors and underwriters did this by hand, going line by line to build a complete picture before making a decision. Depending on the financing product and the complexity of the business, that review can take hours or days.

There are two primary methods to automate document data extraction: deterministic parsing or probabilistic AI.

• Deterministic parsing extracts a value because the document's structure defines where that value sits, following defined logic built around how a given document type is laid out. 
• Probabilistic AI, typically a large language model or similar pattern-based system, predicts a value because it resembles what usually appears in that position, based on patterns learned from the documents it was trained on.

Both methods can produce a number. Only one of them can tell you where that number came from. Run the same document through a deterministic system twice and you get the same output twice. Run it through a probabilistic system and you get its best guess, which can look correct without being correct.

For underwriting data feeding a DSCR calculation or a stacking check, that gap changes what the number means. A deterministic extraction traces back to the document itself. A probabilistic prediction traces back to a training distribution.

How MoneyThumb’s engine reads a document

Deterministic doesn’t mean matching a document against a stored template for that specific bank or statement format. For approximately 90% of our processing volume, MoneyThumb’s engine reads the PDF’s encoded content directly, including: the actual text objects, positions, and structure the file contains, and uses the relational positions of those elements (where a number sits relative to a label, column, a running total) to reconstruct the document’s layout. This process runs the same way regardless of whether the engine has seen that particular bank’s format before. 

Are there any exceptions?

Two document types are the exception:

• IRS tax forms: processed against the IRS’s published templates
• Application forms: processed against templates we build in-house

Everything else, bank statements in particular, don't depend on a template at all.

How each approach handles the same document

Where OCR and AI/LLM extraction introduce probability

Two different methods get lumped together under "AI parsing," and they carry different kinds of risk.

• OCR (optical character recognition) is required any time a document has no embedded text layer, meaning it's a scan or image-based PDF instead of a native PDF. OCR estimates which character a cluster of pixels most likely represents. That estimation step is unavoidable on image-based files and exists no matter whose pipeline runs it, MoneyThumb's included. It's a property of the file and often not a choice of method.
• AI/LLM extraction is a separate method that introduces probability even on documents that don't need it. In most cases, a multimodal LLM reading a PDF converts the page to an image first, runs OCR on that image, and feeds the resulting pixels and tokens into a model that generates a response. That means a clean, text-based statement - one MoneyThumb's engine would read outright - gets converted and re-derived probabilistically anyway once it enters an LLM-based pipeline. This adds several extra steps even when they’re not necessary.

Where probabilistic parsing can be risky

Errors in probabilistic system output can easily appear correct. Here are few examples how these false positives can cause downstream impacts in MCA and SMB underwriting:

• A misread deposit inflates apparent revenue. A model trained mostly on standard bank layouts misreads a subtotal on a credit union statement as a deposit, pushing calculated monthly revenue above what the business actually brings in.
• A recurring NSF fee reads as a routine withdrawal. Without a defined rule for identifying fee codes specific to that institution, the model classifies it as an ordinary transaction, masking a cash flow problem an underwriter needed to see.
• A second MCA position goes undetected. A model extrapolating from familiar statement formats misses a less common transaction description used by a smaller or regional funder, so a stacked position doesn't get flagged before funding.
• A factor rate or repayment schedule gets transposed. On a statement layout the model has seen infrequently, digits in adjacent columns get swapped, changing the effective cost of the deal without any indication that anything went wrong.

Where deterministic parsing closes the gap

The same scenarios play out differently against defined extraction logic:

• Balance reconciliation measures against a baseline. When a starting balance, transaction list, and ending balance don't reconcile, the system flags it immediately, whether that's a parsing issue or a sign the document itself was altered.
• New or uncommon layouts get parsed on structure, not guessed on resemblance. Because the engine reads relational positioning rather than matching against a stored format, a credit union or fintech statement it hasn't processed before still extracts correctly, without needing to have seen that exact layout first.
• Fee and transaction codes extract by defined category, not resemblance. A recurring NSF fee is identified because it matches a known code or pattern for that institution, not because it looks similar to other withdrawals.
• Every extracted field ties back to a specific location in the document. An underwriter reviewing a flagged transaction data will always see numbers directly sourced from the document.

The tradeoffs with deterministic parsing

Deterministic parsing isn't free of limitations. Here's where it's fair to push back, and what addresses each concern:

• It won't infer a value that isn't clearly present. This is by design. A missing or ambiguous field does not get filled with a best guess.
• Some document types will still depend on templates, and new template types take upfront work. IRS forms are processed against the IRS's own templates, and application forms against MoneyThumb's own. Building support for a new template type may take some initial work, but it becomes a permanent capability once complete. Bank statements make up the majority of underwriting documents and don't carry this limitation at all, since they're parsed structurally rather than matched to a template.
• A degraded or malformed document can still fail to resolve cleanly. A document with corrupted encoding or inconsistent structure may not parse with full confidence. This makes up an average of 2% across the millions of documents we process each month. When that happens, the engine can switch to OCR to complete the job instead of returning a partial or uncertain result. 

How does this work with Thumbprint?

The parsing layer that pulls transaction data out of a document (the numbers that PDF Insights customers use for cash flow analysis and reporting) applies the same extraction logic to the same document structure every time. That output doesn't shift unless it's to fix a reconciliation issue for that format moving forward.

ThumbPrint's fraud score works differently by design. Its inter-document model keeps learning from a growing population of verified statements, so a score on a given document can shift over time as MoneyThumb processes more documents from that institution. This creates a more accurate picture of the statement as the system's knowledge of an institution's real statement patterns grows, but does not change how the underlying transaction data gets extracted. The two systems solve different problems but only one of them needs to hold still.

Where MoneyThumb stands out from other tools

Many parsing tools that enter the SMB financing market lead with AI. MoneyThumb leads with deterministic parsing and leverages probability with scanned files where OCR is the only option. That ordering is deliberate. For underwriting data that feeds a funding decision, a number you can trace beats a number you have to trust.

Our pragmatism here is a differentiator, but it isn't the only one. MoneyThumb has parsed bank, credit union, and fintech-issued statements for over a decade. Our engine has encountered the full range of real-world document variation typically produced in the SMB financing industry, including the messy, adversarial, and one-off formats that trip up other tools without the same history behind them. A newer entrant may have a capable model, but there is no shortcut with exposure to a decade of processing volume.

• Deterministic-first by design, with probabilistic OCR used only as a fallback for image-based files, not as the default method for readable documents
• Structural parsing that handles new and uncommon layouts natively, with no dependency on bank or format templates, and no need to see a format before to extract correctly
• Long-tail depth from a decade of volume, across the credit union, fintech, and adversarial statement formats and edge cases most parsing tools haven't encountered at scale
• A document fraud signal that compounds with volume, since ThumbPrint's patented inter-document model gets sharper with every institution's documents it processes

Resources:

• ThumbPrint Core Concepts documentation
• PDF Insights
• https://www.moneythumb.com/blog/moneythumbs-thumbprint-secures-patent-for-fraud-detection-technology-in-document-authentication/
• https://www.moneythumb.com/blog/small-business-administration-sba-website-is-a-great-resource-for-lenders/
• https://www.moneythumb.com/blog/understanding-merchant-cash-advances-for-business/
• https://www.moneythumb.com/blog/lenders-make-instant-credit-decisions-using-thumbprint-from-moneythumb/