LOCAL-FIRST SCREENING

Screen a name without uploading your customer list

Most screening tools work by sending names to a vendor. This one downloads a signed list and matches in the tab, so the names you type never leave the device.

No account. Nothing you type is uploaded. The first visit downloads the matcher and the signed list (up to about 80 MB); repeat visits reuse the cached copy.

The problem with "just upload the list"

Most screening tools are hosted services. To check a name, you send it — and usually a date of birth, a country and sometimes a passport number — to a vendor's server. That creates a data-processing relationship, a cross-border transfer question, a retention policy you do not control, and one more place your customers' data can leak.

For a small firm, the vendor's security may be better than yours. That does not change the fact that you have added a copy of your customer list outside your control.

What happens instead

Download once

The browser fetches a signed, content-addressed watchlist bundle. The bundle is public data; downloading it reveals nothing about your customers.

Verify before use

The app checks the Ed25519 signature over the pointer, the SHA-256 of the manifest and every chunk, and a monotonic sequence that refuses rollback. A bad bundle is refused, not silently used.

Match in the tab

The matcher runs in a Web Worker on your device. The name you type never crosses the network boundary; the app has no backend screening endpoint and loads no third-party scripts.

What leaves your device

Nothing you type. The app fetches its own static files and the public list bundle, and that is the whole network story. There is no account, no analytics tag, no font CDN, no support widget and no error-reporting beacon.

You do not have to take that on trust. Open the browser's Network panel while you screen a name: the request list stays empty after the initial load. The source is public and MIT-licensed; the content security policy allows only same-origin scripts and data.

The honest trade-offs

  • Download size. The first visit downloads the matcher and list bundle (up to about 80 MB). That is the price of not having a server do the matching.
  • No central audit trail. Records live in the browser. If you need a server-retained, organisation-wide log, this is not that product.
  • Your device is the boundary. Device encryption, screen locks and browser profile hygiene matter more when the data never leaves the machine.
  • Public lists are still public. Local matching protects your customer data, not the sanctions list. The list itself is downloadable by anyone.

When a vendor is the right call: you need continuous monitoring, case management across a team, regulatory reporting, or a contractual SLA. Local-first is a data-minimisation choice, not a complete compliance stack.

Questions

Is the data really not uploaded?

Correct. The matching happens in the browser tab against a list the browser downloads. There is no API that receives a name. You can verify this in the Network panel and in the open source.

Does this help with GDPR?

It reduces the data you send to a processor, which can simplify the transfer and processor questions. It does not by itself make you GDPR-compliant; you still need a lawful basis, notices and records.

How do I know the list is genuine?

The pointer is signed with a pinned Ed25519 key, and every chunk is content-addressed. See Trust and verification for the exact checks and how to inspect the published version.

Can I verify the source?

Yes — the repository is public and MIT-licensed, including the verification path and its tests.