# Onchain TLDs and payment companies: what to check
> A sector guide for payment companies: why a TLD matching the name matters here, where the exposure sits, and a short list of checks.
Source: https://hush.partners/onchain-tlds-and-fintech-and-payment-companies
Category: Brand protection
Published by Hush Partners.
---
A payment company's name is not just a brand. It is the thing a customer types, taps or looks for when they want to send or receive money. That distinction changes how a risk function should read onchain top-level domains, in ways that a standard brand protection review does not capture.
An onchain TLD is a top-level domain recorded as a token on a public blockchain, outside the ICANN DNS root. Whoever holds the token controls the TLD, and on Freename nobody but that holder can issue names under it. If your company's name exists as `.yourbrand` onchain and your organization does not hold it, names such as `pay.yourbrand` or `merchant.yourbrand` can be issued and pointed at wallets you have never seen. For a consumer goods brand the harm of that would be mostly reputational. For a payment company, a name that resolves to a wallet is a working payment destination. The namespace and the product surface overlap.
This guide is written for the chief compliance officer or head of risk at a payment or fintech company. It maps the exposure that is specific to the sector, shows which internal function owns each part, and ends with a checklist that can be delegated the same day.
## Why payment and fintech companies sit in a different risk category
Most brand protection frameworks assume that a brand's job is to bring customers to a legitimate product, and that the harm of imitation is confusion about who is selling. In payments, the brand does more than attract. It is the label on the channel through which funds move.
When a customer sees `pay.yourbrand` offered as a destination in a wallet, the question in their mind is not whether a logo is genuine. They are deciding where money goes. The name carries an implied statement: this destination belongs to the company, and money sent to it will arrive where the company says it will. If a third party holds `.yourbrand`, that party decides which wallet `pay.yourbrand` points to, and the customer has no simple way to see the difference before confirming.
Compare this with a manufacturer facing a seller of imitation goods behind a look-alike web address. The manufacturer's exposure begins when the customer discovers the imitation, and there is usually a product, a seller and a payment intermediary to turn to. The payment company's exposure sits at the moment of the transaction itself. A transfer on a public blockchain is final once it is confirmed. There is no intermediary to reverse it, and the first place the customer goes with the problem is your support queue.
Three features of the sector compound this.
First, habit. Your customers have typed, searched and tapped your name many times. A habit formed in a conventional payment app travels with the person into a wallet, where the same name looks just as familiar.
Second, expectation of care. A payment company is expected to know where money sent in its name ends up. "That name was not ours" is a true answer, but it is not a comfortable one to give to a customer, a banking partner or a supervisor, and it invites the follow-up question of whether you knew the name existed.
Third, the product itself. A retailer has no use for a payment name beyond its checkout. A payment company's whole offer is the reliable movement of money to a named recipient. The same namespace that creates exposure when someone else holds it is, in your hands, a piece of product infrastructure. Both sides of that are covered below.
A first reading of where your name stands takes little effort: the [Namespace Exposure Score](/namespace-exposure-score) is a free tool that scores how exposed a brand is onchain, and it gives the working group a common starting point.
## A customer base already comfortable with wallets and readable payment names
The users of a payment or fintech company are not a cross-section of the general public. They have already chosen digital financial tools, they are used to handling account identifiers on a screen, and some of them hold a self-custody wallet alongside your app. That comfort is a commercial asset. It is also why the namespace question matters more here than in most sectors.
Fintech products have taught people that a readable identifier is the safe way to pay. Handles, aliases, phone numbers and short tags replaced long account numbers precisely because long strings cause errors. The lesson customers took from that is simple: if the name is right, the payment is right. Onchain names work on the same promise, and a customer trained by your own onboarding will extend to `pay.yourbrand` the trust they give to an alias inside your app.
The difference is who stands behind the identifier. Inside your app, you issue the alias, you verified the account behind it, and you can correct a mistake. Under an onchain TLD, the name resolves because the registry's smart contract (a program on the blockchain that applies its rules automatically) says it does, and the record was written by whoever holds the TLD or the name. The signals that customers have learned on the web, such as a browser padlock or a support line that can freeze a payment, do not carry over in the same form.
This is not a remote possibility. A [payment to a name](/onchain-tld-payments) works where the wallet or payment tool supports the registry. Freename names can be used in Bitcoin.com Wallet, in MetaMask once Freename's resolver is added, and in desktop browsers that run the Freename Web3 extension. That coverage is partial and it changes, so the absence of a name from one wallet says little about whether it is usable in another.
The honest limit belongs here as well. A customer who never leaves your app and never opens a wallet is not reached by any of this. The exposure concentrates in the part of your base that uses both, and that is the part most likely to act on a familiar name without a second look.
## The company's name as a payment destination by design
On the web, a domain name mainly leads to a website. An onchain name can do that too, but one of its first uses is to stand in for a wallet address. That is what puts a payment company in a particular position: the function a name performs onchain is the function your company sells.
A payment router shows the point concretely. [shaka](https://shaka.deal) is an onchain payment router in which a payment link can pay out to a name rather than a raw address. The parties agree the split and sign it onchain before any funds move, and the router passes funds along without holding them. The consequence for you is plain. Where a tool accepts a name as the destination, the wallet behind a name under `.yourbrand` is chosen by whoever controls that name, and the right to issue names under the TLD sits with whoever holds the TLD.
Your sector has put real effort into one particular control: making sure the name a payer sees corresponds to the account that receives. Customers have come to expect that a mismatch will be caught for them. Under an onchain TLD that you do not hold, there is no equivalent control that you operate. The name and the wallet match by definition, because the holder of the name set the wallet.
Consider a scenario with invented parties. A mid-sized payment company finds that a TLD matching its name is held by someone else, and that names such as `support.yourbrand` and `refunds.yourbrand` have been issued under it. A long-standing customer comes across one of those names, takes it for an official destination, and sends funds. Nothing in the wallet told the customer that the company did not issue the name. The compliance team first hears about it through a complaint, and has to explain to the customer, and possibly to its banking partners, what its relationship to that name is.
The scenario says nothing about the intentions of any holder. A TLD may well be held by someone who registered a word early and has issued nothing under it. The point is narrower: when the name is a payment destination, your risk function needs to know who can issue under it, and what has been issued, before a customer asks.
The scenario also shows why the question cannot be left to the trademark team alone. For general counsel and brand protection teams, the [audience page for legal teams](/brands-and-legal-teams) sets out how the subject looks from that side. In a payment company, the same facts are also a question for compliance, because a name that resolves to a wallet touches the flow of customer funds.
## Partners, merchants and agents acting under the brand
Payment companies are networks. Merchants accept your product. Agents onboard and serve customers in places where you have no branch. Program partners offer your service inside their own. Each of these parties has a legitimate reason to present itself in connection with your name, and each is a point where a customer must decide whether the party in front of them is really part of your network.
You already manage this in the conventional world. You run due diligence before a merchant or agent is onboarded, you keep a register of who is authorized, and you remove a party when the relationship ends. The onchain namespace asks the same three questions in a new place: who may present under the name, how a customer can tell, and what happens at offboarding.
If you hold `.yourbrand`, the answers are yours to give. You can issue `merchant.yourbrand` or `agent.yourbrand` to parties that have passed your onboarding, tie each issuance to the contract that governs the relationship, and publish the rule that a name under your TLD comes from you. Because issuance under a Freename TLD is reserved to the holder of the TLD, that rule is not only a policy. It is how the registry works.
One caution on offboarding. What can be done with a name after it has been issued depends on the registry's terms and on how the name was issued. Check that point before you tell partners or your own compliance committee that a name can be withdrawn, and write the answer into the partner contract instead of assuming it.
If you do not hold `.yourbrand`, the position reverses. You cannot give a partner a name under your own brand, because issuance belongs to someone else. You also cannot state the simple rule that customers could rely on. Worse for a network business, a name that looks like an agent or merchant designation can exist without that party ever having passed your onboarding.
This weighs most where customers meet your brand through intermediaries. If the first contact a customer has with your service is an agent, their confidence in the payment rests on that agent's standing. Your agent register answers the question inside your systems. Only the holder of the TLD can answer it in the namespace.
## Why holding the namespace is a product opportunity as much as a defense
The defensive case for acquiring `.yourbrand` follows from the sections above. The product case is separate, and in this sector it is often the stronger of the two.
Payment products compete on how easily a payer can reach the right recipient. A TLD that matches your name gives you a family of readable destinations that you alone issue: one for each merchant, agent, corporate client or internal function. The payer sees a name that your organization has issued to a party it has checked, instead of a long string that must be copied without error. That is the same improvement your sector delivered when it replaced account numbers with aliases, applied to wallets.
There is also a direct financial element. Freename runs a royalty program under which a share of every registration fee paid for a name under a TLD goes to that TLD's holder. Freename advertises that share at up to half, and what a payment company would receive depends on the registry's current terms and on activation conditions. The income is not free of cost either: the TLD has no annual renewal fee, but taking part in the royalty program carries an annual cost that the registry sets. On a TLD bought from an earlier holder, the registration may date from older terms under which the program is included for life, which is true of some TLDs, and your deal team should confirm with the registry before closing whether those terms pass to a buyer. A payment company is unlikely to acquire its own TLD for that income, and names you issue to your own partners are a governance tool before they are a revenue line. It still belongs in the business case, and it should be read against the registry's terms at the time, not assumed.
A third element is still forming. ERC-8004, called "Trustless Agents", is a draft Ethereum standard, and as a draft it may change. It describes three registries for AI agents: an identity registry, in which each agent is an ERC-721 token that points to its agent card, a reputation registry that collects feedback from those the agent has worked with, and a validation registry for independent checks of its work. How naming registries connect to it is still evolving. For a company that expects software agents to initiate or receive payments, a name under its own TLD is a candidate way to label those agents. It is a possibility to watch, not a capability to plan a launch around.
The practical conclusion is about sequence. If the product case is real, it should shape the acquisition, not follow it. The [work of putting a TLD to use after the transfer](/post-transfer-activation) is easier to scope when product, compliance and partnerships have already agreed what the names are for.
## Exposure by function inside the organization
The exposure does not sit in one team. It runs through compliance, legal, brand protection, product and partnerships at once, which is the main reason it tends to be owned by nobody.
| Function | Primary exposure | Secondary exposure |
| --- | --- | --- |
| Compliance and risk | Names under the brand resolving to wallets nobody has verified | Questions from customers and supervisors it cannot yet answer |
| Legal and IP | Limited reach over names issued under a TLD it does not hold | A harder file if the holder has acted in good faith |
| Brand protection | Names that look authorized and are not | No alert, because DNS monitoring does not see them |
| Product and payments | No readable payment identity under its own name | Design choices made without the namespace |
| Partnerships | No way to issue names to merchants and agents | Partners using raw addresses with customers |
Two functions are missing from the table and should be in the room. Customer support receives the first complaint and needs a prepared answer on which payment names are official. Treasury and operations need to know that any name the company itself publishes for incoming payments is one whose wallet it controls.
## Where resolution stops, and what that means for a risk rating
Onchain names do not live in the ICANN DNS root. An ordinary browser will not open them unless support has been added, and wallet support covers some wallets and not others. A risk function should record this accurately in both directions.
It limits the exposure. Most of your customers, on most days, reach you through your app and your website, both of which rest on the DNS. For those channels the DNS is simply the better system: it resolves everywhere, it has established dispute procedures, and your security controls are built around it. Nothing in this guide suggests moving official channels away from it.
It does not remove the exposure. The customers who can use an onchain name are the ones holding a wallet, which is the group for whom a name is a payment destination. A rating that says "low, because few browsers resolve it" measures the wrong thing. The relevant measure is how many of your customers could pay to such a name, and what they would assume when they saw it.
It also changes. Coverage in wallets and browsers moves, so a check made once is a snapshot. The page that lists [what works with onchain TLDs](/whats-live), with sources, is the reference to revisit when the file is reviewed.
One more property matters for a compliance file. The registry record is public, and anyone can read it on a block explorer, a website that displays blockchain records. You can see which wallet holds a TLD and what has been issued under it. The record shows a wallet, not a person or a company, and it is equally visible to anyone else who looks.
## A checklist of ten checks, with the function that owns each
The checks are ordered so that the first four can be completed without contacting anyone outside the organization.
Namespace checks for payment and fintech companies
Find out whether your name exists as an onchain TLDUse the free Trademark Name Check and the Namespace Exposure Score for the company name and for each product name customers use to pay. Owner: brand protection or legal.
Read what has been issued under itA block explorer shows the TLD's registry record, which is public, to whoever looks it up. Note which names exist under the TLD and whether any of them point to a wallet. Owner: brand protection, with technology.
Compare issued names with your payment surfaceLook for names that mirror how customers pay or get help: pay.yourbrand, send.yourbrand, support.yourbrand, merchant.yourbrand. The test is confusion at the moment of a payment decision, not general resemblance. Owner: compliance.
Record what the public facts show about the holdingNote what the record shows: whether names have been issued, what kind, and whether anything uses your marks. Do not draw conclusions about intent from the record alone. Owner: legal.
Restrict the file and put confidentiality in placeName the working group and agree that nobody contacts a holder directly. Any exchange with Hush Partners takes place under its standard mutual NDA. Owner: legal.
Map merchants, agents and partners against the namespaceList the names you would issue to your network if you held the TLD, and check whether any already exist under it. Owner: partnerships, with compliance.
Prepare the customer-facing positionDecide what support says when asked whether a payment name is official, and where the list of official payment destinations is published. Owner: compliance and customer support.
Test the product case before choosing an optionAsk product what the company would issue and to whom. The Subname Revenue Calculator estimates revenue from names issued under a TLD, and the Launch Roadmap sets out the steps of a launch. Owner: product and finance.
Take legal advice on the instruments availableTrademark rights are the usual starting point. Their reach over an onchain TLD varies by country and by the facts, and your own counsel decides what applies. Owner: legal.
Set up monitoring and name a long-term ownerA single check says nothing about names issued later. Put onchain monitoring in place and assign the file to one person who reviews it on a schedule. Owner: a named lead in compliance or legal.
Check seven is the one most often skipped, and it costs the least. Publishing the official list of payment destinations on your DNS website, where customers already trust what they read, gives support a fixed reference and gives customers a way to verify a name whatever happens in the namespace.
## The options, and who should own the file
Once the checks are done, a payment company that finds its name as an onchain TLD in someone else's wallet has three courses open. They are not exclusive, and the first checks usually show which one leads.
**Acquisition.** Where the product case is real, or where the names already issued touch the payment surface, acquiring the TLD is the most complete answer. It ends the uncertainty about who can issue, and it gives the organization the namespace to use. An organization can mandate Hush Partners to locate the holder and make the approach on its behalf, which is the purpose of [brand namespace recovery](/brand-namespace-recovery). Closing takes place through onchain escrow on an aftermarket. The desk's fee is a fixed amount and never a percentage, and it is paid only by the client who gives the mandate. A holder who answers the desk's note pays no fee.
**Monitoring.** Where nothing troubling has been issued, or where acquisition is not possible for now, [monitoring the brand's names onchain](/namespace-watch) gives the risk function a view of what appears. It does not replace holding the TLD. It shortens the time between a name being issued and your team knowing about it, which for a payment company is the time during which a customer could act on it.
**Legal instruments.** Where a registered mark covers the name and the facts support a claim, enforcement may be available. The UDRP, the dispute policy that registrants of ICANN domain names accept when they register, binds those registrants and does not extend by itself to a registry outside the ICANN system. What remains depends on the country, the registry's own terms and the conduct in question. This is a matter for your own counsel. Hush Partners is not a law firm and nothing here is legal advice.
### Who owns it
The file needs one named owner with authority across all three options. In a payment company that person usually sits in compliance or legal, for a reason specific to the sector: the trigger for action is likely to be a customer payment, not a trademark notice, and the function that handles payment incidents must be able to move without first locating the file.
A workable arrangement uses the structure you already have. The business functions (product, partnerships, support) own the day-to-day items: the list of official names, the partner mapping, the customer wording. Compliance and risk own the rating, the monitoring alerts and the entry in the risk register. Legal owns the instruments and any mandate. Internal audit can then test the file like any other control. Left with brand protection alone, the file tends to be treated as a trademark matter. Left with product alone, it is treated as a feature. It is both.
## What a payment company can run under its own TLD
Holding `.yourbrand` removes an uncertainty. It also gives the organization things it cannot build any other way.
**A single rule customers can rely on.** "A payment name ending in `.yourbrand` was issued by us" is a rule that fits on one line of a help page. It is checkable, because the public record shows that names under the TLD come from the wallet that holds it. You can publish that wallet's address on your DNS website so that customers, partners and supervisors can tie the record to your organization.
**Named destinations for the whole network.** Merchants, agents and corporate clients can each receive a name, issued after your onboarding checks. In any wallet or payment tool that supports the registry, that name is how they are paid. Your authorized-party register and your namespace then say the same thing, and a discrepancy between them becomes a control finding instead of a customer loss.
**Names for your own functions.** Collections, refunds, payouts and treasury can each have a published destination. That is the direct answer to the scenario described earlier: the official name for a refund exists, the company issued it, and support can point to it.
**A foundation for what comes next.** If agent identity standards mature, or if more wallets resolve the names, the organization that holds its TLD decides how to take part. An organization that does not hold it has to ask.
None of this requires moving anything away from the DNS, and none of it works everywhere. It works where the registry is supported, and it should be presented to customers in those terms.
The next step is small. Run the Trademark Name Check, which sits on the page explaining [what a trademark TLD is](/trademark-tlds), and the Namespace Exposure Score, then hand the ten checks above to the functions named in them. If the checks show that your name exists as an onchain TLD outside your organization and you want the holder approached, the desk is reached through the [contact form](/contact) on the site, and one named partner follows the file from the first note to closing.
## Questions people ask
### Does acquiring the TLD give control over names already issued under it?
Acquiring the TLD gives the right to issue names from then on. Names issued earlier fall into two groups. Those the seller holds itself can be transferred together with the TLD, by agreement between the parties, so they can be made a subject of the negotiation. Those sold to third parties sit in other wallets and remain theirs. Reading what has been issued is therefore part of the review before any acquisition. Your own counsel advises on the terms.
### Should a payment company publish payment names before resolution is widely supported?
Only where it can say clearly where they work. A name that some customers can use and others cannot is a support question in the making. A cautious sequence is to hold the TLD, publish the rule that names under it come from them, and introduce named destinations for a defined group first, such as partners who already use wallets, before any general launch.
### Is a name under `.yourbrand` the same thing as a website address?
No. A name under an onchain TLD can stand in for a wallet address, and it can also lead to a website if it is set up to do so. These are separate capabilities, and each works only where the wallet or browser supports the registry. For a payment company, the first is the one that matters to the risk assessment.
### What changes if more wallets come to resolve these names?
The number of your customers who could pay to a name under `.yourbrand` rises, and so does the usefulness of the namespace to whoever holds it. Nobody can promise that resolution will become universal, and this guide does not. The sensible response is to review the file on a schedule, not to forecast.