Privacy policy

Version: 2026-10-23
Effective date: 2026-10-23
Product: NEAREE — Real Life Dating
Controller: [OPERATOR LEGAL NAME]
Registered address: [REGISTERED ADDRESS]
Company registration number: [COMPANY REGISTRATION NUMBER]
Tax number: [TAX NUMBER]
Privacy contact: [PRIVACY EMAIL]
DPO contact, if applicable: [DPO EMAIL]

Draft for legal review. This document is designed to reflect the current NEAREE product and technical specification. It must be completed with the operator's final legal identity, vendors, retention schedule and launch-market requirements before publication.

1. Who we are

NEAREE is a privacy-focused dating service designed to help people discover compatible people nearby and move from online interaction toward real-world meetings.

The controller responsible for the processing described in this notice is [OPERATOR LEGAL NAME].

For privacy questions, data-subject requests or complaints about our processing, contact [PRIVACY EMAIL].

Where a Data Protection Officer is required or voluntarily appointed, the DPO can be contacted at [DPO EMAIL].

2. What this notice covers

This notice applies to the NEAREE iOS and Android applications, the NEAREE web application, the NEAREE website where applicable, and related backend services.

It explains:

• what personal data we process;
• why we process it;
• the legal basis for each purpose;
• how location, profiles, photos, chats and safety data are handled;
• when special-category data may be processed;
• how long categories of data are retained;
• who receives data;
• international transfers;
• automated decision-making and profiling;
• your GDPR rights;
• deletion and anonymisation.

3. Data we process

3.1 Account and identity data

Depending on the sign-in method, we may process:

• internal member identifier;
• name or first name;
• e-mail address;
• identity-provider identifier;
• verified e-mail status;
• device/session information;
• authentication and security events;
• language and application preferences.

The dating service uses a dating account identifier. General CRM customer records are not the source of truth for dating-domain data.

3.2 Age and eligibility

NEAREE requires users to satisfy the configured minimum age.

We may process:

• date of birth;
• calculated age;
• age-gate result;
• account eligibility status.

The administrator interface is designed to show age rather than the full birth date where possible.

If an account is determined to be under the minimum age, it is placed into the applicable restricted state.

3.3 Dating profile

A member may provide:

• first name;
• age;
• photos;
• biography;
• gender;
• who they are interested in;
• relationship intent;
• city/area;
• interests;
• lifestyle attributes;
• smoking and alcohol preferences;
• children / plans for children;
• dating categories;
• age and distance preferences;
• privacy settings such as active-status or city visibility.

Some of these fields can reveal or strongly indicate sensitive information.

3.4 Special-category data

Dating information can include data revealing or concerning sex life or sexual orientation, and may in some contexts reveal other special categories of personal data under Article 9 GDPR.

Where NEAREE processes such data as part of the dating service, the intended legal safeguard is explicit consent under Article 9(2)(a) GDPR, collected separately from acceptance of the Terms.

The current product design contains a separate required consent for processing relevant special-category dating data, including gender, orientation and preferences.

Withdrawal of that consent may make it impossible to provide the dating service and, under the current product design, can trigger account deletion. The final implementation and wording must be reviewed by counsel for the applicable market.

Do not assume that every profile field is special-category data. The classification depends on the actual field and how it is processed.

3.5 Photos

NEAREE may process profile photos and, where enabled, a selfie used for photo verification.

Uploaded profile photos are processed to remove metadata before storage. The service re-encodes accepted images and removes EXIF/GPS/XMP and camera metadata.

Profile photos are stored privately and delivered using short-lived signed URLs.

Verification selfies are used for the verification decision and are deleted after the decision and on account deletion, subject to any lawful hold that must be maintained.

3.6 Location data

Location is particularly sensitive in a dating service.

NEAREE is designed so that:

• background continuous location is not required;
• the app requests foreground / “while using the app” location;
• exact coordinates are never exposed to other members;
• a reported position is rounded before it is stored;
• no historical trail of positions is maintained;
• a location older than 24 hours is treated as stale for active proximity features;
• stale location rows are deleted after the configured retention period, currently 7 days;
• account deletion removes the location record.

Discovery may use fresh location to calculate eligibility and distance internally.

The API does not return another member's exact distance or exact position.

Nearby uses privacy-protected aggregates. Counts below the configured threshold are suppressed, and counts are bucketed so that individual arrivals/departures cannot easily be inferred.

3.7 “I'm Out”

The optional “I'm Out” status is time-limited.

When enabled, NEAREE may process:

• that the member is currently opted in;
• the expiry time;
• a privacy-safe location relationship;
• whether the member has opted into meeting;
• limited match eligibility information.

The feature does not publish an exact position.

3.8 Discovery, likes and matches

We process:

• candidates shown;
• likes and passes;
• highlighted likes and optional notes;
• received likes;
• mutual matches;
• blocks;
• eligibility and visibility state;
• recommendation reasons and internal scoring inputs.

The recommendation system is designed around explicit product rules and deterministic compatibility logic. It can use factors such as relationship intent, age compatibility, distance, lifestyle, interests and activity.

NEAREE does not expose internal ranking weights.

3.9 Chat and realtime data

Chat data may include:

• conversation identifiers;
• participants;
• message identifiers;
• message text;
• timestamps;
• delivery and read state;
• client idempotency identifiers;
• typing and presence state.

PostgreSQL is the persistent source of truth for messages. Redis may carry ephemeral presence, typing and connection-routing state.

Typing indicators are not stored as message history.

Presence is short-lived and expires automatically.

Messages in ended conversations are currently scheduled for deletion 180 days after the conversation ends, unless a lawful safety, dispute, legal or other documented hold applies.

A reported conversation may be placed on a temporary hold until the relevant report is decided.

3.10 Date planning

We may process:

• date proposals;
• acceptance/decline;
• date and time window;
• date type;
• selected or suggested place;
• confirmation/cancellation;
• reminders;
• “We Met” feedback.

The “We Met” feedback is private product feedback and is not displayed publicly.

The share-a-date feature uses the device share sheet and is designed so NEAREE does not store the recipient/friend to whom the user shares the information.

3.11 Safety, reports and moderation

We process safety information including:

• reports;
• block actions;
• restrictions and suspensions;
• moderation decisions;
• report reasons;
• safety events;
• verification status;
• suspicious-account signals;
• audited moderator access.

A report can be submitted only in an interaction context supported by the product. Reporting can also block the reported person.

Moderators do not have unrestricted access to private conversations. Conversation access requires the appropriate permission, an unresolved report concerning the conversation, and a recorded reason. Access is audited.

3.12 Verification

If photo verification is enabled, NEAREE may process a selfie and a pose/verification result.

The verification selfie is not intended to become a permanent profile image. It is deleted after the decision, subject to any lawful retention obligation.

Where verification uses biometric techniques, the operator must confirm with counsel whether the actual implementation constitutes processing of biometric data for the purpose of uniquely identifying a person under Article 9 GDPR. The current design is intended as a liveness/verification measure rather than an identity-matching system.

3.13 Personality and skills

NEAREE may offer personality and skills surveys.

The product specification intentionally retains:

• the latest score per dimension;
• the resulting badge;

and does not retain the member's individual answers.

Scores are shown to the member and may be shown as badges on the profile if the member enables them.

The surveys are described as lightweight dating self-portraits, not medical or clinically validated psychological tests.

3.14 Notifications

We process device and push-token information where necessary to deliver:

• likes;
• matches;
• date updates;
• reminders;
• safety notifications;
• other product notifications.

Stored notification records contain limited identifiers and event metadata rather than chat message text.

The notification centre keeps the newest configured number of notifications and removes notifications affected by blocking or account deletion.

3.15 Analytics

NEAREE may process product analytics for:

• reliability;
• product improvement;
• conversion;
• match-to-date measurement;
• safety and quality;
• experiments.

The dedicated analytics design is pseudonymous by construction. Members, matches, dates and conversations are represented using keyed hashes, and analytics should not store message text, exact locations or private notes.

The analytics service must not be used as a backdoor for reconstructing the dating database.

3.16 Payments and purchases

NEAREE may support:

• Apple App Store purchases;
• Google Play purchases;
• Stripe web subscriptions;
• Stripe web one-off payments for coins.

NEAREE does not receive or store full payment-card numbers from Stripe Checkout.

Stripe may process billing information and payment details under its own terms and privacy documentation.

Apple and Google may process purchases made through their respective stores.

NEAREE records only the information needed to determine entitlement, payment status, invoice references and related accounting/support records.

Coins have a wallet and ledger. Account deletion removes the NEAREE coin wallet and history, while payment records that must remain in Stripe or stores are not controlled by account deletion.

3.17 Support and administration

We may process information necessary to:

• answer support requests;
• investigate abuse;
• enforce Terms;
• resolve payment issues;
• respond to legal requests;
• maintain security;
• operate the service.

Administrative access to sensitive dating information is permission-controlled and audited.

4. Purposes and legal bases

The following is the intended GDPR mapping. The operator must confirm the final legal basis for each processing operation with counsel.

Consent is not treated as a general-purpose legal basis for everything. Where consent is used, it is requested for the specific processing and can be withdrawn.

5. Profiling and automated decision-making

NEAREE performs limited profiling to provide dating recommendations and safety controls.

Examples include:

• compatibility scoring;
• candidate eligibility;
• distance-based relevance;
• activity/visibility eligibility;
• automated suspicious-profile rules.

The recommendation score is not intended to make legal or similarly significant decisions about a person.

Safety automation can result in restrictions or flags. Important moderation decisions should be subject to human review where required by law and product policy.

The exact logic and weights used for ranking are not disclosed because doing so could enable manipulation of the service, but the product uses defined compatibility signals rather than unrestricted inference of sensitive traits.

6. Recipients and processors

Depending on the final deployment, recipients may include:

• hosting and infrastructure providers;
• database and cache infrastructure;
• object-storage provider;
• push-notification providers;
• Apple and Google;
• Stripe;
• e-mail provider;
• error monitoring provider;
• analytics infrastructure;
• mapping/tile/geocoding provider;
• professional advisers;
• competent authorities where legally required.

The final published version must contain an up-to-date processor/sub-processor list with:

• provider name;
• service;
• purpose;
• location;
• transfer mechanism where relevant.

7. International transfers

Some providers may process data outside the EEA.

Where personal data is transferred to a country without an applicable adequacy decision, NEAREE will use an appropriate GDPR transfer mechanism, such as the European Commission's Standard Contractual Clauses, together with any additional safeguards required by law.

The final vendor list must identify the actual transfer locations and mechanisms.

8. Retention

NEAREE follows storage limitation and deletes or anonymises data when it is no longer needed.

Current product-specific targets include:

The final retention schedule must be approved by the controller and adapted to applicable tax, limitation, fraud-prevention and legal-hold requirements.

9. Account deletion and anonymisation

Members can request account deletion.

The deletion process is designed to remove or anonymise dating data across the services.

Deletion includes, as applicable:

• dating profile;
• profile photos;
• location record;
• matches and dating relationships;
• chat data, subject to the applicable message-retention and legal-hold rules;
• survey results;
• notifications;
• coin wallet and history;
• verification data.

Safety records such as reports or restrictions may be retained in anonymised form where necessary to prevent repeat abuse, establish the history of a safety decision, or comply with legal obligations.

Payment records held by Stripe, Apple or Google are governed by those providers' own retention rules and applicable law.

10. Security

We use technical and organisational measures appropriate to the risk, including:

• encryption in transit;
• controlled access to production systems;
• secrets management;
• role-based administration;
• audit logging;
• rate limiting;
• authentication controls;
• private networking between services where available;
• signed access to private media;
• metadata stripping from profile images;
• database backups;
• health monitoring and incident response;
• separation of dating data from general CRM data.

No system can guarantee absolute security.

11. Cookies and similar technologies

The NEAREE web application may use strictly necessary cookies or local storage required for authentication, security and basic functionality.

Optional analytics, advertising or similar technologies will be used only where the applicable law requires consent and the required consent mechanism is provided.

The final web implementation must have a separate cookie notice where necessary.

12. Your GDPR rights

Subject to applicable law, you may have the right to:

• obtain access to your personal data;
• request correction;
• request erasure;
• request restriction;
• object to processing based on legitimate interests;
• receive portable data where applicable;
• withdraw consent;
• object to certain direct marketing;
• lodge a complaint with a supervisory authority;
• obtain information about relevant automated decision-making.

Requests can be sent to:

[PRIVACY EMAIL]

We may need to verify your identity before fulfilling a request.

13. Complaints

If you believe that your data protection rights have been violated, contact us first at [PRIVACY EMAIL].

You may also complain to the competent data protection supervisory authority.

For an operator established in Hungary, the final notice should contain the current official details of:

[SUPERVISORY AUTHORITY DETAILS]

14. Changes to this notice

We may update this notice when:

• the service changes;
• processing purposes change;
• new processors are introduced;
• legal requirements change;
• security practices change.

Material changes will be communicated through the app, website or another appropriate channel where required.

The version and effective date are shown at the top of this notice.

15. Contact

[OPERATOR LEGAL NAME]
[REGISTERED ADDRESS]
[COMPANY REGISTRATION NUMBER]
[TAX NUMBER]

Privacy: [PRIVACY EMAIL]
Legal: [LEGAL EMAIL]
DPO: [DPO EMAIL]

---

Appendix A — Data-flow summary

Member
  |
  +--> Identity / authentication
  |
  +--> Dating Core
  |      +--> profile
  |      +--> discovery
  |      +--> likes / matches
  |      +--> dates
  |      +--> safety
  |      +--> location
  |
  +--> Chat
  |      +--> messages
  |      +--> realtime
  |
  +--> Redis
  |      +--> ephemeral presence
  |      +--> typing
  |      +--> rate limits / queues
  |
  +--> Object Storage
  |      +--> private profile media
  |
  +--> Analytics
  |      +--> pseudonymous events
  |
  +--> Payments
         +--> Apple / Google
         +--> Stripe

The architecture is intentionally privacy-oriented: the general CRM is not the source of truth for dating-domain data, exact locations are not exposed, analytics are pseudonymous, and Redis is not the permanent source of truth for messages.