Mortgage broker standard operating procedures

Every brokerage has standard operating procedures. In most firms they are stored in the memory of whoever has been there longest, which works fine until that person is on holiday, leaves, or turns out to have been doing something differently from everyone else for three years.

Writing them down is not a compliance exercise, though it helps there too. It is a way of making the firm survive its own staff turnover.

Why most SOP projects fail

They start with an ambition to document everything. Someone blocks out a week, writes forty pages, saves it in a shared drive, and it is out of date within two months because the CRM changed and nobody updated the screenshots.

The failure is structural. Documentation that lives away from the work will not be maintained, because maintaining it is nobody's job at the moment the thing changes.

Two design choices avoid this. Write procedures at the point of use rather than in a central manual, wherever your systems allow it. And accept that you will document maybe a dozen processes properly rather than fifty badly.

Choose the dozen

Rank candidate processes by two criteria: how often it happens, and how bad it is when it goes wrong. Document the ones scoring high on both first.

For a typical brokerage that produces something like:

• New enquiry handling and qualification.
• Anti-money-laundering and identity checks.
• Fact find and objectives capture.
• Document collection and verification.
• Case packaging and lender submission.
• Post-submission progression and client updates.
• Offer received to completion.
• Post-completion and review diarising.
• Complaint handling.
• Data breach response.
• Adviser absence cover.
• Client data requests.

The last four are rare and severe, which is exactly why they need writing down. Nobody improvises well during a data breach.

What a good procedure document contains

Keep to a consistent shape so people know where to look.

Purpose, in one sentence. What this process is for and where it starts and ends.

Owner. A named role responsible for the process working and for keeping the document current.

Trigger. What causes this process to start.

Steps, in order, written as instructions to a person. Each step says who does it, in which system, and what the output is.

Decision points. Where the process branches, what the test is, and who decides.

Exceptions. What to do when the normal path does not apply, including who to escalate to.

Definition of done. How you know the process is complete.

Version and date. Non-negotiable, because a procedure with no date is untrustworthy.

Write for the person who joined last month

The most useful calibration is to write for someone competent but new. That means naming systems and screens explicitly rather than assuming, spelling out abbreviations the first time, and not skipping the step that feels too obvious to mention.

The step that feels too obvious is almost always the one that gets missed. Experienced people do it automatically and therefore do not think to say it.

Have a genuinely new person test each procedure by following it literally. They will find the gaps in twenty minutes and the gaps will be embarrassing, which is the point.

Keep them short

A procedure that runs past two pages will be skimmed. If a process genuinely needs more than that, it is probably two processes that should be split, or it is carrying explanatory material that belongs elsewhere.

Separate the how from the why. The procedure says what to do. If people need to understand the reasoning, put that in a separate short note, because mixing them makes both harder to use.

Ownership and maintenance

Every procedure needs a named owner, and the owner should be the person who does the work most often rather than the principal. People maintain documents they use.

Set a review cadence and put it in the diary, but do not rely on it alone. The stronger habit is a rule that whoever changes a process updates the document at the same time, and that this is treated as part of making the change rather than as follow-up.

A simple change log at the bottom of each document — date, what changed, who changed it — is worth the thirty seconds it takes.

Format matters less than location

Firms spend a surprising amount of energy choosing between a wiki, a shared drive, a knowledge base and the case management system itself.

The only criterion that matters is whether the procedure is visible at the moment the work happens. A checklist embedded in the case record beats a beautifully organised wiki that requires opening a second tab. If your system supports task templates, stage checklists or required fields, most of your procedure can live there and the written document becomes a short companion rather than the primary artefact.

The compliance overlap

Some of your procedures will overlap with things your firm is required to have: identity verification, complaint handling, data protection, vulnerable customer treatment, record keeping, financial promotions. In those areas the procedure must reflect actual requirements, not a reasonable-sounding version of them.

If you are an appointed representative, your network will supply or approve several of these, and where their version exists it governs. Do not write a parallel one; write a short local procedure that says how their requirement is executed in your office, and point to theirs for the requirement itself.

If you are directly authorised you write your own, and you should have them checked by whoever provides your compliance support. Confirm any specific timescale, threshold or retention period against the FCA Handbook rather than taking it from a template. Nothing here is compliance advice.

Starting without a project

Do not schedule an SOP week. Write one procedure this month, for the process that most recently went wrong. Test it on someone. Fix it. Then do the next one.

Twelve months of that and you will have a documented firm, built out of things that were actually broken, which is a far better set of documents than any single-sitting effort produces.