Onchain TLDs and banks: what a general counsel should check

A regulated financial institution earns its name over decades. The name appears on account statements, payment confirmations, wire instructions, custody reports and mobile notifications. Each time it does, it carries a specific weight: the counterparty trusts that the instruction is genuine because the name behind it is controlled. That trust is the core asset, and it is also the weak point when the name exists, uncontrolled, somewhere else.

An onchain TLD, a top-level domain recorded as a token on a public blockchain and sitting outside the ICANN DNS root, can create exactly that situation. A TLD matching your institution’s name can be registered by someone other than your institution. Names issued under it, such as pay.yourbrand or treasury.yourbrand, can resolve in the wallets that support them, be used as payment recipients and be attached to software agents. Your customers and counterparties do not necessarily know which naming system they are looking at.

This article explains why that exposure is different for financial institutions than for most brand owners, maps the functions where it matters most, and gives a ten-point checklist that can be delegated to legal, fraud, treasury and communications teams the same day.

Why financial brands carry different weight in a namespace

For a consumer goods company, a look-alike name is a brand problem. For a financial institution, it is a fraud exposure positioned at the exact moment money moves. The name of a bank or payment provider is one of the few identifiers that customers are conditioned to trust without further verification. That conditioning is deliberate: institutions spend heavily on teaching customers that their name is the safe signal. It is also the reason a name carrying that identifier, issued by someone else, does more harm here than in almost any other sector.

There is a second difference. A retailer whose name is misused loses a sale or some goodwill. A bank whose name is misused may face a customer who has lost money and who believed, reasonably, that the bank was on the other side of the transaction. The loss lands on a person, the complaint lands on the institution, and the question of who bears it is decided under customer protection rules that vary by country. Your own counsel decides how those rules apply; the point here is that the exposure is financial and personal, where for most brands it is reputational.

The remedies a brand team usually reaches for do not carry over. The UDRP, the dispute policy for domain names in ICANN’s generic TLDs, binds a registrant through the registration agreement signed with an accredited registrar. An onchain TLD sits outside that contractual chain, so the policy has nothing to attach to, and no registrar exists to receive a takedown request. The person who holds an onchain TLD matching your institution’s name has no procedural obligation to hand it over. What remains is a negotiated acquisition, or an action against the holder in a court that has jurisdiction over them, with all the uncertainty that implies.

Your legal team should understand this distinction before a problem arises, because it changes the order of work. In the DNS, you can often wait, watch and file a complaint when misuse appears. Onchain, the practical options are settled earlier and more quietly.

What a customer sees when a payment resolves to a name

The most immediate exposure is at the point of payment. In wallets that support onchain names, a sender can address a transfer to a readable name instead of a raw wallet address. A raw address is a long string of letters and digits that gives a sender almost nothing to verify. A name such as pay.yourbrand reads as authoritative. The customer’s instinct is to trust it precisely because it carries the institution’s identifier.

The power to issue names under a TLD belongs to whoever holds it, and to nobody else. If a third party holds .yourbrand, that party decides whether pay.yourbrand exists and which address it points to. The record is public, and anyone can look it up on a block explorer, but retail customers do not open block explorers. They read the name. An institution that does not hold the TLD cannot set, audit or withdraw any name under it, and cannot tell a customer that pay.yourbrand leads to an account it controls.

Consider what the screen shows. In an ordinary bank transfer, many payment systems display or check the name of the account holder before the customer confirms. In a wallet, the readable name is the confirmation. Nothing else on the screen is intelligible to a non-specialist. A customer who has learned from your own security messaging to “check the name before you pay” will apply that habit in a setting where the name proves nothing about who issued it.

The same mechanism appears in payment links. shaka, an onchain payment router, lets a payment link pay out to a name where a raw address would otherwise appear, with the split between the parties agreed and signed onchain before any funds move. It routes funds and does not hold them. Tools of this kind make names more useful as recipients, which is the reason to know who can issue names that carry yours. The site’s page on payments addressed to a name sets out how this works in more detail.

Scale matters and should be stated honestly. Onchain names resolve outside the ICANN DNS root, so an ordinary browser does not open them without support, and wallet support is partial and changes. Freename names, for instance, are supported in Bitcoin.com Wallet, in MetaMask through Freename’s resolver, and in desktop browsers through the Freename Web3 extension. The customers exposed are those who already use such wallets, which for most retail banks is a minority of the customer base. For an institution with a digital asset custody line, a brokerage arm or a payment product aimed at that audience, it is the core of the base.

Treasury and counterparty instructions

The retail scenario becomes visible because customers complain. The treasury scenario is quieter and larger in value per event. Corporate treasury, correspondent relationships and asset servicing all run on instructions that identify the receiving institution by name. Wherever a treasury or settlement process accepts an onchain name as a recipient, for a tokenized asset transfer or a collateral movement for example, the question of who issued that name becomes a control question.

A name such as settlement.yourbrand or collateral.yourbrand in a counterparty’s records carries the same institutional weight as letterhead. If a third party holds .yourbrand and issues those names, an operations analyst at the counterparty has no simple way to tell them apart from names your institution issued. The check that would settle it, reading the record on a block explorer and comparing the address with one confirmed through another channel, requires knowledge that most treasury teams do not have as a routine matter.

Banks already know this problem in another form. A change of settlement instructions received by message is not acted on until it has been confirmed through an independent channel, usually a call back to a known contact. The control exists because the instruction and its apparent sender can both be forged. An onchain name is an instruction of the same kind: it tells the payer where to send funds, and its apparent origin is the word after the dot. The existing call-back discipline covers it only if someone has written onchain names into the procedure.

Automation raises the stakes. Straight-through processing is designed to remove manual review. A plausible name that resolves to an unfamiliar address can pass a name-match step and fail only at an address-match step, if that step exists. Two questions follow for an institution reviewing its controls. Do your own systems, where they accept names at all, verify the address behind the name against an approved list? And have you told your counterparties which names, if any, you issue, so that they can treat every other name carrying your identifier as unverified?

Agents acting under the institution’s name

Software agents that act with some autonomy add an identity question to the payment one. ERC-8004, titled “Trustless Agents,” is a draft Ethereum standard for agent identity. It sets out three registries: one for identity, where each agent is an ERC-721 token pointing to its agent card (the document that describes the agent), one for reputation, built from feedback by those the agent worked with, and one for validation, which holds independent checks of its work. For a bank’s planning, two caveats apply: the standard is a draft that may change, and how naming registries connect to it is still evolving.

The direction is what matters for a bank. An agent that negotiates, requests quotes or initiates payments needs a label that a counterparty can read. An agent presenting as settlements-agent.yourbrand carries the institutional identifier in its name. If your institution does not hold .yourbrand, it cannot prevent the holder from issuing that name to an agent you have no connection to. That agent could then appear in procurement workflows, lending pipelines or any other context where your name creates a presumption of authority.

Financial institutions have a mature vocabulary for this: authority to bind. A relationship manager, a dealer and an authorized signatory each act within documented limits, and counterparties can ask for evidence of those limits. An agent has no signatory list unless you build one. A name issued under a TLD you hold is one way to say “this agent is ours”, because no one else can issue it. A name issued under a TLD you do not hold says nothing, yet reads the same. The page on agent identities under a TLD describes what works at present and what remains a draft.

What supervisors generally expect

No framework or supervisory body is named here, and expectations differ by country and by type of license. In general terms, a regulated financial institution is expected to maintain controls proportionate to the risks it faces in three areas that touch this subject: fraud prevention, impersonation and operational resilience.

On fraud prevention, institutions are generally expected to identify the channels through which their name could be used to deceive customers or counterparties, and to take reasonable steps to close or monitor them. An onchain TLD matching the institution’s name, held by someone else, is such a channel. That it operates outside the DNS does not obviously place it outside the risk perimeter: supervisory reasoning tends to start from the harm to the customer and work back to the control, whatever the technical system involved.

On impersonation, institutions are generally expected to watch for unauthorized use of their name and to act on credible findings. Watching an onchain namespace is not different in principle from watching for look-alike domains in the DNS. The tools differ, and the response differs: there is no registrar to write to, so the realistic responses are customer warnings, counterparty notices and, where it makes sense, acquisition. A service that monitors a brand’s names onchain covers the watching part.

On operational resilience, institutions are expected to know their critical functions and what those functions depend on. A payment name that customers or counterparties rely on is an operational identifier. If a third party controls what it points to, that is a dependency, and dependencies on third parties are normally inventoried, assessed and reported.

What an examiner or internal auditor is likely to ask for is modest: evidence that the question was considered, by whom, with what conclusion and with what review cycle. An institution that has looked, found little and written it down is in a sound position. An institution that has never looked has nothing to show. This is information and not legal advice; how a given supervisory regime treats the subject is for your own counsel to determine.

Exposure by function

The table maps four functions of an institution to what an onchain TLD in other hands would mean for each.

Two of the four rows end with acquisition as the only complete remedy. That follows from the rule that only the holder issues names: warnings and notices reduce the harm, but they do not remove the name. One further detail matters for planning. A Freename TLD carries no annual renewal fee, so a holder has no recurring cost that would lead the TLD to lapse. The DNS habit of waiting for a domain to drop does not apply.

The communications row deserves a word, because it is the one a bank controls fully. An institution that has told its customers plainly which channels and names it uses, and that it issues no onchain names (or exactly which ones), has given every customer and every counterparty a reference point. That statement costs little and does not depend on any negotiation.

A ten-point checklist across legal, fraud, treasury and communications

Each check is written so that it can be handed to one function with a clear deliverable. The first two establish the facts, and the rest depend on them.

1. Search the onchain registryLegal: check whether a TLD matching your institution's primary name, its common abbreviation and any major product brand is registered on Freename or a comparable onchain registry. That record is public, and a block explorer is enough to check it.
2. Identify names already in useFraud: if the TLD exists, check whether names under it point to wallet addresses or agent cards. A name that points to an address with activity ranks above a TLD with no names under it.
3. Assess the payment channelFraud: determine whether any name under the TLD could plausibly appear in a payment instruction that your customers or counterparties would follow. A name such as pay.yourbrand matters more than an obscure one.
4. Review treasury controlsTreasury: establish whether your systems, and those of your main counterparties, accept onchain names as recipients, and whether the address behind a name is verified against an approved list. Record any gap with the operational risk function.
5. Extend the call-back ruleTreasury: amend the procedure for changes to settlement instructions so that an onchain name is treated as an instruction to be confirmed through an independent channel.
6. Audit agent identifiersLegal and technology: if the institution operates or is evaluating software agents, confirm that any name proposed for them falls under a TLD the institution holds. If it does not, choose another naming scheme until the question is settled.
7. Record the riskLegal: enter the onchain namespace in the fraud and impersonation risk register, with what was assessed, what was found, what is planned and a review cycle.
8. Review customer and client guidanceCommunications: check that security pages, client onboarding packs and scripted messages say which names and channels the institution uses, and that no material presents a name format the institution does not control.
9. Set a monitoring baselineFraud: whether or not the TLD is acquired, arrange for new names under it and changes to existing records to be reported. A single snapshot is not enough, because onchain records can change without notice.
10. Assign ownership of the fileGeneral counsel: designate one owner across the four functions, with authority to instruct outside advisers and to escalate if the findings warrant it.

Checks one to three can be completed without any outside contact and without disclosing the institution’s interest to anyone. The Namespace Exposure Score, a free tool on this site, gives a structured way to frame the result of those first checks before the file goes to a committee.

Decision options and who should own the file

Once the checklist is complete, the institution has a bounded set of options. They are not all available in every situation, but setting them out early prevents inaction by default.

Acquire the TLD

If no one holds the TLD, the institution can register it with the registry. If a third party holds it, the institution can mandate an intermediary to approach the holder, with a mutual NDA covering the exchange from the start. The brand namespace recovery service describes this path. Price and timing depend on the holder, and neither can be predicted with the confidence of a domain dispute under a published policy.

Activate the TLD

Holding the TLD without using it gives defensive cover and nothing else. Issuing names, setting the records they point to and publishing which names are official is a separate workstream with its own owners in technology and communications. The page on putting a TLD to work after the transfer describes what it involves.

Monitor without acquiring

If an acquisition is not feasible, or the TLD has no names under it, monitoring is the minimum position that can be defended. It does not remove the exposure. It tells you when the exposure changes, which is when the other options should be reopened.

Do nothing and document why

If the assessment concludes that the exposure is low, for instance because the name is a common word, the TLD has no names under it and your customer base does not use wallets, that conclusion is a decision. It belongs in the risk register with a review cycle, signed by the file owner.

Who owns the file

Ownership should sit with the general counsel or a designated deputy, with standing input from fraud and treasury risk. Brand teams are often the first to notice an onchain TLD, and their trademark records are needed. The risks specific to a financial institution, however, are payment misdirection, agent authority and supervisory expectation, and those sit in legal and risk. A file owned by marketing tends to be assessed as a naming matter and budgeted accordingly.

One practical point on budget: the acquisition option should be costed by the function that would bear the loss if the exposure materialized. In most institutions that is not the function that holds the brand budget.

Keep the file confidential while it is open

A bank is better equipped for this than most organizations, because it already runs restricted matters. The practices used for a sensitive transaction transfer directly: a short list of named people who know, a project name that does not contain the TLD, and documents stored where access is logged. Where privilege is available, counsel should direct the assessment so that the working papers benefit from it.

The leaks to anticipate are mundane. A supplier onboarding form that names the counterparty, a budget line with a descriptive title, a ticket in the security team’s queue that quotes the TLD, an inquiry sent from a corporate address to a marketplace: each tells someone outside the group what the institution is looking at. None requires bad faith, only an ordinary process applied to an unusual file.

Timing of internal disclosure also needs a decision. The fraud function and treasury need to know that an exposure exists in order to run their checks. They do not need to know whether an acquisition is being considered. Splitting the file into an assessment, which is widely shareable inside the institution, and a transaction, which is not, lets the checklist proceed without widening the circle.

If your institution has received a note about a TLD that matches its name, the same discipline applies in reverse: decide who answers, and read the standard mutual NDA to see what confidentiality should look like before a substantive exchange begins.

What holding the TLD enables, beyond defense

The defensive case stands on its own. Control of the TLD also gives the institution capabilities that can be assessed on their merits, and that assessment should be sober about limits.

Payment names under a TLD the institution holds let it offer customers and counterparties a readable recipient that it issues, audits and can withdraw. For treasury relationships, a name such as settlements.yourbrand pointing to a confirmed address is easier for a counterparty to check than a raw address, and the record can be read by anyone. The page on names that resolve in wallets covers where that works. Coverage is partial, and for reaching the general public a website on the DNS remains the better instrument. An onchain name complements a bank’s domain and does not replace it.

For corporate clients, the institution could issue names to its own client-facing services, so that a client’s systems recognize an official endpoint by the TLD. For agents, holding the TLD means that every agent carrying the institution’s identifier was named by the institution and can be un-named by it. That gives the institution something close to a signatory list for software.

There is also a statement the institution becomes able to make: “every name under .yourbrand is ours.” That sentence is simple enough for a customer notice and precise enough for a counterparty agreement. Without the TLD, the equivalent statement is “we issue no onchain names”, which is accurate but leaves every such name to be judged case by case.

Economics are secondary for a bank. Freename runs a royalty program under which a share of each registration fee for names under a TLD goes to its holder. The advertised share goes up to half, subject to the registry’s current terms and to activation conditions. Taking part is not free either: the TLD itself has no renewal fee, but the royalty program carries an annual cost set by the registry. Some TLDs were registered under earlier terms that include the program for life, and whether those terms pass to a buyer is confirmed with the registry before closing. An institution that issues names only to itself will see little of this. It becomes relevant only if names are offered to third parties, which for a regulated institution raises questions of its own about who may carry its identifier.

The first step, and who takes it

The first step is internal and costs nothing: have the first three checks completed by legal and fraud, and bring the result to the general counsel as a one-page note. That note states whether a matching TLD exists, whether names under it are in use and whether any of them could appear in a payment instruction. Everything else follows from those three answers.

If the answers point to an acquisition, this is the work Hush Partners does. The desk acts for organizations that mandate it to locate the holder of a TLD and make the approach, and each exchange takes place under a standard mutual NDA. A single named partner stays with the file from the first note through to closing, and closing is carried out through onchain escrow on an aftermarket. The fee is a fixed amount, not a percentage, and it is charged only to the client who gives the mandate. The page for general counsel and brand protection teams sets out how a file opens, and the contact form on the site is the only way in.

Questions people ask

Does holding an onchain TLD protect against look-alike domains in the DNS?

No. Onchain TLDs and DNS domains are separate systems. Holding .yourbrand onchain does not stop anyone from registering a similar domain name in the DNS, and holding your DNS domains does nothing onchain. The two exposures are managed separately, with different tools.

Can a financial institution use the UDRP to recover an onchain TLD?

No. The UDRP reaches registrants of domain names through their agreements with accredited registrars, and an onchain TLD sits outside that system. What remains is a negotiated acquisition, or proceedings against the holder, which depend on who the holder is and where they are. Trademark law may still apply to how a name is used, with rules that vary by country; your own counsel decides.

How does partial resolution affect the priority of this file?

It narrows where the exposure sits. Because ordinary browsers do not open onchain names without support, the exposure concentrates in wallet payment flows and agent identity, not in general web traffic. Priority depends on whether names under the TLD already point to addresses, and on how much of your customer and counterparty base uses wallets that support them.

Does the institution need digital asset activities for this to matter?

No. The exposure arises from the use of your name by others, not from your own product range. An institution with no digital asset business may conclude that its customers are less exposed, and that is a legitimate finding to record. Its counterparties and its clients’ systems may still meet a name that carries its identifier.