Chapter 36: Technology: LOS Systems, CRM, Pricing Engines, AI, and the Digital Mortgage

"Every system in this business is very good at telling you what happened and completely silent about what didn't." — constructed; the working premise of this chapter

Overview

On day 37 of the Linden Street file — a Friday afternoon in the middle of October — the loan officer opened the pipeline screen, looked at loan L-2214, and saw nothing wrong.

The file was accurate on that screen. Conditional approval issued. Nine of eleven conditions cleared. No task overdue. No exception flagged. Status green. Every number in the system was correct, every integration had fired, every document was indexed, and the borrowers were four days from a closing date that had been on the calendar since day 4.

The file was, at that moment, four days into an eleven-day stall that would blow the rate lock, miss the closing date, and cost somebody \$914.38. Nothing on the screen said so, because nothing was late.

That is this chapter's argument in one paragraph, and it is not an argument against technology. The tools in this business are genuinely good and have made real work faster. A credit report comes back in seconds. An asset report arrives without anyone mailing a bank statement. A borrower can sign an initial disclosure package at eleven o'clock at night from a phone in a parked car. The Linden Street file cleared four underwriting conditions in a single day because a borrower photographed four documents and a system indexed them in the time it used to take to find a fax cover sheet.

But every one of those systems measures events. None of them measures absence. And the losses in this business — the lock that expires, the condition nobody escalated, the borrower who wires \$25,376.34 to a criminal — happen in the space between events, which is exactly where the software has nothing to say.

So this chapter does two things at once. It teaches you the stack: what a loan origination system is, what a point-of-sale portal does, what a customer relationship management database is worth, how a pricing engine assembles a quote, how income and assets get verified electronically, and what it took legally to make an electronic promissory note enforceable. And it teaches you the seams — the places where two systems each hold a version of the truth, where a model produces an answer nobody can explain, and where an ordinary email costs a family their down payment.

In this chapter, you will learn to:

• Name the systems in your stack and say which one is authoritative for which fact
• Describe what an LOS does with data, documents, workflow, and disclosures — and what it does not do
• Explain what a POS collects and what it structurally cannot ask
• Make the business case for a CRM database and state the legal limits on taking it with you
• Read a pricing engine's output as software output, not as a rate
• Distinguish what digital verification settles from what it leaves open
• Explain what a transferable record is and why an eNote needed one
• State which uses of AI in origination are real and why automated credit decisions are constrained
• Run a wire-fraud prevention protocol and act correctly in the first hour after a loss

Learning Paths

🎓 Exam — §36.7 and §36.9. E-SIGN and UETA appear on the SAFE test, and adverse action notification is heavily tested. Know that ECOA and FCRA impose separate notice obligations. 🏠 New LO — §36.1, §36.4, and §36.10, in that order. The stack, the database that is yours, and the fraud that will be attempted on one of your files this year. 🤝 Partner — §36.3 and §36.10. What your buyer sees in the portal, and the wire warning you and the listing side must give in the same words. 📊 Operations — §36.2 and §36.5, and the pipeline report in §36.11 that almost no LOS ships turned on by default.

36.1 The loan officer's actual software stack

Ask a loan officer what software they use and you will get the name of whatever they logged into most recently. Ask what the stack is and most cannot draw it, which matters, because the errors that cost money are almost never inside a system. They are between two systems that each believe they are right.

There are seven categories. You will not use all seven at every employer, and two of them are frequently bundled into one login, but they are seven different jobs.

THE STACK — seven jobs, and who owns each                [constructed teaching example]

  ┌─────────────────────────────────────────────────────────────────────────┐
  │ 1. CRM              people, not loans. Past clients, partners, leads,   │
  │                     the borrower who is not ready until next spring.    │
  │                     OWNED BY: you (subject to §36.4's limits)           │
  └──────────────┬──────────────────────────────────────────────────────────┘
                 │ a lead becomes an application
                 ↓
  ┌─────────────────────────────────────────────────────────────────────────┐
  │ 2. POS              the borrower-facing front door. Online 1003,        │
  │                     document upload, status, secure messaging.          │
  │                     OWNED BY: the lender. SEEN BY: the borrower.        │
  └──────────────┬──────────────────────────────────────────────────────────┘
                 │ data and documents flow in
                 ↓
  ┌─────────────────────────────────────────────────────────────────────────┐
  │ 3. LOS              THE SYSTEM OF RECORD. The loan's data, its imaged   │
  │                     documents, its milestones, its conditions, its      │
  │                     disclosures, its audit trail.                       │
  │                     OWNED BY: the lender. AUTHORITATIVE for the file.   │
  └───┬──────────┬──────────────┬───────────────┬──────────────┬────────────┘
      │          │              │               │              │
      ↓          ↓              ↓               ↓              ↓
  ┌────────┐ ┌────────┐ ┌──────────────┐ ┌────────────┐ ┌──────────────┐
  │4. PPE  │ │5. AUS  │ │6. VERIFICA-  │ │7. E-SIGN / │ │  SETTLEMENT  │
  │pricing │ │agency  │ │   TION       │ │  eCLOSING  │ │  title, MI,  │
  │engine  │ │engines │ │credit, income│ │            │ │  appraisal,  │
  │+ lock  │ │(Ch.15) │ │assets, empl. │ │            │ │  flood, fees │
  │desk    │ │        │ │ (§36.6)      │ │  (§36.7)   │ │              │
  └────────┘ └────────┘ └──────────────┘ └────────────┘ └──────────────┘

  THE SEAMS ARE WHERE FILES DIE. Every arrow above is a place where two
  systems can hold different versions of the same fact.

Read that diagram twice, because the shape of it is the lesson.

The LOS sits in the middle and is authoritative. When the LOS and any other system disagree about the loan amount, the property address, the borrower's income, or which conditions are outstanding, the LOS is what the underwriter reads, what the closer works from, what gets delivered to the investor, and what an examiner will pull three years from now. That is not a compliment to the software. It is a statement about which record has legal consequences.

Everything else is either upstream or a service. The CRM and the POS feed it. The pricing engine, the automated underwriting engines, the verification vendors, and the e-sign platform each answer one question and hand back an answer. The settlement side — title, appraisal management, mortgage insurance, flood, fee services — are outside companies reached through integrations that look, from inside the LOS, like buttons.

And then there is the eighth thing, which is not on the diagram because it does not have a vendor: your phone and your calendar. After eighteen years, the two pieces of technology that have generated the most closed volume for me are a telephone and a recurring calendar block. The Linden Street file started with a phone call at 8:40 in the morning, and every genuinely bad moment in it was resolved by somebody calling somebody. Do not let a chapter about software leave you with the impression that the software is the work.

Which system is authoritative for what

This is worth writing down, because new loan officers regularly ask the wrong system a question and believe the answer.

That last row is the one that separates a five-year career from a twenty-year one, and §36.4 is about it.

Why the seams fail

Three structural reasons, and all three show up in real files.

Data is copied, not shared. A borrower types an employer name into the POS. It lands in the LOS. Someone corrects a typo in the LOS. The POS still shows the typo, because the flow was one-way. Now the verification request goes out with one spelling and the paystub comes back with another, and a processor spends forty minutes on a problem that was created by a keystroke.

Systems have different clocks. The pricing engine knows the lock expires on day 42. The LOS milestone screen knows the file is at conditional approval. Neither one knows the other's business well enough to say "the lock on this file expires before its next scheduled event." Two systems, two clocks, and no alarm — which is precisely what happened on the Linden Street file.

Nobody owns the space between. Every system has an owner: the LOS has an administrator, the pricing engine has a secondary desk, the POS has a marketing or IT owner. The seam between them has no owner, and the seam is where the file lives.

The rest of this chapter walks the stack, one system at a time, and names what each one is good at and where it hands you back a problem.

36.2 The LOS

The loan origination system is the system of record for a mortgage loan. It is not one product doing one thing; it is at least five things sold in one login, and confusing them is how loan officers form wrong expectations about what it will do for them.

The five things an LOS actually is

1. A structured database of the loan. Every fact about the file — borrower names, income components, debts, assets, property, program, rate, fees, dates — lives in named fields. The field names are not arbitrary. Most systems map to the data dictionary published by MISMO, the Mortgage Industry Standards Maintenance Organization, a standards body affiliated with the Mortgage Bankers Association. Standardization is what lets an appraisal from one company, a credit report from another, and a closing package from a third all be read by the same system.

The agencies extend that structure at the delivery end. Loans sold to Fannie Mae and Freddie Mac are delivered as structured datasets, and closing data has its own standardized dataset as well, all under the joint uniform-data program the agencies operate at their regulator's direction. The practical consequence for you is blunt: the data has to be right in the field, not just right on the document. A correct paystub in the imaged file does not help if the income field says something else. The field is what travels.

2. A document repository. This is document management: the imaged loan file, with every document classified by type, stamped with who uploaded it and when, versioned when it is replaced, and retained. Retention is a legal requirement rather than a housekeeping preference. Regulation B requires application records to be retained for a period measured in months after notification; Regulation Z has a general retention period measured in years, and a longer one specific to the Closing Disclosure; HMDA has its own. The periods differ by rule and have been revised — verify the current periods with your compliance department rather than trusting a number in a textbook.

3. A workflow engine. Milestones, tasks, roles, permissions, and conditions. Chapter 6 taught the pipeline and the milestones themselves; what matters here is that the LOS implements them as state changes. A file is at "Submitted" until someone or something moves it to "Conditional Approval." That is the entire model, and §36.11 returns to what that model cannot see.

4. A compliance and disclosure engine. The LOS generates the Loan Estimate and the Closing Disclosure, runs tolerance testing against the baselines, tracks the timing clocks, produces the HMDA data, and tests against high-cost and higher-priced thresholds. Chapter 22 owns what those disclosures say and when they are due; Chapter 24 owns the statutes behind them.

What the LOS does not do is comply. It executes a configuration. Someone decided which fee goes in which section, which tolerance bucket applies, which state disclosures fire at which trigger. That configuration is maintained by people, it lags rule changes and fee changes, and it is wrong sometimes. A loan officer who says "the system generated it, so it's right" has misunderstood the relationship. The system generated what it was told to generate.

5. A set of integrations. Credit, AUS, appraisal ordering and delivery, title, flood, mortgage insurance, fraud tools, verification vendors, e-sign, and the pricing engine all reach the file through connections that mostly work and occasionally fail silently. "Occasionally fail silently" is the phrase to remember. An order that did not transmit looks, on your screen, exactly like an order that transmitted and is pending.

WHAT ONE FIELD TOUCHES — a change to "loan amount"        [constructed teaching example]

   LOAN AMOUNT  $365,750
        │
        ├──→ P&I calculation ──→ housing ratio ──→ DTI ──→ AUS re-run needed?
        ├──→ LTV ──→ program eligibility ──→ MI factor ──→ MI premium
        ├──→ discount point cost (0.500 pt = $1,828.75) ──→ Loan Estimate
        ├──→ pricing engine re-price ──→ is the lock still valid?
        ├──→ per-diem interest ($66.3861/day) ──→ prepaid interest at closing
        ├──→ cash to close ──→ reserves after closing
        └──→ closing package, note, security instrument, delivery file

   ONE FIELD. Nine downstream consequences, four of them disclosed to the
   borrower and two of them re-underwritten. This is why "just change it and
   we'll fix the rest later" is not a thing that exists.

That diagram is the honest answer to the question new loan officers ask most often about the LOS: why is it so rigid? Because the loan is a system of simultaneous equations with a legal disclosure attached to half the variables, and the rigidity is the only thing preventing a change in one place from silently contradicting a document the borrower already received.

📄 Read the File

```text FIGURE 36.1 — "The pipeline screen on day 37" [the Linden Street file] THE DOCUMENT Pipeline view, loan origination system, Friday afternoon of day 37. One row per active file; thirty rows. This is loan L-2214. THE CONTEXT Conditional approval issued day 28 with eleven conditions. Nine of them — every prior-to-doc item — cleared between day 29 and day 33. Two prior-to-funding conditions remain open by design. The contract named a day-45 closing. The rate lock expires day 42. WHAT IT SHOWS

PIPELINE — 30 active files              user: LOAN OFFICER      day 37 (Fri)
──────────────────────────────────────────────────────────────────────────────
LOAN     PROPERTY           MILESTONE        STATUS   LOCK EXP    NEXT DUE
──────────────────────────────────────────────────────────────────────────────
L-2214   4412 LINDEN ST     Cond. Approval   ● GREEN  day 42      — none —
         $365,750 / 95% LTV / conv 30yr fixed / est. close day 45
         Conditions: 11 total | 9 cleared | 2 open (both PTF, no due date)
         Last document received: day 33   Last note: day 33
──────────────────────────────────────────────────────────────────────────────

               Every fact on that row is correct. Nothing is overdue. Nothing is
               suspended, expired, or exception-flagged. The status indicator is
               green because green means "no rule is being violated."

WHAT IT DOESN'T It does not show that nothing has happened in four days. It does not compute the interval between the lock expiration (day 42) and the estimated closing (day 45) and observe that the first is before the second. It does not know that the two open conditions require someone to start them — a verbal verification of employment and a credit refresh do not arrive on their own. And it does not show a due date, because prior-to-funding conditions are typically written without one: they are due before funding, and funding has no date yet. THE DECISION On day 37 the correct action was to order the verbal VOE and schedule the credit refresh, notify the closer to build the package, and — most urgently — compare day 42 to day 45 and call the lock desk. None of that was prompted. All of it was available. THE LESSON A milestone system records state changes. It cannot record the absence of a state change, because absence is not an event. Green does not mean "on track." It means "no alarm is currently sounding." ```

Constructed. Screen layouts vary by system; the file's facts and dates are this book's frozen figures.

Where the LOS actually hurts you

Four failure modes, in descending order of how often I have seen them cost money.

The stale duplicate. A loan officer duplicates a file to run a scenario — a second property, a different program — and the duplicate carries forward the original's data. Now two records exist and one of them is wrong. Some of the ugliest disclosure errors I have seen came from a figure that was true on a file that no longer existed.

The two-system condition. A borrower uploads a document to the portal. The portal marks the borrower's task complete. Nobody moves the corresponding condition in the LOS from "open" to "received." Ten days later the file is still waiting on a document that arrived on day one, and the borrower — who watched the green checkmark appear — is furious about being asked twice.

The notes field. Anything typed into an LOS is a business record. It is retained, it is discoverable in litigation, and it is readable by an examiner. This is worth stating plainly: never write anything in a loan file that you would not want read aloud in a deposition or a fair lending exam. A note speculating about a borrower's plans to have children, their national origin, their religion, or their age is not a note. It is an exhibit. Chapter 25 explains why in detail. Write facts, dates, and what you did.

The integration that didn't. The appraisal order that never transmitted. The verification request that returned an error nobody read. The lock confirmation that did not post back. The discipline is old-fashioned and it works: when you order something, confirm it was received by the party who has to do it — a confirmation number, a portal status, or a human. On the Linden Street file the appraisal, title, and verifications were all ordered on day 7 and all returned. Nobody should have known that from the fact that the buttons were clicked.

⚠️ Where Deals Die

Two systems, two truths, and the condition that was cleared in only one of them.

The mechanism, in the order it happens: the borrower uploads a paystub to the point-of-sale portal at 9:40 p.m. The portal shows a green check and a completion bar at 100%. The document syncs into the LOS document folder. But the condition — a separate object in a separate module — is still open, because clearing a condition is a review action taken by a person, not a file-arrival event.

The processor's needs list, which is generated from open conditions, still shows the item. The borrower gets an automated reminder for a document they already sent. They reply, understandably, "I sent that." Nobody investigates, because from the borrower's side it looks like a system glitch and from the lender's side it looks like a borrower who is confused.

The file sits. Then somebody notices on day 30 that the item is still open, opens the document folder, and finds it — sitting there since day 20.

The discipline: reconcile the condition list against the document folder yourself, at least twice a week, on every file in your pipeline. It takes four minutes per file. And when a borrower says "I already sent that," treat it as a fact to be verified in ninety seconds, not as a complaint to be managed. They are right more often than you will expect.

36.3 Point-of-sale and the borrower experience

The point-of-sale system is the borrower-facing front end: the online application, the document upload, the status view, the secure message thread, the e-signature launch point, and increasingly the consent screens for digital verification. Confusingly, "point of sale" is retail terminology borrowed into mortgage; it has nothing to do with a cash register, and everything to do with the moment a borrower decides whether this is going to be pleasant.

What it genuinely does better

It is open at eleven o'clock at night. A registered nurse working three twelve-hour shifts and an outside sales representative who drives a territory do not have a shared free hour during business hours. The Linden Street borrowers cleared four conditions on day 29 — a signed application package, thirty days of paystubs for both borrowers, a signed IRS Form 4506-C, and a gift letter with evidence of transfer — largely because the work could be done at night from a phone.

It produces structured data instead of prose. When a borrower types income into a labeled field, it arrives as a number in a field. When a borrower emails "I make about ninety-eight thousand," it arrives as a sentence somebody has to interpret and re-key.

It replaces email attachments, which is a security win. Chapter 36 §36.10 is about borrower data and criminals; the single most useful thing a portal does is give the borrower somewhere to put a bank statement that is not their email outbox.

It reduces the "any news?" call by showing status — though only if the status shown is honest. A portal that says "In Underwriting" for eleven days while nothing happens has not reduced anxiety. It has automated the concealment of a stall.

What it structurally cannot do

A form cannot ask a follow-up question. That is not a criticism of any product; it is what a form is.

The Linden Street file is the cleanest illustration in this book. The application asks whether the borrower has assets and how much. It does not ask "is any part of your down payment coming from someone else?" — and if it did ask exactly that, in those words, a borrower whose parents have promised \$10,000 verbally might still answer no, because the money is not there yet and the question felt like it was about today.

That \$10,000 gift needed a signed letter from the donors, a statement of no expectation of repayment, and documented evidence of the transfer. It became a condition on day 28 and cleared on day 29 only because it was known from day 1 — because in the twenty-minute discovery call somebody asked a human question and listened to a human answer. Chapter 8 owns that call. What §36.3 owns is the warning: a completed portal application is a starting point for the conversation, not a substitute for it.

Two more structural limits worth naming.

The completion illusion. Progress bars are designed to produce a feeling of doneness, because that is how you get people to finish forms. In mortgage, doneness is a claim about documentation that only an underwriter can make. A borrower at 100% has finished the form. They have not finished the file, and the gap between those two facts generates more borrower frustration than any other single thing in the digital mortgage.

The channel is not universal. Some borrowers do not have reliable broadband. Some have limited English proficiency and the portal is available in one language. Some use assistive technology that the portal handles badly. Some are elderly, or wary, or simply prefer paper — and are entitled to be. Chapter 25 owns the fair lending doctrine; the operational rule here is simple and non-negotiable: a borrower who will not or cannot use the portal must still be able to apply, and must not receive a worse outcome, a slower file, or a discouraging response for it. If your process only works for borrowers who use the app, your process has a fair lending problem and a business problem, and they are the same problem.

📞 On the Phone

Borrower: "The website says one hundred percent complete. So why are you asking me for three more things?"

The answer that makes it worse: "That's just the application. Underwriting always asks for more." True, and it tells the borrower that the number they were shown was meaningless, which is both demoralizing and, from their side, a fair inference.

What actually works: "That bar is measuring the application — every question answered, nothing blank. You did finish it, and it's a good one. What underwriting is doing now is a different job: they're proving each answer with a document. You told us about the \$10,000 from your parents on day one, and I believed you. The underwriter has never met you and can't. So they need the letter and the transfer. Three items, all of them things you already have, and I'll tell you exactly what each one looks like."

Notice the structure, because it is the same structure as every good version of this call: name what the second system is actually measuring, agree that the borrower did what they were asked, and convert the remainder into a finite list. Never let a borrower conclude that a screen lied to them. Explain that it was answering a narrower question than they thought.

36.4 CRM and the database that outlives your employer

Here is a fact about this career that nobody says on your first day: you will probably change employers, and almost nothing will come with you.

Not your pipeline — those files belong to the lender and mostly stay. Not your LOS access, which is revoked the morning you resign. Not your loan numbers, your funded volume records, your closed-file documents, or your rate sheets. You will walk out with a license, a reputation, and whatever you knew well enough to carry in your head.

And, if you built one, a customer relationship management database: the system of record for people rather than loans. Past clients. Real estate partners. Builders. Financial planners and CPAs who refer. Borrowers who called in March and cannot buy until they finish nine months of credit work. The Cypress Court buyers who lost that transaction to a short appraisal and will buy something else eventually.

Chapter 38 owns business development — how you actually earn referrals and what to say. This section owns the tooling and the argument for maintaining it.

The business argument

A borrower closes a mortgage roughly every seven years and talks about the experience for thirty. An active buyer's agent does something on the order of a dozen transactions a year and remembers, for a long time, which lender made the hard one work. Neither of those facts converts into income by itself. They convert when somebody is still reachable at the moment the need arises — which is, by definition, at a time you did not choose.

That is what a CRM is for. It is not a marketing gadget. It is the answer to the question how do I stay reachable to four hundred people for a decade without a database?, and the answer is that you do not.

What a maintained CRM actually holds:

The last row is not a courtesy. It is a compliance control, and the next callout explains why.

The portability question, answered carefully

This is where loan officers get bad advice, usually from other loan officers, and occasionally get sued.

The honest framing has three layers, and you need all three.

Layer one: your employment agreement. Non-solicitation clauses, confidentiality clauses, and trade-secret provisions are ordinary in mortgage employment agreements, and they are enforceable to varying degrees depending on your state and their drafting. Some prohibit soliciting former customers for a period. Some define the employer's customer list as confidential information regardless of who typed it in. Read the agreement when you sign it, not when you leave. If you cannot tell what it permits, that is a question for an employment lawyer in your state, and it is cheap compared to the alternative.

Layer two: privacy law. The Gramm-Leach-Bliley Act governs nonpublic personal information — the financial information a consumer gives you in connection with a financial product. Its privacy rule constrains how that information may be shared and reused, and its safeguards requirements constrain how it must be protected. Critically: information does not stop being protected because you were the one who collected it. A borrower's income, assets, account numbers, and Social Security number are not yours to export. And information derived from a consumer report is separately restricted under the Fair Credit Reporting Act, which limits use to the permissible purpose for which it was obtained.

Layer three: what is actually portable. In practice, and subject to the first two layers, the defensible position is names and contact information for relationships you sourced and maintain — the agent you met at an open house, the past client who is now a friend, the CPA who sends you self-employed borrowers. The indefensible position is an export of the lender's customer database on your last Friday. That distinction is the one courts and regulators care about, and it is also just obviously the right line.

The operational conclusion: keep your relationship data in a system you control, entered by you, containing contact information and relationship history rather than borrower financial data. Do not store income, account numbers, Social Security numbers, credit data, or document images in a personal CRM. That habit protects the borrower, protects you, and — as a side effect — makes the portability question mostly moot before it arises.

⚖️ Compliance Check

A CRM is a marketing system, a privacy system, and a records system at the same time. All three sets of rules apply simultaneously.

• GLBA. Nonpublic personal information collected in connection with a mortgage application is protected. Privacy notices, permitted disclosures, and the safeguards obligations in §36.10 all attach. This does not turn off because the loan closed or because you changed employers.
• FCRA. Consumer report information may be used only for the permissible purpose for which it was obtained. Credit data does not belong in a marketing database. Prescreened offers using consumer report data carry their own separate requirements.
• Advertising rules. Anything you send from a CRM is an advertisement if it promotes credit terms. Regulation Z's advertising rules and the Mortgage Acts and Practices rule (Regulation N) both apply, and both are enforced. Triggering terms pull in required disclosures. Rate quotes in a mass email are quotes.
• Contact rules. Telephone and text campaigns implicate the Telephone Consumer Protection Act and the National Do Not Call Registry; email campaigns implicate CAN-SPAM's identification, opt-out, and honoring requirements. Consent standards under the TCPA have been revised more than once and are actively litigated.
• Your employer's rules. Nearly every lender requires marketing materials to be pre-approved by compliance. This is not bureaucratic caution; an unapproved rate flyer is the lender's violation.

Requirements change and state law varies. Some states have their own privacy statutes, their own do-not-call lists, and their own advertising rules for licensed originators. Verify current requirements with your compliance department, your state regulator, and counsel before you send anything to a list.

36.5 The pricing engine

Chapter 29 explains how a rate is actually built — base price, adjustments, margin, and what the secondary desk is doing. Chapter 30 explains the lock. This section is about the product and pricing engine as software: what it is, what it needs to be correct, and how it fails.

What the engine is

A pricing engine is a rules-and-data system that takes a description of a loan and returns the set of products that loan is eligible for, each with a grid of rates and prices. It needs four categories of input and it is only as good as the worst of them.

WHAT THE ENGINE NEEDS, AND WHO MAINTAINS IT       [constructed teaching example]

  INPUT                          SOURCE                    REFRESH RATE
  ────────────────────────────────────────────────────────────────────────
  1. Base pricing (rate sheets)  secondary desk / investors intraday, and
                                                            on reprices
  2. Adjustment tables           agency + investor grids     when published
     (score, LTV, occupancy,
      property type, purpose,
      loan amount, lock term)
  3. Eligibility rules           agency guides + the         when guidelines
     (what this loan may be)     lender's own overlays       change
  4. Margin / concession rules   the lender's management     rarely, quietly
  ────────────────────────────────────────────────────────────────────────
  THE FILE'S FOUR FACTS          representative score, LTV, occupancy and
  (from the LOS)                 property type, lock period
  ────────────────────────────────────────────────────────────────────────
                          ↓
       ELIGIBLE PRODUCTS × a rate/price grid for each
                          ↓
       lock request → lock desk → lock confirmation → back into the LOS

Two observations about that diagram that loan officers routinely miss.

Row 3 is the row that breaks. Base pricing refreshes constantly and everyone watches it. Eligibility rules change when an agency updates a guide or when your employer adds or removes an overlay, and nobody watches that at all — until the engine returns "no eligible products" for a file that is obviously fine, or worse, returns an eligible product for a loan the investor will not buy. When an engine's answer surprises you, the two questions are: is this rule current, and is this rule ours or the agency's? Chapter 14 taught the guideline-versus-overlay distinction and it is never more useful than here.

The engine is not the lock. The engine shows a live price. The lock is a commitment recorded by the lock desk with a term and an expiration, and it lives in a lock record, not on the pricing screen. This distinction is the source of an enormous number of arguments, and it is why every lock must produce a written confirmation that posts back into the LOS. If you cannot show a confirmation, you are not locked, no matter what you saw on a screen.

🧮 Run the Numbers

What the engine returned on day 12, and what the software actually decided.

On day 12 the file was described to the pricing engine as: conventional 30-year fixed, \$365,750, primary residence, single-family detached, purchase, representative score 706, LTV 95.00%, 30-day lock. It returned this grid.

```text ELIGIBLE: CONV 30-YEAR FIXED 706 / 95.00% LTV / OO SFR / 30-DAY LOCK [constructed teaching grid — verify current pricing at the source]

RATE POINTS COST / (CREDIT) P&I ON $365,750 ───────────────────────────────────────────────────────────── 7.000% -0.750 ($2,743.12) $2,433.34 6.875% -0.375 ($1,371.56) $2,402.72 6.750% par $0.00 $2,372.25 6.625% +0.500 $1,828.75 $2,341.94 ← LOCKED 6.500% +1.000 $3,657.50 $2,311.79 6.375% +1.625 $5,943.44 $2,281.80 ```

Every point cost is the stated percentage of the loan amount: 0.500% of \$365,750 is **\$1,828.75; 1.625% is \$5,943.44**. The borrowers bought the half point. What it purchased:

\$2,372.25 (par) − \$2,341.94 (locked) = \$30.31 per month

\$1,828.75 ÷ \$30.31 = 60.3 months, or 5.0 years, to break even.

Now the part that is about software rather than pricing. The engine's grid is a photograph of one instant. It was generated on day 12 for a 30-day lock expiring day 42. The contract named a day-45 closing. The engine was never asked to compare those two dates, because comparing them is not its job — it prices the term it is handed.

The lock was three days short the moment it was taken. On day 42 it expired and required a 15-day extension at 0.250 point:

\$365,750 × 0.00250 = **\$914.38**

which is exactly half what the borrowers paid to buy the rate down. It was paid by the lender here, so it never touched cash to close — but it was paid. Chapter 30 makes the critique of that lock properly. The software point is narrower and it is this: the engine answered the question it was asked, correctly, and the question was wrong.

The audit trail nobody thinks about until they need it

Pricing engines record what was quoted, to whom, and when. That record does three jobs.

It settles disputes with borrowers about what was quoted on a Tuesday. It supports the lender's fair lending monitoring, because pricing exceptions and concessions are exactly the kind of discretionary act that produces disparate outcomes if it is distributed unevenly — Chapter 25 explains why that matters and Chapter 26 covers what loan originator compensation rules permit. And it supports the lender's own defense in an examination, because "we priced consistently" is a claim about data.

Which produces a practical rule: price in the engine, not in your head. A quote you constructed mentally and delivered on a phone call exists nowhere and protects nobody, least of all you.

36.6 Digital verification of income, assets, and employment

Verification used to be mail. A written verification of employment went out on paper and came back, eventually, signed by someone in a human resources department who had no obligation to hurry. Asset verification meant the borrower assembling statements, and every statement they assembled arrived as a photograph of a moment that was already three weeks old.

Digital verification replaced much of that with direct, borrower-permissioned data: the borrower authorizes a connection to a financial institution or a payroll data source, and a report is generated from the institution's own records. The Linden Street file's asset picture was in hand on day 7 because of it.

The three flavors and what each actually proves

The agencies build programs on top of this. Fannie Mae's Day 1 Certainty and Freddie Mac's automated income and asset assessment tools allow components validated by the automated underwriting system — using reports from authorized report suppliers — to carry representation and warranty relief on the validated component. Chapter 15 owns automated underwriting and the findings; what belongs here is the plumbing: report supplier → automated underwriting system → validated component → relief stated on the findings. The relief is only as broad as the findings say it is, the data has to be current, and not every component is eligible. Verify current requirements in the agency guides, which are updated continuously.

The verbal VOE that nothing has replaced

Note what remained on the Linden Street condition list as an open prior-to-funding item all the way to the end: a verbal verification of employment for both borrowers, within the required window before the note date. Not because anyone doubted the employment, and not because the payroll data was inadequate. Because the question being asked at that point is not "were they employed?" It is "are they employed right now, hours before we wire \$365,750." Data has a timestamp. That question is about the present tense, and the present tense has to be asked out loud.

📄 Read the File

```text FIGURE 36.2 — "The deposit the report cannot explain" [the Linden Street file] THE DOCUMENT Borrower-permissioned asset verification report, generated day 7 from a direct connection to the borrowers' depository institution. 90-day transaction lookback. Two accounts. THE CONTEXT A $385,000 purchase, 5% down, conventional, 95% LTV. Cash to close will be $25,376.34. The report replaces three months of paper statements and arrives four days after the application. WHAT IT SHOWS

ACCOUNT SUMMARY                                    as of day 7
────────────────────────────────────────────────────────────────────────
Savings ****4417   joint                            $21,340.16
Savings ****9052   Borrower 2                        $6,659.84
────────────────────────────────────────────────────────────────────────
TOTAL VERIFIED                                      $28,000.00

FLAGGED ACTIVITY — 90-day window
────────────────────────────────────────────────────────────────────────
● credit  $4,900.00   posted the day before day 0 — LARGE DEPOSIT
          (exceeds the threshold relative to typical account activity)
● recurring payroll credits, Borrower 1, consistent size and timing
● recurring payroll credits, Borrower 2, base only
────────────────────────────────────────────────────────────────────────

WHAT IT DOESN'T It does not show the $10,000 gift, which had not been transferred when the report was generated. It does not show the $5,000 earnest money, which was paid at contract on day 4 from funds outside this $28,000. And it cannot tell you what the $4,900 IS. The report can say a credit of $4,900.00 posted. It cannot say that it is the net of a $6,900 gross quarterly commission after $2,000 of withholding — that Borrower 2's commission is paid QUARTERLY and is lumpy, which is the entire reason a single deposit that size is normal rather than alarming.

               There is a second blindness here and it is subtler. The lookback window
               is 90 days. A quarterly event appears in a 90-day window exactly ONCE.
               The machine flagged it as an outlier because, within the data it was
               given, it was one. A longer window would have shown four of them and no
               threshold would have fired.

THE DECISION The condition written on day 28 asked for a letter of explanation and source documentation. It cleared on day 33 with the commission statement and the deposit record. Note the interval: the data was in the file on DAY 7 and the question it raised was not resolved until DAY 33. THE LESSON Digital verification moved the evidence upstream by weeks and moved the interpretation not at all. A machine can see a deposit. Only a person can explain it, and the explanation is what the underwriter is buying. ```

Constructed. Account numbers are fictional; balances and the deposit are this book's frozen figures.

Three limits to state plainly

Not every borrower is in the database. A borrower whose employer does not contribute payroll records, whose bank is not supported by the connection, or who is self-employed will fall back to documents. Chapter 32 works self-employed income; a business owner's income cannot be verified by connecting to a payroll system that has no record of them, and the Fulton Avenue file is a twenty-page tax analysis for exactly that reason.

Consent is required and may be withheld. A borrower may decline to connect an account. That is their right, they may have good reasons, and the fallback is paper. A borrower who declines may not be treated worse for it. Separately, delivering disclosures electronically requires the borrower's affirmative consent under the federal E-SIGN Act, in a form that reasonably demonstrates they can access the electronic records — §36.7 covers this.

The report does not change what income is countable. This is the point loan officers most often get wrong when a system produces a clean number. Borrower 2's commission history is \$19,800 and \$23,400 over two years. A payroll report will produce both figures accurately. The guideline decides which one qualifies: the 24-month average, \$43,200 ÷ 24 = **\$1,800.00/month, rather than the most recent year's \$23,400 ÷ 12 = **\$1,950.00/month. The conservative rule costs this borrower \$150.00 a month of qualifying income, on income that is rising — up 18.18% year over year. No amount of data quality changes that, because it is not a data problem. It is a rule about continuity, and Chapter 11 owns it.

36.7 E-signature, eNotes, eClosing, and RON

There is a real legal distinction hiding inside the phrase "digital mortgage," and it separates two things that feel identical to a borrower and are not remotely the same.

Signing a Loan Estimate electronically is easy law. Signing the note electronically is hard law, and it took a specific legal invention to make it work.

The easy part: e-signature

The Electronic Signatures in Global and National Commerce Act (E-SIGN, 2000) and the Uniform Electronic Transactions Act (UETA, 1999, adopted in some form by nearly every state, with a few states enacting their own analogous statutes instead) establish the foundational rule: a signature, contract, or record may not be denied legal effect solely because it is electronic. An electronic signature is a sound, symbol, or process attached to or logically associated with a record and executed with intent to sign.

That covers the great majority of a loan file: the application, the initial disclosure package, the Loan Estimate, borrower authorizations, most condition documents, and the Closing Disclosure.

E-SIGN attaches one requirement that matters operationally and that loan officers should be able to explain. Where a law requires that information be provided to a consumer in writing, delivering it electronically instead requires the consumer's affirmative consent, given or confirmed in a way that reasonably demonstrates the consumer can access the information in the form it will be provided. That is why the first thing a borrower does in a portal is consent to electronic records — and it is why that consent is a real legal step and not a click-through to be rushed past. Verify your employer's specific consent procedure and current requirements with compliance.

The hard part: the note

A promissory note is a negotiable instrument. Its value depends on possession — the party entitled to enforce it is, in general, the party holding the original. That model does not survive contact with a computer file, because a file has no original. Every copy is identical to every other copy, and a debt that can be presented for payment by anyone holding a copy is not a debt anyone would buy.

The law solved this with the concept of a transferable record: an electronic record that would be a note if it were on paper, which the issuer has agreed is a transferable record, and for which a single authoritative copy exists — unique, identifiable, and unalterable except in ways that are themselves identifiable. The party who has control of the authoritative copy holds the position a paper holder would hold. Control, not possession, is the operative concept. E-SIGN and UETA both provide for this.

Operationally, that legal idea needed an industry system to make it work. An eNote is an electronic promissory note executed as a transferable record — in practice, in the standardized tamper-evident format maintained by MISMO, which binds the data, the human-readable view, and the signature together so that alteration is detectable. And the industry maintains a registry, the MERS eRegistry, which serves as the system of record identifying who controls the authoritative copy of a given eNote and where it is held. Fannie Mae and Freddie Mac require eNotes they purchase to be registered there. This is publicly documented; verify current requirements in the agency guides and the registry's published procedures.

WHY THE NOTE IS THE HARD ONE                         [constructed teaching example]

  A PAPER NOTE                          AN eNOTE
  ─────────────────────────────         ─────────────────────────────────────
  one physical original                 one AUTHORITATIVE COPY, identifiable
  held in a vault                       held in an eVault
  possession = rights                   CONTROL = rights
  transferred by delivery               transferred by registry update
    and endorsement                       (controller of record changes)
  copies are obviously copies           copies are bit-identical — which is
                                          the entire problem the law solved
  ─────────────────────────────         ─────────────────────────────────────
  A disclosure needs none of this. A NOTE needs all of it, because somebody
  is going to buy it and has to know they are the only one who can enforce it.

eClosing, and the four-way veto

eClosing is the closing conducted with electronic documents. Chapter 23 owns closing and funding mechanics; here is the spectrum, because "we do eClosings" means at least four different things.

Remote online notarization (RON) is notarization performed over a live audiovisual connection, with identity proofing — typically credential analysis of a government ID plus knowledge-based authentication — and an audiovisual recording of the session retained by the notary for a statutorily defined period. RON is governed by state law. States differ on whether it is authorized at all, whether the notary must be commissioned in the state where the notary sits or where the property is, what identity proofing is required, and how long the recording must be kept. Many states issued emergency authorizations during 2020, and permanent statutes followed in many of them. Federal legislation to establish a national minimum standard has been introduced in Congress repeatedly; verify its current status rather than assuming it passed.

And now the practical truth that matters more than any of the above. Even where RON is legal:

Four parties can independently veto it. The lender must permit it. The title underwriter must be willing to insure a RON closing on that transaction. The investor buying the loan must accept it. And the county recorder must accept an electronically recorded, remotely notarized instrument — and electronic recording is adopted county by county, not state by state.

That last one deserves a moment. You can run a fully digital origination with borrower-permissioned verification, an automated underwriting recommendation, an e-signed disclosure package, an eNote registered to a national registry, and a remote notarization conducted over video — and it can still stop at a county recorder's counter that takes paper. That is not a joke about government. It is a reminder that the mortgage is a lien on land, land records are local, and locality is the oldest fact in this business.

🎓 NMLS Exam Watch

E-SIGN turns up regularly, and the questions cluster in three places.

The general rule. A record or signature may not be denied legal effect solely because it is electronic. Candidates over-read this into "everything can be electronic," which is wrong — E-SIGN carves out certain notices, and other law can impose requirements.

Consumer consent. Where a law requires a writing, electronic delivery requires the consumer's affirmative consent, given or confirmed in a manner reasonably demonstrating they can access the record in the form it will be provided. The trap in the stem is a fact pattern where the consumer consented on paper to receive documents in a format they cannot actually open. The demonstration requirement is the point of the rule.

E-SIGN versus UETA. E-SIGN is federal. UETA is a uniform state act, adopted state by state. E-SIGN generally yields to a state that has adopted UETA in its official form. Know which is which.

A fourth, less common but distinctive: control, not possession, is what governs a transferable record. If a question asks how rights in an electronic note are transferred, the answer involves control of the authoritative copy, not delivery.

36.8 Artificial intelligence in origination and underwriting

This section is going to be less exciting than the phrase deserves, and that is deliberate. There is an enormous amount of marketing language in this part of the industry, and a loan officer who repeats marketing language to a borrower or a referral partner is making claims they cannot support. So: what is actually running, stated conservatively, and what is not.

First, a framing that clears up most of the confusion

Statistical models have been making mortgage decisions for decades. A credit score is a model. It takes attributes of a consumer's credit file, weights them, and produces a number that drives pricing and eligibility. An automated underwriting system evaluates a file against published guidelines and returns a recommendation. The Linden Street file went to automated underwriting on day 6 and came back Approve/Eligible — a machine output that shaped every subsequent decision on that file. Chapter 15 owns that.

So "artificial intelligence in underwriting" is not the arrival of machine judgment into a previously human process. It is a change in the kind of model: from small, documented, largely interpretable scorecards and rule sets to larger models trained on more data, whose internal logic is harder to state in a sentence. The new problem is not automation. It is opacity, and §36.9 is about what opacity costs you legally.

What is genuinely in production

These are real, deployed, and useful. I am describing categories of capability, not endorsing products.

Document recognition and classification. A borrower uploads forty images in no particular order. A model classifies them — paystub, W-2, bank statement page 3 of 8, identification, homeowners declaration page — and files them against the right condition. This works well and saves real time.

Data extraction. Reading the year-to-date gross off a paystub, the pay period dates, the employer name, the account and routing numbers on a statement, the totals on a W-2. Accuracy on clean documents is high. It is not perfect, it degrades on poor images and unusual formats, and every extracted figure is subject to human verification before it becomes a qualifying number. Treat extraction as a very fast typist, not as an underwriter.

Fraud and document-integrity detection. Comparing an image against known templates, checking whether the arithmetic on a document actually foots, detecting evidence of editing, flagging duplicated images across files, checking whether an employer exists. Chapter 27 owns mortgage fraud; what belongs here is that these tools produce flags for human review, not conclusions, and a flag is the beginning of an inquiry.

Workflow triage. Scoring files by likely complexity, predicting which conditions a file is likely to draw, routing work, and surfacing files that need attention. This is where I think the most underrated value sits, because it addresses the exact failure this chapter opened with.

Collateral analytics. Automated valuation models and collateral risk scoring have been part of this business for years. Chapter 18 owns appraisal and Chapter 15 owns the circumstances in which an automated underwriting system may offer relief from a full appraisal.

Language assistance. Summarizing a long document, drafting a first version of a condition explanation, taking notes. Useful, with two hard rules attached: anything that goes to a borrower is a communication subject to advertising, fair lending, and UDAAP standards and must be reviewed by a human before it is sent; and borrower data may only be entered into systems your employer has approved. Pasting a borrower's financial information into a general-purpose tool is a data incident, and §36.10 explains why that sentence is not an exaggeration.

What is constrained, and why

Fully automated credit decisions on residential mortgages are constrained — not primarily by technology, but by disclosure law. A denial is an adverse action, and the Equal Credit Opportunity Act requires the applicant be told the specific principal reasons for it. If the decision came from a model whose reasons cannot be stated, the notice cannot be written. §36.9 works this through properly, because it is the most important thing in this chapter.

There is a second constraint worth knowing: the ability-to-repay requirement obliges the creditor to make a reasonable, good-faith determination of the borrower's ability to repay based on verified information. A model output is not a substitute for verification, and the creditor — not the vendor, not the model — remains responsible for the determination. Chapter 14 covers ATR/QM.

What I am not going to claim

I am not going to tell you what percentage of lenders use any of this, how much time it saves on average, or what the industry will look like in five years. Those numbers exist in vendor marketing and I cannot verify them, and a book that prints an unverifiable adoption statistic has taught you a habit that will eventually embarrass you in front of a referral partner who knows better.

What I will say is the thing that has been true through three technology cycles in my career: every one of these tools compresses the part of the job that was already fast, and none of them has touched the part that was slow. The Linden Street file took 51 days. Look at where the days went: five days waiting to lock, four days for an appraisal, four days from title order to commitment, five days in underwriting, and eleven days of nothing at all. Faster document classification would have saved approximately zero of them.

36.9 Model risk, fair lending, and the explainability problem

This is the most important section in the chapter, and to understand why, we have to go back to Chapter 2.

The residential security maps were a risk model

In §2.3, this book described the residential security maps produced by the Home Owners' Loan Corporation in the 1930s — the maps that graded neighborhoods and colored the lowest grade red. It is worth restating what those maps were, structurally, because the usual framing obscures the lesson.

They were a model. They took inputs about a neighborhood — the age and condition of the housing stock, income levels, and, explicitly, the racial and ethnic composition of the residents and the proximity of what the appraisal manuals of the era called "inharmonious" groups — and produced an output: a grade, from A to D, intended to represent lending risk.

The grade then determined where capital went. Areas graded D received less mortgage credit. Less mortgage credit meant fewer sales, less maintenance, declining values, and deteriorating housing stock. And a subsequent look at those neighborhoods showed exactly what the model had predicted: declining values and elevated risk.

The model appeared to be validated by outcomes it had itself produced.

That is the failure mode. Not simply that the model encoded a discriminatory policy — though it did, explicitly, in writing. The deeper problem is that it created a feedback loop in which the consequences of the policy became the evidence for the policy. Anyone auditing the model against outcomes in 1950 would have found it accurate. It was accurate. It was accurate because it had been used.

Why this is not merely a historical analogy

A modern model is trained on historical data. Historical lending data is the record of who was lent to, on what terms, and what happened. It is not a neutral record of creditworthiness. It is the record of a system that, for a substantial part of the period the data covers, allocated credit on grounds that are now unlawful — and whose effects on wealth, neighborhood composition, and property values persist because housing wealth is inherited and neighborhoods are durable.

A model trained on that record learns the consequences of past policy as if they were properties of borrowers. Concretely:

• If lending was historically withheld from certain neighborhoods, then loans in those neighborhoods are scarce, unusual, and thin in the data — and a model reads scarcity and unusualness as risk.
• If a category of borrower was historically served by more expensive products, their performance data reflects the expensive product, not their capacity.
• If a data source is itself the product of unequal systems — the distribution of employers, of school districts, of housing stock, of who has a long credit history and who is credit-invisible — then it carries that inequality forward as signal.

And a model does not need to see a prohibited basis to reproduce it. Proxies are enough. Geography is a proxy. Employer can be a proxy. So can the specific institution someone banks with, where they shop, what device they applied from, what schools appear in an application. A model that has never been shown a borrower's race can produce outcomes that track race closely, and the model will not mention this, because it does not know what race is. It only knows which columns predicted.

Chapter 25 owns the doctrine — disparate treatment, disparate impact, and what the law requires of lenders. What belongs here is the technical version of the same fact: a model's fairness cannot be established by removing prohibited-basis fields from the inputs. It must be tested on outcomes, and tested for whether a less discriminatory alternative achieves the lender's legitimate business need.

The explainability requirement is a legal requirement

Now the part that converts all of this from a philosophical concern into an operational rule, and it is short.

When a creditor takes adverse action, the Equal Credit Opportunity Act and Regulation B require the applicant to receive a statement of the specific principal reasons for the action — or notice of the right to obtain those reasons. Chapter 25 works the notice requirements. The relevant point here is what counts as a reason.

"The model declined the application" is not a reason. Neither is "your score from our proprietary system was too low," standing alone, nor "you did not meet our credit criteria." The requirement is specific and principal — the actual factors that drove this decision on this application.

So the chain runs like this:

THE CHAIN THAT CONSTRAINS AUTOMATED CREDIT DECISIONS

   a decision is made
        ↓
   if it is adverse, the applicant is entitled to the SPECIFIC PRINCIPAL REASONS
        ↓
   which means someone must be able to STATE, for this application, what drove it
        ↓
   which means the decision must be EXPLAINABLE
        ↓
   ───────────────────────────────────────────────────────────────────
   A DECISION THAT CANNOT BE EXPLAINED CANNOT BE DISCLOSED.
   A DECISION THAT CANNOT BE DISCLOSED CANNOT LAWFULLY BE MADE.
   ───────────────────────────────────────────────────────────────────

Explainability is therefore not a technical nicety, a research topic, or something to get to later. It is a precondition for using a model in a credit decision at all. The Consumer Financial Protection Bureau has said this directly in published circulars addressing adverse action notification where decisions are based on complex algorithms — the substance being that there is no exception for complexity, and that a creditor cannot rely on a checklist of sample reasons if the actual reason for the decision is not on the checklist. Read the circulars themselves; they are short, free, and unusually clear.

⚖️ Compliance Check

What a lender must be able to do before a model touches a credit decision.

• State the reasons. For any adverse action, produce the specific principal reasons for this applicant. ECOA and Regulation B. The Fair Credit Reporting Act imposes a separate obligation where a consumer report is used, and residential mortgage applicants have their own credit-score disclosure requirement. These are different notices with different triggers — do not merge them.
• Govern the model. The federal banking agencies' supervisory guidance on model risk management — issued by the Federal Reserve and the OCC in 2011 and referenced widely since — sets out the framework: sound development, implementation, and use; independent validation by people who did not build it; and governance, policies, and controls, including an inventory of models and documentation good enough that someone else could reconstruct the logic. The guidance is directed at banks; non-bank lenders are commonly examined against the same concepts.
• Test for disparate impact. Monitor outcomes by prohibited basis, and search for less discriminatory alternatives that meet the same business need. Chapter 25 owns the doctrine.
• Own the vendor's model. A model licensed from a third party is still the lender's decision. "The vendor won't tell us how it works" is not a defense; it is a reason not to use it. Vendor due diligence and the right to obtain the information you need to comply belong in the contract.
• Watch for drift. A model validated two years ago on a different rate environment and a different applicant mix is not validated today. Monitoring is ongoing, not a launch task.

In April 2023 four federal agencies — the CFPB, the Department of Justice's Civil Rights Division, the Equal Employment Opportunity Commission, and the Federal Trade Commission — issued a joint statement on enforcement against discrimination and bias in automated systems, making the point that existing law applies to automated decision-making without a technology exception.

Requirements change and state law varies — several states have their own rules on automated decision-making and data use. Verify current requirements with your compliance department, your regulator, and counsel.

What a loan officer actually does about this

You will not build a model, validate one, or sit on a model risk committee. You have five duties and they are all concrete.

One: never tell a borrower that "the system" declined them. It is inaccurate — a creditor declined them — and it converts a legally required explanation into a shrug. If you do not know the reasons, say you will find out and then find out.

Two: read the adverse action notice on your own declined files. Compare the reasons to the file you worked. If the notice says "insufficient income" on a file that died over collateral, something is misconfigured, and you may be the only person positioned to notice.

Three: escalate an output you cannot explain. If a system returns a result you cannot reconcile with the file — an eligibility denial that contradicts the guideline, a pricing adjustment that appears from nowhere, a valuation you cannot account for — write it up and send it to whoever owns that system. This is not being difficult. Every model risk framework in existence depends on somebody in the field reporting anomalies, and the person in the field is you.

Four: do not construct your own decision tools. A spreadsheet you built that tells you which leads to call back is a model, and if it happens to encode geography, it is a model with a fair lending problem. Use approved tools.

Five: keep prohibited-basis information out of the file entirely. Not in the notes, not in the messages, not in the "additional information" field. Chapter 25 explains the doctrine; §36.2 already told you that everything you type is discoverable. Both of those facts point the same direction.

36.10 Cybersecurity, wire fraud, and borrower data

A loan file contains, in one place: full legal names, Social Security numbers, dates of birth, current and prior addresses, employer names, income, account numbers, balances, a complete credit history, and a closing date on which a large sum of money will move to a known destination.

There is no more attractive target in consumer finance, and the industry's front door is a loan officer's email inbox.

The regulated part: borrower data

The Gramm-Leach-Bliley Act makes nonpublic personal information the lender's responsibility, in two halves. The privacy half governs what may be shared and requires notices. The safeguards half requires an information security program. For non-bank mortgage lenders and brokers, the Federal Trade Commission's Safeguards Rule sets the requirements; the rule was substantially amended and now specifies elements including a designated qualified individual responsible for the program, written risk assessments, access controls, encryption of customer information in transit and at rest, multi-factor authentication, secure disposal, vendor oversight, an incident response plan, and — under a further amendment — notification to the Commission of certain security events. Depository institutions are examined under their own regulators' equivalent standards. Verify the current requirements; this rule has been amended more than once.

State law adds layers. Every state has a data breach notification statute, with its own definitions and deadlines. Some states impose substantive security requirements on licensees, and at least one state financial regulator maintains a detailed cybersecurity regulation with annual certification requirements that reaches many mortgage companies. Your compliance department knows which apply to you.

What this means for a loan officer, translated into behavior:

That last "do not" in the tool row is worth repeating because it is new and people are careless with it: entering borrower information into a system your employer has not approved is a data incident, regardless of how useful the tool is or how private you believe it to be. Ask first.

The urgent part: wire fraud

Here is the scenario that will be attempted on one of your files, and it is the most likely way a borrower in this business loses their entire down payment.

Somewhere in the transaction — the buyer's email, the agent's, the title company's, the lender's — somebody's mailbox is compromised, or somebody's mail is being watched. The criminal reads the thread long enough to learn the parties, the closing date, the property, the tone of voice everyone uses, and the approximate amount. They wait.

Then, a few days before closing, the borrower receives an email that appears to come from the title company or the closing attorney. It has the right logo, the right file number, the right property address, the right closing date, and a plausible reason for the timing. It contains wire instructions. It is urgent.

The borrower wires \$25,376.34 — the exact cash to close on this file — to an account controlled by a criminal, who moves it within minutes, often through several accounts and frequently offshore.

By the time anyone notices, usually at the closing table, the money is gone. Frequently it is unrecoverable. Chapter 27 covers business email compromise as a fraud scheme in general; what you own is the prevention protocol and the first hour.

⚠️ Where Deals Die

Wire fraud is the deadliest technology risk in residential lending, and it kills the borrower rather than the file.

Understand the three variants, because they defeat different defenses:

1. Display-name spoofing. The email shows the title officer's name. The actual address is unrelated. Defeated by looking at the address — which nobody does on a phone, because phones show the display name.

2. Lookalike domain. The address is almost right. An "rn" where an "m" should be. An extra letter. A .co instead of a .com. A hyphen. Defeated by reading character by character, which nobody does either.

3. A genuinely compromised mailbox. The email really does come from the right address, because the criminal is inside that account — reading, and sometimes replying, and sometimes setting a rule so the real owner never sees the thread. This one defeats every visual check. It is the reason the rule below is absolute rather than a matter of judgment.

THE PROTOCOL. No exceptions, including for people you have worked with for years.

1. Never accept wire instructions by email. Not from the title company, not from the agent, not from your own closer. Email is not a channel for payment instructions. Ever.
2. Verify by voice, using a number you obtained independently — from the executed contract, the title company's published main line, or a number already verified in your records. Never the number in the email. A criminal who can write the email can write the signature block.
3. Treat any change as an attack until proven otherwise. Legitimate changes to wire instructions days before closing are rare. Fraudulent ones are common. The default assumption is fraud.
4. Warn the borrower at application and again before closing, in writing, in plain words, and at least once out loud. Two warnings separated by weeks is the pattern that works, because the first one is forgotten and the second one arrives when it is relevant.
5. Teach the borrower the three red flags: a change to instructions, urgency, and any discouragement from calling to verify.
6. Watch what you publish. Posting "another one under contract!" with a property photo tells a criminal there is a closing coming and roughly when. Reconnaissance is free.

THE FIRST HOUR, IF IT HAPPENS. Speed is the only thing that helps.

• Call the sending bank immediately, report fraud, and request a recall.
• Call the receiving bank and report the fraudulent account.
• File with the FBI's Internet Crime Complaint Center (IC3) immediately. The Bureau maintains a recovery function that can, in some circumstances, work with the receiving institution to freeze funds — and its effectiveness drops sharply with time. Report in hours, not days. Criteria and thresholds have changed over time; use the current guidance at the source.
• Contact the local FBI field office and file a police report.
• Notify the title company, the lender, and the agents — the compromised mailbox may not be the borrower's, and other transactions may be exposed.
• Preserve everything. Do not delete the emails. Keep full headers. Do not "clean up" the mailbox.

Federal financial-crime authorities and the FBI have published repeated advisories on email compromise schemes and real estate wire fraud specifically. Industry groups in title and settlement maintain their own response programs. Read the current versions rather than a summary in a book — the schemes evolve, and so does the guidance.

📞 On the Phone

At application, day 5 — thirty seconds, every file, no exceptions:

"Before we go further, one thing I tell every borrower, and it's the most important thing I'll say today. At some point near closing, someone is going to tell you where to send your money. There are criminals who watch real estate transactions and send fake wire instructions that look completely real — right logo, right file number, right closing date. If you follow them, the money is usually gone for good, and it would be your entire down payment.

So here is our rule, and it protects you from me too: we will never send you wire instructions by email, and you should never accept wire instructions by email from anyone — including from me. When it's time, you'll call the title company at the number on your contract and confirm every digit by voice. If you ever get an email about wiring money, don't reply to it. Call me. I would rather answer that call fifty times than have it go the other way once."

Before closing, day 48, when the Closing Disclosure goes out — same message, sharper:

"You're going to be wiring \$25,376.34 this week. Two rules. One: the instructions come from a phone call you place, to a number you looked up yourself, not from any email. Two: if anything changes — a new account, a new bank, anything at all — assume it's fraud and call me before you do anything. Real changes this late almost never happen. Fake ones happen constantly."

Say it both times. The first warning is education; the second is the one they act on.

36.11 What technology has not changed

Everything in this chapter is real. Turn times are shorter than they were. Paper is nearly gone. Verification moved upstream by weeks. A borrower signs at eleven at night from a phone and a document is classified before anyone looks at it.

And then the Linden Street file sat for eleven days.

Not because a system failed. Every system worked. It sat because between day 33 and day 44 there was no event to record, no rule being violated, no due date passing, and no alarm to sound — and because the one thing that did happen in that window, the lock expiring on day 42, happened in a different system with a different clock and no reason to speak to the first one.

Three things have not changed, and I do not expect them to.

Somebody has to tell a borrower an unwelcome truth on day one. That the 706 does not price like the advertised number. That the accountant's \$9,500 is the underwriter's \$8,916.67. That the appraisal came in \$35,000 under contract and the gap is \$28,000 in cash that did not exist yesterday. No system delivers that news, and delivering it late is how transactions die expensively. Chapter 8 is about saying it early.

Somebody has to decide which of thirty files gets the next hour. The pipeline screen in Figure 36.1 showed thirty rows, all of them green, one of them four days into a stall. Ranking is judgment: which file is quietly in trouble, which condition will take a week if it is not started today, which borrower is about to walk. A system can sort by date. It cannot sort by consequence.

Somebody has to know which condition can be escalated. Every condition list contains items that are genuinely immovable and items that will move if the right person is asked the right way — a document requirement satisfied by an alternative the guideline actually permits, an underwriter's question that dissolves when the file is explained, a third party who will expedite for someone they know. Chapter 19 is that skill. It is entirely relational and it is worth more per hour than any tool in this chapter.

To which the eleven dead days add a fourth, which is really a version of the second:

Somebody has to notice nothing is happening. Here is the thing to take from this chapter and build on Monday. Almost every LOS can produce a report of files sorted by days since last activity — last document received, last note written, last milestone change. Most ship with it turned off, because it is not a compliance report and nobody is required to run it.

Run it every Monday morning. Sort descending. Look at the top five. On the Linden Street file, that report on day 37 would have put L-2214 near the top of a thirty-file pipeline with four days of silence, and four days of silence on a file whose lock expires in five is the whole story.

That is the argument of this chapter compressed into one habit: the systems will always tell you what happened. You have to ask them what didn't.

🗂️ The Loan File

Chapter 36 contribution: map the 51 days across the systems, and find the dead window.

Below is the Linden Street file as its own software stack recorded it. The third column names which system holds the event — because the seams matter — and the fourth is the interval since the previous file event. That fourth column is not on any screen.

Where technology genuinely helped. A pre-approval on day 1 because credit returned in seconds. An automated underwriting recommendation on day 6. Appraisal, title, and verifications all ordered from one screen on day 7, with the asset picture in hand the same day. Four conditions cleared in a single day on day 29 because a borrower could photograph documents at night and a system could index them. Nine prior-to-doc conditions cleared in five calendar days — and only three business days, because days 31 and 32 were a weekend. A payoff made on a Sunday, day 46, because a furniture account can be paid online at any hour. A Closing Disclosure on day 48 with a documented electronic receipt, which is what made the three-business-day count clean and unarguable.

Where it did not help at all.

The eleven days. Day 33 to day 44. Eleven calendar days, eight business days — the file's next longest gap was five, so the dead window was more than twice the file's own worst case, and nothing flagged it. Because nothing was late. The two remaining conditions were prior-to-funding and had no due date; funding had no date. The status was green because green means "no rule is being violated."

The lock lived somewhere else. It expired on day 42, inside the dead window, in the pricing and lock system. The milestone screen never compared day 42 to the day-45 closing date, because the two facts were in two systems and neither one was asked.

The data was there on day 7 and the question waited until day 33. The \$4,900 deposit appeared in the asset report the week of application. The machine could see it and flag it. Only a human could say it was the net of a \$6,900 gross quarterly commission after \$2,000 of withholding, and that took until day 33.

And more monitoring would not have saved it. It is tempting to conclude that continuous undisclosed- debt monitoring — a real service that alerts a lender to new inquiries and new tradelines between application and closing — would have caught the day-41 furniture account before the lock expired. Maybe. But a bureau only learns about an account when the creditor reports it, and reporting lags the purchase by days or weeks. The alert might have come on day 43. It might have come after closing. The reliable controls on this file were not technological: a day-1 conversation telling the borrowers not to open new credit, and a prior-to-funding condition written on day 28 — sixteen days before the event it was written to detect.

What this settles: which system holds which fact, and why the seams between them are where the file was lost.

What it does not settle: anything about the eleven days. No tool would have prevented them. A Monday-morning report sorted by days since last activity would have shown them.

Your task. In Appendix C's workbook, redraw the table above with one change: add a column headed "who should have acted, and on what day." Fill it for days 34 through 43. Then write two sentences naming the report you would run every Monday for the rest of your career, and what you would do with the top five rows.

Conclusion

The stack has seven parts and the LOS is authoritative for the loan. Everything else either feeds it, answers one question for it, or shows the borrower a view of it. The failures that cost money live at the seams: two systems holding two versions of a fact, two clocks that never speak, a condition cleared in one place and open in another.

The tools are real and they work. Digital verification moved evidence upstream by weeks — and moved interpretation not at all, which is why a \$4,900 deposit visible on day 7 was still a condition on day 33. Electronic signature made most of a loan file frictionless, and the note required a genuine legal invention — the transferable record and the concept of control — before a promise on a screen could be bought and sold. E-closing can be fully digital right up until a county recorder's counter that takes paper.

Artificial intelligence in origination is real where it reads, classifies, extracts, flags, and triages, and it is constrained where it would decide, because a denial requires the specific principal reasons and a decision that cannot be explained cannot be disclosed. Chapter 2's maps are the reason that requirement exists in the form it does: a model that encoded a policy, produced the outcomes that appeared to validate it, and did enormous, durable harm — accurately.

Borrower data is regulated and valuable, and the single most likely way a family in this business loses everything they saved is a spoofed email with new wire instructions a few days before closing. Never accept wire instructions by email. Verify by voice on a number you obtained yourself. Warn the borrower twice.

And then there is what remained. Somebody still has to tell a borrower an unwelcome truth on day one, decide which of thirty files gets the next hour, know which condition can be escalated, and notice that nothing has happened in eleven days. Those four things are the job. They were the job before any of this software existed, and every tool in this chapter is best understood as an attempt to buy you more hours to do them.

Next: the market changes underneath you. A pipeline built entirely on purchase business behaves one way when rates fall and another when they rise, and a loan officer who only knows one of those markets is a loan officer with half a career. Chapter 37 works the purchase-versus-refinance pivot — what actually changes, what does not, and how to be ready before the market tells you it is time.

Key Terms

Loan origination system (LOS) — the lender's system of record for a mortgage loan: its structured data, its imaged documents, its milestones and conditions, its disclosures, and its audit trail. When any other system disagrees with the LOS, the LOS is what the underwriter, the closer, the investor, and the examiner read. (Ch.36)

Point-of-sale (POS) — the borrower-facing front end of the origination process: online application, document upload, status view, secure messaging, and e-signature launch. Collects what the borrower says; cannot ask a follow-up question. (Ch.36)

Customer relationship management (CRM) — the system of record for people rather than loans: past clients, referral partners, and not-yet borrowers, with contact history and follow-up scheduling. Chapter 7 introduces its lead-generation use; Chapter 38 owns what to do with it. (Ch.36)

Document management — the classification, indexing, versioning, retention, and access control of the imaged loan file. Retention periods are set by regulation and differ by rule. (Ch.36)

E-signature — a sound, symbol, or process attached to or logically associated with a record and executed with intent to sign. Given legal effect by the federal E-SIGN Act and by state adoptions of the Uniform Electronic Transactions Act. (Ch.36)

Transferable record — an electronic record that would be a promissory note if it were on paper, for which a single authoritative copy exists. Rights are held through control of that copy rather than physical possession. (Ch.36)

eNote — an electronic promissory note executed as a transferable record, in a standardized tamper-evident format, with the controller of the authoritative copy identified in an industry registry. (Ch.36)

eClosing — a closing conducted with electronic documents, ranging from hybrid (most documents e-signed, the note and security instrument wet-signed) to fully electronic. Chapter 23 owns the mechanics. (Ch.36)

Remote online notarization (RON) — notarization performed over a live audiovisual connection with identity proofing and a retained recording, governed by state law. Requires the lender, the title underwriter, the investor, and the county recorder each to permit it. (Ch.36)

Digital verification — borrower-permissioned electronic verification of assets, income, or employment drawn from an institution's or payroll source's own records, in place of borrower-supplied paper. (Ch.36)

Artificial intelligence in underwriting — the use of statistical and machine-learned models in credit evaluation. Not new in kind — credit scores and automated underwriting systems are models — but newly opaque, which is what creates the legal constraint. (Ch.36)

Model risk — the risk of adverse consequences from decisions based on incorrect or misused model output, including the risk that a model reproduces the effects of past discrimination learned from historical data. Managed through sound development, independent validation, and governance. (Ch.36)

Explainability — the ability to state, for a specific decision on a specific application, the factors that drove it. A precondition for a lawful adverse action notice, and therefore a precondition for using a model in a credit decision. (Ch.36)

Cybersecurity and borrower data — the protection of nonpublic personal information under the Gramm-Leach-Bliley Act, applicable safeguards rules, and state law; and the operational defenses against wire fraud, credential compromise, and unauthorized disclosure. (Ch.36)

Spaced Review

1. On day 6 the file returned Approve/Eligible from automated underwriting, and on day 47 the findings were re-run. Using Chapter 15, state what a recommendation is and is not — and then, using §36.9, explain why the same reasoning constrains a lender that wants to use a newer, more opaque model to make the decision itself.

2. Chapter 19 taught the difference between a prior-to-doc and a prior-to-funding condition. Figure 36.1 shows two open PTF conditions with no due date. Explain why they have no due date, why that is defensible, and what a loan officer must therefore do that no system will prompt.

3. The \$4,900 deposit was visible in an asset report generated on day 7 and its condition did not clear until day 33. Using Chapter 19's framework for clearing conditions and §36.6's account of what a verification report proves, say who could have shortened that interval and by roughly how much.

4. Chapter 15 covered the circumstances in which an automated underwriting system may offer relief from a full appraisal. Using §36.9, name two questions a lender should be able to answer about any model that decides which properties get that relief, and say which of those questions a loan officer is positioned to raise.

5. Your borrower forwards you an email from "the title company" with wire instructions, sent the afternoon of day 49. It has the correct file number, the correct property address, and the correct closing date. Write the three things you do next, in order, and state the one thing you must not do even though it is the fastest.