Data protection for finance brokers: UK GDPR in day-to-day practice

Commercial finance brokers handle a lot of sensitive personal data without necessarily thinking of it that way. Bank statements, ID documents, source of funds evidence, director details, sometimes health or family information buried in a set of accounts. All of it falls under UK GDPR, and the obligations don't disappear just because the client is a limited company rather than a consumer.

This is a practical walk-through of what data protection means for a brokerage day to day: the lawful basis for holding data, how long to keep it, what's reasonable to share with lenders, how to handle a subject access request, and what to do if something goes wrong. It isn't legal advice. Where you're unsure, the Information Commissioner's Office is the right place to check, and its guidance for small organisations is a good starting point.

Lawful basis: why 'the client gave it to us' isn't enough

Every piece of personal data a broker processes needs a lawful basis under UK GDPR. For most brokerage activity, the relevant basis is usually contract (you need the data to provide the service the client has engaged you for) or legitimate interests (for activity like fraud prevention or maintaining business records). Consent is sometimes assumed to be the default basis, but it's actually one of the harder ones to rely on properly, since it has to be freely given, specific, and easy to withdraw.

In practice, most brokers should be relying on contract for onboarding and packaging a deal, and legitimate interests for things like AML screening and record-keeping. It's worth being able to say, for each category of data you hold, which basis applies and why. If the honest answer is 'I've never thought about it', that's a gap worth closing before anyone asks.

What data brokers typically hold, and why it's sensitive

• Identity documents: passports, driving licences, proof of address, which are attractive to fraudsters if not stored securely.
• Financial information: bank statements, accounts, credit reports, source of funds evidence.
• Business ownership data: shareholder and director details, sometimes including information on family members with beneficial interests.
• Correspondence: emails and call notes that can incidentally contain health information, relationship breakdowns, or other special category data picked up while discussing a deal.
• Application data held with lenders and packagers, which the broker has shared and remains partly responsible for.

The last two points are the ones brokers most often overlook. An email thread discussing why a director needs finance urgently can end up holding far more sensitive detail than the ID document sitting in the same folder.

Retention: keeping data only as long as you need it

UK GDPR requires personal data to be kept no longer than necessary for the purpose it was collected for. That sits alongside, and sometimes in tension with, Money Laundering Regulations retention requirements, which typically require AML records to be kept for a set period after the business relationship ends. The practical answer is a written retention schedule: how long client files are kept after a deal completes or falls through, how long unsuccessful applications are retained, and when data should actually be deleted or anonymised rather than just left in an old drive.

A retention schedule that exists only in someone's head isn't a policy. It needs to be written down, applied consistently, and revisited when the rules or the firm's activities change.

Sharing data with lenders and third parties

Passing client data to a lender, packager, valuer, or solicitor is a routine and necessary part of arranging finance, but it still needs a lawful basis and, ideally, a clear line the client can see in your privacy notice about who their data might be shared with and why. A few habits help keep this straightforward:

• Only send what the recipient actually needs for their part of the deal, rather than a full file by default.
• Use secure channels for anything containing ID documents or financial detail, rather than unencrypted email as a matter of course.
• Keep a record of what was shared, with whom, and when, so you can answer a client's question about where their data has gone.
• Check that any third party you share data with on a regular basis, panel valuers, packagers, has its own data protection practices in reasonable order, since a failure on their part can still land on your desk.

This overlaps with the wider onboarding process, since the data collected at the start of a relationship is exactly what ends up being shared later. Building good data handling into onboarding, rather than treating it as a separate compliance task, means less rework further down the line.

Subject access requests

A client, or a former client, can ask what personal data you hold on them and request a copy. These requests don't have to be made formally or even mention GDPR by name. A response is generally expected within one month, and it needs to cover the data itself along with an explanation of how it's being used and who it's been shared with. Brokers who keep client data scattered across personal inboxes, shared drives, and old CRM exports often find the hardest part of a subject access request isn't deciding what to disclose. It's finding everything in the first place.

The firms that struggle with a subject access request usually aren't hiding anything. They just genuinely don't know everywhere a client's data has ended up over the years.

If something goes wrong

A data breach, a misdirected email with a client's bank statements attached, a lost laptop, an ID document sent to the wrong recipient, needs to be assessed quickly. Where it's likely to result in a risk to the individuals affected, it must be reported to the ICO within 72 hours of becoming aware of it. Not every mistake meets that threshold, but the assessment needs to happen promptly rather than being left until someone has time to think about it properly.

• Log every incident, even minor ones that don't meet the reporting threshold, so patterns are visible over time.
• Have a named person responsible for triaging a potential breach the moment it's spotted.
• Tell affected clients directly where there's a real risk to them, rather than only reporting to the regulator.
• Review what allowed the breach to happen, not just how it was fixed, so the same gap doesn't reopen.

Making this manageable day to day

None of this requires a dedicated data protection officer at most brokerages, though larger or higher-risk firms may need one. What it does require is a written policy that covers lawful basis, retention, and breach response, a habit of storing client data in one auditable place rather than across individual inboxes, and someone accountable for keeping the policy current. This sits naturally alongside AML recordkeeping, since a lot of the same documents management that supports AML evidence and KYB checks is exactly what needs to be governed under a proper data protection policy.

Getting the basics right, knowing your lawful basis, keeping a retention schedule, sharing only what's needed, and knowing what to do the moment something goes wrong, covers most of what a brokerage actually needs day to day. The rest is discipline rather than complexity.