Privacy Policy

This Privacy Policy explains how Y.O.D.O. Ltd ("Y.O.D.O.", "we", "us", "our") collects and uses personal data when you use our website and our Service (the Y.O.D.O. web application and related services). It should be read alongside our Terms and Conditions and our Cookies Policy.

1. Key points (plain English)

• 1.1 We are the controller for personal data we process to run Y.O.D.O.
• 1.2 We collect only what we need to provide the Service, keep it secure, prevent fraud and misuse, and handle billing, disputes and support.
• 1.3 Check-in and escalation timings are measured from T0 (the Scheduled Check-in due time) as set out in our Terms. We do not contact Delegates before the Response Window ends (T0+8 hours).
• 1.4 Delegates never have access to Message content. Messages remain sealed unless and until a Passing is reported and verified through the Service.
• 1.5 Identity verification through Persona is engaged at two specific points in the Service, not at Account Holder sign-up: (a) when a Delegate reports an Account Holder's Passing, the Delegate completes Persona identity verification before the report is processed; and (b) when a Recipient accesses a released Message for which the Account Holder configured enhanced verification, the Recipient completes Persona identity verification before the Message is decrypted. We receive verification outcomes and limited metadata. We do not receive your biometric template.
• 1.6 Account Holder sign-up has three steps in this order. First, you create the account credential by one of three routes you choose, and your email address is confirmed: with the email-and-password route, you enter an email address and we send a verification link to that address; with Google single sign-on, Google attests your email and sends us your email address, name, Google profile identifier and profile picture where available on your authorisation; with LinkedIn single sign-on, LinkedIn does the equivalent. Second, you provide a mobile phone number and confirm ownership of that number via a one-time password sent by SMS through our SMS provider Twilio (Twilio Ireland Limited). Mobile-phone confirmation is required; sign-up cannot continue without it. Third, you set up Scheduled Check-ins, nominate Delegates, optionally nominate Special Delegates, and create your sealed Messages. We do not require Persona identity verification at sign-up.
• 1.7 "Deleted from our active systems" means removed from our live databases and no longer accessible in the Service. Limited retention in backups and logs may still apply for defined periods as described below.
• 1.8 If we delete an account under our deletion rules (for example T0-based deletion or Inactive deletion), we take reasonable steps to stop future subscription renewals linked to that account (see "Retention" below and the Terms).
• 1.9 We use Cookiebot to manage cookie consent. Non-essential cookies are set only if you consent.

2. Who this Policy applies to

This Policy applies if you are:

• (a) a website visitor
• (b) an Account Holder (someone who sets Scheduled Check-ins and may create Messages)
• (c) a Delegate (someone invited to help if a Scheduled Check-in is not confirmed or to start a Status Check)
• (d) a Recipient (someone invited to receive a Message after Passing verification), including Recipients who access a Message as a guest using a secure link
• (e) someone who contacts us (for example for support)

3. The roles and personal data in Y.O.D.O.

3.1 Account Holders

Account Holders create accounts, choose Scheduled Check-in settings (including timezone), choose escalation settings, invite Delegates, name Recipients and create Messages.

3.2 Delegates

Delegates are invited by Account Holders. Delegates can be contacted only when action may be needed (for example after Escalation triggers or after another Delegate raises a concern). Delegates cannot access Message content.

3.3 Recipients

Recipients are selected by Account Holders to receive Messages after Passing verification. Recipients can access delivered Messages using a secure link and must complete identity verification through Persona before accessing Message content. Recipients do not need to create a Y.O.D.O. account.

3.4 Data about deceased persons

UK GDPR does not generally apply to information about deceased persons. However, where documents or Messages contain personal data about living people (for example Delegates, Recipients, relatives, executors, doctors or officials), UK GDPR may apply to that living-person data and we treat it accordingly.

4. The personal data we collect

We collect different categories of data depending on your role and how you use the Service.

4.1 Identity and contact data (including sign-up data)

• The mobile phone number you confirm at sign-up
• Twilio verification metadata for that confirmation (check identifier, status, timestamp; we do not retain the one-time password itself)
• The credential you choose at sign-up: a password hash if you sign up with email and password, or your Google or LinkedIn profile identifier and authorisation tokens if you sign up via single sign-on
• Name (or chosen display name)
• Email address (verification required)
• Phone number (verification required)
• Timezone setting (for scheduling Scheduled Check-ins)
• Date of birth (optional, where provided, used only to verify delegate-provided information and apply safeguards for minor Recipients)
• Contact details you choose to share (for example Delegates who opt to share email/phone with other Delegates for coordination)

4.2 Account and preference data

• Account settings, including Scheduled Check-in frequency, Escalation buffer and Escalation mode
• Notification preferences (where offered)
• Delegate visibility and contact sharing preferences
• Subscription status and plan selection

4.3 Check-in and status data (operational events)

• Scheduled Check-in due times (T0)
• Account Holder responses (Scheduled Check-in confirmations and Quick check-ins) and timestamps
• Reminder and Escalation events and timestamps
• Care Pause requests, disputes, outcomes and timestamps
• Status Check events (Request a Check-in, Raise a Concern, Report a Passing) and timestamps
• Daily Status Check reminders sent to the Account Holder during the 72-hour Status Check window (timestamps and delivery status)
• Delegate follow-up updates sent to Delegates who were contacted during Escalation or notified via Raise a Concern (timestamps and delivery status)
• Delegate Outcomes recorded in the Service
• Passing verification disputes and responses
• Resolution votes (confirm OK, dispute, confirm passing)
• Dispute resolution outcomes and timestamps

4.4 Message content (Account Holder created)

• Text, audio, video and attachments that Account Holders upload as Messages
• Metadata needed to store and deliver Message content (file size, format, timestamps)

4.5 Passing verification data

When a Passing is reported through the Service:

• The reporting Delegate's identity verification outcome from Persona
• Uploaded death certificate file and associated metadata
• Review notes/outcomes relating to plausibility and consistency checks
• Verification event logs (see section 9)

4.6 Recipient access verification data

• Persona identity verification outcome for Recipients before they can access Message content
• Access window dates and access attempt metadata (for security and abuse prevention)

4.7 Profile data we receive from your chosen Identity Provider

If you sign up with Google, we receive your email address, name, Google profile identifier and (where available) profile picture. If you sign up with LinkedIn, we receive the equivalent data from LinkedIn. We receive this data on your authorisation through the OAuth consent step you complete with Google or LinkedIn directly. We do not push your data to Google or LinkedIn; the flow originates from you.

4.8 Payment and billing data

We use Stripe to process payments. We do not store full payment card details on our systems. We may receive and store:

• Subscription status, billing dates, renewal dates
• Last four digits and card brand (if provided by Stripe)
• Payment confirmations, receipts and invoice information
• Failed payment status and timestamps
• Cancellation timestamps and related confirmations

4.9 Support communications

• Emails you send to us
• Optional WhatsApp messages where offered (general support only)
• Records of support actions and outcomes

4.10 Website and device data

• IP address, device and browser information
• Approximate location derived from IP (for security and fraud prevention)
• Cookie and analytics identifiers (only where consented for non-essential cookies)

5. How we use your personal data and our lawful bases

UK GDPR requires us to have a lawful basis for processing. The lawful basis may depend on the context.

5.1 To provide the Service and perform our contract with you (Contract)

We process personal data to:

• Create and manage accounts
• Verify email and phone numbers
• Schedule Scheduled Check-ins and allow Account Holder responses
• Send Reminders, including daily Status Check reminders while a Status Check is open
• Contact Delegates based on the Account Holder's settings and Service flows
• Send follow-up updates to Delegates who were contacted during Escalation or notified via Raise a Concern, to indicate whether action is still needed
• Operate Care Pause and Status Check flows
• Store Messages and deliver them only after Passing verification
• Allow Recipients to access Messages via secure link (subject to identity verification)
• Provide customer support

Lawful basis: performance of a contract (UK GDPR Article 6(1)(b)).

5.2 To meet legal obligations (Legal obligation)

We process personal data to:

• Comply with tax and accounting requirements
• Respond to lawful requests from regulators or law enforcement
• Maintain records required by consumer protection rules where applicable

Lawful basis: legal obligation (Article 6(1)(c)).

5.3 To protect the Service, prevent misuse and handle disputes (Legitimate interests)

We process personal data to:

• Prevent fraud, account compromise and abuse (including misuse of Status Checks)
• Keep the Service secure, maintain logs and investigate incidents
• Maintain evidence of key contract events (acceptance, billing, cancellation, notices sent)
• Defend and manage complaints, chargebacks and disputes

Lawful basis: legitimate interests (Article 6(1)(f)). Our legitimate interests are operating a secure, trustworthy service and preventing harm and fraud. We have assessed that these interests are not overridden by your rights and freedoms. We balance these interests against your rights and minimise data where possible.

5.4 Consent-based processing (Consent)

We rely on consent where required, including:

• Non-essential cookies and analytics (managed via Cookiebot)
• Marketing emails (where we send them)

Lawful basis: consent (Article 6(1)(a)). You can withdraw consent at any time (see section 11).

5.5 Special category data

We do not require you to provide special category data. Account Holders may choose to include sensitive information in their sealed Messages, including health information; the Service treats the content of sealed Messages as private and encrypts it at rest. Persona may use biometric checks to verify identity at two points only: for Delegates at the moment of reporting a Passing, and for Recipients accessing a released Message where the Account Holder configured enhanced verification for that Recipient. Account Holders are not Persona-verified at sign-up. We do not receive your biometric template or raw biometric data from Persona. We receive verification outcomes and limited metadata needed to operate the Service securely.

5A. Death-verification documents

When an Account Holder dies, family or representatives may submit proof of death (typically a death certificate) so we can confirm entitlement to release the sealed Messages the Account Holder entrusted to us. Because we will not release messages without that confirmation, this step is essential to the service.

We process two layers of personal data when we receive a death-verification document. The first layer is information about the deceased Account Holder. Under UK and EU GDPR (Recital 27), data protection rights do not apply to deceased persons, but we treat that information with the same care. The second layer is information about living people whose names appear on the certificate (typically the informant who registered the death, the spouse, the deceased's parents, the certifying doctor and the registrar). Their data is fully protected under UK GDPR and EU GDPR. We process it on the basis of our legitimate interests under Article 6(1)(f) UK GDPR (verifying entitlement to release the deceased Account Holder's sealed messages), having balanced that interest against their interests, rights and freedoms in a documented Legitimate Interests Assessment.

We ask submitters to redact the cause-of-death section before they send the document. Where it is not redacted, we redact it on receipt before any operational reviewer sees it. Where redaction is not practicable and the cause-of-death section is processed in unredacted form, we rely on Article 9(2)(f) UK GDPR (establishment, exercise or defence of legal claims). A reviewer (the founder of Y.O.D.O. or our engineering processor) conducts a documentary review of each submission before any release decision is made. The reviewer has explicit authority to call for a second reviewer or to escalate to the founder for arbitration if anything about the case warrants it. Where the Account Holder has expressly enabled a Solicitor/Notary Special Delegate verification carve-out for a specific qualifying professional, the reviewer is also informed at the workstation that the reporting Delegate is a verified registered solicitor or notary and may give that status appropriate weight. The detail of how that review works is described on our How Passing Verification Works page.

The death certificate is stored as a file (PDF, JPEG or PNG, up to 20 MB) in encrypted object storage (AWS S3), together with metadata in our database (upload timestamp, uploader identity, verification status, resolution cause, who resolved it, and encrypted resolution notes). We do not compute or store a hash or checksum of the certificate. The certificate file is held while the Account Holder's account is active and is removed from live storage when the account is deleted. Our S3 bucket has object versioning enabled with a lifecycle rule that permanently deletes noncurrent versions at day 365, so a removed certificate may persist as a recoverable noncurrent version for up to 365 days after account deletion, then is permanently deleted. We do not run a seven-year retention period on death-verification documents.

If you are a living person named on a death certificate we hold, you have UK GDPR rights of access, rectification, erasure, restriction, portability and objection (Articles 15 to 22 UK GDPR; Articles 15 to 22 EU GDPR for EEA residents). Contact us at info@yodo.ltd. EEA residents may also contact our EU representative (named elsewhere in this Privacy Policy). Where you exercise the right to object, we balance your objection against our continuing legitimate interest in retaining the record while the related account is active and during the storage-versioning window described above.

6. Who we share personal data with

We do not sell your personal data.

We share data only as needed to provide the Service, keep it secure, comply with law, or manage disputes.

6.1 Service providers and Identity Providers

We do not sell your personal data. We share data with the following categories of third parties only as needed to run the Service:

• Hosting and infrastructure (AWS, Render)
• Database services (Crunchy Data)
• Content delivery and security (Cloudflare)
• Transactional email delivery (Resend)
• SMS delivery (Twilio Ireland Limited, used both for the mobile-phone one-time password at sign-up and for Status Check escalation SMS in the operational lifecycle)
• Payments (Stripe)
• Identity verification (Persona, engaged only at the two irreversible decision points described in §1.5)
• Cookie consent tooling (Cookiebot, operated by Cybot A/S, EU/Denmark)
• Analytics and tag management only where enabled and consented
• Business email and document storage (Google Workspace, provided by Google Ireland Limited as our EEA contracting entity, with Google LLC for US support routing, used for inbound mail to info@yodo.ltd including data subject rights requests and support correspondence, and for shared storage of operational documents on Google Drive)

Identity Providers for Account Holder single sign-on (Google LLC and LinkedIn Corporation) act as independent controllers for the authentication event and are listed transparently on our Sub-processors List in that role. A complete and current list is in our Sub-processors List.

The Google LLC entry as an Identity Provider for Account Holder Google sign-in is a separate processing relationship from the Google Workspace business email and storage role added in v2.3.0. Both are listed in the Sub-processors List with their respective scopes.

6.2 Identity verification provider (Persona)

Persona provides identity verification. For Delegate Passing verification and Recipient access verification, Persona may act as an independent controller (where it determines the means of biometric processing) or as a processor on our instructions (where we control the verification configuration). The specific role depends on the verification product and configuration in use. During the verification flow we will present Persona's notices and you will be able to review how they process your data. For more information, see Persona's Privacy Policy. We receive verification outcomes and do not need your biometric template.

6.3 Delegates and other users

• Delegates can see limited status information (for example whether action is needed and the Account Holder's last check-in) but do not see Message content.
• If the Account Holder enables Delegate visibility, Delegates may see other Delegates' names for coordination, subject to each Delegate's visibility preference.
• Delegates may choose to share email/phone with other Delegates for coordination. This is optional and controlled by each Delegate.

6.4 Special Delegates (Partners)

If you name an individual or organisation as a Special Delegate, and that Special Delegate has a Partner account with Y.O.D.O., they can see a limited set of your personal data through their Partner account: your name, the fact you have named them, and your status (active, in verification, passing confirmed). When a Passing is verified, they also receive the email address and phone number you shared. Special Delegates do not see your Messages, your Check-in responses, your location, health or device data, or your billing details. You can remove a Special Delegate at any time; the information they can see about you stops updating the moment you remove them.

6.5 Legal and professional advisers

We may share data with our professional advisers (lawyers, accountants, insurers) where necessary for advice, compliance, or disputes.

6.6 Legal requests

We may disclose data if required by law, regulation, court order, or where necessary to protect rights, safety and security.

7. International transfers

We are UK-based. Some of our providers may process personal data outside the UK.

Where personal data is transferred outside the UK (and, where relevant, outside the EEA), we use appropriate safeguards such as:

• the UK International Data Transfer Agreement (UK IDTA) or the UK addendum to EU SCCs
• adequacy decisions where applicable
• additional technical and organisational safeguards where appropriate

Details of specific provider transfer mechanisms may be provided on request where feasible.

7.1 EU/EEA users and our EU Representative

If you are located in the European Economic Area (EEA), your rights under EU GDPR (Regulation 2016/679) apply in addition to the rights described in this Policy. The UK currently benefits from an EU adequacy decision, meaning transfers of personal data from the EEA to the UK are permitted without additional safeguards. We monitor the status of this adequacy decision and will implement appropriate transfer mechanisms if it changes. For more detail, see our International Transfers Notice.

EU Representative (Article 27 EU GDPR): Christina-Eloiza Kouraki, Marasli 29, Athens 10676, Greece, email eloizakouraki@yahoo.gr. EU/EEA data subjects and supervisory authorities (in particular the Hellenic Data Protection Authority) may contact our EU Representative for any data protection matter, and may also contact our UK Data Protection Lead (Mrs Theodosia Kouraki) at info@yodo.ltd. EEA users retain the right to lodge a complaint with their local supervisory authority.

8. Security

We use reasonable technical and organisational measures to protect personal data, including access controls, encryption in transit and at rest where appropriate, and monitoring for misuse.

No system is 100% secure. You are responsible for keeping your login details secure and for maintaining access to your verified email account.

8.1 Personal data breach notification

In the event of a personal data breach, we will, in line with Articles 33 and 34 of UK GDPR and EU GDPR:

• notify the Information Commissioner's Office (ICO) without undue delay and, where feasible, not later than 72 hours after becoming aware of the breach, unless the breach is unlikely to result in a risk to the rights and freedoms of natural persons;
• where EEA data subjects are affected, also notify the Hellenic Data Protection Authority (HDPA) as the supervisory authority where our EU Article 27 Representative is established, and cooperate with any other EEA supervisory authority that requests information;
• notify affected users without undue delay where the breach is likely to result in a high risk to their rights and freedoms, using clear and plain language and describing the nature of the breach, the likely consequences, the measures taken or proposed, and a point of contact for more information;
• maintain an internal register of all personal data breaches and our response, regardless of whether notification was required.

9. Logs, evidence and audit trail

To operate a secure, dispute-resistant service, we keep GDPR-minimised logs of key events, which may include:

• Acceptance of Terms (timestamp, version)
• Free Trial start/end timestamps
• Payment details added and trial conversion consent captured (timestamp)
• Subscription start/renewal/cancellation timestamps
• Key notices sent (trial start confirmations, payment details added confirmations, trial end notices, subscription confirmations, renewal notices, cancellation confirmations, failed payment notices, Status Check reminders, Delegate follow-up updates, deletion notices)
• Security events (sign-in attempts, account changes, OTP events)
• Passing report events (start, verification outcome, close)
• Dispute resolution responses (Care Pause and Passing verification)
• Passing verification confirmations and disputes
• Tie-resolution outcomes and triggering events
• 72-hour dispute window start and expiry timestamps
• Recipient verification outcomes

Verification log for Passing reports

Where a death certificate is uploaded, we maintain a passing-report timeline / event-log entry covering events such as "passing verified", "disputed" or "expired". Each entry holds an event type, the actor and actor identifier, a timestamp, an encrypted details payload (report reference, who reported, resolution cause, who resolved, any vote tally) and a metadata field. The details payload is encrypted at rest. The identity-verification record (the ID check on the person reporting the death) is provided by Persona and stores the provider name, Persona inquiry and event identifiers, the encrypted extracted name from the ID document, a name-match result and score, status, timestamps, an encrypted provider session token and the inquiry-attributes block returned by Persona webhooks. The raw identity-document image is held by Persona, not by Y.O.D.O. We do not compute or store a hash of the uploaded death certificate. On account deletion, the timeline / event-log entry and the Persona identity-verification record are soft-deleted: excluded from live queries but retained in encrypted form so we can answer a later dispute or regulator query. Because the rows survive in this soft-deleted form, the fact that a certificate once existed (including who uploaded it and when) is preserved even after the certificate file itself has been removed from live storage.

10. Retention: how long we keep data

We keep personal data only as long as needed for the purposes described in this Policy, then delete or anonymise it.

10.1 Trial ends without a paid subscription

If your Free Trial ends without a paid subscription, we aim to retain your account data for 30 days so you can re-subscribe, unless you request earlier deletion. Limited logs and records may be retained longer for security, fraud prevention and dispute handling.

10.2 Inactive accounts

If an account becomes Inactive (no Active subscription and no Active Delegate relationship), we may delete the account and associated data after 30 consecutive days of being Inactive, subject to legal and security needs.

10.3 T0-based non-response deletion (Account Holders)

If a Scheduled Check-in remains unconfirmed and there is no Account Holder response and no Delegate Outcome, we may begin pre-deletion steps after 30 days from T0 and may delete undelivered Messages and account-operational data after 60 days from T0, subject to legal and security needs.

10.4 Recipient access window

Delivered Messages are available to Recipients for 12 months from the delivery trigger. After that, Message content is removed from our active systems. Limited retention in backups and logs may still apply.

10.5 Passing verification materials

Death certificate files are held in AWS S3 while the related Account Holder's account is active. They are removed from live storage when the account is deleted. Because the bucket has object versioning enabled with a 365-day lifecycle on noncurrent versions, a removed certificate may persist as a recoverable noncurrent version for up to 365 days after account deletion, then is permanently deleted. We do not run a seven-year retention period on the certificate file. The passing-report timeline / event-log entry and the Persona identity-verification record are soft-deleted on account deletion (excluded from live queries but retained in encrypted form for audit and dispute handling) rather than physically erased.

Account deletion itself is a hybrid operation. We anonymise identifying personal data in place on the user record (name overwritten with "Deleted User", email replaced with an anonymised placeholder, phone number and date of birth cleared, sign-in IPs overwritten, auth secrets cleared, and sign-in events, stored contacts and delegation invitations similarly anonymised). We remove from live storage the death certificate file (subject to the S3 versioning window above) and any exported personal-data files. We soft-delete the passing-report record and metadata, timeline / event-log entries and identity-verification records (including Persona inquiry-attributes data).

10.6 Subscriptions and deletion

If we delete an account under section 10.2 or 10.3 (or under any equivalent deletion rule in the Terms), we take reasonable steps to stop future subscription renewals linked to that account (including by cancelling the subscription record with our payment provider where applicable). If a renewal payment is taken after deletion due to timing or processing delays, contact Support and we will review and, where appropriate, refund that renewal payment.

10.7 Backups and security logs

Database backups (Crunchy Bridge) run on a rolling cycle of approximately 10 days (10 daily snapshots, with no weekly, monthly or yearly tier) and contain database rows only, not certificate files. A backup taken before an account deletion will therefore contain that account's pre-deletion personal data until it ages out of the cycle (approximately 10 days). Files held in object storage (AWS S3, including any uploaded death certificate) are subject to the 365-day noncurrent-version window described in §10.5 rather than the database backup cycle. Security and access logs are typically retained for around 12 months.

10.8 Tax and regulatory records

We retain tax, billing and accounting records for up to 7 years as required by HMRC and applicable tax law. Audit logs (including Passing dispute responses, resolution votes, and tie-resolution outcomes) are retained for as long as necessary for security, fraud prevention and dispute handling.

Where we keep data longer than the main operational periods above, it is because we need it for legal obligations, security, fraud prevention or disputes. We keep it minimised and restricted.

11. Your rights

You have rights under UK GDPR, including:

• Access to your personal data
• Correction of inaccurate data
• Deletion (in certain circumstances)
• Restriction of processing (in certain circumstances)
• Objection to processing based on legitimate interests
• Data portability (for data processed based on contract or consent, where applicable)
• Withdrawal of consent (for consent-based processing)

How to exercise your rights

Email info@yodo.ltd from your verified email address with "Data Rights Request" in the subject line. We may need to verify your identity before acting on a request.

We will respond within one calendar month of receiving your request. In complex cases or where we receive a large number of requests, we may extend this by a further two months and will notify you if we do.

If you are a Recipient accessing a delivered Message as a guest, you can still contact us to exercise rights. We may request additional information to locate your data and protect security.

12. Marketing and service communications

12.1 Essential service communications

We send essential service communications by email (and in-Service notices), including:

• Scheduled Check-in prompts
• Reminders (including daily Status Check reminders while a Status Check is open)
• Escalation notices
• Delegate follow-up updates
• OTP and step-up authentication codes
• Trial start confirmations, payment details added confirmations, and trial end notices
• Subscription confirmations, renewal notices, receipts and failed payment notices
• Cancellation confirmations
• Deletion notices
• Verification process notices

You cannot opt out of essential service communications.

12.2 Marketing

If we send marketing emails, we will do so only where we have the right to do so under applicable rules (for example with your consent where required). You can opt out at any time using the unsubscribe link or by contacting us.

Founders' offer (15% off for life): Where you claim our limited founders' discount (claim window closing 31 May 2026), we process your email and basic eligibility data on the basis of contract and our legitimate interests in administering the offer. The discount is one-time and non-restorable per account: if cancelled or lapsed it cannot be re-applied. Full terms are set out in Schedule E of our Terms.

Partner client discount (15%, must be used within 3 months): If you sign up using a Partner code or referral link, we note that you came through that Partner. We use this only to apply your one-off 15% discount to your first paid billing period, to stop the same discount being claimed twice, and to share an anonymous total with the Partner showing how many people used their code. Our lawful basis is contract and our legitimate interest in running the offer and preventing fraud. Codes and links must be used within 3 months of being issued. We do not pass any of your personal details to the Partner as part of this offer. Signing up with a Partner code automatically adds the Partner to your Special Delegates list (see §6.4); you can remove them at any time in account settings before any verification event. The full rules are in Schedule F of our Terms, and the cookie side of this is explained in Cookies Policy §6.

13. Cookies and analytics

We use Cookiebot to manage cookie consent. Non-essential cookies (including analytics) are set only where you consent. You can change your cookie preferences at any time using the cookie settings tool.

For more detail, see our Cookies Policy.

14. Children

Account Holders and Delegates must be 18 or over. Account Holders may name a minor as a Recipient. The parts of the Service likely to be accessed by children, principally the Recipient access flow, are designed to the ICO Age Appropriate Design Code (the Children's Code) by default. Where a Recipient is a minor, a parent or legal guardian may contact us about access window extensions and privacy requests. Our Minors Policy sets out the position in full.

15. WhatsApp support

We may offer WhatsApp support for initial triage only. All substantive matters (including data rights requests, complaints, and account actions) must be handled by email before any action is taken. Do not send one-time codes, identity documents, death certificates, passwords or payment details via email or WhatsApp. If you need to provide documents, we will direct you to the in-app flow.

WhatsApp is operated by WhatsApp Ireland Limited, a Meta Platforms group entity, and acts as an independent controller for messages you send via WhatsApp. Messages sent via WhatsApp are subject to Meta's privacy practices. We do not use WhatsApp for formal notices, document submission, or processing data rights requests.

15A. Automated decision-making and use of AI

We do not make solely automated decisions that have a legal or similarly significant effect on you within the meaning of Articles 22A to 22D UK GDPR (introduced by the Data (Use and Access) Act 2025 with effect from 5 February 2026, replacing the previous Article 22). Release decisions are made by a human reviewer, not by an automated process. Escalation, Reminders and deletion steps are automated but are configured by you in your account settings and can be interrupted by human action (for example by recording a check-in, or by a Delegate recording an outcome).

15A.1 Use of AI in identity verification

Our identity verification provider (Persona) uses machine-learning systems to assess document authenticity, perform face-match comparison, and detect fraud signals. Under the EU AI Act (Regulation (EU) 2024/1689), AI systems used for biometric identification and verification of natural persons are classified as high-risk under Annex III. From the AI Act's applicability dates (and in any event from 2 August 2026 for high-risk AI obligations), Y.O.D.O., as a deployer of a high-risk AI system:

• tells you, in clear and plain language, when an AI system is being used to process your data (this statement is that disclosure);
• maintains meaningful human oversight: a Persona verification outcome never automatically releases messages or unlocks an account. A named human reviewer at Y.O.D.O. assesses the outcome before any consequential decision is taken;
• gives you the right to challenge a verification outcome and to request human review, by emailing info@yodo.ltd;
• cooperates with our provider's fundamental rights impact assessment (FRIA) obligations and retains records sufficient to allow post-market monitoring;
• does not use AI systems for emotion recognition, social scoring, or any prohibited practice under Article 5 of the AI Act.

We do not currently deploy generative AI features that produce content for users. If we add such features, this Policy will be updated and affected users notified before the feature is enabled.

16. Changes to this Policy

We may update this Policy from time to time. The "Last Updated" date shows when it changed. If changes are material, we will take reasonable steps to notify users through the Service and/or by email.

17. Contact us and complaints

General contact: info@yodo.ltd

Data protection requests: If you wish to exercise any of your data protection rights (including subject access requests, erasure, or portability), please email info@yodo.ltd with "Data Rights Request" in the subject line. All data rights requests are triaged and handled by our Data Protection Lead (Mrs Theodosia Kouraki) within the statutory timescales required by UK GDPR (normally within one calendar month of receipt).

EEA users: Our EU Representative under Article 27 EU GDPR is Christina-Eloiza Kouraki, Marasli 29, Athens 10676, Greece, eloizakouraki@yahoo.gr. EEA Data Rights Requests may be sent to the EU Representative or to our UK Data Protection Lead at info@yodo.ltd. If you are based in the European Economic Area, you may complain to your local supervisory authority. The Hellenic Data Protection Authority (HDPA), Kifissias 1-3, 11523 Athens, Greece, complaints@dpa.gr, +30 210 6475600, is the EU supervisory authority Y.O.D.O. expects to liaise with primarily, given our appointed EU representative is established in Greece.

If you have concerns about how we handle personal data, please contact us first and we will try to resolve it.

You also have the right to complain to the UK Information Commissioner's Office (ICO), or if you are based in the EEA, to your local supervisory authority. Y.O.D.O. Ltd is registered with the ICO under reference ZC015883.