eqLend operates inside your existing Encompass environment. There is no separate system of record, and no second pipeline for your team to keep in sync.
Where it sits
Encompass remains the system of record for loan data, documents and conditions. eqLend runs as an orchestration layer above it: it reads loan data and eFolder documents, evaluates your rules, and writes results back — conditions, tasks, document associations, and corrected field values.
| Concern | Owned by |
|---|---|
| Loan data of record, eFolder, milestones, personas | Encompass |
| Task and needs list generation, condition generation, document-to-condition mapping | eqLend |
| The rules that drive all of the above | The lender |
Reading loan state
eqLend re-evaluates a loan when its data changes, so the task list, condition set and borrower needs list stay current rather than being generated once at intake. In practice this means a change saved in Encompass is reflected in what eqLend has generated without anyone re-running anything.
Coexisting with native Encompass features
Encompass has its own condition framework, and most lenders already run business rules, custom fields and personas. eqLend is designed to work with that configuration rather than around it.
The division is clean: conditions and condition attributes are generated outside Encompass, in the eqLend engine, then delivered into Encompass through the Encompass API. Encompass receives real condition records with attributes populated; eqLend keeps the logic that produced them.
| Step | Where it happens |
|---|---|
| Read loan data, findings and documents | eqLend, from Encompass |
| Evaluate the lender’s rules | eqLend |
| Generate conditions and condition attributes | eqLend |
| Deliver conditions into the loan | Encompass API |
| Store, display and work the conditions | Encompass |
The practical effect for an administrator is that there is nothing new to maintain inside Encompass — no custom code, no scripting framework dependency, no SDK-era customisation carrying forward. The integration surface is the API.
Delivery runs on the Encompass Developer Connect v3 APIs, and conditions are written as either standard Encompass conditions or Enhanced Conditions depending on the lender’s preference — so adopting eqLend does not require migrating your condition framework first. See Condition Engine.
The SDK transition
ICE is moving integrations off the legacy Encompass SDK toward REST APIs. Lenders carrying older SDK-based customisations are re-evaluating what they run and who maintains it. Where a lender is replacing brittle custom code, an orchestration layer driven by readable rules is generally cheaper to own than bespoke scripting.
Environments
Role screens are portable across Encompass Desktop, Encompass Web, and eqLend’s standalone Employee Portal. The same screens and the same rules follow the user, so a team split across environments is not running two different processes. See Experience layer.