Summary

  • The American Institute of Certified Public Accountants did not obtain present-day .CPA authority merely by calling its 2012 application community-based. Its community application received 11 of 16 points in Community Priority Evaluation, below the 14-point threshold. The evaluator awarded no points for nexus because the string reached materially beyond the community AICPA had defined, and no point for enforcement because the filed application lacked a coherent and appropriate appeal mechanism. Reconsideration Request 15-17 did not reopen that merits judgment; it tested whether established ICANN policy or procedure had been followed. The application status record now marks the community filing Withdrawn. ICANN Community Priority Evaluation report
  • The operative authority chain begins elsewhere. ICANN and AICPA executed a Base, Non-Sponsored Registry Agreement on 11 June 2019. The filed agreement contains Specification 11 commitments for a highly regulated sector, but no attached Specification 12; its Specification 11 also says that the application-commitment paragraph is intentionally omitted. Present eligibility therefore rests on two distinct decisions: competent authorities determine whether a credential is legally valid, while AICPA decides which authorities, credentials, applicant classes and naming rules it accepts for .CPA. Verification arrangements and registrant terms implement that boundary within, but not wholly defined by, the ICANN contract.
  • The appeal architecture is divided by claim, standing, timing and remedy. The registry-specific REDRP covers a registered name that allegedly violated name-selection rules when registered, continuing failure to satisfy eligibility rules after registration, and an allegedly improper denial of a properly submitted eligible application. The first two routes can end in cancellation, with a possible cure period of up to 14 days for continuing eligibility; the denial route can produce an order permitting registration, followed by 30 days for the successful complainant to complete remaining requirements. The policy’s ten-business-day implementation interval is expressly limited to a decision changing the status of a registered name. It should not be imported into an unregistered denial case. Abuse or security suspension, registrant arbitration, court proceedings, PICDRP or compliance enforcement, ICANN–registry arbitration and technical implementation each remain separate chains.
  • The allocation of power is therefore asymmetric. Public licensing and legally recognised professional bodies decide who may lawfully hold out as a CPA or equivalent in their jurisdictions. Under its registry eligibility policy, AICPA separately decides which authorities, credentials and applicant classes qualify for .CPA and reserves power to amend those rules. Applicants and registrars provide data; the registry or a designated provider checks it; registrars and registry systems implement domain status; and AICPA’s policy stack reserves broad powers to deny, lock, hold, transfer, suspend or cancel. The official sources reviewed for this article did not establish a published .CPA REDRP merits decision, a .CPA PICDRP determination, an ICANN compliance notice, a damages award or a court-ordered registration. Formal review access is documented; aggregate remedy performance is not.

Six records, six kinds of authority

Starting the story in 2019 creates a false continuity. AICPA signed a registry agreement, the string entered the root zone, CPA.com organised a phased launch, and licensed professionals began applying. That operational sequence can make the eventual operator look as though one grant of authority travelled intact from application to delegation. The primary record shows several decision systems instead, each answering a different question and each confined to a different remedy.

The first record is the 2012 community application. It proposed a community definition, registrant classes, phased access, enforcement powers and continuing control over policy. It is evidence of what AICPA asked ICANN to approve. It is not the present registry contract. The second record is the 3 September 2015 Community Priority Evaluation report. It decided whether that community application should escape ordinary contention by obtaining at least 14 points. It did not decide who was licensed as a CPA in any jurisdiction, and it did not award the registry to another applicant. AICPA community application

The third record is the determination on Reconsideration Request 15-17. It considered whether ICANN staff and the evaluation process had contradicted an established policy or procedure. It was not a general appellate rehearing of the CPE score. The fourth is the community application status page, which now says Withdrawn. That status does not retroactively erase the application, the CPE or the reconsideration record; it does prevent the filing from being treated as the continuing legal source of live registry restrictions. ICANN determination on Reconsideration Request 15-17

The fifth record is the executed 2019 Registry Agreement. It creates ICANN-facing rights and duties for the registry operator. ICANN records it as Base, Non-Sponsored; the filed agreement contains Specification 11 public-interest commitments and the agreement’s compliance, dispute and transition machinery, but no attached Specification 12. The sixth record is the operator’s policy stack: the Registrant Eligibility Policy, the Registration Eligibility Dispute Resolution Policy, the Acceptable Use and Anti-Abuse Policy, country terms and application guidance. Those documents govern the practical questions that an applicant or registrant encounters.

The collision among the six records is the case. The community proposal spoke in the language of a profession-led namespace. The CPE said the proposed nexus and appeal design did not justify priority. Reconsideration left that evaluation standing. The later contract did not convert the failed community text into Specification 12 obligations. The operator then built a separate policy-and-terms system for verification and appeal. AICPA appears in every stage, but its powers do not come from the same instrument at every stage. ICANN Community Priority Evaluation report

Two applications did not mean two grants of authority

AICPA filed two applications for .CPA: community application 1-1911-56672 and standard application 1-1910-48133. The reconsideration determination records that they sat in a six-application contention set. Filing twice created two procedural positions, not two rights to operate. The community filing could seek priority through CPE; the standard filing could remain in ordinary contention. Neither filing, merely by being “Active”, amounted to a registry agreement, a root-zone change or an entitlement to sell names. ICANN determination on Reconsideration Request 15-17

This distinction mattered after the CPE loss. AICPA argued in reconsideration that the community application remained Active and that requested changes should be considered. The Board Governance Committee treated “Active” more narrowly. The applications remained in the contention process; contention still had to be resolved, whether privately or through ICANN’s last-resort mechanism, before contracting and delegation. The committee’s wording is useful because status dashboards invite over-reading. “Active” described eligibility to continue through the programme. It did not certify victory, approve the registry’s business model, create contractual rights or place .CPA in the root. ICANN determination on Reconsideration Request 15-17

The public primary sources reviewed here do not establish the final private terms by which the six-way contention set was cleared. They therefore do not support a claim that AICPA won a particular private auction, paid a particular amount, obtained withdrawals through a named settlement or prevailed because another applicant accepted a stated condition. The later registry agreement proves that AICPA became the operator. It does not, by itself, reveal every legal or commercial step that removed the other applications. That gap is not a minor narrative omission. Private contention resolution allocates economic power, yet it can leave the public with only the before-and-after states: multiple applicants in contention, then one contracting operator. ICANN determination on Reconsideration Request 15-17

The existence of the separate standard application also blocks a tempting retrospective argument. AICPA’s eventual operation of .CPA does not prove that the community application was substantively vindicated. The CPE result remained a loss, reconsideration remained denied, and the community filing is now Withdrawn. The operator’s later authority must be traced to the executed contract and live policies, not backfilled into an application that did not obtain priority. ICANN Community Priority Evaluation report

The proposed community was partly a membership design

The community application described a recognisable institutional constituency, but it did not simply map the universe of people legally authorised to use “CPA”. AICPA defined the community through categories connected to its own organisational structure. The filing referred to regular members, associate members, international associates, non-CPA associates and affiliates, and it described an Irish connection through Chartered Accountants Ireland. It also anticipated controlled phases in which AICPA would hold registrations itself and later admit selected third parties. AICPA community application

That design combined three things that are often conflated. One was a legal credential: the authority, under applicable jurisdictional law, to hold out as a CPA or recognised equivalent. A second was institutional affiliation: membership or another relationship with AICPA or an approved professional body. A third was registry allocation: AICPA’s proposed decision about which eligible people or organisations could obtain which names, at which stage and under which naming rules. The community application used the profession to justify the namespace, but it also reserved extensive discretion over the namespace’s growth. AICPA community application

The application contemplated a single-registrant model in its early form and described full control over registration. It allowed AICPA to restrict, limit or expand eligible classes, govern name choice and use, control transfers and maintain approval across the domain life cycle. It also tied policy changes to protection of the AICPA brand and the proposed namespace. Those provisions explain why the application cannot be read as a neutral transcription of state licensing law. Licensing bodies determined professional status in their jurisdictions. AICPA proposed to decide whether that status, membership or affiliation translated into access to .CPA. AICPA community application

That difference also explains the later nexus problem. A string may be strongly associated with a profession and still be broader than the community an applicant has chosen to define. “CPA” can describe licensed professionals who are not members of AICPA, and the global use of the designation or recognised equivalents does not stop at the applicant’s organisational boundary. AICPA’s defined community could be coherent while the string reached beyond it. CPE evaluated that fit; it did not decide whether AICPA was a legitimate professional institution. ICANN Community Priority Evaluation report

Treating the application as a proposal rather than an operative rulebook is more than formalism. Application text can influence evaluation and may later become contractually important in a community-based agreement. But it does not automatically bind registrants years later. The question is whether the final Registry Agreement incorporated the relevant commitments. In .CPA, the filed contract’s structure is decisive: it is non-sponsored, has no Specification 12 and expressly omits the Specification 11 paragraph that would have carried application commitments or business plans into the contract. .CPA Registry Agreement record

GAC safeguards constrained the eventual operator; they did not choose it

The Governmental Advisory Committee’s 2013 Beijing Communiqué created two relevant safeguard tracks. Category 1 addressed regulated and professional sectors, including credential reliability and post-registration validity; Category 2 addressed restricted access to generic strings. ICANN’s Category 2 implementation record lists both AICPA applications. These interventions shaped what a future operator would have to promise. They did not select which of the six applicants should receive the string.

For a professional-sector string, the safeguards aimed at the reliability of credentials and the continuing validity of eligibility. A 2017 ICANN letter to professional regulators described commitments requiring compliance with applicable law, a regulator-reporting channel, credential representations, consultation where authenticity was in doubt and reporting of material changes to authorisation. The same correspondence classified .CPA as a highly regulated sector or closed-entry string in multiple jurisdictions and said the resulting commitments would be placed in Specification 11. ICANN safeguard letter of 15 September 2017

Category 2 dealt with a different risk: an applicant seeking exclusive access to a generic string for itself or affiliates. The implementation record identifies both AICPA applications in the Category 2 process. The contractual answer appears in Specification 11’s generic-string provision, which prevents exclusive registry access from being limited to a single person or its affiliates in the circumstances covered by that provision. That rule constrained the design of the registry. It did not convert governmental advice into a licence to run .CPA, and it did not make regulators co-owners of the allocation decision. ICANN Category 2 safeguards record

Regulators could supply credential data, report misuse and shape safeguards, but the programme still separated that participation from allocation. Evaluators scored CPE, ICANN reviewed process, applicants cleared contention, ICANN contracted and IANA processed delegation. The published records do not confer on a professional regulator a vote over an individual .CPA application. ICANN safeguard letter of 15 September 2017

The 2017 ICANN letter made the remedy boundary unusually explicit. It said Specification 11 commitments would be enforceable through ICANN Contractual Compliance and could be the subject of a Public Interest Commitment Dispute Resolution Procedure complaint. It separately said that the Registry Restrictions Dispute Resolution Procedure would apply if a community applicant became the registry operator. That conditional wording foreshadowed the later contract: .CPA obtained regulated-sector commitments, but the executed agreement did not carry the community-specific Specification 12 architecture. ICANN safeguard letter of 15 September 2017

CPE tested priority, not professional legitimacy

Community Priority Evaluation offered a way for a qualifying community application to prevail over other applications for the same or confusingly similar string without ordinary contention resolution. The threshold was demanding: 14 of 16 points. AICPA received 11. The evaluator awarded four points for community establishment, zero for nexus between the proposed string and the defined community, three for registration policies and four for community endorsement. ICANN Community Priority Evaluation report

The score is revealing because AICPA succeeded on the dimensions most likely to dominate public discussion. The evaluator accepted that the community was clearly delineated and that there was substantial, relevant endorsement. Those findings recognised an organised professional constituency and institutional support. Yet endorsement did not confer decision power, and community coherence did not cure a mismatch between the community and the string. ICANN Community Priority Evaluation report

The zero nexus score followed from the evaluator’s conclusion that .CPA identified people outside the community AICPA had defined. Non-AICPA certified public accountants and professionals associated with other bodies could be described by the string. The evaluator therefore treated the name as substantially over-reaching the proposed community boundary. Under the scoring rules, that finding was severe: a string could be closely associated with the profession and still fail the specific community-to-string test because the applicant’s own definition was narrower than ordinary or international usage. ICANN Community Priority Evaluation report

The lost enforcement point was equally important. The application described sanctions and continuing control, but the evaluator found no coherent and appropriate appeal mechanism. That defect was not about whether AICPA could act against a registrant. It plainly proposed extensive enforcement authority. The problem was what happened after it acted. A credible restricted namespace requires not only a gate and sanctions but also a route by which an affected party can challenge an erroneous denial or enforcement decision before an institution capable of changing the result. ICANN Community Priority Evaluation report

AICPA later referred to an appeal mechanism when seeking reconsideration and an application change. The reconsideration determination refused to treat a later or proposed addition as though it had been part of the application the evaluator scored. That response preserved a basic procedural discipline: evaluators judge the filed record under the programme rules, not an improved design introduced after a losing result. It also prevented one applicant from revising a priority claim in a way that could disadvantage the other members of the contention set after they had organised their own strategies around the existing application. ICANN determination on Reconsideration Request 15-17

CPE’s consequence was limited but executable. AICPA did not receive community priority. The report did not reject the profession, invalidate the AICPA, bar .CPA from the DNS or decide the ultimate operator. It left the application in contention. That is the first recurring lesson in the case: the institutional significance of a decision depends on the object it controls. CPE controlled priority. It did not control licensure, the final Registry Agreement or delegation. ICANN Community Priority Evaluation report

Reconsideration offered access to review, not a merits appeal

Reconsideration Request 15-17 tested a different object. AICPA challenged aspects of the CPE process and ICANN staff’s handling of a requested application change. The Board Governance Committee’s task under the then-applicable reconsideration standard was to determine whether an action or inaction contradicted an established ICANN policy or procedure. It was not authorised to substitute its own CPE score merely because the applicant disputed the evaluator’s reasoning. ICANN determination on Reconsideration Request 15-17

“Review” can mean procedural correction, legality testing, remand or a merits rehearing. Reconsideration did not combine all of those powers. The committee considered AICPA’s complaints and denied the request; access to the mechanism did not guarantee a new evaluator or score. ICANN determination on Reconsideration Request 15-17

The committee also upheld the deferral of AICPA’s requested application change. Its reasoning linked procedure to the rights of other applicants. Allowing a material post-CPE change before the challenge was resolved could alter the competitive conditions within the contention set. The decision therefore treated fairness not simply as an applicant’s right to improve its filing but as a programme interest in applying change procedures consistently across rivals. ICANN determination on Reconsideration Request 15-17

AICPA’s reliance on “Active” status failed for the same reason that application text cannot be treated as a contract. The committee explained that active applications still had to clear contention and proceed through contracting and delegation. The status label was administratively meaningful—it showed that an application had not yet been eliminated—but it did not create an entitlement to the string. A public status page can disclose where a file sits without conferring the power associated with later stages. ICANN determination on Reconsideration Request 15-17

The denial of reconsideration left the CPE result intact. It did not itself award .CPA to another applicant, require AICPA to abandon its standard application or determine the private terms of contention resolution. Nor did it establish that the missing appeal mechanism could never be created. It established only that the mechanism could not be retroactively used to change the score given to the filed community application through that reconsideration route. ICANN determination on Reconsideration Request 15-17

The present REDRP is therefore best understood as a later operational answer to the need for an eligibility appeal, not as proof that the 2012 application deserved the lost CPE point. Its text was implemented in 2020 under the operator’s live policy stack. It can now produce domain-specific remedies. It does not rewrite the 2015 evaluation history. .CPA Registration Eligibility Dispute Resolution Policy

The 2019 contract changed the legal source of authority

On 11 June 2019, ICANN and AICPA executed the .CPA Registry Agreement. ICANN’s metadata records it as “Base, Non-Sponsored”. The metadata label is not the only evidence, but the filed instrument supplies the decisive companion facts: it contains no attached Specification 12 and no operative community-based Section 2.19 package governing .CPA. .CPA Registry Agreement record

The filed PDF and searchable HTML agreement allocate several layers of power. AICPA, as Registry Operator, runs the top-level domain subject to the agreement. Registrations must be made through ICANN-accredited registrars, and the operator may establish non-discriminatory qualification criteria reasonably related to the proper functioning of the TLD. ICANN can audit compliance, investigate contractual obligations, issue breach notices and pursue the agreement’s cure, arbitration and termination mechanisms. The operator’s business relationship with registrars and its registry-service provider implements registrations, but neither replaces ICANN as the contract counterparty. executed .CPA Registry Agreement

Specification 11 is the bridge between professional-sector safeguards and the contract. It requires transparent registration policies, anti-abuse measures, compliance with applicable law, credential-related representations, regulator reporting channels, consultation where credentials are in doubt and continuing notification of material changes. Those commitments are enforceable by ICANN and through the PICDRP framework. The operator therefore cannot describe eligibility as wholly private discretion. Some outer constraints are contractual and can expose the registry to ICANN-level enforcement. executed .CPA Registry Agreement

But Specification 11 does not contain the complete .CPA eligibility code. It does not enumerate every approved state board, Canadian provincial body, Irish authority, licence database, documentary substitute, applicant class or naming rule. Those details appear, if at all, in registry policies, country terms and operational guidance. The contract requires a regulated framework; AICPA’s policy stack supplies much of the actual boundary. executed .CPA Registry Agreement

The filed .CPA Specification 11 contains another unusually important signal. Paragraph 2—the place where application commitments or business plans can be made binding—is intentionally omitted. The agreement therefore does not make the 2012 community application’s promises contractually enforceable through that paragraph. The omission reinforces the need to trace each current rule to the contract, a later policy or applicable law rather than presuming that the application travelled intact into the agreement. executed .CPA Registry Agreement

The contract also has no attached Specification 12. The 2023 global amendment makes its community clause conditional: it applies if ICANN determined, when the applicable agreement was executed, that the agreement was for a community-based TLD. In that setting, Section 2.19 and Specification 12 would require operation consistent with community registration policies and expose substantial deviations to the RRDRP. The amendment does not itself supply that predicate. ICANN’s .CPA metadata remains Base, Non-Sponsored, and the filed agreement contains no Specification 12. The supported contractual inference is therefore that the amendment did not retroactively convert .CPA into a community-based registry. 2023 Global Amendment

This boundary changes who can complain and what a panel can do. Under an RRDRP model, an established institution associated with a defined community may challenge substantial deviation from contractual registration restrictions. In the actual .CPA structure, there is no community Specification 12 to enforce through the RRDRP framework. A party alleging breach of the published Specification 11 commitments must look to ICANN Contractual Compliance or the PICDRP. A person disputing an individual eligibility decision looks to the registry-specific REDRP or other contract and court routes. The same factual dispute may touch more than one system, but the systems do not have interchangeable standing rules or remedies. ICANN Public Interest Commitment Dispute Resolution Procedure

Contracting, root-zone entry and retail launch were separate decisions

The registry agreement was executed on 11 June 2019. The IANA .CPA delegation record gives a registration date of 11 September 2019 and links a delegation report dated 21 September 2019. Those dates separate the contract from the technical and administrative steps that placed .CPA in the root. They also precede the public application phases in 2020 and 2021. .CPA Registry Agreement record

IANA’s root database calls AICPA the “Sponsoring Organisation”. That is the root-zone database’s field name; it does not convert the ICANN agreement into a sponsored registry contract. The contract metadata controls that separate classification and says Base, Non-Sponsored. The terminology illustrates why institutional records must be read according to function. IANA’s page identifies the entity responsible for the delegated top-level domain and its contacts. ICANN’s agreement page identifies the legal form of the registry contract. IANA .CPA delegation record

Delegation also did not open the namespace to every eligible professional immediately. According to the operator’s September 2020 launch announcement, licensed firms could apply during an initial period through 31 October, with a logic-based allocation method verified by an independent third party, followed by rolling allocation. A later launch-phase notice described a brand-protection phase through 31 October 2020, an early-adopter period from 5 November 2020 to 14 January 2021 and individual applications beginning 15 January 2021. CPA.com launch announcement

Those phases allocated timing and priority among eligible users. They did not delegate policy authority. A firm allowed to apply in September 2020 did not acquire a vote over which jurisdictions AICPA would later admit. An independent third party that verified allocation logic did not become the credential regulator. EnCirca’s role, described on the registry’s registrar-partner page, did not give it ownership of the eligibility rules, and a registry-service provider’s technical role did not decide the legal meaning of “CPA”. The launch chain was operational: applicant, registrar, verification process, registry and registry-service provider. The power to define the chain remained divided among public licensing law, the registry contract and AICPA’s policies. EnCirca registrar-partner page

The live eligibility chain begins with law but does not end there

The Registrant Eligibility Policy, version 1.0, took effect on 13 March 2020. It recognises persons or entities holding an active CPA or equivalent licence issued by a national, state or other regulator approved by the Registry Operator and authorised by government to regulate who may hold out under the credential. It also provides for eligible professional non-profit organisations. This wording makes applicable law and competent regulators indispensable, but it reserves a second gate for AICPA: the regulator and credential must be approved by the operator for registry purposes. .CPA Registrant Eligibility Policy

That produces a two-stage legitimacy test. First, a competent public or legally recognised professional body determines whether the person or firm holds a valid credential under the applicable jurisdictional system. AICPA cannot, through DNS policy alone, make an unlicensed person a CPA under state or national law. Second, AICPA determines whether that credentialing system has been admitted to .CPA and whether the applicant class and requested name satisfy its policies. A lawful credential is therefore necessary in the admitted programme, but not necessarily sufficient for a domain. .CPA Registrant Eligibility Policy

The policy requires information such as legal name, business name, licence number, licensing jurisdiction and expiry. It allows AICPA or a designated third party to request and verify evidence. The United States privacy and verification notice says CPA.com may collect information from registrars, public sources, licensing bodies, websites, employers, schools and data aggregators to verify eligibility, and identifies EnCirca as a possible source of application data. These documents reveal an evidence network; they do not fully disclose which service provider makes a final eligibility judgment and which merely reports a factual match.

The operator remains the policy principal. It can modify the Eligibility Policy at its sole discretion by posting changes, with a stated 15-day period before effectiveness, and the policy characterises cancellation as the registrant’s sole remedy for objection to an amendment. It also reserves authority to deny or cancel where registration would violate law, sanctions or other stated constraints. A licensing body can report that a credential has lapsed; a provider can report that a database does not match; a registrar can relay a request for evidence. But AICPA’s policies determine what those facts mean for registry access and status. .CPA Registrant Eligibility Policy

The current application guidance says the programme is available in the United States, Canada and Ireland and that denials may rest on eligibility, name selection or geography. It describes United States access for licensed CPA firms and individual state-board licensees and warns that an unlicensed firm may not use a name that amounts to unlawful holding out. That page is useful evidence of the programme as publicly described at publication. It is not an immutable jurisdiction schedule, and it does not identify every approved regulator, database or documentary substitute. .CPA application guidance

In the United States, the public-law anchor is fragmented across state boards and other approved credentialing authorities. AICPA’s United States terms incorporate the eligibility and acceptable-use policies into the registrant contract and require continuing qualification. The registry is therefore not independently issuing a national professional licence. It is using state or other approved credentials as inputs to a separate domain-allocation decision. United States .CPA terms of service

In Canada, the country terms refer to national, state, provincial, territorial or other regulatory bodies approved by the Registry Operator and adapt dispute provisions where Canadian or Quebec law requires different treatment. That variation shows why “global .CPA eligibility” cannot be reduced to one database query. The underlying credential, consumer-law constraints and enforceability of arbitration can change by jurisdiction even when the top-level domain is globally unique. Canadian .CPA terms of service

Ireland is more opaque in the public materials reviewed. The current guidance lists Ireland, and the 2012 application referred to Chartered Accountants Ireland, but the primary documents located for this article do not provide a complete current Irish credential definition, regulator matrix, accepted evidence list or country-specific appeal instruction comparable to the US and Canadian terms. The responsible conclusion is not that Ireland lacks rules. It is that the public record assembled here does not establish their full operational detail. AICPA community application

The remedy map has separate routes for separate institutional objects

The live governance design becomes clearest when a dispute is classified before a remedy is named. “The registry acted wrongly” is not one cause of action. A denied application, an ineligible registered name, a broad abuse suspension and a breach of Specification 11 place different parties before different decision-makers. Their filing rules, response periods, implementation steps and available relief cannot be collapsed into a general right of appeal.

Improper denial before registration

Paragraph 3.3 of the REDRP addresses a narrow allegation: the Registry Operator did not allow registration of a domain name that was properly submitted in compliance with the Registrant Eligibility Policy. It does not say that every name-selection or geographic dispute is automatically an improper-denial claim. The complainant bears the burden under the policy’s preponderance standard and must submit the applicable Eligibility Policy and the stated reason for denial. FORUM’s registry-specific dispute page identifies the provider through which the policy is administered. .CPA Registration Eligibility Dispute Resolution Policy

If the panel finds that the complainant met all of the Registry Operator’s conditions and that the operator nevertheless failed to register the name, the panel must order the operator to permit registration. The successful complainant then has 30 days from the decision to complete any remaining registration requirements. That interval is not a grace period for proving the merits again; it is the period for completing the transaction after the merits order. If the complainant does not complete the requirements within 30 days, the name may return to the pool of available names. .CPA Registration Eligibility Dispute Resolution Policy

The policy protects the object of the dispute while the case is pending: an unregistered name challenged under paragraph 3.3 is not to be made available for another registration. It separately requires the Registry Operator and applicable registrar to comply with panel decisions and make appropriate registration-status changes. Those general implementation duties do not create a second merits test. They identify the actors that must turn the decision into an executable transaction. .CPA Registration Eligibility Dispute Resolution Policy

The timing distinction is important. Paragraph 5.5 says that the registrar or registry waits ten business days only if a panel decision requires a change to the status of a registered name. An improper-denial case concerns an unregistered name. The REDRP text reviewed here therefore does not establish an automatic ten-business-day implementation stay for that denial remedy. The policy does allow either party to pursue concurrent administrative or court proceedings, and a panel may suspend or terminate the REDRP case in deference to another proceeding. That general court access should not be rewritten as a specific ten-day stay that the policy attaches only to registered-name status changes. .CPA Registration Eligibility Dispute Resolution Policy

Standing remains less clear than the remedy. The Eligibility Policy recognises qualifying “persons” and entities, but its appeal sentence says that a “business or organization” denied eligibility may use the REDRP. The REDRP itself refers to a complainant and defines the proof required for a denial claim without restating, in equally plain terms, every class of prospective applicant that may file. The combined documents therefore do not unambiguously assure an individual applicant that the appeal invitation applies in the same way as it does to a firm or organisation. A published decision could interpret the overlap. No published .CPA REDRP merits decision was located in the official sources reviewed for this article. .CPA Registrant Eligibility Policy

A registered name allegedly violated name-selection restrictions at the outset

Paragraph 3.1 addresses a different object: a name already registered in .CPA that allegedly failed the Registry Operator’s Name Selection Policy at the time of registration. The complainant must supply that policy and prove the original non-compliance. The registered holder is notified and has 30 days to contest the allegations or show why the complaint should not be granted. Default is not treated as an admission, and the burden remains on the complainant. .CPA Registration Eligibility Dispute Resolution Policy

The published remedy for a name found ineligible at registration is cancellation and return of the name to the available pool. During the proceeding, the registered name is locked against transfer. If the decision requires cancellation, paragraph 5.5 applies because the panel is changing the status of a registered name: the registrar or registry waits ten business days after communication of the decision. If the registrant supplies official documentation within that period showing that it has begun qualifying litigation to preserve its claimed rights, implementation pauses until the registry receives evidence of settlement, dismissal, withdrawal or a court order directing disposition. .CPA Registration Eligibility Dispute Resolution Policy

That route does not decide whether the registrant is professionally licensed in law, award damages to a complainant or give a disappointed third party permanent priority to register the cancelled name. It decides whether the existing registration complied with the registry’s name-selection rule at the relevant time and supplies a domain-status remedy.

A registrant later ceases to satisfy continuing eligibility

Paragraph 3.2 addresses post-registration change. The complainant must show that, after registration, the holder failed to comply with continuing restrictions or requirements in the Registrant Eligibility Policy. A licensing body may supply the underlying fact that a licence expired, was suspended or was revoked; the REDRP panel decides the registry question placed before it. Revoking a domain does not revoke a professional licence, and preserving a domain cannot restore a credential withdrawn by the competent authority. .CPA Registrant Eligibility Policy

The remedy language permits a panel to allow up to 14 days to bring the registration into compliance and submit proof of continuing eligibility, and it permits cancellation and return of the name to the pool. The text is not a general entitlement to 14 days in every case; it gives the panel remedial discretion within that limit. The registered holder receives the REDRP response period, the name is locked while the case is pending, and a cancellation order is subject to the ten-business-day registered-name implementation interval and the specified court-document stay. .CPA Registration Eligibility Dispute Resolution Policy

The operational risk lies in the hand-off between systems. A public board may change licence status before the registry learns of it. A database may lag behind reinstatement. Names may not match across records. The Acceptable Use Policy requires a registrant to notify the registry within one business day of certain regulator action or licence revocation, while Specification 11 contemplates reporting and consultation channels. Yet the public sources do not disclose aggregate time-to-detection, false-positive, cure, cancellation, reversal or reinstatement data. Formal authority to act is documented; the frequency and accuracy of action are not. .CPA Acceptable Use and Anti-Abuse Policy

Suspension for abuse, security, payment or broader contractual risk

The Acceptable Use Policy is wider than the REDRP. It reserves power, in stated circumstances, to deny, cancel, transfer, lock, hold or suspend a name, temporarily or permanently, and to act without prior notice for DNS integrity, legal compliance, liability, prohibited activity, error, non-payment and related risks. For a credible security, stability or criminal concern, it sets a default expectation of suspension within 12 hours after completion of an initial investigation, absent exceptional circumstances. .CPA Acceptable Use and Anti-Abuse Policy

A malware hold, fraud response, payment suspension or DNS-integrity measure does not become a REDRP dispute simply because it affects a registrant. Unless the facts also satisfy one of the REDRP’s defined claim categories, the specialised eligibility panel may have no jurisdiction. The affected party must then look to the operator’s escalation process, its country-specific registration terms, applicable consumer or contract law, arbitration or a court. The trigger is the contractual or legal wrong alleged, not the severity of the operational consequence.

The United States terms provide informal senior-management escalation followed, for covered disputes, by binding arbitration under the stated American Arbitration Association framework. They contain governing-law, forum and liability provisions. The Canadian terms alter the contractual position, including exceptions for Quebec consumers. Those routes may produce contractual relief within the governing terms and law, but they are not substitutes for a REDRP order that expressly permits registration, and they do not give the claimant access to ICANN’s separate contract arbitration with AICPA. United States .CPA terms of service Canadian .CPA terms of service

PICDRP and ICANN Contractual Compliance

ICANN’s enforcement object is the Registry Agreement. The PICDRP addresses alleged non-compliance with Public Interest Commitments in Specification 11. A person or entity that claims harm from an act or omission connected with non-compliance may submit a report identifying the commitment, the grounds, the harm and supporting documents. ICANN first reviews completeness and whether a Specification 11 claim has been stated. The procedure may include a conference with the operator, an ICANN compliance investigation and, at ICANN’s discretion, referral to a standing panel. The panel evaluates compliance and reports to ICANN; ICANN retains the enforcement decision. Public Interest Commitment Dispute Resolution Procedure

The PICDRP’s relief is correspondingly institutional. If a panel finds non-compliance, ICANN issues an enforcement notice and the operator has 30 days to resolve it; if the breach remains, ICANN determines the further remedial measure under the Registry Agreement. A reporter does not receive an automatic order registering a particular name merely because a complaint passes preliminary review. The process can test whether the registry maintained and implemented required safeguards, while the REDRP can decide the specified name-level disputes within its policy. A single set of facts might support both questions, but success in one route does not establish standing or dictate relief in the other. Public Interest Commitment Dispute Resolution Procedure

ICANN’s public PICDRP page lists panel reports for .FEEDBACK and .PHARMACY, not .CPA, and no .CPA entry was located on ICANN’s formal enforcement notices page. That absence does not establish perfect compliance, no reports or no private correction. It establishes only that the public record reviewed here does not show a .CPA safeguard dispute reaching a published merits determination or formal enforcement notice. ICANN PICDRP page

ICANN–registry mediation and arbitration

The Registry Agreement’s dispute clause is bilateral. A dispute arising under or in connection with that agreement is first subject to mediation between ICANN and the Registry Operator and, if unresolved, can proceed to binding ICC arbitration. The agreement allows requests for specific performance and, in defined circumstances, operational sanctions. This route protects the contractual allocation between ICANN and AICPA. It is not a registrant appeal and does not make a rejected applicant a party to the Registry Agreement. executed .CPA Registry Agreement

A registrant may supply facts to an ICANN complaint or may benefit indirectly if ICANN forces the operator to cure a contractual breach. That practical interest is not the same as standing to commence the ICANN–registry arbitration. The claimant in that arbitration must be one of the contracting parties. A registrant must establish its own route under the REDRP, registration terms, applicable law or another recognised procedure.

Courts, concurrent proceedings and technical implementation

Court access varies with the underlying claim. The REDRP says its administrative proceeding does not prevent either party from taking the domain dispute to another administrative process or a court of competent jurisdiction during or after the case; the panel may suspend or terminate in deference to the other proceeding. For a registered-name cancellation decision, paragraph 5.5 specifies how timely court documentation can pause the technical status change. Registrant terms supply separate arbitration and forum provisions, modified where applicable law requires. None of those clauses guarantees jurisdiction, merits success, damages or a registration order. .CPA Registration Eligibility Dispute Resolution Policy

Technical implementation is the last link, not another appellate body. The registrar and registry execute registration or domain-status changes ordered through the applicable route. IANA’s root-zone role concerns delegation and, if required under the Registry Agreement, transition of the top-level domain; it does not adjudicate whether an individual applicant deserves a second-level .CPA name. Contract termination, emergency transition and changes to the IANA database operate at the TLD level. A registrant-level hold, cancellation or registration is implemented inside the registry and registrar chain. executed .CPA Registry Agreement

The result is not one ladder of appeal but a set of adjacent mechanisms. An improper-denial panel can change one applicant’s result without deciding whether the overall policy violates Specification 11. ICANN can enforce Specification 11 without conducting a merits rehearing of every eligibility file. An arbitrator can decide a registrant contract dispute without changing public licensing law. A court may bind parties and direct a domain disposition within its jurisdiction, while the registrar and registry turn the order into technical status. Accountability depends on choosing the route that controls the disputed object.

What the public record proves—and what it does not

The high-confidence chain is documentary. AICPA filed both community and standard applications. The community filing entered CPE and received 11 points, below the threshold. The evaluator found a nexus problem and an inadequate appeal design. Reconsideration did not provide a merits rescore and was denied. The community application is now marked Withdrawn. AICPA later signed a Base, Non-Sponsored Registry Agreement. That agreement includes Specification 11, omits application commitments in Specification 11 paragraph 2 and has no attached Specification 12. IANA records the later root-zone entry. Operator policies introduced jurisdiction-sensitive verification, broad enforcement powers and a REDRP with domain-specific remedies. ICANN determination on Reconsideration Request 15-17

Observed operation remains lower-confidence. Current guidance identifies the United States, Canada and Ireland, but the sources do not provide a complete jurisdiction matrix, every approved regulator or database, every documentary alternative or all current provider roles. Nor do they supply aggregate data on denials, proof requests, licence-loss actions, appeals, reversals or cancellations. .CPA application guidance

The remedy evidence is similarly incomplete. The REDRP text establishes that a panel can order registration, cure or cancellation. It does not prove that a complainant has successfully obtained any of those remedies in .CPA. The public sources reviewed do not establish a published .CPA REDRP merits decision, a withdrawn complaint, a fee schedule specific to a filed case, a suspension reversal, a damages award or a court order requiring registration. Formal availability and observed effectiveness must remain separate findings. .CPA Registration Eligibility Dispute Resolution Policy

The contention-resolution gap also remains. The contract proves who became operator, but the public primary record assembled here does not prove the private bargain that cleared the other applications. Inferring an auction, settlement price, concession or governance condition would convert an unknown into a fact. The institutional analysis does not need that invention. It needs the more defensible conclusion that confidential or unlocated contention mechanics can determine economic control while leaving public accountability to the contract that follows. ICANN determination on Reconsideration Request 15-17

The bounded answer: who decides who is a CPA online?

A state board, national authority or other competent professional body decides whether a person or firm is legally licensed or recognised in its jurisdiction. That decision governs professional status in law. It cannot, by itself, allocate a .CPA domain. The Registrant Eligibility Policy uses those credentials as necessary inputs while reserving registry approval of the relevant authority and applicant class.

AICPA controls the separate registry-policy gate. It defines admitted credentials and jurisdictions, applicant classes, name-selection and use rules, verification arrangements and many domain-status powers. Registrars receive and transmit applications; verification providers and data sources establish or report facts; registry systems execute status. Those operational actors can create decisive practical outcomes, but the published policy places the programme boundary with the Registry Operator.

FORUM panels can correct the defined REDRP wrongs and direct domain remedies. Registrant arbitration and courts can decide claims within their contracts and jurisdiction. ICANN can audit and enforce Specification 11, pursue contract remedies and, if the TLD itself must transition, use the Registry Agreement’s continuity and root-zone mechanisms. These powers touch the same namespace but are not interchangeable.

The failed community bid matters because it identifies the architecture that never came into force. Present restrictions do not derive from a successful CPE or a Specification 12 community schedule. The later REDRP answers part of the appeal-design problem identified in 2015, but under a different source of authority: a Base, Non-Sponsored contract plus operator policies and registrant terms. ICANN Community Priority Evaluation report

The decisive test is therefore not whether .CPA is restricted or whether the restriction sounds professionally protective. It is whether a consequential decision can be traced to an operative rule, a decision-maker with jurisdiction, a review route available to the affected party and a remedy capable of addressing the actual harm. The documentary chain is strongest for credential representations, defined REDRP disputes and ICANN-facing Specification 11 obligations.

It remains less transparent for provider decision rights, broad non-eligibility suspensions, Irish implementation detail, private contention resolution and the aggregate performance of remedies. Successful delegation and low visible complaint volume cannot fill those evidentiary gaps.