The ideal mortgage broker software stack for a UK advice firm

Most discussions of a broker software stack are lists of tools. The more useful way to look at yours is as a set of joins. Every place where information leaves one system and has to arrive in another is where time gets lost, where records disagree and where a compliance problem is created quietly.

A firm with four well-chosen tools and clean joins runs better than a firm with two prestigious platforms that do not speak to each other. So build the stack around the hand-offs, not the logos.

Find your joins first

Write down your process and mark every point where a human moves data by hand. A typical firm finds more than it expected:

• Website enquiry into the CRM.
• CRM into the sourcing system.
• Sourcing output into the case file and the suitability record.
• Client documents from email or a portal into the case.
• Case data into the lender's own portal.
• Completion into the accounting or commission record.
• Completion into a future review date.
• Everything into whatever the network or compliance function requires.

Each of those is a candidate for automation, and each is a place where two systems can hold different versions of the truth. You are not trying to eliminate all of them; you are trying to know where they are.

Decide the source of truth for each data type

This is the single decision that determines whether a multi-tool stack works. For every important field, one system must win. Client contact details, fact-find answers, documents, case stage, advice records, review dates and revenue figures each need a home, and everyone needs to know which home.

Where two systems both hold something — which happens often for AR firms with a network platform — write down which one is authoritative and what the rule is when they disagree. An undocumented answer becomes "whichever one the person asking happens to open".

What integration actually means

Vendors use one word for at least four different things, and the difference is the whole point.

• A link: one system opens the other with the client's name pre-filled. Saves a search, nothing more.
• A one-way push: data goes across at a moment in time and does not update afterwards.
• A two-way sync: both sides stay current, with rules about which side wins on conflict.
• A workflow integration: an action in one system genuinely changes state in the other.

When a vendor says they integrate with a tool you rely on, ask which of those four it is, whether it is live today or on a roadmap, whether it costs extra, and whether it is built by them or by the other party. Ask for the name of a customer using that specific connection.

Where the joins usually break

Sourcing into the case record. Research is done in the tool the adviser trusts and then summarised by hand into the file. It is the most expensive unnoticed cost in many firms, because it happens on every case and looks like normal work.

Documents. A file that arrives by email has to be named, filed, checked for age and matched to a requirement. A portal that collects against a request list removes most of that; a portal nobody uses removes none of it, because the team simply falls back to email.

Lender submission. Some data will be rekeyed into a lender portal and you should plan for it rather than expecting it to vanish. What you can control is that the case record afterwards reflects what was actually submitted.

The review date. This is the join that fails silently. The case completes, the file closes and nothing creates the obligation to speak to that client in three years. Firms lose more revenue here than anywhere else in the stack.

Adding a tool without adding a problem

Before anything joins the stack, answer four things: which existing step it removes, who owns it, where its data goes when the case is finished, and what happens if the supplier disappears or triples its price.

Also ask what it duplicates. Stacks bloat because nothing is ever retired. If the new product overlaps something you already pay for, decide now which one you are switching off, and put a date on it.

Keeping the stack accountable to UK obligations

Each system holding client data is part of your data protection position. Keep a short register: what it holds, where it is hosted, how long it retains data, who at your firm can access it, and what the contract says about processing. If you are an appointed representative, confirm your principal is content with each addition rather than discovering the objection during a file check.

Where a tool uses AI on client information, the same register should note what is processed, whether outputs are logged and who reviews them before anything reaches a client.

A stack that holds up

The test is not how modern it looks. It is whether a new administrator, in their second week, can open one screen and tell you the state of any case in the firm without asking anyone. If they can, the joins are working. If they need to check three systems and an inbox, the stack is a collection of subscriptions and the real operating system is still somebody's memory.