Data processing agreement

The processor. Hydrologic Electronics Trading L.L.C, a limited liability company licensed in the United Arab Emirates, trading as “Holla”.

The controller. You, the tenant identified at sign-up. You are either a brokerage or an individual licensed broker. Either way you are the controller and we are the processor.

Effective date. The date you accept this agreement at sign-up, recorded against your account together with the version above.

Succession. A successor entity is being set up to take over running the service, working name Holla Artificial Intelligence FZCO in Dubai Silicon Oasis, and the registered name may end up different. You agree in advance that this agreement, the terms of service, and every consent record collected under them can be assigned to any entity that lawfully takes over the service under a new, renewed or renamed licence, on notice to you and without signing again. That agreement is perpetual and applies each time it happens. An assignment cannot reduce any protection this agreement gives you.

Terms defined in the UAE’s data protection law, Federal Decree-Law No. 45 of 2021 (the PDPL), carry those meanings here: controller, processor, personal data, sensitive personal data, data subject, processing and data breach. In addition:

• End customer. A person who messages you through the service. They are the main category of data subject here.
• Service. Holla’s AI front-desk product, as described in the terms of service.
• Sub-processor. A third party we engage that processes personal data on our behalf to provide the service. The current list is Annex B.
• Core sub-processor. One the service cannot run without and for which no substitute exists: currently Supabase, Anthropic and Meta Platforms.
• Platform provider. A third party that processes personal data in connection with the service partly or wholly as a controller in its own right under its own terms, rather than on our instructions: currently Meta Platforms for WhatsApp transport and Google for calendar data.
• Suppression. The state of an end customer who has sent an opt-out keyword. All outbound messaging to them stops and their durable memory profile is cleared, while the conversation record is kept as your business record.
• Erasure. Deleting an end customer’s personal data from our live systems on your instruction, leaving only the suppression record.
• Suppression record. The minimal pseudonymised record kept after suppression or erasure, specified at 11.5.
• Tenant personal data. Personal data we process on your behalf under this agreement. It does not include data about your own account that we process as a controller in our own right, which is 2.3.

2.1 You are the controller. You decide the purposes and means of processing your customers’ personal data. You decide which conversations happen, what the assistant is configured to say, which listings and knowledge are loaded, and which brokers see what.

2.2 We are the processor. We process your data only on your documented instructions, set out in section 3.

2.3 Where we are a controller instead. For a narrow set of data we act as controller rather than processor: your account and team-member records used for logging in, billing, service messages and abuse detection; billing and payment records handled through our payment processor; and service telemetry. That processing is governed by our privacy notice, not by this agreement. The same piece of data can be processed in both capacities for different purposes. Which capacity applies is decided by the purpose of the particular operation, not by the category of data.

2.4 Instructions we think are unlawful. If we form the view that something you have instructed breaches the PDPL or another applicable data protection law, we will tell you without undue delay and may suspend that instruction until it is withdrawn or amended.

2.5 What you warrant. You warrant that:

• you have a lawful basis for the processing you instruct, have given your customers the notice your own law requires, and hold any consent that basis depends on;
• if you are an individual broker, you have the authority and the lawful right to process the customer data you connect to the service, including leads or contacts that arose while you were engaged with a brokerage. We take no responsibility for a dispute between you and a brokerage or anyone else over who owns that data or has the right to process it;
• where you import data into the service, including portal-page import during setup, you have the right to collect and process what you import, and you instruct the import within that right.

We do not obtain consent from your customers on your behalf, with one safeguard: the service honours opt-out keywords (STOP, UNSUBSCRIBE, and the Arabic equivalent) automatically and applies suppression to that customer, including clearing their durable memory profile. Suppression is not erasure, and neither one is a substitute for your own lawful basis. Erasure happens only on your instruction under 7.2.

3.1 What counts as an instruction. This agreement, the terms of service, how you configure the service in your dashboard, and any further written instruction you give through a channel we recognise.

3.2 The scope of processing is Annex A: its subject matter, duration, nature, purpose, whose data it covers and what kind of data it is.

3.3 Nothing for our own purposes. We do not sell your data, we do not use your customers’ conversations to train general-purpose machine-learning models, and we do not disclose your data to other tenants.

3.4 Aggregates and evaluation fixtures are two different things and we treat them differently.

• Anonymised aggregates. Statistics from which no one is identifiable, directly or by combination: properties generalised, budgets bucketed, dates shifted. We use them to evaluate and improve the service. Data that genuinely meets that threshold is no longer personal data.
• Evaluation fixtures. Test cases curated by hand with identifying details stripped out. Because a real-estate conversation can still be re-identifiable from the property, the budget and the date, we treat fixtures as pseudonymised personal data rather than anonymised data, processed under the instructions in this agreement, with the controls in Annex C. We do not rely on any theory that your customers consented to it.

4.1 We keep your data confidential and disclose it only to people who need it to run the service, to sub-processors under section 5, and where we are compelled by law under 4.3.

4.2 Everyone with access is bound by written confidentiality obligations that outlast their engagement, and is trained on what this agreement requires.

4.3 Compelled disclosure. If we are legally compelled to hand over your data we will tell you first unless we are legally prohibited from doing so, and will disclose only the minimum the compulsion requires.

4.4 Operator access. Our people may enter your workspace to provide support or investigate an incident. Every such access is written to the audit log. Access without your authorisation is treated as notifiable to you even if no third party saw the data.

5.1 General authorisation. You authorise us to engage the sub-processors listed in Annex B.

5.2 New ones. We give you at least 30 days’ notice before engaging a new sub-processor, by email to your account owner and by updating the public register. Within that period you may object on reasonable data-protection grounds. If we cannot resolve your objection, your sole remedy is to terminate the affected subscription without penalty and receive a pro-rated refund of prepaid fees for the unexpired period, despite any no-refund policy in the terms. There is no objection right for a core sub-processor, because the service cannot run without them; the same termination remedy applies instead.

A sub-processor is engaged the moment a credential for it lands in our production environment, not when it is designed or discussed. Adding one is a three-step change and not a deployment: the register, then the public privacy notice, then notice to you under this clause.

5.3 Flow-down. We impose on each sub-processor data-protection obligations no less protective than these, and we stay fully liable to you for what they do. This applies to sub-processors acting on our instructions; platform providers are 5.5.

5.4 Transcription vendors. Two speech-to-text vendors are engaged at once and either may process a given tenant’s voice notes. Which one runs for you is a per-account setting that defaults to Speechmatics, with the other standing as fallback. Both are listed in Annex B because both are live, not alternatives on paper.

5.5 Platform providers. Meta Platforms and Google process some data in connection with the service under their own published terms and, in part, as controllers in their own right: Meta for carrying WhatsApp messages, Google for calendar data when a broker connects a calendar. We cannot impose this agreement on them and we do not warrant their processing beyond exercising the choices their platforms give us. Using the service necessarily involves their own processing, which you accept by choosing to operate on those platforms. We remain liable under 5.3 for the part of their processing that is carried out on our instructions.

6.1 Where it sits. Your data is stored and processed outside the UAE. The main database, authentication, file storage and realtime layer run on Supabase EU-West-1 (Ireland). Compute and the message queues run on Railway EU West (Amsterdam). Media objects sit in Cloudflare R2. Other sub-processors process data in the places noted in Annex B.

6.2 Why it sits there. No UAE-region option was operationally reliable when we chose. We review the hosting region at least every six months and will migrate to UAE-region hosting when a stable offering exists.

6.3 The transfer basis. We intend the transfer to be lawful under the PDPL’s cross-border provisions on these cumulative grounds: the contractual safeguards in this agreement and in particular the transfer clauses at Annex D, which oblige us and each sub-processor to handle the data to a standard consistent with the PDPL; your customers’ explicit consent where you have obtained it; and necessity for performing the contract between you and your customer, and between you and us.

The UAE has issued no adequacy list and no standard contractual clauses of its own, so the contract route is the operative one and Annex D is drafted to what that route requires. The principal recipients sit in the EEA under GDPR supervision, which is what gives the recourse element real institutions behind it. This is the clause the counsel review exists for, and we would rather state the residual uncertainty than paper over it.

7.1 Requests come to you. As controller, answering a request from one of your customers is yours to do. Our privacy notice points them to you first.

7.2 What we do to help. We enable you to access, export, correct and delete your customers’ personal data: through the service where that surface is implemented, and otherwise on written request to us, actioned within ten business days. Erasure carried out this way follows the purge inventory at 11.6 and leaves the suppression record at 11.5 as its only residue in live systems.

7.3 Requests that reach us directly. If one of your customers writes to privacy@holla.ae we will not answer on the merits. We forward it to you without undue delay and help you respond.

7.4 Why 7.2 is worded that way. It is deliberately limited to what the product does today. Export exists operator-side, correction is partial, and a deletion surface is being built. Until those surfaces ship, the written-request route is the operative promise. We would rather under-promise here than describe a button that does not exist.

8.1 Our duty runs to you. The PDPL puts on the processor a duty to notify the controller as soon as it becomes aware, so that you can report to the UAE Data Office. We do not report to the Data Office and we do not notify your customers directly. Both are your decisions as controller.

8.2 Timing. We notify you within 24 hours of detection and do not wait for root cause. That is a commitment we are making, not a restatement of a statutory deadline: the law says “immediately” and leaves the number to regulations that have not been issued. If you are licensed in DIFC or ADGM the same 24 hours applies, and it is meant to leave you room inside your own regulator’s timeline.

8.3 What the notification contains, so far as we know at the time and updated as we learn more: what happened and roughly how big it is, the categories and rough number of people and records affected, the likely consequences, what we have done and plan to do, and a contact point.

8.4 Cooperation. We give you what you reasonably need to make your own report, including audit-log extracts for the affected scope.

8.5 The operational procedure is our internal runbook. It can change without amending this agreement, provided the change does not weaken 8.1 to 8.4.

9.1 We implement and maintain the technical and organisational measures at Annex C, appropriate to the risk.

9.2 We may update those measures provided the level of protection is not reduced.

10.1 Documentation first. We give you what you reasonably need to satisfy yourself that we are keeping to this agreement: written answers to a reasonable questionnaire, the current Annex C measures, the sub-processor register, and relevant policy documents, within 30 days of a written request, at most once in any 12-month period unless a breach affecting you has happened since the last time.

10.2 Third-party audit. Where documentation under 10.1 is demonstrably not enough for a compliance obligation you are under, you may commission an audit by an independent third-party auditor bound by confidentiality: on at least 30 days’ written notice, no more than once in any 12-month period, during business hours, without access to other tenants’ data, and at your cost. On-site audits are excluded until we hold a recognised security certification. Until then the audit runs remotely against documentation and screen-shared evidence.

10.3 Nothing here requires us to breach a confidentiality obligation owed to a third party or another tenant.

11.1 While your account is open you can export your data at any time and delete specific conversations, customers or listings, through the service where that is implemented and otherwise under 7.2.

11.2 When you leave, we delete your data within 90 days of account closure, except where UAE law requires us to keep something, tax and accounting records being the ordinary case. If you are on a free trial and do not convert, the account counts as closed 30 days after the trial expires. During those 30 days it is locked to read-only so you can export or re-activate, and the 90-day clock starts at the end of them.

11.3 Standing retention limits, which apply while you are with us and not only when you leave:

• Conversation messages. The life of your account, unless you delete them earlier.
• Voice-note audio. Purged 90 days after upload, unless that conversation is flagged to keep longer.
• Audit logs. At least 12 months, for security and regulatory traceability. Payloads for erased customers are redacted under 11.6.
• Calendar tokens. Until the broker disconnects the integration or deletes their account.
• Suppressed customers (an opt-out keyword came in). Outbound stops and the durable memory profile is cleared. The conversation record is kept as your business record and as the audit trail of the opt-out itself.
• Erased customers (you instructed erasure). Content is purged per the inventory at 11.6, and the suppression record at 11.5 is the only residue left in live systems.

11.4 Backups. Deleting removes data from live systems. Copies inside backups are overwritten on the ordinary backup cycle rather than being cut out of them individually.

11.5 The suppression record. After suppression or erasure we keep, for each affected customer, only: your account identifier; the channel; a keyed hash of their channel identifier; a suppression timestamp if an opt-out keyword was received; an erasure timestamp if erasure was performed; and the related audit rows with their payloads redacted. The two timestamps are independent of each other. A suppressed customer is excluded from every outbound path. A customer who was erased but never suppressed can open a new conversation, and that legitimately starts a new record. The suppression record is pseudonymised personal data, not anonymised data. We keep it solely to honour the opt-out, to evidence that the erasure happened, and to stop an erased record being re-created through an import, which the law permits as processing necessary to comply with obligations we are under and to establish or defend legal claims. It is checked on the paths data comes in by as well as the paths messages go out by, so a portal import or a CRM re-import cannot quietly resurrect someone who was erased.

11.6 What erasure actually purges. Erasing a customer removes from live systems: their messages and conversation rows; voice-note audio and other media objects in storage; voice transcripts; lead briefs and qualification rows; any residue of the durable memory profile; calendar events the service created for their viewings; and any embedding vectors derived from their content. Audit rows that reference them are kept for the audit-log period with payloads redacted down to action metadata, which is who did what to what kind of thing and when, with the content stripped out. Copies of messages sitting in your own WhatsApp clients or other systems are outside our systems and outside the scope of erasure, and they remain your responsibility.

12.1 Our aggregate liability under this agreement is subject to the limitation of liability in the terms of service, except that for breach of this agreement it is capped at two times the fees you paid for the service in the twelve months before the event, and in any case not less than AED 5,000 where you have paid no or nominal fees.

12.2 You indemnify us against losses arising from processing carried out on your unlawful instruction, from a breach of the warranties at 2.5, or from your own failure to discharge your obligations as controller. We indemnify you against losses arising from our breach of this agreement, subject to 12.1.

12.3 Nothing here excludes liability that cannot lawfully be excluded under UAE law.

12.4 Each party bears any administrative penalty a regulator imposes on it. The indemnities above do not move such penalties from one party to the other, but they do cover the reasonable costs of regulatory proceedings caused by the other party’s breach of this agreement.

13.1 This agreement takes effect on the date recorded under the parties section and continues for as long as we process your data.

13.2 Clauses that by their nature should survive termination do: section 4 on confidentiality, section 8 on breach, section 11 on deletion, section 12 on liability and section 14 on governing law.

14.1 This agreement is governed by the laws of the United Arab Emirates.

14.2 The parties submit to the exclusive jurisdiction of the competent courts of Dubai for any dispute that cannot be resolved by good-faith negotiation within 60 days of written notice. This matches the terms of service deliberately: one forum across every instrument between us.

14.3 Nothing here limits a regulator’s own powers, either party’s obligations to a regulator, or a data subject’s rights before one.

If this agreement conflicts with the terms of service or the privacy notice on a matter of data protection, this agreement prevails. On everything else, the terms of service prevail.

What it is for. Running an AI front desk that answers property enquiries on your WhatsApp number and adjacent channels, qualifies leads, proposes viewings, and hands off to your brokers.

How long. Your subscription, plus the retention periods in section 11.

What we do with it. Collect, record, store, structure, retrieve, transcribe, translate, run machine inference over, transmit, disclose to your brokers, and erase.

Whose data. The customers who message you; your own team members; and property owners and landlords whose details you load into listings.

What kind of data. Customer phone numbers; message content including voice transcripts; voice audio; images and documents customers send; qualification answers including budget and financing intent; viewing schedules and locations; your team members’ names, BRN, mobile and email; calendar tokens encrypted at rest; audit-log payloads; and authentication credentials.

Sensitive data. We do not deliberately collect it, and you should not configure the assistant to ask for it. It nonetheless arrives incidentally, because a customer volunteers it in an open conversation: accessibility needs, family circumstances, the health reason behind a move. The PDPL’s sensitive category expressly covers data revealing a person’s family, which ordinary qualification for a family home touches as a matter of course. We treat any exposure of message content as a sensitive-data event by default rather than assuming otherwise.

Kept against what our systems actually connect to rather than what we plan to use. The public version of this list lives in our privacy notice.

• Supabase (Ireland, EU-West-1). Database, auth, storage, realtime, vector search. Everything in Annex A.
• Railway (Netherlands, EU West). Application servers and the queues behind them. Every message in and out passes through.
• Cloudflare. Object storage for the photos, voice notes and documents your customers send, and hosting for the dashboard and admin applications.
• Anthropic. Language-model inference for the assistant: message content, qualification facts, listing and knowledge context.
• Meta (WhatsApp Cloud API). Message transport and account connection: phone numbers, message bodies, delivery receipts, media. Also a platform provider under 5.5.
• Speechmatics and Deepgram. Voice-note transcription. Both live, see 5.4.
• Cohere. Text embeddings so your own listings and knowledge documents can be searched. Those can carry broker names and contact details.
• Google. Calendar tokens and event reads and writes when a broker connects their calendar; address lookup for listings. Also a platform provider under 5.5.
• Resend. Transactional email: team invitations, alerts when a lead could not be delivered, digests.
• Firecrawl. Reads public brokerage and agent pages on the property portals during setup so you can import your listings and roster instead of typing them.
• MapTiler. Map tiles in the dashboard: browser IP address and map viewport.
• PostHog, EU region (Frankfurt). Product analytics for the signup flow: a broker’s Holla account identifier, their workspace identifier, and the names of the setup steps they reach. No customer conversations, no listing data, no names, email addresses, phone numbers or BRNs. Session recording and automatic event capture are off; it sets no cookie.
• Sentry. Error monitoring with PII scrubbing on.
• Vercel. Hosting for this marketing site and our DNS.

The processing location for each of these is being confirmed vendor by vendor and will be stated here before this agreement is finalised. Supabase and Railway are confirmed as shown.

Stripe is deliberately not on this list. It handles your own billing and payment details, which we hold as a controller in our own right under 2.3, and it never touches your customers’ data. It appears in the privacy notice instead.

Not engaged. Twilio and Doppler appear in older Holla documents and were never engaged. OpenAI exists as an unreachable code path with no key set in production; we name it because setting one environment variable would engage it, which is why 5.2 makes that a notifiable step rather than a silent one. Upstash is not engaged either, despite being the name of the variable that holds the connection string for a Railway-managed Redis service. Cal.com is a booking window on this site, loaded from Cal.com only when a visitor opens it, not a sub-processor: nothing we run sends it data.

• Separation between accounts is enforced in the database itself and not only in application code, so a query that forgets whose data it is asking for returns nothing rather than somebody else’s.
• Encryption in transit throughout, and at rest for the database and file storage. Calendar tokens get a second layer of encryption at the column level.
• Secrets live as environment variables in the deployment platform, never in our code repository.
• The suppression record’s key. The keyed hash in 11.5 uses a dedicated production secret kept separate from our other keys. Rotating it means re-hashing the suppression table in the same change, because a rotated key would quietly break the opt-out and re-import checks.
• Monitoring through error tracking with PII scrubbing on, plus an append-only audit log of material actions kept at least 12 months, with payloads redacted for erased customers under 11.6.
• Backups with point-in-time recovery.
• Separation of environments. Production is separate from development and test, and test data is synthetic.
• People. Written confidentiality obligations, and access limited to what a role needs.
• Incident response follows a written runbook, reviewed quarterly.
• Evaluation fixtures are curated by a named person, stripped of details identifying you or your customers, with properties generalised, budgets bucketed and dates shifted before they enter the corpus. The curation step is logged.
• Data protection officer. We have appointed one: Joe Edwards, co-founder and general counsel, at privacy@holla.ae. The appointment stands whether or not the PDPL’s trigger for requiring one is met, because we treat message content as sensitive by default and we run automated lead qualification.

What we do not have, stated rather than left for you to discover: no SOC 2 or ISO 27001 certification, and no formal penetration-testing programme.

These are the contractual safeguard referred to in 6.3. They apply to every transfer of your data outside the UAE in the course of running the service, for as long as the recipient holds it, including after this agreement ends. We have drafted them to what the PDPL’s contract route requires rather than reworded another jurisdiction’s clauses, and we will replace them with official UAE instruments if and when the Data Office issues any.

D.2 The standard that travels with the data. We ensure your data transferred outside the UAE is processed to a standard consistent with the PDPL: processing limited to the documented instructions in section 3, confidentiality under section 4, the security measures at Annex C, breach notification under section 8, the assistance at section 7, and the deletion and retention rules at section 11. If local practice at a recipient conflicts with that standard, the standard wins, or the data does not go.

D.3 Recourse where the data sits. The principal recipients are in the European Economic Area, Supabase in Ireland and Railway in the Netherlands, where processing falls under the GDPR, supervised by the Irish Data Protection Commission and the Dutch Autoriteit Persoonsgegevens, with recourse to those countries’ courts. For recipients outside the EEA, Annex B states the jurisdiction and our flow-down contract identifies the supervisory or judicial body through which measures can be imposed on them.

D.4 Flow-down and onward transfer. We impose the D.2 standard on each sub-processor under 5.3 and stay fully liable to you for what they do. A sub-processor may pass data on further only under a contract imposing the same standard, and our register records where that leaves the data. Platform providers are covered by 5.5 rather than this annex.

D.5 Your route to remedy. You enforce these clauses against us directly, in the forum at section 14, for a breach occurring at us or at a sub-processor. You do not have to pursue the sub-processor yourself. Nothing here reduces the liability regime at section 12.

D.6 Government access requests. If we, or to our knowledge a sub-processor, receive a legally binding request from a public authority where the data sits, we will tell you without undue delay unless legally prohibited, challenge or narrow the request where there are reasonable grounds, and disclose only the minimum required.

D.7 Suspension and repatriation. If we can no longer ensure the D.2 standard for a category of data at a recipient, we tell you, suspend that transfer, and if it is not cured within 30 days return or delete the affected data under section 11, whichever you choose.

D.8 Survival and future instruments. These clauses survive termination for as long as any recipient holds your data. If the UAE Data Office issues standard contractual clauses, an adequacy decision covering a relevant destination, or other official transfer instruments, we will adopt them within a reasonable period and tell you, and the official instrument then prevails over this annex to the extent of any conflict.

Data-handling questions: privacy@holla.ae. Contract questions: legal@holla.ae. Security disclosures: security@holla.ae.