Can AI summarise bank statements for mortgage brokers?

Partly, and with more caveats than any other task in this area. A statement is a dense grid of numbers where a single misread digit changes an affordability picture, and the tools most brokers reach for are optimised to produce fluent text rather than exact arithmetic.

It is still worth doing in a limited way. The trick is knowing which parts of the job are safe to hand over and which parts will quietly embarrass you.

What brokers are actually looking for

Reading a statement is not a summarisation task. It is a search for specific things, and the list is short and well known.

Regular income credits, their amounts and their consistency. Existing credit commitments that were not mentioned on the fact find. Rent or maintenance payments. Gambling activity. Returned direct debits and unauthorised overdraft charges. Large one-off credits that need an explanation, particularly anything that looks like a gifted deposit. Payments to other lenders, to debt management companies, or to a landlord. Whether the account belongs to who it should belong to.

Notice that most of these are exception-finding rather than summarising. You are not trying to compress the statement. You are trying not to miss one line in four hundred.

That distinction matters, because language models are much better at producing a plausible overview than at exhaustively finding every instance of something.

Where it is reasonably reliable

Reformatting and description. If you paste in a list of transactions, getting back a tidy grouping by type, or a plain-English description of what a pattern appears to be, is a fair use. You are asking it to describe text it can see.

Flagging things to look at. Asking for anything that might indicate an undisclosed commitment, and treating the output as a list of places to check rather than a finding, works. False positives cost you a few seconds. That is an acceptable trade.

Drafting the question to the client. Once you have identified a payment that needs explaining, producing a clear, non-accusatory message asking about it is exactly the sort of writing these tools do well.

Making sense of an unusual account. Statements from newer banks, foreign accounts or business accounts with unfamiliar transaction descriptors are genuinely faster to interpret with help.

Where it is not reliable

Totals. Do not ask for an average monthly income, a sum of commitments or a count of anything and then use the number. Models are inconsistent at arithmetic over long lists, and the failure is silent: you get a number that looks right. If you need a figure, calculate it or take it from a system built to calculate it.

Completeness. If you ask whether there is any gambling on the statement and the answer is no, that is not evidence of absence. It is one attempt at a scan. For anything where missing an item has consequences, you still have to look.

Scanned and photographed documents. Optical character recognition on a phone photo of a printed statement introduces errors before the model sees anything, and a misread column boundary can attach a figure to the wrong row entirely.

Anything you would put in a suitability file as fact. If a figure ends up in your affordability assessment, its source needs to be the document or a verified feed, not a summary.

The data protection problem, which is the bigger one

A bank statement is about as sensitive as a personal document gets. It reveals health treatment, religious donations, political membership, relationship breakdown, addiction and much else, often about people who are not your client.

Uploading one to a general consumer chat account is not a grey area. You are the controller of that data, you need a lawful basis and a processor agreement, you need to know where it is stored and whether it is retained, and free tiers of consumer tools are frequently explicit that inputs may be kept and reviewed by humans.

Redaction helps less than people hope, because the transaction narrative is the sensitive part and it is the part you need. If you are going to do this at all, do it in a tool your firm has assessed, contracted for, and recorded on its list of systems, with retention set deliberately. A data protection impact assessment is worth doing here; the ICO expects one where processing is likely to be high risk, and bulk analysis of financial documents is a fair candidate.

The better route for most firms

Open banking sidesteps most of this. With the client's consent, the data comes as structured transactions from the bank rather than as an image of a page, categorisation is done by a provider regulated for the purpose, and there is no ambiguity about whether a number was read correctly.

It is not free, the client has to consent and complete a journey, and not every account is supported. But for the core job of getting reliable income and commitment figures, a categorised feed beats an inferred summary comfortably, and the audit trail is far stronger if anyone later asks how you arrived at a figure.

Several case management platforms now integrate this. If yours does, that is where the statement analysis should happen, and a general-purpose model has no business touching the file at all.

A workable position

Use open banking or your existing verification tools for figures. Use a model, if you use one, as a second pair of eyes for exception-finding on a document you have already read, inside a system your firm has properly assessed. Never let a generated number reach a lender or a file without being traced back to source.

And keep the adviser's own review as the thing that counts. If a case goes wrong and someone asks how the commitment was missed, "the summary did not mention it" is not an answer that helps you.