Data Processing Agreement

1. Who is who

Two different relationships run through this service, and conflating them is the usual source of confusion.

• Your customers' data: you are the controller, we are the processor. Conversations, phone numbers and orders belong to your business. You decide why they are processed. We process them only to run the service for you.
• Your own account data: we are the controller. Your store details, login, usage counts and billing records are ours to manage, and are covered by the Privacy Policy rather than by this agreement.

This agreement covers the first relationship. "You" means the merchant; "we" means Difae Research.

2. What we process, and for how long

We do not receive, and do not ask for, email addresses or postal addresses from your store platform. We read only the fields listed above.

3. We act only on your instructions

We process your customers' personal data only on your documented instructions, including any transfer to a country outside your own. Your instructions are: this agreement, the Terms of Service, and the settings you choose in the product, such as which automations are on and who receives a broadcast.

If we believe an instruction breaches data protection law, we will tell you rather than quietly carry it out. If we are ever legally compelled to process your data for some other reason, we will tell you before doing so unless the law forbids us from telling you.

We never use your customers' data to serve another merchant, to train models, or for our own marketing. Data is isolated per store at the database level.

4. Confidentiality

Everyone we authorise to access your customers' data is bound by a duty of confidentiality that survives the end of their engagement. Access is limited to the people who need it to operate and support the service, and every access to an individual account is recorded in an audit log that we do not delete.

5. Security measures

The technical and organisational measures we commit to are set out in Annex II at the foot of this page. They are described as what the system actually does, not as what a template suggests. Where a measure is not yet in place, Annex II says so, because a security commitment you cannot verify is worth nothing to you.

6. Sub-processors

You give general authorisation for the sub-processors below. Each is necessary for the service to function: without Meta a message cannot be delivered, and without a model provider the assistant cannot reply.

We will give you at least 30 days' notice before adding or replacing a sub-processor, by email to your account address and by updating this page. If you object on reasonable data protection grounds within that period, you may terminate the affected service without penalty and receive a refund of any prepaid amount for the unused term.

We impose the same data protection obligations on every sub-processor that apply to us under this agreement, and we remain fully liable to you for their performance.

7. International transfers

The application database and servers are in Helsinki, Finland, inside the European Union. Two transfers leave it, and both are necessary to deliver the service you asked for.

• To us. Difae Research is established in Pakistan, which is not the subject of an adequacy decision. Where you are in the EEA, the UK, or Switzerland, the European Commission's Standard Contractual Clauses (Module Two, controller to processor) are incorporated into this agreement by reference and apply to that transfer, together with the UK Addendum where UK data is involved.
• Onward, to OpenAI in the United States. Covered by OpenAI's own data processing addendum and the Standard Contractual Clauses it incorporates. OpenAI states that data submitted through its API is not used to train its models.
• To Meta. Message delivery necessarily reaches Meta's global infrastructure, under Meta's own terms, because Meta is the carrier.

Where the Clauses apply, Annex I is the table in section 2 together with the sub-processor table in section 6, and Annex II is below. In any conflict between the Clauses and this agreement, the Clauses prevail.

8. Deletion and return

• On request, at any time. The deletion page sets out how to ask and what happens to each category of data. We also implement the mandatory platform deletion requests your store platform sends us on a customer's behalf, and those delete immediately.
• Automatically, on a schedule. Conversation content is deleted after 12 months and order records after 24 months, by a job that runs daily.
• When you leave. At your choice we delete your customers' personal data or return it to you, within 90 days of the end of the service, except where law requires us to keep something. Uninstalling deactivates an account rather than erasing it, deliberately, because merchants reinstall and losing an order history to a mis-click would be worse. Ask and it is erased.

9. Helping you meet your own obligations

• Customer requests. Where a customer asks you for access, correction, export, deletion, restriction, or objects to processing, we will help you answer within the time the law allows. If a customer contacts us directly about your store, we will refer them to you rather than act on it ourselves, because it is your decision to make.
• Breach notification. If we become aware of a personal data breach affecting your customers' data, we will notify you without undue delay and in any event within 48 hours, with what we know, what we are doing, and what we recommend. You are the controller, so the notification to a supervisory authority is yours to make, and we will give you what you need to make it.
• Impact assessments. We will give you reasonable help with a data protection impact assessment or a prior consultation, taking into account what we know about how the service works.

10. Demonstrating compliance

We will make available the information you reasonably need to show that we meet the obligations in this agreement, and we will allow and contribute to audits, including inspections, conducted by you or an auditor you appoint. In practice, please ask us first: a written response, this page, and the Privacy Policy answer most questions without anyone visiting anything. Audits take place during business hours, on reasonable notice, without unreasonably disrupting the service, and no more than once a year unless a breach or a supervisory authority requires otherwise.

Annex II — technical and organisational measures

What the system does today. Read section 5 first: measures that are not in place are named as such, and this annex is updated when that changes.

• Encryption in transit. HTTPS is enforced on every endpoint with automatic certificate management and HSTS. Every call to Meta, OpenAI and your store platform is over TLS. Inbound messaging webhooks are signature-verified and rejected outright if the signature is missing or wrong.
• Encryption at rest. The database sits on an encrypted disk (LUKS2, AES-256-XTS with a 512-bit key), unlocked when the server starts and tied to the database service so that a failure to unlock stops the database rather than letting it start on empty storage. The honest limit: this protects the data if a disk is disposed of, copied or detached, and does not protect against someone who has already gained administrative access to the running server, because the key must be readable for unattended start. That is the same trade every major cloud provider's encryption at rest makes.
• Tenant isolation. Every conversation is keyed to a single store at the database level, and an inbound message is routed to a store strictly by the WhatsApp phone number that received it. There is no query path that returns one merchant's data to another.
• Access control. Administrative access uses per-session credentials hashed with scrypt and compared in constant time, session cookies that are httpOnly and same-site-strict with a fixed lifetime, per-address lockout after repeated failures, and CSRF protection. Staff passwords must meet a minimum strength enforced when the credential is created. Server access is by SSH key only, with password authentication disabled.
• No bulk export path. The administrative interface is read-only for customer data. There is no export, download, or reporting endpoint that returns customer personal data in bulk.
• Audit logging. Administrative sign-in, sign-out, and every view of an individual store or conversation is written to an append-only log that survives deletion requests, so access can be demonstrated after the fact.
• Network exposure. The database listens only on the local interface and is not reachable from the internet. The firewall permits only SSH and HTTPS. Security updates are applied automatically.
• Data minimisation. We do not read email or postal addresses from your store. Only a first name is read, and only to address the customer in a message. An order is not recorded at all unless a conversation already exists for that number.
• Backups. The database is dumped nightly, each dump is verified as restorable before it is kept, retention is 30 days, and restores are rehearsed. Every backup is encrypted, including the historical ones, and the decryption key is held separately from the backups themselves. Platform credentials are deliberately excluded from backups.
• Retention and deletion. Automatic deletion on the schedule in section 8, plus immediate deletion on a platform-mandated customer deletion request, covering every table that holds a customer identifier.
• Incident response. A written incident response policy defines severity levels, the notification clock, what is rotated after a compromise, and what evidence is preserved before remediation.
• Not in place, stated plainly. Credentials carry no further layer of application-level encryption on top of the encrypted disk, and access to the operator console is a single shared credential rather than per-person accounts. We say so here rather than imply otherwise, and this annex is updated when each changes.

Contact and status

AiBayya is operated by Difae Research, a sole proprietorship registered with the Federal Board of Revenue in Pakistan.

Data protection questions, audit requests, and breach notifications: privacy@difaeresearch.com

This agreement forms part of the Terms of Service and applies from installation. Where it conflicts with the Terms of Service on the processing of your customers' personal data, this agreement prevails.

Effective 2026-09-11.