Mortgage Closing Disclosure Processing Workflow

A Closing Disclosure follows a fixed, TRID-mandated layout, and that fixed layout fools a lot of teams, who end up thinking extraction is a solved problem. The form looks templated, so the assumption is that pulling fields off it should be a matter of mapping boxes to labels and moving on. The actual engineering work sits downstream of that: reconciling the CD against other documents, enforcing tolerance rules, and verifying compliance across dozens of fields that depend on one another. The document carries real weight in the loan process. It has to reach the borrower at least three business days before closing, and it has to match the terms agreed on earlier in the process, so a wrong field doesn't just sit there as a data error, it can force a re-disclosure, trigger a compliance violation, or delay funding. The cost of doing this by hand sets the baseline everyone is trying to beat: comparing a lender CD against a title CD across 50 to 60 line items takes 45 to 65 minutes per session, and most loans need 3 to 4 of those sessions. That's the standard an automated pipeline has to clear, and it's a higher bar than the form's clean layout suggests.

What the five CD pages contain

The CD isn't one kind of content wearing five pages of disguise. It mixes narrative loan terms, fee tables carrying different tolerance rules, projected payment schedules, cash-to-close math, and plain disclosure text, and each of those needs its own extraction approach rather than one general-purpose parser. Page 1 covers loan terms and projected payments: loan amount, interest rate, monthly principal and interest, and flags for prepayment penalties and balloon payments. These fields are structurally simple to pull, but they only mean something once you check them against the original Loan Estimate for tolerance compliance. Page 2 holds the closing cost detail, organized into lettered sections, each with its own TRID tolerance rule. Section A fees, like application fees, carry zero tolerance: the CD amount has to match the Loan Estimate exactly, and any overage gets absorbed by the lender. Category C fees work the opposite way: they can rise with no tolerance cap at all, as long as the original estimate was made in good faith and the borrower picked a provider off the lender's list, because once the borrower picks a provider off the lender's written list, a cumulative tolerance cap takes over instead, a structure laid out in Infrrd's CD balancing breakdown. Page 4 covers loan disclosures: escrow details, the assumption clause, the demand feature, late charge terms. These fields appear inconsistently between a lender's version of the CD and the title company's version, so the extraction task isn't just reading a value, it's detecting whether the field is even present. The lender CD and the title company CD are parallel documents covering the same transaction from different origination points, and before any comparison can happen, the extraction pipeline has to ingest, classify, and map fields on both of them.

The three-document comparison: LE, lender CD, title CD

None of the CD's fields mean anything in isolation. Their compliance meaning becomes clear only when the CD is read side by side with the Loan Estimate and the title company's settlement fee sheet, so a pipeline that treats the CD as a standalone document misses the actual point of extracting it. This comparison isn't a clean field-to-field match. The LE and the CD sometimes number their lines differently, title companies may organize fees differently than lenders, and the same fee may appear under different labels across documents, so before any numbers get compared, the system has to figure out which labels actually refer to the same fee. Infrrd's step-by-step description of its CD balancer lays out what that workflow actually requires. It starts with uploading all three documents and automatically recognizing which is the LE, which is the lender CD, and which is the title CD or settlement sheet. Before extraction starts, each document goes through preprocessing: correcting lighting, skew, cropping, and rotation. From there, extraction has to work section by section, preserving each fee line's tolerance classification as it comes off the page, so that the comparison step that follows can line up LE values, lender CD values, and title CD values for every item. That comparison has to run at the level of the section total, not the individual line: a single Section B fee can rise past its LE estimate without triggering a violation, as long as the Section B total across all its fees stays under the regulatory tolerance ceiling. Areal's description of an agentic workflow shows what happens once a discrepancy turns up: the system has to notify the title company, track the correction, update the loan origination system, and confirm the loan is ready to fund, so an extraction error at this stage doesn't stay contained to one field, it moves through the whole closing operation.

Where extraction breaks down on the CD in production

The places where CD extraction fails in production don't scatter at random. They cluster around a handful of structural properties of the document that a naive extraction approach simply doesn't account for. The first is the scanned or hybrid PDF: plenty of CDs arrive as image scans with no text layer at all, or as PDFs with a text layer that's incomplete or out of order. The right response is to check the text layer first, using a tool like PyMuPDF or pdfplumber, confirm it's actually complete, and only fall back to rasterizing the page when that check fails. The second is table row undercount. The CD's fee schedules run as multi-row tables, and research on table structure recognition (cited in the underlying research on this problem) found that these tools tend to miss the last row of a table crop when the content runs right up to the image's edge with little padding around it, with one tool, TATR, missing the final row in roughly 40% of PubTabNet samples. On a CD, a missed row isn't a cosmetic gap, it's a missed TRID line item. The third is fee label variance: the same fee is worded differently on the lender CD versus the title CD, so any system matching on exact text strings fails here, and the fix requires normalizing fee descriptions semantically before the numbers ever get compared. The fourth sits on page 4, where fields like the assumption clause, the demand feature, and the late charge amount appear inconsistently from one CD to the next. A missing field here has to be read as "not applicable," not as a failed extraction, because treating absence as an error poisons the compliance check that runs afterward. The fifth shows up on long, multi-document loan packages: when an entire package gets encoded and sent to a language model in one call, extraction quality drops on the later pages. A long package can run into tens of thousands of tokens, and pages deep in the stack come back measurably less accurate than pages near the front, so this hits CD fields buried late in a bundled package harder than most. Even the mortgage industry's own standardization effort has run into these same edge cases: the MISMO SMART Doc Version 1.02 Implementation Guide, which reached Final Status in July 2026, had to add new guidance for fields like late charge amounts and broker and loan originator identifiers, precisely because those fields have shown inconsistency across lender systems for years.

How the tiered fallback architecture addresses closing-document-specific extraction risk

A single model run uniformly across every CD that comes in will do fine on clean digital PDFs and fail in predictable ways on scanned pages, rotated scans, and table-heavy sections. That gap is the whole reason a tiered fallback pattern exists: no single tier handles every case well, so the pipeline has to route documents to the tier suited to their condition. Applied to CD processing, the pattern works in stages. Tier 0 checks the PDF's text layer before anything gets rasterized, and because CDs that come straight out of a lender's loan origination system as native digital PDFs usually have a complete text layer, they can move through extraction without OCR at all. Tier 1 runs a fast extraction model, and if a field comes back with confidence above 0.90, the system accepts it immediately, which covers the bulk of volume on clean CDs with high-confidence numeric fields. Documents that fall between 0.70 and 0.90 confidence get routed to a vision-language model instead, which is typically where scanned CDs and rotated title company fee sheets end up. At the top sits human escalation, reserved for fields whose cost of error exceeds the automation saving: zero-tolerance Section A fees and the finance charge on page 5 should have a lower escalation threshold than Section C fees. The queue system beneath the model tiers produces its own failure modes, and handling those matters just as much as choosing the right tier. A 2025 peer-reviewed production study found that a too-short initial visibility timeout let documents get re-delivered to other workers while the first worker was still processing them, producing duplicate results, and that raising the timeout to 300 seconds eliminated the re-delivery. In a CD balancing workflow, a duplicated fee line doesn't just waste compute, it produces a false tolerance violation that someone then has to chase down and explain.

Per-field confidence calibration and production safety

A confidence score only means something if it's calibrated. A field marked 0.95 should be correct about 95% of the time at that confidence level, and a score that doesn't track real accuracy gives false reassurance on exactly the fields that most need a human to look at them. A calibration study from June 2026 found that this varies by field type: numeric fields tend to be well-calibrated, while free-text fields run overconfident at high predicted probabilities. On a CD, the fee amount (numeric) and the fee description (free-text) sit on the same line, so a system can get the dollar figure right with well-calibrated confidence while being overconfident about the label used to match that fee back to the LE. Testing a vendor's claims here is straightforward in principle: pull a sample of extractions the system marked as high-confidence, check them by hand, and see whether the error rate is material. If it is, the confidence scores are miscalibrated, and any routing threshold built on them will send too few documents to human review. That threshold is a genuine trade-off, and patent filings in this space formalize it directly: a higher confidence threshold produces more accurate extraction but sends more documents to manual review, while a lower threshold moves more volume through automation at the cost of accuracy. Processing teams have to set that threshold on purpose, not take whatever a vendor ships as the default. On the CD specifically, the threshold should track the TRID tolerance structure from earlier: Section A's zero-tolerance fees call for a higher confidence bar and more human review than Section C fees, which carry no tolerance cap at all. Running one threshold across every field on the form isn't a safe default, it's a design mistake.

What TRID compliance validation requires beyond field extraction

You can pull the right fee values off the page, but that isn't the finish line. TRID compliance means you have to check those values against tolerance rules, timing requirements, and the Loan Estimate that came before them, and these are three distinct checks that extraction alone can't fold in. Section A enforcement applies a straightforward exact match: any extracted value that differs from the LE at all counts as a violation, with no tolerance case to be weighed. Section B works differently: it aggregates the extracted fee total from the CD and compares it against the extracted Section B total from the LE, flagging an increase only if it crosses the regulatory tolerance ceiling, so both documents' Section B fields need to be extracted correctly before this check can run at all. Section C needs no tolerance enforcement, but extraction still has to classify its fees correctly, so they don't get swept into a Section A or Section B check by mistake. The Federal Reserve has found that Closing Disclosure violations under Regulation Z rank among the most common compliance problems lenders run into, including failing to show the full finance charge or listing the wrong service provider, and a pipeline only catches errors like these if it checks for field presence and completeness, not just the values themselves. The cost of missing this becomes visible after closing, not before: catching a mismatch between the loan amount on the security instrument and the final CD after a loan has already gone to an investor can trigger a repurchase demand, and with 70% of post-close errors traced back to mismatched fees and missing data between the LE and CD, extraction accuracy on this document is a balance sheet risk for the lender, not just an operational inconvenience.