Mortgage Broker Software: Fixing the Condition Chase

Why loan file software makes or breaks a mortgage brokerage

Every mortgage brokerage has the same physics problem: a file has a rate lock with an expiry date, a borrower who answers texts but not emails, an underwriter at the lender who wants three more documents by Thursday, and a processor juggling 28 other files with the same shape. The software either holds that state accurately or your team holds it in their heads, and in the shops we have measured, heads stop scaling somewhere around 25 active files per processor.

The stack is almost always the same. Encompass, Calyx Point, LendingPad, or Arive as the loan origination system. Each lender's own portal for submission: UWM's EASE, Rocket Pro TPO, Pennymac's POWER, plus four or five smaller wholesale portals with their own logins. Maybe Floify for borrower document collection. A shared Google Sheet or a Monday board called something like "PIPELINE MASTER" that the processors actually trust, because the LOS pipeline view does not show what they need. A Dropbox or SharePoint folder tree for documents. A group text thread for the stuff that is on fire. Encompass list pricing lands around $150 per user per month before the setup fees and the consultant you hire to configure it, and it still does not tell you that the appraisal on file 4471 came back low two days ago.

Here is the scene that costs real money. It is Tuesday. A processor pulls up the pipeline sheet, filters to her 31 files, and starts the ritual: log into EASE, check conditions, copy the new ones into the sheet, log into POWER, same thing, log into the third portal, same thing. That is 45 minutes before she has done a single piece of work. On file 4471 she sees a condition posted Friday afternoon requiring an updated VOE. Nobody saw it. The lock expires in nine days. She emails the borrower, who replies Thursday, HR (Human Resources) takes until the following Tuesday, the lock extension costs 12.5 basis points, and on a $520,000 loan that is roughly $650 the brokerage eats to keep the borrower happy. Do that six times a quarter and you have paid for a meaningful chunk of a custom build with pure leakage.

Problem: conditions live in five lender portals and none of them talk to you

Every wholesale lender posts conditions in their own portal, in their own format, on their own schedule. UWM posts them as a list with internal codes. Pennymac emails a PDF. The smaller lenders send an underwriter email with the conditions in the body. Your processor is the integration layer, and she is a human one who has Fridays off.

The off-the-shelf tools cannot fix this because they do not own the relationship with the lender's portal. Arive and BrokerEngine will show you conditions for the lenders they have integrations with, which is usually the big four, and give you a manual entry field for everyone else. If 30 percent of your volume goes to regional wholesale lenders, and for most multi-branch brokerages it does, 30 percent of your conditions are still manual. Encompass TPO Connect helps if you are on the Encompass side of the fence and the lender is too, which is a coin flip.

What a custom build does: one conditions table, lender-agnostic, with a normalized schema. Condition ID, source lender, raw text, parsed category (income, asset, property, title, credit, compliance), the specific borrower or document it attaches to, who owns it internally, due date, days outstanding, and a state machine: posted, assigned, requested from borrower, received, submitted, cleared, or rejected with reason. Ingestion is per lender: API where the lender exposes one, an authenticated scrape where they do not, and a mailbox parser for the ones that email PDFs. This is where AI earns its keep: a language model reads the raw condition text, however the lender phrased it, and classifies it, extracts the due date, and matches it to the right borrower and document type. We have seen this land at high enough accuracy that the processor reviews rather than transcribes. The screen your processor opens Tuesday morning is one list, sorted by days-to-lock-expiry, across every lender. The 45 minute ritual becomes zero.

Problem: document chasing burns your processors and nobody knows who is waiting on whom

A borrower needs to send 14 documents. Some come by email attachment, some by text photo, some through Floify, some the loan officer forwards from his personal Gmail. The processor renames them, files them, checks them against the condition list, and finds out the bank statement is page 3 of 7. She emails again. Two days pass.

Off-the-shelf borrower portals exist and they are fine at collecting files. What they do not do is close the loop between the document, the condition it satisfies, and the follow-up cadence. The portal tells the borrower "upload paystubs." It does not know the condition said "most recent 30 days consecutive, all pages," it does not read the uploaded PDF to check that you got 30 days, and it does not automatically stop pestering the borrower once the condition is satisfied.

What a custom build does: document intake with extraction on arrival. The borrower texts a photo of a paystub. The system OCRs it, pulls employer, pay period start and end, gross year to date, and net, and checks whether the coverage window satisfies the open condition. If it is one paystub short, the borrower gets an automated reply within a minute saying exactly what is missing, not a generic reminder next Tuesday. Bank statements get parsed for account number, statement period, and page count so a partial upload gets caught immediately instead of at underwriting. Follow-up runs on a cadence tied to the condition due date and the lock clock: gentler at day 10, escalating at day 3, and it escalates to the loan officer with a suggested call script rather than silently expiring. This is the piece with the clearest payback, because chasing is where processor hours actually go.

Problem: your pipeline view lies to you, so you cannot staff or forecast

Ask most brokerage principals how many files are stuck waiting on the borrower versus waiting on the lender versus waiting on your own team right now. They cannot answer without asking someone. The LOS gives you milestone status, which tells you a file is "in processing," which is true of a file that closed a condition ten minutes ago and a file that has been dead for three weeks.

No off-the-shelf tool fixes this because the data it needs does not exist in the tools. "Waiting on whom" is a computed field that requires knowing every open condition, who owns it, and when it last moved. That only exists if you built the conditions layer above.

What a custom build does: once conditions are structured and timestamped, the pipeline view becomes real. Files bucketed by blocker owner: borrower, lender, internal, third party (appraiser, title, HOA). Aging on each. Cycle time by lender, so you can prove that Lender B takes 4 days longer to clear a condition than Lender A and route accordingly. Cycle time by processor, so you know who is drowning before they quit. Forecasting is a modest, real AI use here: a model trained on your own closed files predicts days-to-close for each active file from condition velocity, lender, loan type, and borrower responsiveness. Not to impress anyone, but so that your closing coordinator knows on the 8th whether the 22nd is real, and so you know in the third week of the month whether you are hitting your number.

Problem: lender submission is manual re-keying and the errors are expensive

Submitting to a wholesale lender means taking a file that already exists in your LOS and re-entering or re-uploading it into the lender's portal in the lender's format, with the lender's document naming conventions and stacking order. Processors do this by hand. A mis-stacked package or a missing 1003 signature page comes back as a suspense two days later.

Arive and the newer broker platforms do help here for the lenders they support, and if you send 90 percent of volume to three lenders they support, buy the tool. The gap opens when you are multi-branch with different LO relationships and a long tail of lenders, or when you want submission to encode your own rules: this borrower profile, this LTV, this DTI, goes to this lender because we know their overlay.

What a custom build does: a submission engine with a per-lender adapter. Each adapter knows that lender's required document set, naming convention, stacking order, and the fields their portal wants. Pre-submission validation runs your checklist and theirs before anything leaves: signature pages present, dates within tolerance, income documentation matching the 1003, LOX present where required. The engine assembles the package, submits, records the confirmation, and starts polling for conditions. Where lenders expose no API, the adapter drives the portal in a headless browser with a fallback to a human queue when a page changes. This is unglamorous and it is exactly the work that off-the-shelf will not do for your fifth lender. Note what you should not build: pricing comparison. If you want that, you integrate Optimal Blue or Loansifter rather than rebuilding a pricing engine.

Problem: compliance and audit evidence is reconstructed after the fact

When a state examiner or a lender's QC pulls a file, you need the Loan Estimate delivered within three business days of application, the changed circumstance documented with a reason and a timestamp, the fee tolerances tracked, the borrower's intent to proceed captured, and the whole communication trail. Most brokerages reconstruct this from Encompass, email archives, and memory when the request lands, at a cost of a day or more per file.

The LOS holds a lot of this, but it holds it about the LOS's own actions. The text your loan officer sent, the change the borrower verbally requested on a Thursday call, and the reason the fee moved live outside it. That is where findings come from.

What a custom build does: an append-only event log at the file level. Every state change, every document received, every communication sent through the system, every fee change with the changed circumstance reason attached at the moment it happens rather than backfilled. TRID timing clocks computed and alerting before a deadline, not after. Role-based access so a branch manager sees their branch and NMLS-licensed activity is attributable to the licensed individual who performed it. Encryption at rest and in transit for the borrower PII, because you are holding SSNs, bank statements, and tax returns, and GLBA safeguards apply to you regardless of your size. Audit export produces the packet in minutes.

What this actually costs and how long it takes

These are Digital Heroes bands from delivery across 2,000+ projects, not market averages. A focused first release for a brokerage in this category runs $60,000 to $130,000 and ships in 12 to 16 weeks. That release is normally: the unified conditions layer with two or three lender ingestions, document intake with AI extraction and automated follow-up, the real pipeline view, and borrower status. A full platform that adds the submission engine across your full lender set, the compliance event log and audit export, partner and referral portals, and forecasting runs $150,000 to $400,000, phased over 6 to 12 months.

What pushes price up in this category specifically. First, lender count and integration quality: an adapter for a lender with a documented API is a week; an adapter for a portal with no API, MFA, and a UI that changes quarterly is three to four weeks plus ongoing maintenance, and that maintenance is a real line item, not a rounding error. Second, LOS integration depth: reading from Encompass is manageable, bidirectional write-back with field mapping across your custom fields is where the estimate doubles. Third, document extraction breadth: paystubs and W-2s are well-trodden; self-employed borrowers with K-1s, P&Ls, and two years of business returns are a different project. Fourth, multi-branch permissioning and compensation logic, which sounds trivial and is not, because every brokerage's LO comp plan is a snowflake with tiers, splits, and exceptions. Fifth, migration: pulling three years of historical files out of Encompass or Point with documents attached and intact is its own workstream.

Build versus buy: take the tool if you fit the tool

Buy off-the-shelf if you are a single-office shop under about 40 files a month, sending 85 percent or more of volume to two or three big wholesale lenders that Arive or BrokerEngine already integrates, with a mostly W-2 borrower base. In that shape the tools are good, the price is a fraction of a build, and a custom system is a vanity purchase. Pay for Arive, hire a good processor, and go sell.

Build when these signals show up together, and they usually do show up together. You have a spreadsheet or Monday board that the team trusts more than the LOS pipeline, and it has been alive for over a year. You are over roughly 60 files a month or across three or more branches. More than a quarter of your volume goes to lenders your platform does not integrate. You have hired a person, or part of a person, whose actual job is copying between systems. You have paid for more than a couple of lock extensions this quarter that traced back to a condition nobody saw. Or your differentiation is a niche the tools are not built for: non-QM, bank statement loans, investor DSCR, where the condition patterns and document sets are nothing like a conforming file and every off-the-shelf workflow fights you.

My position: for a brokerage at real volume, the right build is almost never a replacement for the LOS. Encompass and Point are the system of record and re-implementing them is a waste of your money. The right build is the operating layer above: conditions, documents, submission, and visibility. Keep the LOS. Own the layer where your money leaks.

How to choose a developer for mortgage broker software

Ask them to model a condition on a whiteboard before you talk price. A developer who has built in this category will immediately ask whether a condition attaches to a borrower or a file, what happens on a rejected clearing, and how you represent a condition that a lender re-opens. One who has not will draw a table with a status field and a text column. That five minute test filters most of the market.

Make them name lenders and describe the integration honestly. The right answer for a portal with no API is "we drive it in a headless browser, it will break when they redesign, here is our monitoring and here is what maintenance costs per year." Anyone who says integration with any lender is straightforward has not done it. Ask what happens when MFA blocks their scraper at 6am on the 30th.

Probe compliance as data architecture, not as a feature. The question is not "do you know TRID," it is "how do you store a changed circumstance so it is defensible in an exam three years later." You want to hear append-only events, timestamps at the moment of action, and attribution to the licensed individual. You also want a direct answer on where borrower PII lives, how it is encrypted, who on their team can see it, and what they do about data retention.

Settle ownership and exit in the contract, not the conversation. You own the source code, the repositories, and the infrastructure accounts from day one, and there is a written handover: architecture docs, runbooks, and the ability for another firm to take over. Any developer who hosts your borrowers' tax returns in an account you do not control has given you a hostage situation, not a system.