Tamil MeetLAW ENFORCEMENT INFORMATION AND GUIDELINES
Last updated: September 16, 2026
1. Who this page is for
This page is for judicial authorities and investigative services seeking information about a Tamil-Meet account. Tamil-Meet is the dating application published by SASU RCM Consulting. The page explains how to reach us, what a request must contain, and which data actually exists, and for how long. It is not a channel for users. If you are a Tamil-Meet user, write to us at contact@tamil-meet.com or use the website's contact form. For anything involving a minor, see our Child Safety Standards. This is an operational document describing our practices; it is not legal advice.
2. Who operates the service
Tamil-Meet is published by: SASU RCM Consulting 13 rue Giuseppe Verdi - 77185 Lognes, FRANCE SIREN: 933 740 136 Email: contact@tamil-meet.com The company is established in France. It is the data controller, within the meaning of the GDPR, for the data of Tamil-Meet users.
3. How to reach us
Every request must be sent to us in writing, by email, to contact@tamil-meet.com, from an official address of the requesting service. This is the address published in our legal notice: there is no dedicated address, portal or form reserved for authorities. State in the subject line that the message is a request from an authority and, where applicable, that it is urgent (section 8). A request may also be sent by post to the registered office above; email remains the fastest route. Tamil-Meet is published by a one-person company. Requests are read and handled one at a time by the company's director, and we reply by email. We do not publish a response time.
4. Required framework
We disclose a user's data to an authority only on the basis of a request that obliges or authorises us to do so under French law, and never on an informal request. • French authorities: a judicial requisition (réquisition judiciaire), a letter rogatory (commission rogatoire) or any other request made by a competent authority within the framework provided by French law. The request must identify the requesting authority, the proceedings concerned and the basis on which it rests. • Foreign authorities: an authority located outside France proceeds through the channels of international mutual legal assistance, or through a competent French authority, which then sends us the request. We do not respond directly to a request from a foreign authority. We do not assess the merits of proceedings: we check that the request reaches us within this framework and that it is precise enough to be carried out (section 5).
5. What a request must contain
To be actionable, a request must state: • the account concerned, in a form we can look up: the account's email address or the username (pseudonym) displayed in the app. The service does not collect legal names and does not ask for a phone number, so a name, a number or a photo generally cannot identify an account; • the period concerned; • the precise nature of the data requested: registration data, profile, photos, messages exchanged with a given account, reports, etc.; • the requesting service, the name and contact details of the officer in charge, the case reference and the basis of the request. A request that is too vague, or that does not designate a specific account, cannot be processed: we will ask for details before any search.
6. What data may exist, and for how long
The retention periods below describe what the service actually does as of the date at the top of this page, not target periods. Data may therefore no longer exist when a request arrives, in particular if the account has been deleted. • Account: email address (verified at signup), dates of creation, last login and last activity, account state (active, suspended, deletion requested). Kept as long as the account exists. The password is stored only as a hash and cannot be disclosed. • Profile: username, date of birth, gender and gender sought, country of origin, city and country of residence, last known position (GPS coordinates if the user allowed geolocation, otherwise the centre of the declared city), height, build, languages spoken, interests, bio and other optional fields, app language, profile visibility. Kept as long as the account exists. We keep only the latest value of each field: there is no history of positions and no history of profile edits. • Photos: each photo, in its clear and blurred versions, its upload date and the result of automated moderation. A photo rejected by moderation remains stored until the user deletes it. A photo deleted by the user is removed from our storage immediately; the photos of a deleted account are removed when the account is purged (see below). • Messages: for each conversation between two accounts, the content of each message, its sender, its send date and its read date. Kept as long as the conversation exists. A user who deletes a conversation only removes it from their own list: the messages stay in the database and remain visible to the other participant. When an account is deleted, its messages are not erased: they remain in the conversation for the other participant, but are no longer attached to a sender. • Photo access requests: who asked to see whose clear photos, the answer and its dates. Kept as long as both accounts exist; a rejected or revoked request is replaced by the next one. • Profile views: who viewed which profile and when, at most once per viewer, per profile and per 24 hours. Kept as long as both accounts exist. • Blocks: who blocked whom and when. Kept as long as both accounts exist and the block has not been lifted. • Reports: who reported whom, the reason chosen, the free-text description, the processing status, the team's notes and the dates. Kept indefinitely. When an account is deleted, the reports it made or received are kept, but are no longer attached to that account. • Subscription: plan, status, start, expiry and cancellation dates, purchase platform (App Store, Google Play or Stripe) and the transaction identifier assigned by that platform. Kept as long as the account exists. We hold no banking or billing data: payment is processed by Apple, Google or Stripe, which hold that data. The technical notifications those platforms send us (webhook logs) are kept indefinitely and designate a transaction, not an account. • Notifications: the notifications received in the app, as long as the user does not clear them and the account exists; and the technical tokens used to deliver a notification to a device or a browser, deleted at logout and, in any case, when the device stops re-registering. • Saved searches and notification preferences: the search filters the user has named and their notification settings. Kept as long as the account exists. • Email verification codes: a code can no longer be used 15 minutes after it is sent, but the corresponding record (email address, code, dates) is only deleted with the account. The same holds for password reset codes, which are never deleted at all, even when the account is deleted. • IP addresses and connection logs: the application does not record its users' IP addresses. The server records, at each login and each session renewal, a dated row (session creation and expiry dates), without any IP address. These rows are never purged and are not deleted with the account. The server writes technical request logs, collected by our hosting provider; they are not attached to an account and their retention depends on the hosting provider, not on us. We cannot guarantee that they are available or usable. • Account deletion: when a user requests deletion of their account, the account is deactivated immediately and the user has 30 days to cancel. After that period, the account, profile, photos, subscription, blocks, notifications and photo access requests are erased, and the signup verification codes tied to the email address are deleted. What remains: the messages and reports, detached from the account as described above; the session records and the password reset codes; the deletion request itself (reason chosen, optional comment, dates), no longer attached to the account; and an anonymous record of the deletion (technical identifier, reason, date), erased after one year. We have no means of intercepting or monitoring conversations in real time.
7. Preservation requests
We have no mechanism to freeze an account's data at an authority's request. A user can at any time delete their photos, hide a conversation or request deletion of their account, with the effects described in section 6. A preservation request must be sent to us in writing, to the same address, designating the account and the data concerned. It will be handled within the technical means available to us, without our being able to commit to a timeframe, or to the preservation of data already deleted when the request reaches us. Disclosure of the preserved data remains subject to the framework described in section 4.
8. Emergency: imminent danger to a person
In case of imminent danger to a person's life or physical integrity, write to contact@tamil-meet.com with "URGENT" in the subject line, the account concerned and the nature of the danger. We handle these messages before any other request. We have no on-call duty and no telephone line: Tamil-Meet is published by a one-person company, and we cannot guarantee how quickly a message is read. This page is no substitute for the emergency services. Where the danger concerns a minor, also write to child-safety@tamil-meet.com, the point of contact described in our Child Safety Standards.
9. Notifying the user concerned
A user whose data is the subject of a request from an authority is informed of it, except in two cases: where the law prohibits us from doing so, and where informing them would endanger a person's life or physical integrity. The notice is sent to the account's email address. If you consider that the user must not be informed, say so in your request, stating which of these two cases applies.