Mortgage broker remortgage database

Every brokerage says it has a remortgage database. In practice most have a CRM containing several hundred client records, an unknown number of which carry a product end date, some of which are wrong, none of which triggers anything automatically.

The gap between those two states is a data problem with a small amount of process wrapped around it. This is how to close it.

Decide what a record must contain

A database is only as useful as its worst field. Before importing or cleaning anything, define the minimum set that makes a maturity actionable.

• Product end date, as a date field rather than free text. This is the spine of the whole thing and everything else is secondary.
• Lender and product type, so you know whether a product transfer is likely to be the competitor.
• Early repayment charge end date, which is frequently different from the product end date and determines when the client can move without penalty.
• Original loan amount, term and completion date, giving you an approximate current balance.
• Property type and any characteristic that constrained lending, such as construction or leasehold issues.
• Employment or income basis at the time of advice, flagged where it was self-employed, contract or bonus-dependent.
• Whether protection was arranged, declined or never discussed.
• Marketing permission and its source, with the date it was given.
• Owning adviser and, separately, owning administrator.

Free-text notes are not a substitute for any of these. You cannot filter on a note.

Clean before you automate

Automation applied to bad data produces confident, wrongly timed messages, which is worse than no automation at all.

Run four passes over the existing records.

Deduplicate. Joint applicants entered twice, clients entered once as an enquiry and again as a case, and name variations all inflate the count and cause double contact. Merge rather than delete so history survives.

Fill the missing dates. Product end dates can usually be reconstructed from the completion date and the product term recorded on the case file. Where they cannot, mark them explicitly as unknown rather than leaving the field blank, so they appear in a queue to be resolved rather than disappearing.

Correct the obviously wrong. Dates in the past that have not been actioned, terms that do not match the product, cases marked live that completed years ago.

Resolve the permissions. For each contact, establish the lawful basis for marketing them and record it. Where you cannot evidence consent or a valid soft opt-in for someone who took a comparable service from you, that contact cannot receive marketing email, and pretending otherwise creates a regulatory problem that dwarfs the commercial one.

While you are here, apply your retention policy. Records you have no reason to hold should be deleted, and a data cleanse is the natural moment to do it.

Build the trigger, not the report

The difference between a database and a list is that a database causes something to happen without anyone remembering.

Set the primary trigger from the product end date, working backwards. A common structure is a first contact at six months, a second at four, and a firm one at three, with the exact timings driven by when your lenders will let you secure a new product in advance. Check that window per lender, because it varies and it determines how early the conversation is useful.

Where the early repayment charge ends before the product does, that date deserves its own trigger, because the client may be paying more than they need to for a period they have not thought about.

Add secondary triggers for the events that make a conversation relevant regardless of maturity: the annual review date, a recorded change of circumstances, and the anniversary of completion for anyone with no protection recorded.

Assign every trigger to a named person. A task that appears in a shared queue belongs to nobody.

Make the outreach worth receiving

The message that fails is the one announcing that the client's rate is ending and inviting them to get in touch. The lender has already sent that, with a rate attached.

What you have that the lender does not is knowledge of the client's actual situation. Reference it. Someone who was self-employed with one year of accounts at the time of the original case now has three, which changes what is available to them. Someone whose property had a lending constraint may find the position has moved. Someone whose income has grown has different options.

Set out plainly what happens if they do nothing, including that they will move to the lender's standard variable rate, and what the alternatives are in general terms. Keep it factual and inside the fair, clear and not misleading standard, which means describing what is possible rather than promising a saving you have not calculated for them.

Keep it accurate as it grows

A database degrades continuously. Two habits prevent it.

First, capture at source. The product end date and early repayment charge date go into the record at the point of offer, by the person handling the case, as a mandatory step before a case can be marked complete. Retrospective data entry never happens.

Second, review the data quarterly rather than annually. Run a short report of records missing a product end date, records with a date in the past and no action, and records with no marketing permission recorded. Fix them while the number is small.

The measure that tells you if it works

Calculate your refinance rate. Take the clients whose products ended in the last twelve months and work out what proportion refinanced through you.

That single figure is the return on the whole exercise. Track it quarterly. When it moves, look at which trigger produced the difference, and when it does not, look at whether the contacts were actually made or whether the tasks sat in a queue.

Also count the maturities you missed entirely, meaning clients whose product end date passed with no contact recorded. That number should be approaching zero, and if it is not, the problem is the process rather than the data.