Mortgage Compliance Testing Software: How Do You Find a Fee Tolerance Violation Before the Loan Closes Instead of During the Exam?

Why post closing sampling is a structurally late control

The standard quality control design at most lenders is a random post closing sample reviewed by a small team, plus a targeted sample for higher risk categories. By the time that review runs, the loan closed, the money moved, and any fee tolerance violation is now a cure obligation with a 60 day clock and a refund cheque. The control did not prevent anything. It counted.

That would be tolerable if the sample caught everything, but a sample is a sample. The loans outside it carry the same defect rate and nobody looks at them until an examiner does, and the examiner looks at the population, not your sample. The uncomfortable arithmetic is that a defect pattern running quietly through your production for three quarters becomes restitution across every affected loan, not across the sampled ones.

The tooling is usually a compliance engine that tests at a few checkpoints, an audit workflow product where reviewers record findings, an annual reporting process run in Excel by one person, and a fair lending review a consultant performs after filing. Each piece works. The gaps between them are where findings live.

Problem 1: tolerance is decided at disclosure time and tested at exam time

The TRID framework is unforgiving in a very specific way. The Loan Estimate has to go out within three business days of application. A revised estimate needs a valid changed circumstance, documented, and delivered inside its own window, and it cannot reset tolerance once the Closing Disclosure has been provided. The Closing Disclosure must be received three business days before consummation. Lender fees sit in the zero tolerance bucket. Recording fees and services from providers on the written list sit in the ten percent cumulative bucket. Cures must be delivered within 60 days of consummation.

Nothing there is ambiguous. What breaks is that the decision to add a fee, or to re disclose, or to record a changed circumstance, happens in a processor workflow at 3pm on a Thursday, and the test that would have caught it runs at a checkpoint days later or after closing. The processor is not being careless. They added an appraisal re inspection fee because the appraiser asked for one, and nobody told them the reason text they typed does not constitute a valid changed circumstance for that fee.

What a custom gate does is move the test to the moment of the change. Any edit to a fee, a provider, a product or a date evaluates immediately against the last issued disclosure, and if the change creates a tolerance exposure or requires a re disclosure, the system says so to the person making the change, in words about this loan, with the specific bucket and the specific dollar amount. That is a different product from a compliance report, and it is the difference between a cure and a non event.

Problem 2: the annual reporting file is assembled from fields nobody owns

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: syntactical, validity, quality and macro quality. Each one has to be resolved against source documents, and many trace back to a field that was typed once in the origination system, months ago, by someone who had no idea it was a reportable data point.

The structural problem is that reportable fields are collected as a by product of origination rather than as a first class obligation. The universal loan identifier, the rate spread, the automated underwriting system results and recommendation, credit score model, debt to income, combined loan to value, the reasons for denial, and the demographic information all come from different moments in the process and different people. Nobody owns the register until the register is due.

A custom build turns the register into a continuously validated object rather than an annual export. Every loan carries its reportable fields from application onward, the edit rules run nightly against the whole live population, and a field that will fail in February fails in June while the file is still open and the source is still reachable. Lenders who file quarterly need this even more, because the compression between quarters leaves no room for a two week correction scramble. The measurable outcome is not elegance, it is that the February exercise stops being a project.

Problem 3: fair lending is analysed once a year, on data you already filed

Your examiner will run your register looking for pricing disparity and application outcome disparity by prohibited basis characteristics, and for geographic patterns in where you did and did not lend. Most lenders run the same analysis once, after filing, through a consultant. That means any pattern in your production is discovered roughly fourteen months after it started.

This is a reporting problem that a custom build solves cheaply, because the data is already being validated for the register. Running comparative pricing and outcome analysis monthly on your own live population, with the same methodology your examiner uses, converts a yearly surprise into a monthly management report. It will not tell you a disparity is unlawful, and any developer who claims it does is selling something dangerous. It tells you where to look, early enough for your counsel to look with you.

Problem 4: your state tests are not the federal tests

Federal high cost thresholds 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. Add the qualified mortgage points and fees cap, tiered by loan amount and adjusted annually, and the number of thresholds you must keep current is not something a spreadsheet should hold.

Configured products handle the major states. The gaps show up in the states you entered last year and in the annual threshold updates that arrive quietly. A custom build treats thresholds as effective dated data with a source and a review date, so the question of whether your engine is current has an answer somebody can look at rather than assume.

What the incumbents do well, and where they stop

ICE ComplianceAnalyzer runs a mature federal and state rule set and you should keep it. Rebuilding federal disclosure and high cost testing from scratch is a maintenance commitment that grows every year and returns nothing to your business. Wolters Kluwer sits deep in document and content compliance and is a reasonable answer for disclosure generation. Ncontracts is strong on the governance side: policy, vendor and findings management across a bank. ACES Quality Management is a capable audit workflow product and a lot of quality control teams run happily inside it.

Where all of them stop is the same boundary. They test what they are given, at the moments they are invoked, and they hand back results. They do not sit inside the processor edit that creates the exposure. They do not own the lineage that ties a tested value back to the specific document image, the timestamp it was issued, and the delivery evidence. They do not continuously validate your register against your live pipeline. And the audit workflow product records that a reviewer found a defect without connecting that defect to the pattern across the population that produced it. The gap is not rules. It is timing, lineage and population coverage.

What a custom build must include

• A pre close gate that evaluates on every material edit, not at checkpoints, and blocks or warns at the moment the exposure is created.
• Full lineage per tested value: which document it came from, which version, when it was issued, how it was delivered and to whom.
• Business day and holiday aware timing tests, since almost every disclosure rule is a date count and almost every failure is an off by one against the wrong calendar.
• Changed circumstance capture as structured data with a reason category and supporting evidence, not a free text box.
• A continuously validated reporting register with the filing platform edit rules running nightly across the live population.
• Effective dated threshold tables for federal and each licensed state, with a source reference and a review date.
• Monthly comparative pricing and outcome analysis on your own population, produced for counsel rather than for a dashboard.
• An exam evidence export that assembles, for any loan, the full disclosure timeline with the documents attached in the order an examiner reads them.

What this costs and how long it takes

Across the projects Digital Heroes has delivered, a first release covering the pre close tolerance and timing gate, lineage capture and the continuously validated register runs $60,000 to $140,000 and ships in 10 to 14 weeks. That is the piece that changes outcomes, because it stops defects rather than counting them. 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 phased over 6 to 12 months.

What drives cost here specifically: the number of states you are licensed in, because each high cost regime is real test development and real test data; how your origination system exposes data, since a nightly extract cannot power a gate; whether disclosure documents are retrievable as structured data or only as images, because pulling actually disclosed values off a PDF is a separate workstream; and the state of your historical data if you want fair lending analysis to look backwards as well as forwards.

Build versus buy, and when buying is the right answer

Buy, and we will tell you so, if you originate in a small number of states, run modest volume, and your quality control team is comfortably keeping up. A compliance engine plus an audit workflow product plus a consultant for the annual analysis is a reasonable stack for that shape, and a build would be over engineering.

Build when two or more of these are true. Your register regularly returns edits in the thousands and February is a known crisis. You are licensed in enough states that nobody can tell you with confidence whether your thresholds are current. You have taken a finding, a repurchase demand or a restitution obligation on a defect pattern that ran for months before anyone saw it. Your fee tolerance 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 to choose a developer for compliance testing software

Ask them how they compute a business day. It sounds trivial and it is the single 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 tested value taken from an origination system field is not evidence. Evidence is the document that went out, its version, the timestamp, and the delivery record, all linked to the tested value. Developers who have not done regulated work will not think to ask for this.

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

Ask about test data and threshold maintenance after launch, because thresholds change annually and a system nobody updates is worse than no system, since people trust it. Then ask who owns the code. At Digital Heroes the client owns the repository and the infrastructure accounts from the first commit, and any developer hedging on that is building a dependency you will pay for later.