Who Can Register a .bank Domain?

Only defined members of the global banking community can register .bank. The official eligibility list covers regulated retail banks, savings associations, national retail banks, their holding or parent companies, qualifying banking associations, and approved government regulators. An ordinary fintech, lender, adviser, insurer, investment firm, credit union, consultancy, software vendor, or individual does not qualify merely because its work involves money.

Eligibility is only the first gate. The requested name must correspond to the institution's legal name or branding, the requesting employee must be authorized, the registry must approve the Verification Application, and an approved .bank registrar must complete the registration. A deployed site also has mandatory technical and security requirements.

1) Check the institution type

The registry's current eligibility page divides eligible organizations into two groups.

Government-regulated entities include:

• retail banks;
• savings associations;
• national retail banks; and
• holding or parent companies of retail banks or savings associations.

Other eligible organizations include associations or groups whose membership is primarily made up of those regulated entities. Government regulators of eligible organizations, and organizations made up of those regulators, may also qualify when approved by the fTLD board.

The wording is narrower than “financial institution.” A company should not infer eligibility from its industry label, a company-registration category, a financial-services licence, or the word “bank” in marketing copy. It should match its legal entity and supervisory status to the registry's current definitions.

If the organization does not fit, stop the .bank application work. Compare a truthful unrestricted name instead. A focused financial product can review %%EDITORIAL_1%% and %%EDITORIAL_2%%, while a consumer-facing brand can compare three TLDs. Those extensions do not confer permission, but they avoid presenting a restricted application path to an ineligible buyer.

2) Match the requested name

An eligible institution cannot automatically register any available word. The registry says the selected name must correspond to the organization's legal name or branding. A registered trademark is not required, but the name still needs a defensible connection to the applicant.

Prepare a short name file before applying:

1. exact legal name and former names;
2. regulated institution name;
3. trading names and public brands;
4. relevant trademarks, if any;
5. current primary domains;
6. evidence that customers encounter the proposed brand; and
7. the reason each requested label corresponds to the institution.

Also search company, trademark, regulatory, app-store, social, and domain records for conflicts. Registry approval is not a general trademark clearance and does not settle every dispute. A short label may be reserved, unavailable, premium-priced, or too ambiguous even when it resembles the applicant's brand.

Read the full address aloud. A concise brand.bank can be clear, while brandbank.bank may be repetitive. The best choice is the shortest approved label that customers can connect to the institution without guessing.

3) Authorize the applicant

The registry's implementation guide says pre-registration verification checks the requesting employee's authority as well as organizational eligibility and name alignment. This is an institutional application, not an employee's ordinary retail checkout.

Assign roles before submission:

• executive sponsor for the domain decision;
• authorized applicant with verifiable employment details;
• legal or compliance reviewer for entity and naming evidence;
• security owner for DNS, certificates, email, and monitoring;
• registrar administrator with protected credentials;
• web and email migration leads; and
• renewal and incident-response owners.

Use institutional contact details that can be independently confirmed. Record approvals in the organization's change or risk system. Do not register through a personal account, use a departing employee as the sole contact, or leave renewal and recovery dependent on one mailbox.

The registry may contact the institution during verification. Make sure reception, security, legal, and executive offices know how to distinguish a legitimate verification request from social engineering.

4) Complete verification first

The official support flow places the Verification Application before registrar registration. The practical sequence is:

1. confirm the organization is eligible;
2. choose a name that corresponds to its legal name or branding;
3. submit the registry Verification Application;
4. respond to evidence or authorization checks;
5. receive approval and verified data by email;
6. choose an approved .bank registrar; and
7. give that registrar the verified data to begin registration.

Approval should not be described as instant. Although a registrar page may show an automated registration-time field, the organization still has to pass the separate registry verification process. Timelines depend on complete evidence, reachable contacts, name questions, and the registry's review.

Keep the approval email and application record in a controlled repository. Limit who can forward or use the verified data. Ask the registry or registrar how a material entity, brand, contact, or control change must be reported.

5) Choose an approved registrar

The registry maintains the current approved registrar list. It says that if the institution's current registrar is not listed, that provider does not yet support .bank registrations.

Evaluate more than the first-year price. Ask each candidate about:

• support for the current .bank security requirements;
• DNSSEC operations and key changes;
• registry lock and change controls;
• role-based access and strong authentication;
• audit logs and approval workflows;
• incident and abuse response;
• transfer, renewal, redemption, and recovery procedures;
• certificate, DNS, email, and migration services;
• service ownership across time zones; and
• the exact registration, renewal, transfer, premium, and service fees.

The registry list includes providers with different technical certifications and services. Those labels help shortlist vendors, but the institution should verify the scope and current status of any certification it relies on. A registrar relationship does not transfer accountability for the institution's own systems and procedures.

Do not send registry approval data to an unlisted reseller or a provider found through an advertisement. Start from the registry's live list, then open the registrar's official site.

6) Price the full project

Public pricing is not consistent across approved registrars. On 16 August 2026, approved registrar 101domain displayed the following standard .bank prices:

The 101domain %%EDITORIAL_0%% page states that pricing was updated on 13 July 2026. The three-year scenario is $999 + (2 × $1,199) = $3,397. It excludes taxes, premium-name charges, implementation services, certificates, DNS or email work, migration, monitoring, and future changes.

The registry's registrar directory does not publish a common retail price. Some approved providers use quote-led corporate sales. Obtain written quotes for the same label, term, services, and support scope. Do not treat a missing public price as zero, and do not compare a managed migration quote with a domain-only checkout price.

Budget for the complete operating model:

• application and legal review time;
• domain registration and ordinary renewals;
• premium classification, if applicable;
• registrar and registry security options;
• DNS and DNSSEC operations;
• certificates and HTTPS maintenance;
• email authentication and monitoring;
• website and email migration;
• customer communications and staff training; and
• ongoing compliance, incident response, and recovery tests.

Price changes and policy changes require a fresh check immediately before approval and publication.

7) Implement the security controls

The current registry implementation guide identifies mandatory controls that are not ordinarily imposed on unrestricted commercial domains. It covers secure name servers, DNSSEC, a digital identity certificate for HTTPS, TLS 1.2 or higher, and email authentication using DMARC and SPF. It also discusses DKIM as an enhancement.

Treat the official guide and linked policies as the controlling source. Technical teams should convert the current requirements into testable controls, owners, evidence, monitoring, and remediation windows. Requirements can change, and a registrar's default setup may not cover every workload or subdomain.

Inventory:

• the apex and www hostnames;
• online banking and customer portals;
• every customer-facing subdomain;
• APIs, mobile-app endpoints, and redirects;
• outbound and inbound mail systems;
• third-party senders and support platforms;
• name servers, DNS signers, and certificate owners; and
• disaster-recovery and failover environments.

Test certificate issuance and renewal, DNSSEC validation, TLS configuration, DMARC alignment, SPF evaluation, DKIM where deployed, redirect integrity, monitoring alerts, and recovery access. A passing launch test is not permanent compliance.

8) Avoid a false safety promise

Eligibility verification and mandatory controls provide meaningful boundaries. They do not guarantee that every page, email, employee, transaction, product, claim, vendor, or customer outcome is safe.

A legitimate institution can still suffer account compromise, vulnerable software, misconfiguration, insider abuse, vendor failure, or misleading content. A lookalike attacker can also use a different domain, subdomain, social account, phone number, or paid advertisement.

Customer guidance should therefore be precise:

• explain that .bank registration is restricted and verified;
• state the official website and support channels;
• tell customers what the bank will never request;
• encourage independent navigation instead of message links;
• provide a clear impersonation-reporting route; and
• avoid claiming that the suffix alone makes an interaction safe.

Security graphics should not substitute for evidence. Publish current contact details, legal identity, regulatory information, product terms, privacy information, and incident guidance in accessible text.

9) Plan the migration

The registry's support material recommends deliberate migration, including redirects from old addresses, email aliases, and customer education. A bank should decide whether .bank will become the primary address, a protected redirect, or a staged service endpoint.

For a primary-site migration:

1. inventory every public URL and email address;
2. map each old URL to its closest new destination;
3. keep the existing domain under strong control;
4. configure and test permanent redirects;
5. update applications, APIs, statements, cards, forms, branches, and vendor records;
6. maintain email aliases during a measured transition;
7. educate customers before and after cutover; and
8. monitor errors, spoofing, support contacts, and authentication results.

Do not abandon the old .com or country-code name after teaching customers to use it. A controlled legacy domain remains valuable for redirects, email continuity, defensive protection, and recovery. Keep one canonical version of each page to avoid conflicting rates, disclosures, and support instructions.

If the exact legacy .com belongs to the institution, the decision is not .bank or .com. The safer architecture may use both, with one canonical customer destination and explicit roles for the other.

10) Keep search claims accurate

IANA's %%EDITORIAL_0%% record classifies it as a generic TLD sponsored by fTLD Registry Services, LLC. It records registration on 26 November 2014 and an update on 1 July 2024.

ICANN's agreement record lists a base, community, non-sponsored registry agreement dated 25 September 2014. These records establish the namespace and registry relationship. They do not endorse a particular institution, product, website, or transaction.

Google's current search FAQ says the TLD does not determine search performance. An assumed ranking boost is therefore a poor reason for migration.

Search visibility depends on accessible pages, useful content, stable redirects, crawlable implementation, reputation, links, and many other signals. Migration mistakes can disrupt discovery even when the new ending is relevant. Preserve URLs where possible, redirect carefully, update sitemaps and canonical signals, and monitor indexed pages and search errors.

11) Make the application decision

Proceed when the legal entity fits the registry's eligible categories, the requested label corresponds to its name or brand, an authorized employee can complete verification, an approved registrar can support the operating model, and technical teams can maintain the current controls.

Pause when eligibility is inferred rather than documented, the name has a weak connection to the applicant, pricing excludes essential services, ownership is unclear, or the organization cannot sustain DNS, certificate, email, migration, and incident responsibilities.

Do not apply when the organization is outside the registry's categories. Use an accurate unrestricted extension and publish the legal identity and permissions customers need to verify. Never suggest that registration availability can cure an eligibility problem.

For an eligible bank, .bank can provide a verified naming boundary and a stronger technical baseline. The value comes from the complete system: controlled application, approved registration, secure implementation, careful migration, customer education, and continuous operation.