Financial and Technical Evaluation Criteria

## The Two Most Scrutinised Evaluation Dimensions Of the multiple evaluation dimensions that ICANN applies to new gTLD (Generic Top-Level Domain) applications, financial and technical evaluations are the two where applicants most commonly fail — or, if they pass, where the quality of their responses most directly predicts long-term registry success. This guide explains precisely what ICANN's independent evaluators look for, how scoring works, and what distinguishes excellent responses from merely adequate ones. Use the Domain Cost Calculator tool to model whether your financial projections meet the threshold requirements before submission. ## Financial Evaluation: What ICANN Is Looking For The financial evaluation is conducted by an independent panel of financial analysts contracted by ICANN. Their job is to assess whether the applicant has the financial resources to build and sustain a TLD (Top-Level Domain) registry for at least three years — without needing to rely on registration fee revenue to survive. ### The Core Question Can this applicant fund the registry through three years of operations even if zero registrations are sold? This is a conservative, worst-case test. ICANN does not assume that your business plan will succeed. It wants to know whether the internet will be disrupted if it does not. ### Financial Evidence Required **1. Historical Financial Statements (2–3 years)** - Audited by a recognised accounting firm using GAAP, IFRS, or equivalent standards. - If the applicant was incorporated specifically for this application (common for brand TLD applicants), parent company or investor financial statements substitute. - Must demonstrate existing assets sufficient to fund the application fee plus operating costs. **2. Three-Year Financial Projections** - Income statement, balance sheet, and cash flow statement for Years 1–3 post-delegation. - Detailed assumptions disclosed: projected registration volume, pricing, registrar distribution, operating expense build-out. - Sensitivity analysis: what happens to cash flow if registrations are 50% of projections? **3. Capital Evidence** - Bank statements or confirmation letters showing accessible liquidity. - Investor commitment letters (if relying on external capital). - Parent company guarantee or letter of support (if relying on parent backing). **4. Financial Evaluation Questionnaire** ICANN's questionnaire asks applicants to quantify: - Total capital available (above the application fee) - Projected monthly burn rate in Year 1 - Months of runway at zero registrations - Break-even registration volume and timeline ### Scoring and Pass/Fail The financial evaluation is largely pass/fail, not scored. An application either demonstrates adequate financial capacity or it does not. Specific thresholds are defined in the Applicant Guidebook and include: - **Minimum capital**: Sufficient to fund the application plus three full years of projected operations. For a lean registry, this is typically $750,000–$1,200,000 above the application fee. - **Audited statements**: Failure to provide properly audited statements is a basis for rejection. - **Projection quality**: Projections that are internally inconsistent, based on unsubstantiated assumptions, or that simply copy ICANN template numbers without applicant-specific justification fail the quality test. ### Common Financial Evaluation Failures - **Underestimating operating costs**: Many applicants in 2012 projected costs below realistic market rates for back-end registry services. Evaluators compare projections against known market benchmarks. - **Relying on uncommitted capital**: Letters of intent from investors that do not constitute binding commitments are insufficient. - **Missing audited statements**: Unaudited financials — even if accurate — do not satisfy the requirement. - **Projecting unrealistic registration volume**: Projecting 500,000 registrations in Year 1 for a niche sTLD (Sponsored Top-Level Domain) raises red flags with evaluators. ## Technical Evaluation: What ICANN Is Looking For The technical evaluation is conducted by a separate panel of DNS and internet security experts. Their assessment covers five primary areas. ### Area 1: DNS Technical Operations | Criterion | Minimum Standard | |-----------|----------------| | Authoritative name server count | Minimum 2 servers in geographically distinct locations | | Name server availability | 99.9% uptime over any 30-day period | | Round-trip query time | ≤150ms from any point of measurement | | Failover capability | Demonstrated automatic failover with no manual intervention required | Applicants using major back-end registry operators (GoDaddy Registry, CentralNic, Identity Digital) automatically inherit infrastructure that exceeds these minimums. Independent applicants must document their infrastructure explicitly. ### Area 2: DNSSEC Implementation DNSSEC is mandatory for all new gTLDs delegated under the 2026 round. The technical evaluation assesses: - **Key management**: How are Zone Signing Keys (ZSK) and Key Signing Keys (KSK) generated, stored, and rotated? HSM (Hardware Security Module) use is required for KSK. - **Signing frequency**: Zone signing schedule and TTL settings. - **Key rollover procedures**: Both routine and emergency rollover scenarios must be documented. - **Chain of trust**: The registry must maintain the DS record in the DNS Root Zone and coordinate with IANA for KSK rollovers. Applicants that cannot demonstrate DNSSEC competency — either through their own team or their contracted back-end operator — will fail the technical evaluation. ### Area 3: Registration Data Access (RDAP/WHOIS) ICANN requires all gTLD registries to operate a Registration Data Access Protocol (RDAP) service providing: - Accurate, timely registration data (WHOIS) accessible to authorised parties. - Compliance with ICANN's Registration Data Policy (adopted in 2023 to align with GDPR and similar regulations). - 99.9% RDAP service availability. The technical evaluation assesses RDAP implementation plans, data accuracy procedures, and privacy compliance mechanisms. ### Area 4: Registry-Registrar Protocol (EPP) All registrars that sell domains in the new TLD (Top-Level Domain) connect to the registry through EPP (Extensible Provisioning Protocol). The technical evaluation requires: - Compliant EPP server implementation (RFC 5730 and associated RFCs). - Support for required EPP extensions (domain create, update, delete, transfer, renew). - EPP server availability of 99.9% or better. - Load capacity documentation: how many simultaneous EPP connections can the server handle? ### Area 5: Security and Abuse Management This is the fastest-growing area of technical evaluation, reflecting the internet community's increasing concern about DNS (Domain Name System) abuse: **Abuse Prevention Infrastructure:** - DNSBL (DNS Blacklist) monitoring for phishing and malware domains. - Documented abuse reporting procedures (email, web form, or both). - Response time commitments for abuse reports. - Anti-spam measures for domain registration flow. **DDoS Mitigation:** - Anycast DNS deployment (which inherently provides DDoS resilience) or equivalent. - Documented DDoS attack detection and mitigation procedures. - Evidence of DDoS mitigation provider contracts if relying on third parties. **Security Incident Response:** - A documented security incident response plan. - Contact information and escalation procedures. - Commitment to ICANN security incident reporting requirements. ### Technical Evaluation Scoring Unlike the financial evaluation, technical evaluation uses a scored approach in some areas. Applications are scored on a 0–2 or 0–3 scale for each technical criterion, and scores are aggregated. Applications below a minimum threshold in any critical area fail; those above the threshold pass. Applications from applicants using well-established back-end operators — whose infrastructure is already known to ICANN from prior contracts — benefit from a "known quantity" advantage in technical evaluation. ## Coordinating Financial and Technical Responses A critical mistake some applicants make is allowing their financial team to write the financial section and their technical team to write the technical section in isolation. The two sections must be consistent: - The financial projections must include realistic costs for the technical infrastructure described in the technical section. - The technical plan must describe infrastructure that the financial projections can actually fund. - If the technical plan relies on a specific back-end operator, the financial projections must include that operator's fees. Inconsistencies between sections are a red flag for evaluators and can trigger extended evaluation or rejection. See How to Apply for a New gTLD in 2026 for guidance on coordinating the full application, and Post-Delegation: Running a TLD Registry for the technical and financial realities of post-delegation registry operations. ## Working With Evaluators: What the Process Feels Like The financial and technical evaluations are not adversarial — they are investigative. Evaluators are trying to determine whether the applicant can actually do what they say they will do, not trying to find reasons to reject. Understanding this changes how applicants should approach the process. **Be specific**: Vague commitments ("we will implement strong security measures") score lower than specific ones ("we will deploy DDoS mitigation via Cloudflare Magic Transit with a 10 Gbps scrubbing capacity, backed by a contractual SLA with a 5-minute mitigation response time"). **Cite your back-end operator's credentials**: If your back-end registry operator has operated TLDs for ten years without a major security incident, say so. Evaluators weight the track record of the infrastructure provider, not just the applicant's plans. **Address weaknesses proactively**: If your financial history is short (newly incorporated applicant), address it head-on by providing investor commitment letters, parent company guarantees, and detailed explanations of the funding structure. Hoping evaluators won't notice a gap rarely works — they are experienced and thorough. **Respond promptly to supplemental requests**: If evaluators request additional information, respond within the window provided. Late responses create administrative delays that compound throughout the evaluation process. ## The Extended Evaluation Safety Net Applications that receive a "fail" determination on a single non-critical criterion may be placed in Extended Evaluation rather than rejected outright. Extended Evaluation gives the applicant an opportunity to provide additional evidence or make commitments that cure the deficiency. Extended Evaluation adds time and cost — typically two to four additional months and $15,000–$50,000 in consultant and legal fees to prepare supplemental submissions — but it is preferable to outright rejection. Not all failures are curable through Extended Evaluation. Applications that lack fundamental eligibility — an unincorporated applicant, for instance, or one with a disqualifying prior ICANN history — are rejected without Extended Evaluation opportunity. This underscores the importance of confirming eligibility before paying the application fee. See Who Can Apply for a New TLD? Eligibility Requirements for the full eligibility analysis.