Encompass integration in 2026 comes down to two architectural approaches: SDK-dependent solutions that run inside ICE's runtime and inherit its constraints, and API-first solutions that synchronize with Encompass bidirectionally through field mappings while maintaining their own independent data model. Confer LOS uses the API-first approach with 180+ field mappings, E-Folder container auto-assignment (U1–U15), and OAuth-based authentication — enabling organizations to run AI-powered document processing, income calculation, and underwriting alongside existing Encompass infrastructure without replacing it.
The Integration Problem
Every mid-size lender faces the same question: how do you add AI automation to your loan origination workflow when your system of record is Encompass?
The answer depends on architecture. And the architectural choice you make today determines how much control you have tomorrow.
Two Approaches
SDK-Dependent (Inside-Out)
Your solution runs as a plugin or extension inside Encompass. It uses the Encompass SDK to read and write loan data.
Advantage:
Tight integration — everything happens within the Encompass environment.
Disadvantage:
Coupling. Your solution inherits Encompass's deployment cycle, runtime constraints, UI limitations, and SDK version dependencies.
API-First (Outside-In)
Your solution maintains its own data model and synchronizes with Encompass through the REST API. It reads loan data, processes independently, and writes results back.
Advantage:
Independence — your solution operates on its own stack, at its own pace, with its own capabilities.
Disadvantage:
You need to maintain field mappings between two schemas.
Confer chose API-first. Here's why.
The Field Mapping Layer
Encompass represents a loan as a flat object with hundreds of fields identified by alphanumeric codes. A borrower's first name is field 4000. The loan amount is 1109. The property address is 11. These codes are stable and well-documented, but they bear no resemblance to a modern relational data model.
Confer maintains 180+ bidirectional field mappings between its own schema (PostgreSQL tables with named columns) and Encompass's loan object. Each mapping includes:
- Confer field path — The table and column in Confer's database (e.g.,
customers.first_name) - Encompass field ID — The corresponding Encompass field code (e.g.,
4000) - Transform function — How the data is converted between formats
- Direction — Read from Encompass, write to Encompass, or bidirectional
Transform Types
Not all fields are simple copies. The mapping layer handles three types of transformations:
Direct mapping
The value copies as-is between systems. First name, last name, loan amount, property address — these are string or numeric values that need no conversion.
Encrypted field handling
Sensitive data like SSN requires masking rules. Confer stores the full value server-side with encryption at rest but applies masking (e.g., ***-**-6789) when displaying or transmitting. The Encompass sync respects both systems' encryption boundaries.
Enum translation
Encompass uses different codes for categorical values than Confer's database. Property type, loan purpose, occupancy type, loan status — each has a mapping table that translates between the two enum sets. For example, Confer's primary_residence maps to Encompass's occupancy code 1.
E-Folder Container Mapping (U1–U15)
When Confer's AI classifies and processes a document, the result needs to land in the correct Encompass E-Folder container. Downstream users — processors, underwriters, closers, and investors — expect documents filed in standard containers.
Encompass uses 15 container designations:
| Container | Code | Document Types |
|---|---|---|
| Application | U1 | 1003, application documents |
| Appraisal | U2 | Appraisal reports, property data |
| Assets | U3 | Bank statements, investment accounts |
| Credit | U4 | Credit reports, supplements |
| Employment | U5 | VOE, employment verification |
| Government | U6 | Government forms, VA/FHA docs |
| Income | U7 | W-2, pay stubs, tax returns |
| Insurance | U8 | Hazard, flood, MI |
| Legal | U9 | Title, legal documents |
| Loan Package | U10 | Loan package documents |
| Miscellaneous | U11 | Uncategorized |
| Pre-Closing | U12 | Pre-closing conditions |
| Processing | U13 | Processing documents |
| Title | U14 | Title documents |
| Underwriting | U15 | Underwriting conditions, approvals |
Confer's document classifier assigns the correct container code during classification. When a borrower uploads a W-2, the AI classifies it as a W-2, extracts the data, and assigns it to U7 (Income). When the document syncs to Encompass, it files directly into the correct container. No manual sorting by the processor.
Authentication: OAuth-Based API Access
Confer authenticates with Encompass through ICE Mortgage Technology's OAuth 2.0 flow:
- Client credentials — Confer registers as an API client with ICE Mortgage Technology
- Token request — The integration layer requests an access token using client credentials
- API calls — All Encompass API requests include the bearer token
- Token refresh — Tokens are refreshed automatically before expiration
This is the standard ICE-approved authentication method. No Encompass user credentials are stored or proxied. The API client operates with scoped permissions defined during registration.
Why Not SDK-Dependent?
Reason 1: AI Processing Requires Independent Compute
Document classification through a 3-tier pipeline (pattern matching → LLM → vision), income calculation across seven types, and compliance analysis through 10 MCP tools require compute resources and processing time that don't fit within an Encompass plugin's execution model. AI workloads need their own infrastructure — GPU access for vision models, API connections to LLM providers, and Temporal workflow orchestration for durable processes.
Reason 2: Deployment Independence
SDK-dependent solutions ship on Encompass's deployment schedule. When ICE updates the SDK, every dependent solution must update and re-certify. API-first solutions maintain their own deployment cycle. Confer can ship features, fixes, and improvements without waiting for ICE compatibility testing.
Reason 3: Multi-LOS Compatibility
An API-first architecture can integrate with systems beyond Encompass. Organizations running Encompass alongside another LOS — or planning to migrate — get integration flexibility. The same field mapping layer that connects to Encompass can be extended to other systems (Blue Sage, MortgageFlex, custom platforms) by adding new mapping profiles.
Reason 4: Data Sovereignty
With API-first integration, Confer maintains its own database with full control over schema, indexing, and query optimization. Document processing results, income calculations, and compliance audit trails live in Confer's PostgreSQL database — not embedded within Encompass's data model. This means faster queries, more flexible reporting, and no dependency on Encompass's data export limitations.
MISMO 3.4 and ULDD Export
Beyond Encompass integration, Confer supports industry-standard data formats for broader interoperability:
MISMO 3.4 XML
The Mortgage Industry Standards Maintenance Organization format used for data exchange between origination, servicing, and secondary market systems. Confer generates MISMO 3.4 XML exports for loan data, borrower information, and property details. This enables integration with automated underwriting systems (DU/LPA) through standardized submission files.
ULDD (Uniform Loan Delivery Dataset)
The Fannie Mae/Freddie Mac format required for secondary market loan delivery. Confer generates ULDD-compliant exports for correspondent lending workflows and GSE delivery.