The institutional, intelligent LOS
One system for the whole loan, origination through servicing. Orchid, a payroll-deduction lender in Puerto Rico, runs its entire book on it. A scanned loan file goes in. A funded, documented, reconciled loan comes out, and stays reconciled for its full term. This is not a pilot. Every figure on this page is live production data.
Documents catalogued & filed
Document linking automated
Straight-through reconciliation
Payment records under management
Proven in Production
Running the book,
not demonstrating it
Live counts from Orchid's production system of record: the document archive, the servicing ledger, and the reconciliation engine that keeps them agreeing with each other.
Document archive
Documents catalogued, categorised and linked to a borrower
Linked automatically. Only 841 by hand.
Folders organised across 38 categories
Servicing ledger
Payment records processed
Loans under management
Continuous payment history
Payroll deduction
Deduction line items extracted
Paying agencies recognised
Remittance documents parsed
The Problem
Most loan systems
stop at the application
They assume clean input, they hand off at funding, and they leave the hardest work to spreadsheets. Three constraints break them. Orchid had all three. We built for all three.
The System
One pipeline,
intake to reconciliation
Nine stages run end to end. Nothing is re-keyed between them. The record that classifies the file is the record that underwrites it, closes it, funds it and reconciles it years later.
Separate the file
The bundle is divided into individual documents by detected page range. No manual bursting, no page-count guesswork, no operator deciding where one document ends and the next begins.
Classify every document
Each document is read and assigned a category with a confidence score. The system reads past cover sheets and consent pages to the substance of the document before deciding.
Verify identity separately
Identity is not treated as one more extracted field. Names and identifiers are re-read under a separate, stricter pass, because this is the single point where an error becomes a duplicate borrower and a corrupted book.
Resolve the case
The system determines who each document actually belongs to, borrower or co-signer, across the whole file. Anything genuinely ambiguous is routed to a human rather than guessed.
Extract and compute
Structured fields are pulled per document type and validated against a schema. 4,266 application-file documents and 21,297 pages read to date. Amortisation, loan values, prior balances and refinance maths all run off that record, never off a re-keyed spreadsheet.
Advance through the pipeline
Files move through seven stages: incomplete, submitted, underwriting, approved, denied, funded, closed. Each stage is its own queue with its own view and its own controls.
Generate and execute
Closing documents render from the underwritten record and route into electronic signature. The document set is built from the same data that approved the loan, so the file cannot disagree with itself.
Fund and disburse
Funding reports, deposit handling and cheque processing, including bulk intake and automated matching against bank activity.
Reconcile for the life of the loan
Remittances are normalised and matched back to expected payments generated from the register, down to the individual borrower and period, across the 244 paying counterparties seen in production.
Document Intelligence
Every document
in a loan file
Classification is precision-biased by design. A document is identified by its title, its body content and its issuing entity. Never by a signature, a stamp, or the language it is written in, because in a real loan file every document is signed, stamped and in the local language.
When the evidence is not visible, the system returns unclassified and routes the file to a reviewer. An institutional platform does not guess at a borrower's paperwork.
Application-file documents read
Pages extracted and validated
1,579 of 1,643 remittance files cleared against their own printed control totals across five quarterly batches. 64 flagged for review.
Best quarter. Every file reconciled, zero exceptions.
Expected payments flagged as not received, borrower by borrower
Paying counterparties reconciled
Remittance documents parsed
Servicing
The half nobody
else automates
Originating a loan is the easy part. Every repayment arrives inside a remittance file from a third party, and 244 distinct payers appear in the live data, each with its own naming, formatting and timing conventions.
The engine normalises every remittance, generates expected payments from the loan register itself, and matches down to the individual borrower and period rather than the counterparty total. 9,178 borrower-period reconciliations across 2,277 loans, and 84.2% of them matched to a loan with no human input. What did not arrive gets surfaced instead of buried.
Platform
Three surfaces,
one system of record
Every surface reads and writes the same loan record. There is one source of truth and nothing to reconcile between your own systems.
Operator console
The full origination and servicing desk in the browser. Pipeline queues, borrower files, underwriting, reconciliation and reporting across 41 dedicated screens.
Native mobile
A native iOS application covering 13 feature areas, built for staff working away from a desk. Not a mobile wrapper around a web page.
API
Both surfaces run on the same API and the same loan record, so there is one system of record and no reconciliation between your own tools.
Get Started
Bring us a real
loan file
Send a live scanned application bundle. We will run it through the platform and show you what comes out.