Data Protection Policy

African Data Protection Laws

• Ghana: Data Protection Act 2012 (Act 843) — enforced by the Data Protection Commission (DPC)
• Nigeria: Nigeria Data Protection Act 2023 (NDPA) — administered by the Nigeria Data Protection Commission (NDPC)
• Kenya: Data Protection Act 2019 — enforced by the Office of the Data Protection Commissioner (ODPC)
• South Africa: Protection of Personal Information Act 4 of 2013 (POPIA) — enforced by the Information Regulator
• Rwanda: Law No. 058/2021 of 13/10/2021 on protection of personal data and privacy

International Frameworks

• EU General Data Protection Regulation (GDPR) — applicable to processing of personal data of EU data subjects or where Crednce's services are directed at EU residents
• UK GDPR and Data Protection Act 2018 — applicable to processing of personal data of UK data subjects
• ISO/IEC 27001 Information Security Management (aligned as a technical standard)
• ISO/IEC 27701 Privacy Information Management System (PIMS) — aspirational standard guiding our data governance architecture

Regulatory Authority Engagement

• Crednce maintains registration with relevant data protection authorities in jurisdictions where such registration is legally required
• We respond to regulatory enquiries and inspections promptly and cooperate fully with supervisory authorities exercising their lawful powers
• Material data breaches are reported to the relevant supervisory authority and affected data subjects in accordance with the mandatory notification timelines prescribed by applicable law

Lawfulness, Fairness & Transparency

• Personal data is processed only where a valid legal basis exists. All processing activities are documented in the Record of Processing Activities (ROPA) with their associated legal basis
• Processing is conducted in a manner that is fair to the data subject and does not mislead them as to how their data is used
• Data subjects are informed of all material processing activities through our Privacy Policy and, where required, through layered and just-in-time notices

Purpose Limitation

• Personal data is collected only for specified, explicit, and legitimate purposes, which are documented at the time of collection
• Data is not processed in a manner incompatible with the purpose for which it was originally collected. Where new processing is envisaged for a different purpose, a compatibility assessment must be conducted and a fresh legal basis identified if necessary
• Secondary uses of data (e.g. product analytics using transaction data) must be documented, assessed for compatibility, and disclosed to data subjects where required

Data Minimisation

• Only personal data that is adequate, relevant, and necessary for the specified purpose is collected and processed. We do not collect data "just in case" it may be useful in the future
• Product and engineering teams must complete a Data Minimisation Assessment as part of the design process for any new feature that involves personal data collection
• Existing data sets are reviewed periodically to identify data that has exceeded its useful life and should be purged

Accuracy

• Crednce takes reasonable steps to ensure personal data is accurate and, where necessary, kept up to date
• Customers are provided with mechanisms to review, correct, and update their own data via account settings
• Where data inaccuracies are identified — whether by the data subject, internal audit, or third-party notification — they are corrected without undue delay

Storage Limitation

• Personal data is retained only for as long as necessary to fulfil the purpose for which it was collected or as required by applicable law
• Data retention schedules are maintained and applied consistently across all processing systems. Retention periods are documented in the ROPA
• Data that has reached the end of its retention period is deleted or anonymised using approved methods. Deletion is verified and logged

Integrity & Confidentiality (Security)

• Personal data is processed with appropriate technical and organisational security measures to protect against unauthorised or unlawful processing, accidental loss, destruction, or damage
• Security standards are maintained in accordance with Section 07 of this Policy
• Access to personal data is restricted to those with a legitimate need and is enforced through role-based access controls, authentication requirements, and audit logging

Accountability

• Crednce is responsible for, and must be able to demonstrate compliance with, all of the above principles
• Accountability is operationalised through: data protection governance structures, the ROPA, Data Protection Impact Assessments (DPIAs), staff training, contractual requirements on processors, and regular compliance reviews

Contract

• Processing necessary for the performance of a contract to which the data subject is party or to take pre-contractual steps at their request
• Example: Processing account registration data to create and manage a user account; processing transaction data to execute a structured agreement and verification workflows between users.

Legal Obligation

• Processing is necessary to comply with a legal obligation to which Crednce is subject
• Example: Collecting and retaining KYC documents to satisfy AML/CFT regulatory requirements; producing transaction records in response to a court order

Legitimate Interests

• Processing is necessary for the purposes of legitimate interests pursued by Crednce or a third party, except where those interests are overridden by the interests or rights of the data subject
• A Legitimate Interests Assessment (LIA) must be completed and documented before relying on this basis
• Example: Using pseudonymised analytics data to improve Platform performance and detect abuse patterns

Consent

• The data subject has given freely given, specific, informed, and unambiguous consent to processing for one or more specified purposes
• Consent must be obtained via a positive opt-in action — pre-ticked boxes or bundled consent are not valid
• Consent must be as easy to withdraw as to give, and withdrawal does not affect the lawfulness of prior processing
• Example: Sending marketing emails or product updates — only to users who have explicitly opted in
• Consent is not relied upon for processing that is necessary for Crednce's core service delivery or compliance obligations

Vital Interests

• Processing is necessary to protect the vital interests of the data subject or another natural person. Crednce relies on this basis only in genuine emergency situations where no other basis applies

Special Category Data

• Special category data (including biometric data used for verification, and data revealing national origin or financial vulnerability) requires both a standard legal basis and an additional condition under applicable law
• Processing of biometric data for identity verification is processed under the explicit consent of the data subject combined with the legal obligation to conduct KYC
• Special category data processing is documented in the ROPA with both legal bases identified

Right of Access

• Data subjects may request confirmation of whether their personal data is being processed and, if so, a copy of that data along with supplementary information about the processing
• Responses are provided within 30 calendar days (extendable by a further 60 days for complex or multiple requests, with notification)
• Access requests are fulfilled at no charge unless they are manifestly unfounded, excessive, or repetitive — in which case a reasonable fee may be charged or the request refused

Right to Rectification

• Data subjects may request correction of inaccurate personal data and completion of incomplete data without undue delay
• Where rectified data has been shared with third parties, we notify those parties of the correction unless this is disproportionate or impossible

Right to Erasure ("Right to be Forgotten")

• Data subjects may request deletion of their personal data where: the data is no longer necessary for the purpose it was collected; consent is withdrawn (where consent was the only legal basis); processing was unlawful; or a legal obligation requires deletion
• Erasure requests cannot be fulfilled where retention is required by law (e.g. AML/CFT record-keeping obligations), where data is necessary for the establishment, exercise, or defence of legal claims, or where an overriding public interest applies
• Where erasure is refused, the data subject is informed of the reasons and their right to complain to a supervisory authority

Right to Restriction

• Data subjects may request restriction of processing in specified circumstances — for example, while the accuracy of data is contested, or while an objection to processing is considered
• During restriction, data is retained but not actively processed (other than for storage, legal claims, protection of third-party rights, or with the data subject's consent)

Right to Data Portability

• Where processing is based on consent or contract and is carried out by automated means, data subjects may request their data in a structured, commonly used, machine-readable format (JSON or CSV)
• Where technically feasible, data subjects may request direct transmission of their data to another controller

Right to Object

• Data subjects may object to processing based on legitimate interests at any time. Crednce must cease processing unless we can demonstrate compelling legitimate grounds that override the data subject's interests, rights, and freedoms
• Data subjects have an absolute right to object to processing for direct marketing purposes — this must be honoured immediately without exception

Rights Relating to Automated Decision-Making

• Data subjects have the right not to be subject to decisions based solely on automated processing that produce legal or similarly significant effects
• Where Crednce uses automated systems to make risk decisions (e.g. KYC verification outcomes, transaction monitoring alerts), human review is available upon request
• Data subjects will be informed when an automated decision has been made about them and will be given the opportunity to request a manual review

Submitting a Request

• Data subject rights requests should be submitted to dpo@crednce.io with the subject line "Data Subject Rights Request — [Your Name / Account ID]"
• We may need to verify the identity of the requestor before fulfilling the request — identity verification will be proportionate to the sensitivity of the data requested
• Requests received via Platform account settings are accepted as verified requests where the account is in good standing

Intra-African Transfers

• Transfers between African jurisdictions are governed by the applicable national data protection legislation of the originating country
• Where a receiving country has not enacted data protection legislation of equivalent standard, Crednce will apply the standard contractual protections described below
• Pan-African data transfers are reviewed annually as the African Continental Free Trade Area (AfCFTA) digital protocols and regional data governance frameworks evolve

Transfers Outside Africa

• Transfers to the European Economic Area (EEA) or to countries with an EU adequacy decision are permitted without additional safeguards
• Transfers to other countries are subject to one or more of the following safeguards: Standard Contractual Clauses (SCCs) approved by the relevant supervisory authority; Binding Corporate Rules (BCRs) where applicable; explicit consent of the data subject with full disclosure of the risks; or necessity for the performance of a contract to which the data subject is party
• Crednce maintains a register of all third-country transfers, the transfer mechanism relied upon, and the associated risk assessment

Cloud & Infrastructure

• Cloud infrastructure providers are selected based on security certification, data residency options, and contractual commitments on sub-processing
• Data residency preferences (where technically feasible and commercially reasonable) favour African data centres or data centres in jurisdictions with adequate data protection standards
• All cloud processing agreements include data processing addenda that bind the provider to our data protection standards and to applicable law

Technical Measures

• AES-256 encryption for all personal data at rest across production databases, object storage, and backup repositories
• TLS 1.3 encryption enforced for all data in transit between client devices and Crednce servers, and between internal services
• Tokenisation and pseudonymisation applied to sensitive fields (e.g. financial account numbers, national ID numbers) wherever processing does not require the original value
• Multi-factor authentication (MFA) enforced for all employee and contractor access to production systems and administrative interfaces
• Role-based access control (RBAC) with the principle of least privilege applied to all system access — employees access only the data required for their specific role
• Comprehensive audit logging of all access to personal data, with logs retained for a minimum of 12 months and monitored for anomalous activity
• Web Application Firewall (WAF), DDoS mitigation, and intrusion detection/prevention systems
• Regular automated vulnerability scanning and annual third-party penetration testing
• Secure development lifecycle (SDL) — security requirements are built into product design, code review includes security checks, and staging environments use anonymised data

Organisational Measures

• All employees and contractors with access to personal data complete data protection and information security training at induction and annually thereafter
• Background checks are conducted on employees in roles with access to sensitive personal data, in accordance with applicable employment law
• Clean desk and clear screen policies apply to all office environments
• Incidents and near-misses are reported via a defined internal process and reviewed in the monthly Information Security Committee meeting
• Business continuity and disaster recovery plans are maintained and tested at least annually to ensure personal data remains protected in adverse events

Third-Party Security

• All third-party data processors are assessed for security posture before engagement, using security questionnaires and, where appropriate, independent audit reports (SOC 2 Type II, ISO 27001 certification)
• Data Processing Agreements (DPAs) are executed with all processors before any personal data is shared, obligating them to equivalent security standards
• Material security incidents at processors must be notified to Crednce within 24 hours of the processor becoming aware

Detection & Internal Reporting

• Any employee, contractor, or third party who becomes aware of a potential data breach must report it to the Data Protection Officer (DPO) immediately and without undue delay — using the incident reporting channel designated by the Compliance team
• "Data breach" includes: unauthorised access to personal data, accidental loss or deletion, ransomware or malware affecting personal data systems, sending personal data to the wrong recipient, or exposure of personal data through misconfigured systems
• The DPO will initiate an Incident Response Procedure within 1 hour of receiving a breach notification

Severity Assessment & Containment

• The Data Protection team, in conjunction with the Information Security team, assesses the breach for: scope (what data, how many individuals), sensitivity of data involved, likelihood of harm to data subjects, and whether the breach is contained or ongoing
• Where the breach is ongoing, immediate containment steps are taken in parallel with the investigation — including revoking access credentials, isolating affected systems, or blocking data exfiltration paths
• Severity is classified as Low, Medium, High, or Critical based on defined criteria linked to the nature and volume of data involved

Regulatory Notification

• Where a breach is likely to result in a risk to the rights and freedoms of natural persons, Crednce will notify the relevant supervisory authority within 72 hours of becoming aware of the breach (or as required by applicable local law where the threshold or timing differs)
• Notification includes: nature of the breach; categories and approximate number of data subjects and records concerned; contact details of the DPO; likely consequences of the breach; and measures taken or proposed to address it
• Where notification is delayed beyond 72 hours, the notification includes an explanation of the reasons for the delay

Data Subject Notification

• Where a breach is likely to result in a high risk to the rights and freedoms of individuals, affected data subjects are notified directly, in clear and plain language, without undue delay
• Notification to data subjects describes: the nature of the breach; the name and contact details of the DPO; the likely consequences; and the measures taken or recommended to mitigate potential adverse effects
• Where direct notification is disproportionate (e.g. due to very large numbers of affected individuals), a public communication may be used instead — subject to supervisory authority guidance

Post-Incident Review

• All breaches are subject to a post-incident review within 14 days of containment, assessing root cause, remediation actions, and lessons learned
• Findings are presented to the Information Security Committee and, for High or Critical breaches, to the Board
• A breach register is maintained documenting all incidents — including those not meeting the regulatory notification threshold — for a minimum of 5 years

When a DPIA is Required

• Processing that uses new technologies and is likely to result in a high risk to individual rights and freedoms
• Systematic and extensive profiling or automated decision-making that produces legal or similarly significant effects
• Large-scale processing of special category data or criminal convictions/offences data
• Systematic monitoring of a publicly accessible area (e.g. geolocation at scale)
• Any new product, feature, or internal system that involves personal data collection at scale or introduces new data flows not previously assessed
• Transfers to third countries where no adequacy decision exists and Standard Contractual Clauses are proposed

DPIA Process

• The product or project owner initiates the DPIA by completing the DPIA trigger questionnaire in the internal compliance portal, at the design or scoping stage — not after deployment
• The DPO reviews the initial assessment and, where a DPIA is required, facilitates a structured assessment covering: description of processing, necessity and proportionality assessment, risk identification, and proposed risk mitigation measures
• Where high residual risks cannot be mitigated to an acceptable level, the processing cannot proceed without prior consultation with the relevant supervisory authority
• DPIAs are reviewed and updated when the nature of the processing changes materially, or at least every 3 years for ongoing processing activities

Processor Selection

• Processors are selected based on their ability to demonstrate compliance with applicable data protection law — including through certifications, audit reports, and contractual representations
• New processor engagements involving personal data require Data Protection team sign-off before contracts are executed
• Sub-processors (third parties engaged by our processors) must be disclosed to Crednce and are subject to the same contractual requirements as direct processors

Data Processing Agreements

• A Data Processing Agreement (DPA) is executed with every processor before any personal data is shared. The DPA includes: subject matter and duration; nature and purpose of processing; type of personal data and categories of data subjects; obligations and rights of the controller
• DPAs require processors to: process data only on Crednce's documented instructions; ensure confidentiality obligations on authorised personnel; implement appropriate security measures; assist Crednce in meeting data subject rights obligations; delete or return data on termination; and make available all information necessary to demonstrate compliance
• DPAs are reviewed at least every 2 years and updated when the processor's services or data flows change materially

Processor Oversight

• Crednce conducts annual data protection reviews of high-risk processors, which may include document review, questionnaire, or on-site audit
• Processors are required to notify Crednce of any data breach involving Crednce personal data within 24 hours of awareness
• Processor relationships are terminated where processors are unable or unwilling to meet the required data protection standards

Standard Retention Periods

• Customer account data: retained for the duration of the account plus 7 years from account closure, to satisfy financial records and dispute resolution obligations
• KYC and identity verification documents: 5 years from the end of the customer relationship, as required by AML/CFT legislation
• Platform activity records and transaction references: 7 years from the transaction date
• Customer support and communications: 3 years from the last substantive interaction
• Marketing preferences and consent records: retained indefinitely to honour opt-out decisions; underlying contact data deleted if account is closed
• Security and access logs: 12 months for operational logs; 7 years for security incident logs
• Employee and HR data: duration of employment plus 7 years
• DPIA and compliance records: 10 years from creation

Deletion & Anonymisation

• Data reaching the end of its retention period is deleted or anonymised within 90 days of the retention period expiry — deletion is not deferred indefinitely because it is inconvenient
• Deletion is permanent and irreversible. Crednce uses approved deletion methods that ensure data cannot be reconstructed — including overwriting for magnetic media and cryptographic erasure for cloud storage
• Where deletion is not technically feasible (e.g. backup tapes), data is isolated, access-restricted, and not used for any active processing, pending the next scheduled backup rotation
• Anonymisation must result in data from which no individual can be identified — either directly or indirectly. Pseudonymisation is not anonymisation and anonymised data is no longer personal data for regulatory purposes

Data Protection Officer (DPO)

• Crednce appoints a qualified Data Protection Officer who is responsible for: advising the organisation on data protection obligations; monitoring compliance with this Policy and applicable law; overseeing DPIAs; acting as the point of contact for supervisory authorities; and handling data subject rights requests
• The DPO reports directly to the Board and has operational independence — they cannot be dismissed or penalised for performing their data protection duties
• The DPO is contactable at dpo@crednce.io for all data protection matters

Board & Senior Management

• The Board of Directors approves this Policy and receives an annual data protection report covering compliance status, breach incidents, DPIA outcomes, and regulatory developments
• Senior Management is accountable for embedding data protection principles into product design, business processes, and vendor selection
• Material data protection incidents are escalated to the Board within 5 business days

Record of Processing Activities (ROPA)

• Crednce maintains a comprehensive ROPA documenting all processing activities, including: controller/processor identity; processing purpose; legal basis; categories of data subjects and personal data; recipients and transfers; retention periods; and security measures
• The ROPA is maintained by the DPO, updated within 30 days of any material change to processing activities, and made available to supervisory authorities upon request
• Product and engineering teams are required to update the ROPA as part of the launch process for any new feature or data flow

Training & Awareness

• All employees and contractors with access to personal data complete mandatory data protection training at induction and annually thereafter
• Specialist training is provided for roles with elevated data protection responsibilities — including product managers, engineers, customer support, and compliance staff
• Training completion is tracked; non-completion triggers escalation to HR within defined timeframes
• All new starters acknowledge this Policy and the Privacy Policy as part of their onboarding process