Last updated: July 27, 2026
By Kris Drouet, Engineering Executive, in partnership with KORE1
The hard lesson in mortgage tech is that compliance is not something your legal team bolts on after you ship. It lives in your database schema, your disclosure timers, and your deploy pipeline. The engineers who learn that early stop generating audit findings. The ones who learn it late become one.
One of the best engineers I ever hired shipped a feature that broke federal law. He did it trying to help.
The old flow was ugly. When a fee or a rate changed after the borrower’s Loan Estimate had already gone out, a loan officer had to stop, redo the paperwork by hand, and re-send it. Slow. Error-prone. Everybody hated it. So he automated it, and the corrected number flowed straight from the pricing engine into the borrower’s file, and loans that used to slip a week now closed on schedule. It was clean code. Reversible. The kind of quality-of-life fix you would promote someone for at a consumer software company.
Except a change that moves the APR is not a quality-of-life fix in mortgage tech. It is a legal event. Under the TRID rule, certain post-disclosure changes force a corrected Closing Disclosure and a fresh three-business-day waiting period before the loan is allowed to close. By making the correction instant, his automation had quietly been closing a slice of loans inside a window the law says has to stay open. Nobody noticed for months. An audit noticed. By then it had scaled.
He was not careless. He was fast, and he was right that the manual workflow was bad. Nobody had ever told him that the three-day clock was not an inconvenience to optimize away. It was the product.
I have spent 25 years building software inside regulated industries, most of it in mortgage tech and fintech, and I have watched some version of that story play out more times than I can count. It is almost never a talent problem. The engineers are good. What gets them is that the instincts rewarded in unregulated software, ship it, iterate, apologize later, are the exact instincts that create legal exposure the first time your code touches a credit decision. I wrote the broad version of this in my piece on engineering leadership in regulated industries. This is the mortgage-specific, compliance-specific version, the one where the gap between good engineering and legal engineering is widest, and the reason KORE1 keeps placing engineers through their engineering staffing agency into fintech teams that already have plenty of raw talent.
So What Does “Compliance” Actually Mean When You Write the Code?
In mortgage technology, compliance means your systems can prove, on demand, that every loan was disclosed on time, priced without illegal bias, decided for reasons you can name, and stored in a record an examiner can reconstruct. It is not a document. It is a set of properties your architecture either has or does not.
Read that again. Prove, on demand. Those two words are doing all the work.
The people who check are not your users filing a support ticket. They are federal and state examiners, plus the occasional fair-lending litigator, and they arrive with subpoena power and a checklist. What they want is not your intentions. They want evidence, generated by your systems, that the rules were followed on every loan and not just the one you are demoing. If your platform cannot produce that evidence quickly, you do not have a compliance program. You have a hope.
The Data Is a Legal Record, Not Just State
Here is the first thing that ambushes people coming from consumer software. Your database is not just application state. Large parts of it are a legal record you are required to keep, report, and certify as accurate.
Take the Home Mortgage Disclosure Act. Lenders above a fairly low volume threshold have to collect loan-level data on every application, including the applicant’s race, ethnicity, sex, age, income, and whether you approved or denied them, then file all of it with the government once a year. That filing, the loan/application register, gets certified by a named human being who is personally attesting that it is accurate and complete. Then it gets published. Publicly. Regulators, journalists, and plaintiffs’ lawyers all read the HMDA data looking for patterns.
So when an engineer “cleans up” a field, backfills a null, or dedupes what looks like a junk row, they may be editing a federal filing. I once watched a well-meaning data migration silently recode a batch of denial reasons because somebody assumed a lookup table was safe to renumber. It was not. That is not a bug ticket. That is a resubmission, a certification someone now has to un-sign, and an uncomfortable call with a regulator.
You cannot just DELETE. Sometimes you cannot even UPDATE without leaving a trail. The register is due every March 1 whether your sprint went well or not, the records have to stay reconstructable for years, and “we refactored that table” is not an answer anyone in an exam room wants to hear. This is exactly where operational discipline stops being a nice-to-have and starts being the thing that keeps you out of a consent order.
A Disclosure Is a Deadline, and the Deadline Lives in Your Code
Come back to the three-day clock from the top of this piece, because it is the cleanest example of a rule that is really a spec.
The TILA-RESPA Integrated Disclosure rule, everyone just says TRID, folds two consumer-protection laws into a pair of forms and a set of hard deadlines. The Loan Estimate has to reach the borrower within three business days of application. The Closing Disclosure has to be in their hands at least three business days before the loan closes. And when certain things change after the fact, an APR that moves outside tolerance, a switch in loan product, a prepayment penalty that gets added, the corrected disclosure resets that three-day clock back to zero.
Every one of those sentences is a timer, a state machine, and a pile of edge cases somebody has to own. Business days are not calendar days. And “received” carries a legal meaning that has nothing to do with the moment your system fired off an email. A rate lock that expires over a holiday weekend does date math your naive library will get subtly wrong, and subtle is the dangerous kind. Get it wrong and you do not get a failed test. You get a loan that closed illegally. No rollback fixes that.
The instinct to make the slow, manual, annoying step instant is correct almost everywhere else in software. In a disclosure workflow it is the single most dangerous instinct you can bring to work. The CFPB spells out the actual timing mechanics in its TILA-RESPA disclosure guidance, and it is worth having an engineer, not just counsel, sit down and actually read it before touching that code.
Your Model Can Discriminate Without Anyone Deciding To
This is the section that keeps me up at night in 2026, because everyone is bolting AI onto underwriting and pricing right now, and most teams do not see the trap until they are standing in it.
The Equal Credit Opportunity Act draws a hard line. You cannot discriminate in lending on the basis of race, sex, age, national origin, or the other protected classes it names. Fine. Nobody sets out to. The problem is disparate impact. It hides in plain features. A model can produce outcomes that fall harder on a protected group even when the protected attribute is nowhere in the training data, because some innocent-looking feature, a zip code, a school, a spending pattern, quietly stands in for it.
When a team tells me their pricing model is fair because they excluded race from the inputs, I ask to see the data. Show me the outcomes by group, not the inputs. Fairness is a property of what comes out, not a checkbox on what went in, and the only way to know is to measure the results and keep measuring them.
Then it gets sharper. When you deny someone credit, the law requires you to tell them the specific, principal reasons why. Not “the model said no.” The actual reasons. The CFPB has made this explicit: a complex or “black-box” model is not an excuse, and if your algorithm cannot produce an accurate, specific reason for a denial, you are not permitted to use it for that decision. They put it in writing in Circular 2022-03.
Read that as an engineer, not a data scientist. Explainability is not a research nicety you get to add in a later quarter. It is a legal precondition for shipping the model at all. Full stop.
Vendor Code Is Your Compliance Problem, Not Theirs
Almost nothing in a mortgage stack is built from scratch. You pull credit through the bureaus, run loans through Encompass or a similar origination system, hand data to servicers, sub-processors, e-signature vendors, and a dozen APIs. Here is the part people get wrong. When a vendor mishandles your borrowers’ data, the regulator does not go knock on the vendor’s door. It knocks on yours.
The Gramm-Leach-Bliley Act, through the FTC’s Safeguards Rule, requires a real information-security program around customer financial data. Encryption at rest and in transit. Multi-factor authentication for anyone who can reach customer information. Access controls you review on a schedule instead of the day someone leaves. And since May 2024, notice to the FTC within 30 days of a breach touching 500 or more people. That clock is real. None of that is the security team’s private homework. It shapes how you design data flows, which services are even allowed to talk to each other, and what you are permitted to write into a log line.
The integration tax on all of this is real, and I broke down the money-and-timeline side of it in the real cost of an Encompass integration. The compliance side is simpler to state and harder to live with: every integration is also a data-sharing decision you are personally on the hook for. A vendor’s SOC 2 report is a nice thing to have in the file. It is not a shield. That is a big part of why regulated lenders reach for security-focused engineering talent instead of hoping a generalist picks up the rules on the way through.
Where Each Rule Actually Lives in Your Stack
If you are onboarding an engineer who has never worked in mortgage tech, this is the one-page version I wish someone had handed me on day one. It maps each rule to the part of the system it actually touches, and the mistake that tends to surface first.
| Regulation | Where it lives in your stack | What breaks the first time |
|---|---|---|
| TRID / TILA-RESPA (Reg Z) | Disclosure timing logic, date math, workflow state machine | Automating a fee or rate correction that skips the mandated three-day re-disclosure |
| ECOA / fair lending (Reg B) | Underwriting and pricing models, adverse-action messaging | A model that cannot state a specific, accurate reason for a denial |
| HMDA (Reg C) | Loan/application database, reporting exports, data migrations | A “cleanup” that alters a field on a certified federal filing |
| GLBA Safeguards Rule | Auth, encryption, access control, vendor data flows, logging | Writing or shipping customer data somewhere it was never allowed to go |
| FCRA | Credit-pull integrations, storage of report data | Reusing or holding a credit report past its permissible purpose |
None of it is exotic. It just carries consequences that generic web software does not, and the failure modes cluster in the same few places every time.
Hire for the Scar Tissue, Not the Résumé
You can teach the specific rules. You cannot teach the reflex, and the reflex is what actually protects you.
When I interview an engineer for a regulated build, I am not looking for someone who can recite Reg Z from memory. I am looking for someone with a scar. Ask them about a time a technically correct change caused a problem anyway, and listen for whether they think past the diff, out to who the change lands on. The engineers who thrive in mortgage tech are usually the ones who have already been burned once and now ask “who does this decision affect, and what does the law say about it?” before they open the pull request, not after.
This is the crossover KORE1 has spent two decades hiring for. They have placed engineers across more than 30 U.S. metros and hold a 92 percent twelve-month retention rate, and in the regulated corner of that work the pattern is boringly consistent. The person who lasts is rarely the flashiest coder in the room. It is the one who treats compliance as part of the definition of done. If you are trying to build or backfill a team that can hold that line, it is worth a conversation with a recruiter who staffs regulated engineering roles before you hire the résumé that looks great and has never once shipped inside a loan.
The Compliance Questions Engineering Leaders Bring Me
Isn’t compliance really legal’s job, not engineering’s?
Legal owns the rules. Engineering owns whether the system actually obeys them. The rules only become real as behavior in code, timers, schemas, and access controls, and if your architecture cannot enforce a constraint then legal writing it down changes nothing. The strongest regulated teams I have seen treat compliance as a shared property of the system, with counsel defining the constraint and engineering guaranteeing it holds on every loan.
We’re adding an AI underwriting assistant. What trips us first?
Explainability, almost every time. The moment your model influences an approval or a denial, ECOA requires you to state the specific reasons behind an adverse action, and a model you cannot interrogate cannot produce those reasons. The CFPB has already said “the algorithm is complicated” is not a defense. Solve the reason-code problem before you ship the model, not in the cleanup sprint afterward.
How much damage can a single engineer’s change actually do?
Enough to make a lender restate federal filings or buy loans back. A disclosure-timing bug can invalidate closings. A quiet model change can create a fair-lending pattern that surfaces in the public HMDA data a year later. A logging change can turn into a reportable breach. None of these are hypotheticals I am reaching for, and each one traces back to a pull request that looked completely normal in review.
Do we need engineers who already know mortgage rules, or can we train them?
Train the rules. Hire the instinct. The specific regulations are learnable in a few weeks, but the reflex to ask what a change costs downstream is not, and that reflex is what keeps you out of trouble. Seed a new team with at least one or two people who have already shipped inside a regulated flow, then let them set the standard everyone else calibrates to.
Which system should we be most careful with?
Anything on the path between a credit decision and the borrower. Underwriting, pricing, disclosures, and adverse-action messaging are where a technical mistake turns into a legal one fastest. Payments and servicing matter too, but the decision-to-disclosure path is where I put my most careful engineers, my heaviest change control, and my most paranoid tests.
What I Tell Every Leader Walking Into This
The teams that struggle in mortgage tech are not the ones short on talent. They are the ones that imported a set of instincts that were correct at the last job and never got told which ones to check at the door.
Compliance is not the thing slowing your engineers down. Sloppiness is. Rework is. A regulator’s letter absolutely is. A team that designs for the rules from the first commit looks slower on day one and moves much faster over any horizon that matters, because it is not forever ripping out things that were never legal to build in the first place.
That is the version I can fit in a paragraph. The real one is longer, and it depends on your stack, your regulators, and where your engineers are coming from. If you are working through it and want to compare notes, connect with me on LinkedIn. I answer.
