A registrar accreditation application can look straightforward until the evidence, systems, funding, and operational accountability are tested together. A useful guide should do more than list forms. It should show a controlled path from first signup to live provisioning — and it should recognise that not every registry should apply the same bar.
That is how rEngin SRS is designed. The Shared Registry System is multi-tenant: several TLDs and SLDs can run on the same hosted platform, while each registry operator keeps policy and managerial control. Registrar onboarding is one of those policy controls. The platform can require a full accreditation stack, a lighter legal and financial review, agreement-only activation, or a closed pre-qualification gate before an applicant even reaches the queue.
The objective for a new registrar is not only to obtain access. It is to operate against the specific obligations of each namespace it wants to sell: policy, data protection, lifecycle events, billing, and support. The workflow below treats accreditation as the foundation of that operation — and shows how rEngin SRS encodes different registry rules instead of forcing a single path.
Start With the Registry’s Onboarding Profile, Not a Generic Application
Before naming an application owner, decide which namespaces you are targeting and which onboarding profile those namespaces use. A retail registrar, a wholesale registrar serving resellers, and an enterprise registrar supporting a controlled namespace already have different support, billing, fraud, and integration needs. On rEngin SRS, the registry’s accreditation profile is a further constraint.
Those profiles are not theoretical. They are in production across the platforms we operate and support.
ZARC. Registrars must complete legal, financial and technical accreditation before they can provision in the supported ZA second-level domains. That includes the registry-registrar agreement, accreditation fees and financial readiness, legal verification of the applicant, and Operational Test and Evaluation (OT&E) against the EPP service. Live credentials follow only after the technical checks pass.
Registry Africa and ZACR. Registrars complete legal and financial accreditation. Technical accreditation is assumed on the basis of ICANN registrar criteria (IANA ID and the applicable RAA). The registry still reviews standing, agreement acceptance and financial capacity. It does not re-run a full technical OT&E solely because the applicant is already an ICANN-accredited registrar.
RyCE. Access is limited to ICANN-accredited registrars. The platform can enforce that gate at signup so non-accredited applicants never enter the onboarding queue.
Gateway SRS. There is no separate accreditation track beyond accepting the Gateway agreement, completing account information, and funding the account. The commercial model is reseller onboarding, not registry accreditation.
These differences matter operationally. A team that prepares a full ZARC evidence pack for every namespace will over-process Gateway applicants. A team that treats every signup as agreement-only will fail ZARC, Registry Africa, ZACR and RyCE reviews.
Establish the target TLD portfolio, customer geography, sales channels, pricing model, and first-year volume. That work still informs registry connections, credit arrangements, verification controls, data retention, and staffing. On rEngin SRS it also tells you which onboarding states the applicant must pass, and which states the registry has chosen to skip.
This is also the point to decide which functions you operate directly and which sit with a specialist provider. Accountability for policy compliance remains with the accredited (or contracted) entity. Outsourcing can accelerate entry; it still requires vendor oversight and tested escalation.
Create a cross-functional onboarding team
Onboarding should not sit only with legal counsel or a technical lead. It needs a working group that can decide quickly across governance, finance, operations, security, support, and engineering.
Name one executive sponsor and one programme manager. Assign owners for policy documentation, financial evidence, platform configuration, registry connectivity, data protection, abuse handling, and customer communications. A simple responsibility matrix prevents the usual failure: each team assumes another team owns a required control.
Where the registry uses rEngin SRS, add one more owner: the person who tracks per-namespace onboarding state in the registrar portal (agreement, legal, financial, technical, live credentials, funding). Those states are not always all required.
Match the Evidence Pack to the Registry’s Bar
Application requirements vary by registry, jurisdiction, and services offered. Treat the current registry materials and contracts as the controlling source. Most reviews still ask the same question: can this organisation operate responsibly and continuously?
Prepare evidence in a versioned repository with approval records and named owners. Do not wait for an assessor to request documents. What you collect should match the profile:
| Platform / registry | Who may apply | Legal | Financial | Technical (OT&E) | What “done” looks like |
|---|---|---|---|---|---|
| ZARC | Applicants who meet ZARC criteria | Required | Required (including accreditation fee and account funding) | Required | Legal + financial + technical passed; live EPP credentials issued |
| Registry Africa | Typically ICANN-accredited registrars | Required | Required | Assumed from ICANN registrar criteria | Legal + financial review passed; live credentials issued |
| ZACR | Typically ICANN-accredited registrars | Required | Required | Assumed from ICANN registrar criteria | Legal + financial review passed; live credentials issued |
| RyCE | ICANN-accredited registrars only | Per RyCE policy | Per RyCE policy | ICANN technical standing is the entry condition | ICANN accreditation verified; agreement and account activation completed |
| Gateway SRS | Resellers / clients who accept the agreement | Not a registry accreditation track | Account funding only | None beyond platform use | Agreement accepted; account funded; domains can be registered |
The evidence should still explain how the registrar will handle core domain events: registration, renewal, expiration, restoration where applicable, transfer, deletion, contact updates, authorisation requests, and complaints. Policy statements are not enough. Reviewers need confidence that people and systems can execute those processes.
Financial readiness deserves extra weight on ZARC, Registry Africa and ZACR. Accreditation and registry access may involve application fees, recurring fees, deposits, credit thresholds, or prepaid balances. Model those obligations against expected volume, renewals, chargebacks, support cost, and settlement cycles. Underestimating working capital is a business risk even when the technical platform is ready.
On Gateway SRS the financial step is simpler — fund the account — but it is still a hard gate before live registrations.
Design Compliance Into the Platform — and Into Each Tenant’s Rules
A registrar platform must turn policy into repeatable controls. Manual workarounds may support a pilot; they become errors as the portfolio grows. The platform should enforce lifecycle rules, retain required records, capture auditable consent and authorisation data, and prevent unauthorised changes.
At a minimum, document identity and access management, privileged access, password controls, logging, backups, encryption, incident response, and change management. The service must remain trustworthy in normal operations and in failure.
For registry connectivity, confirm that the registrar can support the required protocol, certificates, credentials, test environments, and transaction behaviour for each target registry. EPP is often central to provisioning. An EPP connection alone is not operational readiness. Teams must also handle polling, command failures, status codes, billing reconciliation, and registry-specific policy variations.
This is where a shared system is useful only if it stays configurable. rEngin SRS runs multiple namespaces on one hosted backend, with a single registrar integration path where the operator allows it. Onboarding rules stay per tenant:
- ZARC can require OT&E before live credentials.
- Registry Africa and ZACR can skip a duplicate technical exam when ICANN accreditation already demonstrates technical capacity.
- RyCE can refuse signup unless an IANA ID / ICANN accreditation is present.
- Gateway SRS can activate after agreement acceptance.
A domain management platform built for registry and registrar operations reduces the need to force generic commerce software into a policy-sensitive environment. DNS.Business supports that model with infrastructure designed for lifecycle automation, registry connectivity, and controlled growth.
Gate signup so the queue stays workable
Open self-signup is not always the right control. For some registries we limit signups and pre-qualify applicants before they receive a registration link or portal access.
That is deliberate. Unqualified applications flood legal review, finance checks, OT&E scheduling, and first-line support. They slow down applicants who already meet the criteria. rEngin SRS supports this by allowing a registry to:
- hide or close public signup for a namespace;
- issue a pre-qualification or invite-only link after a short eligibility check (for example IANA ID, registrar name, and intended channel);
- keep Gateway-style namespaces on a simpler public signup where the only gate is the agreement.
Pre-qualification is not a substitute for accreditation. It is a filter so the accreditation workflow only runs for applicants the registry is prepared to review.
Treat data as an operational asset
Registrant, account, payment, and domain data move across customer interfaces, registrar systems, registries, and support. Map those flows before launch. Identify where data is collected, where it is stored, who can access it, how long it is retained, and how corrections or deletion requests are handled when policy and law permit.
That mapping reconciles privacy obligations with contractual recordkeeping. It also exposes hidden dependencies — a support vendor with account access, a billing provider that receives customer identifiers. Clear data ownership makes incident response faster and improves audit evidence.
Test Only What the Registry Actually Requires — Then Test Operations Anyway
The strongest onboarding workflow includes formal testing, not only configuration checks. Build test cases around the domain events customers and registries will encounter. A successful registration is only one scenario. Test renewals, expirations, failed payments, transfers in and out, contact changes, authorisation processes, restores, cancellations, disputed transactions, and registry outages.
On ZARC, technical accreditation is a formal OT&E gate. Treat it as such: complete the required EPP commands and extensions in the test environment, then request live credentials.
On Registry Africa and ZACR, technical accreditation is assumed from ICANN criteria. Do not confuse that with “no testing.” You still need to confirm that your systems behave correctly against that registry’s policy, billing, and launch rules before you take customer orders.
On RyCE, ICANN accreditation is the entry ticket. Connectivity and portal use still need an internal go-live check.
On Gateway SRS there is no OT&E accreditation step. You still need to verify contacts, nameservers, funding, and the registration path before you scale.
Run negative tests as well. Confirm that the system rejects invalid commands, blocks unauthorised account changes, records failed authentication, and escalates suspicious activity. Test registry unavailability, payment delay, and failed synchronisation. Recovery procedures should name who acts, what is communicated, how records are reconciled, and when leadership is notified.
Operational acceptance includes support readiness. Customer-facing teams need scripts and escalation rules for transfers, renewal notices, account access, verification issues, and abuse reports. A technically correct platform can still create exposure if support staff give inconsistent information.
Establish Governance for Abuse, Complaints, and Continuity
Accreditation is not a one-time event. Once live, the registrar must maintain a control environment that can respond to abuse allegations, complaints, security incidents, and continuity events.
Create a documented intake and triage process for phishing, malware, fraud, intellectual property matters, inaccurate contact data, and other policy-relevant concerns. Not every report leads to the same action. Overreaction can be as damaging as inaction. Define evidence standards, response targets, decision authority, customer notification rules, and records of disposition.
Business continuity planning should match the registrar’s size and commitments. Identify critical systems, recovery priorities, backup validation, alternative communication channels, supplier dependencies, and the process for restoring accurate domain state after an incident. Test the plan with realistic scenarios. Do not treat it as a document that exists only for an application file.
Move From Approval to a Controlled Launch
After accreditation approval and registry onboarding, do not open every channel and TLD at once. A phased launch shows real transaction behaviour, customer questions, billing exceptions, and support load. Start with a defined product scope and, where possible, a limited customer group. Expand when operational metrics are stable.
That discipline pairs with how rEngin SRS is used in practice. A registrar may be live on Gateway SRS the same day the agreement is accepted and the account is funded, while the same organisation is still in legal review for Registry Africa or mid-OT&E for ZARC. The platform can hold those states independently so one namespace does not block another — and so a registry that wants a closed, pre-qualified intake is not flooded by an open signup form meant for a different tenant.
Monitor registration success rates, command failures, renewal completion, transfer turnaround, support response times, abuse case ageing, reconciliation exceptions, and security alerts. Those measures show whether the workflow works in production, not only on paper. They also give you the evidence to tighten procedures before growth magnifies a weakness.
The practical value of accreditation is the discipline it creates. Build the controls, evidence, and technical accountability early. Configure the onboarding path to the registry you are joining. Used that way, rEngin SRS lets registry operators keep a high bar where they need one, keep a short path where they do not, and keep signup queues limited to applicants they are ready to onboard.
