Ju kërkojmë ndjesë: kjo përmbajtje nuk është ende e disponueshme në shqip. Aktualisht po shfaqim versionin origjinal në anglisht.

.BANK Doing Surprisingly Well in Sunrise

Shikime:5590 Koha:2015-06-18 14:31:50 Autori: Sophia Kontakt supposet email
.BANK Doing Surprisingly Well in Sunrise
When .BANK launched in 2015, its Sunrise period attracted more than 700 domain applications, an unusually strong response for a restricted new generic top-level domain (gTLD). Unlike open extensions such as .COM, .BANK was designed for verified banking institutions, with strict eligibility checks intended to reduce impersonation and fraudulent registrations.

More than a decade later, the important question is no longer how many Sunrise applications .BANK received. It is what banks need to qualify for a .BANK domain, how the registry verifies applicants, and what security standards must be maintained after registration.

Operated by fTLD Registry Services, .BANK combines institutional verification with mandatory technical security requirements. These include DNSSEC, HTTPS/TLS and email authentication.

For institutions considering a .BANK domain, NiceNIC's .BANK information page provides a starting point for reviewing domain options. Before ordering, check the official fTLD eligibility rules and confirm the applicable registration arrangements and requirements.

Why Did .BANK Attract So Much Interest During Sunrise?

The .BANK Sunrise period took place in 2015, when eligible trademark holders could apply for matching domain names before general availability.

At the time, fTLD reported more than 700 applications. That figure was notable because .BANK was never intended to be an open domain extension available to anyone who wanted a financial-sounding name.

Applications were not the same as completed registrations, and the Sunrise figures should not be confused with the number of .BANK domains in use today.

The early response nevertheless highlighted an important consideration for banks: a domain extension reserved for verified institutions could offer something that a conventional open namespace could not — a registration environment with additional identity and security controls.

Those restrictions remain central to .BANK’s purpose.

Who Is Eligible to Register a .BANK Domain?

.BANK is a restricted gTLD. Being involved in financial services does not automatically qualify an organization to register one.

Under fTLD’s current Registrant Eligibility Policy, qualifying organizations include:

  • State, regional, provincial and national retail banks chartered and supervised by the relevant government regulatory authority.
  • Savings associations meeting the applicable regulatory requirements.
  • Qualifying holding or parent companies of retail banks and savings associations.
  • Associations and groups of associations primarily representing eligible banking institutions.
  • Certain banking regulatory authorities and related organizations, subject to the applicable policy and approvals.

Other regulated entities may qualify only under specific circumstances and with approval from the fTLD Registry Operator Board.

Can Fintech Companies Register .BANK Domains?

A fintech startup, payment processor, cryptocurrency exchange, financial consultant or banking software provider is not automatically eligible simply because its business involves financial services.

The registry’s eligibility rules focus on qualifying banking institutions and specifically permitted organizations, not the broader financial technology industry.

A service provider helping a bank operate its website may assist with technical implementation, but that does not make the provider eligible to register a .BANK domain in its own name.

The intended registrant must independently satisfy the applicable policy.

Organizations uncertain about eligibility should consult the official .BANK eligibility criteria before paying registration fees or making migration plans.

What .BANK Domain Names Can an Eligible Bank Register?

Institutional eligibility is only the first requirement. The requested domain name must also comply with fTLD’s Name Selection Policy.

In general, the name must correspond to the eligible organization’s legal name or recognized branding, such as a trademark, trade name or service mark.

A registered trademark is not necessarily required, but the applicant must have a legitimate basis for the name.

For example, an eligible bank may wish to register a domain matching its established business name or a brand it uses for banking services.

That is different from attempting to register a generic banking phrase solely because the name appears commercially valuable.

Certain names are reserved or subject to additional restrictions. A name that appears available in a search tool may still fail the registry’s naming or verification checks.

Owning a matching .COM domain does not automatically give an institution the right to the corresponding .BANK name.

The registry assesses the requested name under its own policies, and competing eligible applicants may have legitimate interests in similar names.

See fTLD's Name Selection Policy and eligibility guidance for the applicable rules.

How Does .BANK Verify Registrants Before Registration?

Unlike an ordinary domain registration that may be completed shortly after payment, .BANK requires verification by the registry before a domain is registered.

fTLD verifies the applicant’s institutional eligibility, the requested domain name and the authority of the person making the request.

The process is designed to reduce the risk of an unauthorized person registering a domain that appears to belong to a legitimate bank.

What Information Should Applicants Prepare?

An institution should be ready to provide accurate information about:

  1. Legal identity: The official registered name of the banking institution.
  2. Regulatory status: The relevant government regulator and supporting institutional identification.
  3. Requested domain: The domain name and its connection to the institution's legal name or branding.
  4. Registrant contact: The employee responsible for the registration and domain administration.
  5. Independent verification contact: An authorized senior employee who can confirm the request.
  6. Supporting evidence: Documents demonstrating the institution's authority to use a requested brand or name, when needed.

fTLD’s current application instructions specify that the Verification Contact must be separate from the Registrant Contact and hold an appropriate executive or officer position.

How Does the Registration Process Work?

The practical sequence is:

Step 1 — Check eligibility and naming rules. Confirm that the organization and requested domain meet fTLD’s requirements.

Step 2 — Submit the verification application. The organization can begin through the registry's official .BANK application process.

Step 3 — Complete registry verification. fTLD reviews the relevant information and may require clarification or supporting documentation.

Step 4 — Arrange registration through an approved channel. Once verification is approved, the institution works with an appropriate .BANK registrar to complete the registration.

Step 5 — Implement the security requirements. Before the domain is used for production services, the institution must ensure that its DNS, website and email configuration meets the applicable fTLD standards.

A successful payment or an available-domain search result does not replace registry approval.

The registry may also perform subsequent verification, including checks associated with changes to important registration information.

What Security Requirements Apply to .BANK Domains?

.BANK’s security requirements are one of its main differences from unrestricted domain extensions.

fTLD establishes technical controls for domains used on the internet and monitors compliance.

A bank planning to use a .BANK domain should involve its DNS, website security and email administrators before launching services.

1. DNSSEC: Protecting DNS Integrity

Domain Name System Security Extensions (DNSSEC) help verify the authenticity of DNS responses and reduce certain DNS spoofing and cache-poisoning risks.

For .BANK, DNSSEC is part of the mandatory security framework for active domains.

The bank’s DNS provider must support the required signing and key-management operations, while the registrar and registry-side configuration must support the corresponding delegation information.

fTLD also restricts outdated cryptographic algorithms.

Before activating a .BANK domain, confirm that the chosen DNS provider can manage DNSSEC signing, DS records, key rollovers and applicable subdomains.

This is particularly important during DNS migrations, when incorrect signing or delegation can make a domain inaccessible.

2. HTTPS and TLS: Securing Website Connections

.BANK is included in the HTTP Strict Transport Security (HSTS) preload list.

Browsers following that list require secure HTTPS access to .BANK websites.

A bank cannot rely on an ordinary unencrypted HTTP website and assume visitors will still reach it successfully.

fTLD’s published technical requirements include:

  • Valid TLS certificates for applicable web services.
  • TLS 1.2 or higher for web connections, with TLS 1.3 recommended.
  • Restrictions on obsolete protocols and weak cryptographic algorithms.
  • Secure handling of website redirects and other supported services.

Banks migrating from an existing domain should prepare valid certificates before directing customers to the new .BANK website.

Even a simple redirect endpoint under .BANK must meet the applicable HTTPS requirements.

3. DMARC and SPF: Protecting Banking Email

Email authentication is another important part of the .BANK security model.

For delegated .BANK domains subject to these requirements, the registry requires a valid DMARC record even when the domain is not used to send email.

A domain that does not send email must publish a DMARC policy that rejects unauthorized messages:

p=reject

For domains used to send email, fTLD requires SPF and DMARC, including a DMARC reject policy for ongoing operations.

During an approved email implementation period, a temporary p=none or p=quarantine policy is permitted, but the registry requires the policy to move to p=reject within 90 days of deployment.

DKIM is recommended to strengthen email authentication, although it is not independently mandatory under the current published requirements.

Banks should confirm that all legitimate email senders, including outsourced providers, are included in the appropriate authentication configuration before enforcing rejection.

4. Secure Nameserver and DNS Operations

.BANK also imposes requirements on its DNS and nameserver environment.

Banks should confirm that their DNS hosting provider can support the registry’s technical standards, not simply that the provider allows ordinary A, MX or TXT records.

For institutions using customized nameservers, the relevant nameserver and DNSSEC requirements need particular attention.

Outsourcing DNS management does not transfer responsibility for registry compliance entirely to the vendor.

The registrant remains responsible for ensuring that its service providers maintain the required configuration.

The full specifications are available in fTLD's Security Technical Details and Implementation Guide.

What Changed in .BANK Email Security in 2026?

In July 2026, fTLD announced an additional email-security development involving Public Suffix Domain DMARC (PSD DMARC).

The development followed publication of IETF RFC 9989 in May 2026, which formalized DNS Tree Walk behavior for DMARC discovery.

This supports the use of DMARC policy information at the top-level domain, helping participating mail receivers apply an additional layer of protection against spoofed messages.

For .BANK, the enhancement complements the registry’s existing email-authentication requirements.

It does not eliminate the responsibility of individual banks to configure their own DMARC and other required authentication records.

The effectiveness of the additional protection also depends on receiving mail systems implementing the relevant standards.

Read fTLD's July 2026 email-security announcement for the technical background.

Does Registering .BANK Automatically Make a Bank Secure?

No.

The restricted registration model and mandatory security controls reduce important risks, but a .BANK domain does not make every aspect of a bank’s website, email or infrastructure immune to attack.

DNSSEC helps protect DNS integrity. TLS protects communications in transit. DMARC helps reduce unauthorized email spoofing. Registry verification makes it harder for ineligible parties to obtain a convincing .BANK name.

These protections address different threats.

A bank must still maintain secure applications, protect customer accounts, monitor vulnerabilities, manage employee access and respond to security incidents.

Fraudsters may also attempt to impersonate banks through unrelated domain extensions, social media accounts or other channels.

A .BANK address offers a useful additional trust signal, but customers should still verify that they are dealing with the intended institution.

What Should Banks Consider Before Migrating to .BANK?

Moving from an established banking website to a .BANK domain requires more than registering a new name.

For a bank with an existing customer base, the transition affects website access, search traffic, employee email, customer communications and potentially third-party integrations.

Before switching:

  • Confirm registry approval and ownership of the .BANK domain.
  • Select DNS and hosting providers capable of meeting fTLD security requirements.
  • Configure DNSSEC, HTTPS/TLS and the relevant email-authentication records.
  • Test website functionality and redirects before public migration.
  • Plan 301 redirects from existing website URLs to their new locations where appropriate.
  • Update customer communications, email signatures, business listings and important external references.
  • Maintain existing domains and email routing during the transition as needed.
  • Document renewal responsibility, administrative access and ongoing security monitoring.

Banks do not necessarily have to abandon their existing .COM or country-code domains immediately.

Keeping established domains for redirects, customer communications or other legitimate purposes may be part of the transition strategy.

A permanent redirect can help search engines and users discover the new address, but it should not be presented as a guarantee that rankings or traffic will remain unchanged.

The registry provides a detailed Guide to Moving to .BANK covering technical implementation and migration planning.

How Much Does a .BANK Domain Cost?

.BANK generally has higher registration and renewal costs than many open domain extensions.

Pricing varies by registrar, registration arrangement and the particular domain requested. Certain premium or reserved names may have additional conditions.

For a qualifying institution, the financial decision should consider more than the domain fee.

DNSSEC-capable infrastructure, secure hosting, email authentication, monitoring and ongoing compliance may involve additional operational costs.

Before placing an order, confirm the actual registration price, renewal price, supported registration term and any applicable verification or technical service charges.

If your institution is evaluating .BANK through NiceNIC, review the current .BANK domain information and contact NiceNIC to confirm the available registration channel and applicable conditions before payment.

Frequently Asked Questions About .BANK Domains

Can any financial services company buy a .BANK domain?

No. .BANK is restricted to eligible banking institutions and other organizations specifically permitted under fTLD’s policy. Operating a fintech, payment or financial consulting business does not automatically establish eligibility.

Do I need a registered trademark to register .BANK?

Not necessarily. The requested name must correspond to the institution’s legal name or recognized branding and satisfy the registry’s Name Selection Policy. A registered trademark is not a universal requirement.

How long does .BANK verification take?

The time depends on the applicant, the information provided and any additional verification required. Applicants should not assume that registration will be completed immediately after submitting an order. Refer to fTLD’s verification process and allow time for approval before scheduling a public launch.

Is DNSSEC mandatory for .BANK?

DNSSEC is part of fTLD’s mandatory security framework for .BANK domains used on the internet. Before activating DNS services, confirm that your DNS provider and registrar arrangements can satisfy the registry’s requirements.

Can I use .BANK without sending email?

Yes, but a delegated .BANK domain still needs to satisfy the applicable email-authentication rules. fTLD requires a valid DMARC record even for domains not used to send mail, including a reject policy. Publishing an SPF record that authorizes no senders is also recommended.

Can I register a .BANK name simply because it is available?

No. Availability alone is insufficient. The organization must qualify under the registry’s eligibility policy, the name must meet the applicable selection rules, and the registration must pass verification.

Can I keep my existing .COM domain?

Yes. An institution can maintain its existing domain while introducing .BANK, subject to its own operational and security decisions. The registry’s migration guidance discusses redirecting web traffic and maintaining email continuity during the transition.

From Sunrise Interest to Verified Banking Infrastructure

The strong .BANK Sunrise interest reported in 2015 was an early indication that financial institutions saw value in a restricted domain environment.

Today, .BANK is better understood as part of an institution’s security and digital identity strategy rather than simply another domain extension to purchase.

Its value comes from the combination of verified eligibility, controlled name selection and mandatory technical safeguards.

For banks considering adoption, the right starting point is to establish eligibility, verify the proposed name and plan the security implementation before committing to migration.

Organizations exploring their options can review NiceNIC's .BANK information and discuss registration arrangements through NiceNIC support.

The most important consideration is not how quickly a .BANK domain can be purchased, but whether the institution is qualified and prepared to operate it in accordance with fTLD’s requirements.

Primary Sources

Të drejtat e autorit © 2006–2026 NICENIC INTERNATIONAL GROUP CO., LIMITED. Të gjitha të drejtat e rezervuara.