NIS2 Domain Name Registration Data Verification Policy

Accuracy, verification and maintenance of domain name registration data under Article 28 of the NIS2 Directive

Issuing entity Fewmoretaps OÜ, a private limited company (osaühing) incorporated in Estonia, trading as Trustname.com.

• Estonian commercial registry code: 16354846
• Registered address: Roseni 13, 10111 Tallinn, Estonia
• Telephone: +372 6884747
• Contact for this policy: [email protected]

In this policy, "Fewmoretaps", "Trustname", "we", "us" and "our" mean Fewmoretaps OÜ trading as Trustname.com, an ICANN-accredited registrar of generic top-level domain (gTLD) names.

1. Purpose

This policy sets out how Fewmoretaps collects, verifies, maintains and publishes domain name registration data so that the data we hold is accurate and complete, and how we make the data available in accordance with applicable law. It implements the obligations in Article 28 of Directive (EU) 2022/2555 (the "NIS2 Directive") as transposed into Estonian law, and aligns those obligations with our contractual obligations to ICANN.

Maintaining accurate and complete registration data, and providing lawful access to it, contributes to the security, stability and resilience of the Domain Name System (DNS). This policy is made publicly available in satisfaction of Article 28(3) NIS2.

2. Scope

This policy applies to:

• all domain name registration services we provide as an ICANN-accredited registrar, for every gTLD we offer;
• all registrants and all points of contact administering a domain name registered through us;
• registrations made directly, through resellers, and through any privacy or proxy service we make available; and
• all of our personnel and contractors involved in the registration, verification, support, abuse-handling and disclosure functions.

Where a particular top-level domain registry imposes additional or stricter registration-data requirements, those additional requirements apply in addition to this policy.

3. Legal and regulatory basis

This policy gives effect to and is to be read together with:

• NIS2 Directive — Article 28 (Database of domain name registration data), as transposed into Estonian law by the Cybersecurity Act (Küberturvalisuse seadus), as amended (in force from 1 January 2026). The competent authority and national CSIRT is the Estonian Information System Authority (RIA / CERT-EE).
• Regulation (EU) 2016/679 (GDPR) and the Estonian Personal Data Protection Act (Isikuandmete kaitse seadus), which govern our processing of personal data and are supervised by the Estonian Data Protection Inspectorate (Andmekaitse Inspektsioon).
• The ICANN Registrar Accreditation Agreement (2013 RAA), including the WHOIS Accuracy Program Specification, and the ICANN Registration Data Policy (effective 21 August 2025), together with the gTLD Registration Data Access Protocol (RDAP) requirements (RDAP having replaced the WHOIS protocol for gTLDs from 28 January 2025), and applicable registry policies.

Where this policy refers to "applicable law", it includes all of the above.

4. Definitions

• Registration data — the data elements relating to a domain name registration listed in Section 5.
• Registrant (Registered Name Holder) — the natural or legal person in whose name a domain name is registered.
• Point of contact — a contact administering the domain name, where different from the registrant.
• Dedicated database — the access-controlled system of record in which we hold registration data (Section 6).
• Personal data — has the meaning given in the GDPR.
• Privacy/proxy service — a service that substitutes our (or a partner's) contact details for the registrant's details in publicly available registration data, while we continue to hold the underlying registrant data.
• Reseller — a third party that offers our registration services to its own customers under contract with us.
• RDDS / RDAP — Registration Data Directory Services, provided via the Registration Data Access Protocol.
• Legitimate access seeker — a natural or legal person making a lawful and duly substantiated request for access to specific registration data (for example, law-enforcement authorities, computer security incident response teams, holders of intellectual-property or other legal rights, and others recognised under applicable law).
• Verification — taking active steps to confirm that registration data is accurate and that the registrant/point of contact is reachable, as distinct from mere collection.
• Validation — checking that a data element is present and in the correct format.

5. Registration data we collect

For each domain name, we collect and maintain in our dedicated database at least the data required by Article 28(2) NIS2 and by the ICANN Registration Data Policy and RAA, namely:

We additionally collect the further registrant and technical data elements required under the ICANN Registration Data Policy and the RAA (including registrant postal address fields and name-server information). We apply data minimisation: we do not collect more personal data than is necessary for the purposes set out in this policy and our privacy notice. Consistent with the ICANN Registration Data Policy, we no longer maintain separate administrative-contact and billing-contact data sets for the purpose of registration-data publication.

6. Dedicated database, integrity and security

• Registration data is held in a dedicated, access-controlled database maintained by Fewmoretaps.
• Access is restricted on a least-privilege, role-based basis and logged.
• The database and the data within it are protected by the technical and organisational security measures described in our information-security framework (encryption in transit and at rest, monitoring, backup, and access controls).
• Registration data is retained for the periods required by the RAA, registry policies and applicable law, and is escrowed in accordance with the ICANN Registrar Data Escrow requirements.

7. Verification and validation procedures

This Section sets out the "policies and procedures, including verification procedures" required by Article 28(3) NIS2.

7.1 Format (syntactic) validation — at the point of registration

At or before registration, and on any change of data, we automatically validate that the required fields are present and correctly formatted, including:

• email addresses in valid format (RFC 5322);
• telephone numbers in valid international format (ITU-T E.164); and
• postal address fields (street, city, state/province, postal code, country) in the correct format for the relevant country or territory.

A registration or change that fails format validation is not accepted until corrected.

7.2 Affirmative verification of contactability

We take active steps to confirm that the registrant is reachable. For each new registration (and on a change of the registrant's email address or telephone number), we carry out affirmative verification of at least the registrant email address or telephone number — for example by sending a verification link or one-time code that the registrant must action within the required period. Verification status is recorded against the registration.

7.3 Cross-field and plausibility checks

Where feasible, we apply additional checks to detect data that is internally inconsistent or implausible (for example, a postal code that does not correspond to the stated country), and we may apply enhanced verification where risk indicators are present.

7.4 Timing

• Format validation and the initiation of affirmative verification take place at or immediately after registration.
• Where affirmative verification requires a registrant response, the registrant must respond within fifteen (15) calendar days.
• Re-verification is initiated promptly on the triggers in Section 8.

7.5 Consequences of failed, incomplete or unreliable verification

Where a registrant knowingly provides inaccurate or unreliable data, fails to correct data, or fails to respond within fifteen (15) calendar days to our inquiries about the accuracy of contact details, we will, in accordance with the RAA and applicable law:

1. send the required reminder(s) to the registrant; and, failing resolution,
2. suspend or cancel the domain name registration, or place it on clientHold and clientTransferProhibited, until the data has been validated or confirmed.

All such actions, and their reasons and timing, are recorded.

7.6 Privacy/proxy registrations and resellers

• Privacy/proxy services do not reduce the data we must hold or verify. Where a registrant uses a privacy or proxy service, we continue to collect, verify and maintain the accurate underlying registrant data; only the publicly available data is substituted. Use of a privacy or proxy service does not exempt a registrant from the accuracy and verification requirements of this policy, nor from lawful disclosure under Section 10.
• Resellers are contractually required to collect and pass to us accurate and complete registration data and to support the verification, accuracy-maintenance and disclosure processes in this policy. We remain responsible for compliance with Article 28 in respect of registrations made through resellers.

7.7 Evidence and logging

For each registration we record the verification and validation status, the method used, and relevant timestamps, so that compliance can be demonstrated to the competent authority (RIA), to ICANN, and on audit.

7.8 Risk-based manual review of high-risk registrations

Principle. The default registration path is automated and frictionless. Manual review is an exception, applied only to a narrow, defined set of high-risk registrations. We keep the proportion of registrations subject to manual review as low as is consistent with effective fraud and abuse management, and we tune the criteria below to minimise false positives so that legitimate customers — including privacy-conscious customers — are not unnecessarily burdened or delayed. Manual review supports the accuracy and verification objectives of this policy and our obligation to manage DNS abuse.

In this Section, manual review means escalation of a registration to a trained reviewer in our compliance/abuse function for additional, proportionate checking before the registration is finalised or allowed to resolve.

Status of these criteria — indicative and discretionary, save where required by law. The risk indicators, triggers, combinable factors and default thresholds set out in this Section 7.8 are internal, risk-based guidance. Fewmoretaps considers them sufficient for identifying high-risk registrations, but they are not binding commitments and create no obligation owed to, or any right enforceable by, any registrant, applicant or third party. We may, at our reasonable discretion, apply, decline to apply, add to, remove, combine or vary any of these criteria and thresholds, and may take other or additional measures appropriate to the risk. Nothing in this Section limits our discretion to accept, hold, refuse, suspend or cancel a registration in accordance with our registration agreement and applicable law.

This discretion does not extend to measures required by law or by binding obligation, which are mandatory and applied in all cases. These include, in particular: sanctions and restricted-party screening (trigger 5 below); and the data-accuracy, validation, affirmative-verification, publication, accuracy-maintenance and lawful-disclosure obligations set out elsewhere in this policy, which implement Article 28 of the NIS2 Directive, the Estonian Cybersecurity Act, the GDPR, and our ICANN Registrar Accreditation Agreement and applicable ICANN and registry policies. Where any criterion in this Section coincides with such a mandatory obligation, it is mandatory to that extent.

Standalone triggers. A registration is routed to manual review where any one of the following is present:

1. Payment in a privacy / anonymity-enhancing cryptocurrency (for example Zcash shielded transactions, Monero, or Dash PrivateSend) where the payment trail cannot reasonably be traced.
2. A Stripe Radar risk score above 60 on a card payment. (Configurable: this threshold may be aligned with Stripe Radar's "Elevated" and "Highest" risk levels, and should be set to capture genuinely elevated-risk payments without sweeping in normal ones.)
3. More than 10 declined card transactions associated with the same card, customer, account or device within any 24-hour period (card-testing indicator).
4. Seven (7) or more distinct payment cards used by the same account, customer or device within a 24-hour period (card cycling / stolen-card indicator).
5. A sanctions or restricted-party screening match on the registrant (name or jurisdiction), or a registrant located in a sanctioned jurisdiction.
6. A prior chargeback, confirmed payment fraud, or verified abuse linked to the customer, registrant email, card fingerprint, or cryptocurrency address (internal denylist match).
7. Bulk registration of a large number of domain names (default: ≥ 50 in a single order or rolling 24-hour window) by an account that is newly created (default: < 30 days old) or that has not completed affirmative verification under Section 7.2 (automated-abuse-infrastructure indicator). This provision does not apply to approved reseller accounts.

Combinable factors. The following do not trigger review on their own, but route a registration to manual review when two (2) or more are present together:

• failure to complete affirmative email/telephone verification (Section 7.2) within the required period;
• use of a disposable or temporary email provider for the registrant email;
• registrant data that fails the plausibility / cross-field checks in Section 7.3;
• an unusually high-value or high-volume first order from a brand-new account;
• mutually inconsistent registrant, billing and technical details that are not explained by lawful privacy tools.

Not, by themselves, grounds for review. To avoid burdening legitimate and privacy-conscious customers, none of the following is treated as a risk indicator on its own: use of a VPN, proxy or Tor; use of our privacy/proxy service or masked public registration data; payment in a mainstream, traceable cryptocurrency in an ordinary amount; or an IP geolocation that differs from the billing or registrant country.

Conduct of the review. A trained reviewer assesses the registration and may, proportionately and requesting only the minimum information necessary: re-confirm the registrant's email or telephone; for a legal person, confirm publicly verifiable registration details; place the domain on a short hold pending the outcome; and then approve, request limited further verification, or decline and refund (and, where legally required, report). Reviews are completed promptly and without undue delay, consistent with Article 28 and with a good customer experience.

Proportionality, tuning and logging. The criteria, thresholds and default values above are reviewed at least quarterly and adjusted on the basis of false-positive and true-positive rates, with the explicit aim of keeping the manually reviewed population to the minimum necessary. Each manual review is logged (trigger, decision, reviewer, timestamp) for audit by the Cybersecurity Officer, RIA and ICANN.

8. Maintaining accuracy over the registration lifecycle

• Registrant obligations. Our registration agreement requires every registrant to provide accurate and reliable contact details and to correct and update them within seven (7) days of any change, and to respond within fifteen (15) days to any inquiry from us about accuracy. These obligations are a condition of registration.
• Reminders. We send registrants periodic reminders to review and confirm their contact data.
• Re-verification triggers. We re-verify and, where required, re-validate the relevant data elements when: an accuracy complaint is received (including from ICANN Contractual Compliance, a registry, or RIA); communications to the registrant bounce or are returned undeliverable; the registrant data is changed; or other indicators of inaccuracy arise.
• Investigation and correction. On a substantiated indication of inaccuracy, we investigate, require correction, and apply the consequences in Section 7.5 where the registrant does not comply.

9. Publication of non-personal registration data (Article 28(4))

We make publicly available, without undue delay after registration, the domain name registration data that is not personal data, via our Registration Data Directory Services (RDAP, and WHOIS where still required for a given TLD).

• Data relating to legal persons that does not constitute personal data is published.
• Personal data is redacted from the public record in accordance with the GDPR and the ICANN Registration Data Policy; where a data element (such as the Registrant Organization field) may be published only with consent, we publish it only where the required consent has been given.
• Public data is published in the standardised RDAP format in accordance with the gTLD RDAP Profile.

10. Access by legitimate access seekers — lawful disclosure (Article 28(5))

We provide access to specific domain name registration data, including data that is not published, upon lawful and duly substantiated requests by legitimate access seekers, in accordance with the GDPR.

• We acknowledge and reply to every such request without undue delay and in any event within seventy-two (72) hours of receipt; urgent requests are handled on the expedited basis required by applicable ICANN policy.
• Each request is assessed for lawfulness, substantiation and proportionality, and a GDPR balancing assessment is carried out before any personal data is disclosed. Requests that are unlawful, unsubstantiated or excessive are refused, with reasons.
• Requests and decisions are logged.

The detailed procedure for submitting and handling such requests — including how to submit a request, the information a request must contain, and the criteria we apply — is set out in our companion Domain Name Registration Data Disclosure Policy, which is also made publicly available in accordance with Article 28(5). Requests may be submitted to [email protected].

11. Avoidance of duplication and cooperation with registries (Article 28(6))

To avoid duplicating the collection of registration data, we cooperate with the relevant TLD name registries (for example through thick-registry data transfer, data escrow, and registry–registrar coordination) so that registration data is collected and maintained efficiently and consistently across the registration chain.

12. Data protection (GDPR)

• Our processing of personal data in registration data is carried out in accordance with the GDPR and the Estonian Personal Data Protection Act, and is described in our privacy notice.
• We process registration data on the lawful bases applicable to each purpose (including compliance with a legal obligation, performance of the registration contract, and legitimate interests in DNS security and stability), and we apply data minimisation, purpose limitation, storage limitation and security.
• Data subjects may exercise their rights as described in our GDPR privacy notice. Disclosure to legitimate access seekers under Section 10 is subject to the GDPR balancing described there.

13. Roles and responsibilities

• Cybersecurity Officer (Kiryl Nestsiarovich) — owner of this policy; responsible for its implementation, maintenance, review, and for liaison with RIA on Article 28 matters.
• Registration / support team — applies validation and verification at registration, handles reminders, accuracy investigations and lifecycle maintenance.
• Abuse / legal function — assesses and answers lawful-disclosure requests within the 72-hour deadline and maintains the disclosure log.
• Resellers and privacy/proxy partners — bound by contract to the standards in this policy.
• Management Board — approves this policy and oversees compliance.

14. Records, retention and audit

• We maintain records of verification and validation status, accuracy investigations, suspensions/cancellations, published data, and disclosure requests and decisions.
• Records are retained for the periods required by the RAA, registry policies and applicable law.
• This policy and its operation are subject to internal review and to inspection/audit by RIA and by ICANN Contractual Compliance; records are made available to them on request within applicable timeframes.

15. Non-compliance and enforcement

Failure by a registrant to meet the accuracy, update or response obligations may result in suspension or cancellation of the registration as set out in Section 7.5. Failure by our personnel or resellers to follow this policy is addressed through our internal disciplinary and contract-management processes. Breaches of Article 28 may expose Fewmoretaps to supervisory action and penalties under the Estonian Cybersecurity Act and to ICANN compliance action.

16. Review and governance

This policy is reviewed at least annually and whenever there is a material change in applicable law (including NIS2 transposition measures, ICANN policy, or GDPR), in our services, or following a relevant incident. Material changes are approved by the Management Board, version-controlled, and re-published.

17. Public availability and contact

This policy is published on the Trustname.com website so as to be directly and permanently accessible, in satisfaction of Article 28(3) NIS2.

Questions about this policy, and lawful-disclosure requests, may be directed to: Fewmoretaps OÜ (d/b/a Trustname.com) — [email protected]— Roseni 13, 10111 Tallinn, Estonia — +372 6884747.

Annex A — Data element validation and verification matrix

Validation = correct presence and format. Verification = active confirmation of accuracy / contactability. Affirmative verification of at least the registrant email or telephone is carried out at registration and on change.

Annex B — Document history