The Condition Engine generates a loan’s condition set before it reaches an underwriter, and fills condition data from the documents in the file — so underwriting validates conditions instead of building them.
Pre-conditioning
eqLend reads loan application data, automated underwriting findings, and the FHA scorecard where applicable, and generates the initial set of conditions before the file is ever submitted. Upstream teams get loan-level clarity on what belongs in the file and what is still outstanding, without touching the underwriter’s queue.
The term for this is pre-conditioning, not pre-underwriting. No credit judgment is made or implied; the engine determines what the file will be asked for, based on rules the lender owns.
Condition data, filled
The clerical half of conditioning is selecting a condition template and typing values into it — the bank name, the account number, the coverage amount. eqLend reads those directly from the classified documents and fills them in. The underwriter confirms rather than transcribes.
Conditions are written in your language — the way your shop words them — rather than vendor boilerplate, because the condition text comes from your rule set.
Keeping conditions current
The engine re-evaluates after loan data changes and updates conditions, eFolder document expectations and the borrower needs list accordingly, so a condition set does not drift from the loan it describes.
Exception-only workflow
Because generation and data-fill happen before the file arrives, the underwriter’s queue becomes exception work: the conditions that need judgment, not the ones that need typing. Lenders running this in production have reported roughly 30% fewer underwriter touches and 28% fewer days from submission to clear-to-close, with about 80% of clerical condition work removed.
How conditions reach Encompass
Conditions and condition attributes are generated outside Encompass, in the eqLend engine, and then delivered into Encompass through the Encompass API. Two consequences follow, and both matter more than they first appear.
The conditions are native Encompass records
Because delivery happens through the API rather than through a screen overlay, what lands in Encompass is a real condition with its attributes populated — visible in the screens your team already uses, subject to your existing personas and workflows. This is the mechanism behind silent delivery: there is nothing new for a user to open, because the output arrives where they already look.
The logic is not trapped inside your LOS
Generation happens in eqLend, not in Encompass business rules or custom code. The rule set that decides what a loan should be conditioned for is therefore portable — it is not a configuration artefact of one LOS instance. That is what makes the ownership position on the rules page a structural fact rather than a promise.
It also means there is no Encompass customisation for your administrators to maintain, and no dependency on the legacy Encompass SDK that ICE is transitioning integrations away from. Lenders carrying brittle SDK-based customisations are re-evaluating exactly this kind of exposure.
Which conditions, and which API
Delivery uses the Encompass Developer Connect v3 APIs — ICE’s current generation, not the legacy v1 surface and not the retiring SDK.
eqLend writes to either standard Encompass conditions or Enhanced Conditions, according to the lender’s preference. This is a deliberate choice rather than a limitation. Enhanced Conditions is ICE’s newer framework and adoption across the lender base is uneven; a shop that has not migrated should not have to change its condition model in order to automate conditioning, and a shop that has migrated should not be pushed back to the older one.
The practical consequence is that adopting eqLend does not force a condition-framework migration as a prerequisite. Whichever model your underwriters and QC team work in today is the model conditions arrive in.