You submit a government-issued ID and complete a short live facial scan. Didit analyses these — including biometric facial data and liveness signals — to confirm the document is valid and that you are the person it belongs to, then returns a decision and a limited set of identity attributes to Reech.

The facial scan is biometric data used to uniquely identify you. We request your explicit consent before verification begins. We and Didit use it solely to verify your identity and prevent fraudulent, duplicate or fake accounts — never for advertising or profiling unrelated to verification — and we do not sell it.

Reech receives a decision and a narrow set of attributes from Didit. Specifically, Reech stores:

• your verification status (verified, declined, awaiting resubmission, or pending);
• the legal name shown on your document, which becomes your public display name, together with the individual name components so that you can choose which of them is displayed;
• your date of birth, used to confirm you are over 18 and as an input to matching; and
• the sex marker on your document — and only where you have not stated a gender yourself. If you have stated one, including "prefer not to say", the document is ignored and your own answer stands; and
• an identity anchor, which Reech derives rather than receives: a one-way keyed hash computed from your verified name and date of birth. It cannot be reversed to recover either of them. It lets Reech recognise the same person across accounts, and it is used for three things: to recognise a second attempt to verify the same person and refuse it, so that one person cannot hold two accounts; to check a person who is verifying against a list of people who have been banned, and refuse them if they are on it; and to link rejected credential submissions (Section 6), reports (Section 7) and declined verifications (below) to the person, not only to an account.

Reech does not store images of your identity document, your facial image, any biometric template, your document number, or your nationality. Those are held by Didit under Didit's own privacy policy and retention schedule, and Reech has no copy of them.

Your verification status, name components and date of birth are stored on a private, owner-readable record. Only your display name and your verified status are visible to other users.

Your ID images and facial scan are deleted after 30 days. The identity document images, facial images and liveness captures are held by Didit, not by Reech. Reech has configured Didit to retain them for 30 days from your verification, after which they are deleted. We keep them for that short window only so that a failed or disputed verification can be reviewed; they serve no purpose after that and are not used for any other reason. You can also ask us to delete your verification session sooner by contacting privacy@reechnetworks.com, and we will instruct Didit to do so.

The face template Didit keeps. When the images are deleted, Didit keeps one image-free face template: a set of numbers describing your face, from which no image can be rebuilt. It remains biometric data. It is used for two things only: to recognise the same face in a new verification and stop one person from holding two Reech accounts, and, if you ask to change your name with a new identity check, to confirm that the new check is you. It is never used for advertising, never sold, and never shown to anyone. It is deleted when you delete your account, and in any case 3 years after the verification it came from, whichever is first. Reech never receives it.

What Reech keeps for longer. The verification status, your verified name and its component parts, and your date of birth are held by Reech for as long as your account exists, and are deleted when you delete it. These are text attributes. No image and no biometric data is included. Their purpose — confirming you are a real adult, and that one person holds one account — is served only while the account is there to check, so none of them outlives it.

The identity anchor is the one exception. For most people it is deleted with the account as well. It is kept after the account is deleted in three cases: if you are banned, when it is placed on a banned list so that verification can be refused if the same person tries to verify again; if, when you delete your account, you have a record — a rejected credential submission, a credential submission still awaiting review, a recorded decline of your own verification, or a report against you that is pending or was acted on — when it stays attached to that record; and if a record of someone else's declined verification names your account, when it stays on that record. Sections 6, 7 and 11 and the paragraph below describe these cases. In every case, your name and date of birth are still deleted with the account; what remains is the anchor, which cannot be reversed to recover them.

A declined verification can leave a record. Reech keeps a record of a verification in three cases: when it is declined after a person at Reech has reviewed it; when it is refused because the same identity is already verified on another Reech account; and when it is refused because that identity has been banned. The record holds the account, a pseudonymised identity reference, the reason for the decline, the verification session it belongs to, and when it happened. The identity reference is a one-way keyed hash of the name and date of birth on the document, computed in the same way as the identity anchor, and it cannot be reversed to recover either of them. Where the decline followed a face-similarity check, in which Didit compares the face in a new verification with the faces in earlier ones, the record also names the account the face was matched to, with that account's identity anchor and the similarity score. Where the refusal was because the identity is already on Reech or has been banned, the record names that account instead. The record never contains a name, a date of birth, a document, a document number or an image, whether of you or of anyone it names. A decline that no one reviewed, such as an unreadable photo, leaves no record, and neither does a refusal because a person is under 18. The record is kept after account deletion, both yours and that of any account it names, for as long as it is needed to prevent duplicate and banned accounts, like the other integrity records in Section 11. It is not visible in the app.

Didit also states that its retention of biometric data is in every case capped by applicable biometric-privacy law — including the EU General Data Protection Regulation, the Illinois Biometric Information Privacy Act, the Texas Capture or Use of Biometric Identifier Act and Washington H.B. 1493 — and that where such a law requires a shorter period or earlier destruction, the stricter rule prevails.

Adding or changing the first name you go by needs no check. Choosing different parts of the name on your ID, or a spelling we can match to your ID, applies at once. Any other change to your verified name is a request we review, with a reason you choose (a corrected spelling, a changed last name, a legal name change, or another reason with a short note). For a changed last name or a legal name change, you complete a new identity check with Didit on an ID that carries the new name: we confirm that its date of birth matches the one on file, and Didit compares the new face scan with your face template to confirm it is you. For another reason, we may ask you to complete that check too. The new check is handled exactly as above, and its own images and template follow the same periods. If we approve, the new name replaces your display name.

Didit's processing is described in its privacy policy at didit.me/terms/privacy-policy. Didit's lead supervisory authority is the Spanish Data Protection Agency (AEPD). Where Didit acts as our processor, direct your requests to us at privacy@reechnetworks.com rather than to Didit.

Identity verification confirms, on a reasonable-effort basis, that a real person holds a valid ID and matches it. It is not a background check and does not verify your Credentials, character or conduct.

If a Reech reviewer rejects a document you submitted, Reech keeps a record of that rejection: your account ID, the date, the Credential type and the details you claimed (for example degree, field and institution), and the reason. There are four reasons: the document had expired; it could not be read; the name on it does not match your verified name; or it does not support the Credential claimed. Each entry also carries your identity anchor (Section 5). The document itself is not part of the record, and it is still deleted on the terms in (c) above. No name and no date of birth is stored in the record, only the anchor.

Warnings are automated and change nothing about your account. Only two of the four reasons count: the name does not match, and the document does not support the claim. When you reach three of those in total, or two against the same Credential claim (the same type with the same claimed details), you receive a warning notification in place of the usual rejection notice. A warning has no effect on your account.

A ban is decided by a person. At four of those rejections in total, or three against the same claim, you are placed in an internal review queue, and a Reech reviewer decides whether to ban you or to clear you. Nobody is banned automatically. A reviewer can also add someone to that queue by hand, for example after a report.

Rejections are counted per person, not per account. Entries are matched by identity anchor, so rejections on an earlier account that has since been deleted count on a new one. When you submit a new document, the reviewer is shown your earlier rejections, including any from a previous account.

You cannot see this record, or your count, in the app; Reech reviewers can. Your rights over it, and their limits, are set out in Sections 12–14. What a ban does, and how long the record is kept, are set out in Section 11.

When you submit a report we collect: your identity as the reporter; the user, group or content you are reporting; the category you select; a written note of up to 1,000 characters, if you choose to add one; and the time and technical details of the report.

You cannot attach your own screenshots, and you cannot choose which messages travel with a report. Reech assembles the evidence itself, in the same way every time. This is deliberate: an image supplied by a reporter cannot be verified against anything, and letting a reporter select which messages a reviewer sees is how a misleading report is built.

For a reported message, the evidence is:

• an extract of the conversation around the message you reported — up to 30 messages, each capped at 2,000 characters — taken from your device, together with a marker showing which message you reported. In a group conversation, only messages sent by you or by the person you reported carry their text; the rest appear with their text withheld;
• for each message in that extract, the details our servers hold independently of you: who sent it, when it was sent, whether its contents were encrypted, and whether it carried an attachment (and if so, whether it was a photo, a video, a document or a voice note); and
• where the reported message carried a photo, video, document or voice note, a copy of that file. Message contents are end-to-end encrypted, so your device is the only place the file exists in readable form — it is decrypted there and uploaded with the report. Without this, a report about an image would reach a reviewer as the word "photo" and nothing else. For a video, the copy is the clip itself, not the still frame the chat shows before it plays.

For a reported profile, the evidence is a snapshot of that user's public profile as it stood when you reported it — display name, bio, links, photos, Credentials and their verification status, work history and projects. Each of the profile's photos — the main photo and every other photo on it — is copied at that moment, not only linked.

For a reported connection request, the evidence is the request as it reached you: its message, when it was sent, and a copy of each photo or PDF attached to it.

For a reported group, the evidence is what our servers already hold about the group itself, recorded as it stood when you reported it: the group's name, how many members it had and which members were its admins, together with a copy of the group's photo as it was at that moment. No messages travel with a group report, and no file other than that photo — not the conversation, and not anything you sent yourself — because a group report is about the group, not about what any one member said. If a particular message is the problem, report that message, and the evidence described above applies. We also keep a record that you reported that group, which we use to count how many different people have reported it and so that invitations to rejoin it are not passed on to you.

Copies, not links. The photos and attachments named above are copied when the report is filed, because the originals can change or disappear: a profile or group photo can be replaced, and deleting or banning an account removes that user's photos and the files they attached to requests — which is often exactly when a report needs to be looked at again. Only the reported user's or group's own files are copied. Each copy is kept with its report, for as long as the report is kept, including after the reported user's account is deleted or banned. No user can see a copy; only Reech's reviewers can, and it goes no further except as described under "Confidentiality of reports" below. If a copy cannot be made, the report is still filed and holds a link to the file instead, which shows whatever that link leads to when it is opened, or nothing.

If you are reported, we collect the same information about the report made against you.

We use reports to review the reported user, group or content, investigate suspected violations of our Terms, and take action where appropriate — such as issuing a warning, removing content, limiting features, or suspending or banning an account. We may combine a report with other information (for example account, usage or verification signals) to assess it and to detect coordinated or repeated abuse. We rely on our legitimate interest in keeping the Service safe and preventing abuse, on performance of our contract with you to enforce our Terms, and on legal obligations where the law requires us to act on or report certain content.

A report has two parts, and we keep both. The record — who reported whom, the category selected, our decision and any action taken — and the evidence — the note you wrote; the conversation extract, profile snapshot, connection request or group snapshot; any copy of a reported photo, video, document or voice note; and the copies of a reported profile's photos, a reported request's attachments and a reported group's photo — are kept together, for as long as the report is needed to detect repeat and coordinated abuse, including after the reporter's or the reported user's account is deleted or banned. Deciding a report does not delete its evidence, and neither does leaving it undecided. That includes what a reporter's device decrypted: once a message is reported, the conversation extract and any copy of its photo, video, document or voice note are held by us in readable form for as long as the report is kept. We keep the evidence with the record because a record without it cannot be checked again. A decision may need to be revisited or appealed, and abuse patterns only become visible over time and across accounts: a single report says little, while a user who is repeatedly reported by unrelated people, or a person who files many reports against others, can only be shown to be one if the earlier reports, and what they contained, still exist. If the reported user is banned, or deletes their account while they have a record (Section 11), the reports about them are also tagged with their identity anchor (Section 5), so that they stay linked to the person and not only to an account that no longer exists. See the retention schedule in Section 11.

We generally do not tell a reported user who reported them. We may share the substance of a report — but not necessarily the reporter's identity — with the reported user so they can respond, and with the staff and service providers who help us review it. We may disclose reports to law enforcement or other authorities where we believe it is necessary to comply with law or to protect the safety of a person or the public (see Section 8). When you report a group, you leave it: the other members see the same notice they see when anyone leaves, so the group is not told that a report was made or by whom.

A report made about you is personal information we process about you. Your rights over it (Sections 12–14) may be limited where fulfilling a request would reveal the identity of a person who reported you, expose another person's information, or undermine an investigation or the safety purpose of the report. Submitting a false or bad-faith report is itself a violation of our Terms.

Your profile and Credentials are shown to other users according to Reech's visibility model. Visibility is directional, not mutual: whether another user can see or reach you is determined independently by whether their Credentials satisfy the Criteria you set — and the reverse is decided separately. Being able to see a user does not mean they can see you. Your ID images and biometric data are never shared with other users, and Reech does not hold them; only your verification status and your verified display name are shown. Reports are confidential and are handled as described in Section 7, not shown on profiles.

How suggestions work. Explore suggests people you can reach. Suggestions are built once a day from Credentials and profiles, from the requests you and similar users send, accept and decline, from how recently people use Reech, and from endorsements. How often you are suggested depends on whether you answer the requests you receive: answering, by accepting or declining, keeps you visible; requests left to expire mean you are suggested less. Whether you accept or decline never changes how often you are shown. People who joined in the last week can be suggested as new. The counts behind this are not shown in the app to anyone, you included; you can request them like any of your data, and they are kept for the life of your account.

We share information with vendors who process it on our behalf under contracts that require them to protect it and use it only for us. These currently are:

As of the date of this Policy, that table is the complete list of processors that receive your personal information. Reech integrates no advertising, attribution or install-referrer technology, and no analytics or crash-reporting provider other than the two Google services and the Cloudflare website counter named above.

We may disclose information to comply with law, respond to lawful requests, enforce our Terms, or protect the rights, safety and security of Reech, our users, or the public — including acting on reports of other users.

If Reech is involved in a merger, acquisition, financing or sale of assets, information may be transferred as part of that transaction, subject to this Policy.

Reech does not sell your personal information for money, and does not "share" it for cross-context behavioural advertising as those terms are defined under US state privacy laws. We do not sell or share your biometric or identity data. Reech deploys no advertising or attribution technology of any kind: no ad SDK, no ad network, no attribution or install-referrer SDK, and no advertising identifier. Reech does use two Google measurement services — crash reporting and app usage analytics, described in Section 16 — and the advertising-related signals those services are capable of carrying are switched off in the app's own code rather than by a setting, so they cannot be turned on by a configuration change. Nothing collected through them is used for advertising, sold, or shared for cross-context behavioural advertising. The same holds for the Cloudflare visit counter on our website, which has no advertising function.

Reech is established in Israel, which the European Commission recognises as providing an adequate level of data protection, so transfers from the EEA to Reech do not require additional safeguards. Because our hosting infrastructure is located in the United States, personal data is transferred onward from Reech to Google in the United States. That onward transfer is covered by the Standard Contractual Clauses in our agreement with Google; Google LLC is additionally certified under the EU–US Data Privacy Framework. Cloudflare, Inc., which provides the visit counter on our website, is certified under the same Framework, and its Data Processing Addendum incorporates the Standard Contractual Clauses.

The contents of your messages — text, photos, videos, documents and voice notes — are encrypted on your device and stay encrypted until they are opened on the device of the person you sent them to. What Reech stores is ciphertext. In the ordinary course we hold no readable copy of your messages and cannot produce one — not for ourselves, and not for anyone who asks us for it. There are exactly two routes by which readable content or the means to read it can exist outside your device, and both are described in this section: a report that you file, and the key backup that lets you keep your history when you change phones. What we can see about a message in every case is what our servers necessarily handle — who sent it, to whom, when it was sent, and whether it carried a photo, video, voice note or document.

A push notification about a message can show what it says, but not because anyone else can read it. The text, or a photo's or video's caption, travels to your phone still encrypted, and your phone decrypts it to display it: neither our server nor the Apple and Google services that deliver the notification can read it. If your phone cannot decrypt it, or the message is too long for a notification, the notification says only that a message arrived, or names the kind of attachment it carried. A notification about a voice note or document, or about a photo or video without a caption, names only its kind, never a file name. That label is written by our server and passes through Apple and Google readable, as the sender's name and a group's name do. Once your phone has shown a message in a notification, it is kept like any other notification on that phone; your phone's settings let you hide notification previews.

Reporting a message is the only route by which the contents of an encrypted message reach us. Because your device is the only place those contents can be read, reporting one causes your device to decrypt a bounded extract of the conversation and send it to us as evidence. Section 7 sets out exactly what that extract contains, what is left out of it, and that it is kept for as long as the report is. Nothing else in the Service moves message contents off your device in a form we can read.

If the key to your messages existed only on one device, reinstalling the app or moving to a new phone would leave your entire message history permanently unreadable. So a copy of that key is stored with your account, wrapped under your account password. The wrapping key is derived from that password on your device; what reaches our servers is ciphertext, and Reech never stores your password in any form. That has one consequence we would rather state than leave you to infer. You sign in to Reech with your user ID and password. The password is sent to a Reech server, which checks it against Google's authentication service without storing it — a design that exists so that your email address is never disclosed to anyone who knows your user ID. If you created your account on our website, your password also reached a Reech server then, to set the account up. So the password that protects your key backup passes through our systems each time you sign in.

You can close that gap yourself. Creating a recovery code produces a second wrapped copy of the key, sealed with a code generated on your device that we never receive in any form, and lets you remove the password-wrapped copy. Once you have done that, no secret we ever receive can open your key backup. The app shows you which of these two states your account is currently in.

You can delete your account at any time from within the app (Settings), or by contacting privacy@reechnetworks.com. When you delete your account we delete or de-identify your personal information on the schedule above, except for limited data we may retain for fraud prevention, safety, dispute resolution, or as required by law — which may include reports and records of enforcement action.

If you have a record when you delete your account. You have a record if, at the moment you delete your account, you have any credential rejection, a credential submission still awaiting review, a recorded decline of your verification, or a report against you that is pending or was acted on. In that case: your credential rejection record and any record of a declined verification are kept; any submission still awaiting review is kept as an entry, showing only its Credential type and claimed details, with no document and no reason; and the reports against you are tagged with your identity anchor, which is kept with those records. Everything else, including your name and date of birth, is deleted on the schedule above. If you have no record, your identity anchor is deleted with your account, and nothing that remains is linked to you by it, unless a record of someone else's declined verification names your account (Section 5): your anchor then stays on that record.

If you are banned. You receive a push notification. Your account is then deleted exactly as if you had deleted it yourself, except that:

• messages you already sent stay with the people you sent them to, as they do on any deletion;
• reports about you are kept, as they are on any deletion, together with any copies of your photos or request attachments they hold, and are tagged with your identity anchor;
• your credential rejection record, and any record of a declined verification, are kept; and
• your identity anchor is placed on a banned list.

If anyone later verifies with a name and date of birth that produce that anchor, verification is refused, with a message saying that they have been banned and an address to appeal to: support@reechnetworks.com. The appeal exists because two different people can share a name and a date of birth.

The app uses two Google services and no others: Firebase Crashlytics, for crash and diagnostic reports, and Google Analytics for Firebase, for a deliberately narrow record of which screens are opened. Those two are the whole list: there is no advertising SDK, no attribution or install-referrer SDK, and no analytics or crash-reporting provider other than the two named here. What each one collects is set out in the table in Section 3; how long it is kept is in Section 11.

What the app is able to send is fixed in its code, not left to a settings screen. Analytics can be given the names of six screens — the four main tabs, plus the chat and group-chat screens the app opens when you tap a notification — and no others; every remaining screen in the app is unnamed, and an unnamed screen cannot be recorded. There is no general-purpose event call in the app at all, which is what makes it impossible for a message, a profile field, a Reech ID, a phone number or a contact hash to be attached to an analytics event, by mistake or otherwise. Crash reports are held to the same rule: the app never sets a user identifier on one.

Both switches are in Settings → Privacy & Security → Diagnostics. Each drives the underlying service's own collection flag, so switching one off stops collection at the source rather than merely stopping the app from asking.

The setting belongs to the device, not to your account. Collection is a property of an installed app, so the choice is stored on that device and does not follow you to a second phone. Sign in somewhere new and that install starts from the default for its own region.

How the default region is decided. The app reads the country in your device's own language-and-region setting. It does not use your network address, and it does not ask your device for your location. If that setting reports no country at all, the app treats the device as if it were in the EEA — an unknown region gets the stricter default, because the safe direction to be wrong in is the one that collects less.

Advertising signals are off in the code, not in a setting. Google's measurement services can carry three advertising-related consent signals. All three are set to denied by the app itself on every launch and every change, so there is no configuration in which they can be granted. That is what allows the statements in Sections 8.5 and 13 to be made flatly.

Test builds report nothing. Neither service is started in a development build of the app, so our own testing does not appear in either dashboard.

If we introduce any other analytics, advertising, attribution or crash-reporting technology, we will update this Policy, and where consent is required we will obtain it and provide controls to manage it before doing so.

reechnetworks.com counts its visits with Cloudflare Web Analytics. For each counted page view it records the page, the website that linked to it, the browser, operating system and device type, the country, and how long the page took to load. Cloudflare states that the counter uses no cookies or other storage on your device, and does not follow visitors over time by network address, browser details or any other fingerprinting technique. Reech sees counts — visits per page, per country, per referring site — and nothing that identifies a visitor. How long Cloudflare keeps this is in Section 11.

When it does not run. The page decides in your browser, before the counter is loaded, and loads nothing from Cloudflare if any of these is true:

• your browser's time zone is a European time zone, or that of an EEA territory outside Europe such as Cyprus, the Canary Islands or Réunion;
• your browser reports no usable time zone, or only UTC — an unknown region is treated as Europe, because the safe direction to be wrong in is the one that collects less;
• any language in your browser's settings names a country in the EEA, the UK or Switzerland, such as English (United Kingdom);
• your browser sends a Global Privacy Control or Do Not Track signal; or
• the page is not being served from reechnetworks.com, so our own previews and testing are not counted.

The time zone and language are read on your device for this check and are not sent anywhere by it. As in the app, the region comes from your own settings, not from your network address. That is also why the website shows no consent banner: in the places where a measurement script would need your consent first, this one does not run. There is no switch on the website, because a privacy signal from your browser does the same job on every visit without us storing a preference.