The three failures of legacy pricing engines
After a year of conversations with operators across correspondents, brokers, and lock desks, the same three pain points kept coming up. RateStack started here.
Most lenders we've talked to have a pricing engine. Most lenders we've talked to are unhappy with their pricing engine. The reasons cluster tightly around three failure modes — none unique to any single vendor, but most common across the category.
1. Black-box adjustments
The engine returns a final price. The LO can see it. The compliance team asks "why?" and the answer is a paraphrase of the inputs, not the actual rule chain. When a regulator asks the same question six months later, the answer becomes harder, not easier.
We started RateStack with a non-negotiable: every quote ships with a per-rule trace. Not a summary, not a paraphrase — the actual ordered rule chain that produced the number. The first time a compliance lead read one out loud and said "that's the answer, that's exactly the answer," we knew this was right.
2. Brittle ratesheet ingestion
The morning ratesheet ritual is a hidden tax that most shops have internalized. Login to portal, download PDF, open in Excel, copy cells, paste into LOS. Repeat 30-50 times. Errors compound. When a vendor changes a column header, the whole pipeline breaks for a day.
We bet that header normalization could be a learning system: stored template first, AI fallback second, regex heuristic last. The AI resolution writes a new template back to the database. Vendor changes column? First sheet costs a small AI call; every subsequent sheet matches the new template directly. The pipeline absorbs the change instead of breaking under it.
3. Lock-day surprises
The third pain is the most operationally expensive. The LO runs three investors, picks the best, advances the borrower toward lock. On lock day, the price comes back different — investor changed the LLPA, or the borrower's LTV moved 1% from the appraisal, or the doc type doesn't match. The lock either reprices or denies; the borrower is unhappy; the LO is unhappy; the secondary desk gets paged.
Two-stage eligibility solves this by running the cheap pre-flight predicates against every program on every quote. If a borderline change would knock out an investor, the LO sees it before the lock. The surprises don't go to zero, but they go from "routine" to "rare."
The connecting thread
All three failures share a root: they're what you get when the engine is built for speed but not for reproducibility. Make reproducibility a first-class requirement — version the inputs, hash the audit log, trace every rule, gate eligibility separately — and most of these problems stop being problems.
That's the bet RateStack is built around. We're six quarters in and it has held.