# Onchain TLDs and insurers: what to check
> A sector guide for insurers: 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-insurers
Category: Brand protection
Published by Hush Partners.
---
Insurance groups sit at a particular intersection of brand exposure and financial trust. A policyholder who receives a payment instruction, a renewal notice or a claim settlement already expects the transaction to feel slightly unfamiliar: a new portal, a new payment method, a new reference number. That expectation of novelty is the gap a readable onchain name can fill. A name like `claims.yourbrand` or `pay.yourbrand`, shown in a wallet or in a browser that supports it, reads as official to anyone who does not know what an onchain TLD is or how to check who holds it.
This article is for general counsel and heads of fraud at insurance groups. It maps the places where the exposure is specific to the sector, sets out which function inside the organization carries each piece of it, and gives a checklist that can be delegated the same day. It also describes what holding the TLD would let the organization do, because the file is not purely defensive.
After reading it, you will be able to brief a brand protection team on the risks that are particular to insurance, assign ownership of each check, and decide whether the onchain TLD that matches your name belongs on the legal agenda.
## Why insurance is not a generic brand problem
The background fits in a few lines. An onchain TLD is a top-level name, such as `.yourbrand`, recorded on a blockchain instead of in the ICANN DNS root. On the Freename registry, such a TLD exists as a token sitting in a wallet, it carries no yearly renewal charge, and names under it can be issued by its holder and by nobody else. Whoever holds `.yourbrand` therefore decides whether `claims.yourbrand` exists and where it points. For most brands, that is a question of confusion. In insurance, the problem is different in four ways.
**Policyholders are primed to receive payment instructions.** A life insurer, a motor insurer and a health insurer all send communications that ask customers to act: confirm an account for a settlement, follow a link to accept an offer, update contact details ahead of a payment run. Those communications arrive at moments when the policyholder is already engaged: after a claim, at renewal, after a life event. The customer is expecting a message and is under some pressure to answer it. A name under the insurer's TLD fits that moment without effort.
**The intermediary layer widens the surface.** Unlike a retail brand that sells directly, much insurance is distributed through brokers, tied agents, managing general agents and affinity partners. Each of those parties communicates under the insurer's name, or at least by reference to it. A name issued under a TLD the insurer does not hold, such as `broker.yourbrand`, `agent.yourbrand` or `renewal.yourbrand`, borrows the look of that layer.
**Customer protection duties attach to the name.** In general terms, and with differences between countries, supervisors of financial services expect an insurer to keep control of the channels that speak to customers in its name and to watch for impersonation. Onchain names are unlikely to appear on a standard compliance checklist, yet paying to a name is a working capability, as the page on [what works on onchain TLDs](/whats-live) documents with its sources. A supervised firm is usually expected to assess a new channel on its own initiative and not to wait for a rule that names it.
**Remedies that work in the DNS may not work onchain.** The UDRP, the dispute resolution procedure that registrars of ICANN domain names are bound to follow, does not extend to onchain TLDs, which sit outside the ICANN root. A trademark may still give an insurer grounds before a court, depending on the country, but identifying the person behind a wallet and enforcing a decision against a token are both uncertain. The practical consequence is that prevention, meaning knowing the position, watching it or acquiring the name, is more reliable than cure.
One limit belongs in the same picture. Onchain names do not open in an ordinary browser without support, and most policyholders have never used a wallet. The exposure described here is real where the customer or the intermediary does use one, and it is narrow elsewhere. A proportionate review says so, line of business by line of business, and does not treat every channel as equally exposed.
## Claims payments and premium collection
Claims settlement is where a readable payment name would be trusted most easily. A claimant who has just accepted a settlement is waiting for money. If a message arrives by any channel and carries a name like `settlement.yourbrand`, the name does the work of authentication. The claimant has no obvious way to know whether that name was issued by the insurer or by whoever holds a TLD the insurer does not.
The direction of the money matters. In a claim, funds flow from the insurer to the claimant, so a name that imitates the insurer is not used to receive the settlement itself. It is used to ask the claimant for something first: account details, identity documents, or a payment presented as a condition of release. Your fraud team will recognize the pattern from other channels. What changes is the credential: a name that ends in the insurer's own brand, which the claimant reads as the insurer.
Premium collection creates the exposure in the other direction. A policyholder asked to pay a premium to `renew.yourbrand` may well comply. The name is plausible and the request fits the moment. If the TLD is held by a third party who has issued that name, the funds reach a wallet the insurer does not control, and a payment made onchain is not reversed by a call to a bank. The policyholder then believes the policy is paid, which leaves the insurer with a cover dispute as well as a fraud report.
Three other payment flows deserve a line in the review, because they involve professionals who pay and are paid in volume:
- Suppliers in the claims chain, such as repairers, loss adjusters and medical providers, who receive payments from the insurer and are used to updating their payment details on request.
- Premiums collected by an intermediary and passed on to the insurer, where the instruction to change the destination comes, in appearance, from the insurer.
- Recoveries and settlements between insurers and reinsurers, where the amounts are large and the counterparties are few.
The capability is not hypothetical. [shaka](https://shaka.deal) is a payment router that works onchain: its payment links can pay out to a name where a raw address would otherwise appear, the parties agree and sign the split onchain before any funds move, and the router passes funds along without holding them. For an insurer, the point is simple. Paying to a name is something a wallet user can do, so the question of who controls the names under `.yourbrand` is a payments question as much as a trademark question.
The claims and treasury functions need to understand this specifically. It is not a cybersecurity question in the traditional sense, since no system of the insurer is touched. It is a question of whether the insurer's name, used as an onchain address, can point somewhere the insurer did not authorize. If the TLD is held by someone else, it can.
The same logic applies in reverse for a group that is considering [payments to a name](/onchain-tld-payments) as a channel of its own. The holder of the TLD is the only party that can issue names under it, so `claims.yourbrand` and `premiums.yourbrand` exist only if the insurer creates them and point only where the insurer sets them.
## Brokers, agents, and intermediaries
The intermediary distribution model is the sector's most distinctive structural feature for this analysis. An insurance group typically authorizes many firms and individuals to sell and service policies under its name or in close association with it. A policyholder who deals with a tied agent or a panel broker understands that the intermediary represents the insurer, at least in part. That understanding is what a look-alike name borrows.
Consider an invented example: a mid-sized general insurer with a regional broker network. Assume the insurer's name exists as an onchain TLD and that the insurer does not hold it. Names under that TLD are then issued by its holder, not by the insurer, and nothing technical prevents a name such as `broker.yourbrand` or `renewal.yourbrand` from existing. Such a name is hard to tell apart from a legitimate internal convention, because the insurer's own intermediary communications (emails, portals, renewal letters) use the same kind of functional label.
The insurer cannot easily see this without looking at the onchain namespace. An intermediary who receives a message that carries `broker.yourbrand` may forward it to customers before anything looks wrong. By then the payment instruction carries two endorsements: the insurer's name and the broker's own relationship with the customer.
This relay effect is why monitoring matters more here than for a brand that sells directly. A direct retailer's customer sees a doubtful name and decides alone. An insurer's intermediary may already have lent its credibility to the message before the customer ever sees it. It also means the people who need to recognize an unfamiliar name are not only your staff. They are the staff of firms you do not manage, whose training you influence only through distribution agreements and guidance notes.
Delegated authority adds a further layer. Where a managing general agent binds cover and handles claims in the insurer's name, the customer may never deal with the insurer at all. The agent's own trading name is then a second name to check, and the agreement between the parties rarely says who is responsible for watching it onchain.
The compliance position also differs from that of an ordinary brand. Depending on the country, an insurer may answer for the conduct of the representatives it appoints and for communications that customers could reasonably attribute to it. Whether a message built on `renewal.yourbrand`, sent by someone with no link to the insurer, creates any liability is a question for your own counsel. What can be said without legal analysis is that the name implies authorization, and that a complaint will reach the insurer first.
## Group structures and legacy brand portfolios
Large insurance groups are rarely monobrand. Acquisitions, demutualizations, joint ventures and market-by-market licensing have left most groups with a patchwork of trading names: a parent brand, one or more legacy brands kept after an acquisition, affinity or white-label names operated for distribution partners, and co-branded products. Each of those names could exist as an onchain TLD. Each is then a separate question to answer.
Geography compounds the complexity. A group that operates in several territories may use the same name in two markets under different legal entities, or may have sold the right to use a name in one territory while keeping it in another. The onchain namespace does not follow those lines. A TLD is a single token, and a name issued under it appears wherever onchain names resolve. Two unrelated insurers that share a name in different countries, each with a valid trademark at home, have one onchain TLD between them.
Legacy brands present a specific difficulty, and it comes from the length of the product. A policy can stay in force for decades after the brand that sold it stopped advertising. An insurer that acquired a recognized regional brand may no longer maintain trademark filings for it in every relevant class and territory, particularly if the brand is closed to new business. The brand team may not consider it a live exposure. Policyholders still associate their policies with it, and still expect letters, annual statements and eventually a payout under that name. A claims name under the legacy brand's TLD would carry the trust the original brand built, at the point where the group's own attention to that brand is lowest.
Run-off and closed books deserve their own line for the same reason. The customers are long-standing, contact is rare, and a message about a maturing policy or a transfer of the book to a new carrier is exactly the kind of unusual but credible event that a customer does not question.
To score how exposed each brand in the portfolio is onchain, a group can use the [Namespace Exposure Score](/namespace-exposure-score), which is a free tool. For a group with several trading names, scoring each name separately shows where the attention should go first, and gives the legal team a consistent way to compare a flagship brand with a legacy one.
The governance question is ownership: who inside the group is responsible for each legacy name? Intellectual property registers may be managed centrally or by territory. The onchain namespace is a separate layer that neither the IP team nor the compliance function may have mapped. The first task is to give that mapping to someone.
## What supervisors generally expect
This section stays general on purpose. Rules differ from one country to another, no rule is cited here, and your own counsel decides what applies to your group. What can be described is the common shape of the expectations that apply to any firm trusted with customers' money.
The general pattern is that an insurer is expected to ensure that communications sent in its name are authorized by it, to monitor for impersonation and take proportionate action when it is detected, and to show, when asked, that its controls over customer-facing channels match the risks it faces. Alongside that sits a duty to treat customers fairly, which usually covers warning them about known frauds that use the firm's name and handling the complaints of those who were deceived.
None of this was written with onchain names in mind, and it does not need to be. Expectations of this kind are framed around outcomes for the customer, not around a list of technologies. A supervisor who asks about impersonation is unlikely to accept that a channel was out of scope because no rule mentioned it. The useful test is therefore internal: can your risk function say whether the group's names exist as onchain TLDs, whether the group holds them, and who would notice a change?
An insurer that can answer has done what a proportionate control looks like, even if the answer is that the exposure is low and the decision is to watch. An insurer that cannot answer has a gap in its risk assessment, and the gap is the same whatever the exposure later turns out to be.
The review itself does not need to be public. The page for [general counsel and brand protection teams](/brands-and-legal-teams) sets out how a file of this kind is approached from the legal side.
## Exposure by function inside the organization
The risk does not sit in one place. Different functions carry different pieces of it, and the right response depends on who owns each piece.
| Function | Primary exposure | Nature of the risk |
|---|---|---|
| Claims | Payment misdirection | A name under the TLD used in messages to claimants or claims suppliers |
| Treasury and finance | Premium diversion | A name presented as the destination for a premium or a recovery |
| Distribution | Intermediary impersonation | A name that looks like an authorized broker or agent |
| Compliance | Supervisory accountability | No evidence that the channel was assessed |
| IP and brand protection | Enforcement gap | The UDRP does not apply; the TLD is absent from the IP register |
| IT and security | Monitoring gap | Onchain names may sit outside existing brand monitoring |
| Group legal | Legacy names | Acquired and closed brands never checked onchain |
| Customer communications | Customer confusion | No agreed wording on which names the insurer uses |
Read the table as a map of questions, not of incidents. Its use is to make sure that each function knows which row is its own before the checks below are handed out.
## A checklist of nine checks, with the function that owns each
The nine checks run in sequence, and every one of them builds on what the previous check returned. The first three establish the facts, the next four test the organization against them, and the last two turn the findings into a decision. None of them requires outside help or discloses anything to a third party.
Onchain TLD checks for an insurance group
List every trading nameList each name under which the group or its subsidiaries deal with customers, including legacy brands, co-brands and affinity labels. Include names closed to new business that still appear on in-force policies. Owner: group legal or IP.
Check each name as an onchain TLDRun each name on the list through the free Trademark Name Check form on the trademark TLDs page. Where a TLD exists, its registry record is public and can be read on a block explorer. Owner: IP or brand protection.
Score the exposure of each nameUse the Namespace Exposure Score for each name and keep the results side by side, so that the flagship brand and the legacy brands can be ranked. Owner: brand protection, with IT security.
Map the intermediary naming conventionsRecord how brokers, agents and delegated authorities are labelled in portals and letters. Note which labels a customer would accept without question as a name under the insurer's TLD. Owner: distribution compliance.
Review payment communicationsRead the wording used in claims settlement, renewal and premium collection messages. Check that each one tells the customer which channels and names the insurer uses to ask for or announce a payment. Owner: claims operations and treasury.
Check the trademark registerConfirm that registrations in the relevant classes and territories cover each name on the list. Flag any name whose registration has lapsed or was never filed where policies are still in force. Owner: IP counsel.
Check what the group has told its supervisorsEstablish whether any statement made to a supervisor, or any open review, describes the group's control over customer-facing channels. If so, decide with counsel whether onchain names fall within it. Owner: compliance.
Assign the onchain fileName the function that holds the file from now on, usually group legal or IP, with input from IT security, fraud and compliance. Owner: general counsel.
Decide per name: acquire, watch or acceptFor each name, choose between acquiring the matching TLD, placing it under monitoring, or accepting the position. Record the decision, its reasons and a review date. Owner: general counsel and IP.
A group with a handful of trading names can complete the first three checks in a day. The four in the middle depend on other functions answering, and their pace is the pace of the slowest of them, which is the reason to assign an owner early.
## Options and who should own the file
Once the exposure is mapped, the insurer has three broad options, which are not mutually exclusive across a portfolio of names.
**Acquire the TLD.** [Brand namespace recovery](/brand-namespace-recovery) is the service through which an organization acquires the onchain TLD that matches its brand. Hush Partners works under a standard mutual NDA that applies to every exchange, a single named partner stays with the file from the first note to closing, and closing runs through onchain escrow on an aftermarket. For an insurer, the practical value is that its own staff do not make the approach.
**Monitor.** If acquisition is not the right step for a given name, because the group is still deciding which of its many names to prioritize or because the exposure of that name is assessed as low, [Namespace Watch](/namespace-watch) is the service that monitors the names of a brand onchain. Monitoring is the sensible interim measure for any name the insurer does not hold, and it gives the fraud team something to act on.
**Accept the position.** This is a decision, not a default. If the group has assessed the exposure, recorded its reasoning and named someone to revisit it, that is a defensible position. If no one has assessed it, doing nothing is an undocumented gap. The difference matters if a supervisor asks.
A group with many names will usually combine the three: acquire for the parent brand and the names used in payment flows, monitor the legacy brands with books still in force, and accept the position for names that no customer still meets.
The file should sit with general counsel or the head of IP, with input from compliance and IT security. It is a brand and legal risk with a technology dimension, not a technology project. Given to IT alone, it tends to become a monitoring setup with no authority to act on what it finds.
The head of fraud has a distinct role. Fraud teams already run the processes that would catch a misuse: customer reports, intermediary reports, payment anomaly review. The file owner should make sure those processes know what an onchain name looks like and where to send one. No new team is needed for that, only a line in the existing escalation path.
## What holding the TLD lets the organization do
The defensive case for acquiring the TLD is clear. The affirmative case is worth stating separately, with its limits.
An insurer that holds its own onchain TLD decides which names exist under it. It can issue `claims.yourbrand`, `renew.yourbrand` and `broker.yourbrand` for operational use and point them at wallet addresses or payment routes it controls. A payment channel built on those names does not carry the impersonation risk that a TLD held by someone else creates.
For intermediary management, the TLD offers a namespace for authorized distributors. A broker given a name under `.yourbrand` holds something that only the insurer could have issued. The logic is the one an insurer already applies when it gives an agent an address on its own DNS domain, with one addition: the registry record is public, so a counterparty can check on a block explorer who holds the TLD. When an appointment ends, the name is part of what has to be withdrawn, and that step belongs in the off-boarding process.
The limits are plain. A policyholder or a broker can use a Freename name only where it is supported: in Bitcoin.com Wallet, in MetaMask via the resolver Freename provides, and in a desktop browser once the Freename Web3 extension has been installed. That coverage is partial and it changes. For a customer portal, for email and for anything a policyholder must reach from an ordinary browser, the DNS is simply the better tool, and an onchain name complements it without replacing it.
Automated agents are a further use, and a less settled one. Insurers that use software agents in claims triage or customer contact will at some point need those agents to be identifiable by counterparties. ERC-8004, "Trustless Agents", is a draft Ethereum standard that may still change. It describes three registries: one for identity, one for reputation and one for validation of an agent's work. How naming registries connect to it is still evolving, so this is a subject to follow and not a reason to act. The page on [post-transfer activation](/post-transfer-activation) describes how a TLD is put to work once it has been transferred.
The group function best placed to see both the defensive and the affirmative value is general counsel, working with IP and whoever leads digital and payments. The affirmative case is what turns a compliance file into a business case. As a next step, hand the first three checks of the list above to your brand protection lead with a date, and decide on the rest when the results are on your desk.
## Questions people ask
### Does a registered trademark give us the right to recover the TLD?
Not by itself. Onchain TLDs sit outside the ICANN DNS root, so the UDRP is not available. A trademark may support a claim before a court, but that depends on the country, the facts and the holder, and it is a question for your own counsel. In practice, the path is usually a negotiated acquisition. The page on [trademark TLDs](/trademark-tlds) explains what a trademark TLD is and holds the free Trademark Name Check form.
### How is a holder approached without our staff making contact?
An organization can mandate Hush Partners to find and approach a holder on its behalf. The standard mutual NDA covers each exchange, and a single named partner follows the file to closing. The [rules of engagement](/rules-of-engagement) set out the rules the desk works by.
### Do onchain names actually resolve for ordinary users?
Only with support. A standard browser does not open them, and the wallets and extensions that do are a partial and changing set. That narrows the exposure and does not remove it: a customer or an intermediary whose wallet supports these names can pay to one, whether or not the name opens anywhere else.
### Is this relevant only for consumer-facing lines of business?
No. Commercial lines and reinsurance also involve payment flows, intermediaries and communications in the insurer's name. A managing general agent working under delegated authority, or a cedant expecting funds from a reinsurer, faces the same question of whether a name can be trusted as a retail policyholder does. That is why the exposure table is organized by function and not by line of business.