How we protect your data and keep the Verifyd service safe.
#
Security & Data Handling Statement
Verifyd. Instant Clarity. Complete Control.
Effective date 27 June 2026
Version 1.0
Last updated 27 June 2026
This document is a public-facing summary of how Verifyd handles
information and operates securely. It is intended for users,
prospective B2B partners, and security-conscious reviewers. It
accompanies, and does not replace, our
Privacy Policy
and
Terms & Conditions.
Overview
Verifyd is a consumer-facing mobile application that helps people in
South Africa identify scam messages. Because users may submit content
during moments of anxiety, and because that content can incidentally
contain personal information, security and data handling are central
design concerns, not afterthoughts.
This Statement summarises:
The Statement reflects production state as of the effective date above.
Where the architecture is planned to evolve, those changes are described
in Section 10 (Forward Roadmap)
and will move into the body of this Statement when implemented.
Data Handling Architecture
Verifyd processes user-submitted content along two distinct paths with
different data-handling contracts.
Verifyd does not require user accounts. There is no registration, no
login, and no identifying information requested from users at any point.
A typical validation request carries only the message content the user
pastes in, plus standard network metadata (IP address handled per
Section 4.2).
When a user submits a message for verification through the application:
-
A SHA-256 hash of the body is computed and stored in the
validation_log table, alongside structured check metadata
describing how the verdict was reached.
-
Identifying details that appear in the check metadata (account
numbers, card numbers, identity numbers, phone numbers, names, etc.)
are redacted before persistence, see
Section 3.
-
Validation records are anonymised after 24 months by an automated
retention process: the check-detail content is stripped in place and
only a hashed, non-personal skeleton (hash, verdict, timestamps) is
retained. Records are anonymised, not deleted.
The hash enables duplicate-message detection and abuse prevention
without preserving the original content.
When a user explicitly chooses to submit a message as a scam report
through the "Report this scam" flow, the user is making a deliberate
choice to share that content with Verifyd for community moderation
and corpus building.
In this case, and only in this case, the full message text is
retained in the scam_reports table. Reports are subject to
manual review for moderation purposes. Reported-scam content is
anonymised after 24 months by an automated retention process: the
stored message, sender, and reporter identifiers are overwritten in
place, while an anonymised record (category, status, and curator
review outcome, with no personal content) is retained for audit.
This is the only path in Verifyd where readable user-submitted
content is stored. Users opt in to this path knowingly, with
the disclosure surfaced in onboarding and in the app's submission flow.
QR codes are decoded entirely on the user's device using the native
camera module. Camera frames and unprocessed images never leave the
device. Only the resolved URL is transmitted to Verifyd's servers for
analysis.
PII Redaction
Before sending any user-submitted content to our third-party AI
classifier, and before persisting check metadata to our
validation_log database, Verifyd applies pattern-based
redaction to remove identifying details.
The following patterns are redacted with placeholder tokens:
Pattern Placeholder Notes
Email addresses [EMAIL] Standard email format
Phone numbers [PHONE] International (+27…) and South African local (08X…) formats
South African ID numbers [ID_NUMBER] 13-digit pattern
Rand amounts R[AMOUNT] E.g., R50.00, R 1,234.50
Card numbers [CARD] Luhn-validated, 13, 19 digits, supports space/dash separators
Bank account numbers [ACCOUNT] 9, 12 digit sequences
Courier tracking / reference codes [TRACKING] 8, 12 character alphanumeric with mixed letters and digits
Likely personal names [NAME] Capitalised word groups
Verifyd's redaction is deliberately conservative. The internal design
principle states:
False positives don't impair the LLM's ability to detect scam
patterns. False negatives (a real ID number escaping) are a
privacy violation.
In practice this means:
-
Some reference numbers may be redacted as [ACCOUNT] or
[TRACKING]
We accept these false positives because the AI classifier can still
detect scam patterns from message structure (urgency keywords, format
anomalies, sender characteristics) without needing the specific values.
The cost of over-redaction is reduced classifier context. The cost of
under-redaction is leaked PII to a third-party operator. We choose
privacy.
URLs are not redacted. They are preserved through both the AI
classification path and the persistence path because URLs are
load-bearing signals for scam detection. A phishing link is itself
the primary evidence of intent; redacting it would eliminate the
strongest classification signal.
URLs in user-submitted content are subject to Google Safe Browsing
lookup and domain comparison against our institution whitelist.
PII redaction applies at two boundaries:
User-submitted body, subject, and sender fields are stripped of patterns
above before any external API call.
The structured check metadata is stripped of patterns above before being
written to the database. A short body preview that previously appeared in
this metadata has been removed; URLs are preserved per section 3.3.
PII redaction does not apply to:
-
The response returned to the user (users see their own original
message text in the verdict screen. This is for their reference and
never leaves their client).
-
The scam_reports table when users explicitly submit a
scam report (see
Section 2.3).
The redaction module is covered by automated tests including
per-pattern positive cases, negative cases (close-but-not-matching
inputs), pattern ordering invariants, idempotency, and composite
realistic scam SMS containing all patterns simultaneously. The full
backend test suite must pass before any production deployment.
Technical Controls
All client, server traffic uses HTTPS with modern TLS configuration.
Verifyd's production API at api.verifyd.co.za is served
with a dual RSA + ECDSA certificate issued by Let's Encrypt, with
automatic renewal. TLS 1.2 minimum, TLS 1.3 preferred.
Verifyd operates behind a load balancer that forwards client IP
information via standard HTTP headers. The backend trusts these
forwarded headers and uses the real client IP (not the load balancer's
IP) for:
Client IPs are not stored in raw form. Where IP-derived data is
persisted (specifically for scam_reports submissions, to
deter spam), the IP is hashed with SHA-256 using a server-side secret
salt. The salt is stored in our encrypted secrets vault. Even a
database snapshot would not enable enumeration of original IPs.
The Supabase managed PostgreSQL database that backs Verifyd uses
encryption at rest as standard. Database backups are managed by
Supabase with point-in-time recovery enabled.
Application secrets (API keys, database service-role credentials, IP
hashing salt) are stored in:
are injected as environment variables into the running application
container. Values never appear in source code, deployment
configuration, version control, or any log output.
(operator-controlled) holds a recovery copy of all production secrets.
Secret rotation policy: secrets are rotated when a
compromise is suspected, when team composition changes, or as part of
scheduled hygiene reviews.
-
Per-IP and per-session rate limits are applied to the
report submission endpoint to prevent submission flooding.
-
The AI classifier is invoked only after deterministic checks have
run, controlling third-party API costs and reducing the volume of
content sent to external operators.
-
Logs of API responses do not contain raw message bodies or
unredacted personal information.
Operational logs record events sufficient to investigate incidents
(timestamps, endpoint paths, response codes, hashed identifiers, error
categories). They do not contain:
Logs are retained for up to 7 days (our hosting platform's
default log-retention window) unless required for an active
investigation.
Infrastructure & Operators
Verifyd uses the following operators. Each is bound by their own
published terms and, where applicable, contractual obligations to
process information only for the purposes we specify.
Operator Role Relevant protections
Fly.io
Application hosting platform. Runs the FastAPI backend
container in the Johannesburg region.
HTTPS by default; encrypted secrets vault; isolated VM
execution. Privacy policy at fly.io.
Supabase
Managed PostgreSQL database (eu-west-2 London region). Stores
hashed validation logs, institution whitelist, and scam reports.
Encryption at rest; point-in-time recovery; row-level security;
POPIA-compatible data handling.
Anthropic
Provides the Claude API used for content classification. Only
PII-redacted content is sent (see
Section 3).
Under Anthropic's Commercial Terms, API inputs and outputs are
not used to train Anthropic's models. API logs are retained for
30 days.
Google Safe Browsing
URL safety lookup API. Only URLs from user-submitted messages
are sent. No message body content.
Standard Google API terms; URL lookups are checks against known
malicious URL databases.
WHOIS providers
Domain registration data lookup. Only domain names from
extracted URLs are queried. No submitted message content is
shared.
Standard public registry data.
We do not transfer any user-submitted content to operators not listed
in this table.
Operational Practices
-
Source code is held in version control (Git) with commit messages
describing each change.
-
Dependencies are pinned to specific versions and reviewed against
published vulnerability advisories.
-
Security-relevant changes are tested through automated test suites
before deployment.
-
The full backend test suite (currently 687 tests) must pass before
any production deployment.
Production deployments follow a documented process:
-
Post-deployment health checks verify the new version is serving
traffic correctly.
-
Rollback to the previous known-good version is available at any time.
Database schema migrations are applied manually via the Supabase
administrative interface, after verification in a separate development
database. This deliberate-by-hand approach is preferred at current
scale because it prevents accidental destructive operations.
-
Database backups are managed by Supabase with point-in-time recovery
enabled.
-
Application configuration (secrets, environment) is backed up in a
separate operator-controlled vault.
-
New operators are reviewed for security posture and POPIA
compatibility before integration.
-
Existing operator relationships are reviewed when material changes
occur (e.g., terms updates, security incidents at the operator).
Incident Response
If we become aware of a security incident affecting personal
information, we will:
-
Notify the Information Regulator and affected data subjects in
accordance with section 22 of POPIA.
Responsible Disclosure
If you believe you have found a security vulnerability in Verifyd, we
ask that you report it responsibly to
before disclosing it publicly. We commit to:
-
Not taking legal action against good-faith researchers who follow
this process.
Please include:
-
Any supporting evidence (screenshots, request/response captures).
POPIA Alignment
Verifyd has been designed to align with the eight conditions for lawful
processing under POPIA:
Condition How Verifyd applies it
Accountability
Information Officer appointed
Privacy Policy and this Security & Data Handling Statement
are publicly available.
Processing limitation
Anonymous use by default. Minimal collection (only the message
content the user explicitly submits). Lawful basis for processing
documented in Section 5 of the Privacy Policy.
Purpose specification
Clear purposes documented in the Privacy Policy. Retention is
enforced by an automated process running in production:
validation records and reported-scam content are anonymised
after 24 months. Personal and plaintext content is overwritten
in place while a non-personal, anonymised skeleton (hashes,
verdict metadata, and curator audit fields) is retained.
Operational logs are retained for up to 7 days.
Further processing limitation
Aggregated and anonymised data is used only for service
improvement (e.g., refining detection patterns, identifying
false positives).
Information quality
Hash-based deduplication for validation logs. Users may flag
inaccurate verdicts through in-app feedback.
Openness
This Statement and the Privacy Policy are publicly accessible.
Information Officer contact is published.
Security safeguards
The controls described in this Statement
(Sections 3,
4,
6).
Data subject participation
User rights are set out in Section 9 of the
Privacy Policy,
with a channel provided to exercise them.
Forward Roadmap
The following changes to Verifyd's data-handling architecture are
planned but not yet implemented as of the effective date. They will
be reflected in updated versions of this Statement when shipped.
Verifyd plans to use the volume and recency of community-submitted scam
reports as a weighted signal in verdict scoring. The signal will be
combined with content analysis, institution matching, and AI
classification, never as an automatic override.
The signal will deliberately avoid the static-label architecture used
by some incumbent systems (where a phone number labelled as "fraud"
retains that label even after the number is recycled by the telco to a
legitimate user). Verdict will remain about the specific message,
informed by data about the identifier, not the other way around.
Verifyd plans to add two additional check types alongside the existing
four (SMS, email, WhatsApp, QR). These will allow users to check a URL
or phone number directly without an accompanying message body. The
verdict shape for these checks will reflect the sparser signal data
honestly, surfacing what is known and what is not.
Verifyd is anonymous by design at v1.0. We may introduce optional user
accounts in a future version to enable features that require persistent
identity, for example validation history that syncs across a user's
devices, or community participation that benefits from reputation
tracking.
If user accounts are introduced, this Statement will be substantially
revised to describe how account information is collected, stored,
secured, and made subject to data subject rights. Until that revision
is published, no user account information is collected. Anonymous use
remains the only mode of interaction with Verifyd.
What This Statement Does Not Cover
This Statement describes our security practices but is not a guarantee
of perfect security or perfect detection. Specifically:
-
Verifyd does not guarantee that any given verdict is correct. See
Section 3 of our
Terms & Conditions
("No Reliance; User Responsibility").
-
Third-party operators are subject to their own security practices
and controls.
-
Users remain responsible for the security of their own devices,
networks, and accounts.
This Statement is reviewed and updated when material changes occur in
our architecture, operations, or operator relationships.
Contact
Questions about this Statement, our security practices, or
vulnerability reports:
(see Privacy Policy
for full data subject rights process)
Verifyd Technologies (Pty) Ltd · Cape Town, South Africa