Editorial Policy

1. Editorial mission

Nigeria USSD Codes exists to help Nigerian users complete practical banking, telecom, payment, identity and digital-safety tasks with less confusion. The site is not built as a collection of vague articles. A useful guide should tell the reader what code or official route to use, what to press or select, what result to expect, what evidence to save and what to do when the first method fails.

Accuracy, clarity and user safety come before search traffic, advertising revenue or publication speed. We avoid exaggerated promises, clickbait, invented codes, guaranteed reversals and instructions that pressure a reader to disclose confidential information. Content should remain useful even if no advertisement appears on the page.

2. Scope and audience

Our main topics are Nigerian USSD services, banking self-service, telecom short codes, fintech and wallet use, failed payments, POS operations, NIN-SIM guidance, account security and related consumer education. We write for everyday users, families, small businesses, merchants and POS agents who need simple English and practical steps.

The site may explain a regulated or sensitive process, but it does not replace the responsible bank, network, payment provider, regulator, identity agency or qualified professional. Every sensitive guide should make that boundary visible.

3. Source hierarchy

Writers should begin with the organisation responsible for the service. Preferred sources include official bank and telecom websites, official apps and help centres, published regulator material, government agency pages, provider terms, official service notices and verified support documentation. Relevant Nigerian sources may include the Central Bank of Nigeria, Nigerian Communications Commission, Nigeria Data Protection Commission and National Identity Management Commission.

Credible secondary reporting may be used for context, but it should not override a current official source for a code, fee, menu, eligibility rule or legal requirement. Social-media posts, search snippets, copied code lists and unverified screenshots are not sufficient evidence on their own. User comments are treated as reports to investigate rather than facts to publish automatically.

External sources should be linked where they help a reader verify a sensitive claim. Links must lead to the relevant official page when reasonably available and should not be added merely to make an article look authoritative.

4. How we verify codes and task instructions

Before publishing a USSD code, we check the provider identity, service purpose and available official evidence. We distinguish a main menu code from a direct transaction string, emergency lock route, harmonised network code and app-only service. A code used to lock an account must never be described as a normal transfer or balance code.

Menu option numbers can change. A guide should name a fixed number only when the number is supported by a reliable current source. Otherwise, it should tell the reader to choose the number displayed beside the service name. Fees, limits, plan prices and reversal times should not be stated as permanent when they vary by customer or can change.

For app instructions, the writer should identify the official app route, explain the buttons or labels a user is likely to see and acknowledge that interface wording may change. For branch or service-centre tasks, the guide should state what documents or evidence may be useful without claiming that one list applies in every case.

If a code or process cannot be verified safely, we say so and direct the reader to the official provider. We do not fill a gap with a plausible guess.

5. Task-first writing standard

Every article should answer the reader’s main question near the top. Where a verified code exists, it should appear in a clear answer box or table. Where no universal code exists, the article should say that plainly and present the official route instead.

A complete practical guide normally includes requirements, numbered steps, the expected result, alternatives, common errors, troubleshooting, safety warnings, realistic examples, useful internal links and FAQs. The body must justify the title in full. A wrong-transfer article, for example, should explain what evidence to collect, where to report, what to request and what outcomes are realistic, not merely tell a reader to contact the bank.

Language should be simple, respectful and specific. Short paragraphs, descriptive headings, tables and callout boxes are preferred where they make a task easier to complete. Keywords are used naturally. Repetition, padding, copied definitions and generic automated language are removed during review.

6. Authorship, experience and human review

Articles should identify an author and publication or update date. Author pages explain the writer’s role and subject focus. Practical examples may come from ordinary user problems, staff experience helping users understand digital services, documented provider processes or clearly labelled scenarios. We do not invent personal experiences, customer testimonials or test results.

Digital tools, templates or language assistance may support research organisation, consistency checks or drafting. They do not replace editorial responsibility. A human editor is responsible for reviewing the final page for unsupported claims, unsafe steps, duplicated language, broken links, sensitive-data risks and whether the article actually solves the task.

Images and screenshots must be genuine, properly permitted and relevant. We do not create a fake banking screen or present a mock interface as evidence. If a real screenshot is needed but unavailable, an internal placeholder should describe what the team must capture later; that placeholder should not be presented to readers as proof.

7. Updates, corrections and archived information

Digital-service information changes frequently. Records and articles should show an update date where practical. High-use and high-risk pages should receive priority review, especially bank codes, network short codes, stolen-phone steps, wrong-transfer guidance, NIN-SIM processes and failed-payment instructions.

Readers can report an outdated code, broken link, unclear step or safety issue through Support or [email protected]. A useful report identifies the page, provider, disputed detail and an official source if available. The editor checks the report before updating the page.

Small spelling or formatting changes may be corrected without a formal note. A material change to a code, safety instruction, provider route or conclusion should update the review date and may include an explanatory note. We do not silently preserve known dangerous instructions for traffic. If a page cannot be made accurate, it may be removed, redirected or clearly marked as historical.

8. Independence, conflicts and provider relationships

Nigeria USSD Codes is independent from the organisations it covers unless a relationship is clearly disclosed. A provider, advertiser or partner may not purchase a favourable editorial conclusion or prevent a necessary correction. Writers should disclose a material relationship that could reasonably affect trust in the content.

Provider names and trademarks are used for identification and commentary. A comparison describes practical differences but is not a regulated rating or personal recommendation. Editorial scores, where used, are labelled as editorial assessments and should be supported by visible comparison criteria.

9. Advertising, sponsorship and affiliate content

Advertising may fund the site, including advertising supplied through Google AdSense or another network. Ads must be visually distinguishable from editorial content. They must not imitate navigation, emergency warnings, customer-care replies or download buttons, and their placement must not make a reader click accidentally.

Advertising does not determine which code is listed, which safety warning is included or how a provider is compared. Sponsored material, if introduced, must be clearly labelled. Affiliate links, if introduced, must be disclosed near the relevant content and must not replace an official source when the official source is the safer destination.

We do not promise that a policy page or amount of content will guarantee advertising approval. The editorial goal is to meet the underlying standard: original, useful, transparent content that respects users and publisher policies.

10. Comments and community information

Comments are moderated before publication. We may remove spam, impersonation, threats, promotional links, unsupported recovery claims and confidential financial or identity information. A published comment remains the commenter’s opinion and does not become an official Nigeria USSD Codes instruction.

When a comment identifies a possible error, the editorial team should verify it through the source hierarchy before changing the article. Helpful questions may be used to improve FAQs without exposing the commenter’s private details.

11. Contact the editorial team

Send corrections and source updates to [email protected]. General editorial questions can be sent to [email protected]. Never include a PIN, OTP, BVN, NIN, password or full account login details.