ICANN Contractual Compliance Complete Email Trail

On Fri, Jul 11, 2025 at 1:26 AM ICANN-No Reply <[email protected]> wrote:

Dear TAI CHIEW WONG,

Thank you for submitting a complaint to ICANN Contractual Compliance.

The case number that has been assigned to your complaint is 01448650. Please take note of this number as you may need to refer to it in future communications with ICANN.

Upon completing review of your submission, ICANN Contractual Compliance will send you a confirmation that your complaint is under process or will request any additional information or evidence needed to assess your complaint.

ICANN’s authority extends to the enforcement of the requirements outlined in the agreements that it has with its contracted parties, registrars and registry operators. If the issue described in your complaint is outside the scope of these agreements, you will receive an explanation as to why it is not within ICANN’s authority to address your complaint, along with suggestions of alternative avenues which you may wish to pursue.

Information about the process ICANN follows to address each complaint, including turnaround time, is available here:

https://www.icann.org/resources/pages/approach-processes-2012-02-25-en

Sincerely,

ICANN Contractual Compliance

Subject: Case Number 01448650 – Additional information for Reserved Names complaint re: [ ref:!00D6106tJk.!500Rm0ouQhV:ref ]

————————

From: ICANN Contractual Compliance <[email protected]>
Date: Wed, Jul 16, 2025 at 10:52 AM
To: [email protected] <[email protected]>

Dear TAI CHIEW WONG,

Thank you for submitting a Transfer complaint concerning the domain name malaysia.build. Although your complaint is invalid for the complaint type selected, it may be processed as a Reserved Names complaint. To make that determination, ICANN is requesting additional information.

Please note that the information displayed through the Registration Data Directory Service (also known as WHOIS) for the domain name malaysia.build indicates: “This domain has been reserved by the registry, and is not available for registration.” To confirm this information, you may perform a WHOIS search using the registry operator’s web-based service at https://whois.nic.build/.

According to Section 3.3 of Specification 5 of the registry agreement (RA) for the TLD .build, the registry operator may withhold from registration at all levels domain names that are not activated in the Domain Name System (DNS) and release them for registration to another person or entity at the registry operator’s discretion. Please note that beyond the terms and exceptions explicitly provided by the RA and ICANN Consensus Policies, the ICANN organization has no contractual authority to instruct a registry operator to release a reserved name.

Additionally, according to Section 4 of Specification 5 of the RA for the TLD .build, the names included in the list of United Nations member states must be reserved by the registry operator in the terms explained therein. “Malaysia” is included in the aforementioned list.

Please find below the following links:
.build registry agreement (RA) https://www.icann.org/en/registry-agreements/details/build
Internationally Recognized List https://www.icann.org/resources/country-territory-names

Taking the above into consideration, and to allow ICANN Compliance to determine whether your issue can be addressed, in whole or in part, within ICANN’s contractual authority, please provide the following before 23 Jul 2025 if you believe a registrar or a registry operator failed to comply with an ICANN policy or agreement:

1. A detailed explanation regarding the alleged violation and supporting evidence;

2. Copies of all communications with the registrar and the registry operator regarding this matter; and

3. Any other records or information relevant to your complaint.

Please send the information and records requested above via reply email (no more than 20 MB total) and do not change the email subject heading. Please provide any records as attachments in .CSV, .PDF, .DOC(X), .XLS, .XLS(X) or .TXT formats.

Please provide this information before 23 Jul 2025, to allow ICANN Contractual Compliance to address your complaint. If you have any questions or require any additional clarification, please let us know as well via reply email. If you require additional time to provide the information requested above, please indicate as much in your response so that an extension can be granted.

Sincerely,

ICANN Contractual Compliance

############################################

Original Complaint

REPORTED REGISTRAR : namecheap.com

REPORTED RESELLER :

PREVIOUS REGISTRAR : namecheap.com

CURRENT REGISTRAR : The .BUILD Registry

OTHER REGISTRAR(S) :

TRANSFER DATE : December 5, 2023

DESCRIPTION
Subject: FORMAL COMPLAINT: Unauthorized Transfer of Domain malaysia.build – Urgent Action Required (Namecheap Ticket Number – [NC-UWS-6390])

I am filing this formal complaint regarding the unlawful transfer and improper reservation of my domain, malaysia.build (Registrar: Namecheap, Inc.). This escalation targets:
1. The .BUILD Registry for reserving my domain without justification despite nearly 10 years of ownership.
2. Namecheap, Inc. for violating ICANN transfer policies and failing to protect my domain.
3. ICANN Compliance for inadequate registrar oversight.

Critical Facts:

Unauthorized Transfer:
The domain was transferred out of my account on December 5, 2023, despite being valid until April 29, 2024 (Whois History – https://whoisfreaks.com/tools/whois/history/lookup/malaysia.build). Please find the attached receipt named namecheap-order-116083446-malaysia-build-03-30-2023.pdf.

Active Auto-renewal:
Auto-renewal was active with no authorization for transfer. Please find the attached screenshot (auto-renewal-2021.png) confirming that Namecheap notified me of a successful auto-renewal. I have also included a copy of my credit card ending in 0593. The card is still active, and I continue to use it.

Substantial Prior Rights:
I have owned and developed malaysia.build since 2014. (Video proof: Ownership Evidence – View at: https://malaysia.sibu.design/proof-of-malaysia-build-ownership-since-2014/). The video also includes a second part where I demonstrate that I have access to both Android and iOS developer accounts.

My development efforts since December 2022 represent a value of over $500,000+ USD, encompassing multi-platform development including:
1. A functional demo of this project, showcasing nearly 90% of all its key features and functions, a complex backend with 50+ search filters, mortgage calculators, multi-language support, etc., is available at my demo website: https://malaysia.sibu.design. You can navigate to the “Features” section in the menu.
2. To experience the PWA on your mobile device, please visit https://malaysia.sibu.design/pwa/ and follow the instructions.
3. To try the Android mobile app, please download it from https://malaysia.sibu.design/android/malaysia-build.apk, install it on your phone, and explore all the available features.
4. iOS-ready WebView implementation (App Store developer account accessible via video proof).
5. To see the FPX Payment Gateway features, please visit https://malaysia.sibu.design/fpx/. There, you’ll find a YouTube video demonstrating the entire transaction process, showing that it fully supports real online payments.
6. Losing the malaysia.build domain name makes all my significant multi-platform development efforts effectively wasted.

I’ve created two trial accounts to test the platform—one with an Agent role and the other with an Agency role (https://malaysia.sibu.design):
• Agent Account: Username: agent, Password: return-my-domain-name
• Agency Account: Username: tcwong, Password: return-my-domain-name
These accounts are for demonstration purposes.

Namecheap’s Gross Negligence:
1. There have been ONE month of unresolved escalation (First report: June 11, 2025) with zero accountability.
2. No explanation has been provided for transferring a paid domain 5 months pre-expiry.
To view the complete email trail with Namecheap regarding malaysia.build, please visit:
https://malaysia.sibu.design/complete-email-trail/

.BUILD Registry’s Unlawful Reservation:
1. The domain was reserved retroactively despite my prior ownership and extensive development.

Demonstrated Losses (Conservatively $1,000,000+ USD):
1. Development Costs:
Developer cost of $500,000 (30+ months of full-time work).
Includes platform, Android/iOS apps, PWA, Google Maps/Street View, advanced 50+ field search, AUTO mortgage calculator, WhatsApp messaging, email forms, printable formats, saved favorites, property comparison, social sharing, photo watermarking, floor plans, brochures, embedded videos, nearby places, reviews, related listings, etc.

2. Revenue Loss:
$15,000+ per month.
Lost income from FPX payment transactions, premium listings, ad revenue, lead generation, third-party advertising, agent subscriptions, valuation reports, and market insights.

3. Business Damage:
Project stalled just weeks before launch.
Reputational harm with early users and agency partners.
Operational costs ongoing despite halted progress.

4. Opportunity Cost:
Loss of strategic first-mover advantage in Malaysian real estate tech.
Unique market position forfeited—mobile-first, multilingual, fully integrated with financial systems.

5. Branding & Marketing Loss:
Resources spent on building and promoting the “malaysia.build” brand are now wasted.
Launch campaign efforts compromised.

6. Dispute Costs:
Significant time and effort required to resolve the dispute.
Ongoing and potential legal/administrative expenses.

7. Potential Legal Risk:
Risk of punitive damages due to the unauthorized and unlawful transfer of a paid domain asset.

Policy Violations:
1. ICANN Transfer Policy (Section II.E.7): Unauthorized transfer of an active domain.
2. Registration Data Accuracy (ICANN 3.7.7): Failure to validate transfer requests.
3. .BUILD Registry Abuse: Retroactive application of reservation policies.

Demands:
1. Immediate restoration of malaysia.build to my Namecheap account.
2. Formal ICANN investigation into Namecheap’s transfer protocols.
3. .BUILD Registry intervention to release the domain within 48 hours.
4. Initiation of UDRP proceedings (WIPO/ADNDRC) to enforce my rights under Paragraph 4(a) of the UDRP Policy.

Evidence Attached:
1. Domain renewal receipt (valid until April 29 2024).
2. Auto-renewal confirmation and credit card copy ending 0593.
3. Video proofs (ownership, FPX transactions, app developer accounts).
https://malaysia.sibu.design/proof-of-malaysia-build-ownership-since-2014/
https://malaysia.sibu.design/fpx/
4. Apple and Android developer account screenshots
5. Screenshot evidence of the start date of my development of the malaysia.build real estate listings website.
6. malaysia.build WHOIS history

I kindly request written confirmation of the actions taken within 24 hours. If the issue remains unresolved, I may be compelled to pursue further action through appropriate international legal and regulatory channels.

Sincerely,
WONG TAI CHIEW

Mobile#: +60198280131
Email: [email protected]
Address: 21, Lane 9, Rejang Park, 96000 Sibu, Sarawak, Malaysia

P.S. Included below are my final email to Namecheap and their reply.

On Sun, Jul 6, 2025 at 10:45?PM DotCoName <[email protected]> wrote:
Subject: Follow-Up Regarding Domain malaysia.build (URGENT)

Dear Namecheap Support Team,

I am writing to express my significant concern regarding the ongoing situation with my domain name, malaysia.build. My initial report was filed on June 11, 2025. Despite multiple follow-up emails, your last communication on July 3, 2025, merely reiterated that you were “waiting for updates from our upstream provider and the Registry.” As of today, July 6, 2025, it has been nearly a month since my initial report, and 3 days since your last update. Every reply I have received so far has simply asked me to give more time for your team to investigate, offering no specific progress, no timeline, and no concrete explanation to date.

This prolonged delay is particularly concerning given a critical detail: the domain malaysia.build was transferred out of my account on December 5, 2023, despite its paid-for expiry date being April 29, 2024 — meaning it was still valid for nearly five months at the time of the transfer. (Reference: https://whoisfreaks.com/tools/whois/history/lookup/malaysia.build). This transfer of an actively registered and paid-for domain raises significant questions about the circumstances surrounding its removal and Namecheap’s domain management protocols.

Please find the attached receipt named namecheap-order-116083446-malaysia-build-03-30-2023.pdf as evidence of the domain’s renewal and validity through April 29, 2024. In addition, I have uploaded a video to YouTube as supporting evidence of my ownership of malaysia.build dating back to 2014. The video is in Mandarin with subtitles, but by viewing the description and content, it should be clear that I am demonstrating long-standing ownership and usage of the domain. You may view it at: https://malaysia.sibu.design/proof-of-malaysia-build-ownership-since-2014/.

To underscore the immense importance of this domain, I had even set malaysia.build to auto-renew, linked directly to my credit card ending in 0593. This proactive measure was specifically put in place to prevent any accidental incidents, such as forgetting to renew, highlighting how critically important this domain is to me. Please find the attached screenshot (auto-renewal-2021.png) confirming that Namecheap sent me a notification that the auto-renewal had been successfully processed. This domain is truly priceless to me.

The domain malaysia.build was actively held and used for other purposes until 2020. During that time, it was not used as a real estate listings website. However, since December 2022, I have dedicated substantial time and effort to develop this project specifically into a comprehensive real estate listings platform. This involved significant investment in the core platform, mobile app (for both Android and iOS platforms), PWA framework, and a suite of advanced features for a market-ready ecosystem. My decision was made at a high level to exclusively develop and launch this platform under malaysia.build, recognizing it as the perfect and most valuable choice due to its direct relevance to the real estate sector and its strong potential to achieve high rankings in Google search with keywords like “Malaysia” and “build.” The inclusion of “Malaysia” in the domain name is paramount for geo-targeting and local SEO, ensuring high visibility for users searching for real estate within Malaysia. The .build extension directly relates to construction, development, and real estate, instantly signaling the website’s purpose and establishing a professional, industry-specific perception, which is critical for user engagement, conversion, and long-term value.

Crucially, malaysia.build is designed to serve a global audience. Unlike country-specific domains like .com.my or .my, the .build gTLD (generic Top-Level Domain) has no geographical limitation, allowing me to connect with property seekers and investors worldwide. To support international visitors, especially those exploring programs like the Malaysia My Second Home (MM2H) program (official URL: https://www.imi.gov.my/index.php/en/main-services/malaysia-my-second-home-mmh2-en/), I’ve integrated a global language translator and a built-in language selector (default: English) to ensure a seamless and accessible property search experience for everyone.

Beyond the technical development, I also invested significant time in extensive research into the Malaysian real estate market. This research meticulously determined all the necessary fields for property submission forms and the comprehensive details to be displayed on each single property page. I even considered crucial cultural factors, such as the importance of Feng Shui for most Malaysians (especially the Chinese community), which led me to deliberately include a “direction” field in both the submission and details display sections. This demonstrates the deep understanding and tailored approach taken to ensure the platform’s relevance and appeal to the target market.

A fully functional demo of this project, showcasing nearly 90% of all its key features and functions, is available at my demo website: https://malaysia.sibu.design. You can navigate to the “Features” section in the menu.

To experience the PWA on your mobile device, please visit https://malaysia.sibu.design/pwa/ and follow the instructions.

To try the Android mobile app, please download it from https://malaysia.sibu.design/android/malaysia-build.apk, install it on your phone, and explore all the available features.

To see the FPX Payment Gateway features, please visit https://malaysia.sibu.design/fpx/. There, you’ll find a YouTube video demonstrating the entire transaction process, showing that it fully supports real online payments.

I’ve created two trial accounts on Namecheap to test the platform—one with an Agent role and the other with an Agency role:

• Agent Account: Username: agent, Password: return-my-domain-name

• Agency Account: Username: tcwong, Password: return-my-domain-name

These accounts are for demonstration purposes.

I am suffering tremendous loss due to this unauthorized transfer, encompassing:

• Significant Time and Effort & Development Costs: Substantial investment in the core platform, mobile app (for both Android and iOS), PWA framework, and a comprehensive suite of advanced features (including Google Maps/Street View, very complicated search functions within the system that allow users to search over 50 fields and narrow down results to easily find what they are looking for, automatic mortgage calculation, preset messages via WhatsApp, email forms, printable formats, saved favorites, property comparison, social sharing, image galleries, downloadable brochures, floor plans, embedded videos, nearby places, visitor reviews, related properties, photo watermarking, etc).

• Lost Revenue and Monetization Delays: Inability to generate expected income from premium listings (The integrated FPX Payment Gateway is fully functional in real-time, meaning I am losing real potential transaction revenue every day the website is unavailable.), featured properties, broker lead fees, ad space, data analytics, transaction commissions, commission on bank loans, third-party advertising, property valuation reports, exclusive content/market insights, and agent subscriptions.

• Business Disruption: The entire project, which was weeks from launch, is on hold, causing severe operational setbacks. This includes ongoing operational costs for maintaining the stalled project.

• Reputational Damage: Credibility with early users and partnering agencies is being undermined by the inability to launch.

• Loss of Strategic Market Position: Forfeiting a unique and unreplicable advantage in the Malaysian real estate market, particularly concerning mobile users, cross-language accessibility, and financial integration. This includes loss of first-mover advantage in a competitive market.

• Loss of Marketing and Branding Investment: Resources already invested in promoting the malaysia.build brand or preparing launch campaigns that are now compromised or wasted.

• Opportunity Cost: The missed potential to pursue other valuable business initiatives while resources are diverted to resolving this dispute.

• Costs of Dispute Resolution: The time, effort, and potential future expenses associated with pursuing this complex dispute.

• Potential Punitive Damages: Arising from the serious nature of an unauthorized transfer of a paid-for domain.

Your previous communication indicated that the malaysia.build domain is currently in a “reserved” status by the .BUILD Registry, with an assumption that this relates to the domain name consisting of a country name. However, I owned and actively developed this domain for nearly a decade before this “reserved” status was apparently enforced or before it was “transferred out” without my authorization. I received no prior notice of any policy violation. My long-standing and substantial development creates a clear, legitimate interest in the domain that should override any belated or ambiguous reservation policy. Furthermore, Namecheap’s role in the “transferred out” notification and your current inability to provide clear reasons or solutions indicates a potential breach of your contractual obligations to me as my registrar.

As a loyal Namecheap customer, I kindly ask you to recognize the URGENCY of this matter and the direct responsibility Namecheap holds for the removal of my domain prior to its expiry. I respectfully request a comprehensive explanation for the pre-expiry transfer of my domain and a definitive outline of the immediate steps Namecheap will take to rectify this situation within 48 hours of this email.

Please understand that if a satisfactory explanation and the return of my domain name are not provided within this 48-hour timeframe, I will unfortunately need to proceed with filing formal complaints with:

• The .BUILD Registry directly.

• ICANN’s Contractual Compliance Department regarding Namecheap’s apparent failure to protect my domain and adhere to transfer policies.

• An ICANN-approved dispute resolution service provider (such as WIPO or ADNDRC) to pursue the recovery of the domain based on my prior rights and your inability to restore it.

Thank you for your prompt and serious attention to this critical matter.

Sincerely,

WONG TAI CHIEW

From: Namecheap Domains Support Team <[email protected]>
Date: Mon, Jul 7, 2025 at 12:52?AM
To: <[email protected]>

Hello,

Thank you for getting back to us.

Please accept our apologies for the delay in replying. We are doing our best to process the support tickets in a timely manner.

We sincerely understand how frustrating and stressful this ongoing delay must be, especially when you’ve done everything on your part to move the process forward.

Please rest assured that as soon as we received your request, we submitted it to our upstream provider. Since then, we’ve been closely monitoring the progress, which, unfortunately, is still pending on their end. They have acknowledged our request and assured us they will make every effort to expedite the process. While this is somewhat encouraging, we do recognise that this delay is far from ideal and deeply inconvenient for you.

We truly wish we had more direct control over this stage of the process. That said, we are committed to staying proactive on your behalf, and we will continue to follow up regularly until the matter is resolved.

We know this has been time-consuming and emotionally taxing, and we’re genuinely sorry that you’re having to go through this. Please know that your concerns are being taken seriously, and we’ll notify you immediately the moment we receive any update.

Your patience is highly appreciated.

############################################

ref:!00D6106tJk.!500Rm0ouQhV:ref

From: DotCoName <[email protected]>
Date: Tue, Jul 22, 2025 at 11:00 PM
To: ICANN Contractual Compliance <[email protected]>
Cc: <[email protected]>

Subject: Re: Transfer Complaint – Additional Information for Reserved Names Review (malaysia.build)

Case Number 01448650

Dear ICANN Contractual Compliance Team,

Thank you for your response and for allowing me the opportunity to provide additional documentation regarding my complaint concerning the domain malaysia.build.

I wish to strongly emphasize that I have been the rightful registrant of malaysia.build for nearly a decade. This is not a short-term registration nor a case of misuse or neglect. I actively maintained and paid for the domain annually, with auto-renewal enabled through my Namecheap account. The most recent renewal was completed on March 30, 2023, with the domain valid through April 29, 2024. Despite this, the domain was suddenly removed from my Namecheap account on December 5 2023, no EPP code request, and no warning of any kind. There was no justification—technical, contractual, or policy-based—provided by Namecheap, Enom, or the .BUILD Registry.

To assist your review, I’ve created a full documentation portal at:
https://liable.co

This site contains:

• WHOIS history and domain renewal/payment records, including confirmation that the credit card ending in 0593—used for auto-renewal—remains active.
• A complete email trail with Namecheap, Enom, and the .BUILD Registry, clearly showing a pattern of blame-shifting and lack of resolution from all parties involved.
• A series of twelve videos demonstrating proof of ownership, Android and iOS developer access, a fully developed property platform with complex backend features, and real-time FPX transactions approved by PayNet.
• A comprehensive compensation assessment based on the damages caused by this disruption.

Please note that the videos are spoken in Mandarin, and I sincerely apologize for not being able to provide English subtitles in time. However, each video includes a brief English summary, and the visual evidence should be sufficient for your team to understand the platform’s functionality and ownership context.

After maintaining the domain for almost ten years—investing time, resources, and substantial development into a business tied directly to malaysia.build—I believe it is completely unjustifiable that the domain could be unilaterally reclaimed or “reserved” by the registry after so long, and without due process.

I respectfully ask ICANN to treat this matter with the seriousness it deserves and to consider the long-term ownership and ongoing harm this has caused.

Lastly, may I kindly ask: approximately how long will ICANN take to review the provided documentation and respond with a determination? Knowing the expected timeline would greatly help in managing the situation on my end.

Please don’t hesitate to contact me should you require any documents in a specific format or additional clarification.

Sincerely,
Tai Chiew Wong
[email protected]
Mobile#: 60198280131

From: ICANN Contractual Compliance <[email protected]>
Date: Fri, Jul 25, 2025 at 4:40 PM
To: [email protected] <[email protected]>

Dear TAI CHIEW WONG,

Thank you for your response. However, you did not provide a response to all of ICANN’s previous requests.

Specifically, you did not provide an explanation of the specific violation(s) of the registry agreement (RA). ICANN also notes that the provided records were not provided in .CSV, .PDF, .DOC(X), .XLS, .XLS(X) or .TXT format as requested by ICANN. Due to the format of the files provided, the documents could not be reviewed.

As previously indicated, Section 3.3 of Specification 5 of the RA for the TLD .build allows the registry operator to withhold from registration at all levels domain names that are not activated in the Domain Name System (DNS) and release them for registration to another person or entity at the registry operator’s discretion.

Additionally, according to Section 4 of Specification 5 of the RA for the TLD .build, the names included in the list of United Nations member states must be reserved by the registry operator in the terms explained therein. “Malaysia” is included in the aforementioned list.

Please find below the following links:
.build registry agreement (RA) https://www.icann.org/en/registry-agreements/details/build
Internationally Recognized List https://www.icann.org/resources/country-territory-names

Please note that beyond the terms and exceptions explicitly provided by the RA and ICANN Consensus Policies, the ICANN organization has no contractual authority to instruct a registry operator to release a reserved name.

If you still require ICANN’s assistance, please provide ICANN the following before 1 Aug 2025:

1. A detailed explanation why you believe the registrar or the registry operator failed to comply with the applicable RA requirements as explained above or an ICANN policy or agreement, and any available evidence.

2. Copies of all communications with the registrar and the registry operator regarding this matter.

Please send the information and records requested above via reply email (no more than 20 MB total) and do not change the email subject heading. Please provide any records as attachments in .CSV, .PDF, .DOC(X), .XLS, .XLS(X) or .TXT formats.

If we do not hear from you by 1 Aug 2025, we will close this case.

Sincerely,

ICANN Contractual Compliance

From: DotCoName <[email protected]>
Date: Tue, Jul 29, 2025 at 9:41 PM
To: ICANN Contractual Compliance <[email protected]>
Cc: <[email protected]>

Dear ICANN Contractual Compliance Team,

Please accept my sincere apologies for the oversight in my previous submission. I understand that I did not fully address all of your requests, particularly regarding the specific format of the attached records and a clear explanation of the Registry Agreement violations. I also apologize if the previous file formats caused any inconvenience in your review.

Thank you for providing the direct links to the .build Registry Agreement and the Internationally Recognized List, which have been very helpful in preparing this revised response. I also appreciate your clarification regarding ICANN’s contractual authority.

I have carefully reviewed your feedback and the relevant sections of the Registry Agreement, particularly your specific points regarding Section 3.3 and Section 4 of Specification 5. This email aims to provide a comprehensive response that directly addresses all your requests, ensuring all information is presented clearly and in the requested .PDF and .TXT formats.

Herein, I provide:

1. A detailed explanation of why I believe the Registry Operator and the Registrar failed to comply with the applicable Registry Agreement and Registrar Accreditation Agreement requirements and relevant ICANN policies, along with supporting evidence. This explanation is structured to directly counter the points raised in your email regarding Section 3.3 and Section 4 of Specification 5, and to highlight additional violations.
2. Copies of all communications with the registrar (Namecheap) and the Registry Operator (.BUILD Registry) regarding this matter. These are compiled for your ease of review.

In direct response to the issues you highlighted:

• Regarding Section 3.3 of Specification 5 (Registry Operator’s ability to withhold domains not activated in DNS), please refer to ‘2. section-3-3-of-specification-5-of-the-ra-for-the-tld-build.pdf’. This document provides detailed evidence refuting the claim that malaysia.build was not activated, showcasing its long-term use and active development.
• Regarding Section 4 of Specification 5 (reservation of United Nations member state names), please refer to ‘3. section-4-of-specification-5-of-the-ra-for-the-tld-build.pdf’. This document explains why the application of this section to malaysia.build is a misinterpretation of the ‘at the second level’ requirement and constitutes a retroactive and inappropriate action.

I have attached the following documents to support my claims:

1. the-incident-an-unauthorized-disappearance.pdf:Provides an overview of the domain’s disappearance and sets the context.
2. section-3-3-of-specification-5-of-the-ra-for-the-tld-build.pdf:Dedicated to refuting the “not activated in DNS” claim with historical evidence of domain activation and usage, directly addressing ICANN’s point regarding this section.
3. section-4-of-specification-5-of-the-ra-for-the-tld-build.pdf:Addresses the “reserved names” argument, demonstrating the retroactive and inappropriate application of this rule, directly addressing ICANN’s point regarding this section.
4. build-registrys-violation-of-icann-obligations-and-operational-duties.pdf:Contains a detailed explanation of the Registry Operator’s violations of the .build Registry Agreement.
5. namecheap-violations-breach-of-registrar-duties.pdf:Details the Registrar’s (Namecheap’s) failures to comply with its Registrar Accreditation Agreement duties and provide adequate service.
6. the-project-real-world-impact.pdf:Illustrates the legitimate and significant business purpose of the domain, quantifying the tangible losses and harm incurred due to its unauthorized removal.
7. watch-all-features-in-action.pdf:Provides visual and descriptive evidence of the extensive development and functionality associated with the domain.
8. complete-email-trail.txt:Contains the compiled communications with the registrar and registry. (Provided in .TXT format to comply with file size limits.)

I trust that this submission addresses all the points you raised and provides the necessary detail and evidence for your review. I remain available to provide any further information or clarification required.

Thank you for your continued assistance in this critical matter.

Sincerely,

WONG TAI CHIEW

Email: [email protected]

Phone: +6019 8280131

[ICANN Case #: 01448650]

From: DotCoName <[email protected]>
Date: Tue, Jul 29, 2025 at 9:59 PM
To: ICANN Contractual Compliance <[email protected]>
Cc: <[email protected]>

Dear ICANN Contractual Compliance Team,

I am writing to provide a quick clarification regarding one of the file names in my previous submission for ICANN Case #: 01448650.

I noticed that the file previously attached as watch-all-features-in-action.pdf.pdf was an oversight in naming. The correct file name for this document is watch-all-features-in-action.pdf.

Although the file content should still be fully accessible and viewable despite this naming error, I wanted to bring it to your attention for accuracy and ease of your review process.

For your convenience, I have attached the corrected file watch-all-features-in-action.pdf with this email.

Thank you for your understanding and continued attention to this matter.

Sincerely,

WONG TAI CHIEW

Email: [email protected]

Phone: +6019 8280131

[ICANN Case #: 01448650]

From: ICANN Contractual Compliance <[email protected]>
Date: Wed, Aug 13, 2025 at 2:59 PM
To: [email protected] <[email protected]>

Dear TAI CHIEW WONG,

Thank you for your responses on 29 July 2025 and the additional information provided.

According to the communications you provided, the registrar NameCheap, Inc. (“NameCheap”) advised you that the domain name was reserved by the .build registry operator due to Specification 5 of the registry agreement (RA), which “certain country and territory names (including their IDN variants, where applicable) shall be withheld from registration or allocated to Registry Operator at All Levels.” Additionally, based on the communications you provided, the upstream provider eNom, LLC (“eNom”) advised you that they received a response from the .build registry operator stating that the domain name has been “[removed or blocked] […] from registration due to it violating Spec 5 of our Registry agreement.” NameCheap and eNom both advised that you contact the registry operator directly for assistance as the domain name is reserved at the registry level.

As indicated previously, Section 4 of Specification 5 of the RA for .build requires the country and territory names (including their IDN variants, where applicable) contained in the following internationally recognized lists be reserved at All Levels: https://www.icann.org/resources/country-territory-names.

Regarding your response that “malaysia.build was under legitimate, active use and its DNS was fully activated and resolving at the time of its unauthorized removal. The Registry Operator’s reliance on Section 3.3 of Specification 5 is therefore baseless and unjustified”, to clarify, Section 3.3 of Specification 5 of the RA for .build states that the registry operator may withhold from registration at all levels domain names, and that “[s]uch names may not be activated in the DNS”. ICANN is not claiming that “malaysia.build was not activated” before it was reserved by the registry operator.

Please note that beyond the terms and exceptions explicitly provided by the RA and ICANN Consensus Policies, the ICANN organization has no contractual authority to instruct a registry operator to release a reserved name.

In light of the above, by 20 Aug 2025, if you have reason to believe that the registrar or the registry operator failed to comply with the applicable RA requirements as explained above or an ICANN policy or agreement, please provide further details of the specific violation(s) and evidence (if available).

Please send the information and records requested above via reply email (no more than 20 MB total) and do not change the email subject heading. Please provide any records as attachments in .CSV, .PDF, .DOC(X), .XLS, .XLS(X) or .TXT formats.

If we do not hear from you by 20 Aug 2025, we will close this case.

Sincerely,

ICANN Contractual Compliance

From: DotCoName <[email protected]>
Date: Tue, Aug 19, 2025 at 1:40 AM
To: ICANN Contractual Compliance <[email protected]>

Dear ICANN Contractual Compliance,

Thank you for your clarification regarding Specification 5 of the .BUILD RA. While I understand the policy’s intent, I respectfully submit procedural and contractual concerns that warrant investigation.

To ensure clarity, I provide a Compliance Violation Matrix mapping each issue to the relevant contractual clause and supporting evidence, followed by detailed sections.

Issue	Violated Clause(s)	Description of Violation	Evidence (Attachment)
Improper Allocation / Retroactive Reservation	RA Spec 5 §4 (Reserved Names)	Domain was allocated in 2014 despite claim it was “always reserved”; retroactive enforcement after 9 years contradicts predictability.	1 (Preorder & renewals), 2 (WHOIS records), 3–5 (Active use evidence)
Improper Domain Removal Without EPP Code	ICANN Transfer Policy §2.1.1	No Standardized Form of Authorization (no EPP code issued) prior to removal/transfer.	6 (Registrar confirmation: no EPP code issued)
Lack of Pre-Deletion Notice	RAA §3.7.5.4; ERRP	Registrant was not provided notice prior to removal.	6 (Registrar confirmation), 7 (Registrar explanations)
Registrar/Registry Non-Cooperation	RAA §3.18 (Registrar responsiveness); RAA §3.4.3 (Record retention & cooperation)	Registrar provided inconsistent answers; registry gave no response despite being copied on communications.	7 (Inconsistent explanations), 8 (Registry silence)
Misrepresentation of ICANN Authority	RA Spec 5 (Reserved Names), RAA Principles of Transparency & Fairness, ICANN Accountability Commitments	Enom provided documentary evidence that the .BUILD registry claimed ICANN itself “requested” removal of malaysia.build. This directly contradicts ICANN’s written statement to me that it has “no contractual authority to instruct a registry operator to release or reserve a name.”	10 (Email from Enom dated 14 July 2025)
Failure to Consult GAC Database / Notify Government	Specification 5 of the .BUILD RA; 2015 GAC Singapore Communiqué; ICANN Applicant Guidebook 2.2.1.4	Malaysia has “R” status (requires notification). No evidence registry consulted Malaysia’s GAC-designated contact before allocation or removal.	Request for ICANN verification (no evidence provided by registry).
Cross-TLD Enforcement Inconsistency	RA Spec 5 enforcement; ICANN accountability principles	Other country-name domains (e.g., peru.travel, greece.travel) remain active in gTLDs, suggesting selective enforcement.	9 (WHOIS data for peru.travel and greece.travel)
Lack of Transparency & Appeal	RAA Principles of Openness & Fairness; ICANN Accountability commitments	Registry gave no notice, no response, and no appeal mechanism for removal of malaysia.build.	8 (Registry silence), 11 (Complete email trail)

1. Allocation Contradicts Reserved Status

Core Issue: malaysia.build was lawfully allocated in 2014 and continuously used (Attachments 1-5). A 3,287-day enforcement delay contradicts the ‘always reserved’ claim and ICANN’s principles of predictability.

Fundamental Questions & Requests:

1. Was it on the Reserved Names List in 2014? If yes, why was it allocated? If no, why enforce retroactively? (Clarify enforcement timing)
2. Does a nearly a decade delay constitute a waiver of enforcement rights? (Investigate RA compliance)
3. Given uninterrupted commercial use, restoration must be considered (Remedy request).

Evidence:

1. 2014 launch allocation, transfers and continuous renewals (Attachment 1: 1-proof-of-successful-preorder-registration-transfers-renewals-2014-2023.pdf)
2. Historical WHOIS records confirming uninterrupted registration, 2014–2023 (Attachment 2: 2-whois-records.pdf)
3. Active Commercial Deployment (Resolution & Use Records)
   i. Domain resolution records and screenshots of live malaysia.build operations and demo continuation at https://malaysia.sibu.design (Attachment 3: 3-domain-resolution-records.pdf)
   ii. Video demonstrations of full platform functionality (Attachment 4: 4-video-demonstrations-of-full-platform-functionality.pdf)
   iii. FPX payment gateway approval and transaction integration proof (Attachment 5: 5-fpx-payment-integration-demo-for-woocommerce.pdf)

2. Procedural Requirements Not Followed

Transfer Policy Concerns:

1. No EPP Code was issued (Attachment 6: 6-confirmation-from-namecheap-no-epp-code-was-issued.pdf), raising concerns under ICANN Transfer Policy §2.1.1 requiring a Standardized Form of Authorization.
2. No pre-deletion notice was provided, potentially inconsistent with RAA §3.7.5.4 and ERRP requirements.

Registrar Coordination Issues:

1. Registrar provided inconsistent explanations (Attachment 7: 7-registrar-provided-inconsistent-explanations.pdf).
2. The .BUILD Registry did not respond despite being copied on communications and online submissions (Attachment 8: 8-the-registrys-silence-no-answers-from-build.pdf).

Requests:

1. Investigate non-compliance with RAA §§3.4.3 (record retention), 3.7.5.4 (notices), and 3.18 (response obligations).
2. Restore domain due to procedural violations (Remedy request).

3. Contradictory Claims Regarding ICANN’s Role

Core Issue:

The registry’s communication to Enom (upstream provider) on 1 December 2023 stated:

“This email is to inform you that we have been requested by ICANN to remove / block the domain malaysia.build from registration due to it violating Spec 5 of our Registry Agreement.”

This message was relayed to me by Enom on 14 July 2025 (Attachment 10: 10-enom-email-registry-claims-icann-ordered-removal.pdf).

This claim directly conflicts with ICANN’s own compliance correspondence to me dated 13 August 2025, which states:

“Please note that beyond the terms and exceptions explicitly provided by the RA and ICANN Consensus Policies, the ICANN organization has no contractual authority to instruct a registry operator to release a reserved name.”

This creates a direct contradiction:

1. ICANN’s Position (2025): ICANN stated to me that it does not instruct registries to release or withhold reserved names, as this is beyond its contractual authority.
2. Registry’s Claim (2023): The registry explicitly invoked ICANN as the source of the removal order.

Analysis:

1. If ICANN did instruct the registry → ICANN exceeded its contractual authority under the RA, contradicting its own compliance statement.
2. If ICANN did not instruct the registry → the registry misrepresented ICANN’s authority to justify retroactive removal, which constitutes a breach of transparency, accountability, and fair dealing obligations under the RA and ICANN accountability principles.

Requests:

1. ICANN must clarify whether it directly instructed the .BUILD registry to remove malaysia.build.
2. If ICANN did not issue such an instruction, ICANN must take compliance action against the registry operator for falsely invoking ICANN authority in registrar communications.
3. In either scenario, the removal of malaysia.build is tainted by procedural irregularity and lack of lawful basis; therefore, restoration must be considered as a remedy.

Evidence:

Attachment 10: 10-enom-email-registry-claims-icann-ordered-removal.pdf (copy of Enom’s 14 July 2025 communication relaying registry’s statement).

4. GAC Database Consultation Verification

Requirements:

Per the 2015 Singapore Communiqué and Section 4 of Specification 5 of the .BUILD Registry Agreement (RA), registry operators must consult the GAC database before allocating or removing country-name domains. The ICANN Applicant Guidebook (Module 2.2.1.4) and the Reserved Names List further codify this obligation.

For countries with an ‘R’ status, such as Malaysia, the registry operator is specifically mandated to notify the government before allocating or removing their reserved names.

Requests:

1. Confirm if .BUILD registry consulted Malaysia’s GAC representative in 2014 (allocation) and 2023 (removal). (Clarify timing)
2. Provide copies of notifications or confirm absence (Investigate RA compliance).
3. If documentation is missing, restore domain for registry non-compliance (Remedy request).

5. Cross-TLD Enforcement Consistency

Analysis:

Removing malaysia.build while country names operate in other gTLDs suggests selective enforcement.

Examples for Verification:

1. peru.travel (Attachment 9: 9-historical-whois-data-for-peru-travel-and-greece-travel.pdf)
2. greece.travel

Requests:

1. Address why Reserved Names rules apply inconsistently across TLDs (Selective application).
2. Investigate whether new gTLD examples (Attachment 9) underwent GAC consultation (RA compliance).
3. Clarify how ICANN ensures equal registrant treatment.

Unlike legacy TLDs (.com, .net, .org, .info), both .travel and .build are new gTLDs subject to the same Registry Agreement and Specification 5 obligations. The continued operation of peru.travel and greece.travel therefore highlights inconsistent enforcement of Spec 5 across new gTLDs.

6. Lack of Notification and Transparency

Issue:

No notification/appeal mechanism accompanied malaysia.build’s removal.

Evidence:

1. Zero registry response despite submissions (Attachment 8).
2. No documentation beyond one email.

Requests:

1. Investigate violations of RAA transparency obligations and ICANN due process principles (RA/RAA compliance).
2. Restore domain given absence of lawful procedure (Remedy request).

Relevance:

From my perspective as the registrant, the registry’s silence and lack of an appeal mechanism raises questions about consistency with ICANN’s principles of openness, due process, and fairness for registrants. I respectfully request ICANN to review whether this approach aligns with its accountability commitments.

Evidence Highlights

• Attachments 1-5: Proof of lawful allocation, use, and commercial deployment.
  • 1-proof-of-successful-preorder-registration-transfers-renewals-2014-2023.pdf
  • 2-whois-records.pdf
  • 3-domain-resolution-records.pdf
  • 4-video-demonstrations-of-full-platform-functionality.pdf
  • 5-fpx-payment-integration-demo-for-woocommerce.pdf
• Attachments 6-8: Registrar/registry procedural failures.
  • 6-confirmation-from-namecheap-no-epp-code-was-issued.pdf
  • 7-registrar-provided-inconsistent-explanations.pdf
  • 8-the-registrys-silence-no-answers-from-build.pdf
• Attachment 9: Cross-TLD inconsistency.
  • 9-historical-whois-data-for-peru-travel-and-greece-travel.pdf
• Attachment 10: Contradictory Claims Regarding ICANN’s Role.
  • 10-enom-email-registry-claims-icann-ordered-removal.pdf
• Attachment 11: 11-complete-email-trail.txt (Provided in .TXT format to comply with file size limits.).

I appreciate your review and remain available for questions.

Respectfully,

Tai Chiew Wong

From: ICANN Contractual Compliance <[email protected]>
Date: Thu, Aug 28, 2025 at 5:29 PM
To: [email protected] <[email protected]>

Dear TAI CHIEW WONG,

Thank you for your response on 18 August 2025. ICANN is reviewing your response and the documents provided, and will contact you again if further information is needed.

For more information about ICANN’s process and approach, please visit http://www.icann.org/en/resources/compliance/approach-processes .

Sincerely,

ICANN Contractual Compliance

From: ICANN Contractual Compliance <[email protected]>
Date: Wed, Sep 10, 2025 at 12:03 PM
To: [email protected] <[email protected]>

Dear TAI CHIEW WONG,

Thank you for your response on 18 August 2025.

The ICANN organization contracts with registries to operate generic top-level domains (gTLDs), such as .BUILD, through a Registry Agreement (RA). The RA specifies the responsibilities of the registry operator. ICANN Contractual Compliance enforces the obligations that exist in ICANN’s agreements with registries (RAs) and registrars and the community-developed policies incorporated into those agreements. These agreements and policies were created and are implemented to preserve and enhance the security, stability and resiliency of the Domain Name System (DNS).

According to Section 4 of Specification 5 of the .build Registry Agreement (RA), dated 7 November 2013, the Registry Operator must reserve (i.e. withhold from registration) certain country and territory names unless the Registry Operator reaches an agreement with the applicable government. The RA further states that the Registry Operator must not activate such names in the DNS; provided, that the Registry Operator may propose the release of these reservations, subject to review by ICANN’s Governmental Advisory Committee and approval by ICANN. The list of protected names includes Malaysia.

ICANN Contractual Compliance maintains an Audit Program that regularly validates compliance across all ICANN policies and agreements. Information about the ICANN Contractual Compliance Audit Program can be found at https://www.icann.org/resources/pages/audits-2012-02-25-en. The October 2023 Audit round was launched to validate Registry Operators’ compliance with the terms of their RAs. The Registry that operates the .BUILD TLD was selected as an auditee for this Audit. As part of the Audit, any detected violation was communicated to the relevant Registry Operator who presented remediation measures to become compliant with the pertinent requirement of its RA. In some cases, these remediation measures included the deletion and reservation of protected names that had been released in error by the Registry Operator, as it occurred with malaysia.build.

For more information about reserved names, including a list of protected names/labels, please visit https://www.icann.org/reserved-names-en.

In the communications attached to your complaint you referenced potential compensation, please note that ICANN Contractual Compliance has no authority, contractual or otherwise, to serve as an appellate body or otherwise exempt Registry Operators from compliance with certain requirements. ICANN Contractual Compliance’s authority derives exclusively from ICANN’s agreements and policies which do not contemplate requirements related to the compensation a registrar or registry operator may decide to offer to an impacted party when correcting mistakes (including by deleting and reserving domain names that had initially been released by mistake). You may wish to review the Registry Operator’s policies or the terms applicable to your registration for information about any possible compensation or otherwise, and/or seek legal advice from an attorney.

We hope the information above is helpful. If you have any additional questions, please reply let us know by replying to this email without changing the email subject heading. Provide any records as attachments in .CSV, .PDF, .DOC(X), .XLS, .XLS(X) or .TXT formats.

If you require additional time to respond to the request above, please indicate so in your response so that an extension can be granted.

If we do not hear from you by 17 Sep 2025, we will close this case.

Sincerely,

ICANN Contractual Compliance

From: DotCoName <[email protected]>
Date: Wed, Sep 10, 2025 at 4:20 PM
To: ICANN Contractual Compliance <[email protected]>
Cc: <[email protected]>

Dear ICANN Contractual Compliance,

Thank you for your reply of 10 September 2025 regarding my complaint on the removal of malaysia.build. I appreciate the clarification regarding the October 2023 Audit and the reserved names framework under Specification 5 of the .BUILD Registry Agreement.

However, several core issues I raised in my 18 August 2025 submission remain unanswered. For clarity and accountability, I have summarized them in the table below. I respectfully request ICANN Contractual Compliance to provide specific answers to each question:

Issue	Contractual Reference	Unanswered Question
2014 Allocation vs. Reserved Status	RA Spec 5 §4 (Reserved Names)	Was “Malaysia” on the Reserved Names List in 2014? If so, why was it allocated? If not, why is enforcement applied retroactively after a decade?
Procedural Compliance	Transfer Policy §2.1.1; RAA §3.7.5.4; ERRP	Why was the domain removed without (a) an EPP code and (b) pre-deletion notice? Do the registrar’s inconsistent responses constitute RAA non-compliance under §§3.4.3 and 3.18?
Contradictory Claims of ICANN’s Role	RA Spec 5; ICANN accountability principles	Did ICANN instruct the registry to remove the domain, or did the registry misrepresent ICANN’s role to justify the removal?
GAC Consultation Requirement	RA Spec 5 §4; 2015 GAC Communiqué; Applicant Guidebook 2.2.1.4	Was Malaysia’s GAC-designated contact consulted/notified before allocation (2014) or removal (2023)?
Cross-TLD Enforcement Consistency	RA Spec 5 enforcement	Why is malaysia.build removed while peru.travel and greece.travel remain active under other new gTLDs? How does ICANN ensure consistent enforcement?
Transparency, Notice & Appeal	RAA Principles of Openness & Fairness; ICANN Accountability Commitments	What notification or appeal mechanisms exist for registrants in Spec 5 enforcement cases? Was the registry’s silence and lack of response consistent with ICANN’s principles of transparency and accountability?

In addition, I request ICANN to address the following accountability concerns arising from your reply of 10 September 2025:

1. Admission of Error– Does ICANN acknowledge that allowing malaysia.build to be allocated in 2014 was a mistake under Specification 5? If not, why is the allocation being treated as such nearly a decade later?
2. Responsibility– All parties in this chain—the Registrar (Namecheap), the Upstream Provider (Enom), and the Registry (.Build) Operator—received payments for the registration and renewal of a domain that was, according to ICANN, a reserved name and should never have been available. Who bears accountability for this collective failure to safeguard a domain that was paid for and used in good faith for nearly ten years? Specifically, who authorized the allocation of malaysia.build in 2014, and who authorized its deletion in 2023?
3. Audit Timing– If the Audit Program has existed since 2012, why was this issue only discovered in the 2023 Audit? Why did ICANN’s oversight fail for nearly ten years while the domain remained valid, renewed, and in active use?
4. Fault & Accountability– Does ICANN consider this a failure of the Registry Operator alone, or also of ICANN’s own compliance mechanisms? What accountability exists when ICANN’s delay directly harms registrants?
5. Audit Transparency– Am I, as the impacted registrant, entitled to see the audit findings related to malaysia.build? If not, how does withholding such information align with ICANN’s principles of transparency and accountability?
6. Due Process & Notice– Why was no notice, appeal mechanism, or transition option provided before deletion of the domain? Which ICANN policy allows silent deletion of a domain that had been continuously valid and renewed for years?
7. Good Faith & Detrimental Reliance– Does ICANN’s model of retroactive enforcement, which nullifies a decade of good-faith registration and investment, acknowledge the legal principle of “detrimental reliance”? How does ICANN justify penalizing the registrant for an error made by its own contracted party?
8. Registrant’s Burden of Knowledge– Does ICANN expect every potential registrant to conduct a full legal audit of every Registry Agreement to identify reserved names? How does placing this impossible burden on the public align with ICANN’s commitment to a stable and trustworthy domain name system?
9. Systemic Risk & Registrant Security– If a domain registered and renewed in good faith for nearly a decade can be deleted without notice due to a retrospective audit, what assurance can any gTLD registrant have that their domain is secure? Does ICANN not see this as a fundamental threat to DNS stability and predictability, undermining trust in the system for all registrants?
10. Scale of Audit Impact– How many other registrants across how many gTLDs were impacted by the October 2023 Audit’s “remediation” of names “released in error”? What is ICANN’s plan to address this widespread harm caused by its prolonged failure to enforce its own agreements?
11. Duty of Care & Transition– Even assuming the deletion was contractually required of the registry, what specific steps did ICANN Compliance take to ensure its contracted parties fulfilled their duty of care to the registrant by providing a transition path, rather than executing a silent deletion?
12. Selective Enforcement– The audit enforced the registry’s obligation to reserve the name. Did the audit also enforce the registrar’s obligations under the RAA to provide adequate notice and a reason for the deletion (§ 3.7.5.4, § 3.4.3)? Or does ICANN only enforce contract provisions that protect itself and registries, while ignoring those that protect registrants?

For clarity, I am not requesting ICANN to adjudicate compensation. I am requesting confirmation of contractual compliance, procedural obligations, and accountability under the RA, RAA, Transfer Policy, and GAC-related requirements.

Given that ICANN Contractual Compliance has set 17 September 2025 as the date by which I must respond, I respectfully request confirmation that this case will remain open until ICANN has addressed the specific questions outlined above. If these questions remain unanswered, I will have no choice but to seek further review through ICANN’s accountability mechanisms.

I further request that ICANN provide substantive answers to these questions no later than 17 September 2025, to ensure procedural fairness and accountability.

Thank you for your attention.

Respectfully,

Tai Chiew Wong

* I have cc’d [email protected] to ensure my response is formally logged in ICANN’s compliance system.

From: DotCoName <[email protected]>
Date: Wed, Sep 10, 2025 at 11:32 PM
To: ICANN Contractual Compliance <[email protected]>
Cc: <[email protected]>

Subject: Clarification Request – Contradictory Claims Regarding ICANN’s Role in malaysia.build Removal

Dear ICANN Contractual Compliance,

Apart from the questions I sent to ICANN several hours ago, I would like to emphasize that two core questions remain unanswered. For clarity, I set them out in Q & A format below for your direct response:

1. Contradictory Claims Regarding ICANN’s Role

Evidence:

On email dated 1 December 2023, the .BUILD Registry informed Enom:

“We have been requested by ICANN to remove / block the domain malaysia.build from registration due to it violating Spec 5 of our Registry Agreement.”

On email dated 13 August 2025, ICANN Contractual Compliance informed me:

“Beyond the terms and exceptions explicitly provided by the RA and ICANN Consensus Policies, the ICANN organization has no contractual authority to instruct a registry operator to release a reserved name.”

On email dated 10 September 2025, ICANN Contractual Compliance further stated:

“ICANN Contractual Compliance has no authority, contractual or otherwise, to serve as an appellate body or otherwise exempt Registry Operators from compliance with certain requirements.”

Contradiction:

These statements cannot all be correct. Either:

1. a) ICANN did instruct the registry→which exceeds the contractual authority ICANN described,

or

1. b) ICANN did not instruct the registry→in which case the registry misrepresented ICANN’s authority in registrar communications.

Direct Question:

1. Did ICANN instruct the .BUILD Registry to remove or block malaysia.build?
2. If not, does ICANN consider the registry’s statement to Enom a misrepresentation, and what compliance action will ICANN take?

Procedural Irregularity & Remedy

Issue:

If either (a) ICANN acted outside authority, or (b) the registry misrepresented ICANN’s authority, then the deletion of malaysia.build was procedurally irregular and lacked a valid basis.

Direct Question:

1. Does ICANN acknowledge that such a procedural irregularity occurred?
2. In light of this, does ICANN consider restoration of the domain a possible corrective action within compliance processes?

Without clear answers to these two questions, registrants cannot rely on ICANN’s compliance framework as consistent or transparent. I respectfully request direct responses to each point by the 17 September 2025 deadline for this case.

Respectfully,

Tai Chiew Wong

* I have cc’d [email protected] to ensure my response is formally logged in ICANN’s compliance system.

From: DotCoName <[email protected]>
Date: Thu, Sep 11, 2025 at 2:38 AM
To: ICANN Contractual Compliance <[email protected]>, <[email protected]>
Cc: <[email protected]>

Subject: Follow-up on Case [01448650] – Audit Timeline Clarification for malaysia.build

Dear ICANN Contractual Compliance,

Further to my previous emails of 10 September 2025, I must additionally raise concerns regarding ICANN’s reliance on the October 2023 Audit Program, which was disclosed for the first time in your 10 September 2025 correspondence.

My original complaint was filed on 11 July 2025. It has now been two months since that filing, yet only at this late stage has ICANN introduced the audit as the explanation for the removal of malaysia.build. This delay raises critical questions: does ICANN really need two months to identify and disclose audit findings related to my domain’s deletion, if that was truly the cause?

1. Delayed Disclosure
2. ICANN’s 13 August 2025 response to me contained no mention of any audit findings, despite my direct questions regarding the basis of malaysia.build’s removal.
3. Only in ICANN’s 10 September 2025 reply—two months after my original complaint—was the Audit Program cited.

If the October 2023 Audit Program was genuinely the cause, why was this not disclosed immediately when I first raised the issue in July 2025?

2. Audit Program Timeline
3. ICANN’s Audit Program has existed since 2012. If malaysia.build was always considered “reserved,” why did no earlier audit (2014–2022) identify this?
4. The domain was registered, renewed, and actively used for nearly a decade. Why was it only flagged in 2023, and why did ICANN wait until September 2025 to cite the audit as justification?

This sequence of events strongly suggests a retroactive justification, not a genuine contemporaneous audit finding.

3. Serious Doubt About Transparency

While ICANN’s Contractual Compliance Audit Program is a legitimate initiative, the way it has been presented in this case raises serious doubts. The sudden introduction of the audit—two months after my complaint and nearly two years after the audit allegedly began—creates the appearance that the Audit Program is being used as a convenient post hoc excuse rather than the true, timely basis for action.

This raises a material question: is ICANN being fully transparent in its communications, or is the Audit Program being invoked selectively to rationalize the unexplained deletion of malaysia.build? Without documentary proof, the latter interpretation cannot be ruled out and risks amounting to a misrepresentation of fact.

4. Request for Documentary Proof

To verify that the October 2023 Audit Program was in fact the reason for removal, I respectfully request:

1. A copy of the October 2023 Audit findings that specifically reference malaysia.build.
2. The exact date when malaysia.build was first flagged during the audit.

iii.            A copy of the remediation notice (or equivalent communication) issued to the .BUILD registry regarding malaysia.build.

1. The date on which ICANN required or instructed the registry to act on this audit finding.

Without this documentation, ICANN’s explanation remains unsubstantiated.

5. Next Steps

Given the conflicting explanations already on record, I respectfully request that ICANN provide the above documents and answer my questions exactly as asked—not with general references—no later than 17 September 2025. Failure to do so will only reinforce the perception of incomplete disclosure and lack of accountability.

Respectfully,

Tai Chiew Wong

* I have cc’d [email protected] and [email protected] to ensure my response is formally logged in ICANN’s compliance system.

From: DotCoName <[email protected]>
Date: Fri, Sep 12, 2025 at 2:15 AM
To: ICANN Contractual Compliance <[email protected]>
Cc: <[email protected]>

Subject: Urgent Clarification – Contradictory Explanations, Lack of Registrant Notification & Case Closure Risk

Dear ICANN Contractual Compliance,

This is my fourth follow-up in relation to ICANN’s 10 September 2025 correspondence on the removal of malaysia.build.

Further to my previous correspondence, I must raise additional concerns regarding the handling of my complaint on the removal of malaysia.build.

1. Direct Contradiction Between Registry and ICANN

The .BUILD registry’s email to eNom on 1 December 2023 stated:

“We have been requested by ICANN to remove / Block the domain…”

This wording indicates a direct, specific instruction from ICANN regarding malaysia.build.

By contrast, ICANN’s September 2025 explanation describes a very different process: a general compliance audit where the registry was found non-compliant and then independently chose its own remediation (deletion).

Both accounts cannot be true at the same time:

1. Registry’s Story (Dec 2023): “ICANN told us to do it.”
2. ICANN’s Story (Sep 2025): “Our audit found non-compliance, and the registry chose its own remediation.”

This fundamental contradiction demands immediate clarification, supported by documentary evidence. Otherwise, it appears that shifting justifications are being offered after the fact.

2. Delayed Disclosure of the Audit

If the October 2023 Audit Program was genuinely the reason for the deletion of malaysia.build, why was I, as the lawful registrant, never notified at the time? Silent deletion without notice undermines ICANN’s commitments to transparency and registrant trust.

Furthermore, a simple internal check should have immediately revealed the audit as the root cause when my case was first opened in July. Instead:

1. ICANN’s 13 August 2025 reply made no mention of any audit findings, despite my direct questions on the basis of the removal.
2. Only in ICANN’s 10 September 2025 correspondence—two months after my complaint—was the audit cited for the first time.

If the audit truly was the cause, why was it not identified and disclosed immediately?

3. October 2023 Audit Timeline

ICANN mentions an “October 2023 Audit round” that supposedly led to the deletion of malaysia.build. However, my complaint was filed in July 2025—almost two years later.

This raises another critical question: Why would it take nearly two years to implement audit findings if the domain was truly identified as non-compliant in 2023? Such a delay undermines ICANN’s claim that the audit was the genuine and timely cause of the deletion.

4. Request for Documentary Proof

To resolve these inconsistencies, I respectfully request that ICANN provide the following without further delay:

1. A copy of the October 2023 Audit findings that specifically reference malaysia.build.
2. The exact date when malaysia.build was first flagged during the audit.
3. A copy of the remediation notice (or equivalent communication) issued to the .BUILD registry regarding malaysia.build.
4. The date on which ICANN required or instructed the registry to act on this audit finding.

Without this documentation, ICANN’s explanation remains unsubstantiated.

5. Immediate Clarifications Required

In addition, I request ICANN to confirm:

1. Why no registrant notification was given at the time of deletion.
2. Why the audit was omitted from ICANN’s 13 August 2025 reply.
3. How ICANN reconciles the registry’s December 2023 statement (“ICANN requested removal/blocking”) with ICANN’s September 2025 explanation (“registry chose its own remediation”).
4. Why it took nearly two years from the October 2023 Audit round for ICANN to cite the audit as the basis for the deletion.
5. That this case will not be closed on 17 September 2025 unless and until ICANN has provided full and exact answers to my questions, supported by documentary evidence.

Failure to provide these clarifications and documents by 17 September 2025 will only reinforce the perception of incomplete disclosure and lack of accountability.

Respectfully,

Tai Chiew Wong

From: DotCoName <[email protected]>
Date: Mon, Sep 15, 2025 at 7:26 PM
To: ICANN Contractual Compliance <[email protected]>
Cc: <[email protected]>, <[email protected]>, <[email protected]>, <[email protected]>

Dear ICANN Contractual Compliance,

I write to inform you that, due to unresolved issues and the impending closure of Case #01448650 on 17 September 2025, I have formally escalated this matter to the ICANN Ombudsman for independent review.

This step is taken in good faith, to ensure fairness, accountability, and consistency with ICANN’s Bylaws.

I will continue to keep relevant parties copied for transparency.

Respectfully,

Tai Chiew Wong

Registrant, malaysia.build

From: ICANN Contractual Compliance <[email protected]>
Date: Tue, Sep 16, 2025 at 9:56 AM
To: [email protected] <[email protected]>

Dear TAI CHIEW WONG,

Thank you for your responses on 10 September 2025, 11 September 2025 and 15 September 2025. ICANN is reviewing your response and the documents provided, and will contact you again if further information is needed.

From: DotCoName <[email protected]>
Date: Tue, Sep 16, 2025 at 3:39 PM
To: ICANN Contractual Compliance <[email protected]>
Cc: <[email protected]>, <[email protected]>, <[email protected]>

Subject: Case 01448650 – Request for Specific Answers and Timeline

Dear ICANN Contractual Compliance,

Thank you for your reply of 16 September 2025. While I appreciate that you are reviewing my emails, I must respectfully point out that your reply does not address the specific questions or doubts I raised in the four emails I sent following your reply of 10 September 2025. This leaves fundamental issues unresolved, and I cannot consider this a standard case. I will not consider it closed until my questions are answered.

1. A Systemic Failure, Not a Simple Mistake

Your explanation of the October 2023 audit does not adequately explain or excuse the harm caused. As an ordinary registrant, I invested significant time and money over a decade. No one is expected to know the intricacies of ICANN’s audit programs or reserved names. The fact that my domain was active and renewed for ten years, with all parties—including ICANN, the registry, and the registrar and its upstream provider, Enom—profiting from my payments, points to a systemic failure of oversight.

This also raises the issue of registrar accountability. ICANN, the registry, and the registrar (and its upstream provider, Enom) accepted my payments for years, renewed my registration multiple times, and represented my domain as valid. If ICANN now says the domain was never valid, how could these parties be allowed to profit from this for nearly a decade without consequence?

This case sets a troubling precedent for every registrant in the gTLD system. If a domain, paid for and used in good faith for ten years, can be deleted without notice due to a retroactive audit, what assurance can any registrant have that their domain is truly secure? Unless ICANN provides clear accountability, this situation undermines trust in the system.

2. Suspicious Timelines and Delayed Disclosure

The way the audit was handled raises doubts about its validity. While ICANN states the audit was conducted in October 2023, I was only informed of it on 10 September 2025—after two years later. A professional organization would have notified me immediately, not months after my complaint and only after repeated requests.

To illustrate: imagine you have owned and driven the same car for nearly a decade, paying your insurance premiums on time every single year (like my nearly decade of domain renewals). One day in 2025, the car is suddenly repossessed without warning. After weeks of evasive responses, your insurance company finally tells you, “An audit in 2023 discovered a fundamental problem with your car’s VIN number that existed since the day you bought it. Therefore, we had to repossess it.”

Such an explanation would understandably cause serious concern. Why did it take nearly ten years to act on an issue that supposedly existed from the start? Why was I not informed immediately in 2023? The delayed disclosure makes the audit explanation appear more like a convenient, retroactive justification than a genuine, timely finding.

Even more concerning is the complete absence of prior notification. At no point before deletion was I warned or given the opportunity to appeal, despite being the active, paying registrant. This lack of due process is deeply troubling.

3. The Fundamental Contradiction

My primary concern remains ICANN’s contradictory role. The registry explicitly told my registrar’s provider, Enom, they were “requested by ICANN to remove / block the domain.” Yet ICANN Contractual Compliance has repeatedly stated it has “no contractual authority to instruct a registry operator.”

To put this in a clearer context, imagine you are at a supermarket checkout. The cashier tells you, “We’ve been instructed by the bank’s central fraud department to permanently disable your card because of a long-standing issue (like the reserved names list).” When you call the bank’s fraud department, they say, “We have no authority to disable a card for that reason, and we never gave that instruction” (like ICANN telling me they have no contractual authority to instruct a registry to remove a name). The bank is telling you they had no authority to take that action, but the store insists the order came directly from them.

This is not a minor miscommunication—it is a fundamental contradiction about who has the authority to act. Either ICANN instructed the removal, or the registry misrepresented ICANN’s role. Both scenarios require full transparency and accountability.

4. Unacceptable Behavior of ICANN’s Contracted Parties

I must also highlight the behavior of the parties involved. Namecheap has attributed the removal to Enom and the .BUILD Registry, then referred me to their legal department, which denied involvement. The .BUILD Registry has remained silent throughout. What steps will ICANN take to ensure its registrar and registry partners are accountable for this behavior toward an ordinary registrant?

5. My Request

Respectfully, I cannot accept this case as “standard” or subject to silent closure. Given the unresolved doubts, I request:

1. A clear deadline by which I will receive full and specific answers to my questions.
2. Assurance that my case will not be closed until these questions are directly addressed.

As I have already filed this matter with the Ombudsman, I will continue to update the Ombudsman and the ICANN Board with ICANN’s latest reply and my responses on the lack of clear accountability.

Respectfully,

Tai Chiew Wong

Cc: ICANN Ombudsman for transparency and oversight.

On Mon, Sep 22, 2025 at 10:17 PM DotCoName <[email protected]> wrote:

Subject: Request for Direct Answers Regarding malaysia.build Complaint 

Dear ICANN Contractual Compliance,

Since my initial filing on 11 July 2025, I have provided all requested evidence, including supporting documents, video recordings, and a detailed compliance violation matrix. ICANN has acknowledged receipt (e.g., on 18 August 2025). I now specifically request ICANN to answer my doubts and questions raised in this matter. For clarity, I have attached the content and evidence again with this email.

ICANN’s reply dated 10 September 2025, citing the October 2023 audit, raised more doubts and contradictions instead of resolving the matter. Following that reply, I sent four further emails seeking clarification. To date, not one of my questions has been answered.

1. A Systemic Failure, Not a Simple Mistake

The October 2023 audit does not excuse the harm caused. My domain was active and renewed for nearly a decade, with ICANN, the registry, the registrar, and Enom all profiting from my payments. If the domain was “never valid,” how could these parties profit for ten years without consequence? This undermines trust in the gTLD system.

2. Suspicious Timelines and Delayed Disclosure

ICANN says the audit took place in October 2023, yet I was only informed on 10 September 2025—almost two years later, and only after repeated requests. A professional body would have disclosed such a finding immediately. The delay makes the explanation appear retroactive and convenient, rather than timely and genuine.

3. The Fundamental Contradiction

The registry told Enom they were “requested by ICANN to remove/block the domain.” ICANN Compliance has repeatedly said it has “no contractual authority to instruct a registry operator.” Both cannot be true. Either ICANN gave such an instruction, or the registry misrepresented ICANN’s role. Both require transparency.

4. Unacceptable Behavior of ICANN’s Contracted Parties

Namecheap referred me to Enom and the .BUILD Registry. Enom pointed to ICANN. The registry has remained silent. This cycle of denial leaves the registrant—who acted in good faith for a decade—without answers or accountability. What steps will ICANN take to address such conduct?

5. Your Reply Dated 16 September 2025 – Why It Is Problematic

ICANN’s 16 September reply is a textbook example of bureaucratic deflection. It contained no substantive answers, relied on vague template language, and provided no timeline, no case reference, and no escalation path. In effect, it communicated: “We received your complaint, filed it somewhere, and hope you will give up.” This is unacceptable for an organization mandated to uphold transparency and accountability.

At this stage, I must ask ICANN directly:

Therefore, I require a direct answer to a simple, binary question: Can ICANN provide detailed answers to the specific doubts and questions I have raised, or can it not?

1. If yes, I expect those answers without further delay.
2. If no, I require a clear written explanation for ICANN’s inability to address these points.

It has now been 73 days since my complaint was first filed. I have complied fully with ICANN’s requests, yet ICANN has not provided a single substantive response. Ignoring a registrant’s doubts undermines trust in ICANN’s compliance framework.

Accordingly, I request ICANN’s detailed written reply within 7 days of this email.

This email is also copied to the ICANN Ombudsman for oversight, as the lack of engagement raises serious concerns about fairness and accountability. Unless detailed answers are provided, I will have no choice but to escalate this matter further.

I look forward to ICANN’s substantive reply.

Sincerely,

Tai Chiew Wong

Dear TAI CHIEW WONG,

Thank you for your additional communications to ICANN Contractual Compliance.

Below is a summary of the information ICANN provided you with so far, along with further details addressing your latest inquiries:

1. Your Question: “Issue: 2014 Allocation vs. Reserved Status; Was “Malaysia” on the Reserved Names List in 2014? If so, why was it allocated? If not, why is enforcement applied retroactively after a decade?”

On 7 November 2013, the Registry Operator and ICANN entered into a Registry Agreement (RA), pursuant to which the Registry Operator operates the .build generic top-level domain (gTLD). The covenants that both parties, Registry Operator and ICANN, must adhere to are set forth in this agreement, which is available at .build Registry Agreement.

According to Section 4 of Specification 5 of the .build Registry Agreement, the Registry Operator must reserve (i.e., withhold from registration) certain country and territory names, and this list of protected names includes Malaysia. The Registry Agreement also offers guidelines for registry operators to reach approval from the relevant government for the release of second-level country and territory names (see https://www.icann.org/en/contracted-parties/registry-operators/services/reserved-names/country-and-territory-names). According to the information available to ICANN regarding this matter, the Registry Operator did not seek approval for the release of this second-level domain name; instead, it released the name by mistake. Accordingly, the release of the name in 2014, after the Registry executed its RA in 2013, violated Section 4 of Specification 5 of the RA.

In August 2023, the 2023 Audit round was launched and the Registry Operator of .build was selected as an auditee. Information about the audit program is available at https://www.icann.org/resources/pages/audits-2012-02-25-en. Not all registry operators are selected for each audit round. Different registry operators are selected in different audit rounds based on different criteria. This Registry Operator had not been audited before, nor had ICANN received a complaint or indications of the improper release of this name prior to the 2023 Audit.

You asked why enforcement was “applied retroactively after a decade”. Please note that there was no retroactive enforcement. The obligation was in effect in 2014 and remains in force; it has been enforced consistently throughout the years. Registry Operators are expected and required to comply with their Registry Agreements without ICANN’s intervention. Enforcement actions are taken only when noncompliance is detected, and it was during the 2023 Audit that this particular violation was discovered.

Upon identifying the noncompliance and notifying the Registry Operator, the Registry Operator presented ICANN with remediation measures to resolve the noncompliance with its Registry Agreement. In this case, the remediation measures proposed by the Registry Operator included the deletion and reservation of the protected name that had been erroneously released.

ICANN’s agreements contain multiple requirements designed to protect registrants, including provisions to ensure transparency about the terms and conditions applicable to domain name registrations. This includes the obligation in the Registrar Accreditation Agreement (RAA) for registrars to enter into an agreement with each registrant that contains certain mandatory terms. Section 3.7.7.11 of the RAA mandates the registrar to include it its registration agreement with registrants that: “The Registered Name Holder shall agree that its registration of the Registered Name shall be subject to suspension, cancellation, or transfer pursuant to any Specification or Policy, or pursuant to any registrar or registry procedure not inconsistent with any Specification or Policy, (1) to correct mistakes by Registrar or the Registry Operator in registering the name or (2) for the resolution of disputes concerning the Registered Name.” In this case, malaysia.build was deleted and reserved to correct the mistake by the Registry Operator in registering the domain name.

The registration agreement you entered into with the registrar when registering the domain name was required, pursuant to the terms of the registrar’s agreements with ICANN, to include this information.

2. Your Question: “Issue: Procedural compliance; Why was the domain removed without (a) an EPP code and (b) pre-deletion notice? Do the registrar’s inconsistent responses constitute RAA non-compliance under §§3.4.3 and 3.18?”

As explained above, the Registry Operator deleted the domain name and reserved it to correct an erroneous release that put the Registry Operator out of compliance with its Registry Agreement.

According to Section 3.4.3 of the RAA that you reference in your question, registrars must make specified data, information, and records available to ICANN during the term of the agreement and for two years after. Section 3.18 of the RAA refers to a registrar’s obligation to investigate and respond to abuse reports and to publish abuse contact details. These sections are not relevant to the present case. There is no indication that the registrar failed to comply with these or any other requirements in the RAA. Additionally, there is no RAA obligation to send a prior notification to the registrant when domain names are deleted due to the correction of mistakes.

Information about registrant rights and responsibilities, including information that must be made accessible to registrants, can be found at https://www.icann.org/resources/pages/benefits-2013-09-16-en.

There are also requirements regarding notifications related to the expiration of domain names that may subsequently be deleted; however, these do not apply here, as the domain name did not expire.

Please note that neither the Transfer Policy, which contains requirements related to the inter-registrar and inter-registrant transfers, nor the Expired Registration Recovery Policy (ERRP) apply to this case (although you referenced them in prior communications). This is because the domain name was neither transferred nor deleted due to its expiration.

3. Your Question: “Contradictory Claims of ICANN’s Role; Did ICANN instruct the registry to remove the domain, or did the registry misrepresent ICANN’s role to justify the removal?”

ICANN Contractual Compliance enforces the specific requirements outlined in the RAA, the RAs, and ICANN Consensus Policies.

ICANN informed you that, beyond the terms and exceptions explicitly provided by the RA and ICANN Consensus Policies, ICANN has no contractual authority to instruct a registry operator to delete or release a domain name. ICANN also provided you with information about the requirements in the RA to reserve the label “Malaysia,” the 2023 Audit, the detection of the violation, communication with the Registry Operator, and the subsequent deletion of the domain name by the Registry Operator to correct its noncompliance.

If the Registry Operator releases a domain name, that must be protected in accordance with Section 4 of Specification 5 of the RA, without obtaining approval from the relevant government that is a violation of its RA. The options to be compliant are outlined in the RA, and further explained at

https://www.icann.org/en/contracted-parties/registry-operators/services/reserved-names/country-and-territory-names#reserved

ICANN Contractual Compliance does not have the authority to exempt a registry operator from complying with the requirements of the RA. Similarly ICANN has no authority, contractual or otherwise, to require a registry operator to choose one option over the other (i.e., reserving vs. seeking authorization) where both options are compliant with the RA; ICANN assesses that the registry operator is compliant with the relevant agreement.

4. Your Question: “Issue GAC Consultation Requirement; Was Malaysia’s GAC-designated contact consulted/notified before allocation (2014) or removal (2023)?

ICANN Contractual Compliance detected a violation of the Registry Agreement and presented its findings to the Registry Operator, including the specific requirement that was not met. The Registry Operator did not provide any information to ICANN indicating whether it had sought approval from Malaysia’s representative in ICANN’s Governmental Advisory Committee (GAC) to release the domain name. While there is no contractual obligation for a registry operator to notify ICANN when such approval is obtained, if a potential violation is detected and ICANN inquires about it, the registry operator must provide evidence that approval was obtained if the name was released. In this case, the Registry Operator did not provide this information to ICANN and stated that the release had been made in error which it subsequently corrected.

5. Your Question: “Cross-TLD Enforcement Consistency; Why is malaysia.build removed while peru.travel and greece.travel remain active under other new gTLDs? How does ICANN ensure consistent enforcement?”

The Audit Program is conducted twice a year: once for registries and once for registrars. Parties are selected based on multiple factors; not all registries or registrars are audited during each round. All requirements are reviewed and enforced equally across all audited parties, in accordance with their agreements with ICANN.

In addition, ICANN Contractual Compliance investigates noncompliance issues through the processing of external complaints. There is an established process that ICANN follows; details can be found at https://www.icann.org/resources/pages/approach-processes-2012-02-25-en, and this process is applied consistently across all registrars and registry operators.

ICANN has not received a complaint regarding peru.travel or greece.travel, nor had it otherwise detected the release of these domain names. Please confirm whether your intention is to submit a formal complaint about the release of these two domain names.

6. Your Question: “Issue Transparency, Notice & Appeal; What notification or appeal mechanisms exist for registrants in Spec 5 enforcement cases? Was the registry’s silence and lack of response consistent with ICANN’s principles of transparency and accountability?”

In your previous communications, you also inquired about why registrants are not informed about the audit process.

Information about the ICANN Contractual Compliance Audit Program can be found at: https://www.icann.org/resources/pages/audits-2012-02-25-en. After each audit is completed, ICANN Contractual Compliance publishes a final report detailing the audit results. The final report for the August 2023 audit is here.

Registries and registrars are notified in advance when they are selected for an audit. ICANN does not have information about individual registrants, nor does it have the authority to contact registrants directly. ICANN has contracts with registrars and registry operators and from these contracts ICANN derives its enforcement authority.

Registrars and registry operators are expected and required to comply with the RAA, the RA, and ICANN Consensus Policies without the need for enforcement by ICANN. These agreements and policies include requirements designed to preserve the stability, security, and resiliency of the Domain Name System and to protect the rights of registrants and other parties, such as the countries and territory whose names are protected (reserved) in accordance with Section 4 of Specification 5 of the RA.

ICANN Contractual Compliance does not have the authority to exempt a registry operator from complying with the requirements of the RA. Similarly, ICANN has no authority, contractual or otherwise, to require a registry operator to choose one compliant option over another (e.g., reserving vs. seeking authorization) when both options comply with the RA. ICANN’s role is to assess whether the registry operator is in compliance with the relevant agreement.

There is no appeal mechanism for registrants related to Specification 5 under the RA. ICANN cannot provide you with legal advice regarding whether other remedies may exist if you believe the Registry Operator or registrar violated their agreements with you; ICANN is not a party to those agreements.

Your communication dated 10 September 2025 included questions regarding the ICANN Audit, concerns about “retroactive” and “selective” enforcement, and requests for clarification on these issues. You reiterated similar concerns in subsequent emails. We have addressed your questions in our responses above, specifically referencing the points you identified in your chart. You concluded your message by requesting confirmation of contractual compliance, procedural obligations, and accountability under the RA, RAA, Transfer Policy, and GAC-related requirements. As detailed above, we have provided explanations for each of these areas.

Please be assured that we have thoroughly reviewed your questions and have responded multiple times. While ICANN strives to be as transparent and supportive as possible, we must operate within the limits of contractual authority.

We have provided you with all the information at our disposal regarding the questions you presented and the matter at hand. There is no indication that a registry operator or a registrar failed to comply with an ICANN policy and agreement. Accordingly, ICANN Contractual Compliance does not have the authority to take any action in this matter. Nevertheless, we remain available should you have any further questions that have not already been presented and addressed. If so, please let us know by 12 Nov 2025.

If you have any additional questions, please send them via reply email (no more than 20 MB total) and do not change the email subject heading. Please provide any records as attachments in .CSV, .PDF, .DOC(X), .XLS, .XLS(X) or .TXT formats.

If we do not hear from you by 12 Nov 2025, we will close this case.

Sincerely,

ICANN Contractual Compliance

Case Number 01448650 – Additional information for Reserved Names complaint re: [ ref:!00D6106tJk.!500Rm0ouQhV:ref ]

DotCoName <[email protected]>	Wed, Nov 5, 2025 at 10:04 PM
To: ombuds <[email protected]>, [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected] Cc: [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], ICANN Contractual Compliance <[email protected]> Bcc: [email protected], Namecheap Domains Support Team <[email protected]>, [email protected], [email protected], Namecheap Risk Management Team <[email protected]>, Namecheap Legal & Abuse Team <[email protected]>, [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected]
TO: ICANN Ombudsman, Board, Malaysia GAC Representative, MCMC Subject: Case #01448650 – ICANN Responded in 9 Hours After Public Campaign, Ignored 117 Days + Multiple Deadlines – Systemic Accountability Failure Proven Date: 5 November 2025 From: Wong Tai Chiew (IC# 710708-13-5207), Former Registrant – malaysia.build Case: #01448650 EXECUTIVE SUMMARY FOR IMMEDIATE ACTION This case demonstrates that ICANN’s accountability mechanisms require public shaming to function – a finding that should alarm every stakeholder in the multi-stakeholder model. What happened: ICANN Contractual Compliance ignored 117 days of internal process, my formal 22 September deadline, 34 days of Ombudsman involvement, and my final 4 November deadline—but responded within 9 hours of my public accountability campaign and complaint to Malaysia’s GAC representative. Why it matters: This proves ICANN’s accountability system only functions when publicly pressured, not through its own internal mechanisms—a fundamental governance failure with implications for all registrants and national sovereignty over country names. What’s needed now: Ombudsman: Open formal investigation within 24 hours (117-day delay violates your own SLA) Board: Acknowledge receipt and initiate independent review within 24 hours Malaysia GAC/MCMC: Determine if Malaysia’s sovereign name was mishandled in violation of ICANN agreements The evidence is irrefutable. The timeline below proves everything. PART 1: THE UNDENIABLE PROOF – TIMELINE OF INSTITUTIONAL FAILURE Date Event ICANN Rule/Standard Violated 11 Jul 2025 Case #01448650 opened — 13 Aug 2025 ICANN denies authority to instruct registries Contradicted by Registry’s 1 Dec 2023 email: “requested by ICANN” 19 Aug 2025 Comprehensive evidence submitted (11 attachments) — 10 Sep 2025 ICANN introduces “October 2023 Audit” (61 days late) Audit Transparency Policy – why hidden for 61 days? 16 Sep 2025 Last Compliance reply (template) — 22 Sep 2025 MY FORMAL 7-DAY DEADLINE TO COMPLIANCE IGNORED 26 Sep 2025 Formal 48-hour demands to Namecheap, Enom, .build Registry All ignored 1 Oct 2025 Ombudsman escalation — 3 Oct 2025 Ombudsman: “Compliance working on detailed response” — 14 Oct 2025 Ombudsman acknowledges escalation, “waiting for Compliance” Continued silence → Violation of Ombudsman SLA (3–5 working days) 19 Oct 2025 100-day status update to Ombudsman No response (violates Ombuds 3-5 day SLA) 29 Oct 2025 15 direct questions + 1 Nov deadline to Ombudsman — 1 Nov 2025, 17:00 MYT 1 NOV DEADLINE MISSED Ombudsman SLA violated (3-5 days) 3 Nov 2025 Ombudsman: “May or may not respond before 4 Nov” Admits no binding timeline exists 4 Nov 2025, 24:00 MYT FINAL ABSOLUTE DEADLINE IGNORED 5 Nov 2025, 00:54 MYT I LAUNCH PUBLIC CAMPAIGN + FILE MALAYSIA GAC COMPLAINT — 5 Nov 2025, 10:10 MYT COMPLIANCE RESPONDS – 9 HOURS AFTER CAMPAIGN After 117 days + ignored deadlines LET THE RECORD SHOW: ICANN Contractual Compliance ignored: 117 days of internal process My 22 September 7-day deadline 34 days of Ombudsman involvement My final 4 November deadline But responded within 9 hours of: Public accountability campaign launch Formal complaint to Malaysia’s GAC representative This is not accountability. This is reputation-driven damage control. This proves ICANN’s internal mechanisms are systemically broken. PART 2: COMPLIANCE’S “DETAILED RESPONSE” – MATERIAL CONTRADICTIONS After 117 days, ICANN Compliance’s response contains fatal contradictions that collapse under basic scrutiny: CONTRADICTION #1: August or October Audit? 10 September 2025 email: “The October 2023 Audit round was launched…” – see https://loss.co/icann-contractual-compliance-complete-email-trail/#109 5 November 2025 email: “The final report for the August 2023 audit is here.” Which is it? This is not a typo—this is a two-month discrepancy in the same case regarding the audit that supposedly justifies deleting my domain. ICANN demands precision from registrants but cannot keep its own audit timeline straight. CONTRADICTION #2: Impossible Timeline Compliance’s claim: August 2023 audit detected violation Actual deletion date: 5 December 2023 Gap: 3+ months after audit completion How does an audit from August trigger a deletion in December? This timeline makes no logical sense. Audits are completed and reported within weeks, not months later. CONTRADICTION #3: ICANN’s Authority 13 August 2025 (ICANN): “ICANN organization has no contractual authority to instruct a registry operator to release a reserved name.” 1 December 2023 (Registry to Enom): “We have been requested by ICANN to remove / Block the domain malaysia.build.” 5 November 2025 (ICANN): Claims there’s no contradiction because ICANN “detected” violation and “presented findings” but didn’t “instruct.” This is semantic evasion. When ICANN notifies a Registry of noncompliance requiring remediation, the functional result is indistinguishable from an instruction. The Registry’s own words were “requested by ICANN.” Demand: Provide the exact text of ICANN’s communication to .BUILD Registry regarding malaysia.build. This document will resolve the contradiction definitively. PART 3: THE SPECIFICATION 5 CATCH-22 – WHY IT’S NOT A VALID DEFENSE Compliance’s entire defense rests on Specification 5 (country name reservation). But this defense creates an impossible Catch-22 that exposes systemic failure: The Registry’s Admission Compliance’s quote: “The Registry Operator… stated that the release had been made in error which it subsequently corrected.” Compliance’s quote: “malaysia.build was deleted and reserved to correct the mistake by the Registry Operator in registering the domain name.” Compliance’s quote: “…deletion and reservation of the protected name that had been erroneously released.” The Impossible Logic IF Spec 5 truly prohibited “malaysia.build” in 2014: The Registry’s systems should have blocked it at registration (this is what technical safeguards are for) The fact that it was accepted and renewed 10 times over 3,287 days proves system failure The mistake was institutional, not registrant-caused I, as registrant: Registered through proper ICANN-accredited channels (29 April 2014) Made 10 consecutive annual renewal payments (2014-2023) Received 10 confirmations of registration, renewal, WHOIS publication, DNS resolution Had no reason to suspect any violation Invested 30+ months in commercial development Operated in complete good faith The Implausibility of “Oversight” Malaysia is: One of fewer than 200 countries worldwide A G20 member state Subject of massive international coverage in 2014 (MH370 tragedy – March 2014, weeks before my registration) Subject of ongoing international coverage 2015-2023 (1MDB scandal) How could the Registry “miss” Malaysia as a country name for 3,287 days? A simple Google search for “ISO 3166 country list” yields results in seconds. The Registry was contractually bound to implement Spec 5 protections. Yet they: Accepted my registration in 2014 Processed 10 renewals (2014-2023) Published 10 WHOIS records Enabled 10 years of DNS resolution Collected fees from me, Namecheap, Enom, the .build Registry and ICANN Then suddenly in 2023: “Oops, our mistake—domain deleted, no notice, no compensation.” Legal Principle: Estoppel In law, this is called estoppel (or legitimate reliance): When an authority enables a party to rely on something for many years, it cannot later revoke it without: Due process (notice, opportunity to be heard) Compensation for reliance damages Good faith dealings All parties profited (Namecheap, Enom, the .build Registry, ICANN) for 10 years. Why should the registrant bear 100% of financial harm? Real-World Analogy Landlord scenario: You rent an apartment for 10 years Landlord accepts rent, renews lease 10 times Year 10: “Our lease always prohibited pets—you’re evicted immediately, no notice, no refund” You: “You approved my pet deposit, accepted 10 years of rent knowing I had a dog, renewed the lease knowing I had a dog. You can’t invoke that rule NOW without compensating my reliance.” Parking scenario: You park in same spot for 9 years Authority issues permits, collects fees, renews annually Year 10: They tow your car—”This was always a no-parking zone” Their Catch-22: If always no-parking, why issue 10 permits? If it only became no-parking now, retroactive enforcement is unlawful. Either way, remedy is owed. Why Spec 5 Defense Fails Compliance cannot simultaneously claim: Spec 5 prohibited malaysia.build in 2014 (so why was it accepted?) The Registry made an “error” in 2014 (so it’s the Registry’s fault, not mine) I should bear 100% of financial losses (why?) No remedy is available (how is this just?) This Catch-22 means at least one of these must fail: Either the rule didn’t apply, OR The Registry violated its contract, OR ICANN failed its oversight function, OR Remedy is owed to the good-faith registrant You cannot escape all four. THE ADMISSION THAT DESTROYS THEIR DEFENSE Compliance’s response contains this devastating admission: The Registry Operator did not seek approval for the release of this second-level domain name; instead, it released the name by mistake. This confirms: ·         The violation was institutional (Registry error), not registrant misconduct ·         All harm stems from third-party failure, not my actions ·         ICANN now punishes the victim rather than fixing the system that failed When a bank makes an accounting error, it doesn’t seize customer assets to correct its mistake. When a government agency errs, it doesn’t punish citizens for bureaucratic failures. Why does ICANN’s framework allow this? PART 4: CRITICAL UNANSWERED QUESTIONS REQUIRING DOCUMENTARY EVIDENCE After 117 days, Compliance still refuses to provide basic evidence: DEMAND 1: Audit Documentation Complete audit report section referencing malaysia.build specifically Specific finding that flagged the domain Date noncompliance was detected Date Registry was notified Your generic audit link mentions nothing about malaysia.build DEMAND 2: ICANN-Registry Communications Exact text of ICANN’s notification to .BUILD Registry (Oct-Dec 2023) Registry’s proposed remediation plan ICANN’s acceptance/approval Any discussion of registrant notification requirements This resolves the “authority” contradiction definitively DEMAND 3: Evidence of Registrant Notification Any attempt by Registry to notify me before deletion Any requirement ICANN placed on Registry to notify registrants Any guidance ICANN gave Registry on handling existing registrations Compliance admits: “there is no RAA obligation to send a prior notification to the registrant when domain names are deleted due to the correction of mistakes.” But whose mistake? Not mine. Why should the registrant bear all losses for the Registry’s system failure? DEMAND 4: Explanation of Enforcement Inconsistency Compliance’s quote: “ICANN has not received a complaint regarding peru.travel or greece.travel, nor had it otherwise detected the release of these domain names.” These domains: peru.travel: Registered 2006, still active (19+ years) greece.travel: Registered 2012, still active (13+ years) malaysia.build: Registered 2014, deleted 2023 (9 years) Questions: Why did audits not detect peru.travel / greece.travel if audits systematically review Spec 5 compliance? This proves enforcement is reactive (complaint-driven) not proactive (audit-driven) as claimed Why should I trigger complaints against other innocent registrants who acted in good faith like me? This is selective, inconsistent enforcement. DEMAND 5: EPP Transaction Logs EPP deletion command for malaysia.build Authorization chain showing who ordered deletion Registry system logs showing deletion event Proof deletion occurred on 5 December 2023 (not earlier/later) ICANN operates the technical infrastructure. These records exist in your systems. DEMAND 6: Explanation of 61-Day Audit Disclosure Delay Timeline: 11 July 2025: I file complaint 13 August 2025: ICANN responds (no mention of audit) Multiple emails exchanged (no mention of audit) 10 September 2025: ICANN suddenly introduces “October 2023 Audit” explanation (61 days after case opened) Why the 61-day delay? The audit information was instantly available in your systems. A simple database query using “malaysia.build” would reveal audit flags immediately. This delayed disclosure appears retroactive—a convenient explanation offered only after I submitted extensive evidence of procedural violations on 19 August 2025. PART 5: THE DUE PROCESS VOID Compliance’s admission: “There is no appeal mechanism for registrants related to Specification 5 under the RA.” This confirms a complete absence of due process: No prior notice of alleged violation before deletion No opportunity to contest the alleged “reserved status” No appeal process after deletion No remedy available even for good-faith registrants ICANN disclaims responsibility for fixing the harm Compare to legitimate regulatory frameworks: Framework Due Process Rights ICANN Spec 5 Criminal law Notice, hearing, appeal ❌ None Administrative law Right to be heard before adverse action ❌ None Consumer protection Right to dispute decisions ❌ None Contract law Right to cure before termination ❌ None Domain expiration 5-day notice before deletion (ERRP) ❌ None Domain transfers Authorization required (Transfer Policy) ❌ None Why do domains deleted for expiration get 5 days notice, but domains deleted for “mistakes” get zero notice? Why do domain transfers require explicit authorization, but domain deletions require nothing? This is a procedural void that makes ICANN’s “registrant protection” claims meaningless. PART 6: QUESTIONS FOR MALAYSIA GAC REPRESENTATIVE & MCMC As Malaysia’s official representatives in ICANN’s Governmental Advisory Committee and national telecommunications regulator, you should be aware: Issue 1: Was Malaysia’s Sovereign Name Protected or Exploited? Specification 5 exists to protect countries’ sovereign names. But in this case: 2014: Registry accepted registration of “malaysia.build” despite Spec 5 2014-2023: All parties (Registry, Upstream/Downstream Provider, Registrar, ICANN) profited from my payments for 9+ years 2023: Domain suddenly deleted based on “audit findings” with no registrant notice 2025: ICANN disclaims any responsibility to remedy harm Questions for Malaysia GAC: Was Malaysia’s GAC representative consulted before the 2014 registration was allowed? Was Malaysia’s GAC representative consulted before the 2023 deletion? Did the Registry seek Malaysia’s approval at any point (as Spec 5 permits)? Is Malaysia aware that its country name is being used as justification to harm good-faith registrants without due process? Issue 2: The “malaysia.build” Domain Was Promoting Malaysia The domain was being developed to: Showcase Malaysian real estate developments Promote Malaysian property market internationally Support Malaysian businesses and agents Integrate with Malaysian payment systems (FPX via PayNet) Feature Malaysian-specific property attributes (land titles, Feng Shui, etc.) Demo site: https://malaysia.sibu.design Evidence: https://loss.co Video Demos: https://loss.co/videos This was not abuse of Malaysia’s name—it was promotion of Malaysia’s interests. Question: Does Malaysia’s government want ICANN’s framework to enable deletion of domains promoting Malaysian commercial interests—especially when the registrant is Malaysian? Issue 3: Implications for National Digital Sovereignty If ICANN’s framework permits: Registration of country names for 9+ years Sudden deletion without notice based on retroactive “audits” No consultation with affected countries No remedy for good-faith registrants Then no country’s digital sovereignty is protected. Any domain using country names can be deleted arbitrarily under the guise of “mistake correction.” This undermines the GAC’s entire purpose in ICANN governance. PART 7: THE OMBUDSMAN’S PROCEDURAL CATCH-22 Ombudsman’s position: “I cannot open a case until you have received a conclusion or decision from Contractual Compliance.” But this creates an impossible situation: Compliance delayed 117 days without concluding My complaint to Ombudsman was specifically about Compliance’s failure to respond Requiring Compliance to conclude before investigating why they won’t conclude is circular logic This means the Ombudsman cannot investigate delay, non-response, or institutional evasion The proof: Compliance only responded after public pressure—exactly what the Ombudsman is supposed to prevent. The Ombudsman’s rule makes it impossible to address the core accountability failure it was established to remedy. PART 8: THE BOARD’S GOVERNANCE FAILURE The ICANN Board was copied on: 28 October: 111-day institutional failure documented 1 November: Formal deadline to Ombudsman missed 3 November: Ombudsman’s “may or may not” non-response 4 November: Final absolute deadline before public campaign Board response: Silence. But within 9 hours of public campaign and GAC complaint: Compliance responds. This proves: Board oversight is ineffective when internal processes fail ICANN responds to external pressure, not internal accountability The multi-stakeholder model fails when all internal mechanisms fail simultaneously This is a Board-level governance failure requiring immediate action. PART 9: FORMAL DEMANDS WITH 24-HOUR DEADLINES TO OMBUDSMAN ELIZABETH FIELD (Within 24 hours of receipt): DEMAND 1: Open formal Ombuds case immediately investigating: 117-day delay in violation of Compliance Process standards Contradictory statements about ICANN’s authority (RAA §3.12) Material inconsistencies in audit timeline (August vs. October) Failure to provide requested documentary evidence after 117 days DEMAND 2: Request Compliance attach the following to case file: Complete audit findings for malaysia.build ICANN-Registry email communications (Oct-Dec 2023) EPP deletion transaction logs Evidence of any registrant notification attempts DEMAND 3: Provide written explanation of: Why 117-day delay does not constitute procedural failure warranting immediate investigation Why “cannot open case until Compliance concludes” rule doesn’t prevent investigating delay itself Why Ombudsman’s 3-5 day response SLA was violated multiple times in my case Your silence beyond 24 hours will be treated as confirmation that the Ombudsman cannot function when ICANN’s internal processes fail. TO ICANN BOARD (Within 24 hours of receipt): DEMAND 1: Acknowledge receipt of this email in writing DEMAND 2: Initiate independent review of: Why Contractual Compliance required 117 days + public pressure to respond Why multiple formal deadlines were ignored Whether Compliance’s “detailed response” meets ICANN’s transparency standards Why Ombudsman’s procedural rules prevent investigation of delay DEMAND 3: Publish public statement addressing: Whether registrants have due process rights in Specification 5 enforcement Whether good-faith registrants can be held liable for Registry system failures What remedies exist when all internal accountability mechanisms fail Your silence beyond 24 hours will be documented as Board-level governance failure. TO MALAYSIA GAC REPRESENTATIVE & MCMC (Response requested within reasonable time): REQUEST 1: Investigate whether Malaysia’s sovereign name was properly protected: Was the GAC representative consulted in 2014 or 2023? Did the Registry seek Malaysia’s approval before registration or deletion? Does the current framework adequately protect Malaysia’s digital sovereignty? REQUEST 2: Provide guidance on whether: Domain was being used to promote or harm Malaysia’s interests Malaysian registrants should have additional protections GAC should recommend reforms to ICANN’s Specification 5 process REQUEST 3: Consider whether to: File formal complaint with ICANN about Registry’s handling Request Board review of Specification 5 enforcement practices Raise this case at next GAC meeting as policy issue PART 10: WHAT HAPPENS NEXT This email will be published soon at: https://loss.co My public accountability campaign continues through: Domain registrant advocacy organizations Documenting this as case study in ICANN accountability failure Supporting systemic reforms to protect registrants Internet governance stakeholders Submitting public comments in ICANN policy processes Engaging with technical community on due process standards Media coverage Sharing story of how ICANN’s accountability system fails registrants Documenting 117-day delay + ignored deadlines + 9-hour response after public pressure Academic research Providing case materials to researchers studying ICANN governance Supporting empirical analysis of accountability mechanism effectiveness International regulatory attention Engaging with government representatives beyond Malaysia Highlighting sovereignty concerns in country name protections The 22 September deadline was ignored. The 4 November deadline was ignored. The “detailed response” after 117 days is contradictory and evidence-free. ICANN’s accountability system is demonstrably broken. The internet is watching. CONCLUSION This case is no longer just about one domain. It’s about: Whether ICANN’s accountability mechanisms function or merely create the appearance of oversight Whether registrants who act in good faith have meaningful protections Whether “mistake correction” provisions can be abused to delete long-standing domains without due process Whether ICANN responds to internal accountability or only external pressure Whether countries’ sovereign names are protected or weaponized against good-faith users The timeline proves everything: 117 days of internal process ignored Multiple formal deadlines ignored 34 days of Ombudsman involvement produced nothing 9 hours after public campaign: Compliance responds When internal accountability fails this comprehensively, external transparency and reform advocacy are not preferences—they are necessities. Your 24-hour response windows begin upon receipt. For the complete documentary record—including all correspondence, evidence, and timelines referenced below—please visit the public repository at: https://loss.co The repository contains, among other items: 1.    The Complete Email Correspondence from 11 July to 5 November 2025, documenting the entire 117-day delay. 2.    Evidence of 10 Consecutive Renewal Payments and Confirmations, proving lawful registration and good-faith reliance for nearly a decade. 3.    The Registry’s 1 December 2023 Email to Enom, explicitly stating the domain removal was “requested by ICANN.” 4.    Proof of Substantial Commercial Development, demonstrating a 30+ month investment and the significant harm caused. 5.    A Detailed Timeline of all formal deadlines set and subsequently ignored by all parties. 6.    Screenshots of peru.travel and greece.travel remaining active, providing clear evidence of inconsistent and selective enforcement of Specification 5. This public repository serves as the definitive evidence base for this case of systemic failure. Respectfully but firmly, WONG TAI CHIEW Former Registrant – malaysia.build +60 19-828 0131 [email protected] Complete case documentation: https://loss.co Case #: 01448650 Date: 5 November 2025

To: ombuds <[email protected]>, [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], ICANN Contractual Compliance <[email protected]>

Cc: [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected],  [email protected], [email protected], [email protected], [email protected], [email protected]

Bcc: [email protected], Namecheap Domains Support Team <[email protected]>, [email protected], [email protected], Namecheap Risk Management Team <[email protected]>, Namecheap Legal & Abuse Team <[email protected]>, [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected]

SUBJECT: FINAL NOTIFICATION: 24-HOUR ACCOUNTABILITY DEADLINE FAILED – COMPLETE INSTITUTIONAL COLLAPSE CONFIRMED

6 November 2025

This serves as my final notification regarding Case #01448650.

The 24-hour deadline was the last opportunity for any party in this multi-stakeholder system to demonstrate basic accountability. That deadline has now passed.

The result? A coordinated, institutional silence from every responsible party:

·         ICANN Contractual Compliance

·         ICANN Ombudsman

·         ICANN Board of Directors

·         .BUILD Registry

·         Enom

·         Namecheap

YOUR COLLECTIVE FAILURE TO RESPOND CONFIRMS THE COMPLETE COLLAPSE OF ICANN’S ACCOUNTABILITY FRAMEWORK.

1. The “Detailed Response” Was Triggered Only By External Pressure and Remains an Evidentiary Vacuum
ICANN Compliance’s email of 5 November 2025—issued only after I filed a formal complaint with Malaysia’s GAC representative and launched a public campaign—was presented as a resolution after 117 days of delay. Yet it contains no audit reports, no transaction logs, no communications with the registry, and no specific evidence for malaysia.build. How can this empty assertion, produced only under external pressure, be considered the “detailed response” promised by the Ombudsman’s office on 3 October 2025?

2. ICANN Compliance’s Position is Logically Impossible

Beyond the contradictions previously documented, your response contains this fundamental inconsistency:

You state:

“There is no indication that a registry operator or a registrar failed to comply with an ICANN policy and agreement.“

Yet you simultaneously assert:

“The Registry Operator… stated that the release had been made in error which it subsequently corrected.”

“malaysia.build was deleted and reserved to correct the mistake by the Registry Operator…”

“…deletion and reservation of the protected name that had been erroneously released.”

A registry error in releasing and maintaining a reserved name for nearly a decade constitutes a clear failure to comply with Specification 5. You cannot claim there was “no failure to comply” while basing your entire case on the need to “correct” a “mistake.” This logical impossibility voids your argument’s foundation.

3. The Accountability Framework is a Facade

The Ombudsman’s office, aware of this 117-day delay and the manifestly inadequate “detailed response,” has failed to act. The Board, copied on every escalation, has provided no oversight. The system is designed to create the appearance of accountability while being structurally incapable of delivering it.

THE SILENCE FROM ALL PARTIES SPEAKS LOUDER THAN ANY RESPONSE COULD. IT CONFIRMS THAT ICANN’S ACCOUNTABILITY MECHANISMS EXIST ONLY ON PAPER, NOT IN PRACTICE.

This concludes all internal engagement. The campaign to expose these systemic failures will continue indefinitely in the public domain. There will be no closure until meaningful accountability and reform are achieved.

 

WONG TAI CHIEW
Former Registrant – malaysia.build
Case #01448650
https://loss.co

The evidence is cataloged here. The structural solution is THE WONG CLAUSE, and it is being institutionalized.

Disclaimer: This website reflects the author’s personal account and opinions regarding the loss of access to the domain *malaysia.build*. The information presented is based on direct experience, contemporaneous records, and a good-faith belief in its accuracy at the time of publication. Mentions of companies, registrars, registries, or other organizations are included only to factually describe events and circumstances relevant to this case. These references are provided solely to factually describe documented events and communications. They should not be read as allegations of misconduct, negligence, or liability of any individual, company, or organization. The content is provided solely for informational and documentary purposes. It does not constitute legal, financial, or professional advice, and should not be relied upon as a definitive statement of fact or legal conclusion.

Corrections Policy: If any party believes that information contained on this website is inaccurate, incomplete, or misleading, they are invited to contact the author at [email protected]. All requests will be reviewed promptly and in good faith. Verified corrections, clarifications, or updates will be published transparently.

Right of Reply: Any registrar, registry, upstream provider, or organization referenced in this website is welcome to submit a written response. Such responses will be published in full, unedited, to ensure fairness and balance.

© 2025 WONG TAI CHIEW. All Rights Reserved.