Mortgage Compliance Testing Software Problems: The 7 That Surface in an Exam, and How to Avoid Them

Why does the test keep getting scoped as a report rather than a gate?

Compliance projects are usually specified by the people who consume the output, which means quality control and audit. They describe what they need to see, so the requirement becomes a set of tests, a findings queue and a dashboard. Everyone signs it off because it is exactly what was asked for.

The trouble is that the exposure is not created where the report is read. It is created at three o'clock on a Thursday when a processor adds an appraisal re inspection fee, types a reason into a free text field, and does not know that the reason does not constitute a valid changed circumstance for that fee. No report catches that in time. The Loan Estimate went out, the tolerance bucket is set, and the only remedy left is a cure within 60 days of consummation.

This is specific to mortgage because the timing rules are unforgiving in a particular way. A revised estimate needs a documented valid changed circumstance delivered inside its own window, and it cannot reset tolerance once the Closing Disclosure has been provided. Lender fees sit in the zero tolerance bucket. Recording fees and services from providers on your written list sit in the ten percent cumulative bucket. None of that is ambiguous, and all of it is decided at the edit.

Scope the first release as an evaluation on every material edit that names the bucket and the dollar amount to the person making the change, in words about this loan. That is a different product from a compliance report, and it converts most cures into non events.

What goes wrong with the reportable data behind the register?

Every February the same scene plays out. Someone extracts the loan application register, runs it through the filing platform, and gets back thousands of edits across the syntactical, validity, quality and macro quality categories, each of which must be resolved against source documents.

The structural cause is that reportable fields are collected as a by product of origination rather than owned as an obligation. The universal loan identifier, rate spread, automated underwriting results, credit score model, debt to income, combined loan to value, denial reasons and demographic information all originate at different moments with different people, and nobody owns the register until it is due.

Migration makes this worse. Lenders want history in the compliance layer so fair lending analysis can look backwards, and historical registers carry fields corrected during the filing scramble without those corrections ever going back to the origination system. So you import two versions of the truth, the register as filed and the loan file as recorded, and they disagree on exactly the fields examiners care about.

Import the filed register as its own dated artefact rather than merging it into loan data, and run the filing platform edit rules nightly against the live population from day one. A field that will fail in February then fails in June while the file is open and the source is reachable. Lenders filing quarterly need this more, since the compression between quarters leaves no room for a correction scramble.

Why do origination system and compliance engine integrations break after launch?

The integration that passes acceptance testing is a nightly extract, and a nightly extract cannot power a gate. That is the first break, and it is architectural rather than incidental. If your origination system cannot emit events when a fee, a provider, a product or a date changes, the gate degrades into the checkpoint test you were trying to escape.

The second break is field level drift. Lenders reconfigure origination systems. A custom field carrying the changed circumstance reason gets repurposed, a fee is renamed, a new fee code appears for a new investor product, and the compliance layer keeps testing against a mapping that no longer describes reality. Nothing errors. The tests simply stop seeing a category of fee.

The third break is documents. A value taken from an origination system field is not evidence of what was disclosed. Evidence is the document that went out, its version, the issue timestamp and the delivery record. If disclosures are retrievable only as images, extracting disclosed values is a separate workstream, and it quietly degrades when a template changes.

Three defences: alert on category silence rather than only on failures, treat fee and field mappings as versioned configuration with a named owner who reviews them when the origination system changes, and reconcile disclosed values against system values continuously.

What happens when lineage and state thresholds are not covered?

Two gaps produce most of the pain that arrives years later.

The first is lineage. In an exam you must demonstrate, for a specific loan, what was disclosed, when it was issued, how it was delivered and to whom, and how the tested value relates to that document. A pass or fail held against a value with no link to the document that carried it hands an examiner a conclusion and asks them to trust it. Business day arithmetic sharpens this: almost every disclosure rule is a date count, almost every failure is off by one against the wrong calendar, and unless the system stores the count it used, the reviewer cannot see the arithmetic.

The second is state thresholds. Federal high cost tests are one layer. New York, North Carolina, Massachusetts and Illinois all maintain their own high cost regimes with their own trigger arithmetic, and a lender licensed in twenty states runs twenty overlapping test sets. The qualified mortgage points and fees cap is tiered by loan amount and adjusted annually.

Held as constants in code, those thresholds are a silent liability, because nobody can tell you whether the engine is current and everybody assumes it is. Held as effective dated data with a source reference and a review date, the question has an answer. Every new state is genuine test development, not a configuration flag, and pricing it as a flag is how expansion becomes an unbudgeted quarter.

Should you build custom or configure what you already own?

Do not rebuild the federal and state rules engine. ICE ComplianceAnalyzer runs a mature rule set and you should keep it, because reimplementing disclosure and high cost testing from scratch is a maintenance commitment that grows every year and returns nothing to your business.

If you originate in a small number of states at modest volume and your quality control team is comfortably keeping up, buying is the right answer. A compliance engine plus an audit workflow product plus a consultant for the annual analysis suits that shape, and a build would be over engineering. Wolters Kluwer sits deep in document and content compliance and is a sound answer for disclosure generation. Ncontracts is strong on governance across policy, vendor and findings management. ACES Quality Management is a capable audit workflow product.

What none of them do is sit inside the processor edit that creates the exposure, own the lineage tying a tested value to a specific document image and delivery record, or continuously validate your register against the live pipeline. The gap is not rules. It is timing, lineage and population coverage.

Build alongside when two or more of these hold. Your register regularly returns edits in the thousands. You are licensed in enough states that nobody can confirm your thresholds are current. You have taken a finding, a repurchase demand or a restitution obligation on a pattern that ran for months. Cures are a recurring monthly number rather than an exception. Or you subservice, sell to multiple investors or run correspondent channels where each counterparty wants its own evidence package.

How do hidden costs get into the quote?

A first release covering the pre close tolerance and timing gate, lineage capture and the continuously validated register runs 60,000 to 140,000 dollars over 10 to 14 weeks in Digital Heroes delivery experience. A full platform adding quality control sampling and workflow, fair lending analysis, state threshold management, findings tracking with remediation and the exam evidence export runs 180,000 to 400,000 dollars over 6 to 12 months. Four things escape the estimate.

State count is the largest. Each high cost regime is test development plus test data plus a review cycle with counsel, and lenders consistently price the second state as if it were the twentieth.

How your origination system exposes data is the second. Real time events versus a nightly extract is not a preference, it changes what the system can be.

Document retrieval is the third. If disclosures exist only as images, pulling actually disclosed values off them is a separate workstream with an ongoing maintenance tail every time a template changes.

Interpretation is the fourth and it is schedule risk rather than budget. Most lenders find that two departments hold different views of what constitutes a valid changed circumstance for a given fee. Writing those interpretations down with counsel in the room is what makes the system defensible later, so it deserves a line in the plan rather than being absorbed.

What separates a compliance build that works from one that fails?

Ask a developer how they compute a business day. It sounds trivial and it is the most common defect source in this domain. The answer should cover which calendar applies, which events start which counts, how the delivery method changes the receipt presumption, and how the system stores the count it used so a reviewer can see the arithmetic rather than trust it.

Ask how they will prove what was actually disclosed. A value read from an origination system field is not evidence. Developers without regulated experience will not think to ask for the document version, the issue timestamp and the delivery record, and that omission is invisible until an exam.

Ask what they have integrated, specifically. A real time event feed from a loan origination system, a compliance engine interface, a document repository and a filing platform submission are four different problems.

Be direct about where automated models belong. Document extraction earns its place, pulling disclosed values off issued documents and comparing them to system fields, which is exactly where quiet divergence hides. Triaging changed circumstance narratives that are too generic to support the fee they justify is also useful. What should never be automated is the pass or fail determination on a regulatory test, because you must show the rule version, the inputs and the arithmetic.

Then ask about threshold maintenance after launch, because a system nobody updates is worse than no system once people trust it. And settle ownership: the repository, the infrastructure accounts and the documented test interpretations should be yours from the first commit, since the interpretations are what you hand an examiner to explain how the system decides.