The Approval That Still Owes the Borrower a Notice: Risk-Based Pricing, the Credit-Score-Disclosure Exception, and What an AI Pricing Agent Has to Trigger

The Approval That Still Owes the Borrower a Notice

Most of the compliance attention on mortgage pricing goes to the denial, because the denial is the visible adverse event and the adverse-action notice is the obvious obligation. The approval at a higher rate gets less attention, and it carries its own notice duty that a lender can miss precisely because the outcome felt like a yes. A borrower approved at 7.25 percent when the lender's best-priced borrower gets 6.75 percent was priced up on the strength of a credit report, and the Fair Credit Reporting Act treats that as an event the borrower is owed a notice about.

We build the agent that quotes and locks rates on mortgage origination platforms, so the pricing decision runs through code we wrote before a human confirms it. The notice obligation attaches to that decision, which means it has to be designed into the pricing flow rather than added by a compliance team after the rate is set. What follows is where the obligation comes from, why the mortgage industry discharges it through an exception rather than the general rule, and the timing line the agent enforces so a locked rate never reaches consummation without the notice already delivered.

What FCRA §615(h) Requires, and Why the Determination Is Hard

The statutory source is FCRA §615(h), codified at 15 U.S.C. 1681m(h), and the operating rule is Regulation V, subpart H. 12 CFR 1022.72 says that a person who uses a consumer report in connection with an application for credit, and who, based in whole or in part on that report, grants credit on material terms that are materially less favorable than the most favorable terms available to a substantial proportion of consumers, has to give the consumer a risk-based pricing notice.

The hard part of that rule is the word "materially less favorable," because it requires the lender to know where the line sits between the borrowers who got the good terms and the borrowers who got priced up, and then to sort every approved applicant against that line. The rule gives two methods for finding the cutoff, a direct comparison of the consumer's terms against the terms actually offered to others, and a credit-score proxy method that sets a cutoff score, and both of them require the lender to maintain and defend a determination of who falls on the worse-terms side. For a mortgage lender pricing thousands of loans across investors, rate sheets, and loan-level price adjustments that move daily, that determination is a moving target and a standing source of error, because a cutoff that was right last quarter is wrong after the pricing grid changes.

Why Mortgage Uses the Exception, Not the General Notice

Regulation V anticipates that the who-crossed-the-line determination is expensive and error-prone, so 12 CFR 1022.74 provides exceptions that let a lender discharge the obligation without ever computing the cutoff. The one the mortgage industry uses is the credit-score-disclosure exception for loans secured by residential real property, at 1022.74(d). Under it, the lender gives a credit-score disclosure notice to every applicant for a loan secured by one to four units of residential real property, and having given that notice to everyone, the lender does not have to identify which applicants received materially less favorable terms and does not have to send the risk-based pricing notice at all.

The model notice for that exception is form H-3 in Appendix H to Part 1022, and it carries the applicant's credit score, the range of possible scores under the model used, the key factors that adversely affected the score, the date the score was created, and the name of the consumer reporting agency or other person that provided the score. The design choice the exception forces is worth stating plainly, because it drives how we build the agent: the cleaner control is to notify everyone rather than to notify the subset the rule technically targets. The subset approach means a live cutoff the pricing team has to keep accurate against a daily-moving grid, and every time that cutoff drifts the lender is either over-notifying, which is harmless, or under-notifying, which is a violation. Sending H-3 to every mortgage applicant removes the cutoff from the control surface entirely, so there is no line to keep accurate and no applicant who slips below a stale threshold without a notice.

So the agent does not try to be clever about which borrowers were priced up. It treats the credit-score disclosure as a universal output of the pricing event, generated for every applicant whose file the agent touched, because the exception makes universality the safe posture and the determination the risky one.

The §609(g) Notice the Mortgage Applicant Also Gets

The credit-score disclosure the borrower receives is doing two jobs at once, and the second one is easy to lose track of. Separate from the risk-based pricing regime, FCRA §609(g), at 15 U.S.C. 1681g(g), requires any person who makes or arranges loans secured by residential real property and who uses a credit score to provide the applicant a notice to the home loan applicant that discloses the score and related information. The H-3 form is written so that a single notice satisfies both the 1022.74(d) exception and the §609(g) mortgage-specific requirement, which is why the mortgage industry standardized on it.

The consequence for the agent is that the score disclosure is not optional even for the borrower who got the best rate. A wage earner with an 800 score buying a primary residence at the lender's sharpest price is still owed the §609(g) notice because the lender used a score to price the loan, and the same H-3 that discharges the risk-based pricing exception discharges that duty too. The agent generates the notice for the top-of-book borrower for the §609(g) reason and for the priced-up borrower for both reasons, and the content is the same, which is the point of the exception.

The Timing Line the Agent Cannot Let a Locked Rate Cross

The notice has a clock, and the clock is where an automated pricing flow gets into trouble, because the agent can lock a rate faster than a manual process ever delivered a disclosure. Under the timing rules for the exception at 1022.74(d) and the general timing at 1022.73(c), the credit-score disclosure has to reach the applicant as soon as reasonably practicable after the credit score is obtained, and in any event at or before consummation. Consummation of a mortgage is the closing, so the outer bound is the closing table, and the inner bound is the pull, which for us is usually the moment the agent orders the tri-merge and prices off it.

We wrote the pricing flow so that obtaining the score and queuing the H-3 are one transaction, not two steps a later handoff might drop. When the agent receives the credit score that feeds pricing, it records the score, the model, the range, the key factors, and the pull date into the loan's provenance record, and it emits the H-3 to the delivery channel in the same operation. The agent does not treat the lock as complete until the notice is in the delivery queue with a timestamp, because a locked rate that reached the borrower before the disclosure did is the exact sequence the rule is written to prevent, and it is the sequence an automated system produces by default if delivery is a downstream afterthought rather than part of the pricing transaction.

That design also fixes the multi-pull problem. A mortgage application often generates several score pulls across its life, an initial pull at application, a re-pull after a lock extension or a program change, sometimes a soft refresh late in the process. The §609(g) and exception obligations attach to the score the lender uses, so the agent's rule is to disclose the score the loan was priced on and to re-disclose when a subsequent pull becomes the score the loan is re-priced on, with each disclosure carrying its own pull date. An institution whose disclosure fires once at application and never again is an institution that, on a loan re-priced off a later pull, delivered a notice describing a score the final terms were not based on.

The Fields That Feed the Notice Have to Be the Pricing Fields

The integrity risk in H-3 is that the score, range, and key factors printed on the notice have to be the exact score, range, and key factors the pricing engine consumed, not a nearby copy pulled from a different call. The key-factor codes come from the credit-reporting agency alongside the score, and the range is specific to the scoring model the lender used. What the notice has to name is the consumer reporting agency or other person that provided the score, not the scoring model's name or version, so which model produced the score is something the agent tracks internally for pricing integrity rather than a field the notice discloses, and the disclosed score, range, and key factors still have to be the ones that model produced. If the agent prices off one model's score and the notice-generation step reads a different model's score from a separate field on the credit file, the borrower gets a disclosure that does not describe the number that set their rate.

So the agent sources the notice fields from the same score object that entered the pricing calculation, not from a re-read of the credit file. The score, the model identifier, the score range for that model, the reason codes, the CRA that furnished it, and the pull date travel together as one record from the pull into pricing and into the H-3, and the notice is rendered from that record. The reason codes matter here because the key-factor statements on H-3 are the plain-language versions of those codes, and a mismatch between the codes the score arrived with and the factors the notice prints is a data-integrity defect an examiner can find by comparing the notice against the credit file in the loan.

The Failure Mode We Engineered Against

The failure that shaped the current design showed up on an early deployment where the pricing agent and the disclosure step were separate services with a queue between them. On loans that locked late in the day near a rate-sheet change, a re-price would fire, the loan would close on the re-priced terms, and the H-3 in the file described the score from the original pull because the re-price had not re-triggered the disclosure. The terms were based on the later score; the notice described the earlier one. On an aggregate audit the disclosure-present rate looked complete, because every loan had an H-3, and the defect was that the H-3 on the re-priced loans described the wrong pull. An aggregate "notice delivered" metric hid it, the same way an aggregate accuracy number hides a cohort failure.

The decision we made from that is the one described above, that the disclosure is emitted as part of the pricing transaction rather than by a downstream service, and that a re-price is a pricing transaction, so it re-emits. We also changed the audit from "does every loan have an H-3" to "does the score on each loan's H-3 match the score the final terms were priced on," because the first question is the one an automated system passes while failing the second. That second check is the control that would have caught the defect in week one, and it now runs at loan level across the book rather than on a sample.

Why the Exception Is the Cleaner Control

The instinct on a rule like risk-based pricing is to build the precise thing the rule describes, a cutoff that separates the priced-up borrowers from the best-priced ones and a notice that goes to the first group. Regulation V offers a better path for mortgage, which is to notify everyone under the 1022.74(d) exception and delete the cutoff from the control surface, and the reason to take it is not laziness but reliability, because the cutoff is the part that drifts and the universal notice is the part that does not. The agent we run treats the credit-score disclosure as a mandatory output of every pricing event, sources its fields from the same score that set the rate, emits it inside the pricing transaction so a locked rate never outruns it, and re-emits on every re-price. That is the version of the control that stays correct while the rate sheet changes daily underneath it, and staying correct while the inputs move is the whole job. We build the pricing agent to make the disclosure a property of the price, so the two cannot come apart.