sendaya

Version 2026-09-05-draft-1

DRAFT NOTICE. This document is a draft prepared for review by qualified legal counsel in each launch jurisdiction and does not constitute legal advice.

Sendaya — Privacy Policy

Version: 2026-09-05-draft-1 Effective on acceptance. Superseded when a new version is published and re-accepted at the User's next authenticated session.

Plain-language summary of the whole document. Sendaya holds and moves money for elderly recipients in Africa. To do that safely, we need to know who you are, who the money is for, how you contact each other, and where the money is going. We hold identity documents, phone numbers, voice recordings, PIN hashes, call logs, text messages, and transaction data. We use it to run the Service, meet our legal obligations, and protect you from scams. We do not sell personal data. We do not run ads. Circle members see limited things about a Senior's account; the Senior can narrow what they see. Agents only ever see the exact amount to pay out. We keep AML records for as long as the law says. You can access, correct, and delete your data subject to those legal limits. A Senior can exercise their rights over the phone, by USSD, or through a trusted Circle member. This is a draft prepared for review by qualified legal counsel in each launch jurisdiction and does not constitute legal advice.

1. Who is the Controller

1.1 Plain-language summary

We — Sendaya — are the company that decides what we do with your personal data. If you signed up through a bank or telco under a co-brand, that partner is the primary controller and we help them run the platform.

1.2 Sendaya as controller

For Users who register with Sendaya directly (not via a Tenant), the controller of personal data is [SENDAYA OPERATING ENTITY], incorporated in [JURISDICTION OF INCORPORATION] with registered office at [REGISTERED OFFICE ADDRESS].

1.3 Tenant joint-controller structure

For Users who register via a Tenant (a bank, MNO, or remittance partner), the Tenant is the primary controller for personal data processed in respect of the Tenant channel. Sendaya is a processor for the payment-service data and a joint controller with the Tenant for a limited set of platform-level personal data (fraud-signal cross-referencing, sanctions screening, Rail-Partner reconciliation, and cross-tenant device fingerprints used to detect scams that span tenants). The scope of joint-controllership is described in Section 8 and in the Tenant DPA at /legal/TENANT_DPA.md.

1.4 Data Protection Officer

Sendaya's Data Protection Officer, where required to be appointed, is reachable at [DPO@EMAIL] and by post at the registered office marked "Attn: DPO". Users in Nigeria may also contact [NDPA DPO EMAIL] as the Data Protection Officer appointed under the Nigeria Data Protection Act 2023.

1.5 EU and UK representatives

Where Sendaya is not established in the EU or UK but processes personal data of data subjects there, Sendaya has appointed:

  • (a) an EU Article 27 representative at [EU REP NAME AND ADDRESS];
  • (b) a UK Article 27 representative at [UK REP NAME AND ADDRESS].

1.6 Regulators

Sendaya's data-protection supervisory authorities in each country are named in the Country Annex.

2. Definitions

Terms in this Privacy Policy have the same meanings as in the Sendaya Terms of Service (/legal/TERMS_OF_SERVICE.md) unless a different meaning is stated below.

  • "Data subject" means an identified or identifiable natural person whose personal data Sendaya processes. Data subject categories include: Sender, Senior, Agent, Beneficiary, Biller contact, and Ops staff.
  • "Personal data" has the meaning given in the applicable data-protection law (including UK/EU GDPR, the Nigeria Data Protection Act 2023, the Kenya Data Protection Act 2019, and the Ghana Data Protection Act 2012).
  • "Special category data" (also "sensitive data") means personal data whose processing is subject to heightened protection under the applicable law, and includes for Sendaya's purposes: biometric-adjacent voice samples used for authentication; voice-based identification data; and health-adjacent inferences derived from Medicine Wallet activity.
  • "Processing" means any operation performed on personal data.
  • "Circle member" means a Sender or Guardian invited to a Senior's Circle.
  • "Duress event" means the event where a Senior enters the Duress PIN.
  • "Rate provenance record" means the record of FX data providers and rates used at a given moment; contains no personal data on its own but is linked to a User's transaction.

3. Data We Collect

3.1 Plain-language summary

We collect different things depending on who you are. For a Sender: identity, address, funding-method data. For a Senior: identity, phone, voice sample, PIN hash, transaction data. For an Agent: identity, location of their kiosk, float and payout logs. For a Beneficiary: name and contact. Some of it is sensitive.

3.2 Data collected — table by data-subject type

The following categories of personal data are collected, per data-subject type.

3.2.1 Sender

Category Examples
Identity Full legal name; date of birth; nationality; government-issued ID number and image (passport, driver's licence, national ID); tax ID where required.
Contact Residential address; email; primary phone; alternative phone.
Government ID images and numbers Front and back scans of an accepted ID; selfie for face-match; document metadata.
Financial and transaction data Funding-method details (masked card PAN, bank account, remittance-partner reference); transaction amounts, timestamps, counterparties; funding and Cash-out history; fees charged.
Device and app data Device model; OS version; app version; IP address; approximate location derived from IP; app-crash logs.
KYC results Match/no-match verdicts from KYC vendors; risk score; sanctions/PEP screening results.
Support communications In-app messages; chat transcripts; call recordings when a Sender uses the support IVR.
Preferences and settings Language; currency preferences; notification preferences.

3.2.2 Senior

Category Examples
Identity Full legal name; date of birth; nationality; ID number and image where available; photograph.
Contact Primary phone; alternate phone; residential address; language.
Biometric-adjacent Voice samples taken at onboarding, later re-enrollment, and any Trusted-Voice recording spoken by the Senior. Used for voice-authentication anti-fraud, not for public identification. Handled as special category / biometric where the applicable law so treats.
Voice PIN The hash of the PIN and Duress PIN, not the PIN itself.
Trusted Voice recordings Audio files recorded by Circle members intended for the Senior, and recordings by the Senior intended for Circle members.
Call and IVR data Full IVR session recordings; DTMF logs (key presses); menu selections; timestamps; carrier metadata.
USSD / SMS / WhatsApp Message content and metadata; short-code session logs; delivery status.
Device and app data Where the Senior uses the Senior App: device model, OS, IP, app version.
Location of Cash-out events Latitude/longitude of the Agent kiosk at the time of Cash-out; a per-transaction record, not continuous tracking.
Financial and transaction data Wallet balance; Local Buffer balance; Cash-out history; Biller-pay history; Goal Jar activity; Medicine Wallet activity.
FX and custody records The Applied Rate, Mid Rate, Spread, and rate provenance for each conversion; the Custody Pool the funds sat in.
KYC results Vendor match verdicts and risk scores.
Scam and duress events Timestamps of Scam Shield triggers, Duress events, Whitelist changes, PIN change attempts.
Inactivity data Last activity timestamps; escalation stage.
Health-adjacent inference (sensitive) Medicine Wallet activity allows inference about health conditions (frequency of pharmacy spend, hospital categories). Treated as sensitive personal data (see Section 6).
Beneficiary designation record Beneficiary name, phone, relationship, and the voice-authentication record of the nomination.

3.2.3 Agent

Category Examples
Identity Full legal name; date of birth; nationality; ID number and image; passport-style photo; face-match selfie.
Contact Business address; kiosk address (used for the location record shown to Users); phone; email.
Kiosk data Location coordinates; opening hours; float balance; float top-up and withdrawal history.
Trust score data Cash-out throughput; refusal rate; complaint rate; trust-score history; training records.
Device data Agent-device fingerprint; app version; OS; IP.
Financial and transaction data Cash-out redemption logs; commission history.
KYC results Match verdicts; sanctions screening.

3.2.4 Beneficiary

Category Examples
Identity Name; date of birth (if provided); relationship to Senior.
Contact Phone; email (if provided); address (if provided).
Voice-authentication record Recording of the Senior's voice-based nomination naming the Beneficiary.
Claim documentation Death certificate; probate documents; ID of claimant; provided at claim time only.

3.2.5 Biller contact

Category Examples
Business identity Business name; registration number; category tag (utility, pharmacy, school, hospital, mobile-top-up).
Contact Business address; support phone; support email.
Payment routing Bank account or MoMo number to which Biller payments are directed.

3.2.6 Ops staff

Category Examples
Identity Full legal name; role; employee/contractor number.
Access data Authentication logs; role assignments; access-review records.
Action audit Every mutating action performed by Ops staff is logged with timestamp, actor, and metadata.

3.3 Children's data — not collected

The Service is not intended for anyone under 18. Sendaya does not knowingly collect personal data from persons under 18. If we discover we have inadvertently done so, we will delete it as soon as practicable, subject to any AML retention obligation.

4. Sources of Personal Data

4.1 Plain-language summary

Some data comes from you directly. Some comes from your family member (the Sender giving us your details), some from the field agent who signed you up, some from KYC providers, and some from banks and telcos.

4.2 Sources

We collect personal data from the following sources:

  • (a) Directly from you, when you use the Service (call the IVR, send an SMS, use the app, hand a Cash-out Code to an Agent, sign a Field App consent screen).
  • (b) From the Sender about the Senior. The Sender identifies the Senior at onboarding and provides the Senior's phone number, name, and language. The Sender's authority to do so relies on Section 3.3 of the Terms and the consent mechanics in Section 13 of this Privacy Policy for a data subject who did not register themselves.
  • (c) From field agents. Field agents collect Senior identity documents, photographs, and voice-sample recordings during assisted registration.
  • (d) From KYC vendors. Sendaya uses KYC providers to verify identity documents; those providers return match verdicts, risk scores, and (where permitted) sanctions and PEP screening hits.
  • (e) From telephony providers. Africa's Talking (or equivalent) supplies inbound call metadata (caller number, duration, carrier). WhatsApp Business Platform supplies inbound message metadata.
  • (f) From Rail Partners. Paystack, Flutterwave, Hubtel, ExpressPay, Daraja, MTN MoMo, Airtel Money, PSB operators supply settlement confirmations, reversal notices, and reconciliation reports.
  • (g) From remittance partners. Where a funding is initiated via Wise, Remitly, Sendwave, MoneyGram, WorldRemit, Grey, etc., that partner supplies the funding reference and the settled amount.

4.3 Consent mechanics for a data subject who did not register themselves

Where a Senior did not personally initiate the registration:

  • (a) The Sender provides the Senior's phone number and language.
  • (b) Sendaya sends a first-contact IVR/SMS/WhatsApp/USSD message to the Senior on the channel the Senior uses most (as reported by the Sender), asking the Senior to (i) confirm they wish to receive money via Sendaya, (ii) hear a plain-language summary of the Service in their language, and (iii) accept the Terms and this Privacy Policy by "press 1 to agree" or equivalent.
  • (c) Alternatively, a field agent may perform assisted registration in person, following the process in Section 5.6 of the Terms.
  • (d) Until the Senior has confirmed by their own action, the Account is in "provisional" status. Sender fundings sit in the Custody Pool but no Cash-out Code can be issued.

5. Purposes and Lawful Bases

5.1 Plain-language summary

The main reasons we hold your data are: (i) to actually deliver the Service you asked for, (ii) to comply with law, (iii) to protect you from fraud and scams, (iv) because you gave us permission (for voice samples and marketing), and (v) sometimes to protect your safety in an emergency.

5.2 Purposes-and-bases table

Where we operate under UK/EU GDPR-style regimes, the lawful bases are: contract performance (Art 6(1)(b)); legal obligation (Art 6(1)(c)); legitimate interests (Art 6(1)(f)); consent (Art 6(1)(a)); vital interests (Art 6(1)(d)); public interest / substantial public interest (Art 6(1)(e), Art 9(2)(g)). Under the Nigeria Data Protection Act 2023 the analogous bases apply; under the Kenya Data Protection Act 2019 and the Ghana Data Protection Act 2012 the analogous bases apply. Consent-based processing is always distinguished so it can be withdrawn without affecting other processing.

Purpose Data categories used Lawful basis (GDPR-style) Balancing/notes
Onboarding and identity verification Identity, contact, ID images, KYC results Contract; legal obligation (AML/KYC) KYC is legally required in every operating country.
Wallet creation, balance holding, ledger accounting Identity, financial and transaction data Contract Core Service.
Custody safeguarding and reconciliation Financial and transaction data, custody records Legal obligation (safeguarding rules); legitimate interest in solvency and reconciliation Reconciliation runs analyse only pseudonymised account IDs at scale.
FX conversion and rate disclosure Financial data, FX and custody records Contract Rate provenance is stored for audit.
Cash-out issuance and redemption Identity, PIN hash, Cash-out record, Agent kiosk data Contract Location is captured only at the moment of Cash-out, not continuously.
Rules engine (velocity, threshold, whitelist, channel flags) Financial data, session state Contract; legitimate interest in fraud prevention Rules are documented in ARCHITECTURE.md and are auditable per User.
Scam Shield freeze All Account data Vital interest (User safety); legitimate interest in fraud prevention Triggerable by Senior or Sender; no additional data collected on trigger beyond timestamp.
Duress event handling Voice PIN hash, Cash-out request state, notifications Vital interest (User safety); legal obligation where a report to authorities is triggered Silent to the coercer; notifies Sender, Ops, and (where designated) safeguarding contact.
Voice authentication and anti-fraud voice-matching Voice samples (biometric-adjacent) Explicit consent collected at enrolment; substantial public interest for financial-fraud prevention where local law recognises it See Section 6; opt-out available with fallback to PIN-only.
Trusted Voice playback Trusted Voice recordings Consent from the recorder; contract for delivery to the recipient Recordings are single-purpose; not repurposed.
Call and IVR session recording Voice; DTMF; session metadata Legitimate interest in dispute resolution and safeguarding; legal obligation where required Disclosed at session start; retention per Section 10.
USSD/SMS/WhatsApp messaging Message content and metadata Contract WhatsApp messages are subject to Meta's own processing terms — see Section 8.
Beneficiary designation and voice authentication Voice sample, Beneficiary details Consent; contract 72-hour cooling-off applies before nomination takes effect.
Inactivity escalation Contact, activity timestamps Legitimate interest in User safety and Beneficiary rights Follows the 90/120/180-day model in Terms Section 12.2.
Medicine Wallet operation Financial data with pharmacy/hospital tag Contract; explicit consent where health-adjacent inference is treated as special category data in the User's country See Section 6.
Bill-pay routing Financial data; Biller contact Contract Biller contact treated as business data, not consumer personal data.
Agent trust score computation Agent throughput, complaint rates, refusal rates Contract; legitimate interest in Agent quality control Automated decision — see Section 7.
FX kill-switch Rate provenance records Legitimate interest in Service reliability No personal data used in the kill-switch decision itself.
AML transaction monitoring and suspicious-activity reporting Financial data, KYC data, network data Legal obligation Reports to FIUs; tipping-off is prohibited per Terms Section 15.7.
Sanctions screening Identity, transaction counterparties Legal obligation Cross-tenant screening under joint-controller basis for platform-level fraud.
Cross-tenant scam detection Device fingerprints, phone hashes, transaction patterns Joint controller: legitimate interest in fraud prevention across tenants Pseudonymisation applied wherever possible.
Support and complaints handling All Account data as relevant Contract; legal obligation to resolve complaints See Terms Section 22.
Compliance with regulator information requests All Account data as required by the request Legal obligation Disclosures logged.
Litigation and dispute resolution Any relevant data Legal obligation; legitimate interest in defending or bringing claims Retention extended for the duration of the dispute.
Direct marketing to Senders (only) Contact Consent (opt-in) Never to Seniors. See Section 16.
Product research and improvement Pseudonymised transaction and interaction data Legitimate interest in improving the Service No profiling for advertising; no cross-context ads.
Payroll / staff administration (Ops) Ops staff identity, access logs Legal obligation; contract Standard employer-employee processing.

5.3 Balancing tests

Where we rely on legitimate interests, we perform a balancing test in accordance with the applicable law. The balancing tests are documented internally and available to the relevant supervisory authority on request. Summary of the key balancing considerations:

  • (a) Necessity — the processing is necessary to achieve the interest.
  • (b) Proportionality — the volume and depth of data used is the minimum necessary.
  • (c) Impact — impact on the data subject is limited by pseudonymisation, access controls, and retention limits.
  • (d) Reasonable expectation — the processing is one a reasonable User would expect given the nature of the Service.

5.4 Withdrawing consent

Where processing is based on consent (voice samples, Trusted Voices, health-adjacent inference under Section 6, marketing under Section 16), the User may withdraw consent at any time via the app, IVR menu, USSD short code, or by written notice to [DPO@EMAIL]. Withdrawal does not affect the lawfulness of processing before withdrawal. Withdrawal of voice-sample consent switches the Senior to PIN-only authentication.

6. Special Category and Sensitive Data

6.1 Plain-language summary

Voice samples and health-adjacent things (Medicine Wallet activity) are treated as extra-sensitive. We ask for your explicit permission and we store them separately with tighter controls.

6.2 Voice / biometric handling

Sendaya records voice samples at onboarding for the purpose of voice-authentication anti-fraud. The processing:

  • (a) is on the basis of the Senior's explicit consent, captured on the channel of enrolment (IVR "press 1 to agree", Field App checkbox with the Senior's own PIN entry, or Senior App tap);
  • (b) is limited to authentication — the samples are not used for public identification, are not sold, and are not shared with any third party except a KYC vendor solely to perform an authentication check;
  • (c) is subject to a retention limit tied to the life of the Account plus the AML retention period (see Section 10);
  • (d) may be withdrawn at any time, whereupon the Senior falls back to PIN-only authentication;
  • (e) in jurisdictions with a biometric-specific opt-in requirement, the opt-in step is a distinct on-screen or on-call action, not bundled with general Terms acceptance.

Trusted Voice recordings are separate from voice samples. Trusted Voices are user-generated content intended for playback to a specific recipient; they are stored, delivered, and deleted according to the recorder's and recipient's instructions.

6.3 Health-adjacent inference from Medicine Wallet use

Because Medicine Wallet transactions may allow inference about the Senior's health (recurring pharmacy visits, hospital category spend), Sendaya treats Medicine Wallet metadata (frequency, category tags, Biller identity) as sensitive personal data for the purpose of this Privacy Policy, even where the applicable law does not automatically categorise it as such.

  • (a) Medicine Wallet activity is not shown to Circle members other than the primary Sender and Guardians the Senior has explicitly authorised to view it. In particular, "Circle" broadcast notifications never include a Biller name where the Biller is tagged pharmacy or hospital.
  • (b) Where the applicable law requires explicit consent to process health data, that consent is captured at Medicine Wallet enablement.
  • (c) Health-adjacent inference is not used for marketing, is not shared with third parties for their own purposes, and is not fed to any automated decision that materially affects the User except the Medicine-Wallet spend-category enforcement itself.

6.4 Storage and opt-outs for special category data

Special category data is stored with additional access controls (dedicated role permissions, encryption at rest with separate key material, and dedicated audit trails). Opt-outs:

  • (a) voice sample: opt out at Settings → Security → Voice authentication, or by IVR menu code, or by writing to [DPO@EMAIL];
  • (b) Medicine Wallet: opt out by disabling the Medicine Wallet in the Sender app (any remaining balance returns to the main wallet on disable);
  • (c) Trusted Voice recordings: delete individual recordings from the Trusted Voices list, or bulk-delete via Settings.

7. Automated Decision-Making

7.1 Plain-language summary

Some rules are applied automatically: whether a Cash-out is over the approval threshold, whether it hits your velocity limit, whether it's on your whitelist, and how a duress PIN behaves. Agents also get a trust score. If any of these affect you, you can ask a person to review the decision.

7.2 Automated systems in operation

The following automated systems make decisions that may materially affect a User:

  • (a) Rules engine. Blocks a Cash-out or Biller payment where a Sender-defined rule (velocity limit, threshold, channel disable, whitelist) is triggered. Rules are Sender-configured and country-configured; the engine's decisions are logged.
  • (b) Duress-PIN behaviour. A Duress PIN triggers a fixed decoy-and-notify behaviour; not truly a decision, but automated.
  • (c) Agent trust score. Computed nightly from throughput, complaint rate, refusal rate, and training compliance. Feeds into Agent volume caps.
  • (d) FX kill-switch. Trips automatically on provider disagreement or excessive deviation. Freezes conversion quotes for the affected pair.
  • (e) AML transaction monitoring. Automated rule-based flags; every flag is human-reviewed before any Account action.
  • (f) Cross-tenant scam detection. Pseudonymised device and phone signals cross-referenced across tenants to identify scam clusters.

7.3 Human review rights

For any automated decision that materially affects a User, the User has the right to:

  • (a) obtain human review of the decision, by contacting [SUPPORT@EMAIL] or the in-app "Help" flow;
  • (b) request an explanation of the basis for the decision, at a level of detail that does not compromise the anti-fraud purpose;
  • (c) contest the decision and provide additional context;
  • (d) obtain the outcome of the human review within 15 business days.

7.4 Rules engine transparency

The rules engine's rule catalogue is public (documented in ARCHITECTURE.md) so a User can understand which rules can block a transaction. The specific configuration for a given Account (thresholds, whitelist entries, channel flags) is visible to the Sender and, on request, to the Senior.

7.5 Agent trust score

Agents are notified when their trust score changes materially. Agents can request the components of the score and can dispute individual complaint or refusal records that fed it. See the Agent Agreement.

8. Sharing of Personal Data

8.1 Plain-language summary

We share personal data only with the people who need it to run the Service and only for the purpose stated. Circle members see what the Senior lets them see. Agents see only the amount to pay out. Tenants see their own tenant data. Regulators see what the law says they see.

8.2 Recipients

We share personal data with the following categories of recipients:

  • (a) Circle members — the Sender always sees the Senior's identity, wallet balance, transaction history (subject to Section 6 for health-adjacent), Cash-out issuance and redemption events, Whitelist entries, and Scam Shield status. Guardians see the subset the Senior has authorised per Section 4.4 of the Terms. Other Circle co-funders see contribution totals and pending Requests they have been asked to approve.
  • (b) Agents — see only (i) the Cash-out Code they are redeeming, (ii) the Local-Currency amount to pay out, (iii) the Senior's phone number for verification, (iv) the Senior's PIN pad input (the Agent does not see the digits, only the result), and (v) where relevant, the witness threshold prompt. Agents do not see the wallet balance.
  • (c) Tenants — see the User data associated with the Tenant's channel, in the Tenant's role as controller per Section 1.3.
  • (d) Custody Banks — see the aggregate Custody Pool balances and, where required by AML law, the individual transaction and identity data underlying them.
  • (e) Rail Partners — see the specific transaction they are settling (payer, payee, amount, reference), not the full Account history.
  • (f) Telephony providers — see call metadata and, in the case of USSD/SMS/WhatsApp, message content, insofar as it passes through their systems as a carrier.
  • (g) Meta Platforms Ireland Limited (WhatsApp) — as the operator of the WhatsApp Business Platform, receives the messages Sendaya sends and receives via that channel, subject to Meta's own processor arrangements with Sendaya and to the applicable Business Terms.
  • (h) KYC vendors — receive identity documents and metadata for verification; return verification verdicts and risk scores.
  • (i) FX data providers — receive currency-pair identifiers only, not User identity.
  • (j) Cloud hosts — process personal data as sub-processors under standard cloud provider terms.
  • (k) Regulators — receive data in response to lawful information requests and periodic reports as required.
  • (l) Law enforcement — receive data in response to a court order, subpoena, or other lawful legal process, subject to Sendaya's review of the legal validity of the request. Where the law prohibits us from telling the User about the request, we do not; otherwise, we notify.
  • (m) Professional advisers — receive personal data as necessary to advise Sendaya (legal, tax, audit), under a duty of confidentiality.
  • (n) Successors in interest — in the event of a merger, acquisition, or asset transfer, personal data may transfer subject to notice and continued application of this Privacy Policy at least at the level of protection stated here.

8.3 We do not sell personal data

Sendaya does not sell personal data. Sendaya does not share personal data for behavioural advertising. Sendaya does not run ads.

For US residents, "do not sell/share" statements: Sendaya does not "sell" or "share" personal information as those terms are defined under the California Consumer Privacy Act as amended by the California Privacy Rights Act. See Annex D for the full CCPA/CPRA disclosures.

8.4 Sub-processors

Sendaya's current sub-processors are listed at [SENDAYA.COM/SUB-PROCESSORS] and are also delivered on request. Changes are announced with 30 days' notice on the same page, with a right for Tenants to object under the Tenant DPA.

8.5 Circle visibility controls

The Senior can narrow Circle visibility at any time via the Senior app, IVR menu, or by request. Options include:

  • (a) hide transaction detail from all Guardians;
  • (b) hide the Beneficiary designation from all Guardians;
  • (c) hide Medicine Wallet activity from all Guardians and from the Sender (where the Senior chooses);
  • (d) exit Circle: the Senior may fully exit the Circle relationship, terminating the Sender's ability to see any Account data (the Sender's own contribution history is retained on the Sender side; the Senior's ability to spend continues as usual).

8.6 Joint-controller platform-level data

Under the joint-controller arrangement described in Section 1.3, Sendaya and Tenants jointly process a limited set of platform-level personal data:

  • (a) hashed device fingerprints for scam detection;
  • (b) hashed phone numbers for cross-tenant fraud checks;
  • (c) sanctions and PEP screening hits, retained as evidence of screening.

The scope, purposes, and division of responsibilities between Sendaya and each Tenant are set out in the Tenant DPA. The essence of that arrangement is available to data subjects in-app under Settings → About → "Joint controller arrangement".

9. International Transfers

9.1 Plain-language summary

Data may leave your country. When it does, we make sure the receiving country protects it to a legal standard equivalent to yours, using the tools the law provides (SCCs, IDTA, adequacy decisions, or the local equivalents).

9.2 Where data goes

Personal data is processed in:

  • (a) the country of the User's residence;
  • (b) the country of Sendaya's operating entity for that region;
  • (c) the country of the Custody Bank for the User's currency (typically the US for USD, the UK for GBP, an EU member state for EUR);
  • (d) the region of Sendaya's cloud host (currently [CLOUD REGION]);
  • (e) any country where a sub-processor is based, as listed in the sub-processor page.

9.3 Safeguards

Where a transfer is subject to a data-protection law requiring safeguards for outbound transfers, Sendaya uses:

  • (a) EU/EEA outbound: the European Commission's Standard Contractual Clauses (SCCs), supplemented as needed;
  • (b) UK outbound: the ICO's International Data Transfer Agreement (IDTA) or the UK Addendum to the SCCs;
  • (c) Nigeria outbound: the NDPA's cross-border transfer conditions (including adequacy where declared, contract-based safeguards, or explicit consent as available);
  • (d) Kenya outbound: the DPA 2019's transfer conditions (adequacy or safeguards under Section 48);
  • (e) Ghana outbound: the Data Protection Act 2012 transfer conditions;
  • (f) South Africa (if operating): POPIA's Section 72 conditions;
  • (g) US inbound: the Data Privacy Framework where applicable, or equivalent contractual safeguards.

Copies of the relevant safeguards are available to data subjects on request to [DPO@EMAIL].

9.4 Adequacy

Where the receiving country is subject to an adequacy decision (e.g., EEA to UK, UK to EEA, EEA to Japan/Switzerland/etc.), Sendaya relies on adequacy. Where adequacy is withdrawn, Sendaya reverts to SCCs/IDTA within a reasonable transition period.

10. Retention Schedule

10.1 Plain-language summary

We keep data only as long as we need it or as long as the law says. The main legal driver is AML — that keeps identity and transaction records for years after the account closes.

10.2 Retention table

Data category Retention period Legal basis for period
Identity documents (Sender, Senior, Agent) Life of Account + 7 years AML/CTF record-keeping (varies 5–10 years; 7 years chosen as the conservative baseline).
Address / contact Life of Account + 7 years AML; ability to make contact for post-closure correspondence.
Transaction records (postings, journal entries) Life of Account + 10 years AML + tax + longer of local dispute-limitation periods; the ledger is append-only.
FX conversions and rate provenance Life of Account + 10 years Ledger integrity; regulator audit.
Cashout tokens (redeemed / expired) Life of Account + 7 years AML + dispute resolution.
Voice samples used for authentication Life of Account + 3 years, or on opt-out Explicit consent basis; retention limited to authentication purpose.
Trusted Voice recordings Until deleted by the recorder or the Senior, or 2 years of inactivity, whichever is sooner Consent basis; user-generated content.
IVR call recordings 12 months (routine), 6 years for recordings tagged to a complaint or safeguarding event Dispute resolution; safeguarding evidence.
USSD / SMS / WhatsApp message content and metadata 12 months (routine), longer where tied to a specific investigation Dispute resolution; anti-fraud.
Device data (IP, device fingerprint) 12 months routine Anti-fraud and cross-tenant scam detection.
Agent kiosk location (per Cash-out) Life of the transaction record + 7 years AML.
Scam Shield / Duress event records Life of Account + 7 years Safeguarding evidence; AML.
Inactivity escalation records Life of Account + 7 years Safeguarding.
KYC vendor verdicts and screening results Life of Account + 7 years AML.
PIN hashes (Argon2id) Until PIN change; previous hashes overwritten Security; no need to retain post-change.
Support tickets and chat transcripts 2 years post-resolution (or longer if tied to a complaint) Dispute resolution.
Audit logs of Ops staff actions 7 years Regulator audit; security.
Marketing consents (Sender) Until withdrawn Consent basis.
Cookies / analytics identifiers (app / web) See Section 14.
Health-adjacent Medicine Wallet inference Life of Account + 3 years Sensitive-data minimisation; 3-year floor for dispute resolution.
Beneficiary designation records Life of Account + 10 years Succession and estate resolution.
Dormant Account balance and identifier Per local dormancy law Local statutory obligation.

Where a longer retention is required by law or by an active legal or regulatory matter (e.g., an ongoing suspicious-activity investigation), retention is extended for the duration of that requirement.

10.3 Deletion on retention expiry

At the end of the retention period, personal data is deleted or fully anonymised. Anonymised data may be retained for statistical and product-improvement purposes indefinitely, provided that re-identification is not reasonably possible.

11. Security

11.1 Plain-language summary

We encrypt data at rest and in transit, we minimise what agents can see, we log every access, and we tell you promptly when something goes wrong.

11.2 Security measures

  • (a) Encryption in transit by TLS 1.2+ for all API endpoints and for all channel adapters. Certificate pinning is applied on mobile clients where technically feasible.
  • (b) Encryption at rest for databases, backups, object storage of ID images and voice recordings, and secrets stores. Key material is separated per environment; production keys are rotated on a defined schedule.
  • (c) Append-only immutable ledger — journal entries and postings cannot be updated or deleted after insertion (enforced by database triggers).
  • (d) Role-based access control with least privilege; Ops staff access is scoped by role and audit-logged per action.
  • (e) Agent data minimisation — Agent apps only receive the fields needed for a specific Cash-out redemption; wallet balances are never sent to Agent apps.
  • (f) PIN storage — PINs are stored only as Argon2id hashes with per-record salts; PIN comparison is a constant-time operation.
  • (g) Session security — signed short-lived JWTs for Sender/Agent/Ops authentication; refresh flows include device binding.
  • (h) Audit logging — every mutating action is recorded in the audit_log table with actor, action, entity, IP, channel, and metadata.
  • (i) Rate limiting and abuse detection on all public API endpoints and channel webhooks.
  • (j) Reconciliation between the ledger and each Rail Partner's reported float, run daily, with drift resolved through the suspense account.
  • (k) Vulnerability management — regular dependency scanning, penetration testing, and coordinated disclosure via a security.txt endpoint.
  • (l) Incident response — a written incident response plan, tested on a rolling basis; defined severity levels and communication paths.

11.3 Incident response and breach notification

Sendaya notifies affected data subjects and applicable supervisory authorities in the event of a personal data breach in accordance with the applicable law:

  • (a) UK / EU: within 72 hours to the supervisory authority; without undue delay to affected data subjects where the breach is likely to result in a high risk;
  • (b) Nigeria: within 72 hours to the NDPC and to affected data subjects as required by the NDPA and its guidelines;
  • (c) Kenya: to the ODPC within 72 hours where a real risk of harm arises, per Section 43 of the DPA 2019;
  • (d) Ghana: to the DPC as soon as reasonably practicable;
  • (e) US (state laws): per the state-specific breach-notification law of the User's state of residence;
  • (f) Seychelles: per the Data Protection Act 2003.

Notifications are made through the Sender/Agent app, email, and (where the incident affects Seniors) SMS/IVR in the Senior's chosen language.

12. Rights of Data Subjects

12.1 Plain-language summary

You have rights to see your data, correct it, delete it (subject to the law), object to some processing, port it to another service, and complain to a regulator.

12.2 Rights (varies by jurisdiction)

The following rights apply to some extent in every operating country. Where a right does not apply in a specific jurisdiction, the Country Annex says so.

  • (a) Access to the personal data we hold about you and a copy in a common format.
  • (b) Correction / rectification of inaccurate or incomplete data.
  • (c) Deletion ("right to be forgotten") subject to legal-retention exceptions (Section 12.4).
  • (d) Restriction of processing while a dispute is under investigation.
  • (e) Objection to processing based on legitimate interests, including profiling.
  • (f) Portability of data provided to Sendaya, in a structured, machine-readable format.
  • (g) Not to be subject to a solely automated decision with legal or significant effects, subject to Section 7.
  • (h) Withdraw consent at any time (Section 5.4).
  • (i) Complain to a supervisory authority in the country listed in the Country Annex.
  • (j) Under CCPA/CPRA (California residents): right to know, right to delete, right to correct, right to opt out of "sale/share", right to limit use of sensitive personal information, right to non-discrimination.
  • (k) Under UK GDPR / EU GDPR: as above; plus the right to lodge a complaint with the ICO / national supervisory authority.
  • (l) Under NDPA / Kenya DPA / Ghana DPA / POPIA: as above, subject to national procedural rules.

12.3 How to exercise rights — Seniors

A Senior may exercise their rights:

  • (a) By voice — an IVR menu code (*7# inside the IVR session) that routes to a live Ops interaction on a scheduled call-back;
  • (b) By USSD — a short-code sequence that flags an Ops ticket;
  • (c) Through a Guardian — a trusted Circle member the Senior has authorised may submit a rights request on the Senior's behalf, but Ops will still confirm the request with the Senior directly on the Senior's registered channel;
  • (d) By SMS or WhatsApp — sending the keyword MYDATA (or its localised equivalent);
  • (e) In writing — post to the registered office marked "Attn: DPO".

12.4 Identity verification

We verify the identity of the rights-request applicant before releasing data. Verification methods:

  • (a) for Senders / Agents / Ops: standard authentication via the app;
  • (b) for Seniors: voice-authentication (where opted in) plus PIN verification, or callback-verified voice conversation with Ops in the Senior's language, or in-person verification with a Sendaya field agent.

12.5 Legal retention exceptions

We may refuse or partially decline a deletion request where retention is required by AML, tax, dispute-resolution, or public-interest obligations. In such a case we tell you which category of data is retained and why, and we minimise the retained set.

12.6 Timelines and fees

Rights requests are responded to within one month (extendable by two further months for complex requests, with notice). No fee is charged for the first request in a 12-month period. Fees or refusals for excessive or manifestly unfounded requests are limited to the extent permitted by law.

13. Seniors and Vulnerable Persons

13.1 Plain-language summary

Seniors are the reason Sendaya exists. We take extra care with their data. Consent is captured in a way we can prove. The Senior can control how much the Circle sees. If they want to be forgotten, we do what the law lets us.

13.2 Consent capture during assisted registration

Where a Senior is registered by a Sender and confirms remotely, the acceptance is captured on the confirmation channel with the timestamp, the channel identifier, and the specific document version accepted, and stored in the legal_acceptances register.

Where a Senior is registered in person by a field agent using the Field App, the acceptance flow includes:

  • (a) selection of the Senior's language;
  • (b) automatic text-to-speech playback of the plain-language summary of the Terms and this Privacy Policy in that language via expo-speech;
  • (c) a checkbox confirmation by the field agent that the summary was read aloud in full;
  • (d) the Senior's own PIN entry on the Field App as evidence of acceptance;
  • (e) a short voice recording ("I agree to Sendaya's terms") saved as evidence and linked to the acceptance record with channel field.

13.3 Voice-delivered privacy notice

At the Senior's first IVR call and at any material update to this Privacy Policy, the Senior is offered a voice-delivered summary of the key privacy points in their chosen language. The summary is short (approximately 60 seconds) and specifically calls out: what personal data we hold, why, who sees it, and how to opt out of voice authentication. The Senior can then "press 1 to agree" or defer to a fuller text/audio delivery via a Circle member.

13.4 Guardian access boundaries

Guardians see only what the Senior has authorised (Section 8.5). Where a Sender promotes a Circle member to Guardian, the promotion is announced to the Senior on their next IVR/SMS session; the Senior can decline the promotion and remove the Guardian.

13.5 Senior's right to limit Circle visibility

Section 8.5 sets out the visibility controls. These are exercisable by the Senior directly by voice PIN.

13.6 Right to be forgotten vs AML retention conflicts

Where a Senior requests deletion but AML retention applies:

  • (a) we delete data outside the AML retention set (Trusted Voices, non-transactional preferences, marketing consents where held, voice samples on opt-out, cached device data, etc.);
  • (b) we retain the minimum AML set (identity, transactional records, screening results) for the statutory period;
  • (c) we describe to the Senior in plain language what has been kept, why, and when it will be deleted at the end of the retention period.

13.7 Vulnerable-consumer principle

Where a Senior is identified as vulnerable, the following defaults apply and can be widened only on the Senior's positive request:

  • (a) transaction detail is not shared with any Guardian, only aggregate balance;
  • (b) Medicine Wallet activity is not shown to any Guardian;
  • (c) Trusted Voice recordings from Circle members are throttled to prevent bombardment;
  • (d) any change to the Beneficiary or PIN requires a 72-hour cooling-off with a callback confirmation.

14. Cookies and App Tracking

14.1 Plain-language summary

We use only the essential cookies and identifiers we need to run the apps. We do not use tracking cookies. We do not run ads.

14.2 Cookies (web surfaces)

Where Sendaya operates any web surface (the Ops dashboard, the marketing site, the legal document pages), the following cookies are used:

  • (a) strictly necessary cookies for session and CSRF handling — no consent required;
  • (b) functional cookies to remember language preference — consent captured on first visit where required;
  • (c) analytics cookies only where opted in (Section 14.4).

Sendaya does not use advertising cookies.

14.3 App identifiers

The apps use only the identifiers necessary for the Service and for anti-fraud (device fingerprint hash, install token). No advertising identifiers are collected. On iOS, no AppTrackingTransparency prompt is shown because Sendaya does not track across other apps and websites.

14.4 Analytics

Sendaya uses first-party, privacy-preserving analytics tooling to understand feature usage and diagnose problems. Analytics does not receive personally identifying information. Users can opt out via Settings → Privacy → Analytics.

15. Children

15.1 Not permitted

The Service is not for persons under 18. Sendaya does not knowingly collect personal data from persons under 18.

15.2 If we discover a minor account

Where Sendaya discovers a minor has registered (Sender-side), the account is closed and personal data deleted subject to any AML retention that has attached. The registering party is notified. No further processing occurs beyond what is required to comply with the law.

16. Marketing and Communications Preferences

16.1 Plain-language summary

We do not market to Seniors. We only send Senders marketing after they've opted in. Every marketing message includes a one-tap unsubscribe.

16.2 To Senders

We may send Senders marketing communications (product news, referral programs) only where the Sender has expressly opted in. Opt-in is per channel (email, in-app notification, SMS). Opt-out is one-tap in-app and by unsubscribe link in each email.

16.3 To Seniors — never

We do not send marketing communications to Seniors. Communications to Seniors are limited to Service messages (transaction confirmations, security alerts, complaint follow-ups, safeguarding contact) and to changes to Terms or this Privacy Policy per Section 17.

16.4 To Agents

We may send Agents operational and product-update messages under the Agent Agreement; marketing separately opted-in.

17. Changes to this Privacy Policy

17.1 Right to change

Sendaya may update this Privacy Policy to reflect changes in the Service, in the law, or in operational practice.

17.2 Notice methods

Notice of a material change to this Privacy Policy is given by:

  • (a) in-app banner and mandatory re-acceptance on next authenticated session (Sender / Agent);
  • (b) email to the Sender's registered email address;
  • (c) SMS to the Senior in their chosen language;
  • (d) IVR notice on the Senior's next inbound call, in their chosen language, offering the option to hear the summary and "press 1 to accept";
  • (e) WhatsApp broadcast for Users who use that channel and have opted in.

17.3 Notice period

Material changes take effect no earlier than 30 days after notice, save for changes required immediately by law or regulator direction.

18. Complaints

18.1 To Sendaya

Data-protection complaints should be raised to [DPO@EMAIL] or by post to the registered office marked "Attn: DPO". Acknowledgement within 3 business days; substantive response within 30 days.

18.2 To a supervisory authority

A User may lodge a complaint directly with a supervisory authority. The applicable authority per country is named in the Country Annex.

Country Annex

Annex A — Nigeria

  • (A.1) Supervisory authority. Nigeria Data Protection Commission (NDPC), established under the Nigeria Data Protection Act 2023 (NDPA). The National Information Technology Development Agency (NITDA) retains a residual role for standards and guidance.
  • (A.2) Data controller for Nigeria Users. [SENDAYA NIGERIA LTD], registered as a data controller with the NDPC (Data Controller Number [DCN]).
  • (A.3) Cross-border transfers. Governed by NDPA Sections 41–43 and NDPC guidance. Sendaya relies on (i) adequacy where declared, (ii) explicit consent where obtained, and (iii) NDPA-compliant contractual safeguards. A list of transfer destinations is available on request.
  • (A.4) Complaint contact. NDPC — [NDPC ADDRESS AND EMAIL].
  • (A.5) Language. Rights requests and privacy notices are available in English, pcm, yo, ig, and ha.
  • (A.6) Breach notification. Within 72 hours to the NDPC and to affected data subjects where a risk of harm arises.

Annex B — Kenya

  • (B.1) Supervisory authority. Office of the Data Protection Commissioner (ODPC), Kenya, established under the Data Protection Act 2019.
  • (B.2) Data controller for Kenya Users. [SENDAYA KENYA LTD], registered as a data controller (Registration No. [REG NO]).
  • (B.3) Cross-border transfers. Governed by DPA 2019 Section 48. Sendaya relies on adequacy where declared and on the DPA-compliant transfer safeguards.
  • (B.4) Complaint contact. ODPC — [ODPC ADDRESS AND EMAIL].
  • (B.5) Language. Available in English and Swahili.
  • (B.6) Breach notification. To the ODPC within 72 hours where a real risk of harm arises.

Annex C — Ghana

  • (C.1) Supervisory authority. Data Protection Commission (DPC), Ghana, established under the Data Protection Act 2012 (Act 843).
  • (C.2) Data controller for Ghana Users. [SENDAYA GHANA LTD], registered with the DPC (Registration No. [REG NO]).
  • (C.3) Cross-border transfers. Governed by Act 843 Sections 47–48.
  • (C.4) Complaint contact. DPC — [DPC ADDRESS AND EMAIL].
  • (C.5) Language. Available in English and Twi.
  • (C.6) Breach notification. As soon as reasonably practicable to the DPC.

Annex D — United States

  • (D.1) State privacy laws. Sendaya is subject to the California Consumer Privacy Act as amended by the California Privacy Rights Act ("CCPA/CPRA") for California residents, and to comparable statutes in Colorado (CPA), Connecticut (CTDPA), Utah (UCPA), Virginia (VCDPA), and other US states with comprehensive privacy laws in effect. Financial data may additionally be subject to the Gramm-Leach-Bliley Act ("GLBA") privacy rules, in which case the GLBA notice is delivered separately.
  • (D.2) Categories of personal information collected (CCPA schedule). Identifiers; personal information categories under Cal. Civ. Code §1798.80(e); protected classification characteristics (where inferable — treated as sensitive); commercial information; biometric information (voice samples); internet or other electronic network activity information; geolocation data (Cash-out kiosk events); audio, electronic, visual (call recordings); inferences (limited to Medicine Wallet health-adjacent tags).
  • (D.3) Do not sell / do not share. Sendaya does not "sell" or "share" personal information as defined under CCPA/CPRA. The "Do Not Sell or Share My Personal Information" and "Limit the Use of My Sensitive Personal Information" links are provided in-app and at [SENDAYA.COM/PRIVACY-CHOICES].
  • (D.4) Sensitive personal information. Sendaya limits use of "sensitive personal information" (biometrics, precise geolocation of Cash-out events, PIN hashes) to what is necessary to perform the Service.
  • (D.5) Consumer rights. Right to know, delete, correct, opt out of sale/share, limit use of sensitive personal information, non-discrimination.
  • (D.6) Authorised agent requests. Accepted with a valid signed authorisation from the consumer.
  • (D.7) Breach notification. Per the state-specific data-breach law of the consumer's state of residence.
  • (D.8) Complaint contact. California Privacy Protection Agency (CPPA), California Attorney General, or the state attorney general in other states.

Annex E — United Kingdom

  • (E.1) Supervisory authority. Information Commissioner's Office (ICO), regulating UK GDPR and the Data Protection Act 2018.
  • (E.2) UK representative. [UK REP NAME AND ADDRESS].
  • (E.3) Cross-border transfers. IDTA or UK Addendum to the SCCs; adequacy where declared.
  • (E.4) Complaint contact. ICO — https://ico.org.uk — Wycliffe House, Water Lane, Wilmslow, Cheshire SK9 5AF.
  • (E.5) Language. English.

Annex F — European Union

  • (F.1) Supervisory authority. The lead supervisory authority for Sendaya's EU establishment (identified at [SENDAYA.COM/EU-DPA]), plus the national supervisory authority of the User's country of residence.
  • (F.2) EU representative (Art. 27). [EU REP NAME AND ADDRESS].
  • (F.3) Cross-border transfers. European Commission SCCs (2021), supplemented by transfer risk assessments.
  • (F.4) Complaint contact. The national supervisory authority in the User's country of residence.
  • (F.5) Language. English and the primary official language of the User's country of residence.

Annex G — South Africa (POPIA)

  • (G.1) Supervisory authority. Information Regulator (South Africa).
  • (G.2) Cross-border transfers. POPIA Section 72 safeguards.
  • (G.3) Complaint contact. Information Regulator — [POPIA CONTACT].
  • (G.4) Language. English.

Annex H — Seychelles

  • (H.1) Applicable law. Seychelles Data Protection Act 2003. Where the User is also a GDPR/UK GDPR data subject, those laws apply cumulatively.
  • (H.2) Cross-border transfers. Contract-based safeguards; explicit consent where required.
  • (H.3) Complaint contact. [SEYCHELLES DP CONTACT].
  • (H.4) Language. English.

Annex I — Rest of World

  • (I.1) Applicable law. The data-protection law of the User's country of residence, to the extent it applies.
  • (I.2) Cross-border transfers. Sendaya applies GDPR-level safeguards as a baseline in the absence of a more prescriptive local regime.
  • (I.3) Complaint contact. The national data-protection authority in the User's country of residence.
  • (I.4) Language. English by default; local-language translation on reasonable request.

Appendix 1 — Detailed data flow illustrations

The following flow descriptions illustrate the personal-data handling at each principal Service action. They are illustrative and not exhaustive; consult the operational architecture documentation for the canonical description.

Flow A — First IVR call by a Senior (already registered)

  • (A.1) The Senior dials the Sendaya local number. The carrier hands the call to the Africa's Talking Voice platform, which invokes the Sendaya IVR webhook with sessionId and callerNumber.
  • (A.2) Sendaya matches the callerNumber against the users.phone field to identify the Senior. If matched, a channel session row is opened.
  • (A.3) The Senior selects a language via DTMF. The selection is stored on the session row; the session recording continues.
  • (A.4) The Senior enters their PIN. Sendaya compares the entry to the stored Argon2id hash. Result: ok, duress, or fail.
  • (A.5) On ok, the Senior navigates the main menu. Each menu action produces a ChannelCommand handled by the ledger and returns a response formatted for voice.
  • (A.6) At session end, the recording is finalised and stored under the 12-month retention window; the DTMF log is stored under the same window.

Personal data touched: identity (matched via phone), PIN hash (compared), voice sample (compared where opted in), session recording, DTMF log, transaction data (if the Senior asked for balance or issued a Cash-out).

Flow B — Sender-initiated Cash-out issuance

  • (B.1) The Sender opens the Sender app and taps "Issue Cash-out" for a specified Senior and Local-Currency amount.
  • (B.2) The Sendaya API validates the amount against the rules engine (thresholds, velocity, whitelist, channel flags).
  • (B.3) The FX composite is asked for the Applied Rate for the required currency pair. Rate provenance is captured.
  • (B.4) A journal entry is posted: debit the Senior's Base Currency wallet, credit custody_pool_base net of Spread, credit fx_revenue_base, debit custody_pool_local, credit the Cash-out escrow account.
  • (B.5) A Cash-out Code is generated and stored in cashout_tokens with expiry.
  • (B.6) The Sender app displays the Code and sends it to the Senior via the channel the Sender selected (SMS/WhatsApp/inside-Circle notification).

Personal data touched: Sender identity (session token), Senior identifier, wallet balance (Sender view), Cash-out record (both), rate provenance (linked to the transaction).

Flow C — Agent redemption

  • (C.1) The Agent opens the Agent app and enters the Code. The API returns only: the Local-Currency amount to pay out, the Senior's phone number for verification, and a PIN pad screen. The wallet balance is not returned.
  • (C.2) The Senior enters their PIN on the Agent device. The Agent app posts the PIN entry to the API; the API returns pin_ok or pin_fail without disclosing the PIN or its hash.
  • (C.3) On pin_ok, the Agent pays out the amount and confirms redemption. The API posts a journal entry moving funds from the Cash-out escrow to the Agent's float, subject to the Agent's commission split.
  • (C.4) The Agent's kiosk location (from the device) is stored on the redemption record.

Personal data touched: Agent identity (session token), Senior identity (phone, PIN verification), Agent kiosk location, Cash-out record.

Appendix 2 — Notes on specific special situations

  • (a) A Senior who calls from a stranger's phone. Because Sendaya matches by callerNumber, a call from a non-registered phone will fall through to a "phone not recognised" flow. The Senior may then use the "call back my number" option (Sendaya calls the Senior's registered phone) or the field-agent-assisted flow.
  • (b) A Senior who has lost their phone. The Senior asks a Circle member to trigger a Scam Shield freeze (Terms Section 11.5). The Senior then attends a Sendaya field agent for identity re-verification (voice + KYC document) and phone-number reset. During the reset, all outbound Cash-out and Biller actions are blocked.
  • (c) A Senior whose phone number is reassigned by a carrier. Sendaya's inactivity escalation catches this within 90 days for typical carrier reassignment timelines. A Sendaya field-agent welfare check confirms the Senior is still reachable. Where the number has been reassigned to a third party, the third party never gains access to the Senior's Account because authentication requires the PIN and (where opted in) voice sample.
  • (d) A Sender who separates from the Senior. The Senior may exit the Circle (Section 8.5) and continue with a new Sender or without a Sender for the remaining balance.
  • (e) A Senior whose Sender is subject to a chargeback. The chargeback is handled at the Sender-Sendaya interface. The Senior's own use of already-vested funds is not affected; only unvested credits may be reversed. Where a reversal is unavoidable, Sendaya notifies the Senior in their language and offers a payment plan for the Sender to restore the balance.
  • (f) A duress event without a Duress PIN configured. If a Senior did not configure a Duress PIN, the primary PIN pathway completes. To reduce this risk, Sendaya proactively prompts every Senior to configure a Duress PIN at first PIN change and periodically thereafter.

End of Privacy Policy.

Version pointer: the current effective version of this Privacy Policy is served by the Sendaya API at /legal/privacy/current and is retrievable by version identifier at /legal/privacy/{version}. Each version is content-hashed on publication and recorded in the legal_documents table.