AI underwriting integrates with a loan origination system in one of three shapes: as a SaaS platform working alongside the LOS through REST APIs and webhooks, as a module embedded inside the LOS through a vendor partner program, or as an on-prem or VPC-deployed system. For most $1B to $10B community banks, the first shape is what works. It keeps the LOS as the pipeline of record, does not require a Salesforce or Azure rebuild, and gives the AI platform a defined boundary the bank's integrations engineer can actually defend in a third-party risk review.
Most published material on this is vendor pitch deck rather than architecture. This page is the version you can hand to the integrations engineer at your bank and get usable answers from. It covers the three integration shapes, the four data flows that actually move between the AI platform and the LOS, the auth and data boundary you need to defend under SR 11-7 and OCC Bulletin 2023-17, the integration patterns by LOS, and the six RFP questions to ask any AI underwriting vendor before signing.
For the broader framing on where AI underwriting sits inside a community-bank rollout, the AI-Assisted Underwriting Playbook is the right pillar to start with. The build-vs-buy guide covers the decision before this one. This page focuses on the integration architecture once the buy decision is made.
What Are the Three Integration Shapes?
Every AI underwriting vendor sits in one of three deployment shapes relative to the LOS. The shape determines who holds the pipeline record, where the borrower documents land, and what the integration surface looks like.
1. SaaS alongside the LOS (REST APIs and webhooks)
The AI platform is its own SaaS application. The LOS stays the system of record for the pipeline. The two systems talk over REST APIs and webhooks against whatever public surface the LOS exposes. This is the Aloan shape, and it is the most common pattern when a community bank wants to add AI underwriting without a multi-quarter platform replacement. The bank keeps its LOS, keeps its committee process, and adds an analyst-layer tool that hands a structured spread, credit memo, and risk flag set back to the LOS pipeline record.
When the LOS does not expose a usable API surface, this shape falls back to file-drop. The AI platform writes a structured PDF spread or CSV pipeline update into an SFTP location, and an LOS-side job picks it up on a schedule. File-drop is slower and harder to audit than a webhook, but it works on closed LOS deployments where the API is licensed separately or simply not built out.
2. Embedded inside the LOS (vendor partner program)
Some LOS platforms run a vendor partner program. The AI module installs inside the LOS environment, gets distributed through the LOS marketplace, and renders inside the LOS UI as a tab, side panel, or workflow step. The bank's integration surface is essentially the LOS itself, plus whatever the partner program exposes for configuration and data flow.
This shape removes some of the cross-system plumbing but trades it for partner-program constraints. The AI vendor's release cycle, model upgrades, and configuration changes have to clear the LOS vendor's process. Pricing usually layers on top of the LOS subscription. And the data boundary becomes whatever the LOS vendor's partner agreement says it is.
3. On-prem or VPC-deployed
A few risk-management and analytics products still ship as on-prem appliances or VPC deployments. For modern AI underwriting, this shape is rare. Inference economics push almost every serious vendor onto managed cloud infrastructure with elastic GPU access, and the operational burden of running a model-serving stack inside the bank's network is hard to justify unless the institution has both a specific regulatory driver and a real ML platform team. If a vendor offers this shape, the question to ask is what they actually run inside your environment versus what still calls out to their cloud at inference time.
What Are the Four Data Flows That Matter?
Strip away the vendor pitch and the integration surface reduces to four data flows. If the AI platform handles all four cleanly, the LOS keeps its job as the pipeline record and the analyst gets a faster file. If any of the four is hand-stitched in Excel, the integration is partial.
| Flow | Direction | What moves |
|---|---|---|
| Document intake handoff | AI platform → LOS | Borrower-submitted documents, classified by form and matched to the LOS pipeline record |
| Spread and memo write-back | AI platform → LOS | Structured spread, credit memo, and risk flag set attached to the LOS deal or loan object |
| Status webhooks | AI platform → LOS | Pipeline state changes (intake complete, spread ready, memo drafted, flags raised) for downstream credit-decisioning and approval routing |
| Pipeline read-back | LOS → AI platform | Loan and borrower context the AI platform needs to scope work and report on portfolio-level metrics |
The first three are the load-bearing ones. The fourth is the one most pilots leave for later. Without read-back, the AI platform cannot tell you how many deals are stuck in extraction versus stuck in committee, which is the question a CCO asks two months after go-live.
What Does the Auth and Data Boundary Look Like?
Integration is also a boundary question. Where the data lives, how it crosses, and who can read it on either side. The pieces below are what an integrations engineer needs to lock down before the first webhook fires.
Authentication
OAuth 2.0 with a dedicated LOS service account is the standard pattern. The bank provisions a service-account user inside the LOS, scopes its role to the deal, borrower, and document objects the AI platform needs to read or write, and rotates the credential on a schedule. Long-lived API tokens still appear, especially on older LOS surfaces, but OAuth with audit-logged service accounts is the cleaner answer when an examiner asks who wrote which record.
Data residency
Where the AI platform stores borrower documents and where it runs inference are two separate questions. For Aloan, the platform is US-hosted, AI inference runs through enterprise APIs from Google Cloud (Gemini Enterprise) and AWS Bedrock, and customer data is never used to train foundation models. The full posture is documented on the AI data security page. The point for the procurement file is that the vendor can tell you, in writing, what region holds the data at rest and what region the inference call lands in.
Encryption
TLS in transit and at-rest encryption on storage are table stakes. Every serious vendor has both. What varies is key management and whether the bank can bring its own key for sensitive document storage. For most community-bank deployments, vendor-managed keys against a documented KMS are acceptable. Banks with a specific regulator-driven control around key custody should ask the question explicitly.
What crosses the trust boundary
Borrower documents and the structured data extracted from them cross. Internal bank credit policy configuration crosses (so the AI platform knows which add-backs to apply and which covenants to test). Pipeline status crosses both ways. What should not cross: bank user credentials, downstream booking-system records, or core processor data the AI platform has no reason to read. A clean integration scopes the service account to exactly the objects the workflow needs, and nothing else. That scoping is what the third-party risk review will ask you to defend.
What Does the Integration Pattern Look Like by LOS?
Each LOS exposes a different integration surface. The descriptions below are integration patterns, not Aloan partnership claims. The right way to use them is as a starting point for the technical conversation with your LOS vendor and the AI vendor on the same call.
nCino
nCino is built on the Salesforce platform, so the integration surface is Salesforce. Custom objects on the Salesforce side hold the pipeline record, and REST integration goes through the standard Salesforce API. An AI underwriting platform writing back into nCino is writing back into Salesforce custom objects with the correct record type and a service-account user that has been licensed for API access. For the broader comparison, the Aloan vs nCino page walks through how this shows up in practice.
MeridianLink
MeridianLink publicly markets an Open API for LOS integration. The pattern is REST against the documented endpoints, with webhooks for state changes the AI platform needs to react to. The integration question to ask is which API tier is licensed under your contract, since the public Open API page does not always reflect what your specific institution has enabled. The Aloan vs MeridianLink page covers the analyst-workflow side of the same decision.
Encompass
Encompass is the ICE Mortgage Technology LOS, and the public integration story is heavily mortgage-shaped. The Encompass SDK and webhook patterns exist and are well-documented for mortgage origination workflows. Commercial-lending coverage is thinner, and AI underwriting integration on the commercial side often falls back to file-drop or to a narrower set of fields than what mortgage integrations expose. If your bank runs Encompass for commercial files, the integration conversation with the AI vendor should start with the specific commercial objects you need read or written.
Abrigo
Abrigo distributes integration through a vendor partner program, and parts of the Abrigo stack are themselves a broader bank-software platform rather than a single LOS. The integration pattern is partner-program-mediated rather than open REST. Banks running Abrigo should expect the technical conversation to involve Abrigo's partner team alongside the AI vendor. The Aloan vs Abrigo page walks through where the platform-vs-overlay choice lands for community banks.
Baker Hill
Baker Hill NextGen exposed an older API surface that integrations engineers know well. UN/FY, the next-generation Baker Hill platform launched in November 2025, is built on Microsoft Azure Cosmos DB and Microsoft Fabric, and the integration story for AI vendors is still settling out. Banks on a Baker Hill upgrade path should ask the AI vendor explicitly which Baker Hill version the integration targets. The Aloan vs Baker Hill page has more on the NextGen-to-UN/FY transition.
Six RFP Questions for Any AI Underwriting Vendor on Integration
These six questions separate vendors who have shipped real LOS integrations from vendors who have demoed against a clean sample. Put them in the RFP and ask for written answers, not slide bullets.
- Auth model. OAuth, service account, long-lived token, or something else. Which one, and what does the bank provision on the LOS side to make it work?
- Write-back schema. Which LOS objects and fields does the AI platform write to, with sample payloads. If the vendor cannot show you a sample JSON body for a spread write-back, they have not shipped one.
- Webhook delivery guarantees. At-least-once or at-most-once. How does the AI platform guarantee a status event reaches the LOS pipeline record, and what does the LOS side need to do to deduplicate.
- Retry behavior. When the LOS API rejects a write or returns a 5xx, what does the AI platform do. How many retries, on what schedule, and where does the failure show up for the integrations team.
- Audit-log access. Both directions. Who-wrote-what on the LOS side (service-account audit) and what-the-AI-did on the platform side (model output, override trail, source-document citation). Examiners under current model risk guidance will ask for both.
- Sandbox availability. A non-production LOS environment the AI vendor can connect to during the parallel-run phase of implementation. If the vendor can only test against your production LOS, the integration is risky to ship.
Useful operating benchmark: a vendor that cannot answer all six of these in writing on a single technical call has not done a production LOS integration with a real bank. The written answers are what your procurement file and third-party risk review need; the slide deck is not.
What If Our LOS Does Not Expose a Usable API?
File-drop is the working fallback. The AI platform produces a structured artifact (a PDF spread with embedded source citations, a CSV pipeline update, a credit memo document) and writes it to an SFTP location or storage bucket the LOS-side job picks up on a schedule. The handoff is slower and harder to audit than a webhook, but it works on legacy LOS deployments where the API surface is closed or licensed separately. The trade-off is real: file-drop loses the at-least-once delivery guarantee of a webhook and pushes more deduplication work onto the LOS-side job. For most community banks, the answer is to ship file-drop first, then upgrade to webhook once the LOS API budget clears procurement. That sequencing keeps the analyst-side win on schedule without holding the rollout hostage to an LOS contract negotiation.
Frequently Asked Questions About AI Underwriting LOS Integration
How does AI underwriting integrate with a loan origination system?
Most AI underwriting vendors connect to the LOS in one of three shapes: as a SaaS platform working alongside the LOS through REST APIs and webhooks (the most common pattern for community banks), as a module embedded inside the LOS through a vendor partner program, or as an on-prem or VPC-deployed system (rare for AI vendors today). The right shape depends on which system holds the pipeline of record and how much of the analyst workflow lives inside the LOS UI versus a separate tool.
Does my bank need to replace its LOS to add AI underwriting?
No. Most community banks add AI underwriting as a layer alongside the existing LOS rather than replacing it. The AI platform handles document intake, spreading, K-1 tracing, and credit memo drafting, then writes results back into the LOS pipeline record so the existing approval and booking workflow does not change.
What data flows between an AI underwriting platform and the LOS?
Four flows matter: borrower-side document intake handed off from the AI platform to the LOS, structured spread and credit memo write-back into the LOS pipeline record, status webhooks for credit-decisioning and approval routing, and read-back of LOS pipeline state for monitoring and reporting. All four can run over REST APIs and webhooks where the LOS exposes them.
What authentication patterns are standard for AI underwriting integration?
OAuth 2.0 with a service account is the common pattern. The bank provisions a dedicated service-account user inside the LOS, scopes its permissions to the objects and fields the AI platform needs to read or write, and rotates the credential on a schedule. Token-based auth (long-lived API keys) still appears, but OAuth with audit-logged service accounts is the cleaner answer when an examiner asks who wrote what record.
What if our LOS does not expose a usable API surface?
File-drop fallback is the standard answer. The AI platform produces a structured export (PDF spread, CSV pipeline update, or a memo document) into a shared SFTP location or storage bucket that an LOS-side job picks up on a schedule. The handoff is slower than a webhook and harder to audit, but it works on legacy LOS deployments where the API surface is closed or licensed separately.
How do we evaluate a vendor on integration during procurement?
Ask for six things in writing: the auth model (OAuth, service account, token), the write-back schema (which LOS objects and fields, with sample payloads), webhook delivery guarantees (at-least-once vs. at-most-once), retry behavior on failure, audit-log access for both directions of the integration, and a sandbox environment for parallel testing before go-live. A vendor that cannot answer all six on a single call has not done a real integration before.
How this works in practice: Aloan deploys as the first integration shape: SaaS alongside the LOS, talking REST and webhooks against whatever surface the LOS exposes, with file-drop fallback where it does not. The platform is US-hosted, SOC 2 Type II certified, and the data boundary is documented on the AI data security page so your third-party risk team can review it before the technical call. If you want to walk through the integration shape against your specific LOS, get a demo and bring your integrations engineer.
Go deeper: For the build-vs-buy decision that sits one step earlier, read build vs buy for AI underwriting. For the 30/60/90-day rollout that this integration plugs into, read the playbook's pilot-to-production timeline. For the third-party risk track that runs parallel to integration design, read OCC 2023-17 for AI underwriting vendors. For the examiner-readiness side of the same workflow, read examiner readiness for AI lending. For the analyst-layer product that lands the data after integration, read financial spreading software. For the broader category map of where each LOS sits, read the commercial lending technology landscape.