AI for mortgage brokers

Almost every conversation about AI in intermediary firms starts in the wrong place: with a product demo. A better starting point is a question about consequence. If this piece of software gets something wrong, who finds out, how quickly, and what does it cost?

Sort the work in your firm by that question and the picture gets clearer very fast. Some tasks are cheap to get wrong and easy to check. Some tasks reach a client before anyone notices. And some tasks carry regulatory weight that no software vendor will carry for you.

Tier one: mistakes that cost you sixty seconds

This is where almost every firm should begin, because the downside is trivial and the upside is real.

Examples include tidying up a rough set of typed notes into readable prose, turning a long email thread into a short internal summary, producing a first draft of a blog post or a social update, rewriting a paragraph you have written badly three times, or reformatting a list of criteria questions into something you can send to a packager.

The common thread is that you are the only reader. You look at the output, you can see immediately whether it is right, and if it is wrong you delete it. Nothing leaves the building. Nothing enters a client file.

Firms that stall usually stall here, because they try to jump straight to the impressive use cases and get nervous. Spending a month only on tier one work is not timid. It teaches your team what these tools are actually good at, which is mostly rewriting and restructuring text you already have, rather than knowing things.

Tier two: mistakes that reach a client

Drafted emails, meeting summaries that go into a case file, chatbot replies on your website, transcriptions of a client conversation, first-pass summaries of income documents.

These are genuinely useful and genuinely worth doing. They also need a named human between the machine and the outside world. Not a policy that says someone should check. A named person, a defined moment in the workflow, and a way of telling afterwards that the check happened.

The practical trap in tier two is that the output reads well. Fluent text feels checked even when nobody has checked it. An adviser skim-reading a summary that is beautifully written is far less likely to spot the missing dependant, the wrong employment start date or the invented lender name than one reading a scrappy set of bullet points. Good prose lowers your guard, and you have to compensate for that deliberately.

Tier three: work that stays with a qualified human

Deciding what to recommend. Assessing whether a product is suitable for a particular set of circumstances. Judging affordability. Deciding whether a vulnerability disclosure changes how you handle a case. Signing off a suitability report. Answering a complaint.

A language model can produce something that looks like all of these. That is precisely the problem. Your permissions, your competence obligations under the FCA's training and competence rules, and your responsibility to the client under Consumer Duty do not become shared with a vendor because you pasted a case into a chat window. If a decision would need to be defended to a file checker, a network compliance officer or the Financial Ombudsman Service, a person with the relevant qualification makes it and owns it.

That does not mean AI has no place near these tasks. It can gather the inputs, restate them, flag gaps and prompt the adviser to consider something. The line falls at the point of judgement, not at the point of preparation.

The data question that comes before any of it

Before a single tool touches a real case, you need an honest answer to one thing: where does the text go?

Every prompt that includes a client's name, income, address, health information or credit history is a disclosure of personal data to whoever operates the model. Under UK GDPR you are the controller and that vendor is a processor, which means you need a lawful basis, a processing agreement, clarity on where data is stored, and a straight answer on whether your inputs are used to train the model. Free consumer chat accounts are the wrong place for client data. Many are explicit that inputs may be retained and reviewed.

There is also the reverse risk. Personal data ends up inside a tool, and eighteen months later you cannot answer a subject access request properly because nobody knows what is in there. The ICO expects you to know what you hold and where.

Practical version of this: keep a list of every AI tool anyone in the firm uses, what data it is allowed to see, and who approved it. If an adviser has quietly been pasting fact-find notes into a personal account, you want to know now rather than during an audit.

Choosing where to start

Pick two use cases. Not eight. The two should be things your team already complains about, not things that would look good in a strategy document.

For most small intermediary firms, the two that pay back fastest are note capture around client conversations and first drafts of the routine chasing correspondence that nobody enjoys writing. Both are high-frequency, both are text-heavy, and both leave an obvious trail when they go wrong.

Judge them on something you can count. Not "does the team like it", which will always be yes in week one. Count how many minutes pass between a meeting ending and the note being on the file. Count how many document chases it takes to get a full set of payslips. Those numbers are boring and they are also the only honest evidence you will get.

Before you spend anything

Answer these in writing. It takes an hour and it saves a great deal of unpicking later.

• Which tasks in the firm are we willing to let software touch, and which are off limits?
• Who is named as the reviewer for anything that goes to a client?
• What personal data, if any, is allowed into each tool, and who checked the vendor's terms?
• If a client asked whether AI had been used in handling their case, what would we say?
• How would we prove, six months from now, that an adviser reviewed a particular AI-drafted document?

The last one catches most firms out. Reviewing is easy. Evidencing the review is the part that needs a workflow, and it is the part a file check will look for.