Mortgage Intelligence

Company

We are building Mortgage Intelligence.

Mortgage is one of the most information-dense financial systems in the economy. A single mortgage can involve hundreds of pages, multiple institutions, changing policy, dozens of calculations, and years of downstream obligations. Yet most technology still treats those inputs independently. We are building an intelligence layer designed to understand them together.


Why mortgage

Every decision in this industry is a judgment about a stack of documents

Whether to lend. Whether to buy the loan. What to service, and on what terms. What sits inside a security. Whether a file survives an examination in three years. Each of those is a question about what a few hundred pages actually say, and each is answered today by a person reading a fraction of them against a policy that keeps moving.

That is the layer the industry has never had: something that reads mortgage documents, understands what they assert, knows the policy that applies, and can prove the answer to whoever asks later. It serves the originator, the aggregator, the investor, the servicer and the auditor, because they are all asking questions of the same documents.


The problem with document-only intelligence

Reading a value and understanding a mortgage are different problems

Document reading is now a capability anyone can buy, and it improves across the whole industry every quarter. An extraction system answers what does this document say? A mortgage system has to answer is this file sound, under the rules that apply to it, and can you show why? The first question is about one document. The second is about the relationships between all of them, checked against a body of policy that changes over time.

A system can be excellent at the first and structurally incapable of the second, and from a demonstration the difference is invisible. Both produce a screen of extracted fields with confidence numbers beside them. The difference shows up later, in what escapes. The thesis, at length.


Why QC first

The first review by someone with no interest in the deal closing

A defect in a loan file is usually described from one end of the chain: a repurchase demand, an audit finding, a cost. That framing is accurate and narrow. The same defect at the other end is a borrower whose income was assessed incorrectly, a disclosure that arrived late, or a loan that should not have closed on those terms. The borrower has the most at stake in the file being right and the least ability to check any of it.

Post-closing quality control is one of the few reviews performed by someone with no direct interest in the transaction having closed. It is also where the checking already happens, where the answer is already supposed to be evidenced, and where the work is measurable. Making that examination complete rather than sampled, and reproducible rather than remembered, improves the accuracy of lending for every party at once. It is the first application, not the ambition.

The platform thesis

One intelligence layer, and the applications that earn their place on it

The same mortgage is examined at origination, underwriting, closing, quality control, delivery and servicing, by different teams for different reasons. The application changes. The need for coherent, evidence-backed understanding of the file does not. So the platform is built once, as six pillars, and each application is built on it: QC first, because the reasoning there is hardest to fake, and the others as they are proven on real files rather than as they appear on a roadmap.

Today a general-purpose vision-language model reads the documents behind a versioned rule engine, with a person resolving the exception. We are building a mortgage-domain model for the documents, the policy and the exceptions this industry actually produces: not to read pages better, which the whole market is buying from the same few providers, but to reason about what it has read. The rule engine is what earns the right to that model, because it produces the signal that is otherwise unavailable: which rule fired, what a reviewer did with it, and why.


How we build responsibly

Claims follow evidence, and the record is the product

STATUS
Current and roadmap are always distinguishable
Every application carries one of five statuses, set by product rather than marketing. A roadmap item is never described in the present tense.
DATA
Customer documents are not training data
Not ours, not the model provider's. Any future domain model would use customer data only under a separate written agreement signed knowingly. Security and data handling.
NUMBERS
No performance figure without the method
An accuracy percentage is publishable only alongside a stated benchmark, a stated document set and a comparison anyone can reproduce. Until then we state the method and invite you to test it on your files.
PEOPLE
A named person makes the decision
The system produces findings and evidence. A reviewer reaches the disposition, and that is recorded. This is a design position, not a gap.
AGENCIES
No implied endorsement
Encoding a published requirement is not endorsement by, affiliation with, or certification from Fannie Mae, Freddie Mac, HUD, the CFPB or any other agency.

Leadership

Who is building it

Shailesh Bhujbal, Co-Founder

Nearly three decades in fintech, building document and data platforms at scale across mortgage finance, cloud infrastructure, international development and industrial engineering. The problem has been the same throughout: turning documents into systems whose output can be relied on, in environments where the record has to survive examination years later. This is the continuation of that.


Where we are

Current stage, and how to work with us

Quality control is available for evaluation on sample, synthetic or de-identified historical files. The other applications are stated with their status on their pages. Deployment inside a customer's own AWS account is in development and not yet available; today the platform runs in our managed cloud environment.

The way to work with us is a working session: an hour, on a synthetic file or files of your own with outcomes you already know. No procurement process is required to start, and a good session ends in a decision rather than another meeting.

Talk to us about your files.

A working session on a synthetic file, or de-identified files of your own. No obligation and no procurement process required.