The stack you already run. We make it produce cleaner files.
We took a deliberate position with Apsis Line: no new calculation engines, no shadow systems of record and no rip-and-replace. It’s an intelligent middleware layer above your loan origination system (LOS), and its job is to get more out of the LOS investment you’ve already made, upstream of underwriting.
LOS-agnostic by architecture. The platform speaks Mortgage Industry Standards Maintenance Organization (MISMO) 3.4, the industry-standard interchange, and every vendor connection is an adapter seam, so we can wire Apsis Line to any LOS. Our integration is deepest today on Encompass from Intercontinental Exchange (ICE): application push and field-level write-back. We’ve built Partner Connect service orders and disclosure generation to ICE’s published contracts, and they run simulated until you connect your sandbox. None of it has run against a live Encompass instance yet. If you run something else, that’s an integration conversation, and it isn’t a dead end. Bring your LOS to the walkthrough.
The Integration Surface
| Layer | Connects to | What it does |
|---|---|---|
| LOS: system of record | Any MISMO 3.4-capable LOS · deepest today: Encompass (ICE Mortgage Technology) | MISMO 3.4 Uniform Loan Application Dataset (ULAD) application push, the industry-standard interchange every major LOS accepts, with field-level write-back and receipts. We’ve built disclosure generation and tracking to the LOS’s published contracts, and they run simulated until you connect your sandbox. Your LOS remains the single source of record, and we don’t try to replace it. |
| Vendor services | LOS-native service channels · e.g. Encompass Partner Connect (EPC) | One governed connection powers every service order a file needs. In the loan officer workspace, four of them gate the disclosure launch: soft credit, hard credit, flood determination and the automated compliance review. Closing costs gate the same file through escrow readiness. Address verification and the value estimate ride the same connection without gating. On Encompass we’ve built these to ride EPC, and they run simulated, clearly labeled, until you connect your sandbox. On other platforms, we’d wire the same seams to that LOS’s service channels or to direct vendor application programming interfaces (APIs). |
| Credit | Your credit provider: direct bureau APIs or your LOS’s credit channel (e.g. Encompass Partner Connect) | Soft pulls for the borrower journey (no score impact), hard pulls in the workspace, each behind per-person authorization. We never pull without it. |
| Compliance review | Your compliance engine: e.g. via Encompass Partner Connect, or the review service you run today | In the loan officer workspace and on both self-serve journeys, we hold the file before disclosures unless the review affirmatively clears. Fail-closed. |
| Closing fees | Your fee service: e.g. via Encompass Partner Connect, or your current fee vendor | Real fee data on the file ahead of disclosure, so the Loan Estimate reflects the fees we ordered, not placeholders. |
| Flood | Your flood-determination vendor: e.g. via Encompass Partner Connect | We order it and attach it before disclosure, and it’s a required member of the services gate. |
| Product & pricing | Pricing engine connectivity | Product and pricing quotes (par and rate-stack options) once you connect your pricing engine. The borrower’s chosen product (rate, points, term) carries through the math and onto the LOS file exactly as they selected it. |
| Automated underwriting (AUS) | Fannie Mae Desktop Underwriter (DU) · Freddie Mac Loan Product Advisor (LPA) | Dual-AUS submission architecture with normalized findings, so we surface underwriting posture upstream. |
| Home valuation | Your automated valuation model (AVM) provider: e.g. RentCast | Per-property value estimates in the borrower journey, licensed for consumer display. We label each one clearly as an estimate, and it never substitutes for the appraisal. |
| E-signature & delivery | LOS-native disclosure delivery | We deliver generated packages for borrower e-signature and record the send dates to disclosure tracking. We’ve built it to the LOS’s delivery contract, and it runs simulated until you connect your sandbox. |
| Customer relationship management (CRM) | Consumer-direct and retail CRM connectors | Inbound lead prefill and outbound milestone status for the CRM your teams already run. |
| Artificial intelligence (AI) model surfaces | Optional, per surface, each configured on its own | Optional assistive surfaces (a loan-officer guideline assistant, a borrower question panel, a staff co-pilot, and document intelligence on an upload), each off until you configure it. On the question-answering surfaces, retrieval runs first over a bounded local corpus, and our code validates the answer after the model returns. Document intelligence picks from a closed list of document types, our code re-checks it, and it falls back to a labeled simulation. None of them is in the path of a regulated decision, and a continuous integration (CI) gate fails our build if one becomes reachable from a regulated module. We name our subprocessors, and no model trains or fine-tunes on lender or borrower data. |
| Lead partners | Adapter-based intake | Signed-token redirects and webhook lead models normalize into one attribution spine. Adding a partner is configuration work, and it doesn’t take new code. |
Vendor and product names describe technical interoperability only and don’t imply endorsement, sponsorship, or partnership. We confirm specific vendor availability per deployment against your licensing.
Integration honesty, as an architecture
Every vendor connection in the platform is a governed seam. Credentials live server-side only, the server decides simulated or live, and we label every result with its source. In a sandbox the platform demonstrates the full flow honestly. Once you connect your credentials, the same seams run live, and the experience, the math and the gates are identical either way. Your integration test tells you the truth.
We apply the same reflex to the model surfaces. An assistive surface stays off until you configure it on its own. On the question-answering surfaces, we ground the model in a bounded local corpus and never ask it what the answer is. No surface can reach a regulated decision, and a gate that fails our build enforces that. The AI governance posture →
Service orders carry durable transaction references, so nobody accidentally orders a billable service twice, and you can reconcile every order against the vendor invoice. There’s more on the credential and data posture →
Bring your integration checklist.
We like the detailed questions: field mappings, service orders, failure modes.