For mortgage broking networks, aggregators and lenders, the data that matters most rarely lives in one place. Loan records sit in loan and aggregator systems, broker details sit with head office, and client conversations happen in the CRM. When those systems don't talk to each other, the business can't act on what it already knows. A fixed-rate term rolls off, and nobody gets a nudge to call the client.
Connecting HubSpot to a central data platform, such as Google BigQuery, Snowflake or Databricks, is how most finance businesses close that gap. If you're weighing up how to do it, or who to do it with, this guide covers the decisions that shape the result: native or custom, what it costs, how long it takes, and how to get your brokers and internal team ready.
Why does broker and loan data end up disconnected?
Broker and loan data ends up disconnected because each system was chosen to do one job well, and broking networks grow by adding brokers, franchises and systems over time. The data platform and the CRM usually arrive at different points, owned by different teams.
The result is a business that runs on manual reconciliation:
-
Head office pulls reports from several places to see how the book is performing.
-
Brokers see only part of the client's history.
-
A client who has dealt with two brokers in different states can receive two versions of the same message, and nobody can say with confidence which broker owns the relationship.
The fix is to give each system a clear job:
-
The data platform becomes the single source of truth for loan, broker and client data.
-
HubSpot becomes the place brokers and head office act on it: sending the right message, creating the right task, and seeing the full picture on the client record.
What data should move between HubSpot and your data platform?
In most broker networks, loan and broker data flows from the data platform into HubSpot so people can act on it, and engagement data flows back so reporting is complete. Deciding what moves, and in which direction, is the most important design decision in the project.
The common mistake is to sync everything. That creates noise in the CRM, adds cost, and puts sensitive financial data in front of people who don't need it. Syncing too little has the opposite problem: brokers still switch systems to answer basic client questions.
A better starting point is the actions you want to trigger:
- Settlement dates, loan status, fixed-rate expiry dates and the assigned broker are typical candidates to bring into HubSpot, because each one drives a conversation.
- Email engagement, campaign opt-ins, tasks and property report sends are typical candidates to send back, because they complete the picture for reporting.
Everything else can stay in the data platform, where it is governed and queried.
Should you use a native connector or build a custom integration?
Use native connectors where they cover what you need, and custom integration where your business rules have to travel with the data. Most broker networks end up with both.
Native options have matured.
-
HubSpot's Snowflake Data Share passes HubSpot data into Snowflake without a pipeline to maintain, though it requires HubSpot Data Hub Enterprise and your own Snowflake subscription.
-
Databricks offers a HubSpot connector through Lakeflow Connect (still in beta as of 6th Oct).
-
Managed ELT (extract, load, transform) tools such as Fivetran and Airbyte cover most other combinations, including BigQuery.
The limitation is that most native options move data one way, from HubSpot into the warehouse, and none of them know how your network works.
-
They can't decide that a broker should only see their own clients, that a primary broker sends communications while a secondary broker can only view, or that a record must pass validation before it reaches the warehouse.
When those rules matter, and in a franchise broking network they usually do, a custom integration built on HubSpot's APIs is the answer.
Custom doesn't have to mean forever. For Mortgage Choice we built a custom integration to sync BirdEye reviews into HubSpot, and BirdEye has since released its own native HubSpot integration. Reviewing custom builds against the marketplace every year or so keeps your maintenance load as small as it can be.
What does it cost, and how quickly can you move?
The cost of connecting HubSpot to a data platform has three parts: licensing, the build, and ongoing ownership. How quickly you can move depends mostly on how clearly your data rules are defined before anyone writes code.
Buyers often compare build quotes and miss the other two.
- Snowflake Data Share, for example, needs HubSpot Data Hub Enterprise plus Snowflake compute.
- Managed ELT tools are usually priced on data volume.
- A custom integration needs hosting, monitoring, and someone to update it when an API changes.
- A cheaper build can become the more expensive option once two or three years of running costs are added.
On speed, a native connector can be running soon after licensing is in place, while a custom integration takes longer because it encodes more of your business. In our experience the biggest delays come from decisions: agreeing who owns a client, what head office is allowed to see, and what your security team needs to sign off. Settle those early and the build moves quickly.
How do you prepare your business and your brokers?
Prepare by agreeing data ownership and access rules before the build, involving your security team from day one, piloting with a group of brokers, and deciding who owns the integration after launch. The technology is the smaller part of the change.
In a broking network, brokers often run their own businesses under one brand. If they don't trust the data, or feel head office campaigns are being pushed to their clients without a say, adoption stalls. And if all the knowledge of how the integration works sits with an outside partner, the business is exposed the moment that partner steps away.
What should you look for in an integration partner?
Look for a partner who works confidently on both sides, HubSpot and your data platform, who can deliver inside your security process, and who designs for handover from the start. Gaps between a CRM partner and a data team are where most finance integrations stall.
A CRM-only partner often stops at the edge of the warehouse. A data-only team may not know HubSpot's objects, associations and API limits. The space between them, where ownership rules, validation and two-way sync live, ends up with your internal team by default.
Four questions help separate the options:
- Have you built two-way integrations between HubSpot and our data platform, with access rules enforced in HubSpot?
- Can you build and host inside our cloud environment, and work through our security review?
- Will you tell us where a native connector is enough, even when a custom build is the bigger project?
- How will our team take over the integration when the project ends?
What does this look like in a broker network?
For Mortgage Choice, a franchise-style broking network of around 3,000 brokers, operating under REA Group, we connected HubSpot to the business's existing data lake on Google Cloud through a BigQuery sync. Loan, broker and client data flowed into HubSpot with strict partitioning, so each broker saw only their own clients.
We built two HubSpot portals on top of that data:
- The broker portal supported marketing and client outreach, with ownership rules for clients shared across brokers and the option for brokers to opt in or out of head office campaigns.
- The manager portal gave Mortgage Choice's broker managers reporting and automation based on loan data, including alerts when a client's fixed-rate term was about to expire.
- Because records flowed on to the data warehouse, we rebuilt the contact and deal interfaces with data validation before save, so every record met the warehouse's format requirements.
- Every build was hosted on REA Group's stack and signed off by its security team before going live.
The integrations extended beyond the warehouse, including a custom PropTrack CRM card for sending property reports from the client record. Over time, Mortgage Choice's own team rebuilt and took ownership of the BigQuery sync, and an internal team was trained to run the platform. That is what a well-prepared handover looks like.
"At Mortgage Choice, the integration had to do more than move loan data. Broker-level access rules, validation before records reached BigQuery, and a clear handover made it work for the network and the team who would own it"
We've been building custom integrations since 2009, and as accredited partners of Snowflake, Databricks and Google Cloud, we work on both sides of the connection.
Frequently asked questions