Mortgage Condition Clearing Automation: What an AI Agent Clears, What the Processor Keeps

Which mortgage conditions can AI clear automatically?

An underwriting condition is an item the underwriting decision says must be satisfied before a loan can close or fund, whether it comes from a Desktop Underwriter (DU) finding, the underwriter, or investor and agency guidelines — labeled prior-to-document (PTD) or prior-to-funding (PTF), depending on timing. Some conditions ask for a document that already has a standard form: a pay stub, a bank statement, a verification of employment. Others ask a person to explain something a system can't judge, such as why an inquiry appears on a credit report.

The conditions a workflow can automate well are the ones where the acceptable evidence is already written down in checkable terms — a date window, a coverage period, a required field — in the lender's own stipulation language, not left to judgment. Fannie Mae's Selling Guide is one place such documentation standards are published: B3-3.2-01 on employment and income (published March 4, 2026) ^[1], and B3-4.2-01 on deposits and assets (published May 4, 2022) ^[2]. A system can check those parameters without guessing what "recent enough" means.

• Auto-draft — the evidence document has a standard form and the match is objective: employment and income verification, asset and reserves verification, hazard-insurance binders.
• Assist — the match needs interpretation first: self-employed income from tax returns and profit-and-loss statements, gift-fund documentation, title and vesting names across documents.
• Human-only — the condition asks for judgment a system can't make: a credit explanation letter, an appraisal condition tied to repair completion, anything suggesting a document has been altered.

The condition taxonomy matrix

The table below sets out eight common condition types against the evidence document that clears them, how automatable the match is, a suggested reviewer role, and the failure mode to guard against. Use it as a starting checklist for scoping a pilot, not as a complete list of every condition an investor's or agency's guidelines can generate.

Auto-draft means the system proposes the condition as satisfied with the matching evidence attached, ready for a one-click confirmation — not that it clears the condition by itself. Assist means the system narrows the work to what still needs a read: the specific figure, name, or date to check. Human-only means the system's best contribution is assembling the file cleanly; the call itself stays with a person.

Who signs off when an AI agent marks a condition cleared?

The system drafts; a named person confirms. That split is the lender's own operating choice, not a constraint AI imposes. Some lenders let a processor confirm auto-draft-level conditions and reserve everything else for an underwriter; others route every condition through the underwriter regardless of automation level. Either way, the loan origination system should record who confirmed each condition, when, and what evidence they saw, the same as for any other underwriting decision — in Encompass, for example, the documents themselves sit in the loan's eFolder.

Credit decisions and condition sign-off stay with the underwriter or processor throughout the workflow described here. An agent that proposes a clear-or-not-clear call without a named person's confirmation attached to it isn't the scoped pilot this article describes; it's a different, higher-risk project.

How does an AI agent read condition text and match it to documents?

The DU Underwriting Findings report lists certain steps the lender needs to complete ^[3], and the underwriter or processor adds conditions of their own to the stipulation list. Matching each condition to the right document in the file, not just the right document type, is the harder half of the problem.

1. 01
   Parse the condition

   Read the condition text and classify what it's asking for: document type, date window, and any named party.

2. 02
   Classify the upload

   Identify what type of document the borrower or broker actually uploaded, independent of which condition it was attached to.

3. 03
   Extract the relevant fields

   Pull the fields the condition depends on — dates, amounts, names, employer — each linked to where it appears on the page.

4. 04
   Compare against the condition's parameters

   Check the extracted fields against what the condition specifies: is the document recent enough, does it cover the required period, does the name match the file.

5. 05
   Propose or flag

   Where every parameter matches, propose the condition as satisfied with the evidence attached. Where one doesn't, flag the specific mismatch instead of a generic "needs review."

This matching logic has to run against whatever system holds the loan file. ICE Mortgage Technology, for instance, publishes Encompass Developer Connect, giving lenders and vendors "full access to open APIs, interactive documentation, testing playgrounds, and developer resources" for the platform ^[4]. Whether those APIs expose a loan's conditions for reading and writing back a proposed clear is something to confirm in ICE's developer documentation and with your IT team — a scope decision for the lender, not a default here.

What happens when a borrower uploads the wrong document?

Design for mismatches as a routine case, not an exception: a prior month's statement, the wrong pay period, or a document meant for the other applicant on a joint loan are all plausible uploads. The system's job is to say specifically what's wrong, not just that the condition remains open.

• Route the mismatch to the processor with the specific reason attached, not just the original condition text repeated back.
• Send the borrower a specific re-request naming what's missing or wrong, rather than the same generic checklist item.
• Keep the original, wrong upload in the file rather than discarding it; it's part of the record if the same condition gets flagged again.
• Escalate a condition that's been re-flagged more than once or twice to a person for a closer look, instead of looping the same automated request.

Where to start: a first scoped workflow

A first pilot works best scoped to one or two auto-draft-level condition types on one loan product, not the full stipulation list on day one. The steps below describe a method; there's no published figure here for how long a pilot should run or how much time it saves.

1. 01
   Pick the condition types

   Start with auto-draft-level types from the matrix above. Income/employment and asset verification are good first candidates, since the evidence format and the check are both already standardized.

2. 02
   Write the match rules down

   Turn your existing stipulation language into explicit parameters: document type, date window, named parties, required fields. A rule that isn't written down precisely can't be checked precisely either.

3. 03
   Build the exception path first

   Design where a mismatch goes, what the processor sees, and what the borrower is asked for, before building the matching logic itself.

4. 04
   Run a shadow period

   Let the system propose clears on live files without acting on them, and compare its proposals against what the processor actually decided.

5. 05
   Expand deliberately

   Add condition types one at a time, using the mismatch and false-clear rates from the shadow period to decide whether a type is ready, assisted, or still human-only.

When this doesn't apply

• Your condition volume is low enough that a processor clears conditions faster than it would take to define the match rules.
• Your investor's or agency's guidelines for the product change often enough that the match rules would need constant rework.
• The condition asks for judgment, not a document match: a credit explanation letter, an appraisal repair sign-off, anything alleging altered documents.
• Your loan origination system already tracks conditions and evidence links well; the gap is somewhere else in the file, not here.

Frequently asked questions

Related reading

• For the fuller picture across origination, closing, post-close QC, and servicing, see our industry page, AI consultant for mortgage companies.
• Loan underwriting document workflow covers the surrounding file-preparation workflow this condition-clearing step sits inside.
• Document review with human approval covers the same evidence-linked extraction and abstention pattern applied to contracts and policies.
• Multi-agent loan underwriting covers the underlying system design in more depth.
• AI agent implementation describes how a system like this is scoped, tested, and handed over.

Sources

1. [1] — Selling Guide B3-3.2-01, Standards for Employment and Income Documentation, published March 4, 2026 (accessed 2026-09-30)
2. [2] — Selling Guide B3-4.2-01, Verification of Deposits and Assets, published May 4, 2022 (accessed 2026-09-30)
3. [3] — Selling Guide B3-2-11, DU Underwriting Findings Report, published September 7, 2022 (accessed 2026-09-30)
4. [4] — Encompass Developer Connect (accessed 2026-09-30)