For any lender running meaningful workflow automation on Encompass's SDK, it is close enough to be a real operational risk by 2026. ICE Mortgage Technology's deprecation of the SDK in favour of Partner Connect endpoints^[1] is, on the surface, a technical migration. You audit your integrations, rebuild your API calls, retest your workflows, and move on. That is what ICE wants you to do.

But for the lenders who have spent years building custom point-of-sale logic, automated disclosure workflows, proprietary decisioning rules, and underwriting automation on top of Encompass, the SDK sunset surfaces a harder question: Is the platform underneath all of that worth preserving?

The SDK deadline is a forcing function that surfaces a decision most Encompass shops have been deferring for years: whether the cost of staying on this foundation now exceeds the cost of owning something else.

This guide is for lenders who are asking that question seriously.

The Encompass SDK Sunset: What It Means for Lenders With Deep Customization

The SDK sunset is the visible trigger. The real frustrations predate it by years.

Encompass's single-user-per-file limitation creates processing bottlenecks that scale badly with volume. The UI, broadly described across review platforms^[4] as a Windows 95 experience, generates consistent friction for loan officers and underwriters. Administrative configuration is deep, brittle, and expensive, lenders routinely carry high admin-to-loan-officer ratios just to maintain Encompass stability.^[5]

ICE's own public positioning has made the build-versus-stay calculus more explicit. When SDK customers are documenting significant reductions in SDK call volume as they move toward Partner Connect^[2], the message is clear: the platform is moving toward simplification and not toward expanded customisation capability. Lenders who have built competitive differentiation on top of deep SDK customisation are being told that architecture is no longer supported.

For lenders at scale, with proprietary workflow depth, and with a technology organisation capable of owning a platform, the question is whether the evaluation has been done rigorously enough. See also: legacy system modernisation strategy [IL-2].

The Migration Ceiling

The Migration Ceiling is the threshold at which the cost and friction of continuing to customise a vendor's platform exceeds the cost of building a system the lender controls outright. It is not a fixed number. It is a function of origination volume, workflow complexity, technology team capability, and the gap between what Encompass can accommodate and what your business actually requires.

Most lenders do not consciously hit the Migration Ceiling. They accumulate technical debt against it over multiple years: one more custom integration, one more workaround for a platform limitation, one more configuration layer built to approximate a feature Encompass does not natively support. The debt accumulates until a forcing function  in this case the SDK sunset  makes the total cost visible all at once.

The indicators that a lender has reached or is approaching the Migration Ceiling are specific. Your Encompass admin cost is growing faster than loan volume. Your technology team spends more time maintaining integrations than building new capability. Your proprietary workflows have become bottlenecked by platform limitations. Your competitive differentiation in pricing, speed, or product flexibility is constrained by what Encompass can accommodate. And your per-loan technology cost  including licensing, admin, and integration maintenance  has passed the point where a custom system's amortised cost looks favourable at your volume.

When these conditions are present simultaneously, the Migration Ceiling has been reached. The question shifts from whether to build to how to build without destroying loan operations in the process.

Ideas2IT has built financial services software since 2009.

‍

‍If you're evaluating whether a custom LOS build is viable, the architecture and migration decisions need to be right before a line of code is written.

‍Audit your Encompass SDK dependencies and custom field exposure
Recommend an architecture pattern based on your volume, workflow depth, and compliance obligations
Define your data migration sequence and parallel-run strategy before build starts

Book a no-cost LOS Architecture Working Session. Schedule Your Working Session →

Build vs. Buy vs. Stay: The Decision Framework

The three realistic paths for a lender evaluating an Encompass exit are a custom build, a switch to another off-the-shelf LOS, and a migration within the Encompass ecosystem from SDK to Partner Connect API. Each has a different risk profile, cost structure, and fit depending on where your lender sits.

‍

The break-even threshold for most custom builds is approximately 500 loans per month at scale. Below that volume, the amortized build cost and long-term maintenance overhead rarely justify the investment over a well-configured off-the-shelf alternative. Above it, the per-loan cost on Encompass, including licensing, admin overhead, and integration maintenance, consistently exceeds what a custom system costs to run.

‍

Custom build is not the right answer for every lender. It is the right answer for lenders with high origination volume, deeply proprietary workflows that no off-the-shelf system can replicate, and a technology organisation capable of owning long-term platform maintenance. For a deeper look at how organisations have navigated this decision in adjacent financial services contexts, see Ideas2IT's fintech software development case study [IL-3].

An off-the-shelf alternative makes sense for lenders who are primarily exiting Encompass for cost or UI reasons, without deep workflow customisation requirements. The risk here is replicating the same vendor dependency problem with a different vendor.

Staying on Encompass with an API migration makes sense for lenders with modest SDK integration depth and no fundamental objection to the ICE ecosystem. For lenders with significant customisation, this path extends the problem rather than solving it.

What a Custom Loan Origination System Architecture Looks Like

A production-ready custom LOS is a set of integrated modules, each with a defined domain boundary, connected through a shared data model and event-driven workflows. Core modules includes

Point of Sale (POS):

‍Borrower-facing application, document upload, and initial data capture. Often the first module built, since it is the most visible and the fastest to validate with end users.

Decisioning engine:

‍Automated rules processing for loan eligibility, rate assignment, and product selection. This is where lenders with proprietary underwriting criteria see the biggest return from a custom build.

Document management:

‍Loan file management, eSignature integration, and MISMO-compliant document packaging.^[8] This module must be designed for both internal workflow efficiency and secondary market delivery requirements.

Underwriting workflow:

Condition tracking, approval routing, and exception handling. The most complex module in terms of state management, and the one most commonly underscoped in initial build estimates.

Compliance layer:

‍TRID disclosure timing,^[6] HMDA reporting hooks,^[7] RESPA service ordering, QM determination, and state-level disclosure automation. Addressed in detail in the next section.

Secondary market delivery:

‍FNMA/FHLMC data package generation per the ULAD specification,^[9] MISMO XML export, and investor delivery automation. Required for conventional lending and typically the last module built — but the one that determines whether the system can close loans at scale.

Architecture pattern: Microservices vs. Modular Monolith

The instinct for most engineering teams evaluating a greenfield LOS is to reach for microservices. The correct answer depends on team size, operational maturity, and timeline requirements.

A microservices architecture provides maximum flexibility and independent deployability, but it introduces distributed system complexity that most mortgage technology teams are not staffed to manage in the first 18 months. For a practical view of how this trade-off plays out, see Ideas2IT's analysis of microservices architecture for financial platforms [IL-4].

A modular monolith with clearly bounded internal domains delivers the same clean separation of concerns at a fraction of the operational complexity. It is the right starting point for most mid-market lender builds, with a clear migration path to microservices once volume and team maturity justify the switch.

Data layer: MISMO as the foundation

The Mortgage Industry Standards Maintenance Organisation (MISMO) XML standard is the canonical data model for mortgage origination data in the US market.^[8] Building against MISMO from day one eliminates the data translation overhead that makes secondary market delivery, regulatory reporting, and partner integrations brittle.

The Uniform Loan Application Dataset (ULAD) maps directly to the MISMO model and is required for Fannie Mae and Freddie Mac submission.^[9] An API-first design with MISMO as the shared data layer, and event-driven loan state management replacing polling-based workflow triggers, is the architecture pattern that holds up at production volume.

The Encompass Data Migration Playbook

Data migration is where custom LOS projects fail. In the assumption that loan data comes out of Encompass cleanly and maps directly into a new schema without significant transformation work.

A five-phase migration approach minimises operational risk and allows lenders to validate data integrity before committing to cutover.

1. Audit SDK dependencies and loan data fields. Before anything else, catalogue every custom SDK call, every custom field, every integration endpoint, and every workflow rule that touches Encompass.^[1] This audit typically takes two to four weeks for a lender with significant customisation depth. The output is a dependency map that determines migration sequence.
2. Map Encompass data fields to the new schema. Encompass's data model does not map cleanly to MISMO without transformation.^[8] Custom fields require specific mapping decisions. This is the step where most lenders discover that their data is more complex than their Encompass reporting suggested.
3. Extract and validate what comes out cleanly. Run a full data extract from Encompass and validate the output against your new schema. Identify orphaned records, incomplete loan files, and custom field values that do not map directly. This validation step determines whether your migration can proceed or whether data remediation is required first.
4. Run a parallel period. For any lender processing meaningful volume, operating both systems simultaneously during a defined parallel period is not optional. The parallel period validates that the new system produces identical outputs on the same inputs and that your compliance layer catches every required disclosure and reporting event. Typical parallel periods run 60 to 90 days.
5. Cutover and decommission. Cutover to the new system with a defined rollback window. Historical loan files in Encompass should be maintained in read-only mode for the regulatory retention period applicable to your loan types — typically seven years for most conventional mortgage files. Decommission should not happen until all regulatory reporting obligations for loans originated in Encompass have been satisfied.

Compliance Architecture: The Part That Scares Everyone

Compliance is the most common reason lenders abandon the custom LOS evaluation before it gets serious. The concern is not unfounded: TRID timing violations carry per-loan penalties,^[6] HMDA reporting errors create regulatory exposure,^[7] and QM designation mistakes affect secondary market eligibility.^[9] The consequence of getting this wrong is a regulatory action.

The correct architecture decision here is to integrate a compliance engine.

Established compliance engine providers i ncluding Mavent, ComplianceEase (now part of Wolters Kluwer^[10]), and ACES Quality Management^[11]  offer API-accessible compliance verification that can be embedded into a custom LOS workflow. This is the same model Encompass itself uses for many compliance checks. A custom LOS that integrates an established compliance engine inherits that engine's validation logic, update cycle, and regulatory coverage.

The architectural work is in the integration, not the compliance logic itself. The specific integration requirements across the primary obligations are as follows.

• ‍TRID disclosure timing: The Loan Estimate and Closing Disclosure workflows must enforce the regulatory timing windows automatically,^[6] with blocking controls that prevent loan advancement if required disclosures are not delivered within the required timeframe. Change-of-circumstance triggers must be wired into the document management module, not handled manually.
• ‍HMDA data capture: HMDA reportable fields must be captured at the point of application and maintained through the life of the loan.^[7] The LAR (Loan Application Register) export must be generated from live data, not reconstructed from loan file documents after the fact. This requires HMDA data hooks at the POS module, not at the reporting layer.
• ‍RESPA service ordering: In a custom LOS without Encompass's Partner Network, RESPA-compliant service ordering for appraisal, title, and settlement services requires explicit workflow design.^[12] The ordering controls, fee disclosure requirements, and change-of-circumstance triggers must be built into the workflow engine.
• ‍QM determination: General QM and Safe Harbor QM determination must be run against each loan file at application and at closing. If the compliance engine does not include QM determination, a separate integration is required.
• ‍State-level disclosures: Multi-state lenders require state-specific disclosure automation. This is best handled through a third-party document preparation service rather than maintained internally.

Realistic Timeline, Team, and Cost

The most common error in LOS build scoping is treating the compliance layer and data migration as late-stage additions rather than as foundational constraints on the timeline. Both must be scoped before engineering begins.

‍

‍

The cost drivers that most lenders underestimate are the compliance layer integration and testing, the parallel-run operational overhead of running two systems simultaneously for 60 to 90 days, the partner integration work for AUS connections, credit report providers, and appraisal management platforms, and data migration remediation when custom fields do not map cleanly to the new schema.

A lender that reaches production in 18 months with a full-featured system, clean data migration, and a completed parallel-run validation period has executed well. The lenders who take 36 months typically did not scope the compliance layer or the data migration before engineering started.

‍

With 18 to 24 months to production on a full-featured LOS, lenders who have not begun architecture scoping are already inside the risk window for the December 2026 deadline. The working session maps your Encompass dependencies, defines your build sequence, and gives you a team sizing estimate before you commit to anything.

What Execution Actually Looks Like

A mid-market independent mortgage bank processing 800 loans per month engaged Ideas2IT to build a custom LOS after hitting repeated processing bottlenecks on Encompass's single-user-per-file limitation. The system reached production in 21 months. Per-loan technology cost dropped 34% in the first full year of operation.

Working with a Development Partner vs. Building In-House

A lender's internal technology team is well-positioned to own long-term platform maintenance, define workflow requirements from a business-domain perspective, and manage vendor integrations with systems the team already operates. What most internal teams are not staffed for is concurrent deep expertise in mortgage compliance architecture, MISMO data modelling, LOS module design patterns, and the infrastructure engineering required to run a production system at origination volume. For context on how specialist custom software development for financial institutions [IL-1] differs from general-purpose software delivery, Ideas2IT's service page outlines the delivery model.

The lenders who build successfully typically engage a development partner for the initial architecture and engineering sprint, then transition ownership to the internal team once the system is in production. The variables to evaluate in a development partner are mortgage domain knowledge, engineering depth, and delivery model. An offshore team that only builds what you specify will create a system you do not fully understand. A consulting firm that documents and advises will leave you with a comprehensive deck and no working software.

Forward Deployed Engineers embedded inside your team  working in your stack, against your OKRs, with shared accountability for delivery outcomes  is a different model. Ideas2IT's FDE teams also have access to MigratiX, a purpose-built agentic data migration platform [IL-5], which accelerates the Encompass data extraction and schema-mapping phases by handling 80% of the heavy lifting pre-migration. The test for any partner is simple: ask where their engineers will sit during the build, whose standups they attend, and how they handle a production incident that surfaces six months after delivery.

‍

Build What’s Next. With an AI-Native Software Team.

Ideas2IT has been building financial services software since 2009. Our Forward Deployed Engineers embed inside your team from Day 0  your stack, your standups, your delivery cadence. Backed by a platform suite built to accelerate the hardest parts of mortgage technology.

In a working session we will:

• Map your current Encompass dependencies and SDK exposure
• Recommend an architecture pattern based on volume, workflow complexity, and compliance obligations
• Define the data migration sequence and parallel-run strategy
• Deliver a build sequence and team-sizing estimate before you commit to anything

Schedule your LOS Architecture Working Session →  ideas2it.com/contact

‍