Identity, Authority and Domain Verification Policy

DRAFT v1.0 | applies to Sellers AND Buyers

Why verification is necessary

GTLD, operated by ZAGRAN LTD (Company No. 16334360), verifies users and domain-control claims to reduce domain hijacking, impersonation, payment fraud, money laundering risks, legal disputes and sanctions exposure. Verification is risk-based; a successful check does not guarantee title, the absence of a trademark dispute, creditworthiness or regulatory compliance. GTLD does not claim to be a bank or regulated identity-certification authority.

Buyer and seller identity levels

All accounts: verified ownership of email address via expiring one-time link; legal name (individual or organisation), declared residence/incorporation country, contact address, account password/magic-link security and acceptance of the current Terms. Buyer and seller both must verify the email; unverified accounts cannot place binding orders or list saleable domains.

All parties to a binding purchase or sale: identity verification appropriate to risk, legal name matching payment or payout instruments, evidence of corporate authority for representatives and sanctions screening where appropriate. Identity check must either use an approved specialist provider with lawful data processing and secure hosted upload, or a human-managed verified process with tightly controlled access. A "Verified" badge must differentiate `email verified`, `identity verified`, `company authority verified` and `domain control verified`. Never treat a passed DNS test as personal ID verification.

Company accounts: registered legal name, jurisdiction, company number/local equivalent, registered business address, director/authorised representative identity, attestation of signatory authority; request board authorisation/power of attorney for atypical representatives. Onboarding must not confuse a business name with a company's verified legal identity. Corporate beneficial ownership is requested only where justified by provider/risk/legal requirements; never assert universal mandatory UK MLR-regulated KYC just because the platform is a marketplace.

Risk-based enhanced checks: mismatch of names, high-value sales, newly registered or recently transferred domains, high-risk geographies, unusual currencies, hurried transfer, recent WHOIS registrant/NS changes, adverse IP reports, sanctions match, chargeback pattern, price vastly above/below comparison, third-party beneficiary account, trademark disputes. Review with a human, document reason and outcome, ensure appeals/corrections.

Age: contract users must be 18+; where verification raises doubt ask for appropriate evidence in a privacy-preserving manner. Sanctions: no business with designated parties or prohibited jurisdictions/activities, subject to current UK measures and international rules applicable to a transaction. Do not automatically impose nationality discrimination; apply actual legal restrictions.

Domain name authenticity: DNS challenge

1. Canonicalise each domain (IDNA2008/UTS46 policy declared, lowercase ASCII IDNA/Punycode, correct registrable boundary/public suffix list, prevent invalid Unicode/confusable hostnames, test gTLD/ccTLD). Record both user-friendly Unicode and canonical ASCII, including safety warning where they differ.

2. Generate at least 128 bits of cryptographically secure random token, one challenge for one seller/domain/version, expiry 72 hours. Never use a static global shared challenge. Example DNS method TXT: `_gtld-verify.example.com` with exact value `gtld-verify=<unique-token>`; optional CNAME challenge `_gtld-verify.example.com` -> `v-<token>.verify.gtld.name.` when configured. Explain normal DNS propagation; never tell a seller to change NS records solely to verify.

3. Perform server-side real DNS lookup with expected FQDN and value. Validate exact token and domain, reject any response copied from other zone, rate-limit endpoints, prevent arbitrary HTTP requests, log outcome only with masked token. Expire and invalidate previous challenges when regenerated. Handle DNS failures, no answer, authoritative timeouts and retry limits with clear statuses.

4. Require human/automated additional checks where possible: RDAP registrar, record source and age, registrant-controlled proof (privacy redacted), registry lock, trademark dispute indicator, transfer lock, expiry, renewal conditions. DNS control alone is never conclusive legal ownership. If a registrant is a different entity from signing Seller, request enforceable evidence of signing rights from registrant.

5. On successful check, set `domain_control_verified_at` and bind evidence to a specific seller, listing ID, challenge ID and current domain/record snapshot. Domain enters `pending_admin_review`. Publication requires BOTH verified Seller identity (as determined by go-live policy) AND domain-control verification AND Seller signed mandate AND human approval. Revoked domain control, expired domain, ownership change, payment dispute or suspect changes suspend new orders automatically pending review.

6. Re-check at least every 30 days while listed, immediately before payment acceptance and again before transfer initiation when feasible. Use verified registrar owner/transfer checkpoint before irrevocable payout. Provide manual evidence pathway for DNS providers that prohibit changing verification records, but manual review must be two-person approved and evidence-backed; never bypass both legal ownership and identity checks.

Disclosure to users

We collect and verify identification and domain records solely for legitimate transaction, fraud, security and applicable legal purposes. We disclose personal data only to necessary parties/payment and identity partners, authorised staff or as required by law, following the Privacy Notice. You may request correction or challenge a negative verification decision. Submission of documents is not public and is never required via ordinary email where secure upload is available.

Outcomes and appeal

Possible identity statuses: `not_started`, `pending_email`, `pending_provider`, `manual_review`, `verified`, `failed`, `expired`, `revoked`, `sanctions_blocked`. Domain statuses: `challenge_issued`, `dns_pending`, `dns_verified`, `title_review`, `verified_for_listing`, `reverification_due`, `suspended`, `failed`, `expired`. Declines have coded, reviewable internal reasons; only non-sensitive summaries are shown publicly. High-impact decisions are reviewed by a human where legally required. No payment or release to an unverified/sanctions-flagged party. Contact admin@gtld.name for appeal.

Retention: raw identity documents ideally remain solely with the contracted identity provider; collect minimal result/verification ID, and delete manually submitted files promptly according to approved retention schedule. Do not use facial biometrics without documented necessity, special-category data condition where applicable, DPIA and processor safeguards. The final Privacy Notice must reflect actual provider and schedule, not hypothetical ones.