Mortgage compliance and audit, end to end

Why mortgage compliance is hard

Mortgage capital markets is a high-regulation environment because the decisions involved — extending credit, pricing risk, retaining borrower data — have direct economic and civil-rights consequences. The regulatory layer is multi-statute, multi-agency, and changes frequently. Doing well at it is not optional.

The good news: most compliance demands reduce to four operational requirements — provenance (where did this decision come from?), reproducibility (can you run it again and get the same answer?), integrity (has anything been changed after the fact?), and access (can authorized people see it; are unauthorized people kept out?). A platform that gets these four right answers most regulator questions quickly.

Nothing on this page is legal advice. Consult counsel for binding compliance interpretations. Where we cite specific rules, we link the primary source — read the source.

ECOA and fair lending in pricing

The Equal Credit Opportunity Act (ECOA) and Regulation B prohibit discrimination in credit transactions on the basis of protected classes (race, color, religion, national origin, sex, marital status, age, source of income, exercise of consumer-protection rights). The CFPB and federal banking agencies enforce; HUD enforces fair-housing adjacency through the Fair Housing Act.

Pricing engines do not, themselves, look at protected characteristics. But they consume rules that you configure, and rules can encode disparate impact even without explicit references. The compliance discipline:

• Audit your rule set for proxy variables. Anything that strongly correlates with a protected class (zip code patterns, name-based heuristics, certain occupation codes) is a flag.
• Run pricing against a fair-lending sample. Synthetic applicants with identical credit profiles but varying protected characteristics. Significant price differences need explanation traced to a documented credit factor.
• Capture the trace. When a borrower challenges a price decision, the per-rule trace plus the historical replay shows precisely which rules fired and why. ECOA Section 615 requires specific reasons for adverse action; the trace produces them.
• Train and retrain. ECOA exposure increases as rule sets grow. Periodic disparate-impact analysis catches drift.

Reference: see the CFPB's ECOA examination procedures (publicly available at consumerfinance.gov) for the auditor's lens.

HMDA reporting from a pricing engine

The Home Mortgage Disclosure Act requires lenders meeting reporting thresholds to submit Loan Application Register (LAR) data annually, covering the application, the borrower, the property, and the pricing outcome. Several LAR fields are pricing-derived: rate spread, total loan costs, total origination charges, points and fees.

The pricing engine is the source of truth for those fields if it's been doing its job. The compliance discipline:

• Persist every priced quote with its trace, ratesheet version, and correlationId — not just the locked one. HMDA requires reporting for applications that didn't close as well.
• Reconcile LAR pricing fields against the trace. The total loan cost reported should exactly match the trace's sum of fee-class adjustments.
• Use the historical replay endpoint to reproduce any disputed LAR row. The numbers must match, deterministically.

Reference: FFIEC HMDA publishes the data dictionary and submission tools.

TRID and disclosure timing

The TILA-RESPA Integrated Disclosure (TRID) rule under Regulation Z governs Loan Estimate (LE) and Closing Disclosure (CD) timing and content. Pricing changes during the loan affect TRID timing — a change in circumstance can require a re-disclosure with a new three-business-day window.

Where the pricing engine intersects TRID:

• The LE's rate, points, and lender credits come from the priced quote. Persist the quote behind the LE so re-disclosure reconciliation is mechanical.
• When pricing changes mid-pipeline, log the change-in-circumstance event with a correlationId that links to the resulting LE re-issue. Auditors will trace the chain.
• Lock-day re-pricing (if the lock breaks and re-locks) requires a new disclosure unless the new lock matches the old terms within tolerance. The lock subsystem's journal entries make the chronology evident.

Reference: the CFPB's TRID Small Entity Compliance Guide is the most readable summary; the rule itself is in Regulation Z.

GLBA Safeguards Rule

The Gramm-Leach-Bliley Safeguards Rule (16 CFR Part 314) governs how financial institutions protect customer information. A pricing platform processes substantial NPI (nonpublic personal information) and must implement the controls the rule requires:

• Designated qualified individual responsible for the information security program.
• Written risk assessment, periodically updated.
• Encryption of customer information in transit and at rest.
• Multi-factor authentication for systems holding customer information.
• Continuous monitoring and security reviews.
• Incident response plan.
• Service-provider oversight.
• Periodic penetration testing and vulnerability assessment.

For a SaaS pricing platform, the practical implementations are field-level encryption of persisted secrets, TLS 1.2+ on every external endpoint, a published capability catalog gating every authenticated call, audit logging of access to NPI (with actingAsOrgId on cross-tenant operations), and PII redaction on logs and traces. RateStack implements each — see /trust/security.

The audit hash chain

Tamper-evident audit logging is increasingly a regulator expectation for material state changes. The pattern:

Each audit log row carries a previous_hash and an entry_hash, where entry_hash = SHA-256(previous_hash || canonical(row)) and canonical(row) is a deterministic JSON serialization of the row contents. To mutate a row without detection, an attacker must recompute every subsequent entry_hash — an indication that the chain has been tampered with.

A verify endpoint walks the chain and reports the first break (or confirms the chain is intact). Run it on a schedule from your monitoring stack; treat any break as a security incident.

Pricing replay as a compliance primitive

Most regulator questions about a historical decision reduce to: can you show me what would have happened? Pricing replay answers this directly. With a versioned ratesheet, effective-dated comp/margin rules, and timestamped program eligibility, the engine reproduces the historical price exactly.

The replay's output — a price plus a trace plus a ratesheet version pin — is the response to most regulatory inquiries about a specific transaction. Combined with the audit chain (which proves the historical record hasn't been altered), the answer is usually complete in minutes.

Operating model for compliance teams

Practical disciplines that compound:

• Quarterly fair-lending sampling. Run synthetic applicants through the engine; review for unexplained disparities.
• Annual rule-set audit. Read every active eligibility predicate and adjustment rule. Most fair-lending issues live in legacy rules that nobody's reread.
• Monthly chain verification. Schedule the audit verify endpoint; alert on non-OK responses.
• Post-incident learnings. Every customer dispute is an audit on your engine. Track patterns; adjust the rule set or the UX accordingly.
• Vendor compliance documentation. Maintain a current SOC 2 (or attestation roadmap), DPA, and subprocessor list. Make the evidence packet routine, not a panic.

None of this is glamorous. All of it compounds. Compliance, treated as an engineering discipline, becomes a query rather than a quarterly fire drill.