Privacy Policy

Sargo | Website and Kenya Services

Version 5.4 | Effective 24 September 2026

About this notice. This Privacy Policy explains how Sargo Ltd handles personal information for the Sargo website, business enquiries and related activities, and how personal information is handled when Kenya Services are made available by the Kenya Provider identified to you before collection. The identity of the controller, the purpose of processing and any service-specific recipients or transfers are provided at or before the point at which the relevant information is collected.

At a glance. Sargo Ltd may handle website, enquiry, security, support and compliance information. When Kenya Services are enabled, the relevant controller may also process account, identity, order, payment, wallet and dispute information to provide the Service, verify eligibility, prevent fraud and meet legal duties. Wallet activity on a public blockchain can be visible worldwide. A proof, hash or wallet address is not necessarily anonymous. We do not ask for your wallet recovery phrase or private key. Optional marketing and any consent-based biometric processing require separate choices; accepting Terms is not consent to everything described in this notice.

1. Who is responsible for your information

1.1 Website controller and TopCo. Sargo Ltd, company number 15206415, registered at 71-75 Shelton Street, Covent Garden, London, WC2H 9JQ, United Kingdom, operates the Sargo website and is a controller for website, merchant/business enquiry and other processing whose purposes and means it determines. It is referred to as the Technology Company. A controller decides why and how personal information is used.

1.2 Kenya Services controller. If you use a Kenya Service, the Kenyan company identified in the Service Details and the service-specific Privacy Details is the controller for the regulated Service and associated compliance processing to the extent it determines the purposes and means of that processing. Before collecting information for an enabled Kenya Service, we identify that company by registered name and number, address, contact details and applicable data-protection registration or representative information where required.

1.3 Group and supplier roles. A group label does not decide who is a controller. Sargo Ltd may act as a processor for the Kenya Provider for some technology or support functions, as an independent controller for its own security, corporate or legal purposes, or, only where the legal test is met, as a joint controller. Vendors may act as processors or independent controllers depending on the service and law. The Privacy Details explain the material role for each enabled processing flow. A processor acts only on documented instructions except where law independently requires otherwise.

1.4 Contact. For privacy questions or rights requests, contact support@sargo.io and mark the message “Privacy”. You may also use any in-application privacy or support route. The relevant controller’s postal contact is stated in the Service Details or Privacy Details. We publish the contact details of an appointed Data Protection Officer, local representative or other required privacy contact if and when that appointment is legally required.

1.5 Applicable regimes. The Kenya Provider applies the Data Protection Act, 2019 and applicable regulations to processing within their scope. Sargo Ltd applies the UK GDPR and Data Protection Act 2018 where they apply to its processing. More than one regime can apply to a particular flow. We do not use corporate structure or contractual labels to avoid a mandatory privacy obligation.

2. Where this notice applies

This notice applies to the Sargo website and blog, merchant or business enquiries, website and security operations, customer support, complaints, and records lawfully retained from prior activity. It also applies, when the relevant features are enabled, to Sargo accounts; wallet connections and signatures; buy and sell orders with a customer-selected merchant; merchant offers and participation; fiat-payment evidence; identity and business verification; payment-proof or dispute tools; sanctions, fraud and financial-crime controls; notifications; APIs and approved messaging or mini-app channels; and records required to operate or document those services.

A third-party bank, mobile-money service, wallet, blockchain, token issuer, verification provider, messaging platform or other external service may separately determine how it uses information. Its own privacy notice applies to processing for which it is an independent controller. Linking to or integrating a third party does not make Sargo the controller of all information that third party handles, and does not remove Sargo’s responsibility for the data flows Sargo determines.

3. Information collected and its sources

3.1 Website, app and technical use. Hosting, security and application infrastructure can receive IP addresses, device and browser details, requested URLs, request times, referring information, application version, error and security records, cookie or local-storage identifiers where enabled, and similar network or diagnostic information. Sargo’s website and authenticated application can use analytics technologies including Google Analytics and PostHog. Whether a particular analytics service is active depends on the Sargo property and configuration you are using; section 10 explains analytics and choice controls. A lack of cookies on one page does not mean that no technical data is processed elsewhere in the service.

3.2 Merchant enquiries. A merchant or business enquiry can include your name, email, experience as a merchant on other services, proposed transaction range, preferred payment rails and stablecoins, and how you heard about Sargo. A website form may prepare an email in your own email application rather than transmitting directly from the page. Your browser, email application and email provider may process the draft; Sargo receives the content when you send it. Do not include identity documents, passwords or sensitive banking material in a general enquiry.

3.3 Account, authentication and communications. Account functions can process your wallet address, username, email, telephone number, country, profile preferences, language/currency preferences, account and registration identifiers, authentication tokens, device or browser identifiers, security events, access failures and lockouts, notification preferences, profile image, and linked messaging identifiers such as Telegram or other supported channels. We also process chats, support messages, reviews, merchant-vetting information and related audit records where those features are used.

3.4 Identity and business verification. Depending on the enabled tier and justified due diligence, we or an identified verification provider can process your legal name, identification number and type, nationality/country, date of birth or other identity attributes where required, photograph or selfie, identification-document images, verification status and provider response. When identity verification is enabled, Sargo can use Smile Identity to process identity details, a selfie and an identity-document image for document or biometric verification. Business checks can include registration and tax identifiers, ownership, beneficial owners, directors, representatives, authority documents and relevant source-of-funds information. The collection screen identifies the fields actually required for the live service.

3.5 Wallet and signing data. For the core Kenya Service, we process wallet addresses, chain and token identifiers, wallet-provider information, signatures or signed challenges used to authenticate ownership, transaction hashes and public blockchain records. The core Kenya Service is designed for customer- and merchant-controlled self-hosted wallets connected through compatible browser, mobile or WalletConnect-style connections. Sargo does not need or request your plaintext private key or recovery phrase. Any future Sargo-provided custodial, hosted or embedded wallet service would require separate regulatory assessment, any necessary permission and a feature-specific notice explaining the key, storage, recovery and control model before activation.

3.6 Orders, fiat and payment data. Order and transaction records can include order/transaction IDs and references, chain and escrow addresses, direction, token, amounts, rates, fees, timestamps and statuses; client and merchant wallet addresses and usernames; payment method; bank, mobile-money or business numbers; account names and account numbers; beneficiary information; payment references; cancellation and dispute reasons; approvals; and settlement or refund information. A blockchain balance or history may be checked where needed for an authorised function or proportionate risk assessment.

3.7 Cryptographic payment-proof data. Sargo’s payment-proof system can process an authenticated bank response and encrypted session material in order to verify a payment or account. Depending on provider and proof type, extracted fields can include account number or account name, amount, currency, direction, date/time, bank reference, transaction description, recipient/counterparty, payment method, wallet/proof owner, request identifier and a transaction fingerprint. Proof objects, linked-transaction records and fingerprints can be stored in Sargo proof databases. Section 7 explains bank-session processing and possible public-blockchain registration.

3.8 Documents, complaints and files. The transaction and identity services can store verification or dispute documents and attachments, including through object-storage infrastructure, together with filename, size, content type, reference, notes and certification metadata. Dispute records can include names, contact information, fiat references and amounts, reasons, narrative evidence, reviewer comments and resolution notes. Upload only material reasonably necessary for the stated purpose.

3.9 Analytics, preferences and security. Where enabled, analytics can process page or feature use, wallet-provider events, wallet or user identifiers, onboarding events and transaction-stage metadata. The authenticated webapp can use PostHog for page views, interaction capture and product events, and a Sargo website implementation can use Google Analytics. Non-essential analytics are subject to the minimisation and choice rules in section 10. Security and fraud monitoring can separately process proportionate device, network, authentication and transaction signals on an appropriate non-marketing basis.

3.10 Other sources. Information can come from you, your authorised representative or business, counterparties, identity and screening providers, public company registers, public blockchain records, payment providers, wallet providers, messaging providers, security providers and competent authorities. Where we obtain personal data indirectly, we provide the information required by applicable law within the relevant period, including the Kenyan period where applicable, unless a lawful exception applies.

4. Why information is used and on what legal basis

We identify the basis for each particular purpose rather than relying indiscriminately on contract, consent and legitimate interests for everything. Legal obligations apply only when the relevant law actually binds the responsible entity. Sensitive and criminal-offence information needs additional conditions, not merely an ordinary lawful basis.

4.1 Individual account and order performance - contract. We use necessary account, contact, wallet, order and payment information to take steps you request before contracting, provide an agreed service, issue a receipt and administer an ordinary service enquiry. Information not objectively necessary for that service is not justified by calling it contractual. For an employee or representative of a business customer who is not personally the contracting party, necessary business-contact administration instead relies on the legitimate interest described in section 4.4, subject to applicable law.

4.2 Required identity, compliance and records - legal obligation. Where applicable anti-money-laundering, counter-terrorism/proliferation-financing, sanctions, tax, accounting, virtual-asset or other law requires identification, screening, recordkeeping or disclosure, the responsible controller processes the necessary information to comply with that identified duty. The legal register and collection notice identify the applicable requirement. A general desire for more information or an application for a licence is not itself an unlimited legal obligation to collect it.

4.3 Security and fraud prevention beyond mandatory checks - legitimate interests. We use proportionate technical, account and transaction indicators to protect the service, users and others against unauthorised access, fraud and abuse. We assess necessity and the effect on people’s rights and use safeguards such as restricted access, limited retention and review of adverse results. We do not use an untested fraud score as an unquestionable statement of criminal conduct.

4.4 Business enquiries, representatives and non-essential service improvement - legitimate interests. We use necessary business contact details to assess merchant enquiries, communicate with authorised representatives and maintain business relationships. Proportionate first-party operational analysis can help identify faults and improve the service. This does not authorise intrusive tracking, unrelated profiling or the use of identification records to train general-purpose AI. Where a device-storage rule separately requires consent, that rule must also be met.

4.5 Optional communications and consent-based features - consent. Where required, we ask separately before sending optional promotional messages, using non-essential tracking or performing a feature that relies on consent. The request names the purpose and relevant controller, identifies what is optional and provides a practical withdrawal method. Refusing marketing does not prevent a transaction. Consent to receive a support reply is not consent to promotional campaigns.

4.6 Disputes and legal claims. Routine order support uses the basis relevant to contract performance. Where information must separately be preserved or used to establish, exercise or defend a legal claim, we rely on the applicable legitimate interest and any required additional sensitive-data condition, or on a binding legal obligation where one applies. The reason and scope of a legal hold are recorded and reviewed. A speculative possibility of litigation does not justify keeping all data indefinitely.

4.7 New purposes. Before a materially different use, we assess compatibility and give the required information. Where fresh consent or another legal condition is required, we obtain it before the new processing. We do not retrospectively replace withdrawn consent with a different basis simply to continue the same optional use.

5. Identity, biometric and other sensitive information

A photograph becomes biometric data for legal purposes where it is processed by relevant technical means for unique identification or verification. Where enabled, Sargo uses Smile Identity functionality for document verification and biometric KYC, including selfie and identity-document processing. If that functionality is enabled, the collection screen identifies the controller, verification provider, purpose, exact inputs and outputs, whether a biometric template or liveness result is created, what Sargo receives, countries of processing, retention, the consequence of refusal and any available alternative.

Kenyan law treats biometric data and specified other categories as sensitive personal data. UK law treats biometric data used for unique identification as special-category data. We therefore identify both an ordinary lawful basis and any additional sensitive/special-category condition required by the law that applies. A regulatory duty to identify a customer does not automatically prove that facial recognition is necessary in every case. Where explicit consent is the relied-on condition, it is obtained separately and must meet the applicable standard; where consent cannot be freely given, another lawful condition must genuinely apply or the biometric route remains disabled.

Raw images, templates and detailed provider responses are not automatically retained for as long as a regulatory identity record. Their retention requires its own necessity and legal analysis. Verification providers are contractually restricted from unrelated marketing or general-purpose model training to the extent required by our role and applicable law. A failed or uncertain biometric or screening result can be wrong and must be capable of appropriate human investigation; refusal or inability to use an optional biometric tool is not itself evidence of wrongdoing.

Information about convictions, alleged criminal conduct, sanctions and politically exposed status is handled proportionately and under any additional conditions that apply. A sanctions or PEP match is a risk signal, not a finding of criminal conduct.

6. Automated processing and human review

Enabled functions may automatically apply eligibility checks, transaction limits, fraud alerts, proof-validation rules and order timers. The licensed Kenya Service does not use personal information to automatically allocate a customer request to a merchant: the customer selects the merchant and that merchant acts as the identified counterparty for the order. For example, a payment check may compare the disclosed account identifier, amount, currency, direction and time against an order and reject duplicate references. A failed payment-data comparison can delay or block an order, request more information or initiate review; it is not necessarily proof of fraud or non-payment.

Where an automated outcome has legal or similarly significant effects, we explain the relevant logic in meaningful terms, principal information used, expected consequences, safeguards and review route before the feature operates. A technical model’s source code need not be published to explain the actual grounds for a decision. We comply with restrictions and exceptions under applicable Kenyan law and the current UK automated-decision regime where it applies, including additional safeguards for sensitive information.

You may ask for an explanation, correct relevant information, express your position, contest the outcome and request meaningful human review. The reviewer must have competence and authority to reassess the matter or arrange a remedy, not simply endorse the score. We do not claim there are no significant automated decisions when a timer or verification result can materially affect access to funds. A technically irreversible settlement does not extinguish legal rights or prevent investigation and an appropriate remedy.

7. Payment proofs, bank sessions, wallet signatures and public blockchains

7.1 What the proof system does. For the proposed proof-enabled Kenya Service, the merchant ordinarily initiates the technical payment proof from the merchant’s own supported payment account and device or browser. For a customer purchase, the proof can verify receipt and, only where a validated complete-record method is enabled, non-receipt of the matching Kenyan shilling payment. For a customer sale, it can verify the merchant’s matching outgoing payment. The proof flow can capture an authorised bank request or authenticated session material, including protected session headers, and encrypt that material on the merchant’s device before it is transmitted to the designated attestation environment. The attestation service can decrypt it inside that environment, replay the narrowly scoped bank request, inspect the returned source record, extract selected fields, bind them to the requested order, generate a fingerprint to reduce proof reuse, and sign a cryptographic claim. The customer does not ordinarily need to provide the merchant with the customer’s banking password, PIN, OTP or banking session for this merchant-generated proof. This is privacy-reducing compared with sending a full statement to a counterparty, but it is not accurate to say that only the final proof leaves the device or that no authenticated session material leaves the merchant’s device.

7.2 Session credentials and who can see them. Supported providers can designate fields such as bank session cookies or authorisation headers as secret session material. In the merchant-generated proof flow, that material belongs to the merchant’s authenticated payment session and is encrypted before transmission to the designated attestation environment. It must not be exposed to the customer or another merchant, and it must not be placed in ordinary support messages or public logs. Sargo support does not need a banking password, PIN or one-time password, and you should not send those values to Sargo. The live feature notice identifies the attestation operator/environment, scope, duration, retention and material transfer location before use. The proof service is designed not to store raw bank-session credentials as persistent proof fields. We must also prevent unnecessary logging or persistence of this material and apply deletion controls in operation.

7.3 Proof contents, non-receipt checks and off-chain storage. A generated claim can include request metadata and extracted payment/account fields in JSON parameters and context, including amount, currency, date or time, reference, account or counterparty identifiers, description, payment method, request/order identifiers, wallet address, linked-transaction data and a transaction fingerprint. Where a non-receipt proof is enabled, the feature must use the complete defined source records needed for the stated period; Sargo must not infer non-receipt merely because a payment is absent from a partial page, selected result or incomplete query. The proof API can retain the proof JSON and linked-transaction/fingerprint records for validation, replay prevention, dispute handling and required records. These records are personal data where linkable to a person. A cryptographic hash or fingerprint is normally pseudonymous rather than anonymous when it remains linkable to the underlying transaction.

7.4 On-chain registration. Where this feature is enabled, Sargo’s verifier contract records whether a proof identifier has been registered and maintains proof counters. To register a claim, however, the blockchain transaction call includes the claim’s parameters and context. Public nodes, block explorers and other parties can inspect historical transaction input data, so extracted fields placed in those strings may become publicly accessible and practically irreversible even if the verifier contract does not store the full strings in its own state variables. Before this path is enabled, Sargo must minimise the submitted claim to what is necessary, perform the required privacy assessment, tell you which fields will become public and obtain any required affirmative choice. Direct identity-document images, selfies, passwords, PINs, OTPs and raw bank statements must not be published through the proof flow.

7.5 Wallet and escrow records. Public-chain transactions can reveal wallet addresses, token transfers, amounts, timestamps, contract calls and events. Historic pilot contracts may also contain public records of administrative actions taken under the retired pilot architecture. The proposed licensed production architecture uses order-specific prescribed settlement outcomes and is described in the applicable Control Notice. A wallet address can be linked to off-chain identity, payment information or a counterparty’s records. Independent blockchain nodes and explorers are not all Sargo processors.

7.6 Corrections and erasure. Sargo may be unable to alter data already written to an independent public blockchain or copied by third parties. We still assess rights requests, correct or delete off-chain records where required, minimise avoidable links, restrict further processing where appropriate and explain what can and cannot be changed. An irreversible technical record is not a blanket exemption from data-protection law.

8. Sharing and recipients

8.1 Your counterparty. The merchant selected and authorised for your order receives only the information needed for the transaction or lawful related checks, such as verified trading identity, payment beneficiary details, order amount, reference and necessary confirmation. It does not automatically receive your full identity-verification file or unrelated account history. Merchant-facing notifications and interfaces must minimise information and must not disclose customer payment details to merchants who are not entitled to act on the specific order.

8.2 Service providers. Depending on enabled functions, contracted providers support hosting, databases, authentication, identity verification, screening, payment verification, messaging, email, customer support, security and professional services. The adopted provider disclosure identifies the providers actually used, their role, data, locations and material access. Processors act under appropriate written instructions and safeguards. We assess subcontractors and give any information or notice required by law or contract.

8.3 Independent controllers. Banks, mobile-money providers, external wallet providers, merchants, professional advisers, messaging platforms and screening or verification providers may be controllers for some purposes and processors for others. Their actual role is disclosed rather than describing every recipient as a processor. They may have separate lawful retention and reporting obligations. We remain responsible for the lawfulness of our own disclosure to them.

8.4 Authorities and claims. We share necessary information in response to lawful requirements, regulatory reporting, competent court orders, fraud or crime reporting with a valid basis, and the protection or exercise of legal claims. We assess the requester’s authority and scope. Legal restrictions may prevent us from telling you about a particular report or investigation. We do not sell access to personal data under the label of compliance.

8.5 Business transfers. A reorganisation, financing, acquisition or insolvency may require limited disclosure to advisers or prospective counterparties under appropriate confidentiality, minimisation and legal safeguards. Any actual transfer of accounts or controller responsibility requires the appropriate lawful basis, notice and other conditions. Group membership does not authorise unrestricted sharing or an automatic migration to an unnamed Kenyan company.

8.6 No unrelated exploitation. Under this policy we do not sell personal information, allow merchants to reuse payment details for unrelated marketing, or use identity documents, biometric templates or banking records to train general-purpose AI models. A proposed new use must undergo the section 4.7 process; a unilateral policy update does not make an unlawful use lawful.

9. Countries and international transfers

The UK Technology Company and Kenyan operations can involve access in the United Kingdom and Kenya. Other hosting, verification, messaging and support destinations depend on the providers actually enabled. Remote access from another country can itself be a transfer. The adopted provider disclosure must name the relevant destinations and transfer arrangements before the corresponding processing begins; “global providers” is not an adequate inventory.

For transfers from Kenya, the responsible controller must meet the applicable Data Protection Act and General Regulations requirements, including suitable safeguards or another lawful route and any required proof to the Data Commissioner. For sensitive personal data processed outside Kenya, section 49 requires consent and confirmation of appropriate safeguards; consent alone is not enough. Applicable localisation and sector-specific requirements must also be assessed. We do not assume that a UK incorporation or a vendor’s general privacy notice supplies these safeguards.

For restricted transfers subject to UK GDPR, we use an applicable adequacy arrangement, appropriate safeguards such as an executed UK International Data Transfer Agreement or applicable UK Addendum, or a narrowly applicable lawful exception. We assess the required level of protection and additional measures. We do not claim a contract has been signed, a destination is adequate or an assessment has passed until verified for the actual transfer. Routine high-volume transfers are not justified solely by a blanket consent clause.

You may request information about the relevant safeguards and, where applicable, a copy, subject to appropriate redaction of confidential or security information without withholding its essential protections. Public-ledger disclosures and independently chosen messaging services have distinct risks; they do not remove Sargo’s responsibility to assess disclosures it initiates.

10. Analytics, cookies, external resources and messaging

10.1 Analytics used in Sargo services. A Sargo website implementation can use Google Analytics, and the authenticated webapp can use PostHog. PostHog can process page views, interaction/autocapture events, page-leave events and product events relating to wallet connection, onboarding and transaction stages. The cookie or settings interface for the Sargo property you are using identifies which non-essential analytics are active and provides the applicable choices.

10.2 Minimisation and choice. Non-essential analytics must be configured so that legally required consent or equivalent choice is obtained before collection and can be withdrawn without losing a service that does not genuinely depend on analytics. Where we offer an analytics preference, the analytics tools must respect that choice. Analytics must exclude identity-document images, biometric data, bank-session material, bank credentials, plaintext recovery material and unnecessary payment-account information. Full transaction objects must not be sent merely because an event library accepts them. Where event-level transaction metadata is genuinely necessary, fields are minimised and documented.

10.3 Cookies and similar technologies. Necessary storage can be used for authentication, security, fraud prevention, load balancing and user-requested functionality on an appropriate lawful basis. Analytics, advertising or other non-essential cookies/SDK storage are handled through the applicable consent or preference mechanism. The current production cookie/technology notice must identify material technologies, purposes, providers and expiry or retention information rather than relying on this Policy alone.

10.4 External resources. Sargo deployments may request resources from providers such as Google or wallet/network infrastructure, which can disclose IP address, browser information, requested resource and timing. We review material external resources and international transfers before deployment and may self-host or replace them where appropriate.

10.5 Messaging and notifications. Sargo services can send email, SMS/WhatsApp, Telegram and push notifications, including through providers such as Twilio, Telegram and Firebase where configured. Those providers receive the identifiers and message metadata/content necessary for the chosen channel. A bot, group, SMS or email channel is not assumed to provide end-to-end confidentiality. Do not send passwords, bank PINs, OTPs, recovery phrases, private keys or unencrypted bank-session credentials through support or messaging.

10.6 Preferences and marketing. Marketing preferences are separate from transaction, security and legally required messages. Where consent is required, it is not bundled or pre-ticked and can be withdrawn through a practical route. We keep enough suppression information to honour an opt-out. Analytics or messaging preferences do not prevent processing genuinely necessary on another lawful basis, which we explain.

11. How long information is kept

We keep information only for the relevant purpose and any applicable statutory minimum, legal hold or justified defence of a claim. We use a documented category-based schedule rather than one blanket period. Deleting an account does not necessarily delete a required transaction record, and a minimum regulatory period does not justify keeping every selfie, bank-session artefact, analytics event or unrelated message for the same duration.

11.1 Regulated transactions and complaints. Where the Kenya Provider is subject to applicable VASP recordkeeping duties, transaction and required activity/complaint records are kept for the applicable statutory period, including the seven-year periods that apply to specified regulated records. The schedule records the correct triggering event for each record type. Public blockchain data can remain accessible independently of Sargo after an off-chain record is deleted.

11.2 Identity and compliance. We retain the verification result and supporting evidence only to the extent required for customer due diligence, ongoing monitoring, audit, legal claims or another documented purpose. Raw selfie/biometric material, unnecessary document copies and full provider payloads require separate justification and may have a shorter period than the core KYC record. The live collection notice identifies the provider-side and Sargo-side retention applicable to the enabled verification flow.

11.3 Proof and bank-session material. Proof results, linked-transaction records and anti-replay fingerprints can be retained with the associated transaction/dispute record where necessary. Authenticated session cookies, authorisation headers and raw bank responses are designed for narrowly scoped verification and must not be retained merely because a proof record is retained. Production systems must use short technical lifetimes and deletion/logging controls for this source material, subject only to a separately identified legal or incident-preservation need. Data intentionally submitted to a public blockchain may remain retrievable indefinitely.

11.4 Analytics and technical logs. Analytics events and identifiers use the shortest period reasonably necessary for product measurement and are deleted or aggregated according to the production analytics configuration. Security, authentication and audit logs can be retained for a different risk-justified period. A security log is not repurposed for marketing merely because the same user identifier appears in both systems.

11.5 Enquiries, messaging and account administration. We retain enquiries and communications while responding and for a limited follow-up, complaint or claims period where justified. Business-onboarding records transition to the appropriate account/compliance category if an application proceeds. Unsuccessful or abandoned applications are reviewed and deleted or genuinely anonymised when their purpose and any justified defence period end. Notification-provider records follow the relevant provider/configuration and are not kept indefinitely by default.

11.6 Backups, preferences and legal holds. Backups follow an identified overwrite cycle; deleted data is not restored into ordinary use without reapplying the deletion. Consent evidence and minimal suppression records can be kept as needed to demonstrate a choice or honour an opt-out. A regulator direction, court order, incident or genuine ongoing claim may justify a longer restricted hold for identified records, but not unrestricted continued use.

You may ask for the retention period or criteria applicable to your information. The Service-specific Privacy Details provide the actual periods or meaningful criteria for material providers and high-risk source data before the relevant feature is enabled.

12. Security and personal-data incidents

We are responsible for appropriate technical and organisational safeguards proportionate to the data and risks. These include appropriate access control, authentication, confidentiality, secure transmission and storage, staff and provider controls, logging, recovery arrangements, secure disposal and incident handling. The actual implementation must be verified; this notice does not claim a certification, audit or encryption configuration that has not been evidenced.

No system is perfectly secure. Use an appropriate device lock, protect credentials and verify the recipient before sharing information. Your duty to take care does not absolve Sargo of its own security obligations. Report suspected exposure through support without posting the affected data publicly.

We investigate suspected breaches, preserve appropriate evidence, mitigate harm and make regulatory and affected-person notifications where legally required. Applicable notification duties and deadlines run from the legally relevant awareness and risk thresholds; they do not wait for an internal investigation to be complete. Where a notification can lawfully be provided in stages, we provide outstanding information without undue delay. We do not promise that no breach can occur or that every incident is automatically exempt from notification.

13. Your rights and how to exercise them

Subject to the applicable law and its conditions, you may request information about processing; access and a copy of your data; correction; erasure; restriction; portability; objection to processing; withdrawal of consent; and safeguards or review relating to significant automated decisions. You may complain to a regulator and seek a remedy. Your rights are not waived by a blockchain transaction, a trade deadline, account closure or acceptance of our Terms.

Contact the privacy route in section 1.4. Identify the request sufficiently for us to locate the information. We may ask for proportionate identity or authority verification, especially before disclosing financial or identity records; we do not automatically require a new selfie or a full passport copy for every request. We help authorised representatives and people requiring an accessible channel. A request does not need special legal wording.

We normally provide rights responses free of charge. Any refusal, restriction or permitted fee must have an applicable legal basis, be proportionate and be explained with the available complaint route. We protect other people’s information and apply legal exemptions only where the relevant conditions are met, not by declaring all fraud or compliance records exempt.

Kenyan response periods. Where the Kenyan General Regulations apply, the relevant periods include seven days for access; fourteen days for rectification, erasure, restriction and objection; and thirty days for portability. Certain refusals require a response within seven days, and the rules include a seven-day response requirement for restricting third-party direct marketing. We apply the requirement appropriate to the specific request, including any shorter required response, rather than replacing all of them with a one-month target.

UK response periods. Where UK law applies, we respond to rights requests without undue delay and within the applicable period, generally one calendar month. Any lawful extension, identity clarification, pause or limitation is used only where its conditions are met and is explained within the required time. Where the same request attracts a shorter applicable Kenyan deadline, we do not rely on the UK period to ignore it.

Objection and withdrawal. You may object to processing based on legitimate interests and explain your situation; we assess the applicable balancing and legal conditions. Objection to direct marketing is honoured without requiring you to justify it. You may withdraw consent through the same practical route used to give it or through support. Withdrawal does not make past lawful processing unlawful, and necessary processing on a genuinely separate basis is explained rather than concealed. It does not automatically erase statutory records.

Accuracy and remedies. We take reasonable steps to correct relevant data and notify recipients where required. We explain material inability to erase an independent blockchain record and the actions available for associated off-chain data. A technically final order does not prevent you from challenging an inaccurate compliance record or obtaining a legally required remedy.

14. Privacy complaints and independent regulators

We aim to acknowledge a privacy complaint within two working days and begin investigating without undue delay. For a complaint within the UK statutory organisational-complaints regime, we acknowledge within the applicable 30-day maximum, keep you informed and provide an outcome without undue delay. The acknowledgement period is not permission to postpone investigation. A complaint involving a rights request is also tracked against that request’s separate, potentially shorter deadline. A licensed-service complaint may also attract the 21-day progress-update commitment in the Terms.

You may complain to Kenya’s Office of the Data Protection Commissioner (ODPC), through its official complaint channels at odpc.go.ke, where the Kenyan regime applies. Where UK data-protection law applies, you may complain to the Information Commissioner’s Office (ICO) through ico.org.uk. We encourage contacting us so we can address the issue, but this is not a contractual bar to a statutory complaint, court remedy or urgent action. We explain the relevant escalation options in our response.

15. Children and information about other people

Sargo transaction accounts are for adults aged 18 and above. We do not intentionally offer them to children. A public website can nevertheless be accessed by a child; an age rule is not proof that no child data reaches us. Where we learn that an ineligible child’s information has been collected, we assess the lawful steps to stop the account, protect the child, delete unnecessary information and retain only what is justified, such as a required safeguarding or fraud record. We do not routinely collect a parent’s identity merely to allow an ineligible trading account.

Only provide information about another person when authorised or otherwise lawfully entitled to do so and relevant to the requested service. Business representatives must help supply appropriate notice to beneficial owners and other individuals where necessary. This does not shift the controller’s own notice obligations entirely onto the person submitting a form.

16. Changes to this notice

We identify the version and effective date of the adopted policy and retain prior versions relevant to existing processing. We give appropriate notice before a material change, particularly a new controller, purpose, sensitive-data use, recipient or transfer. We obtain fresh consent or meet other required conditions before the changed processing where necessary. Merely posting a revision does not validate an earlier unlawful act or authorise unrelated reuse of existing data.

A transfer of a service or personal data between Sargo group entities must identify the receiving entity, explain its role and contact details, describe any material change in processing before it occurs, and use a lawful international-transfer mechanism where required. A general statement that Sargo may reorganise is not a substitute for required notice or consent. Existing requests, complaints and retention obligations must be handled through the transition rather than restarted or lost. If Sargo Ltd provides technology to the Kenya Provider, its controller or processor role is documented according to what it actually does, not merely its group title.

17. Service-specific Privacy Details and integrations

This Privacy Policy is supplemented by Privacy Details shown at or before collection for enabled Services where additional factual information is needed. The Privacy Details are versioned and form part of this notice. They do not reduce the rights or protections in this Policy. If a feature-specific notice differs from this general Policy about a fact specific to that feature - for example the active vendor, destination country or retention period - the more specific current notice governs that factual detail.

17.1 Controller details. For each enabled Kenya Service, the Privacy Details identify the Kenya Provider and any other controller whose identity must be provided, including addresses, monitored privacy contact, relevant ODPC registration information and any appointed DPO or representative where applicable. Company or data-protection registration is not described as regulatory endorsement.

17.2 Provider categories. Depending on the features you use, Sargo may use service providers or infrastructure for identity verification through Smile Identity; AWS-compatible object storage for files; Google Analytics and PostHog analytics where lawfully enabled; Firebase push services; Twilio messaging; Telegram; email delivery; compatible wallet/WalletConnect providers; public blockchain/RPC infrastructure; and supported bank or payment sources used by the cryptographic proof system. The Privacy Details identify material providers that are active for the relevant Service, their role, categories sent or received, sensitive or session data involved, material access/storage countries, transfer mechanism and retention where required.

17.3 Proof-specific notice. Before a bank-proof flow is used, the notice identifies the bank/source, whether the merchant or another party initiates the proof, the attestation environment/operator, whether authenticated session material is transmitted, extracted fields, proof-database retention, any counterparty disclosure, whether complete-record non-receipt verification is supported, the applicable outage/alternative route, and whether on-chain registration is enabled. If on-chain registration is enabled, the notice must accurately describe the transaction call data that can become public rather than stating only that a hash is stored.

17.4 Wallet-specific notice. The core Kenya Service uses customer- and merchant-controlled self-hosted wallets and does not require Sargo to hold the user’s private key or recovery phrase. If a future Sargo-provided custodial, hosted or embedded wallet service is separately authorised, its notice will explain the key-generation, encryption, storage and recovery architecture and whether Sargo or a provider can restore, reset, decrypt or otherwise control the wallet before that feature is activated. A wallet service will not be described as “non-custodial” merely because a private key is encrypted.

17.5 Automated and high-risk processing. If a feature makes or materially contributes to a decision producing legal or similarly significant effects, uses biometric recognition, processes high-risk bank-session material or publishes linkable information on-chain, the required DPIA or equivalent assessment is completed before activation. The notice explains material inputs, consequences and human-review route where applicable.

17.6 Website and app technologies. Sargo may operate more than one web property, and sargo.io and app.sargo.io can use different technical stacks and analytics configurations. We do not make a blanket claim that every Sargo property uses the same analytics or cookies. The cookie or technology notice and settings for the property you are using describe the non-essential technologies that are active there.

Version history. Version 5.4 replaces the Privacy Policy dated 12 June 2026 previously published on sargo.io. Earlier versions relevant to prior processing are retained and made available on reasonable request.