Privacy policy

Who is responsible

This policy covers the JFS mobile app (Android package and iOS bundle jamiat.iqbal.jfs) and this website, jfs.jamiat.org.pk. It is the privacy policy URL for the Google Play and Apple App Store listings.

The records belong to Islami Jamiat Talaba Pakistan, which decides who inside the organisation may see them. On Google Play the app is published by the developer Muhammad Iqbal, on behalf of Islami Jamiat Talaba Pakistan. On the App Store it is published by the developer team IDARA MATBUAT E TALABA (PRIVATE) LIMITED, also on behalf of Islami Jamiat Talaba Pakistan.

Two kinds of people appear in the system. Members are the office bearers who hold an account and enter records. Donors do not have accounts; a member types their details so a receipt can be issued.

Contact for privacy requests: jfs@jamiat.org.pk
Muhammad Iqbal, publishing on Google Play on behalf of Islami Jamiat Talaba Pakistan
1-A Zaildar Road, Ichra, Lahore, Pakistan

Accounts are issued, not opened

There is no public sign-up and no in-app purchase. An account exists only because a Nazim sent an invitation to a specific email address, naming the unit and the role. Accepting that invitation creates the account. This website cannot create, change or read an account.

What is collected, and why

Nothing below is collected for advertising, for tracking you across other apps or websites, or for building a marketing profile. The categories match the groups Google Play’s Data safety form and Apple’s App Privacy label use. Every item is linked to the member or the donor it belongs to, except the ordinary web-server log of a visit to this website, which is not tied to a JFS account.

Name, email address, phone number, and address

Why. A member’s name and email address are the account. The email is the sign-in identifier and the address invitations, password-reset codes, and account-closure emails are sent to. A phone number is optional on the member’s profile. A donor’s name, and any phone, email, profession, location, or postal address a member chooses to record, exist so the unit can issue a receipt and, only if a member deliberately turns it on, send a payment reminder. That reminder defaults to off. A donor’s email is otherwise used to send the receipt itself.

Who else sees it. The organisation’s database and, when an email is actually sent, the email provider. Role-holders inside the organisation see it only to the extent their role allows, as described under who can see what.

Account identifier

Why. Every account has an identifier. The audit trail attributes each action to it. After an account is closed, that identifier remains and the name and email on the account row do not.

Device identifier and device details

Why. Authenticated requests carry a device identifier, the device’s name, the platform, the operating-system version, and the app version, so the server can recognise the session and the device. Public receipt verification on the sign-in screen does not require an account and does not send this.

The identifier is the operating system’s own per-app value: on Android, the Android ID; on iOS, the identifier for vendor. It is not an advertising identifier. The app stores a copy on the device and sends that copy. On Android the Android ID survives uninstalling and reinstalling the same app. On iOS the identifier for vendor changes when every app from this publisher has been removed. The name may be the name you gave the phone, when the operating system provides it, or a generic model name.

Who else sees it. Our own API and database. It is not sent to an advertising network. The Expo update check, described below, does not receive this identifier.

IP address and user agent

Why. A sign-in stores the IP address and user agent on the session row, so a session can be recognised and revoked. The API also writes a request log (method, path, status, duration, IP address) on the server. This website’s host keeps the ordinary log of a page request. We do not turn an IP address into a location.

Financial and other records members enter

This is the product. It is typed or photographed by a person, not collected in the background:

• Receipts — the donor, the amount, the date, how it was paid, whether it is general or special, whether the amount is classified as Zakat, an optional note, and an optional photograph.
• Expenses and events — a title and description, a category, an amount, a date, who was paid, notes, and photographs of bills.
• The unit’s finances — opening balances, budgets, assets, liabilities, the unit’s bank name, account title, account number, IBAN and branch, and period closures.
• Free text — descriptions, remarks, clarification messages, and the reason a member types when asking to close an account or reset a device.

The Zakat flag is a classification of that receipt for the organisation’s own accounting. It is not a survey of anyone’s beliefs, and it is not used to target anyone. There is no card payment, wallet, or in-app purchase in the app, so we do not collect payment-card numbers.

Photos

Why. A photograph of a bill on an expense or event item, and a profile picture. Before upload the image is resized and re-encoded as a JPEG, which does not carry the original file’s embedded metadata — including any location the camera stored — forward with it.

Who else sees it. Cloudflare R2, which stores the file. The app does not receive your photo library beyond the images you choose.

In-app notices

Why. The app shows notices about the work — a review, a device reset, an account-closure request — while you are using it. They are delivered through our own server. No push token is created, and nothing is sent to the phone by Apple or Google push services when the app is closed.

What you type into this website

The support form and the account deletion page send your name, email address, and message to the publisher’s support inbox. The invitation page and the receipt-confirmation page send the token from the link you opened, so the server can show that one invitation or that one receipt. The public receipt check sends the serial number you type and returns the amount, the date, and the unit — not the donor.

What is recorded about actions

Who created, edited, submitted, reviewed, approved, rejected, or reversed each record, and when. That trail is the point of the product. Administrative events, such as an invitation being sent, are logged separately and can include the invited email address.

Permissions the phone is asked for

• Internet. The app cannot reach its server without it. Android declares this permission; it is not a prompt you accept.
• Camera. To photograph a bill, or to take a profile picture. The app asks when you tap to attach something, not at startup. Declining leaves the rest of the app working.
• Photo library. To choose an existing picture for those same two purposes. The system picker returns the images you select. The app does not read the rest of the library.
• Face ID or fingerprint. Only if you turn on biometric unlock. See the next section. Declining means you sign in with your password.

The app does not request location, contacts, calendar, microphone, or audio recording. It does not read the advertising identifier. It reads the phone’s language setting on the device to choose English or Urdu; that choice is not stored as a field on the account.

Face ID and fingerprint

If you turn on biometric unlock, the check is performed entirely by your phone. iOS and Android answer the app with yes or no. They never hand over a face or a fingerprint, and the app has no way to ask for one.

What the app stores is a random secret it generated on your device, kept in the iOS Keychain or the Android Keystore and marked so that reading it requires a successful biometric check. The matching value on the server is a hash that proves the unlock happened. No biometric data leaves your device or is stored by us.

Each time the app is opened from a fresh start, the sign-in tokens saved on the device are removed and you sign in again — with Face ID or fingerprint if you turned that on, or with your password. The biometric secret stays on the device until you turn the feature off or sign out, which deletes it.

Tracking

We do not track you. JFS does not use data to link you with other companies’ apps or websites, does not use an advertising identifier, and does not show Apple’s App Tracking Transparency prompt, because there is nothing to ask permission for. There is no advertising network, no data broker, and no third-party analytics or crash-reporting SDK. The charts inside JFS are computed by the organisation’s own server from the organisation’s own records.

This website sets no cookies and loads no fonts, scripts, or images from anyone else’s server. The typeface is a file we host ourselves.

How the information is used

The purposes are only these:

• To create and sign in the account a Nazim issued, and to reset a password or a device.
• To keep the unit’s ledger: receipts, expenses, events, budgets, assets, liabilities, bank details, and the review and audit of those records.
• To send the emails the product sends: invitations, password-reset codes, donor receipts, a reminder only when a member has turned it on, and the two account-closure emails.
• To recognise a session, apply the role you hold, and record the audit trail.
• To store the photographs you attach, and to deliver an app update from Expo.
• To answer a message you send from this website.

We do not sell information. We do not use it to advertise, to profile you for marketing, or to train a model.

Who else receives it

Nothing in JFS is sold. Nothing is shared with advertisers, ad networks, or data brokers. Information is disclosed to the service providers below only so they can run the service for us, and where the law requires a disclosure to a competent authority. Members of the organisation see records according to their role; that is use inside the organisation, not a sale.

Supabase

Hosts the PostgreSQL database in which the records are kept.

Railway

Hosts the API server the app talks to.

Vercel

Hosts this website. It sees the ordinary web-server log of a page request and nothing from the app’s ledger.

Cloudflare R2

Stores the photographs. Uploads and downloads go directly between the device and R2 using a short-lived, single-purpose link the server issues.

Resend or the configured SMTP host

Delivers email. The code sends through Resend, or through SMTP when that is switched on. The SMTP host written as the default in the source is a SiteGround server (SiteGround’s policy). Which of these production actually uses is an operational setting. Whoever it is sees the recipient’s address and the contents of that email.

Expo

Distributes app updates. When the app starts it asks Expo whether a newer version of its code exists, which tells Expo the platform, the app version, and the release channel. It does not tell Expo your name, your email, or the device identifier above.

The app does not include Firebase, Google Analytics, Sentry, a payment SDK, an advertising SDK, or a maps SDK. Apple and Google distribute the install under their own store policies. They do not receive the ledger from us.

Who inside the organisation can see what

Nobody in JFS can see everything. Every record belongs to exactly one pocket — one unit’s ledger — and what you can see is decided by the role you hold and where the pocket sits. The server decides it on every request.

• A Nazim or Mutamid sees their own pocket and the pockets their role is allowed to reach. They do not see sideways into an unrelated unit.
• An auditor sees only the pockets they have been assigned to, and cannot hold an operating role in a pocket they audit.
• An Assistant Incharge Finance sees and exports only their own receipts and ordinary expenses, and cannot see balances. The server refuses the request.
• The Nazim-e-Aala can read across the organisation. Writing outside the central pocket is limited and requires re-entering a password.
• Donor names are never published. The public receipt check returns the amount, the date, and the unit — and no donor.

The law in Pakistan, and why we may use it

The publisher is based in Pakistan, and the terms of use are governed by Pakistani law. Two parts of that law matter here, in plain words.

Prevention of Electronic Crimes Act 2016. That Act makes it an offence to access an information system or its data without authorisation, to copy or transmit data without authorisation, to interfere with data, or to dishonestly use someone else’s identity information. JFS is built so that only an invited member, inside the role they were given, can see or change the records that role allows. Using another person’s account, sharing a password, or taking records out of JFS for a purpose the organisation did not authorise can be a crime under that Act as well as a breach of the terms.

Personal data protection. Pakistan has published drafts of a Personal Data Protection law. As of this policy, that law is not in force, and this page does not pretend that it is. We already follow the principles those drafts are built on:

• Notice. This page says what is collected, why, and who receives it.
• Purpose and minimisation. We collect what the finance system uses, and we do not use it for a new purpose without saying so here.
• Accuracy. You can correct your name, phone number, and profile picture in the app. A donor’s details are corrected by a member of the unit that recorded them.
• Storage limitation. The retention rules below are the ones the software actually applies.
• Security and accountability. We protect the service, and we are responsible for the providers who hold it for us.
• Your say. You can ask for access, correction, or deletion as described under your rights. Where the ledger must keep a record, we keep the record without your name and contact details on the account.

In practical terms, we use personal information on these grounds:

• The role you accepted. The account and the records you enter exist because the organisation appointed you and you accepted the invitation. Processing them is what the role is.
• The organisation’s duty to keep an auditable ledger. Issued receipts, posted expenses, and the audit trail are kept so the organisation can account for its money, including to its own auditors and where a competent authority lawfully requires it.
• A choice you can take back. The profile picture, the optional phone number, biometric unlock, and donor payment reminders are optional. Removing the picture, clearing the phone number, turning biometric unlock off, or turning reminders off withdraws that choice. Closing the account withdraws the account itself, subject to the ledger rules below.

Where it is kept, including outside Pakistan

The records live in the organisation’s database and are reachable only through its own API. The providers listed above may process data on servers outside Pakistan. This repository does not record the country of each provider’s data centre. If a Pakistani law that is actually in force later requires some of this data to stay in Pakistan, the organisation will have to move it or document the transfer. Until then, the transfer is the hosting described above, limited to running JFS.

How it is protected

The production site and API are served over HTTPS. Passwords are stored only as a bcrypt hash — never in a form anyone can read, and no one at JFS can tell you what yours is. Session tokens and invitation tokens are stored as hashes. Biometric secrets stay in the phone’s secure storage. Photographs are uploaded with a short-lived link that can be used for that one object. Every request is checked for the role you actually hold. The API sets ordinary browser-hardening headers and limits how often public forms can be submitted.

No measure is a promise that a breach is impossible. If we learn that personal data has been exposed, we will tell the affected members and donors by the email address we hold, and we will tell any authority a law then in force requires us to tell.

How long it is kept

Some records are deliberately permanent, because an audit trail that can be rewritten is not one:

• Receipts are immutable. Once issued, a receipt cannot be edited or deleted by anyone, including us.
• The financial audit trail only grows. Those entries are not edited or removed. They store the account identifier, not a separate copy of your email address. Free text someone typed into a comment can still contain a name or an address, and that text stays with the entry.
• A closed period is a locked snapshot and stays one.
• Donors are deactivated rather than deleted, so the receipts issued to them remain verifiable. Contact details can be removed on request; the receipt cannot.
• The invitation row keeps the email address it was sent to. Closing the account does not erase that row.

Other operational data is deleted on a schedule. The defaults in the software are:

• In-app notices: 180 days, and immediately when the account is closed.
• Administrative logs: 365 days. An invitation log can include the invited email address and falls under this default. Two organisation-wide device-binding records are kept permanently; they do not contain a member’s contact details.
• Copies of sent email: 90 days after the copy is marked sent or failed.
• Password-reset codes: deleted when the account is closed, and they expire on their own before that.
• API request logs on the server: rotated by size (five files of 5 MB), not by a number of days. They contain IP addresses.
• Session rows, including IP address and user agent, are deactivated when you sign out, when the app tells the server a previous run has ended, when the password changes, or when the account is closed. The software does not delete the deactivated row on a timer.

These day counts are the defaults in the code. An operator can set different positive values in the server environment. The financial ledger is not included in that sweep.

When an account is closed the account row’s name becomes “Closed account”, the email becomes an anonymous address that cannot receive mail, and the phone number, profile picture, and password are removed. Device bindings, the biometric secret, sessions, in-app notices, and pending password-reset codes are removed or deactivated. The user identifier, the financial records, the audit trail, the role history, and the closure request itself stay, so the ledger can still be audited. They are no longer labelled with your name or your contact details on the account row.

Your rights

You can do the following, whether or not a personal-data statute is yet in force:

• Access. The app shows you your name, email address, phone number, and profile picture. The ledger you are allowed to see is the access your role already has. There is no button that downloads every row the database holds about you. For a copy of the account information itself, write to jfs@jamiat.org.pk.
• Correction. Name, phone number, and profile picture are edited in the app under More → Personal info. The email address is the one the invitation was sent to; the app does not offer a self-service change of that address. Write to us if it is wrong. Donor details are corrected by the unit that recorded them.
• Deletion. See the next section, and the account deletion page. You do not have to keep the app installed after you have confirmed deletion. A donor asks for contact details to be removed; the receipt stays.
• Withdraw a choice. Remove the profile picture, clear the phone number, turn biometric unlock off, or turn donor reminders off. Closing the account is the withdrawal of the account.
• Complain. Write to us first, at the address below. If a Pakistani regulator is later given this job, you may also complain to them. Nothing here limits a right the law does not allow to be limited.

Children

JFS is not directed at children. It is a finance tool for appointed office bearers. It does not ask anyone’s date of birth, and the software does not enforce a minimum age of its own. Accounts are created only when a Nazim invites someone. We do not knowingly collect personal information from a child for advertising or for any purpose outside the organisation’s records.

If a child’s contact details were entered by mistake — for example on a donor record — write to jfs@jamiat.org.pk and we will remove the details the ledger does not require us to keep.

Changes to this policy

When this policy changes, the “last updated” date at the top changes with it. A change that alters what is collected, who it is shared with, or how long it is kept will also be announced in the app, rather than left for you to notice. The previous version is replaced on this page; we do not operate a separate archive of old policies.

Contact

jfs@jamiat.org.pk
Muhammad Iqbal, publishing on Google Play on behalf of Islami Jamiat Talaba Pakistan
1-A Zaildar Road, Ichra, Lahore, Pakistan

For questions about how to use the app, the support page is quicker. To ask for deletion, use the account deletion page. The terms of use cover the rest of the arrangement.