Where sex-offender screening data comes from

1. The registries are run by jurisdictions, not by anyone national

Under SORNA, “the 50 states, the District of Columbia, the 5 principal U.S. territories and federally recognized Indian tribes that elect to function as registration jurisdictions are all defined as ‘jurisdictions’”.¹ Each one keeps its own registry, with its own fields, its own update cadence, its own website and, often, its own restrictions on bulk access. A registrant appears in the registry of the jurisdiction where they are registered, which is not always where they live or work.

2. NSOPW is a search portal, not a database

The Dru Sjodin National Sex Offender Public Website is “the only U.S. government website that links public state, territorial and tribal sex offender registries in one national search site”. The Department of Justice is explicit about what that means: “Information is hosted by each jurisdiction, not by NSOPW.gov or the federal government”, and “the sex offender registration information that you see on NSOPW.gov is retrieved from the individual jurisdiction(s)”.² Its conditions of use state that the Department “does not guarantee the accuracy, completeness, or timeliness of the information contained in Jurisdiction Websites” and advises that results “should be verified by visiting the individual jurisdiction’s public registry website”.³

Two consequences for a front desk. First, NSOPW is a person-at-a-time search for the public; it is not a feed a kiosk can query for every visitor. Second, “national” in a vendor’s brochure cannot mean NSOPW’s data, because NSOPW holds none.

3. So vendors use aggregators, or build their own

A vendor that screens at check-in needs a local copy of every jurisdiction’s registry that it can query in under a second. There are two ways to get one: buy access to a commercial aggregator that compiles the registries and resells them, or compile them yourself. Raptor’s Service Specific Terms take the first route: sex-offender checks “are performed through one or more third parties and are subject to the terms and conditions of such third parties”, the customer “must enter into an End User Agreement with the third-party provider”, and Raptor “does not screen, monitor or verify any Background Check information and does not guarantee the accuracy, completeness, or quality of such information”.⁴ That is a normal and honest way to write it. It also means the coverage question has to be put to a company you are not contracting with.

Asan Digital takes the second route. EduQueue screens against a database that Asan Digital maintains itself: about 632,000 registrant records compiled from state registries across all 50 states, DC, U.S. territories and tribal jurisdictions, refreshed on a published schedule, with per-state coverage documented. Completeness varies by state, because the states vary in what they publish and how, and we publish that variation rather than claim it away.

4. Why coverage differs between vendors that both say “all 50 states”

• Rows per state is not completeness. A state may publish 20,000 registrants on its website and release 12,000 in a bulk file; a vendor that has the file has “that state” and 60% of its registrants. The honest figure is the vendor’s count against the jurisdiction’s own published count, per state.
• Tiers. Some states publish only higher-tier registrants; lower tiers exist in the registry but not in the public data anyone can compile.
• Refresh. A registry refreshed nightly and one refreshed quarterly both count as “covered”. Ask for the interval per state, not the average.
• Matching. Name plus date of birth from a scanned licence matches far better than a typed name. CENTEGIX’s support documentation says as much: the check “is not 100% accurate” because “users may not always enter correct information”, and it widens a manual date of birth to five years either side.⁵ Vendors handle aliases, hyphenated names and transliterations differently.
• Photos. A match that shows the registry photo next to the licence photo is resolved at the desk in seconds; one that shows a name and a county is not.

5. What “all 50 states” should mean in a contract

Not a phrase. A table: for each of the 50 states, DC, the five territories and each tribal registry the vendor holds, the number of records held, the jurisdiction’s own published count where one exists, the date of the last refresh, and the refresh interval. Then a sentence saying who compiles it, and a sentence saying who is liable if it is wrong. The RFP kit has those rows (3.1.1–3.1.3) written so you can send them to every bidder.

6. The questions to ask any vendor — including us

1. Who compiles the registry data you screen against: you, or a named third party? If a third party, do we sign their terms too?
2. For each jurisdiction, how many records do you hold today, and what is the jurisdiction’s own published count?
3. What is the refresh interval, per jurisdiction, and where is it published?
4. Which tiers are included per state, and which are absent because the state does not publish them?
5. What is matched: name only, name and date of birth, aliases? What happens to a scanned licence versus a typed name?
6. What does the desk see on a match, and who clears a false positive?
7. Do we own the results of screens run on our visitors, and can we export them?
8. Does anything in your terms disclaim the accuracy of the data? (Every honest vendor’s do, in some form. Read the form.)