Developers
Integrating financial spreading with a loan origination system
How a spreading tool connects to a loan origination system: files, an API on finalize, an embedded view, the account mapping under all three, and what to ask.
A loan origination system is the system of record for a commercial loan, and a spread that lives anywhere else must get back into it. How it gets there decides whether a spreading tool removes work or adds a second place to key the same figures. The question comes up with every tool, including the LOS vendor’s own module when a lender runs more than one system.
This guide describes the three ways a finished spread reaches an origination system, the account mapping that every one of them depends on, the questions to ask the spreading vendor and the LOS vendor, and how the common platforms take outside data. It is written for the credit technology lead who has to make the handoff work, not only for the buyer who approves it.
Three routes into an origination system
The file route is the oldest and still the most common. It needs no engineering, suits a team that files a few spreads a day, and fails only on the discipline of keeping the file layout and the LOS import in step. The API route is the durable one: the spreading tool announces a finalized spread, the lender’s service reads the approved figures and writes them into the LOS, and nothing is re-keyed. The embedded view solves a different problem, the analyst’s context, and pairs with either.
| Route | How it works | What it requires |
|---|---|---|
| File | An analyst or a job exports the spread as a workbook or a flat file and loads it through the LOS import | An import on the LOS side and a file in its layout; no engineering |
| API on finalize | The spreading tool notifies the lender’s service when a spread is approved; the service reads the figures and posts them to the LOS | A webhook receiver, the LOS write path and an account mapping |
| Embedded view | The spreading tool is seated in an iframe beside the loan record so analysts work without leaving the LOS | A signed URL minted server-side and a place in the LOS page; figures still travel by file or API |
| Vendor connector | The LOS vendor or the spreading vendor ships a prebuilt integration | Both vendors’ cooperation, a version match, and the vendor’s schedule |
| Manual re-keying | An analyst types the spread into the LOS template | Nothing, and it costs the most |
A vendor connector is the route buyers ask for first and get least often, because it depends on two vendors agreeing on a contract and maintaining it through both products’ releases. The lender that insists on one usually waits. The lender that builds the API route with its own team ships.
The account mapping every route depends on
Whatever the route, the spread’s accounts must arrive under the names and codes the origination system expects. Revenue, officer compensation, rent, cash and the current portion of long-term debt each have an identifier in the LOS, and a figure posted under the wrong one is a figure the LOS memo misstates. The mapping between the spreading tool’s accounts and the LOS codes is therefore the first artifact of the integration, and it should be owned by the credit department, saved once, and applied to every loan.
A good spreading tool exposes that mapping as data: an export map the lender edits, carried on every mapped statement so the payload arrives already in the LOS’s terms, and readable through the API so the mapping is versioned with the rest of the configuration rather than hidden in a transform somebody wrote.
What triggers the handoff
The right trigger is the analyst’s approval. A spread moves and changes while it is being worked, and an origination system that receives every draft receives noise. When the analyst finalizes, the figures are frozen at a version, and that version is what the LOS should hold. The spreading tool should announce the finalize with a signed event that names the loan and the version, and the receiver should record the versions it has posted so a retried delivery posts nothing twice.
Reopening is the companion case. When an analyst reopens a finalized spread, the LOS should know that the version it holds is no longer the latest approved one, and the next finalize should supersede it. A tool that cannot say which version the LOS holds cannot support that.
Webhooks in the SpreadSpace API documentation
Spreads and attribute snapshots in the SpreadSpace API documentation
How the common platforms take outside data
The major origination systems take outside data by different routes. nCino runs on the Salesforce platform and is reached through the Salesforce APIs and the middleware a bank already runs. Abrigo delivers integrations through its API network and partner program rather than a public reference. Baker Hill extends through partners, as its FlashSpread tax return arrangement shows. Jack Henry publishes a LoanVantage API and jXchange on its developer site. Finastra offers FusionFabric.cloud and product APIs such as LaserPro Connect. FIS publishes through Code Connect, and Fiserv through its Developer Studio.
The integration guides on this site describe each in turn, from the platform’s own public pages, with the SpreadSpace side of the handoff laid out the same way for every one of them.
Questions for each vendor
Ask the spreading vendor for the file formats and their layouts, the API that reads the approved figures, the event that announces a finalize and how it is signed, whether the accounts can be named in the LOS’s codes, and how the embedded view is authenticated. Ask for a sandbox where the whole loop runs on test data before a live loan.
Ask the LOS vendor which objects or records hold a spread, which import or API writes them, what permissions that needs, and what it costs. Ask whether the import keys on account codes or names, and what happens to a figure under a code it does not recognize. The answers decide the mapping, and the mapping decides the project.
The SpreadSpace handoff
SpreadSpace hands a finished spread to an origination system by all three routes. Documents export as CSV or JSON, sets of documents bundle in the background, and the loan’s spread comes out as two Excel workbooks. A finalize sends a signed event, and the approved figures and the mapped statements are read through the API and SDKs for TypeScript, Python and C#. A signed iframe URL seats the workspace beside the loan record.
The export map names every account in the origination system’s codes once per workspace, and every mapped statement carries them. No vendor connector is required for any route, and the integration guides describe the platform side for each major system.