Kirra and I started Maestro in 2024 after working on document processing systems together for several years. The observation that drove us here was not complicated: mortgage origination teams spend a large share of their working time doing things that do not require human judgment. Reading a number from a W-2. Checking whether a bank statement covers a continuous three-month period. Verifying that a field on a 1003 is not blank. These are checkable, readable facts, and they consume hours per file.
That observation is not unique to us. The mortgage industry has been trying to reduce manual processing work for decades. What surprised us, when we started looking closely at the origination stack, was how little had actually changed at the very front of the process.
Where the origination stack has gaps
Modern mortgage origination has good tooling for the underwriting decision itself. Fannie Mae's Desktop Underwriter and Freddie Mac's Loan Product Advisor have been mature automated underwriting systems since the 1990s. The appraisal workflow has digital ordering and review platforms. Title and closing have several strong point solutions. Compliance at the back end of the process is well-covered.
The front of the process, the stage between a borrower submitting their documents and a file reaching the underwriter's queue, is where the gaps are. This is the stage where a processor receives a folder of PDFs and has to figure out what is present, what is missing, what the numbers say, and whether anything obvious looks wrong before the file goes anywhere. This is 4 to 8 hours of active work per conventional file, more for self-employed borrowers. For the most part, it is still done manually.
The LOS systems that anchor origination workflows were not designed as document reading tools. They are systems of record for loan data, not systems for extracting that data from documents in the first place. The gap between "borrower submits a stack of PDFs" and "structured loan data in the LOS" is filled by manual processor work on most origination teams.
What Maestro does
Maestro reads the documents a borrower submits, extracts the fields that matter for the pre-underwriting assessment, and returns a structured report before a human processor begins their review.
The document types we support in the current release: URLA 1003, W-2, 1099-NEC and 1099-MISC, recent paystubs, federal tax returns including Schedules C and E, and bank statements. These cover the standard document package for the majority of conventional purchase and refinance applications.
The extraction output includes the key fields in each document: gross income figures from W-2s, qualified income from Schedule C, bank statement period coverage and average balance, employment dates from paystubs, and the major fields from the 1003. Alongside each extracted value, the report notes which document it came from and gives a confidence score. Low-confidence extractions are flagged for human review rather than silently passed through.
The pre-underwriting report also includes a document completeness check: what was submitted, whether date ranges are continuous, and which required documents appear to be missing. This check runs against a standard conventional-loan document checklist, with the intent of surfacing the gap list before a processor starts their review, so they can contact the borrower once with a complete list rather than discovering gaps sequentially through the review process.
What Maestro does not do
We want to be direct about this: Maestro does not make credit decisions. It does not recommend approval or denial. It does not compute risk scores or compare a file against program guidelines in a way that would constitute underwriting.
The output is a structured data set and a completeness summary. The processor reviews it, applies their judgment and program knowledge, and submits the file to underwriting. The underwriter reviews the complete file and makes the credit decision. That division of responsibility is intentional, and it is how we have built the product from the ground up.
We are also not a lender and not a mortgage broker. Maestro is tooling for origination teams. ECOA and fair-lending compliance is the obligation of the lenders who use the tool, as it has always been for any technology in the origination stack. We have designed the product to sit upstream of credit decisions specifically to ensure our extraction is not functioning as a decisioning layer.
Who we built this for
Our early conversations were with three types of origination teams. Regional bank mortgage departments that process several hundred loans per month and feel the staffing pressure during purchase season. Independent brokers who work with lean teams and submit to multiple wholesale lenders, each with slightly different document requirements. High-volume loan officers who handle the processing themselves and want a first-pass extraction before they submit.
Each of these groups has a different workflow and different pain points, but the common thread is the same: they spend time on document organization and data extraction that they would rather spend on the work that requires their expertise. That is the problem Maestro is built to reduce.
Where we are now
We are an early-stage company. We have a small angel round behind us and a small team in Chicago. We have been working with a handful of lender partners to refine the extraction models and the report format based on real origination workflows.
The product is live and available for early access. We are working with teams who want to integrate document extraction at intake and are willing to give us detailed feedback on where the extraction does and does not work on their actual file mix. If you process mortgage files and want to understand what Maestro produces on your document types, that is the conversation we want to have.
The problem is not going away. Document review will remain a manual labor sink for origination teams until the extraction tooling matures enough to be reliable on production files. That is the version of Maestro we are building, one document type at a time, starting with the ones that show up in every single application package.