AI at the Mortgage Point of Sale: Intake That Starts the TRID Clock Without Starting a Violation

Where the Point of Sale Actually Breaks

The borrower-facing application is the most measured surface in mortgage and the least understood one. Lenders track application starts, drop-off, and pull-through, and they talk about the point of sale as a conversion problem. The compliance team looks at the same surface and sees a different thing: the moment an application becomes an application under the law, and a set of clocks that start running whether or not anyone on the origination floor noticed.

Most point-of-sale software treats "application" as a UI state: the borrower clicked submit. Regulation defines it differently, and the gap between those two definitions is where lenders get findings. An AI agent that sits in the intake flow has to know the legal definition cold, because the agent is now the thing collecting the six pieces of information that start the clock.

The Trigger Nobody Wants the Agent to Miss

Under Regulation Z, an application for a closed-end mortgage is complete for TRID purposes once the lender has six pieces of information: the borrower's name, income, Social Security number to pull credit, the property address, an estimate of property value, and the loan amount sought. 12 CFR 1026.2(a)(3) defines it, and Comment 2(a)(3)-1 lists the six. Once the lender has all six, the Loan Estimate deadline starts: no later than three business days after receipt, per 12 CFR 1026.19(e)(1)(iii).

That is the whole game at the point of sale. An AI intake agent collects those six data points in the course of a normal conversation. The moment the sixth one lands, the three-business-day Loan Estimate clock is running, and the lender cannot ask for anything else as a condition of providing the Loan Estimate, per 1026.19(e)(2)(iii). If the agent keeps asking the borrower for documents before the Loan Estimate goes out, that is a violation, and it is one an examiner can reconstruct from the timestamps.

So the first thing we build into a point-of-sale agent is a trigger detector that fires the instant the six-piece set is complete. It does two things at once. It timestamps the application-received event to an immutable log, and it hands the file to the disclosure workflow so the Loan Estimate deadline is a system fact, not a loan officer's memory. The agent does not decide whether to issue the Loan Estimate. It makes sure the clock that governs that decision cannot be started silently.

What the Agent Collects, and What It Refuses to Collect

There is a design choice at the point of sale that has compliance consequences. If the agent asks for more than the six pieces before the Loan Estimate, the lender risks turning a pre-application conversation into an application it then has to disclose on, and risks collecting information it now has to act on under Reg B. If the agent asks for too little, the file stalls and the borrower drops.

We draw the line the way the rule draws it. Before the six-piece trigger, the agent is having a conversation: product education, rough affordability, what documents will be needed later. It is explicit that it is not yet an application. After the trigger, the agent's job changes. It confirms the six pieces, timestamps the application, and moves the file into disclosure. It does not gate the Loan Estimate behind a single additional document, because the rule forbids that.

One thing the agent never does at the point of sale is collect information the lender is not allowed to use. Reg B permits collecting demographic information for a dwelling-secured application under the Home Mortgage Disclosure Act, and in fact requires the request, but the agent has to present it the way the URLA does: as a request the borrower may decline, with the government monitoring purpose stated. The agent reads the approved HMDA demographic language. It does not paraphrase it, and it does not infer race or ethnicity from anything the borrower said. We treat that text as a versioned, compliance-approved artifact, the same way we treat every disclosure the agent reads.

The Incomplete Application Problem

Most point-of-sale sessions do not finish. The borrower gets to income, gets interrupted, and leaves. In a pure conversion frame, that is a re-marketing opportunity. In a Reg B frame, it is a decision the lender may have to document.

One thing to get right here is that Reg B does not define an application the way TRID does. The six-piece set above is the Reg Z trigger for the Loan Estimate clock. Reg B, at 12 CFR 1002.2(f), defines an application as an oral or written request for credit made in accordance with the procedures the creditor uses for the type of credit requested. That trigger turns on the lender's own procedures, and it can attach before the six-piece TRID set is complete. A borrower who has requested credit under the lender's procedures and then stalls before providing, say, the property address may already be inside the Reg B timing and incompleteness obligations even though the TRID clock has not started. So the agent tracks two application states, not one, and does not assume the Reg B clock waits for the six-piece trigger.

Regulation B, at 12 CFR 1002.9(c), gives the lender a choice on incomplete applications: send a notice of incompleteness that tells the applicant what is missing and gives a reasonable deadline, or treat the file under the standard adverse action rules. The agent has to know which path the lender has chosen and drive the file down that path on a timer, because "the borrower abandoned it" is not a category the regulation recognizes once a request has come in under the lender's procedures.

The control we build: every intake session that crosses the Reg B application threshold and then stalls is put on the Reg B incompleteness clock. The agent sends the notice of incompleteness with the specific missing items, on the lender's approved template, and it tracks the reasonable-time deadline the lender has set. If the borrower does not respond, the file routes to the human who owns the adverse action decision. The agent does not deny anyone. It makes sure an abandoned application does not quietly become an undocumented denial.

Where the AI Helps and Where the Human Still Signs

The decision rights at the point of sale are the same ones we draw everywhere. The agent does the high-volume intake work that does not require judgment. It qualifies interest, collects the application data, verifies identity to the lender's standard, requests the initial document set after disclosure, and keeps the borrower moving. It does not approve, deny, price outside a published rate sheet, or make a Reg B determination.

The value is real because the point of sale is where loan officer time is worst spent. A loan officer walking a borrower through a 1003 by phone is doing data entry a borrower could do with a good agent guiding them. The loan officer's real skill is reading a borrower's situation, structuring the loan, and handling the objection, and that skill is wasted on form-filling. In the intake deployments we have run, the agent handles the full application conversation and the loan officer enters the file already populated, already disclosed, and already identity-verified. The loan officer spends their time on the loans that need a person.

The Data-Handling Line

The point of sale is where the most sensitive data enters the system: Social Security numbers, income, the credit pull authorization. That puts the intake agent squarely inside the GLBA Safeguards Rule, 16 CFR 314, and the interagency guidelines for banks. The agent's access to that data is scoped, logged, and encrypted, and the vendor relationship is inside the lender's third-party risk program, not beside it.

We call this out at the point of sale specifically because it is the surface teams forget. Everyone thinks about servicing data and back-office data. The intake agent is collecting the SSN and the credit authorization in the first ninety seconds of the relationship, and that data flow has to be inside the same safeguards program as everything else, with the same access controls and the same breach-notification obligations.

An Audit File That Explains Itself

The file we hand an examiner for the point of sale is built as the conversation happens, not reconstructed later:

• The full intake transcript or recording with timestamps
• The application-received event, with the exact moment the six-piece trigger fired and the Loan Estimate clock started
• The disclosure delivery record, tied to that timestamp, showing the three-business-day deadline was met
• The HMDA demographic request and the borrower's response or decline, in the approved language
• For stalled files, the Reg B incompleteness notice, its timestamp, and the deadline
• The identity verification record and the data-access log for the sensitive fields

An examiner reviewing point-of-sale compliance is asking one question in several forms: did the clock start when the law says it started, and did the lender do what the clock required. A file built this way answers it in an hour.

What We Tell Digital Lending Teams

The point of sale is the best place to put an AI agent in origination because it is where the most borrower conversations happen and where the least judgment is required. It is also where the compliance clocks start, which means a fast, conversion-optimized agent built without the trigger logic is a liability generator that also happens to convert well.

The way we deploy it at Sei is to build the conversion flow and the clock logic as one system, so the thing that makes the borrower experience good and the thing that keeps the examiner satisfied are the same code path. Build them separately and the conversion team will always win the argument, because their metric is on the dashboard and the compliance cost shows up two years later in an exam. Build them together and the question never comes up.