Privacy Policy — Birge
Last updated: 04.11.2026 · Personal data operator: Abat Kassymov, Republic of Kazakhstan · Contact: support@birgeapp.com · Address of this policy: https://birgeapp.com/en/privacy
1. Who we are and what this document covers
Birge is a mobile application for finding flatmates, housing and teams in Kazakhstan. This policy describes which personal data we collect, why, to whom we transfer it and how you can manage it — both about the users of the application and about the authors of the listings that Birge itself posts (section 3). By using the application, you accept this policy.
2. Which data we collect
You provide it yourself:
- Sign-in through Apple or Google — the account identifier at the provider and what it shared (name, email, if you allowed it).
- Phone (E.164) — optional. You may type it into your profile without confirmation: it prefills your listings as the contact to reach you, helps find a listing with the same number that Birge itself posts (section 3), and never shows on the card. Confirmation by a code (Telegram, WhatsApp or SMS) comes once we switch a delivery channel on; it is what trust between users and sign-in recovery need.
- Profile: name, year of birth (for the age; we do not ask for the exact date), gender, a short "about me", occupation, interface language.
- City and search district, free-text district, and — if you draw an area on the map — an approximate polygon/radius of the search.
- Preferences: budget, lifestyle (sleep, cleanliness, smoking, diet, etc.), interests, answers to prompts, the preferred gender of a flatmate, situation (have housing / looking / assembling a team).
- Photos: of the profile, of your flat and of listings.
- Verification materials (optional) — a photo of a government-issued identity document and two selfies with gestures; in detail in section 4. They are not shown in the profile or in the gallery.
- Listings, flats, teams that you publish — including the phone or Telegram for contact, if you gave them in a listing: signed-in users who open the contact see them.
Arises during use:
- Swipes, mutual likes, chat messages, applies to listings, those who liked you.
- Contacts that you opened in listings and at people that Birge itself posts (section 3): we remember that you opened the contact — it counts towards the daily apply limit.
- Reports and blocks that you send or receive.
- Sessions and devices: session tokens, a device label, the time of the last sign-in — for security and for signing out of all devices.
- Service counters: daily limits of swipes, likes and applies.
- Usage events (analytics): which screens and steps you open, openings of the Birge+ screen, taps on notifications, as well as the facts the server sees (registration, phone confirmation, swipe, connect, first message and reply, publication, apply, purchase). Without texts, name, phone or coordinates; under a pseudonymous identifier, not your id. To turn analytics off for your account, write to support@birgeapp.com: the mark is stored in the account and stops both the application's events and the server's events.
- Device data: model, OS version, application version and build.
- Crash reports: the error stack, the state of the application at the moment of the crash, the same pseudonymous identifier. Without screenshots, screen recordings, request bodies or phones.
- Push notifications. The device token; the notifications "New people in the city" and "Likes are available again" are on by default, each has its own switch in the application's settings; all push notifications can also be turned off in the system settings.
We do NOT store the precise geolocation of the device: if you allow geolocation, the application determines your city from it once, and our server does not write these coordinates to your profile. The map point — the one you place on the map, or the one found by the device's location when you tap "Where am I" on the map — is sent to OpenStreetMap Nominatim to find the city and the address (section 7); it is sent without your identifier. We do not read the phone book contacts, do not collect advertising identifiers (IDFA/AAID) and do not record the screen. The application does not show advertising and does not use cross-site tracking.
Payment data (when buying a Birge+ pass or the "Top" promotion of a listing) is processed by Apple, Google and RevenueCat — we do not see the card number, only the fact of the purchase, the product, the pass's term and the refund, if there was one. RevenueCat receives your Birge account identifier at sign-in — so a purchase interrupted halfway finds its account — and the purchase data at the moment of purchase.
3. Listings and cards that Birge itself posts
Some of the listings in the feed and some of the cards of people at the end of the "Search" section are posted by Birge itself. Such a listing contains what its author stated, including the author's contact. We do not contact the authors ourselves: we do not write to them and do not send messages or SMS to their numbers. These are two kinds of records.
3.1. Listings in the feed. A "renting out" listing: price, address or district, housing parameters, photos (stored in our storage) and the author's contact (phone or messenger).
- The author's contact is not shown on the card: it is opened by tapping "Apply" and counts towards the daily apply limit.
- The listing is shown for 7 days from the moment of publication (a repeated publication extends the term), then it is hidden; the record and the photos are deleted 30 days after that.
- If the author registers in the application with the same number, we offer them to take such a listing: it becomes their own.
3.2. People looking for housing or a flatmate. A "looking for a room / a flatmate" listing with the author's phone is shown by Birge as a card at the end of the "Search" section.
- The card shows only what the author stated: gender, age (only if stated and the author is 18 or older), occupation, educational institution, district, budget, move-in date. Without the name, photo or the text of the listing.
- We do not post listings of minors.
- When a user likes such a card, they see the contact the author left (phone or messenger). This counts towards their daily like and apply limits. We send nothing to the author.
- The like waits for the author. If the author later registers in the application with this number, the waiting likes become ordinary likes, and the author sees them.
- For the card we store: the author's number and contact, the fields listed above and the name, if the author stated it (it is not shown on the card).
- The card is shown for 7 days from the moment of publication. The record with the contact is kept for up to 30 more days after that — only so that a waiting like reaches the author if they register — then it is deleted.
- We process the author's data for the purpose for which they stated it in the listing — so that tenants or flatmates can find them — and for no other. The author may remove the listing at any time (section 3.4).
3.3. The listing text and the AI model provider. The text of such a listing and the fields filled in from it are stored for 30 days, then deleted. Of a listing a moderator took down for a violation, only a contact-free fingerprint (a checksum and the set of words) remains after that, so that a copy of it does not come back. To fill in the fields of a listing or a card, the listing text is processed by an AI model provider, Anthropic, PBC (USA). Before sending, we replace the phones, messenger account names and profile links in the text with stand-ins and send no photos — the provider does not receive the author's contacts. The author's name, if it is in the text, stays. This is a cross-border transfer, see section 7.
3.4. How to remove yourself. If you are the author of such a listing and want it to disappear:
- register with the number from the listing — the card disappears by itself, only your profile remains, which you control;
- or write to support@birgeapp.com — state the number from the listing.
After the request, a moderator immediately hides the listing or the card. The author's number is put on an exclusion list (kept without a time limit, otherwise the listing would appear again), and their listings are no longer posted. We reply within 3 working days.
4. Identity verification (optional)
Verification gives the "Identity verified" mark and is not mandatory. To receive the mark, you send:
- a photo of a government-issued identity document (identity card, passport or another government document) — the side with the photo and the full name;
- two selfies with gestures that the server picks and shows you before shooting.
If you have already passed a check with a document, and after that the mark was removed by a new photo, the repeated check is only two selfies, without a document.
What is on the document. The document may bear an individual identification number (IIN). We do not extract it from the image, do not store it as data and do not use it for anything: the moderator merely sees the image as a whole.
Who sees it. Only a moderator. They compare the face on the document and on the selfies with the photos of your profile, and the name and year of birth on the document with the profile. Every opening of an image is recorded in the audit log. The decision (approve or reject) is made by a human; we have no automatic recognition of faces or documents.
Where it is stored. In a closed storage that has no public link: the images are not given to the application and are not shown to other users. The storage is on our server in Kazakhstan.
When it is deleted. The images (three; on a repeated check — two) are erased at the moment of the decision (both on approval and on rejection), on account deletion and — if the request has not been reviewed — no later than 14 days. Only the record of the decision (status, time, reason for rejection), the mark of your consent (time and version of the text) and the date when the document was compared with the profile (it is needed so that a repeated check does not ask for the document again) remain; on account deletion all of this is deleted.
Consent. By sending the materials, you consent to their processing for the check. The time of the consent and the version of its text are recorded on sending. The consent can be withdrawn: the images are already erased after the decision, and if the request is still under review, delete the account or write to support@birgeapp.com.
The mark and the photos. The mark means that the person in the profile photo is the one who passed the check. Therefore a new photo in the profile removes the mark; the application warns about this before saving. To get it back — two new selfies with gestures, the document is not needed again. Deleting photos and changing their order do not remove the mark. If the mark is removed manually by a moderator, the next check is with a document again.
5. Staff access to correspondence
The chat between users is not protected by end-to-end encryption: messages are stored on our server. Staff may read them only in the following cases:
- the administrator (the owner of the service) — any chat, stating a reason;
- a moderator — only a chat that has been reported.
Staff read the correspondence but do not write into it and do not change it. Every opening of a chat is recorded in the audit log (who, when, which chat, the reason) before the messages are shown. The content of messages is not checked automatically; there is only a limit on the sending rate.
When you send a report about a message or a chat, we keep a copy of the chat's latest messages as evidence. It remains even after the chat or the account is deleted — otherwise deletion would become a way to erase evidence of violations.
6. Why we process data
- Matching flatmates / housing / teams (the main function) — the swipe deck and the feed.
- Showing the listings and people that Birge itself posts, so that there is something to choose from in the feed and in the search (section 3).
- Identity confirmation by phone (optional) and by a document and selfies (optional) — trust and safety.
- Chat between matched users.
- Moderation: reports, blocks, bans — compliance with the app stores' requirements and protection of users.
- Account security and prevention of abuse.
- Sale and accounting of Birge+ passes and listing promotion ("Top").
- Analytics and improvement of the service: registration and publication funnels, retention, the work of the matching algorithm — by pseudonymous events (turned off on request to support@birgeapp.com).
- Diagnostics of crashes and errors of the application, the server and the moderation panel.
7. To whom we transfer data (processors)
We do not sell personal data. We engage processors only for the operation of the service:
| Processor | Purpose | What it receives |
|---|---|---|
| An SMS operator, Telegram or WhatsApp (Meta) | code delivery for confirming the number; confirming the number through Telegram | phone, code |
| Apple / Google / RevenueCat | sign-in through Apple and Google; purchases of Birge+ passes and "Top" in the App Store and Google Play | the account identifier at the provider; the account identifier in Birge, the purchase identifier, its status |
| Anthropic, PBC (USA) — AI model provider | automatic processing of the text of the listings that Birge itself posts (section 3.3) | the listing text with phones, account names and profile links replaced by stand-ins; the author's name if it is in the text; no photos |
| OpenStreetMap Nominatim (OpenStreetMap Foundation, United Kingdom) | geocoding of listing addresses; finding the city and the address for a map point | the address strings of listings; the coordinates of a map point (including the one found by the device's location after "Where am I" on the map), without a user identifier |
| Hosting provider of our server (Kazakhstan) | the server that runs the database, the photo storage and the closed storage of verification materials | provides computing capacity; we process the data ourselves |
| Google (Maps SDK) | the map in the application | standard tile requests: IP address, map area |
| Google Firebase (Firebase Cloud Messaging); Apple (APNs) | push notifications: on Android through Firebase Cloud Messaging, on iOS through the Apple Push Notification service, which the message also reaches through Firebase; verification of the application's authenticity (App Check) | the device token for push; the notification text (a title and a body of up to 180 characters, for example the sender's name and the start of a chat message); the App Check token |
| Cloudflare Turnstile | protection of sign-in from bots when the application check is unavailable | technical information of the browser check |
| PostHog Inc. (EU Cloud, Frankfurt, Germany) | product analytics | the pseudonymous identifier, usage events, device model, OS, application version; from the profile — language, city, gender, occupation |
| Functional Software Inc. — Sentry (EU region, Germany) | diagnostics of crashes and errors | the pseudonymous identifier, the error stack, device model, OS, application version |
Transfer abroad. PostHog and Sentry store data in the EU (Germany) — a country that ensures the protection of personal data. This is a cross-border transfer; we transfer only the pseudonymous data from the list above, under data processing agreements (DPA) with these processors, and by accepting this policy you agree to it. The IP address is not stored in analytics.
Google (Firebase Cloud Messaging) and Apple (APNs) deliver push notifications: the device token and the notification text pass through their servers, including outside Kazakhstan. OpenStreetMap Nominatim operates in the United Kingdom: it receives the address strings of listings and the coordinates of a map point, without a user identifier. This is also a cross-border transfer, and by accepting this policy you agree to it.
Anthropic processes the listing text in the USA; this is also a cross-border transfer — of the data of the listings' authors, not of the application's users. The author's contacts do not enter the transferred text (section 3.3). Under the contract, the provider does not use the transferred text to train its models.
8. Retention and deletion
| What | Term |
|---|---|
| Account data | while the account exists |
| A listing that Birge itself posts | shown for 7 days from the moment of publication (a repeat extends it), then hidden; the record and the photos are deleted 30 days after that |
| A person's card that Birge itself posts | the card — 7 days from the moment of publication; the record with the contact — up to 30 days after that, then deleted (earlier — if the author registered with this number or asked to remove themselves) |
| The text of the listings that Birge itself posts and the fields filled in from it | 30 days, then deleted; of a listing a moderator took down, a contact-free fingerprint (a checksum and the set of words) remains — with no term, so that a copy of it does not come back |
| Exclusion list (numbers of authors who asked to remove a listing) | without a time limit |
| The document photo and two verification selfies | erased at the moment of the decision; on account deletion; without a decision — no later than 14 days |
| The record of the verification decision and of the consent (time and version of the text); the date of the document comparison | while the account exists; the date of the document comparison is also erased when a moderator removes the mark |
| Reports and the copy of the chat's latest messages as evidence | until the report is decided and 1 year after that; survive the deletion of the chat and the account |
| The moderation and audit action log | 2 years |
| Purchase records (ours and RevenueCat's) | at least 5 years — the retention term of accounting documents under the legislation of the Republic of Kazakhstan; after account deletion they are marked as voided |
| Expired sign-in codes | deleted automatically |
| The log of sent sign-in codes (number, time) — protection against guessing and spam | 24 hours |
| The carry-over of a deleted account's sanctions to its number and Apple/Google sign-ins (a hash of the number or identifier; the ban, the suspension, the rest of the day's limits) | 30 days; without a time limit when banned |
| Analytics (PostHog) | 12 months; the events go under a pseudonymous identifier derived from the account's number and not stored at PostHog next to it; after account deletion we link them to no one, and on request to support@birgeapp.com we delete them at PostHog |
| Crash reports (Sentry) | 90 days |
| Geocoder cache: map point → city and address (no user identifier) | 90 days, then deleted automatically |
Account deletion from the application (Profile → Delete account). We anonymise the account: the name and other identifying fields are erased, the phone is released (a banned account's number and Apple/Google sign-ins stay on the block list), sessions are revoked, the Apple/Google links, push tokens, notifications and saved searches are deleted, as are your listings, flats, photos, swipes, likes, applies, blocks and verification materials. What remains:
- the correspondence at the other party — without your name ("Deleted user"), including the messages you wrote to them;
- reports with the copy of messages as evidence;
- purchase records (voided) and the moderation action log.
Blocking. When you block a person, the personal chat between you is closed and deleted for both; likewise the chat between the person and a team is closed if the block is between them and one of its members. The chat of a team in which you both are members keeps working.
Data export: you can request an export of everything you created in the account.
9. Your rights
You have the right to: access your data, correct it in the profile, delete the account, export the data, withdraw consent (by deleting the account), turn analytics off (on request to support@birgeapp.com — both the application's events and the server's events stop being sent; crash reports continue to be sent — without them we cannot fix the application). If you are the author of a listing that Birge itself posts (section 3), you have the right to demand its deletion — the ways are given in section 3.4. Requests about rights and about the deletion of someone else's content: support@birgeapp.com, a reply within 3 working days.
10. Children
The application is not intended for persons under 18. We do not collect data of known minors — neither among users nor among the authors of listings.
11. Security
Traffic encryption (TLS), session tokens with a limited term, secrets stored outside the code, a rate limit on chat messages, a closed storage without a public link for verification materials, a log of staff access. There is no absolute guarantee of security on the internet.
12. Changes
We may update the policy; material changes are announced in the application. The date in the header reflects the latest revision.
13. Contacts
Abat Kassymov, Republic of Kazakhstan · support@birgeapp.com