Last updated: July 10, 2026
By Kris Drouet, Engineering Executive, in partnership with KORE1
An Encompass integration realistically takes four to six months and costs well past the vendor quote, because certification, field mapping, event re-architecture, and testing against a real loan file are never inside the number you are shown. The six-to-eight-week figure from a sales cycle prices a happy path that does not exist yet. Here is where the rest of the time and money actually go, and how to size them before you sign.
A VP of Engineering slid a signed statement of work across the table to me last year and asked why his team was three months into a “six-week” Encompass integration with no end in sight. I read one page. Then I asked him four questions. Had the vendor mentioned partner certification. Had anyone mapped their loan fields to the Encompass field IDs yet. Were they still polling for changes the old way, or had they moved to events. And whose loan file, a real one, with real borrower edge cases, had actually flowed end to end.
Silence on all four. Not because his team was weak. They were good. Nobody had told them the quote priced the part that was easy.
The quote is not a lie, exactly. It is a build estimate for the demo, priced as if the demo were the product. Encompass is the loan origination system a large share of the U.S. mortgage industry runs on, which means integrating with it is never a side project you slot between features but the plumbing that every loan in the building flows through. And the gap between what a vendor quotes and what a regulated lender actually lives through is the widest I have seen in twenty-five years of doing this work.
I have written the general version of this fight in my build vs buy framework, and the AI-specific one in why most AI pilots die before production. This is the mortgage-tech version. It is the one where the quote and the reality drift furthest apart, and the one with a hard deadline attached that most teams have not priced in yet.
Why the Quote Is Always Wrong
A vendor quote is honest arithmetic on a dishonest scope. Someone counts the API calls. Read a loan. Write a few fields. Fire a webhook. Two engineers, a few sprints, done. On a whiteboard that math is correct.
The problem is that “integrate with Encompass” is not an API problem. It is a data problem wearing an API costume. The ICE Mortgage Technology developer platform gives you clean REST endpoints, OAuth 2.0, and event notifications. Good tools. None of them know what your business calls a “rush file,” or which of the several thousand fields on a loan your downstream systems actually depend on, or that your servicing team quietly relies on a document naming convention nobody wrote down.
That knowledge lives in your org, not in the SDK docs, and dragging it into the open, writing it down, and reconciling it against the way Encompass actually models a loan is the integration. Extracting it is the work. The API is the last ten percent.
Here is the reframe I give every leader sizing one of these. You are not buying weeks of coding. You are buying weeks of coding, plus a certification you do not control the calendar on, plus a data-mapping project that touches every team that ever reads a loan, plus a testing effort against the messiest data in your building. Price four things. Not one.
Where the Other Months Actually Go
Below is the honest breakdown. Left column is the quote’s mental model. Right column is what the work actually is, from the integrations I have been part of at real lenders. The pattern is the same every time. The line items that blow up are never the ones anyone flags in the sales call.
| The work | What the quote assumes | What it actually takes |
|---|---|---|
| Partner onboarding and certification | A form and an API key | A review process on ICE’s clock, not yours. Weeks of back and forth before you touch production. |
| Field mapping | “We map a few fields” | Reconciling your loan model against Encompass field IDs and MISMO, ULAD, and UCD formats. The single biggest time sink, every time. |
| Event re-architecture | “We call the API when we need data” | Moving from SDK polling to Enhanced Field Change webhooks, then building the queue, retry, and idempotency layer that real event traffic demands. |
| Documents (eFolder) | Not mentioned | Loan documents, attachments, and their naming rules. Almost always discovered late, and never small. |
| Security and compliance review | “It uses OAuth, so we are covered” | A real review, because this is borrower financial data under federal scrutiny. Your own security team is a dependency now. |
| UAT with a real loan file | “We test with sample data” | The sample data passes. The real file breaks things, and finding out how is the entire point of this phase. |
Look at that right column and count the teams involved. Engineering. Security. Compliance. Servicing. A vendor whose review queue you cannot see into. That is not a two-engineer job. That is a program, and programs run on calendar time, not sprint time.
There is a cost pressure sitting under all of this that engineering leaders outside mortgage tend to miss. Producing a single loan already costs the industry a fortune. The Mortgage Bankers Association put total production expense at $11,109 per loan in the third quarter of 2025. Every month your integration slips is another month those already thin margins carry an unfinished project on top of a per-loan cost that sits near the highest levels the industry has ever recorded. The business feels the delay in a way a SaaS company simply does not.
The SDK Sunset Just Changed the Math
If your integration still runs on the Encompass SDK, you are not planning a new build. You are running a migration against a regulator-grade clock, and the clock is loud right now.
ICE is retiring the Encompass SDK. Per ICE Mortgage Technology’s own transition guidance, SDK-based applications reach end of life on December 31, 2026, and usage fees begin accruing on anything still leaning on the SDK starting January 1, 2027. After that date, SDK applications stop loading properly and service-ordering connections break. In a loan pipeline, a broken service order is not a bug ticket. It is a stalled closing.
Read that timeline against today’s date. Less than six months. And “migrate off the SDK” is not a find-and-replace. Where the SDK let you poll for changes from inside your own process, the new model wants you subscribed to events, hosting a service of your own, holding OAuth tokens, and monitoring a live pipeline you never had to run before. That is a rebuild of how your systems talk to each other, not a port.
So the honest math for a lot of teams reading this is worse than a fresh integration, not better. You are doing the new build and unwinding the old one at the same time, with a deadline you did not choose. I am not saying this to sell panic. I am saying it because the teams that started in the first half of 2026 are fine, and the teams still quoting it at six weeks in July are the ones who will be paying SDK penalty fees in January while they finish.
A Phase Timeline You Can Actually Defend
When a leader asks me to help them size one of these, I do not give them a single number. I give them phases with honest ranges, because the variance lives in a couple of specific places and pretending otherwise is how you end up back at the six-week fantasy. Here is the shape I walk them through for a lender doing this properly.
| Phase | What happens | Honest range |
|---|---|---|
| 0. Discovery and field inventory | Find out which fields, documents, and events you actually depend on | 2 to 4 weeks |
| 1. Sandbox, OAuth, first read | Get a token, pull a loan, prove the connection | 1 to 2 weeks |
| 2. Field mapping and writes | The real reconciliation work, plus write-back and validation | 4 to 8 weeks |
| 3. Events and documents | Webhooks, retries, idempotency, eFolder handling | 3 to 6 weeks |
| 4. Certification and security review | ICE partner review, your compliance sign-off | 3 to 6 weeks, mostly not yours to control |
| 5. UAT and cutover | Real loan files, edge cases, and the switch | 3 to 5 weeks |
Add the low ends and you land near sixteen weeks. Add the high ends and you are past thirty. That is your four to six months, and the part worth staring at is that Phase 4 is largely a queue you sit in rather than code you can write faster by adding people, which is the exact reason staffing up in a panic near the deadline buys you almost nothing. This is where throwing engineers at the problem does nothing. You cannot parallelize a certification review.
One more thing the timeline hides. Some of this is brittle by nature. Point-to-point integrations into a system this central tend to grow tangled until everything is holding everything else up and nobody wants to touch it. If that is already your situation, an Encompass migration is a good moment to decouple instead of re-cabling the mess. I wrote up how we did exactly that with an event backbone in our Kafka pub/sub case study, where the decoupling cut downstream latency 45 percent and, more to the point, made the next integration cheaper instead of scarier.
Build, Buy, or Buy the People
Once the real number is on the table, the decision splits three ways, and the right answer depends less on the technology than on who is going to still be here in eighteen months maintaining it.
Buy a pre-built connector. Fastest to first value if a marketplace product covers your exact use case. The catch is fit. The moment your workflow needs a field the connector never exposed, or an event it does not emit, you are back to building anyway, only now you are stacking your code on top of someone else’s abstraction that you do not control and cannot change. Good for standard use cases. Painful for anything bespoke.
Build it in house. Right when the integration is core to how you compete and you intend to own it for years. It only works if you have engineers who understand both the API model and the mortgage domain. That second half is the rare one. A brilliant backend engineer who has never opened a loan file will still burn the better part of a month learning what a milestone is, why a field gets locked, and how a closing disclosure differs from an estimate, all before shipping a single thing that matters.
That domain gap is where most of these projects actually stall, and it is a hiring problem more than a coding problem. This is regulated-industry engineering, which has its own rules that generic SaaS teams learn the hard way. I get into why in engineering leadership in regulated industries. When the internal skills are not there, the fix is not a bigger vendor contract. It is one or two engineers who have shipped an Encompass integration before and will not rediscover every trap for you. KORE1’s software engineer staffing team runs these searches constantly, their recruiters average more than fifteen years in the business, and 92 percent of the people they place are still in the seat a year later. On a project where the person who built it walking away is the real risk, that retention number is the one I would anchor on.
My actual advice, most of the time, is a blend. Buy the connector for the standard flows, build the thin layer that encodes what makes your lending business yours, and staff that build with at least one person who has already shipped an Encompass integration and will not rediscover every trap on your budget and your timeline. The all-build teams underestimate the domain. The all-buy teams discover the fit gap in production. The blend is boring and it is usually right.
What Mortgage-Tech Leaders Ask Me Before They Sign
What does a vendor actually mean when they quote six weeks?
Six weeks is the coding estimate for the happy path, and nothing else. It counts reading a loan and writing a handful of fields with sample data. It does not count certification, field mapping, event work, security review, or a single real loan file.
None of those omissions are malicious. The vendor is quoting the slice they control, which is the API calls, and assuming your side of the work is free. It is not free. It is most of the project. Ask them in writing what the quote excludes, and watch the six weeks turn into a conversation.
We are still on the Encompass SDK. How bad is the December 31 deadline for us?
Bad enough to make it this quarter’s problem, not next year’s. SDK applications reach end of life on December 31, 2026, service-ordering connections break after that, and usage fees start accruing January 1, 2027. That is under six months from now.
Bad is not the same as hopeless. A team that scopes honestly this month, gets into the certification queue early, and treats it as a migration rather than a tweak can finish in time. The teams I worry about are the ones still calling it a six-week job in the middle of summer.
A connector looks cheaper than building it ourselves. Is it?
Cheaper up front, almost always. Cheaper over three years, only if your use case stays inside what the connector supports. The price you pay for a connector is not the license. It is the fit.
Map your must-have fields and events against the connector’s capabilities before you sign anything. If it covers them, buy it and move on. If you find three things it cannot do that your business depends on, you are going to build anyway, and building on top of a connector you have outgrown is more expensive than building clean.
How much of the real cost is the certification nobody warned us about?
Plan for three to six weeks, and understand that most of it is not yours to speed up. Certification and security review run on ICE’s queue and your compliance team’s calendar, not your sprint board. Adding engineers does nothing here.
The mistake I see is teams treating this as a formality they can rush at the end. Then they finish the code, hit the review wall, and lose a month they had already promised to the business. Get into the queue while you are still building. It is the single cheapest schedule save available to you.
Do we need mortgage-tech engineers specifically, or will a strong backend team do?
A strong backend team can build it. They will just build it slower, because the hard part is the domain, not the code. The difference between an engineer who has shipped an Encompass integration and one who has not is roughly a month of expensive discovery.
You do not need an entire mortgage-native team. You need one or two people who have seen a loan file break an integration before, embedded with your strong generalists. That mix moves fastest. Pure generalists rediscover every trap. Pure specialists are hard to find and expensive to hire in bulk. One experienced hand changes the whole timeline.
Before You Sign the SOW
Do one thing this week. Take the vendor quote in front of you and write the six line items from the first table down the margin next to it. Certification. Field mapping. Events. Documents. Security. UAT with a real file. For each one, ask the vendor plainly whether it is in the number. The quote is not wrong because the vendor is dishonest. It is wrong because it answers a smaller question than the one you are actually asking.
If you are staring at a signed six-week SOW and a December deadline right now, connect with me on LinkedIn and tell me which phase you are stuck in. I read those. And if the honest read is that nobody on your team has shipped one of these before, talk to KORE1’s engineering hiring team before you scope another integration blind. The right first hire is cheaper than the second missed deadline.
Related reading: Show Me the Data: An Engineering Leader’s Framework for Build vs Buy Decisions, Build vs Buy in AI: Why Most Pilots Die Before Production, and Engineering Leadership in Regulated Industries: Where Fintech Differs from Generic SaaS.