Data Processing Agreement

Effective date: 27/09/2026 · Last updated: 27/09/2026

1. What this agreement is, and who it is between

This data processing agreement (the "DPA") is between your organisation — the organisation that accepts our Terms of Service and keeps its books in the Hayatiq service (the "Controller") — and HAYATIQ AI SOLUTIONS F.Z.E (official Arabic legal name «حياتيك إيه آي سوليوشنز م.م.ح»; trade name as registered on the trade licence and commercial registry: HAYATIQ AI SOLUTIONS - F.Z.E), a Free Zone Establishment registered in Ajman Free Zone, United Arab Emirates, Licence/Registration No. 56374, registered address B.C. 1306744, Ajman Free Zone C1 Building, Ajman Free Zone, Ajman, United Arab Emirates (the "Processor", "we", "us").

"Hayatiq" is the name of the software; HAYATIQ AI SOLUTIONS F.Z.E is the name of the company that provides it — two different names, deliberately so. On our side, this DPA binds only the company defined above.

This DPA is written against the Saudi Personal Data Protection Law and its regulations (the "PDPL"), because the Controller and the data subjects will ordinarily be in the Kingdom of Saudi Arabia. Whether UAE federal data-protection law also applies to us as a free zone company is being confirmed with qualified counsel; that question does not reduce the commitments stated here.

2. How this DPA is accepted

This DPA forms part of the Terms of Service and is incorporated into them by reference. It is accepted for your organisation by the person who creates or administers the organisation's account, when accepting the Terms at sign-up and again when subscribing to a paid plan at checkout. No separate signature is required.

If your organisation has signed a separate written data processing agreement with us, that signed agreement is the one that applies to your organisation and prevails over this version to the extent they conflict.

3. The two roles — who is controller and who is processor

For Customer Data. For the bookkeeping content, entries, invoices, uploaded documents and related records your organisation keeps in the Service ("Customer Data"), your organisation is the controller and we are the processor within the meaning of the PDPL. Customer Data will ordinarily include personal data of third parties — supplier invoices and receipts name individuals — and your organisation is responsible for having a lawful basis to collect and hold that data in the first place.

For our own data. For the account, contact, usage and billing data of users, we act as a controller in our own right; that processing is governed by our Privacy Notice, not by this DPA. The two roles are deliberately kept distinct: which one applies decides which obligations attach.

4. What we process, why, and on whose instructions

We process Customer Data only to provide, secure, support and maintain the Service, and only on your organisation's documented instructions — the Terms and this DPA are the standing set. We do not process Customer Data for our own purposes, and we do not use it to train any general-purpose AI model. If we believe an instruction breaches the PDPL or other applicable law, we will tell your organisation before proceeding.

Duration: for as long as your organisation's account exists, plus the export and wind-down period in section 11.

Data subjects and categories: your organisation's authorised users, directors and employees; its customers, suppliers and other counterparties (including individuals named in uploaded documents). Categories: identification and contact details; financial and transactional data; the content of uploaded documents; and audit-trail metadata (which user did what, and when).

Sensitive data: the Service is not designed for sensitive data (health, creed, biometric and similar data). Your organisation agrees not to upload it, and we may suspend processing of any we identify, with notice to your organisation.

5. Security measures

We maintain, as a minimum: encryption of Customer Data in transit and at rest; logical isolation between organisations enforced at the database layer (row-level security); least-privilege access controls; an append-only audit log that records the acting user and the before/after state for writes to the Service's business tables — uploaded files, a narrowed set of assistant fields, and writes made by the system itself (which record no user) are exceptions; an architecture in which AI-drafted entries are proposals only and post to the books solely on approval by a human user of your organisation; and vulnerability management.

And, plainly, about backups and restores: our database provider takes regular backups under our plan; we do not currently offer point-in-time recovery; and we have not yet tested a restore of the production database.

If we become aware of a material degradation of any of these measures that is not itself a personal data breach (for example, backups failing), we will notify your organisation without undue delay, and in any event within five (5) business days, describing the measure affected, interim mitigations and the remediation plan. If a degradation is, or becomes, a personal data breach, section 8 applies instead.

Our personnel with access to Customer Data are bound by confidentiality obligations and receive access only as needed for their duties.

6. Sub-processors

Your organisation generally authorises the sub-processors below, each engaged under its own published terms; we are confirming that those terms are no less protective than this DPA and will update this page. The current list is the table in this section, and our Privacy Notice carries the same recipients. We will email account contacts, and update this page, at least thirty (30) days before adding or replacing a sub-processor; during that period your organisation may object on reasonable data-protection grounds. If an objection cannot be resolved, your organisation may close its account and — as an exception to the no-partial-refund rule in our Refund Policy — receive a pro-rata refund of prepaid fees for the unused period, as its sole remedy.

Current sub-processors:

A specific acknowledgement about the OCR and AI paths. Your organisation acknowledges that the original uploaded document is sent to Mistral AI for text and field extraction; that Anthropic receives the extracted text for a PDF and the image itself for a photograph or scan; and that the documents, and the data extracted from them, may contain personal data of third parties.

A plain word about error monitoring. Error reports are scrubbed before transmission, and the scrubbing is designed so that they carry no ledger content, no document data, no request bodies and no identifier for your account or organisation. However, any hosted error-monitoring service inherently receives, with every event reported from a user's browser, the connecting device's network (IP) address at the connection level, and the location of the failing code — which can be a page URL, including its query string. We therefore do not claim that this recipient receives no personal data; we state what is removed and what remains.

Paddle is not a sub-processor of Customer Data. Paid subscriptions are sold through Paddle.com Market Limited as merchant of record. Paddle is an independent controller of the payment and checkout data you give it at checkout, under its own privacy policy, and it never receives your organisation's ledger content. Details are in our Privacy Notice.

7. Data-subject requests — and correction and deletion in a book of account

Taking into account the nature of the processing, we assist your organisation in responding to data-subject requests under the PDPL (access, correction, deletion/destruction, and the others the law provides). Requests we receive directly are forwarded to your organisation without undue delay; we do not respond on the merits.

Our working rule for deletion, stated plainly. The Service is a book of account: posted entries are immutable by design and are corrected by reversal, the audit log is append-only, and your organisation may be under statutory record-keeping duties. So: correction is honoured through correction-by-reversal; deletion is honoured except where a statutory retention duty requires the record to be kept; and where the record must be kept, we assist your organisation with restriction of processing and, where lawfully and technically feasible, masking or anonymising personal identifiers outside the retained statutory record. Qualified counsel has not yet confirmed this rule. We state it here as our working position, and we will update this DPA if the confirmed position differs.

8. Personal data breach

If we become aware of a personal data breach affecting Customer Data, we will notify your organisation without undue delay, and in any event within forty-eight (48) hours of becoming aware, with the information reasonably available to us (nature, categories, approximate numbers, likely consequences, measures taken), supplemented as more becomes available. That window is set so your organisation can meet its own duty to notify the competent authority; that duty is your organisation's, not ours. Our notification is not an admission of fault or liability.

9. Where the data is — and cross-border transfer, stated honestly

Hosting. Customer Data is stored and processed outside the Kingdom of Saudi Arabia: currently in Frankfurt, Germany (Supabase eu-central-1; Vercel fra1), and with the sub-processors listed in section 6.

PDPL transfer mechanism. We have not yet adopted a specific transfer mechanism under the PDPL's rules on transferring personal data outside the Kingdom, and we are obtaining qualified legal advice on which mechanism to adopt. We commit to notifying account contacts and updating this DPA and this page when a mechanism is adopted. If your organisation needs a specific safeguard sooner, contact us at the address in section 15.

Tax record-keeping — a separate regime. The tax laws that apply to your organisation — including the record-keeping rules of the Zakat, Tax and Customs Authority — may require its records to be kept in the Kingdom, or attach conditions to electronic record-keeping. We do not claim that hosting in Germany satisfies any requirement about where records must be kept. Your organisation remains responsible for its own record-keeping obligations, including where and for how long its records are kept. The Service provides export tools to support that, and we recommend that your organisation keep, in the Kingdom, its source documents and periodic exports of its books.

10. Retention and the audit log

We do not keep Customer Data beyond what the purpose requires, except where law or a statutory retention duty requires it to be kept. The Service's audit log is append-only and is not pruned; its evidential value is the point, and its maximum lawful retention period has not yet been settled — it is one of the questions before our advisers. Until it is settled, the log remains protected by the security measures in section 5 and the purpose limitation in section 4.

11. When the relationship ends: export, then deletion — stated against what the system can actually do

These steps are performed manually by us on request; no self-service account closure or full-data export exists in the product today.

Export. On closure of your organisation's account we make Customer Data available for export in a common machine-readable format for thirty (30) days.

Deletion, honestly. After the export window, deleting Customer Data from production is the objective, and two constraints qualify it, disclosed here rather than papered over: the Service is built as a book of account — posted entries are append-only and trigger-protected against deletion, and core records (documents, parties, bank accounts, bank transactions) carry delete-blocking triggers — and no administrative whole-tenant purge mechanism exists today. For those records, our end-of-term mechanism is therefore: restriction of processing, removal of all your organisation's access and all routine access of ours, and masking or pseudonymisation of personal identifiers where feasible — not physical deletion. We are building a purge-on-expiry mechanism; until it exists, we will not promise anywhere else that we physically delete ledger records at the end of the relationship.

Customer Data outside that set (for example, exportable copies, caches, and files under no retention duty) is deleted from production within sixty (60) days after the export window, and leaves backups as those backups expire in the ordinary course; we do not publish a fixed backup rotation cycle, and we will state the current arrangement on request.

Data retained under this section remains protected by this DPA, is processed for no other purpose, and will be physically deleted when the applicable retention ground lapses and the purge mechanism described above exists.

12. Audit and information

We will make available the information reasonably necessary to demonstrate compliance with this DPA, answering first with documentation. We hold no third-party attestations today (such as SOC 2 or ISO 27001), and we will not claim one until we do. Your organisation may audit once in any twelve (12) months, on thirty (30) days' notice, at its own cost, under confidentiality, without access to any other customer's data, and with a reasonably agreed scope.

13. Liability, order of precedence, law and language

Liability under this DPA is subject to the limitations of liability in the Terms of Service, except where the applicable data-protection law does not permit liability to be limited. If this DPA and the Terms conflict on a matter of personal data, this DPA prevails. Governing law, the forum for disputes and the prevailing language are as set out in the Terms of Service.

14. Changes to this DPA

We may update this DPA from time to time. We will post the updated version on this page with a new effective date and give account contacts reasonable advance notice of material changes — including the adoption of the transfer mechanism described in section 9.

15. Contact

Email: privacy@hayatiq.ai or by post to the registered address in section 1.