Mortgage Pipeline Hedging Software: How Do You Stop the Hedge From Trailing Your Locks When Rates Move 40 Basis Points Before Lunch?

Why the hedge trails the pipeline, every single time

The lock desk takes locks all day. The hedge gets adjusted when someone looks. In between sits a gap, and the gap is where a quarter of earnings goes when the ten year moves hard on a jobs number. A desk running $300 million a month has roughly $600 million of open commitments at any moment. A 40 basis point move against an unhedged sliver of that is not a rounding error, it is the origination margin for the month.

The workflow that produces the gap is the same at almost every lender. Rate sheets go out in the morning from a pricing engine. Locks come in through the loan origination system. A secondary analyst pulls a position report, usually late morning, exports to Excel, applies pull through assumptions that were set at some point in the past, computes a required coverage in TBA terms, and calls a broker dealer. Then the desk reprices intraday, extensions and renegotiations arrive, three loans fall out, one borrower switches from a 30 year to a 15 year, and the position report that drove the morning trade is already describing a pipeline that no longer exists.

Nothing here is anyone incompetence. It is a latency problem. The lock is an event and the hedge is a batch, and the two are joined by an analyst with a spreadsheet.

Problem 1: your pull through assumption is a single number and it should not be

Most desks carry pull through as a small set of buckets, often by lock stage. Applications get one percentage, approvals another, clear to close another. Those numbers were set from a rough historical average and reviewed occasionally. They are wrong in exactly the moment they matter most.

Pull through is a function of rate incentive above all. When market rates fall 50 basis points below the note rate on a locked loan, that borrower has a reason to renegotiate or walk to a competitor, and your fallout rises precisely when your hedge is losing on the forward side. It also varies by channel, since a retail borrower behaves nothing like a broker submission, by loan purpose, by lock term and remaining days, by loan officer, and by whether the file has an appraisal in hand. A single blended number blends away every one of those signals.

What a custom model does is estimate pull through per loan, from your own history, with rate incentive as a live input recomputed against current market pricing rather than the pricing at lock. The output is not a prettier number. It is a coverage requirement that moves when the market moves, which is the entire point. Building this needs 18 to 24 months of your own lock and funding history, and the honest answer is that if you do not have clean historical lock data with the market level at lock recorded alongside it, the first phase of the project is capturing that, not modelling it.

Problem 2: best execution is decided by habit

Every loan can go several ways: agency cash window, securitisation into a pool, a correspondent whole loan sale, an assignment of trade, or the bank balance sheet. The right answer differs loan by loan and it changes with the market. In practice most desks default to whichever outlet was right last quarter, because comparing properly is a spreadsheet exercise that nobody has time for at 3pm.

Real best execution has to price the whole loan, including servicing. A loan sold servicing released earns a service release premium today. Retained, it creates a servicing asset with a value that depends on prepayment expectations. Buy up and buy down grids on the guarantee fee change the coupon and therefore the pool the loan can go into. Specified pool payups are real money and get ignored constantly: a low loan balance pool, a geographic concentration story, or a high LTV story can be worth meaningful ticks over generic TBA, and if your execution engine only compares cash window against generic delivery, you are leaving those payups on the table every month.

A custom build encodes this as an execution comparison per loan across every outlet you are actually approved for, using your own commitment terms and your own margin requirements, and it recomputes when pricing changes. The engine does not have to be exotic. It has to be honest about the outlets you can genuinely deliver into, which is why generic vendor best execution frequently disagrees with reality: it does not know your investor approvals, your delivery limits, or your appetite for retained servicing this quarter.

Problem 3: the lock desk exception ledger does not exist

Extensions, relocks, renegotiations, float downs, and worst case pricing exceptions are granted every day. Some are policy, most are a phone call with a producer. Each one has a cost, and that cost is a real reduction in the margin on that loan. Almost nobody attributes it back to the loan, the branch, or the loan officer who asked for it.

This is the least glamorous feature in the category and it is frequently the one that pays for the project. Every exception becomes a ledger entry with an amount, an approver, a reason and a link to the loan. Then the monthly margin report shows realised margin after exceptions by branch and by originator. The conversation that follows is uncomfortable and extremely valuable, because in most shops a small number of producers consume a large share of the exception budget and nobody could prove it before.

What Optimal Blue, MCT, Polly and ICE Compass actually do well, and where they stop

Optimal Blue is the widest product and pricing engine in the market and it should generally stay in your stack. Rebuilding rate sheet generation, investor pricing ingestion and loan level pricing adjustment maintenance is a maintenance treadmill you will regret owning. Polly is a genuinely modern alternative on the same job with a cleaner API surface, which matters if you plan to build anything on top. MCT gives you an outsourced hedge advisory relationship plus a platform, and for a desk under a few hundred million a month that combination is usually cheaper and safer than employing the equivalent expertise. ICE Compass Analytics is strong analytics for larger desks.

Where all of them stop is the same place. Their pull through models are theirs, calibrated broadly, and you cannot inspect or retrain them on your own funded history. Their best execution knows public investor grids, not your specific approvals, your delivery capacity or your servicing retention appetite this quarter. None of them holds your exception ledger, because exceptions live in your origination system and your email. And none of them makes the position visible to the desk continuously, because they are reporting against your data on their refresh cadence, not on the event.

What a custom build must include

• An event driven position: every lock, change, cancellation, fallout and funding updates the pipeline immediately, so the hedge requirement is always current rather than as of the last extract.
• A loan level pull through model trained on your own lock and funding history, with rate incentive recomputed against live market pricing.
• Best execution across only the outlets you are actually approved for, including servicing value, buy up and buy down, and specified pool payups.
• A hedge recommendation in tradeable terms, by coupon and settlement month, with a clear coverage ratio and a shock analysis at plus and minus 25, 50 and 100 basis points.
• Trade capture with pair offs, margin call tracking against your broker dealer counterparties, and a reconciliation to their statements.
• An exception ledger with amounts, approvers and attribution back to branch and originator.
• Daily profit and loss attribution split into position, market move, pull through change and execution, because until you can attribute the change you cannot tell a bad hedge from a bad month.
• Records that satisfy your accounting treatment, since rate lock commitments and forward sales are carried at fair value and your auditor will ask how each mark was derived.

What this costs and how long it takes

Across the projects Digital Heroes has delivered, a decision layer sitting on top of a bought pricing engine runs $70,000 to $150,000 and ships in 10 to 16 weeks. That covers the event driven position, the pull through model, the best execution comparison and the exception ledger, with your existing engine still producing rate sheets. A full desk platform including trade capture, margin call tracking, profit and loss attribution and investor commitment management runs $200,000 to $500,000 phased over 8 to 14 months.

What drives cost up here specifically: the number of investors and delivery outlets, because each commitment structure is its own modelling problem; whether you retain servicing, since servicing valuation adds a genuine analytics workstream; the number of broker dealer counterparties you clear with, because each statement format is separate reconciliation work; and the quality of your historical lock data. If your loan origination system did not record the market level at lock time, the model cannot learn rate incentive, and reconstructing that history from archived rate sheets is real weeks of work before any modelling starts.

Build versus buy, stated plainly

Buy, and do not call us, if you originate under roughly $100 million a month in conventional agency product, sell best efforts, and do not retain servicing. Your risk is small, your outlets are few, and a hedge advisory relationship covers you at a fraction of a build.

Build the thin layer when you originate roughly $200 million a month or more, retain servicing or are deciding whether to, and your pull through assumption is a number someone set and nobody has revisited. Build more of the desk when your products are not priced properly by any third party engine, which in practice means non-QM, jumbo held on balance sheet, construction to permanent, or a credit union pricing members differently from the market. And build when your position report is an export, because the export is the lag, and the lag is the loss.

How to choose a developer for secondary marketing software

Ask them to explain the difference between best efforts and mandatory delivery, and what a pair off is, before you discuss architecture. If they cannot, they will build you a very clean application that models the wrong thing.

Ask how they would validate the pull through model. The right answer involves holding out a period of your own funded history, backtesting the coverage the model would have recommended against what actually funded, and showing the error by rate incentive bucket. An answer that stops at model accuracy without connecting to hedge coverage has missed the purpose.

Ask what they have integrated. Pulling locks in real time from Encompass is a different problem from a nightly file. Ingesting investor pricing, reconciling a broker dealer statement, and posting fair value marks your auditor accepts are three separate pieces of work. Ask for the specific system and the specific interface.

Ask who owns the model, the code and the data. Your funded loan history is your most valuable asset in this project and it should never sit inside a vendor account you do not control. At Digital Heroes the client owns the repository, the infrastructure and the trained model from the first commit.