Application Details
Last published on: 7 October 2026 at 15:38 UTC
Application Responses
Section: Applying Entity Information
This question set collects information regarding the legal entity that would enter into a Registry Agreement with ICANN upon successful completion of all relevant application processes. The information collected is intended to be used for background screening.
Provide the full legal name of the applying entity as it appears on the official registration documents. Do not use abbreviations.
European Central Bank
Provide the name under which the applying entity is doing business, if different from the full legal name answered in Question 1. Such a name must be registered with appropriate local jurisdiction or public authority.
Not Applicable
Provide the long form (no acronyms) of the legal entity form/business structure of the applying entity as it appears on the official registration documents. If the original script of the legal entity form/business structure is not English, ONLY provide its official English translation. No additional information should be provided as this will be used for the automatic population of the Registry Agreement.
Institution of the European Union
The jurisdiction indicates the location in which the business of the applying entity is registered for legal and financial purposes. This is either 1) a country name, or a 2) state/territory name, depending on where the applying entity is registered. No additional information should be provided as this will be used for the automatic population of the Base Registry Agreement. Examples include "Delaware", "Germany", etc.
Germany
Provide the website URL of the applying entity, if available.
https://www.ecb.europa.eu/
1. Choose Yes or No. 2. Use the definition of Affiliate from the Base Registry Agreement (see https://www.icann.org/en/registry-agreements/base-agreement).
false
Choose Yes or No.
false
49
Provide the primary business phone number without including the country code.
69 13 44 0
Provide the primary business email address of the applying entity.
info@ecb.europa.eu
Enter the street address (no PO Box).
Sonnemannstrasse 20
Enter the city, village, municipality, etc.
Frankfurt am Main
Enter the state, province, department, territory, prefecture, oblast, etc., if applicable.
Frankfurt am Main
1. Enter the postal code, if applicable. 2. If a postal code does not exist, type “Not Applicable”.
60314
DE
Section: Applying Entity Background and Organization
This question set collects information related to the individuals who will have access to TAMS, manage the application, and receive inquiries.
Alain Jean-Jacques Busac, Thierry Roger Julia Bracke, Evelien Francisca Joanna Nagelkerke
Section: Self-Certification
Provide a single document for Self-Certification question Q1.1-1.0 The document must include only the SC1.1-1.1 and SC1.1-1.2 statements.0 Do not modify any of the Self-Certification statements.
1. Provide a single document for Self-Certification question Q1.1-1. 2. The document must include only the SC1.1-1.1 and SC1.1-1.2 statements. 3. Do not modify any of the Self-Certification statements. 4. If the applying entity cannot Self-Certify the SC1.1-1.1 and SC1.1.1-2 statements, provide a document that explains why the applying entity cannot Self-Certify the SC1.1-1.1 and SC1.1.1-2 statements.
Section: Operational/Planning
The document for Q1.2-1 must be a PDF. The document for Q1.2-2 must be an Excel (.xlsx) file.
1. The document for Q1.2-1 must be a PDF.
Section: Security Policy and Planning
Provide a single document for Self-Certification question AGB Q220, Q5.1-1. The document must include only the SC5.1-1.1 through SC5.1-1.3 statements. Do not modify any of the Self-Certification statements. If the applicant cannot Self-Certify SC5.1-1.1 through SC5.1-1.3 statements, provide a document that explains why the entity cannot Self-Certify the SC5.1-1.1 through SC5.1-1.3 statements.
1. Provide a single document for Self-Certification question Q5.1-1. 2. The document must include only the SC5.1-1.1 through SC5.1-1.3 statements. 3. Do not modify any of the Self-Certification statements. 4. If the applying entity cannot Self-Certify the SC5.1-1.1 through SC5.1-1.3 statements, provide a document that explains why the applying entity cannot Self-Certify the SC5.1-1.1 through SC5.1.1-3 statements
Section: DNS Abuse
Provide a single document for Self-Certification question AGB Q221, Q5.2-1. The document must include only the SC5.2-1.1 through SC5.2-1.7 statements. Do not modify any of the Self-Certification statements. If the applicant cannot Self-Certify the SC5.2-1.1 through SC5.2-1.7 statements, provide a document that explains why the applying entity cannot Self-Certify the SC5.2-1.1 through SC5.2-1.7 statements.
1. Provide a single document for Self-Certification question Q5.2-1. 2. The document must include only the SC5.2-1.1 through SC5.2-1.7 statements. 3. Do not modify any of the Self-Certification statements. 4. If the applying entity cannot Self-Certify the SC5.2-1.1 through SC5.2-1.7 statements, provide a document that explains why the applying entity cannot Self-Certify the SC5.2-1.1 through SC5.2-1.7 statements.
Section: Primary String
This question set collects basic information regarding the string that is being applied for (for example, a-label, meaning, script). If the applying entity opts to designate a replacement string, it must answer the same set of questions for the replacement string from the AGB Question Set 5 on.
euro
Provide the meaning, or restatement of the string in English, that is, a description of the literal meaning of the string in the opinion of the applying entity. If there is no literal meaning in English (for example, a brand name or a proper noun without a translation) simply state "No English Translation"
The term “EURO” refers to the common currency used by many countries within the European Union. It denotes the official monetary unit (€) adopted by the Eurozone member states for economic and financial transactions.
If an IDN, provide the script of the string (both in English and as referenced by the RZ-LGR/ISO 15924)
Latin
Provide a representation of the string according to the International Phonetic Alphabet.
/ˈjʊə.rəʊ/ (UK) or /ˈjʊr.oʊ/ (US)
Confirm the statement using a checkbox.
true
1. Describe the mission and purpose of the applied-for gTLD, including the intended registrants and users, and the related activities that have been or will be carried out to achieve this purpose. 1a. If applying for a variant of an existing gTLD, please also describe the mission and purpose of the existing gTLD, including the intended registrants and users, and the related activities that have been or will be carried out to achieve this purpose. 2. Explain how this purpose is sustainable over time.
The mission of the .euro TLD (Top Level Domain) is to create a highly trusted and secure ecosystem online that is defined by its pre-approved Registrants (the European Central Bank and euro area National Central Banks and their partners) to communicate everything about the euro and central bank related topics. The .euro TLD provides support online to the European Central Bank’s (ECB) objective of ensuring the continued trust, stability, and accessibility of the euro currency in an increasingly digital environment by enabling a reliable and recognisable online presence. European Central Bank and 21 euro area National Central Banks currently include: 1. Banque nationale de Belgique (Belgium) 2. Българска народна банка (Bulgaria) 3. Deutsche Bundesbank (Germany) 4. Eesti Pank (Estonia) 5. Central Bank of Ireland 6. Bank of Greece 7. Banco de España (Spain) 8. Banque de France 9. Hrvatska narodna banka (Croatia) 10. Banca d'Italia (Italy) 11. Central Bank of Cyprus 12. Latvijas Banka (Latvia) 13. Lietuvos bankas (Lithuania) 14. Banque centrale du Luxembourg 15. Central Bank of Malta 16. De Nederlandsche Bank (Netherlands) 17. Oesterreichische Nationalbank (Austria) 18. Banco de Portugal 19. Banka Slovenije (Slovenia) 20. Národná banka Slovenska (Slovakia) 21. Finlands Bank (Finland) Purpose The purpose of the .euro TLD (Top Level Domain) is to operate a trusted and clearly identifiable namespace that enables pre-approved Registrants (ECB and euro area National Central Banks) to register and use domain names associated with euro-related activities, information, and services, within a framework designed to support user confidence and trust. The .euro TLD will: • Provide a clearly defined, trusted and recognisable space online for euro-related digital content, services, and communications. • Create a unified, secure and recognisable namespace for euro-related services, outreach, education and innovation. • Support the ECB’s and the Eurosystem’s long-term digital communication, trust and stakeholder engagement strategies. • Implement policies and operational practices that enhance trust, security, and accountability within the namespace • Facilitate the effective representation of the euro in the digital economy. • Reinforce the ECB’s digital identity, authority and credibility in an increasingly complex online environment. The .euro TLD is intended to operate as a trusted, secure and policy-governed namespace where the European System of Central Banks can communicate about the euro to its audiences. The .euro TLD would provide a restricted, trusted and authoritative digital namespace for the ECB, euro area National Central Banks and their partner Banks to communicate clearly and securely about the euro and other central bank related initiatives. As the institution responsible for the euro and for maintaining public trust in the currency, the ECB is uniquely positioned to establish .euro as an official online environment for euro-related information, services, outreach and innovation. The TLD would support communications concerning euro banknotes, the digital euro, public education, stakeholder engagement, and other euro-related activities led or coordinated by the ECB and the Eurosystem. The .euro TLD would therefore serve the public interest by creating a clear, secure and institutionally governed online space for authoritative euro-related content. It would enhance public confidence, reduce opportunities for online abuse, and ensure that information concerning the euro currency is accessible through a domain environment that is trusted, recognisable and controlled by the appropriate public authority.
Section: Safeguard Identification
This question set collects information related to determining whether certain Safeguard Public Interest Commitments (Safeguard PICs) are required for the applied-for gTLD string. See Section 7.8.2.3 Safeguard PICs. Answers to these questions will inform assessment by ICANN on whether and which Safeguard PICs must be incorporated in the applicable Registry Agreement (RA) if the string proceeds to delegation. The answers themselves will not automatically make such a determination.
1. When answering the questions, apply criteria by considering the meaning of the requested TLD string in the following contexts: a. Literally as described in the application b. Literally in any other language in which the string is a recognized word or phrase. c. Informally in any language or regional variant, where alternative meanings exist. 2. If the proverbial “reasonable person” who understands the relevant context believes that the question should be answered ‘yes’, then the answer is yes.
Yes
1. When answering the questions, apply criteria by considering the meaning of the requested TLD string in the following contexts: a. Literally as described in the application b. Literally in any other language in which the string is a recognized word or phrase. c. Informally in any language or regional variant, where alternative meanings exist. 2. If the proverbial “reasonable person” who understands the relevant context believes that the question should be answered ‘yes’, then the answer is yes.
Yes
1. When answering the questions, apply criteria by considering the meaning of the requested TLD string in the following contexts: a. Literally as described in the application b. Literally in any other language in which the string is a recognized word or phrase. c. Informally in any language or regional variant, where alternative meanings exist. 2. If the proverbial “reasonable person” who understands the relevant context believes that the question should be answered ‘yes’, then the answer is yes.
Yes
1. When answering the questions, apply criteria by considering the meaning of the requested TLD string in the following contexts: a. Literally as described in the application b. Literally in any other language in which the string is a recognized word or phrase. c. Informally in any language or regional variant, where alternative meanings exist. 2. If the proverbial “reasonable person” who understands the relevant context believes that the question should be answered ‘yes’, then the answer is yes.
Yes
1. When answering the questions, apply criteria by considering the meaning of the requested TLD string in the following contexts: a. Literally as described in the application b. Literally in any other language in which the string is a recognized word or phrase. c. Informally in any language or regional variant, where alternative meanings exist. I-2. If the proverbial “reasonable person” who understands the relevant context believes that the question should be answered ‘yes’, then the answer is yes.
No
1. When answering the questions, apply criteria by considering the meaning of the requested TLD string in the following contexts: a. Literally as described in the application b. Literally in any other language in which the string is a recognized word or phrase. c. Informally in any language or regional variant, where alternative meanings exist. I-2. If the proverbial “reasonable person” who understands the relevant context believes that the question should be answered ‘yes’, then the answer is yes.
Yes
Select Yes or No. Notes: 1. ICANN will evaluate whether an applied-for gTLD string requires one or more Safeguard Public Interest Commitments (Safeguard PICs) to be included in the Base RA). 2. In addition to the Mandatory Public Interest Commitments (PICs) that must be included in each Base RA, a subset of Base RAs must include Safeguard PICs based on ICANN’s Safeguard Assessment. See Section 7.8.2.3 Safeguard PICs. 3. Applying entities for TLDs that are not found to require Safeguard PICs can elect to add them to the applicable Base RAs voluntarily to, for example, further their business objectives, help address issues or concerns that are raised or could be raised with respect to their applications, or avoid the need for the evaluation and implementation of customized Registry Voluntary Commitment (RVC). See Section 7.8.3 Registry Voluntary Commitments (RVCs).
Yes
Choose the applicable Safeguard PICs from the provided list (more than one option can be selected).
• Registry Operators will include a provision in their Registry-Registrar Agreements that requires Registrars to include in their Registration Agreements a provision requiring registrants to comply with all applicable laws, including those that relate to privacy, data collection, consumer protection (including in relation to misleading and deceptive conduct), fair lending, debt collection, organic farming, disclosure of data, and financial disclosures. • Registry Operators will include a provision in their Registry-Registrar Agreements that requires registrars at the time of registration to notify registrants of the requirement to comply with all applicable laws. • Registry Operators will include a provision in their Registry-Registrar Agreements that requires Registrars to include in their Registration Agreements a provision requiring that registrants who collect and maintain sensitive health and financial data implement reasonable and appropriate security measures commensurate with the offering of those services, as defined by applicable law. • Registry Operators will proactively create a clear pathway for the creation of a working relationship with the relevant regulatory or industry self-regulatory bodies by publicizing a point of contact and inviting such bodies to establish a channel of communication, including for the purpose of facilitating the development of a strategy to mitigate the risks of fraudulent and other illegal activities. • Registry Operators will include a provision in their Registry-Registrar Agreements that requires Registrars to include in their Registration Agreements a provision requiring Registrants to provide administrative contact information, which must be kept up-to-date, for the notification of complaints or reports of registration abuse, as well as the contact details of the relevant regulatory, or industry self-regulatory, bodies in their main place of business. • Registry Operators will include a provision in their Registry-Registrar Agreements that requires Registrars to include in their Registration Agreements a provision requiring a representation that the Registrant possesses any necessary authorizations, charters, licenses and/or other related credentials for participation in the sector associated with the Registry TLD string. • If a Registry Operator receives a complaint expressing doubt with regard to the authenticity of licenses or credentials, Registry Operators should consult with relevant national supervisory authorities, or their equivalents regarding the authenticity. • Registry Operators will include a provision in their Registry-Registrar Agreements that requires Registrars to include in their Registration Agreements a provision requiring Registrants to report any material changes to the validity of the Registrants' authorizations, charters, licenses and/or other related credentials for participation in the sector associated with the Registry TLD string in order to ensure they continue to conform to appropriate regulations and licensing requirements and generally conduct their activities in the interests of the consumers they serve. • Registry Operators will develop and publish registration policies to minimize the risk of cyber bullying and/or harassment. • Registry Operators will include a provision in its Registry-Registrar Agreements that requires Registrars to include in their Registration Agreements a provision requiring a representation that the Registrant will take reasonable steps to avoid misrepresenting or falsely implying that the Registrant or its business is affiliated with, sponsored or endorsed by one or more country's or government's military forces if such affiliation, sponsorship or endorsement does not exist.
Section: Registry Voluntary Commitments (RVCs)
This question set collects information related to any Registry Voluntary Commitments (RVCs) that the applying entity is submitting. The decision to submit an RVC is typically voluntary, except for those recognized by ICANN to resolve an objection or to address GAC Consensus Advice. See Section 7.8.3 Registry Voluntary Commitments for more information.
1. Select Yes or No. 2. In addition to Safeguard Public Interest Commitments (PICs), an applying entity will be permitted to propose one or more Registry Voluntary Commitments (RVCs) to provide additional safeguards with regard to the registry operator’s operation of an applied-for gTLD string. See Section 7.8.3 Registry Voluntary Commitments (RVCs). 3. RVCs are separate from Community Registration Policies. See Section 7.8.3 Registry Voluntary Commitments (RVCs) and Section 7.8.4 Community Registration Policies for more information. If you are applying for a Community gTLD, please submit the Community Registration Policies by answering Questions 150-155. However, if you propose to include additional Registry Voluntary Commitments in the RA beyond the Community Registration Policies, you may answer "yes" and proceed to answer the following questions. 4. You are encouraged to consider whether there are other means, separate from including commitment(s) in the Base RA, that could be used to further your business objectives or help resolve any anticipated or actual issue(s) raised regarding the applied-for gTLD string or application. See Section 7.8.3 Registry Voluntary Commitments (RVCs). Notes: If you select “yes” to this question, you are required to pay the conditional Registry Commitments Evaluation fee, and commitments that are approved by ICANN will be included in Specification 11 of the applicable Base RA as specific voluntary public interest commitments as contractual obligations.
No
Section: Brand & Code of Conduct Exemptions
This question set collects information related to whether the applied-for gTLD string is a .Brand (see Section 7.3) or if the applying entity is seeking a Code of Conduct exemption (see Section 7.4).
Select Yes or No
No
This serves as an indication of intent to apply for an exemption to Specification 9 and that the applying entity is NOT requesting to be designated a .Brand TLD, pursuant to Specification 13.
Yes
Confirm statement with a checkbox.
true
Confirm statement with a checkbox.
true
Provide justification for why the Code of Conduct is not necessary to protect the public interest. This may include an explanation of how the TLD's operation under the exemption would serve the best interests of the registry operator, its stakeholders, and the broader Internet community, without adversely affecting the domain name ecosystem.
The European Central Bank ("ECB") confirms that it is applying for an exemption from the Code of Conduct pursuant to Specification 9 of the Registry Agreement. The .euro TLD will operate under a restricted registration model. Registrations will not be available to the general public and will be limited to the ECB and National Central Banks participating in the Eurosystem. This model reflects the unique institutional and public-interest nature of the euro. Article 1 of the Statute of the European System of Central Banks ("ESCB") provides that the ECB and the national central banks constitute the ESCB and that the ECB and the national central banks of Member States whose currency is the euro constitute the Eurosystem. Article 3 provides that the ESCB's basic tasks include defining and implementing the monetary policy of the Union, conducting foreign-exchange operations, holding and managing official foreign reserves, and promoting the smooth operation of payment systems. Article 8 further provides that the ESCB shall be governed by the decision-making bodies of the ECB. The governance relationship between the ECB and the National Central Banks is established by the Statute of the ESCB. Article 12.1 provides that the Governing Council shall adopt the guidelines and decisions necessary to ensure performance of the tasks entrusted to the ESCB and that the Executive Board shall give the necessary instructions to national central banks. Article 14.3 further provides that national central banks are an integral part of the ESCB and shall act in accordance with the guidelines and instructions of the ECB. The ECB understands that the purpose of the Code of Conduct is to ensure non-discriminatory access to registry services and prevent anti-competitive conduct where domain names are offered in a competitive public market. Those concerns do not arise in relation to the proposed .euro operating model. The .euro TLD will not operate as a general-purpose public namespace. Rather, it will operate under objective eligibility criteria linked to the institutional framework of the Eurosystem. Registrant eligibility will be strictly controlled and registrar participation will be subject to accreditation requirements established by the Registry Operator. The relationship between the ECB and the National Central Banks should be assessed in light of the Treaty-based governance framework described above. Under the ICANN Base Registry Agreement, the definition of Affiliate is based on concepts of control rather than solely on corporate ownership. Granting the requested exemption will: 1- Protect the integrity of the .euro namespace by limiting registrations to authorised Eurosystem institutions. 2 - Reduce the risk of fraud, abuse, phishing and misleading use associated with the euro. 3 - Ensure clear accountability through the governance framework established under the Treaties and the Statute of the ESCB. 4 - Cause no competitive harm, as .euro will not operate as a public retail domain-name market. 5 - Allow the Registry operator to select registrars already showing a high level of security and service demonstrated by the existing relationship with local national banks In light of the restricted registration model, the ESCB governance framework, and the absence of the competition concerns that the Code of Conduct is intended to address, the ECB respectfully submits that application of the Code of Conduct is not necessary to protect the public interest and that granting the requested exemption is appropriate and consistent with ICANN's objectives
Section: Additional Information and Supporting Materials
This question set collects any additional information that the applying entity would like to provide, including any supporting materials.
1. An applying entity may use this response field to submit any additional, optional information or documentation that the applying entity believes enhances understanding of its application or may be of interest to the general public. This could include, but is not limited to, the applying entity’s: a) Individual registry policies; b) Separate agreement with a third-party to fulfill certain commitments; c) Terms of use; d) Additional Community Registration Policies not intended for RA inclusion; e) Other materials that clarify the applying entity’s mission, values, or intended use of the gTLD. Notes: 1. This question is optional and for informational purposes only. 2. The information provided here will not be evaluated as part of the application, or be contractually binding on the applying entity. 3. All submissions to this question will be posted for the public to review and comment.
The European Central Bank (ECB) wishes to highlight the support expressed by national central banks through 17 formal letters of endorsement from the following countries: Austria Cyprus Germany Greece Estonia Spain France Croatia Ireland Italy Luxembourg Lithuania Malta The Netherlands Portugal Slovenia Slovakia The .euro project aims to establish a dedicated online space for the Eurozone market, representing approximately 350 million people across 21 countries and a combined GDP of €15 trillion. The support of the national central banks is therefore of significant importance, as it reflects a shared vision and a coordinated strategic approach to the Eurozone’s digital representation. Note : the 17 letters have been merged into two file for facility of use.
Section: Bona Fide Intent and Prohibited Communications
This question set contains attestations related to the applying entity’s acknowledgment of bona fide intent and prohibited communications.
Confirm the statement using the checkbox.
true
Confirm the statement using the checkbox.
true