Merchant Signal: New-Merchant Leads From Public Records

Every day, somewhere near you, someone signs a lease, files a license, and opens a business. That business needs a way to take a credit card before it makes its first sale. It is one of the most predictable purchases in the economy.

So here is the strange part. The people who sell card processing usually find out months later, when that merchant shows up on the same recycled list everyone else is already dialing. The timing is backward. The need is sharpest in week one, and the outreach lands in month six.

We kept running into that gap, so we built something to close it. It is called Merchant Signal, and this is how it came together.

Merchant Signal is a lead tool that surfaces newly opened and about-to-open businesses, built from public business-license filings, for the people who sell payment processing.

Where new-merchant leads actually come from

The useful insight was not technical. The moment a business needs payment processing is already a matter of public record. Cities and states publish new business-license filings and registrations, and a freshly filed license is a business that, by definition, did not exist last month and now needs to operate, hire, and get paid. The best new-merchant leads are sitting in plain sight.

Nobody was packaging that into something a salesperson could actually work. The records are scattered across dozens of city and state open-data portals, each with its own format, its own field names, and its own quirks. The raw data is free. The usable product is not.

That gap, between public data and a usable product, is where most good software ideas actually live.

How do you find businesses that just opened?

The payments world is drowning in lists. Any agent can buy a hundred thousand business records tomorrow. What they cannot buy is timing.

A merchant who opened last week is a fundamentally different prospect from one who opened five years ago. The new one is making first decisions: who processes the cards, who handles the point of sale, who they will still be using in three years out of pure inertia. The established one already has a provider and a reason not to think about it. Same industry, same address, completely different conversation.

So we built Merchant Signal around recency instead of size. The method is simple to describe: monitor public business-license and registration data, filter to the last few weeks, and rank what is left by how new each business is and whether it already accepts cards. A smaller list of businesses that genuinely just opened will out-earn a giant list of businesses that opened whenever, because it catches people while the decision is still open. Every lead carries a plain-English reason it is worth a call right now, like a license filed in the last few weeks with no processor yet on file. That one line is the whole product in miniature: not just who, but why now.

What Merchant Signal does

Merchant Signal watches public records and surfaces the businesses that just opened or are about to. Each lead is scored on how new it is, whether it sits in a card-present vertical like retail, restaurants, or personal care, and whether it already accepts payments. The freshest, highest-fit businesses sort to the top, so a rep works the best opportunities first instead of reading top to bottom.

Where the public record includes a phone number, the lead ships callable. Where it does not, you get the full record, the business name, address, vertical, and the why-now, and you add contact data with your own enrichment tool. We are upfront about which markets are which.

It is live today in 15 markets across 11 states, refreshed every week so the list never goes stale. A free account unlocks one full ZIP with real phone numbers and no card, so anyone can judge the data before they pay. You can see it at merchantsignal.kingbirdsolutions.com.

Underneath, it is a small, repeatable pipeline: pull the latest filings, normalize the messy fields into one shape, score each business against the verticals that matter, drop anything too old, and publish. Adding a new market is a configuration change, not a rewrite, which is why coverage can grow week over week instead of in big quarterly lurches.

The messy part nobody sees

The demo looks clean. The data underneath is not, and that is the actual work.

Every city and state names its fields differently. One portal calls it business_start_date, the next calls it creationdate, a third buries the open date three columns over from a field that looks like the open date but is the license expiration. Some feeds carry phone numbers. Most do not. A few publish dates that are flatly wrong, like a business that supposedly opened in the year 2092, which will happily sort to the top of a newest-first list if you let it.

So a lot of the build is unglamorous judgment. Deciding which date field actually means "this business is new." Throwing out the records that are too old to matter and the ones with dates that cannot be real. Collapsing duplicates. Refreshing on a schedule so last week's list does not quietly become this week's list. None of that shows up in a screenshot, and all of it is the difference between a real product and a spreadsheet.

We were also honest with ourselves about where the data simply is not there. Some large metros publish nothing usable. A couple of states have no open-data portal at all. Rather than fake coverage we do not have, we ship the markets where the public record is genuinely good and keep adding as more come online.

The constraints we picked on purpose

The interesting decisions in a build like this are the ones you make about what not to do.

We built on public records, end to end. Every lead traces back to a filing a city or state already publishes. That keeps the data transparent, easy to stand behind, and free of credit-bureau information. It also means the same pipeline that serves one market serves the next, so coverage grows on its own each week.

We let the data set the honest line. Some markets have phone numbers in the public record and some do not. Rather than paper over that, the product says so plainly: verified markets ship a phone on every lead, the rest are bring-your-own-contact. Honest coverage beats a promise you cannot keep on the first call.

We shipped the thin slice. The first version did not try to cover all 50 states. It covered the markets where the data was genuinely good, proved the model, and grew from there every week. A working product in a handful of markets teaches you more than a roadmap for all of them.

What it looks like in practice

Picture a rep starting their week. They pick their territory, and the screen fills with the businesses that opened in the last stretch, sorted best first, each with a reason to call. They work down the list, mark the ones they have contacted so they are not dialing the same shop twice, and export the rest to drop into whatever they already use. Next Monday the list is new again.

That is the whole point. Not a bigger haystack, a shorter one, refreshed often, pointed at the people most likely to say yes.

The lesson if you are sitting on a data idea

Most founders we talk to assume a data product requires a proprietary dataset nobody else has. Usually it does not. It requires taking data that is technically public but practically unusable, and doing the unglamorous work of making it usable: the cleaning, the scoring, the recency, the weekly refresh, the honest labeling of what you have and what you do not.

That work is the product. The public record is just the raw material.

If you have an idea shaped like that, a signal hiding in messy public or internal data, the build is more approachable than it looks. The hard part is rarely the scraping or the AI. It is the judgment about what to include, what to throw out, and where to tell the truth about your own limits. That judgment is most of what we do at Kingbird, and Merchant Signal is a working example of it. If you want a read on your own idea, you can run the free diagnostic.