Name, date of birth, address history, again
The client's details are in the CRM from the fact find. The broker opens the sourcing system and enters income, deposit, property value and commitments to search for products. Then they open the lender's portal for a DIP and type names, dates of birth and three years of address history. Then the full application, with much of the same again, plus employment details.
By the fourth entry the broker is copying from one window to another, and a digit in a postcode or a month in an address date goes wrong. The lender's credit search does not match, and the case stalls while everyone works out why.
Why the systems do not share
Mortgage brokerages use several systems that were built separately. Some CRMs connect to sourcing tools such as Twenty7tec or Mortgage Brain, and some lenders accept applications through those routes. But coverage varies, fields do not always map, and many lender applications still start from a blank form in the lender's own portal.
Brokers often do not know which integrations they already have, or whether they are being used fully. Habit wins: they type it again because that always works.
- CRM, sourcing and lender portals built by different companies.
- Integrations exist but do not carry every field.
- Lender portals that only accept typed entry.
- Brokers unaware of integrations already available to them.
- Address history and employment details retyped most often.
What rekeying costs
| Field | Common error when retyped | Consequence |
|---|---|---|
| Address history | Wrong dates or postcode | Credit search mismatch |
| Date of birth | Day and month swapped | Identity check fails |
| Income | Gross and net confused | Sourcing or DIP based on wrong figure |
| Commitments | One missed | Underwriter query later |
Time is the visible cost, and it adds up across every case. The errors cost more, because they surface later, often as a failed search or an underwriter query, and take longer to unpick than they took to make.
How we reduce rekeying
- We map a typical case from your fact find to completion, noting every place each piece of data is entered.
- We check which integrations your CRM and sourcing tool already support, and whether they are switched on and used fully.
- Where systems offer APIs, we connect them so data flows from the CRM onward, and results such as DIP outcomes flow back.
- Where a lender portal accepts no automated input, we produce a case summary laid out in the order of that lender's form, so copying is fast and easy to check.
- Before submission, key fields in the application can be compared with the CRM record, and differences flagged.
- We do not use tools that log into lender portals as staff to fill forms automatically, unless the lender permits it.
What brokers get back
Client data is entered once, at the fact find, and reused. Brokers spend less time copying and more time advising. Errors in names, dates and addresses drop because the same data travels rather than being retyped. And where copying is still needed, it is quicker and checkable.
Sometimes the answer is simpler than a build: an integration you already pay for is not switched on. If that is the case, we will say so.
Recognise the copying?
- Brokers type the same client details into three or more systems.
- Credit searches fail because of typos in address history.
- You are not sure which integrations your CRM already has.
- DIP results are copied back into the CRM by hand.
- Lender application forms are filled from scratch each time.