Page History

Note: This is a pilot information repository page for Registrars. The information contained in this repository are extracts of the full policies/requirements, and are put together for the purpose of capacity development for Registrars.  They act as a supplement to the actual policies, and will be updated from time to time. To implement the full requirements, and for the latest policy information, please always refer to the relevant policy pagedocument provides a summary of registrar requirements related to the Transfer Policy as stated in the link below. The summarization of terms within this document do not override or replace the terms set forth within the stated policy. Please refer to the full text of the policy to review and understand the requirements for registrars.

Full Policy at: https://www.icann.org/resources/pages/transfer-policy-2016-06-01-en

This section covers the following:

Change of Registrant (Section II)

Definitions:

• Change of Registrant - Material Change to:

1. 1. Prior Registrant Name; OR
   2. Prior Registrant Organization; OR
   3. Prior Registrant email address; OR
   4. Administrative Contact email address, if there is no Prior Registrant email address.

• Prior Registrant –registered name holder (RNH) when change is initiated
• New Registrant – entity or person to whom the Prior Registrant proposes to transfer its domain name registration
• Material Change - means a non-typographical correction:

1. 1. A change to the Registered Name Holder’s name or organization that does not appear to be merely a typographical correction;
   2. Any change to the Registered Name Holder’s name or organization that is accompanied by a change of address or phone number;
   3. Any change to the Registered Name Holder’s email address.

• Prior Registrant –registered name holder (RNH) when change is initiated
• New Registrant – entity or person to whom the Prior Registrant proposes to transfer its domain name registration
• Material Change - means a non-typographical correction:

Availability of Change of Registrant:

...

- Registrar must deny request for change of registrant if:

1. 1. Registration agreement has expired, and registrant no longer has the right to renew or transfer the domain name to another registrar,
per ERRP
2. 1. per  Expired Registration Recovery Policy (ERRP)
   2. Change of Registrant was not properly authorized by the Prior Registrant and the New Registrant
   3. Domain name in dispute (e.g., URS, UDRP, TDRP, court order)

Change of Registrant Process

...

(3)  Inform the Prior Registrant (or Designated Agent) that if its final goal is to transfer the domain name to a different registrar, advised to request the inter-registrar transfer before the Change of Registrant to avoid triggering the 60-day lock described in II.C.1.2 (unless registrar gave Prior Registrant option to opt out, and Prior Registrant opted out of the 60-day lock)

...

(6)  Notify the Prior and New Registrant per II.C.1.1.6

(7)  Lock name (if applicable) per II.C.2

Change of Registrant process (section II.C, .1.1) does not apply to following situation:

1. 1. Registration agreement expires
   2. Registration agreement is terminated by the registrar
   3. Registrar or registry updates the prior registrant’s information pursuant to a court order
   4. Update per UDRP decision implementation
   5. Update per Expired Domain Deletion Policy
   6. Updates in response to an abuse complaint

Registrar Notification to Registered Name Holder (Section II.C)

• 1.1.2  and 1.1.4 –

• • inform the New Registrant that it must enter into a registration agreement with the Registrar;
  • include instructions on how to approve or cancel the Change of and inform the Prior Registrant and New Registrant that the request will not proceed if it is not confirmed in a number of days set by the Registrar, not to exceed sixty (60) days;      
• 1.1.6 -
  • 1.1.6.1 – always be sent to both the New Registrant and Prior Registrant before or within one day of the Change of Registrant;
  • 1.1.6.2 - explain the request that was received and list the domain(s) in question;
  • 1.1.6.3 - include contact information for questions.
  • 1.1.6.4 – inform the New and Prior Registrant of 60-day lock (if applicable); or advise the Prior Registrant that it previously opted out of the 60 day lock

...

60-day Inter-Registrar Transfer Lock (II.C.2)

• Registrar must impose 60-day inter-registrar transfer lock following Change of Registrant;
• Registrar may offer “opt-out” option of the lock to the Prior Registrant, prior to the change of registrant request;
• Registrar may not need to impose the Registrar Lock, if it offers an “opt-out” option, and the Prior Registrant has opted-out of the lock.

Inter-Registrar

...

Transfer  (Section I.A.1-4) 

Transfer Authorities (Transfer Contact)

...

• Registrar must receive confirmation from the Transfer Contact before moving forward.
• The Gaining FOA shall expire until either one of the following conditions (Section I.A):

a. 2.2.3.1 a period of sixty (60) days has passed since the FOA was issued by the Gaining Registrar, unless the Gaining Registrar allows automatic renewal of the FOA and the Registered Name Holder has expressly opted in to the automatic renewal;

...

• In the event the RNH preapproves a transfer, the Registrar has the option of sending a modified version of the FOA, which informs the RNH that the preapproved transfer has been initiated.
• If the losing registrar does not receive a confirmation from the Transfer Contact, and the registrar has not explicitly denied the transfer request, after five (5) calendar days, the default action will be that the registrar must allow the transfer to proceed. It’s a default "approval" of the transfer.
• The Losing Registrar MAY deny (NACK) a transfer request based on any of the following reasons: (Section I.A.3.7)

a. 3.7.1 Evidence of fraud.

...

• The Losing Registrar MUST deny (NACK) a transfer request in any of the following circumstances: (Section I.A.3.8)

a. 3.8.1 A pending UDRP proceeding that the Registrar has been informed of.

...

• Registrars will establish a Transfer Emergency Action Contact ("TEAC") for urgent communications relating to transfers. The goal of the TEAC is to quickly establish a real-time conversation between registrars (in a language that both parties can understand) in an emergency. Further actions can then be taken towards a resolution, including initiating existing (or future) transfer dispute or undo processes.
• Communications to TEACs will be reserved for use by ICANN-Accredited Registrars, gTLD Registry Operators and ICANN Staff. The TEAC point of contact may be designated as a telephone number or some other real-time communication channel. Communications to a TEAC must be initiated in a timely manner, within a reasonable period of time following the alleged unauthorized loss of a domain.
• Messages sent via the TEAC communication channel must generate a non-automated response by a human representative of the Gaining Registrar. Responses are required within 4 hours of the initial request, although final resolution of the incident may take longer.
• Failure to respond to a TEAC communication may result in a transfer-undo in accordance with Section I.A.6.4 of this policy and may also result in further action by ICANN.
• Both parties will retain correspondence in written or electronic form of any TEAC communication and responses, and share copies of this documentation with ICANN and the registry operator upon request.

Requirements for the "ClientTransferProhibited" Status and "AuthInfo"

...

Codes (Section I.A.5)

• Registrars may only impose a "ClientTransferProhibited" status for a domain name upon registration or subsequent request by the RNH, if it includes in its registration agreement the terms and conditions for imposing such status and obtains consent from the Registered Name Holder
• Registrars must remove the "ClientTransferProhibited" status within five (5) calendar days of the Registered Name Holder’s initial request and provide the Registered Name Holder with the unique "AuthInfo" code. (if the registrar does not provide facilities for the Registered Name Holder to generate their own “Authinfo” code and to remove the “ClientTransferProhibited” status).
• Registrars may not employ any mechanism for RNH’s request to remove the "ClientTransferProhibited" status or obtain the applicable "AuthInfo Code" that is more restrictive than the mechanisms used for changing any aspect of the RNH's contact or name server information.
• Registrar-generated "AuthInfo" codes must be unique on a per-domain basis.
• “Authinfo” codes must be used solely to identify a RNH.
• The registrar may not refuse to remove “ClientTransferProhibited” status or release an “Authinfo Code” solely because there is a dispute over payment.

ICANN Approved

...

Transfer (Section I.B)

• Registrar can transfer all its sponsored registrations to another registrar as the result of:

...