Autopilot Update: Getting the Details Right

Most of what we shipped this cycle has a single thread running through it: what the agent does when it hits something it cannot complete.

And that’s a more interesting problem than it sounds. An agent that succeeds is easy to evaluate. An agent that fails has choices. It can guess at a cause and tell the borrower something untrue. It can invent a request the file does not support. It can report a blocker that is not really a blocker and stop a loan that was fine. Or it can say precisely what it knows, name who should look at it, and stop.

That’s what connects the updates below: helping Autopilot handle uncertainty more accurately.

Let’s dive in.

Document review and follow-ups

Clearer handling of documents flagged by security checks

Autopilot runs security checks on every document it processes. These include checks for prompt injection, which is when text inside a document attempts to influence or redirect the AI’s behavior. If a document triggers one of these checks, Autopilot blocks it from being processed.

Previously, Autopilot sometimes gave an incorrect explanation for why a document was blocked. For example, it might tell the borrower that a document was corrupted, password-protected, or unreadable, even though it had no evidence that any of those issues existed. It could then ask the borrower to upload another copy unnecessarily.

What’s changed: Autopilot now clearly distinguishes between a security block and a problem with the document itself.

• It no longer guesses why a document was blocked or asks the borrower to upload a different copy.
• It tells the loan officer that an automated security check blocked the document and that manual review is needed.
• When the block happens during a run that generates a run card, Autopilot automatically flags the document for lender review.
• When no run card is available, Autopilot tells the loan officer that no review flag was created and that they need to review the document directly.
• Other documents submitted in the same request continue processing normally.

Borrowers won’t receive unnecessary requests to fix documents when the actual issue requires lender review. Loan officers also get a more accurate explanation of what happened and what they need to do next.

Better follow-ups when a borrower uploads the wrong document

Some document requests are automatically marked complete as soon as a borrower uploads a file, before Autopilot has reviewed whether it’s the correct document. For example, a borrower might upload last year’s W-2 when the lender requested the current year’s W-2. Lending automatically closes the request when the file is uploaded, but Autopilot reviews the document afterward and identifies that it’s the wrong year.

What’s changed: Autopilot now checks how a document request was closed before deciding what to do next.

• Automatically closed when the borrower uploaded a file: If the document doesn’t meet the requirements, Autopilot creates a new borrower request linked to the original.
• Completed by someone at the lender: Autopilot respects that decision. It notifies the loan officer that the document didn’t satisfy the request but doesn’t automatically ask the borrower again.
• Rejected, cancelled, waived, or declined by the lender: Autopilot records the outcome in its summary without creating another request.
• Waiting on a third party: Autopilot leaves the request alone because it isn’t the borrower’s responsibility.
• Closed by Autopilot, or the reason is unclear: Autopilot refers the issue to the loan officer rather than sending another borrower request.

Only requests automatically closed upon upload can trigger a new borrower request. In all other cases, Autopilot leaves the decision to the loan officer or respects the existing request status.

More accurate reviews of bundled bank statements

Borrowers often upload several months of bank statements together in a single PDF. Previously, Autopilot could treat the entire file as one continuous date range. For example, if a PDF contained statements for January and March but was missing February, Autopilot could record the file as covering January through March without identifying the missing month.

What’s changed: Autopilot now reviews each page and records the coverage period of each individual statement within a bundled PDF. This means it can identify:

• Missing monthly statements within a bundle.
• Gaps between the end of one statement period and the beginning of another.
• Dates that appear on a document but don’t represent the actual statement period.

Autopilot also no longer assumes that a statement covers a particular period simply because that period was requested. It uses only the coverage dates explicitly shown on each statement. We’ve added automated tests for both missing months and gaps between statements to help ensure this behavior continues working as expected. Lenders get a more accurate picture of which bank statement periods have actually been provided, reducing the risk of missing documentation going unnoticed.

More precise document requests for purchase loans

When reviewing purchase loans, Autopilot may need to request documents such as a purchase contract, earnest money deposit, or homeowners insurance for the property being purchased. But there’s an important distinction: the purchase agreement for a home a borrower is buying and the sales contract for a home they’re selling can share the same document type.

Previously, Autopilot could treat both documents the same way and send the borrower a direct request for the sales contract on the home they were selling.

What’s changed: We’ve updated the document request rules to distinguish between the two properties.

• For the home being purchased: Autopilot continues requesting the required purchase documents directly from the borrower.
• For the home being sold: When guidelines require the sales contract, Autopilot now places the request in the loan officer’s suggested panel rather than sending it directly to the borrower.

This follows the approach behind Autopilot’s Selective Follow-up Mode: requests clearly supported by the loan file can go directly to borrowers, while requests requiring lender judgment are suggested to the loan officer. The improvement was made through lender-specific configuration rules rather than changes to Autopilot’s underlying code. We’ve also expanded the automated tests covering these requirements.

Borrowers receive more appropriate document requests, while loan officers retain control over requests that require additional judgment.

Pricing and AUS

Pricing now asks for missing pricing information

Running a loan pricing scenario requires certain details about the loan. When those details were missing, the pricing engine could reject the request, leaving the loan officer with an error rather than a clear explanation of what was needed.

What’s changed: Navigator now helps loan officers provide missing information before continuing.

• Loan purpose: If pricing cannot proceed because the loan purpose is missing, Navigator asks the loan officer to provide it.
• Occupancy: If the property’s occupancy status is missing, Navigator asks for that information.
• Property details: The pricing intake card now clearly identifies the required property information upfront.

Instead of encountering repeated pricing failures, loan officers can see what information is needed and provide it to move forward.

Subscribe to Autopilot updates

More accurate handling of DU readiness checks

Before submitting a loan to Desktop Underwriter (DU), Autopilot performs a readiness check to identify potential issues that could prevent submission. Previously, if the readiness check couldn’t return a result because the necessary readiness data was unavailable, Autopilot could block the submission. But an unavailable result doesn’t necessarily mean there’s anything wrong with the loan.

What’s changed: Autopilot now distinguishes between a confirmed issue and a readiness check that couldn’t reach a conclusion.

• Confirmed readiness issue: Autopilot continues to block the submission.
• No readiness result available: Autopilot proceeds with the DU submission and lets the agency evaluate it.

Loans aren’t unnecessarily held up simply because an internal readiness check couldn’t return a result. Actual blockers still prevent submission.

URLA 2020 blockers are now explicit

When a loan is missing a required URLA 2020 element for Desktop Underwriter, Blend Lending now identifies it as a specific DU readiness blocker.

Loan officers can see what’s preventing the submission and take the appropriate action, rather than troubleshooting an unclear error.

---

To get started with Blend Autopilot, contact your Blend account team.

For more on what is shipping across Autopilot and Navigator, visit our changelog. It is updated weekly with everything new and improved across Autopilot.