The Application Arrives Without a Person at the Keyboard
Sierra recently posted a demo of the Personal Agent Protocol, described in its own words as a personal agent "working with Redfin and Rocket agents to find homes in Michigan and get a user pre-approved for a mortgage." A demo is not a production volume, and we make no claim about how many borrowers do this today. But the shape of it is clear, and it is worth taking seriously at the point of sale: the borrower states an intent, and software acting for them does the form-filling, the document-gathering and the back-and-forth with the lender.
Nothing about that changes the rules the application is subject to. Regulation Z, Regulation B, the Fair Credit Reporting Act and E-SIGN were written about the consumer and the creditor, and they do not have a category for "the consumer's software". So the question for a lender is not whether agent-submitted applications are allowed. It is which moments in intake carry legal weight, and whether those moments are still the borrower's own when an agent is doing the typing. We wrote the personal agent readiness guide to cover the whole stack; this post is about the point of sale specifically.
Six Pieces of Information, Whoever Types Them
Under Regulation Z, an application for a closed-end mortgage subject to TRID exists once the creditor has received six pieces of information: the consumer's name, income, Social Security number to obtain a credit report, the property address, an estimate of the property's value, and the loan amount sought (12 CFR 1026.2(a)(3)(ii)). Once it exists, the Loan Estimate has to be delivered or placed in the mail no later than the third business day after the creditor receives it (1026.19(e)(1)(iii)).
The rule does not ask who entered the six items. An agent that holds the borrower's income history, their identity and the listing they are looking at can supply all six in one request. If your intake treats that request the way it treats a borrower submitting the same form, the clock starts at that moment, regardless of whether the borrower was watching.
That has two practical consequences. The first is operational: agent traffic arrives at any hour and in bursts, and an intake process that relies on a loan officer noticing a new file the next morning will miss deadlines it never knew it had. We covered the general version of this in AI at the mortgage point of sale; agents make it sharper. The second is a design choice. Because the six items are a bright line, a lender can decide where an agent's work stops short of it.
Draft Is Not Submit
The cleanest pattern we have seen is to separate the work an agent can do on its own from the act that creates the application. An agent can assemble a draft: everything the borrower would otherwise type, every document the file will need, the property and the scenario. Submitting that draft is a separate action, and it goes back to the borrower for approval, with a plain summary of what they are applying for and what happens next.
The Personal Agent Protocol has a primitive that fits this exactly. Its draft 0.3 guides describe "operations": consequential actions a business asks the user to approve, each with a self-contained summary, terms whose names match the business's own API fields, and an expiry. The approval is recorded with the operation's identifier, its revision, the agent that requested it and the time. Mapped onto intake, submission becomes an operation. The agent proposes, the borrower approves on the lender's side, and the lender has a record that the borrower — not their software — chose to apply.
This is not only tidy. It means the lender can tell, for any application, whether it was submitted by a borrower directly or by an agent with the borrower's approval, which is the first question anyone will ask the day a borrower disputes that they applied.
The Moments That Still Belong to the Borrower
Submission is the most obvious borrower decision at the point of sale. It is not the only one. Each of these carries its own legal or financial weight, and each is a candidate for the same approval pattern.
Authorizing a credit pull. A mortgage application gives a creditor a permissible purpose under the Fair Credit Reporting Act, and many lenders also capture the consumer's explicit authorization before pulling, because it is cleaner evidence and because a pull affects the borrower. An agent relaying "go ahead" is weaker evidence than the borrower approving a pull on the lender's own consent screen. We discussed permissible purpose in a different context in fresh credit and undisclosed debt monitoring.
Consenting to electronic delivery. E-SIGN requires that a consumer's consent to electronic records be given electronically in a manner that reasonably demonstrates the consumer can access the information in the form it will be provided (15 U.S.C. 7001(c)(1)). Whether an agent's acceptance satisfies that requirement on the borrower's behalf is, as far as we know, untested. The safe position is to treat e-consent as a borrower approval, not an agent action. Our E-SIGN post has the background.
Intent to proceed and rate locks. Both commit the borrower. A lock offered to an agent at 9 a.m. should not be acceptable at 9 p.m. at the morning's price, which is why the protocol's operations carry an expiry. Put the lock's terms in the approval, let the borrower see them as written, and record what they accepted.
Anything that changes the deal after disclosure. A changed circumstance requested by the borrower — a different loan amount, a different program — can reset what the Loan Estimate has to say. If an agent can request those changes, it should do so as a proposal the borrower approves, so the change has a borrower behind it and a time on it.
What the Agent Is Good At, and Should Be Allowed to Do
None of this argues for keeping agents out of intake. The work a borrower's agent does well is exactly the work that slows a mortgage down: collecting documents, answering the file's questions, chasing what is still missing. A lender that can tell an agent precisely which documents the file needs, and accept them against named conditions, gets a complete file sooner than one that sends a portal link and a checklist by email.
That argues for a few concrete design choices:
- Publish what the file needs as data. If an agent can read the document list for a given scenario, it can collect it once rather than in four rounds.
- Accept uploads against a named condition. An upload that says which condition it is meant to clear can be verified on arrival, and the agent can be told immediately if it does not.
- Verify everything an agent supplies. An agent will forward whatever the borrower's accounts and inbox contain. That makes it no more trustworthy than the borrower, and possibly less, because it is also a channel an attacker can try to use. Every document should be tested for alteration and fabrication before an underwriter relies on it, as we argue in the document fraud post.
- Answer status with structure. Milestones, open conditions and dates should come back as fields, not prose, so the borrower's agent does not have to interpret a sentence to know whether closing is on Friday.
Adverse Action Still Goes to the Applicant
One last point is easy to miss. Regulation B requires a creditor to notify an applicant of action taken within 30 days after receiving a completed application (12 CFR 1002.9). The applicant is the borrower. An agent that submitted the application may be the most convenient channel to send a decision through, but the notice is owed to the person, through a channel the borrower agreed to. Delivering the notice to the borrower and telling the agent that a decision has been sent is the conservative pattern until the rules say otherwise.
Where to Start
A lender does not need a protocol implementation to get ready for this. It needs to know which steps in its intake carry weight, and to make sure each of them can only be completed by the borrower, whoever did the work leading up to it. Once that line is drawn, letting an agent do everything on the near side of it is mostly upside.
The personal agent readiness guide covers the rest of the stack: how an agent finds you, how you know which agent it is, how the borrower grants access, and how every session ends up in a record an examiner can read.
Ramkumar Venkataraman
CTO & Co-Founder