1. Scope & accountability
This is a proposed operating standard for adult customers in Nigeria and Ghana. Before activation, the operator must designate an accountable compliance owner, assess local obligations and approve country-specific procedures, vendors and recordkeeping. It does not claim a financial-services licence, regulatory certification or current technical enforcement.
2. Identify the customer
The proposed onboarding record includes legal name, date of birth, country of residence and verified contact details. Where required by the applicable risk assessment, request an accepted government-issued identity document through a secure verification channel. Examples may include an appropriate Nigerian identity document or Ghana Card; accepted documents and permitted verification methods must be confirmed for each market.
Avoid unnecessary national-identifier collection. Biometric or liveness checks require a documented need, an approved provider and clear notice before collection. Collecting an email address alone does not prove identity.
3. Confirm ownership
Match the customer to the intended payout account, investigate name discrepancies and validate that the customer is entitled to sell the gift card. Request proportionate supporting evidence where needed. Do not release a payout subject to unresolved identity or ownership concerns once this control is implemented.
4. Apply proportionate risk review
Assess country eligibility, card provenance, transaction behaviour, inconsistent identity information and other relevant risk indicators. The proposed procedure includes screening for applicable sanctions and politically exposed persons using an approved source, with manual review of potential matches. A name match alone must not be treated as a confirmed adverse finding.
Higher-risk cases require enhanced review, which can include source-of-card or source-of-funds evidence and approval by the responsible reviewer. Specific thresholds and vendor integrations remain to be established before enforcement.
5. Review activity over time
The proposed monitoring process looks for unusual transaction patterns, repeated validation failures, duplicate identity evidence and unexplained changes to payout details. Keep information current and reverify after material changes. Document the reason and evidence for a hold, refusal or escalation.
6. Escalation & human review
Assign unresolved cases to an authorised reviewer. Provide an understandable status and a route to correct information or contest a decision, except where disclosure is lawfully restricted. Handle suspicious-activity escalation and any reporting under the obligations actually applicable to the operator; do not promise automatic reports for every alert.
7. Protect verification information
Before collecting identity evidence, establish a secure submission channel, encryption safeguards, access permissions, audit logging, provider agreements and an incident-response procedure. Restrict use to stated verification and lawful compliance purposes. Do not collect passwords, email one-time codes or withdrawal PINs as verification evidence. This website accepts no identity uploads.
8. Recordkeeping & disposal
Approve a documented schedule for verification decisions, transaction evidence and any identity records before collection begins. A proposed baseline is five years after the relationship or transaction ends where that period is appropriate under applicable requirements; local law, necessity and documented legal holds must determine the final schedule. Keep raw document images or biometric material for no longer than demonstrably necessary and securely dispose of records when their purpose expires.
9. Activation requirements
- Confirm the accountable owner and market-specific legal assessment.
- Approve verification providers, accepted documents and privacy notices.
- Implement and test verification states, transaction restrictions and exception review.
- Train authorised reviewers and establish a customer appeal channel.
- Validate data access, retention, deletion and incident handling.
Publication of this framework does not activate these controls in the app or backend. Details must be updated when implementation is verified.
Questions & corrections
Contact miriamrhodes9314@outlook.com for questions about this framework. Start with a description of your concern. Do not attach identification documents to your initial email.