FINRA BrokerCheck data feed
- Coverage
- Your CRD list
- Cadence
- Weekly
- Typical volume
- ~10k records
- Difficulty
- Medium
- Price
- $450 / mo
What's in it
Registration and conduct records for the brokers and firms on your list:
- Registration - CRD number, current and former firms, registration status, dates, and states registered
- Employment history - firm affiliations with start and end dates, including gaps
- Examinations - qualifying exams passed, with dates
- Disclosures - customer disputes, regulatory actions, criminal matters, terminations, and financial events, each as its own record
- Disclosure detail - event date, allegation, resolution, and amounts where published
- Change events - new disclosures and status transitions as typed alerts rather than a changed row you have to spot
Disclosures are modelled as their own table with their own delta, because the registration record is context and the new disclosure is the thing you actually needed to know about. Everything is keyed on CRD, which you already store.
Delivery
Weekly refresh on your list, with new disclosures emitted as alerts the run they appear. Lands in S3, a webhook, or your database. Scoped to the CRDs or names you provide; this is not sold as a full copy of the registry.
Why this one is hard
The acquisition is the easy half and it is worth saying so. The public site is driven by a JSON endpoint and FINRA additionally publishes downloadable reports, so where the published files carry the fields you need, the right build uses them and does no crawling at all. I check that route first on every engagement, because a feed with no crawler in it is a feed that cannot break.
The terms are stricter than a government open-records site, and it matters that FINRA is a self-regulatory organisation rather than a government publisher. Public availability is not the same permission that a state open-records statute grants, which is why this feed is scoped to your list rather than offered as a bulk copy, and why CRD space is never enumerated.
The registration record is not the product. Almost everyone building this the first time models a broker row and then discovers the thing their compliance team wanted was a notification that a new customer dispute appeared on someone already in their book. That is a child-table delta with its own identity and its own dedup problem, and retrofitting it onto a flat broker row is painful.
Disclosure text is unstructured and the amounts are inconsistent. Allegations and resolutions are narrative, damages are sometimes ranges and sometimes exact, and a settled dispute and a denied dispute both end up as a resolution string that needs careful reading rather than a lookup table.
Identity resolution against your own records is the recurring friction. Brokers move firms, change names, and appear in your CRM with a nickname. CRD is the strong key when you have it, and when you do not, matching on name and firm and state has to publish its evidence rather than assert a match.
Build versus buy
Build it yourself if your list is small and static and you are happy with a weekly manual check. For a few dozen CRDs this is not a pipeline problem.
Buy it when the list is large enough that a new disclosure could appear on someone and nobody would notice for a quarter. The value here is the alert, not the data, and the cost that recurs is keeping the disclosure delta correct and deduped against your list. Against $450/mo that is usually an easy call.
One use restriction: this feed is not a consumer report and is not licensed for FCRA-covered decisions about employment, credit, insurance, or housing. Broker due diligence and ongoing compliance monitoring are what it is built for.
Related
This feed is part of the Compliance Screening Stack ($3,650/mo) with OFAC sanctions, state AG enforcement actions, and Secretary of State entity status, all resolved to one party model so a broker, their firm, and any action against either arrive as one record.