Data processing addendum
What we process on a publisher's behalf, on what instructions, and for how long.
AESHA Technology Services Limited · Last revised 7 October 2026 · All legal documents
This addendum forms part of the terms of service between the publisher (the controller) and AESHA Technology Services Limited (CRN 210193), Seychelles (the processor). It applies automatically to every publisher account; no signature is required, though we will sign a copy on request.
1. Roles
For a publisher's end users, the publisher is the controller and we are the processor. The publisher decides to show the wall, decides what identifier to send, and holds the relationship with the user.
For the publisher's own account — the name, email and login of the person running it — we are the controller. That is covered by the privacy policy, not by this addendum.
2. Subject matter and duration
We process end-user data to serve targeted offers, attribute clicks to conversions, calculate and pay the publisher, and answer support claims about missing rewards. Processing lasts for as long as the placement is active, plus the retention periods in clause 6.
3. What we process
| Data | Where it comes from | Why |
|---|---|---|
| The publisher's user identifier | The publisher, in the wall URL | To attribute a conversion to the right user and tell the publisher who to credit. |
| IP address | The request | Country targeting, fraud checks, and the abuse record on a click. |
| User agent | The request | Device targeting and bot detection. |
| Country | Derived from the IP, or supplied by the publisher | Offer targeting. Offers are geo-restricted by the advertiser. |
| Click and conversion records | Generated by us | The audit trail that makes a conversion payable and a claim answerable. |
We do not ask for and do not want names, email addresses, phone numbers, payment details or any special-category data about end users. Do not send them. If you do, we will delete them.
4. Instructions
We process only on the publisher's documented instructions, which are: this addendum, the settings on the placement, and the parameters sent in each request. We will tell the publisher if an instruction appears to us to breach applicable data protection law.
We do not sell end-user data, do not use it to build advertising profiles of our own, and do not use one publisher's data to serve another's.
5. The opaque token
This is the part worth reading. Networks never receive the publisher's user id.
Each end user is given a stable, opaque token derived by keyed hash, and that is what an advertising network sees. A network can recognise a returning user — which they need, to deduplicate completions — without ever learning the publisher's identifier for them, and without being able to correlate them with the same person on another publisher's placement.
The wall also sets no cookies at all and starts no session, so nothing is stored on the user's device by us. See the cookie policy.
6. Retention
- Clicks: 12 months. Long enough to resolve a late conversion and answer a claim about one.
- Conversions and ledger entries: 7 years. These are financial records of money paid, and are kept as such.
- Support tickets and claims: 24 months after closing.
- Fraud blocks: until they expire or are lifted.
On termination we delete or return end-user data within 90 days, except records we must keep for the financial retention above, which are retained in the ledger and not used for anything else.
7. Security
- Everything is served over HTTPS, with HSTS.
- Passwords are hashed; secret keys are never displayed except to the account that owns them, and can be rotated.
- Every callback we send is signed with the placement's own secret so the publisher can verify it came from us.
- Access to production data is limited to staff who need it, gated by named permissions, and every action touching money or an account is written to an audit log with the acting user.
- Cross-account access is refused at the query, not in the interface: an identifier in a URL is always checked against the account that owns it.
8. Subprocessors
The current list is published at /legal/subprocessors and is part of this addendum. We will give notice before adding one, and a publisher who objects on reasonable data-protection grounds may terminate without penalty.
9. International transfers
We operate from Seychelles, and our subprocessors operate in other countries. Where data moves out of the EEA or UK, it moves under Standard Contractual Clauses or the subprocessor's own approved transfer mechanism. The subprocessors page names where each one operates.
10. Data subject requests
End users should go to the publisher, who holds the relationship. When a publisher passes us a request we will help them answer it — including deleting or exporting everything we hold for one end user on one placement. The support desk can do this from a single lookup.
If an end user comes to us directly, we will refer them to the publisher and tell the publisher, rather than acting on data we hold for someone else.
11. Breach notification
We will notify affected publishers without undue delay, and in any event within 72 hours of becoming aware of a personal data breach affecting their end users, with what we know, what we are doing, and what they may need to report.
12. Audit
We will answer reasonable written questions about this addendum and provide what we have. For an on-site audit, ask — we will agree a scope that does not expose other publishers' data.
13. Contact
Data protection questions to [email protected], or by post to AESHA Technology Services Limited, 1032 Office House of Francis Ilu de Port, Mahe, Seychelles (SC).