Blley

Blley Privacy Policy

Effective date: 20 August 2026 · Version: 2026-08-20

1. About this Policy and who we are

Blley is a product and service operated by Zimpl Inc. Zimpl Inc. is a Delaware C Corporation, with its address at 300 Delaware Ave., Suite 210, Wilmington, DE 19801, United States. In this Policy, “Blley”, “we”, “us” and “our” mean Zimpl Inc. and the Blley product and services it operates.

This Policy explains what personal data Blley handles, why, who receives it, and the choices and requests available to you. It covers the Blley marketplace, the Blley gateway, publisher tenant websites operated through Blley, and the related tools and services (together, the “Services”). Your use of the Services is also governed by the Blley Terms of Service; this Policy is about personal data and does not repeat the Terms of Service.

You can reach us about privacy at privacy@blley.com, or by writing to Zimpl Inc. at 300 Delaware Ave., Suite 210, Wilmington, DE 19801, United States.

2. Scope and our roles

Blley’s role in relation to personal data is not a single universal one; it depends on the category of data and who decides how that data is used. Describing the actual flows rather than one blanket label:

  • Platform and account data — Blley operates the account and umbrella-identity systems, and the account holder is the person the data is about.
  • Publisher staff public identity — a publisher decides what staff information is published on its presence, and Blley hosts it.
  • Visitor marketplace behaviour — saved listings, saved projects, saved searches, alerts and contact-disclosure clicks are decided by the visitor, are owned by the Property membership, are isolated from the account, and are not routed to publishers except as aggregates.
  • Enquiries — Blley is the intake that receives and routes an enquiry, and the publisher is the recipient who independently determines how the enquiry and any resulting lead are used in the publisher’s own systems.
  • Communications — Blley is the sender of the transactional messages the Services generate.
  • Advertising — an advertiser determines its own campaign and contact data.

3. Personal data we handle

We handle the following categories of personal data:

  • Account identity — your name, email address (and a canonical form of it), a hashed password, your account status, and your language and timezone preferences. Accounts do not store a phone number. This supports authentication and your umbrella Blley identity.
  • Authentication and security — password-reset tokens; multi-factor authentication, where the authenticator secret is encrypted at rest and recovery codes are stored only as hashes; and sessions. Sessions are the only application database record that currently retains a network address and browser user-agent in readable form; where another governed record needs a network identifier, it stores a salted one-way digest rather than a readable address. This describes Blley’s application and database records, and not production infrastructure such as web-server or security access logs, whose handling is settled as part of deployment (see the service providers and subprocessors section).
  • Publisher staff public identity — for publisher team members, a display name, title, biography, and public email and phone. Disclosure of a phone or WhatsApp number is an explicit per-record opt-in that is off by default. This information is owned by the publisher and is published only when marked public.
  • Enquiries — when you send an enquiry, your contact name, email, mobile number, message and preferred contact channel, together with a record of your consent to be contacted in response. Enquiries do not store a network address or user-agent; only a keyed fingerprint is kept to detect duplicate submissions.
  • Publisher customer records — leads, lead activities and viewing requests hold contact identity and the publisher’s private notes and follow-ups. These are the publisher’s business records, and the publisher independently determines how they are used.
  • Contact-disclosure clicks — when a WhatsApp or call contact is revealed, we record the click event. We do not store a network address, user-agent or tracking cookie for it, and we associate it with an account only if you are signed in.
  • Saved state and alerts — your saved listings, saved projects, saved searches and alert subscriptions, which belong to your Property membership rather than to the account.
  • Communications — records of the transactional messages the Services generate, holding the recipient email or account, the template and the delivery status. We do not store the message body, and delivery-failure reasons come from a fixed set of codes rather than raw transport text.
  • Content reports — if you report content, the report reason and any free-text notes you add (which may themselves contain personal data if you include it), an optional reporter contact email, and a salted fingerprint. A report’s own record stores no account, network address or user-agent.
  • Privacy requests — when you ask for a data export or to close your account, we keep a durable record of the request: the subject account and, where different, the requesting account; the request type and status; its scope; any refusal or blocking reason; and metadata about a generated export file, such as its size and when it expires. These records let us carry out and evidence your request.
  • Tenant-team invitations — when a publisher invites someone to join its team, we store the invited email address and a canonical form of it, the role offered, and the identities and timestamps of the invitation, its acceptance and any revocation.
  • Audit and security records — operator actions and security events, which store a salted address hash and an operator reason, as append-only, hash-chained records.
  • Advertising and commercial data — advertiser and advertiser-user contact identity, and impression and click reporting that is coarse and aggregated, with hashed context and de-duplication keys and no per-person cross-day identifier.
  • Uploaded assets — stored as object references; the personal case is a publisher staff photo.

Our structured technical logs are automatically redacted so that emails, phone numbers, tokens and message contents are scrubbed before the logs are written.

4. Why we use personal data

We use the personal data above for these purposes, and not for unrelated ones:

  • to authenticate you and operate your umbrella Blley identity and account;
  • to secure the Services, including multi-factor authentication and abuse prevention;
  • to host publisher presences and the staff identity a publisher chooses to publish;
  • to receive an enquiry and route it to the relevant publisher;
  • to let you save listings, projects and searches and receive the alerts you set up;
  • to send you transactional communications about the Services;
  • to provide advertising and commercial features and aggregate reporting; and
  • to keep audit and security records and to comply with legal obligations.

5. How data flows and who receives it

When you send an enquiry, Blley routes it to the relevant publisher, who then acts on it in the publisher’s own customer records and independently determines how the resulting lead is used. A publisher’s customer records are that publisher’s business record. Advertising reporting is provided only in aggregate. Blley does not sell personal data.

We share personal data with service providers that process it on our behalf solely to operate the Services, as described in the service-providers section below, and where the law requires disclosure or to protect the Services and their users.

6. Cookies and similar technologies

The Services use only strictly functional, necessary mechanisms. Specifically:

  • a session cookie that keeps you signed in;
  • a CSRF token that protects form submissions;
  • an opt-in “remember me” mechanism; and
  • a blley_locale cookie that remembers your language preference.

There are no analytics, advertising, pixel or third-party tracking cookies in the Services. Because of that, Blley does not use a cookie-consent banner and does not operate a separate cookie policy. If non-essential tracking is ever introduced in future, it will be assessed under a fresh privacy and cookie review before it is turned on.

Blley-owned surfaces serve their web fonts themselves, so viewing a Blley-owned page does not send your visitor data to a third-party font host.

7. Ask Blley and automated assistance

“Ask Blley” and similar features provide automated assistance and search. Their output depends on available data and may be incomplete or inaccurate, and it is not professional advice; you should independently verify anything you intend to rely on. The current implementation does not send your queries to an external artificial-intelligence or model provider. If this changes in future, it will be subject to applicable privacy requirements and to any disclosure or consent then required.

8. Data retention

We keep personal data for as long as it is needed for the purpose it was collected for, and for as long as we are required to keep it to meet a legal, regulatory, security or accounting obligation, after which it is deleted or anonymised. Rather than fixing a single period, we retain each category by reference to its purpose and to what the law requires.

Some records are, by their nature, retained even after you make a privacy request: our append-only audit and security chains, financial and commercial records, and a publisher’s own business records, including the leads a publisher owns, are kept where necessary or legally required and are not erased by a consumer request. The one fixed time limit the Services apply is a short operational lifetime on a generated data-export file, after which the file is removed; this is a security and operational measure, not a statutory retention period.

9. Your privacy choices and requests

You can ask us for a copy of your own Blley data. An export is an allow-listed bundle of only your own data. It never includes passwords, multi-factor secrets, cryptographic keys, other people’s information, or a business’s private customer records.

You can also ask to close your account. Closure anonymises your identity, purges your multi-factor credentials, password-reset tokens and sessions, and redacts your own enquiry contact details. There is no one-click self-service erasure of your data; erasure is handled through the account-closure and privacy-request process, and it is subject to the retention exceptions described above, so records we are required or entitled to keep are not removed.

10. Security

We protect personal data with, among other measures: multi-factor authentication; encryption of the multi-factor secret at rest; revocation of active sessions on account suspension, closure or a password change; salting of network identifiers into one-way digests in our governed records; automatic redaction of personal data from our application’s technical logs; and signed, time-limited URLs for access to private assets. No method of transmission or storage is perfectly secure, and we cannot guarantee absolute security.

11. Service providers and subprocessors

We use categories of infrastructure and service providers to run the Services, such as cloud hosting and object storage and transactional email delivery. We describe these by category because the concrete provider list is finalised as part of deployment, and the shipped defaults keep data local rather than handing it to an outside processor. We do not claim that any particular named vendor is processing production personal data, and the Services include no payment processor. The finalised list of subprocessors will be recorded before launch as part of that deployment step.

12. International and markets

Bahrain is the initial operational market for the Services. We do not make a data-residency promise and do not commit the Services to hosting in any particular country; hosting and provider regions are kept neutral and are settled as part of deployment. Where personal data is processed across borders, it is done in line with applicable law.

13. Children

The Services are directed to real-estate professionals and adults using a property marketplace, and are not intended for or directed to children. We do not knowingly collect personal data from a child. If you believe a child has provided personal data to us, please contact us at privacy@blley.com so we can address it.

14. Changes to this Policy and re-acceptance

We may update this Policy from time to time. Where a change is material, we will seek your renewed acceptance at the next appropriate point in your use of the Services; where a change is minor, we may notify you without requiring renewed acceptance, where legally appropriate. We never overwrite the historical record of a consent you have already given.

15. Contact

You can contact Zimpl Inc. about this Policy or about your personal data at privacy@blley.com, or by writing to Zimpl Inc. at 300 Delaware Ave., Suite 210, Wilmington, DE 19801, United States.

16. Effective date and version

This Policy is identified by its effective date and version, shown at the top of this document. Effective date: 20 August 2026. Version: 2026-08-20.