The end client — not the agency, and not the build partner — should hold the account that controls the domain and hosting on a white-label project, set up that way from day one. Get this wrong and a routine registrant-name correction later can trigger a 60-day inter-registrar transfer lock under ICANN's transfer policy, the exact moment a client can least afford to be stuck.
It's an easy detail to skip on a white-label build, because neither party in the room is technically the end client. The agency is focused on the relationship and the deliverable; the build partner is focused on shipping the work. Domain and hosting ownership sits slightly outside both of those jobs, which is precisely how it ends up registered under whoever happened to click "buy" first — usually the build partner, sometimes the agency, rarely the client whose business actually depends on it.
What "client-owned" means once you get specific
Ownership and day-to-day access aren't the same thing, and conflating them is where this usually goes wrong. The end client holds the root account — the login that can add or remove anyone else, and the one a registrar or hosting provider will recognise if there's ever a dispute. The agency still gets full administrative access to actually run the project, exactly as they would on any client engagement; nothing about day-to-day work changes. What changes is who's left holding the account if the agency's relationship with the build partner ends, or if the client eventually moves the work in-house or to someone else entirely. On our own white-label engagements this is the same setup we use for direct Malaysian clients, described in more detail in our handover checklist — we just apply it one layer removed, with the agency instructing which name the accounts go under instead of instructing us directly.
Why the timing matters more than the policy
The ICANN rule itself isn't unusual or vendor-specific — any registrar enforces the same 60-day hold after a registrant name, organisation, or email changes, as a standard anti-hijacking measure. The problem isn't the rule; it's discovering it exists only after a relationship has already soured and someone needs the domain moved quickly. A client who was set up correctly from the start never triggers that clock under pressure, because there's no registrant change left to make — the name on the account was theirs the whole time. Hosting doesn't carry the same formal transfer-lock rule, but the underlying exposure is identical: whoever's name and payment method sit on the account is the one who can lock everyone else out of it, and that's worth fixing before it's needed, not after.
Frequently asked questions
Doesn't the agency need admin access too, not just the end client?
Yes — ownership and access aren't the same thing. The end client holds the root account (the login that can add or remove anyone else), and the agency gets its own administrative access to actually run the project day to day. What changes is who's left holding the account if the agency or the build partner is no longer involved.
What happens if the domain was already registered under the agency's or a previous vendor's name?
It gets transferred into the end client's name as part of the handover, the same as any other ownership correction. The registrant-change step itself is the one to plan for, not skip past, because it's what starts a registrar's transfer-lock clock.
Why would a change of registrant information delay a domain transfer?
Under ICANN's transfer policy, updating the registrant name, organisation, or email on a domain triggers a 60-day hold on moving that domain to a different registrar, as an anti-hijacking safeguard. It's a real, well-documented rule, not a vendor stalling tactic — but it means an ownership correction started during a dispute can leave a client locked in for two months.
Does this apply the same way to hosting as it does to domains?
The transfer-lock specifics are a domain-registrar rule, but the underlying risk is identical for hosting: whoever's name and payment method is on the hosting account is the one who can lock everyone else out of it. We set both up in the end client's name at the same time, for the same reason.
Is this any different from how Techleet handles ownership on a direct Malaysian client project?
No — it's the identical client-owned-everything setup we use on every project we build directly, just applied one layer removed. The only thing white-label changes is that the agency, not us, is the one making sure it actually happens.