Mortgage pricing engines, explained.

What a pricing engine actually does

A mortgage pricing engine accepts a loan profile (borrower, loan, property, transaction, execution) and returns investor-specific quotes. For each eligible investor, the engine looks up the base price on the active ratesheet at the requested rate, runs the investor's adjustment rules against the loan profile, applies margin layering, and emits a final price. The output ranks investors by execution criteria.

The job sounds simple in summary and is moderately complex in practice. Real engines support thousands of adjustment rules across dozens of investors, each with their own conditional logic. The architectural decisions that distinguish good engines from poor ones are about explainability (can a compliance team read why a number is what it is?), reproducibility (can you reprice as of a prior moment?), and integration ergonomics (can your LOS or POS or hedge stack consume the output cleanly?).

Who needs one

Anyone originating mortgages at non-trivial volume. Specifically:

• Correspondent lenders who price across multiple investors and need BEST_EX for each loan.
• Mortgage brokers who shop across wholesale lenders and present scenarios to borrowers.
• Mini-correspondents running hybrid retail + secondary operations.
• Lock desks managing the lock pipeline and sell-side execution.
• Secondary marketing teams consuming pricing events for hedging and bid-tape work.

The modern category

Mortgage pricing engines have been around for decades, and most of the market still runs on architectures designed in that era — monolithic deployments, configuration-by-spreadsheet, opaque pricing decisions. The modern category, by contrast, is built around three commitments:

1. Explainable pricing. Every quote ships with a per-rule trace built as a side-effect of the math. The trace is the compliance answer; you don't generate a separate "explain" report after the fact.
2. Versioned data. Ratesheets are immutable per version. Comp/margin rules are effective-dated. Audit logs are hash-chained for tamper-evidence. Historical replay reproduces past pricing deterministically.
3. Open integration. Public REST + GraphQL APIs with standard semantics (idempotency keys, RFC 7807 errors). HMAC-signed webhooks with retry, DLQ, replay. MISMO 3.4 / ULAD native. No proprietary SDKs that lock you in.

Vendors in the modern category include Polly and RateStack; several of the established incumbents are evolving toward this posture but with the friction of large legacy customer bases.

How to evaluate

An honest evaluation runs sandboxes from two or three vendors against your real ratesheets and your top scenarios. The dimensions that matter:

• Trace quality. Open a quote drill-down. Can you read every adjustment with its source rule and ratesheet version? Can you defend it to compliance without a separate report?
• Latency consistency. Run the same scenario 100 times. The p95 and p99 latency matter more than the average.
• Ingestion robustness. Drop in a ratesheet with a slight column change. Does the pipeline absorb it, or does it require vendor support?
• Audit chain. Ask the vendor to demonstrate a hash-chain verification on a known good and a known bad state.
• Replay. Reprice an old loan as of last quarter. Does the engine reproduce the historical price deterministically?
• Integration ergonomics. Read the OpenAPI spec. Try a curl. How quickly can your engineers produce a working integration?
• Support responsiveness. Send a purposely-vague support question on a Friday afternoon. The response time is informative.

For a structured RFP that exercises each of the above, see /resources/rfp-template.