Secondary Marketing Software Problems: The 7 That Cost Real Money, and How to Avoid Them

Why does the scope creep from a decision layer into a full desk platform happen so often?

Nearly every secondary marketing project starts with one sentence from the head of capital markets: the hedge trails the locks. That is a narrow problem with a narrow fix. Six weeks later the scope contains trade capture, margin call tracking, investor commitment management and servicing valuation, because this is the first time in years anyone asked capital markets, accounting and post closing what they need. Everybody answers honestly, and the answers add up to a platform.

This is specific to secondary because the desk genuinely does touch all of it. A lock is a commitment, a commitment is a position, a position is a trade, a trade is a mark, and a mark is an accounting entry. There is no natural seam, so nobody in the room can point at the line where the project should stop. The result is priced at $200,000 to $500,000, scheduled over 8 to 14 months, and delivers its first useful output in month seven.

The fix is to force the first release to answer one question: what should the coverage be right now. That means an event driven position, a pull through model, a best execution comparison and an exception ledger. Trade capture and profit and loss attribution become the second release, funded by the first one working. A developer who will not phase it that way is optimising for their own revenue rather than your risk.

What goes wrong with lock and funding history when you try to use it?

The pull through model is the reason to build, and it needs roughly 18 to 24 months of your own lock and funding history. The failure is rarely that the history is missing. It is that the history is missing one column: the market level at the moment each loan locked. Without it the model cannot learn rate incentive, which is the single variable that makes pull through move when it matters, and the output degrades into the blended average you already had wearing better clothes.

This is peculiar to mortgage because a lock is a point in time option granted to the borrower, and its value depends entirely on where the market went afterwards. Most origination systems record the locked price and a rate sheet identifier, not the underlying market level, so reconstructing incentive means pulling archived rate sheets and mapping them back by timestamp. That is real weeks of work and it happens before any modelling starts.

The second data problem is cancellations, which is exactly the outcome you are trying to predict. Fallout records are usually the worst maintained in the system: duplicates, loans re entered under a new number when the borrower changed product, files never closed out at all. Train on that uncleaned and the model learns your data entry habits.

The fix is a paid history assessment before you commit. Two weeks of profiling tells you whether the model is buildable now, buildable after reconstruction, or only buildable on data you start capturing today.

Why do the pricing engine, origination system and broker dealer integrations break after launch?

Three integrations carry this category and all three fail differently. The first is the pricing engine. Optimal Blue and Polly both expose product and pricing, and the break is rarely the interface. It is that loan level pricing adjustments and investor grids change constantly, so a mapping written in March quietly stops matching in September and best execution starts comparing against stale grids without raising an error.

The second is the loan origination system. Pulling locks from Encompass in near real time is a different engineering problem from a nightly extract, and teams that scoped the nightly version find after launch that the position is only ever as fresh as the file. Worse, mid cycle events such as relocks, extensions and product changes often arrive as updates to the same record rather than as new events, so a naive integration overwrites the very history the model needs.

The third is the broker dealer. Every counterparty sends statements in its own format, and pair offs, margin calls and settlement details do not reconcile themselves. Adding a fourth counterparty after go live is fresh work, not configuration, and it is the integration most often left out of the original quote.

The fix is contractual rather than technical. Require the developer to name each interface, state the refresh mechanism, and build a monitored reconciliation for each one, so a drift in an investor grid or a missed lock event raises an alert instead of quietly changing your coverage.

What happens when fair value marks and the audit trail are not covered?

Interest rate lock commitments and forward sale commitments are carried at fair value, which makes every mark your system produces an accounting input rather than a management report. The gap appears when the build treats a mark as a display: the screen shows a number derived from live pricing, and nothing stores the inputs, the pricing source or the model version behind it.

Then the audit asks how the mark on a specific loan on a specific day was derived. If the system simply recomputes it now from current pricing, the answer is worthless, because the pricing that produced the original mark is gone. Teams rebuild the evidence from archived files, which is expensive, or accept a finding, which is worse because it recurs every year.

The same gap shows up in the exception ledger. Extensions, relocks and pricing concessions get approved by phone, and if the system records only the resulting price rather than the amount, the approver and the reason, you cannot attribute exception cost back to a branch or an originator. That report is frequently what pays for the whole project, and it is invisible until somebody asks for it.

The fix is to make marks and exceptions immutable records with their inputs attached, and to design profit and loss attribution split into position, market move, pull through change and execution from the start. Attribution added later needs history you did not keep.

Should you build custom or configure what you already own?

For a large share of lenders the honest answer is configure, and we say so. If you originate under roughly $100 million a month in conventional agency product, deliver best efforts and do not retain servicing, your open risk is small and your outlets are few. Keep Optimal Blue for pricing and take a hedge advisory relationship with MCT, where you are buying expertise as much as software. That covers the risk for a fraction of a build, and the expertise is the part you cannot write in code.

If you already run Optimal Blue or Polly, do not rebuild rate sheet generation, investor pricing ingestion or pricing adjustment maintenance under any circumstances. That is a permanent maintenance treadmill and no lender has ever gained an edge by owning it. ICE Compass Analytics is a serious answer for larger desks wanting deeper analytics without a build.

The build case is narrow. It starts around $200 million a month, earlier if you retain servicing, and it is strongest when your products are not priced properly by any third party engine: non-QM, jumbo held on balance sheet, construction to permanent, or a credit union pricing members differently from the market. The test that settles it is simple. If the change you need is a new pull through assumption, a vendor can do that. If the change you need is your own model trained on your own funded history, no vendor can.

How do hidden costs get into the quote?

Four line items are routinely missing. The first is data reconstruction. If the market level at lock was never recorded, the weeks spent recovering it from archived rate sheets are engineering work, and a quote that assumes clean history is a quote that will change.

The second is counterparty and outlet count. Each broker dealer statement format is its own reconciliation and each investor commitment structure is its own modelling problem. A quote written against two counterparties and three investors does not scale linearly to five and eight, because the second and third structures are where a naive data model breaks.

The third is servicing. Deciding to retain adds a genuine valuation workstream: a servicing asset whose value depends on prepayment expectations, buy up and buy down grids that change the coupon, and specified pool payups that most engines never surface. Teams add servicing to scope in month four and are surprised by the number.

The fourth is model validation. Backtesting the coverage the model would have recommended against what actually funded, by rate incentive bucket, is what makes the model trustworthy, and it is frequently quoted as though it were a test pass. Ask for it as a named deliverable with a named holdout period. None of these come from anyone acting badly. They are the questions a developer who has not built a desk does not know to ask.

What separates a secondary marketing build that works from one that fails?

The first separator is whether the developer can explain best efforts versus mandatory delivery, and what a pair off is, before architecture is discussed. Teams that cannot will build a clean application that models the wrong thing, and you will not find out until the first month the coverage disagrees with the desk.

The second is whether the position is event driven. If every lock, change, cancellation, fallout and funding updates the pipeline immediately, the structural lag is gone. If the position refreshes on a schedule, you have bought a nicer view of the same delay.

The third is whether best execution is restricted to outlets you are genuinely approved for, with your delivery limits and your servicing appetite encoded. Generic best execution comparing public grids will disagree with your reality, and the desk stops trusting it within a month, which is how these systems die quietly.

The last is ownership. Your funded loan history is the asset that makes the model work and it should never sit in a vendor account you cannot export. At Digital Heroes the client owns the repository, the infrastructure and the trained model from the first commit.