Privacy Policy

Privacy + government access

What we collect, what we don't, and what happens if the government asks.

The short version: a registrant row holds an email, a name, and a few optional fields you chose to share. We don't ask for immigration status, we don't ask for a home address, we don't ask for a social security number. If a court order ever compels disclosure, only what's in the row can leave — there are no extra columns, no enriched profile, and no shared pipeline with any law-enforcement agency to correlate against. Below is the same picture as a diagram so you can see every field at once.

Why this answer matters to you, your family, and your community.

• →For you: a column we don't ask for can't be handed over. Immigration status, home address, and SSN aren't in the row, so they can't leave the row.
• →For your family: registering doesn't create a contact graph the government can pull. Household entries are scoped to people you add yourself, and we don't buy data-broker lists to enrich them.
• →For your community: a registry that holds the minimum a count needs is the registry that survives the next administration. The less we hold, the less is at risk.

The full legal detail — including the four enforcement mechanisms (board control, append-only audit log, narrowed disclosure, post-dissolution data deletion) — sits in the sections below.

Our promise on your data

Plain English. Six answers.

Who owns the data?

The 501(c)(3) — National Albanian Registry. Held in trust for the community, not by any individual board member. If the organization ever winds down, the data goes with it (deleted, not transferred or sold).

Where is it stored?

Supabase Postgres in US-East, encrypted at rest (AES-256). TLS for everything in transit. No third-party data warehouse, no analytics export, no off-site copies.

How is it used?

Three things: (1) the community count published in our annual Impact Report (aggregate only), (2) the business directory for Albanian-owned businesses who opted in, and (3) transactional email tied to your registration (certificate, deletion confirmations, account changes). Marketing email is optional. The marketing checkbox at registration is pre-checked — uncheck it before submitting to opt out, or unsubscribe from any marketing message anytime via the one-click link in every send. Transactional mail (your receipt, your magic-link, account-change notifications) always reaches you regardless of marketing preference. We do not record when you open or click links in our email; the only link-attribution we keep is the UTM tag we add ourselves before sending.

Who decides if usage changes?

Two of eight managing-board members must approve any substantive change to how data is collected, used, or shared. Each proposal is filed in the public governance log before anything ships; the founder has no override. We're seating an advisory board of twelve community leaders this year that gets a vote on bylaws-level changes — while it's being seated, those decisions take six of eight managing-board votes plus a public-comment window (Article X). After IRS approval, a third-party custodian holds the codebase, database, and bank account independently. Material changes are notified to registrants who opted in and posted to this page with a dated changelog.

What we will never do.

Sell your data. Share an individual record with any government — foreign or domestic. Hand records to advertisers. Match you against campaign databases. Hand registrant lists to other Albanian-American organizations — VATRA, AANO, regional federations, religious institutions, anyone — even when their cause is good. We can publish aggregate counts anyone is welcome to use, and we can refer interested registrants to a partner organization one at a time with that registrant's explicit per-referral consent, but bulk lists never leave the registry. Collect immigration status, social security numbers, or anything we don't strictly need. If a court order ever compels disclosure, we publish that fact and notify you before any record leaves our hands.

What if the board steps away?

Continuity is built into the bylaws, not into one person. Managing-board members rotate per the 501(c)(3) bylaws without disrupting operations. No individual member can unilaterally change how data is used — see the four mechanisms below. If the 501(c)(3) ever winds down, the data is deleted as part of dissolution — never transferred or sold. Your certificate stays verifiable independently of us: every cert is signed as a W3C Verifiable Credential whose public key is published at /.well-known/did.json, so any third party can confirm authenticity without our servers running.

Your rights — export, edit, delete — are self-service from your account. Detail below.

Running an Albanian-American organization evaluating whether to share data with us, endorse us, or refer your members? Read the partner FAQ →

How we enforce this

Four mechanisms — bylaws + database, not a marketing promise.

Every claim above maps to a concrete control we can point to in the bylaws, the database, or the public governance log. If we ever break one of these, you can point to the exact mechanism that should have stopped us.

1. 01

   No one person controls this.

   Substantive changes to how registrant data is collected, used, or shared require at least two of eight managing-board votes (the data_usage_change threshold in src/lib/governance.ts). Bylaws-level changes go higher (75% advisory in steady state, 6-of-8 founders during the Article X bootstrap). Every proposal is filed at /admin/governance/propose and surfaced on /governance the moment it's executed. The president has no override authority — Article IV makes that explicit, and the audit log catches anyone who tries. After IRS approval lands, a third-party custodian (independent of the board) will hold the codebase, the production database, and the bank account, so even the eight of us can't unilaterally pull a copy of the registry.

2. 02

   The audit log is append-only at the database layer.

   Every INSERT, UPDATE, and DELETE on the registrants, donations, admin_users, donations, and other PII tables fires the audit_table_change trigger and writes a row to audit_log with the actor's email, the old + new values, and the timestamp. Every email Resend sends writes a row too. We don't currently log SELECT (read) queries — that's an honest limitation; reading the data leaves no trace, but changing it always does. Two further Postgres triggers (audit_log_no_update, audit_log_no_delete) raise errcode 23514 on any UPDATE or DELETE attempt against audit_log itself — so even an admin connected directly to Supabase Studio can't rewrite or erase history. Corrections are new rows that supersede old ones; the original is preserved forever.

3. 03

   Compelled disclosure is narrowed, notified, and published.

   If a government — federal, state, or foreign — compels disclosure of any individual record, three things happen before any data leaves our hands, all written into Article VII: (1) we narrow the scope of the request to the minimum the law actually requires; (2) we notify the affected registrant before disclosure unless the order itself includes a non-disclosure clause — and even then we notify once that prohibition lifts; (3) every request is recorded in the gov_compelled_disclosures table and surfaced in the annual transparency report (number of requests, broad nature, scope), within 30 days of the disclosure event. The order itself is published when the gag clause permits; otherwise the transparency-report row carries the redacted summary.

4. 04

   If NAR ever dissolves, your record stays yours.

   Article IX governs dissolution. Once a dissolve_org action accumulates the required approvals and org_meta.dissolved_at is set, the site flips to read-only at the middleware layer — every write endpoint returns 503 with a clear error. Article VII's data-deletion procedure then runs: registrant rows are purged, donor records are kept only at the IRS-mandated minimum (name + amount + date + ZIP, no contact info), and remaining 501(c)(3) assets transfer to a like-purpose successor per IRS rules — registrant data is explicitly excluded from that transfer. Your heritage certificate keeps verifying through a W3C Verifiable Credential signed at issuance with an Ed25519 key. The public key stays published at /.well-known/did.json (with deactivated: true after dissolution, so verifiers know the org has wound down — but the signature still validates). No registrant record is sold, transferred, or handed to a successor org.

5. 05

   No board member uses the data for personal, business, or political benefit.

   The rule: Article XII §5 of the bylaws prohibits any admin — or family member or affiliated business — from using registrant data for personal, business, or political purposes outside NAR's mission. That covers solicitation for personal businesses, partisan outreach, fundraising for unrelated causes, and any bulk export other than a registrant's own request. Aggregate counts published in the annual Impact Report are exempt because they carry no individual identification.

   How it's enforced — four overlapping layers:

   1. Database-level: every change to registrants, donations, and admin_users writes a permanent row to audit_log with the actor's email. The triggers (audit_log_no_update, audit_log_no_delete) prevent anyone from rewriting that history afterward.
   2. Approval gate: any new bulk query, export, or data-sharing arrangement requires two-of-eight managing-board approval, filed in the public governance log before any data leaves.
   3. Investigator panel: a credible report of personal-use violation triggers the Article XIV §2 panel — three conflict-free admins review before removal proceeds. Bad-faith filings circle back as their own removable offense (Article XIV §6).
   4. Third-party custodian (post-IRS approval): the codebase, production database, and bank account are held by an independent custodian who is not on the board. No seated admin can pull a copy of the registry unilaterally — the custodian is in the loop.

   Result: a board member who tries to use the data for their own business has to (a) bypass the access policy, (b) leave a permanent log entry tied to their email, and (c) face an investigator-panel review that the rest of the board can refer immediately. Removal under Article V is the documented outcome.

Want to verify? The bylaws are public and the governance log is public. The codebase is held by individual contributors and transfers to the 501(c)(3) within 90 days of IRS confirmation per Article VIII; if you want to verify a specific claim against the code in the meantime, email privacy@albanianregistry.org.