Data Retention, Deletion and Records Policy

Personal information will be retained only for as long as reasonably necessary to achieve the lawful purpose for which it was collected or further processed.

Convenience, curiosity or the possibility that information may become useful someday is not by itself a sufficient retention purpose.

Where a full document or detailed record is no longer required, 6membership may retain a smaller record containing only the information necessary for accountability, verification, legal compliance or dispute resolution.

For example, an identity document may be deleted while the verified name, date, verification result and review timestamp remain.

Different information categories may have different retention periods because they support different purposes.

A payment record may need to remain longer than an expired secure link, while a legal hold may require preservation beyond the ordinary schedule.

Information retained for an active operational purpose should remain accurate, complete and appropriately updated where necessary.

An incorrect historical record should be corrected through an auditable process rather than silently rewritten.

Retained information remains subject to appropriate access control, confidentiality, integrity, availability and incident-response safeguards.

Archiving information does not make it public or remove its security classification.

6membership should be able to explain why a material category of personal information is retained, the expected retention period and the event that starts or ends that period.

Administrative and automated deletion actions should be recorded where appropriate.

The Privacy Notice explains the information collected and the lawful purposes for processing it.

The Security Policy governs safeguards and incident records.

The Policy Updates document governs retention of historical policy versions.

Some short-lived technical records are retained from the date they are created.

Examples may include an expired OTP event, temporary verification attempt or ordinary website-security log.

An unsubmitted application draft may be retained from the date of the applicant’s last meaningful activity.

Merely loading a page without changing or confirming the record need not restart the retention period.

For submitted applications, a retention period may begin when the application is approved, declined, withdrawn, cancelled or closed as incomplete.

For membership records, a retention period may begin when the membership expires, is cancelled, is revoked or otherwise ceases to be active.

A later reinstatement may create a new active period without erasing the earlier status history.

Financial, payment, refund, tax and accounting records may be calculated from the transaction date, relevant accounting period or year of assessment according to the applicable requirement.

Complaint, appeal, privacy, security and investigation records may be retained from the date the matter is closed or the final related action is completed.

Where several justified retention periods apply to the same record, the record may remain until the latest applicable period ends.

The retained content should still be reduced where the full record is no longer necessary.

The periods stated in this Policy establish the ordinary maximum or baseline periods used by the production service.

A shorter period may be applied where the information is no longer necessary and no competing obligation requires retention.

6membership should maintain an internal retention register connecting each database table, storage location, email record, provider system and backup class with its purpose, owner and retention rule.

The internal register may contain technical identifiers that are not appropriate for public disclosure.

Retention rules should be enforced through database queries, scheduled deletion jobs, storage lifecycle controls, administrator workflows and provider configuration where practical.

A policy period that is not implemented technically must not be represented as though automatic deletion is already occurring.

The retention schedule should be reviewed periodically and when a new tier, application field, provider, payment function, public-verification field or legal obligation is introduced.

An authorised privacy, security or administrative owner should be responsible for reviewing deletion exceptions, legal holds and failures of scheduled deletion.

An administrator must not extend a retention period indefinitely merely by adding a note that the record may be useful.

An extension requires a documented lawful or operational reason.

Service-provider retention settings should be configured consistently with this Policy where the provider offers relevant controls.

Where a provider imposes a fixed backup or security-log cycle, that cycle should be recorded and assessed before production use.

Flutterwave retention must be recorded separately from 6membership-controlled retention because Flutterwave may independently retain transaction, settlement, risk, fraud, tax, accounting and regulatory records.

An unsubmitted application draft may be retained for up to 30 days after the applicant’s last meaningful activity.

The period allows the applicant to return and complete the application without retaining an abandoned draft indefinitely.

Where an email address has been verified and the person has not opted out of applicable reminders, 6membership may send a limited reminder before the draft is deleted.

A reminder does not convert the draft into a submitted application.

The draft flow should avoid requesting sensitive identity and guardian documents before they are necessary.

Where sensitive evidence has already been uploaded, it remains subject to the same private-storage and deletion rules as submitted evidence.

After the draft period ends, the draft and unnecessary uploaded files should be deleted from active production storage.

A minimal abuse-prevention or consent record may remain where another lawful purpose applies.

Where a person is identified as under the minimum permitted age, unnecessary draft information should be deleted promptly.

A minimal restricted record may remain where necessary to prevent immediate circumvention or demonstrate that payment was blocked.

An abandoned draft that never reached Flutterwave must not be represented internally as a completed or failed payment transaction.

Ordinary checkout-attempt metadata may be retained separately where a provider session was created.

A submitted application and relevant supporting information may be retained while payment, verification, guardian consent, compliance review and administrative decision-making remain active.

An application marked incomplete may remain open for up to 90 days after the latest official request for the missing information.

6membership may close the application earlier where the applicant withdraws or confirms that the requirement cannot be satisfied.

Where no adequate response is received within the incomplete period, the application may be closed as incomplete.

Closing an application as incomplete is not the same as finding that the applicant committed fraud.

The core record of a declined, withdrawn or closed application may be retained for up to three years after closure.

The core record may include the Application Reference, applicant identity, selected tier, payment status, decision, reason, policy versions, communications and complaint status.

Full identity, guardian and supporting documents for a declined, withdrawn or incomplete application should ordinarily be deleted within 12 months after closure.

A document may remain longer where required for an active refund, chargeback, fraud investigation, complaint, authority request or legal hold.

Where credible fraud or identity misuse was established, a limited fraud-prevention record may remain beyond ordinary document deletion.

The record should contain the minimum information necessary to identify and prevent repeated abuse.

A new application may be connected with an earlier record where this is necessary to identify predecessor-tier status, correct information, repeated misuse or the outcome of an earlier complaint.

An earlier decline must not automatically determine every later application where circumstances have changed.

The approved application, decision, policy acceptances, selected tier, payment relationship and Membership ID may be retained while the membership remains active.

The record supports membership administration, verification, renewal, upgrade, complaints and status history.

Full-resolution identity and supporting documents should ordinarily be deleted or reduced within 12 months after final approval where they are no longer needed for continuing verification or compliance.

A derived record may retain the verified fields, document type, review result, reviewer and verification date.

A document may remain longer where the membership tier, legal requirement, active investigation or separate agreement requires continuing verification.

The reason and expected review date should be recorded.

The approved card photograph, card file, certificate and verification information may remain while the membership or relevant credential remains active.

Public assets should use limited derivatives rather than original private uploads.

The core approved application and membership history may be retained for up to six years after the membership ends.

Unnecessary card files and private documents should be removed earlier where they no longer support a legitimate purpose.

Records relating to a separately signed private, strategic, commercial, investment or equity agreement are retained according to that agreement, applicable law and the associated limitation and recordkeeping requirements.

They are not governed solely by the ordinary public-membership schedule.

Ending a membership should disable its active public-verification presentation promptly.

A minimal protected historical status may remain without keeping the former member publicly searchable.

Current membership records may include the member’s identity, tier, billing period, start and end dates, Membership ID, card status, certificate, associated people and administrative status.

Status transitions including active, expiring, expired, suspended, restricted, stolen, invalid, revoked and cancelled may be retained as an audit history.

A later status must not erase the fact that an earlier status existed.

Tier history may be retained where predecessor-tier status affects eligibility for a later tier.

Only the history necessary to establish the relevant eligibility chain should be used.

Household, guardian, organisation and associated-person relationships may remain while the relevant membership relationship is active.

When the association ends, unnecessary private information should be removed while the historical relationship may remain where required.

Public verification should expose only current authorised fields.

After expiry, cancellation or revocation, the active display should be disabled or changed to a limited non-active status according to the verification policy.

Core membership, status and verification-history records may be retained for up to six years after the membership ends.

This period supports complaints, predecessor checks, card disputes, legal claims and protection against counterfeit use.

Records of a lost, stolen, altered or counterfeit card may remain for the ordinary post-membership period or longer while an active investigation or legal hold applies.

Where practical, the full identity document should be stored separately from the extracted verification result.

Deleting the full document does not require deletion of the verified name, date, result and audit evidence where those fields remain necessary.

Original or full-resolution documents should not be kept longer than needed for verification, quality review, fraud assessment and any applicable challenge period.

Approved-applicant identity documents should ordinarily be deleted or reduced within 12 months after approval unless a documented continuing requirement applies.

Identity and guardian documents for a declined, withdrawn or incomplete application should ordinarily be deleted within 12 months after closure unless another lawful need requires retention.

The guardian’s identity and authority documents may be reduced after verification while the consent event, policy versions, relationship, timestamp and decision remain with the younger applicant’s record.

The precise date of birth and age-verification result may remain where necessary to establish eligibility and manage the transition to adulthood.

Public card and verification pages must not display the full date of birth.

A forged, stolen or manipulated document may be retained as restricted evidence while an investigation, complaint, authority request or legal claim remains active.

When the full file is no longer required, a hash, fraud marker or limited evidential copy may be retained where appropriate.

Payment records may include the internal transaction reference, Flutterwave transaction identifier, transaction reference, amount, currency, verified status, payer name and email, payment-method category, application relationship, customer relationship, verification timestamp and limited provider response information.

6membership should retain only the provider information needed for reconciliation, accounting, fraud prevention, refunds, disputes and legal compliance.

6membership must not store complete card numbers, card security codes, payment PINs, banking passwords, payment OTPs, Flutterwave secret keys or encryption keys as ordinary transaction records.

Where Nigerian tax, accounting or related recordkeeping requirements apply, relevant payment, refund, accounting and tax records may need to be retained for at least six years after the applicable year of assessment, accounting period or other legally defined starting event.

A longer period may apply where another binding requirement, audit, investigation, chargeback, legal claim or dispute remains active.

The financial baseline does not justify retaining full payment credentials or unrelated personal information.

A failed or abandoned payment attempt may be retained for up to two years where necessary for reconciliation, fraud prevention, customer support and provider disputes.

Unnecessary checkout-session, redirect and retry data should be removed sooner where no continuing purpose applies.

A failed attempt must not be retained or described as a successful payment merely because a checkout session or debit notification existed.

Refund records may include the internal decision, approved amount, reason, idempotency reference, Flutterwave refund reference, provider submission, provider acceptance, processing status, succeeded or failed result, original payment destination and related communications.

Internal approval, submission to Flutterwave, provider processing and final completion are separate events and should remain distinguishable in the retained record.

The records may remain with the underlying financial transaction for the applicable financial-retention period.

A chargeback or payment-dispute record may include the dispute reason, provider or financial-institution reference, evidence supplied, deadlines, provisional action, final outcome and resulting membership status.

The record may remain while the dispute is active and afterward for the applicable financial, fraud, audit and claims period.

The same transaction must not be reimbursed through both a completed refund and a successful chargeback.

An applicant-supplied screenshot, debit alert or bank message should be deleted when independent Flutterwave verification has made it unnecessary, unless it remains relevant to a dispute, chargeback or fraud investigation.

A screenshot must not replace the retained server-side verification result.

An administrator’s custom email observation cannot shorten a legally required financial-retention period or extend it indefinitely.

A custom message must not change a verified payment or refund status without an authorised, auditable status action.

A Flutterwave event record may include the event identifier, event type, received time, signature-validation result, linked transaction, processing result, retry count, error information and deduplication or idempotency reference.

Webhook and verification records may remain with the underlying transaction where they establish payment, refund, reversal, settlement or chargeback status.

Repeated raw payloads that add no evidential value should be reduced or deleted sooner, and webhook secrets, API credentials and complete payment credentials must never be copied into ordinary logs.

Flutterwave may retain transaction and personal information for as long as reasonably necessary to provide its services and satisfy regulatory, fraud-monitoring, tax, accounting, dispute and other legal obligations.

Banks, card networks, mobile-money operators and other participating financial institutions may retain their own transaction records under separate legal and operational requirements.

6membership cannot promise deletion of independently controlled provider records beyond the rights and controls available under applicable law and the relevant provider arrangement.

A policy-acceptance record may include the applicant or member, policy identifier, version, action, timestamp, Application Reference, Membership ID and relevant technical evidence.

Acceptance records may be retained throughout the associated application or membership relationship.

They support proof of the terms and disclosures applying to the relevant action.

Material policy and consent records may be retained for up to six years after the associated application or membership relationship ends.

A longer period may apply where a legal claim, complaint or authority requirement remains active.

Where consent is withdrawn, 6membership may retain a record of the withdrawal, its date, scope and resulting action.

The withdrawal record helps prevent the withdrawn processing from restarting incorrectly.

Guardian consent and the younger applicant’s own acknowledgement must remain distinguishable records.

The records may remain as part of the age and membership history after the member reaches adulthood.

An opt-out or suppression record may be retained for as long as necessary to respect the person’s preference.

The suppression record should contain only the information needed to prevent unwanted promotional communication.

The complete policy version connected with an acceptance may be archived so that the content presented at the time can be established.

Email-delivery logs may include the recipient, subject, template identifier, provider message ID, timestamps and generated, queued, accepted, delivered, bounced, rejected or complained-about status.

Ordinary delivery metadata may be retained for up to two years after the communication.

A shorter provider period may apply where the log is not exported or required for an active matter.

An approval, decline, incomplete request, refund notice, complaint response, privacy response or security notice may remain with the associated application, transaction or case for that record’s longer retention period.

A custom administrator observation may remain as part of the decision record.

Irrelevant, insulting, discriminatory or unlawfully included information should be corrected or restricted rather than preserved as though it were required evidence.

A usable OTP or secure token must expire according to the action presented and should not remain stored in readable form after use or expiry.

Limited metadata showing generation, delivery, expiry or successful use may be retained for up to 12 months for security and dispute purposes.

A bounced, rejected or complained-about email address may be retained in a limited suppression record to prevent repeated failed or unwanted sending.

Sensitive identity, guardian or payment documents should not be retained in ordinary email attachments where an approved private upload route is available.

An attachment received unexpectedly should be transferred, restricted or deleted according to the associated case and security risk.

A privacy-request record may include the Privacy Request Reference, requester identity, verification, request type, scope, communications, searches, provider-assistance steps, decision and completion date.

Privacy requests, complaints and appeals may ordinarily be retained for up to three years after closure.

This period supports accountability, repeated-request management and review of the response provided.

The record may remain longer where a regulator, court, legal claim, unresolved complaint or enforcement process remains active.

Identity evidence supplied solely to verify a privacy requester should be deleted or reduced promptly after verification unless a dispute concerning identity remains.

Evidence submitted with a complaint should be retained only where relevant to the allegation, response and outcome.

Unrelated private information should be removed or restricted.

The final outcome, reason, corrective action and communication may remain even where unnecessary supporting files are deleted.

Information must not be retained indefinitely or used adversely merely because a person exercised a privacy, consumer or complaint right.

Where a privacy request concerns Flutterwave transaction, refund, chargeback or payer information, 6membership may retain the provider correspondence, transaction references, request scope and response needed to demonstrate how the request was handled.

The request record should not unnecessarily duplicate complete provider records or payment credentials.

Flutterwave or another financial institution may independently assess a request concerning information it controls under its own legal responsibilities.

Routine access, error, authentication and abuse-prevention logs may ordinarily be retained for up to 12 months.

A shorter period may be used where the information is not needed for detection, investigation or service integrity.

Material administrator actions involving approvals, declines, incomplete flags, payment confirmation, refund approval, Flutterwave submission, webhook replay or resolution, membership status, deletion, access roles and exports may be retained for up to six years.

Security-incident and personal-data-breach records may be retained for up to six years after closure of the incident.

A longer period may apply where regulatory, insurance, legal or continuing-risk requirements remain.

A vulnerability report and remediation record may remain for up to six years after closure where needed to demonstrate the issue, corrective action and recurrence prevention.

Copied personal information should be deleted sooner where it is no longer required.

A secret or credential identified as exposed must be revoked or rotated rather than retained as an active credential.

A redacted incident record may preserve the credential type and response without storing the usable secret.

Security and audit records should be protected against unauthorised alteration and deletion.

A person whose action is under investigation must not be able to remove the relevant evidence through the ordinary console.

Security logging must not become a reason to retain complete documents, passwords, OTPs, Flutterwave API credentials, webhook secrets, encryption keys, complete raw payment payloads or full payment credentials unnecessarily.

A legal hold is a documented instruction preventing ordinary deletion of specified information because it may be relevant to a complaint, dispute, investigation, regulator request, authority request or legal proceeding.

A legal hold should identify the relevant records, reason, responsible person and review date.

It must not suspend deletion across every system where only a limited set of records is relevant.

Records under a valid hold may remain beyond the ordinary retention period until the hold is released.

The records remain subject to security, access and confidentiality controls.

A lawful request may require preservation of identified records while the request is reviewed or fulfilled.

6membership will assess the authority, scope and legal basis before disclosure where permitted.

A hold should be reviewed periodically and released when the relevant matter ends.

A label stating legal does not justify permanent retention without an identifiable matter.

When a hold is released, the records return to the ordinary retention schedule.

Records whose ordinary period already expired should be deleted or reduced promptly unless another lawful purpose applies.

The creation, review, modification and release of a material legal hold should be recorded.

Deletion may remove a record from an active production table or replace personal fields with a restricted anonymous or pseudonymous identifier where a non-identifying record remains necessary.

Private identity, guardian and supporting files should be deleted from active storage when their retention period ends.

Associated database pointers and signed-access routes should also be invalidated.

Where supported, information may be rendered inaccessible by securely deleting the encryption key required to decrypt it.

The method must be appropriate to the provider architecture and must not be described as completed where recoverable copies remain available ordinarily.

Information may be retained in a genuinely de-identified form where it can no longer reasonably be connected with an identifiable person.

Removing a name alone is not sufficient where other fields still identify the person.

Replacing a name with an internal identifier while retaining a link capable of reconnecting the information remains personal-data processing.

The retained record must still have a lawful purpose, retention period and access controls.

Where a physical record exists, it should be destroyed securely when retention ends rather than discarded through an exposed waste route.

Material deletion processes should produce sufficient audit evidence to confirm the category, period and result without recreating the deleted content in the audit log.

Backups may be maintained to restore critical records after accidental deletion, corruption, outage or security incident.

A backup must not be used as an informal permanent archive.

Backup retention follows the documented production-provider and system configuration applicable at the time.

The configured cycle must be recorded internally and reviewed before this Policy becomes effective.

Information deleted from the active service may remain temporarily in protected backups until the relevant backup expires or is overwritten.

The backup copy must not be restored to ordinary active use except for legitimate recovery.

Where an older backup is restored, deletion actions completed after the backup date should be reapplied where technically and operationally possible.

A recovery process must not permanently revive information whose lawful retention period ended.

Where a provider holds information outside the active 6membership database, 6membership may use the provider’s deletion, retention, restriction or account-closure controls.

The timing and available action may depend on whether the provider acts on 6membership instructions or independently controls the relevant record.

A provider may lawfully retain limited security, billing, fraud, tax, accounting, regulatory or dispute information after an operational deletion request.

When a provider relationship ends, 6membership should export necessary records, revoke access, rotate or revoke credentials, disable obsolete webhooks and request deletion or allow expiry of provider-held copies according to the applicable agreement and law.

Termination of an integration does not automatically require destruction of financial or evidential records that remain subject to a lawful retention obligation.

Flutterwave may retain payment, settlement, refund, chargeback, risk, fraud and compliance records under its own service and legal responsibilities.

Where 6membership accepts a valid privacy request concerning information shared with Flutterwave, 6membership may communicate the request or direct the requester to the appropriate Flutterwave process where required.

6membership must distinguish information deleted from its own active systems from information independently retained by Flutterwave or another financial institution.

6membership must not claim that every provider, financial institution, delivery system and backup copy was deleted immediately unless the available provider records support that statement.

A person may request deletion of personal information through the official privacy channel.

The request should identify the person, relevant application or membership and the information or processing concerned.

6membership may verify the requester before deleting or disclosing protected information.

Verification should remain proportionate and should not require more information than necessary.

Erasure may apply where the information is no longer necessary, consent was withdrawn and no other lawful basis applies, an objection succeeds, processing was unlawful or deletion is required by a binding legal obligation.

A deletion request may be limited where retention remains necessary for contract performance, payment verification, settlement, refunds, chargebacks, tax and accounting records, fraud prevention, security, legal obligations, authority requests, public-interest purposes, freedom of expression or the establishment, exercise or defence of legal claims.

Where complete deletion is not appropriate, 6membership may delete unnecessary documents, restrict access, remove public display or retain only a smaller required record.

Where appropriate and required, 6membership may communicate an accepted deletion or restriction request to relevant processors or recipients, including Flutterwave where the request concerns information shared for payment processing.

Flutterwave, a bank, card network or another financial institution may independently determine whether information it controls must be retained for regulatory, fraud, tax, accounting, settlement or dispute purposes.

This obligation is subject to legal, technical and proportionality limitations.

6membership will communicate the outcome of the request and may explain why particular information remains.

Where relevant, the response should distinguish information removed from 6membership systems from information independently retained by Flutterwave or another financial institution.

A limited request-and-response record may remain for accountability.

Only authorised roles should be able to approve or execute deletion of sensitive application, payment, audit, complaint or security records.

An ordinary verification reviewer should not automatically receive unrestricted permanent-deletion capability.

An administrator must not delete or alter an audit record to conceal an incorrect approval, decline, refund, access event or custom observation.

A high-impact deletion may require confirmation, reason entry or a second authorised review before execution.

The protection should be proportionate and should not obstruct valid privacy rights unnecessarily.

Bulk deletion must use a controlled process with scope validation, preview or review, audit logging and failure handling.

A malformed filter must not delete unrelated applicants or members.

Automated retention jobs should use defined dates and statuses and should avoid deleting records under an active legal hold, complaint, payment-verification issue, refund, chargeback, webhook investigation, security incident or other investigation.

A failed deletion job should generate an appropriate operational record or alert so that information does not remain indefinitely without detection.

A manual deletion or correction outside the ordinary workflow should record the reason, authorised person, affected records and outcome.

A privacy or administrative search should use the identifiers necessary to locate relevant records without exposing unrelated applicants or members.

A person’s access right may cover personal information and associated processing information, subject to applicable limitations.

It does not automatically provide access to another person’s private information, privileged advice or exploitable security details.

Archived records remain within the scope of a relevant search where they are reasonably accessible and connected with the request.

The existence of an archive must not be used to avoid applicable access rights.

6membership may not be required to restore an entire backup solely to respond to a request where the information is not reasonably accessible through ordinary production systems and another lawful approach is available.

The assessment depends on applicable law and the circumstances.

An export containing personal information should be generated and delivered securely, with appropriate authentication, expiry and access controls.

A temporary export created for a privacy request, audit or investigation should be deleted after secure delivery and the applicable validation period unless it forms part of an active case.

Where an applicable portability right exists, eligible information may be provided in a structured and commonly used format, subject to the rights of other people and technical feasibility.

An access or portability response may include payment information that 6membership received from Flutterwave and retains within its own systems.

The response does not automatically require 6membership to obtain every independently controlled record held by Flutterwave, a bank, card network or another financial institution.

Where appropriate, the requester may be directed to the relevant provider’s privacy process for records controlled independently by that provider.

Requests for access, correction, deletion, restriction, objection or information about a retention period may be sent to privacy@6membership.com.

Questions about an unsubmitted draft, submitted application, incomplete request or application document may be sent to applications@6membership.com.

Questions about an approved membership, card, certificate, status history or associated person may be sent to admin@6membership.com.

Suspected unauthorised access, record alteration, evidence destruction, exposed information or deletion failure may be reported to security@6membership.com.

A person may challenge a refusal to delete information, an excessive retention period, an incorrect deletion, continued public display or another records-handling decision.

The complaint should identify the relevant record and requested resolution.

Nothing in this Policy removes a mandatory right to contact the Nigeria Data Protection Commission, a consumer authority, court, financial institution, law-enforcement body or another competent authority.

Retention periods may be updated where legal obligations, provider capabilities, service functions, limitation periods or risk assessments change.

A change must not be used to conceal an earlier unlawful retention or deletion failure.

A material change affecting how long sensitive information remains, whether it becomes public or whether a deletion right is limited will be handled through the central policy-update framework.