VerifAi

Data retention & privacy

What VerifAi stores, what it pools, how long each kind of data lives, and exactly what happens when you export your data, erase one person, or delete your account.

What we store

Everything below is tenant-scoped and isolated from other customers:

  • Your records — email, phone, name, company, address, website, your passthrough columns, and the enrichment and validation fields we derive from them.
  • Validation history — verdicts, reasons, evidence and per-field provenance.
  • Lists, jobs, dedupe clusters and golden records, and their lineage.
  • Quality score snapshots and scoring outcomes — retained longer, deliberately, so that a scoring model can eventually be trained; these stay tenant-scoped and are deleted with your account.
  • Account data — your users (name and email; passwords only as salted hashes, never exported), API keys (only a hash, never the key itself), request logs, usage counters, billing history, webhook endpoints and their delivery history, and hygiene registrations.

What is pseudonymised and shared (the corpus)

To improve validation, catch-all detection and the email finder for everyone, VerifAi keeps a cross-tenant corpus (address_observations and domain_intel) holding keyed pseudonyms — an HMAC-SHA256 of the address — and domain-level intelligence. It never contains the plaintext address.

Two things are true at once, and we state both.

  • We cannot isolate or erase one customer’s entire historical contribution to the corpus. Observations are pooled and keyed only by address hash or domain, with no tenant identifier, so there is no way to select “everything this account ever contributed” — and we do not pretend otherwise.
  • We can erase every trace of a specific individual, on instruction, across every store including the shared corpus. The corpus is keyed by the HMAC of the address. Given the plaintext address, we recompute the same hash and delete that row — along with that person’s records, validations, score snapshots and outcomes, and any golden record or cluster derived from them. This is what a data subject’s right to erasure actually requires: the unit is a person, not an account.

Erasing an individual (data-subject erasure)

Under the GDPR the right to erasure belongs to a data subject — a person. When a contact asks your organisation to erase them, you instruct us to erase that one address, and we remove every trace of it:

  • Its records row and all derived enrichment.
  • Its validations rows, evidence and provenance.
  • Its score_snapshots and score_outcomes.
  • Its address_observations corpus row (recomputed from the address hash).
  • Any dedupe cluster membership and any golden record derived solely from it.

Do it from Settings → Data & privacy, or via POST /v1/erasure. Erasure is irreversible, so it requires an explicit confirmation — you retype the exact address — on both the dashboard and the API. Because it is per-address and low blast-radius, there is no grace period. It charges nothing.

You can only erase an address your own account has submitted. A request for any other address is refused with a clear reason. This is a deliberate safety control: without it, a tenant could degrade the shared corpus for everyone by erasing observations it never made.

Suppression is retained, on purpose

The suppression list (hard bounces, complaints, spamtraps and abuse) exists to stop anyone re-contacting an address that has already asked not to be, or that is a trap. Erasing a suppression entry would cause harm — the address would become sendable again, and someone could mail a person who previously complained. So suppression entries are retained through erasure, under a legitimate interest in preventing harm. What is retained is only a one-way hash of the address and a reason category (for example “complaint”) — never the plaintext address. This is a pseudonym, kept deliberately and narrowly, and it is the one thing an erasure does not remove.

Re-observation after erasure

Erasure removes what we hold today; it is not a permanent block. If the same address is submitted again later — by you or by another customer — it is validated and observed afresh, as new processing under a new instruction. We deliberately do not keep a permanent do-not-observe list: such a list would itself have to retain the pseudonym it was meant to remove. The one exception is the suppression list above — if an address is suppressed, a later submission is recognised as suppressed and not re-probed, which is the harm-prevention behaviour, not a re-created profile.

Accountability

Every erasure is recorded for accountability — a timestamp, the requesting account, and a count of rows removed from each store — without retaining the address or its hash. The record proves an erasure happened and how much it removed, while holding nothing that could re-identify the person.

How long we keep it

  • Tenant-scoped data — kept for as long as your account is active, and deleted on account deletion.
  • Billing and tax records — retained 7 years after closure under statutory obligation, detached from your account (the tenant link is removed) and kept only as financial records.
  • The pseudonymised corpus — retained indefinitely as non-attributable shared intelligence, minus any individual erased on instruction.
  • The suppression safety list — retained indefinitely (including through erasure) as pseudonymised harm-prevention data.

What you can do

  • Export everything your account owns, anytime — from Settings → Data & privacy, or via POST /v1/export. You get a single JSON archive with one section per entity; it never includes API-key material or password hashes. Large exports run as an async job served by the same signed webhook. It is free.
  • Erase one person — from Settings → Data & privacy, or via POST /v1/erasure, with a retyped-address confirmation. Free, irreversible, limited to addresses you have submitted.
  • Delete your account — from Settings → Data & privacy, or via DELETE /v1/account, which requires a second explicit confirmation parameter. Deletion is confirmed, not one click, and your API keys stop working immediately.

What account deletion removes and what survives

Deletion permanently removes every tenant-scoped row — records, validations, lists, jobs, dedupe clusters, golden records, score snapshots and outcomes, hygiene registrations, users, API keys, request logs, usage, and webhook endpoints and their delivery history — verified table by table.

These survive, each stated:

  • Billing and tax records — 7 years, statutory, detached from your account.
  • Aggregate non-identifying usage counters — carrying no personal data.
  • The cross-tenant corpus and suppression safety list — which carry no tenant attribution and cannot be tied back to you. To remove a specific person from the corpus, use per-address erasure above, which works regardless of whether your account is open.

A 30-day grace period applies to account deletion: your account is suspended but recoverable for 30 days after you request deletion; after that, deletion is irreversible. (Per-address erasure has no grace period — it is immediate.)

← All docs