tounify

SCOPE AND CONCLUSION

This Data Processing Agreement pursuant to Art. 28 of the General Data Protection Regulation (GDPR) ("agreement") applies to every contract for a per-connection plan of the tounify API. Under these plans tounify processes personal data on the customer's behalf in two ways: it stores and prices the grid connections the customer registers, and it extracts tariff data from the documents the customer uploads to the document scan.

It does not apply to per-call plans. Requests under them are addressed by postal code and tariff identifier; no end customer's name, meter, address or account reaches tounify, and tounify processes no personal data on the customer's behalf. Where an end customer uploads its own bill to tounify directly, tounify is the controller, as its Privacy Policy states.

The customer accepts this agreement when it concludes a per-connection plan in the tounify Cockpit: the plan cannot be ordered until the customer has accepted the Terms and Conditions and this agreement, and tounify records the acceptance with the version accepted. This agreement forms part of the Terms and Conditions for that processing (Section VI.4). Art. 28(9) GDPR allows the contract in electronic form; no separate signature is needed. On request, tounify provides a copy signed on its side. Changes follow the notice rules of the Terms and Conditions (IX.2); a change of sub-processor follows Section 7.

1. PARTIES

Controller ("Customer"): the organisation that accepted this agreement, as named in its tounify account.

Processor: tounify GmbH, Burgring 1 / DG 23, 1010 Vienna, Austria, Commercial Register Vienna FN 497477i, VAT ATU73661423. Contact for data protection matters: [email protected].

No Data Protection Officer is designated, as none of the cases of Art. 37(1) GDPR applies to the Processor. This is reviewed if the processing under this agreement reaches a large scale.

2. SUBJECT MATTER AND DURATION

The Processor provides the Controller with two services of its API, through which it processes personal data on the Controller's behalf:

Connections: storing the grid connections the Controller registers through the tounify API and pricing them, that is resolving their grid operator and tariffs and computing their prices, components and price forecasts.
Document Scan: the automated extraction of structured tariff data from energy bills, contracts and price sheets that the Controller uploads through the tounify API, or through any other upload channel the Processor provides to the Controller, such as the tounify Cockpit, into a draft connection.

This agreement takes effect when the Controller accepts it on concluding a per-connection plan, and remains in force for as long as the Processor processes personal data on the Controller's behalf. It terminates with the main service agreement; Section 9 governs the deletion that follows.

3. NATURE AND PURPOSE OF PROCESSING

Connections. Receipt, storage, change and deletion of the connection records the Controller sends; matching them to a grid operator and to tariffs; computing prices, price components and, where the Controller opts a connection in, price forecasts; returning them to the Controller. Purpose: to give the Controller the prices that apply at its end customers' connections. The Processor counts the connections registered or priced in each month to bill the Controller.

Document Scan. Receipt of an uploaded document; storage of that document; automated optical character recognition and layout analysis; extraction of tariff and consumption values; return of the extracted structured record to the Controller; deletion in accordance with Section 9.

Optical character recognition and extraction are performed by large language models that the Processor calls through its sub-processor's inference API (Annex III). The Processor does not train, fine-tune or otherwise build models, and does not use the uploaded documents to train or fine-tune any model, to enrich its own tariff database, or for any purpose other than the two the Controller instructs here:

returning the extraction result to the Controller; and
keeping the extraction of the service working correctly: within the retention period of Section 9, authorised staff of the Processor may open an uploaded document, its derived artefacts and the extraction result, re-run the extraction, and compare or label the result, to find and fix faults in the extraction and to measure its accuracy. This is part of the service the Controller receives. It never uses one controller's document to produce or change another controller's result, and nothing from the document leaves the retention period of Section 9 except the measurement itself, which holds no personal data.

The Controller instructs the Processor to carry out both.

The extraction result is limited by design to tariff, price and consumption values: it carries no name, address, account or contract reference, or metering-point identifier. The uploaded document and the full text transcribed from it do contain personal data and are held as set out in Section 9.

The inference sub-processor's own terms exclude the use of submitted content for training and do not retain it after processing; the one exception is a request flagged as malicious or as degrading the service, whose content may be held temporarily to find the cause.

4. CATEGORIES OF DATA SUBJECTS

The Controller's end customers, and its prospective end customers, at whose grid connections the Controller registers a connection
Natural persons who are named on an energy bill uploaded by the Controller, typically the same end customers
Users of a device from which the Controller's application sends API requests to the Processor, where that application runs on the end customer's device rather than on the Controller's servers

5. CATEGORIES OF PERSONAL DATA

Connections, all pseudonymised: none identifies a person without the Controller's own records.

The Controller's reference for the connection. The API refuses a reference that looks like a metering-point identifier
Postal code of the supply point, and the grid operator
Annual consumption, contracted capacity, fuse rating, phases, voltage level
Metering type and capability, off-peak hours
Customer class, special load classes, grid tariff group
The tariffs the connection is on, and whether it is opted into the price forecast

Document Scan:

Name of the bill holder
Supply and billing address
Metering point identifier
Customer and contract reference numbers
Consumption volumes and billing periods
Tariff name, prices and invoice amounts
Any further personal data the Controller chooses to include in the uploaded document
The postal code the Controller states for the supply point when it uploads a document, kept with the scan record

API request records:

The IP address from which each API request was sent, with the time of the request, the API token and the Controller's organisation, the country, endpoint and API version, the tariffs asked about and any error

Special categories of personal data (Art. 9 GDPR) are not processed. The Controller undertakes not to upload documents containing them.

6. OBLIGATIONS OF THE PROCESSOR

The Processor shall:

process personal data only on documented instructions from the Controller, including as regards transfers to third countries, unless required to do otherwise by Union or Member State law, in which case the Processor shall inform the Controller before processing (Art. 28(3)(a));
ensure that persons authorised to process the personal data are bound by confidentiality (Art. 28(3)(b));
implement the technical and organisational measures set out in Annex II (Art. 32);
engage sub-processors only in accordance with Section 7;
assist the Controller, insofar as possible, in fulfilling data subject requests under Chapter III (Art. 28(3)(e));
assist the Controller in complying with Art. 32 to 36, including in the event of a personal data breach and in any data protection impact assessment (Art. 28(3)(f));
at the Controller's choice, delete or return all personal data at the end of the provision of services (Art. 28(3)(g), see Section 9);
make available all information necessary to demonstrate compliance and allow for and contribute to audits (Art. 28(3)(h), see Section 10);
notify the Controller without undue delay, and in any case within 48 hours, of becoming aware of a personal data breach affecting the Controller's data. The notice describes the nature of the breach (where possible the categories and approximate number of data subjects and records concerned), names a contact point, and states its likely consequences and the measures taken or proposed. What is not yet known follows in further notices without undue delay (Art. 33(3) and (4));
inform the Controller immediately if, in its opinion, an instruction infringes the GDPR or other Union or Member State data protection law (Art. 28(3), second subparagraph);
forward to the Controller without undue delay any request it receives from a data subject about the Controller's data, and not answer it except on the Controller's documented instruction;
if a public authority demands the Controller's data, refer it to the Controller where the law allows, inform the Controller of the demand without undue delay unless the law forbids it, and disclose no more than the demand compels.

Assistance under items 5 and 6 that goes beyond what the service itself provides may be charged at the Processor's then-current rates, except where it is needed because of the Processor's own breach.

7. SUB-PROCESSORS

The Controller grants general written authorisation for the engagement of sub-processors. The current list is in Annex III.

The Processor shall inform the Controller of any intended addition or replacement of a sub-processor at least 30 days in advance, giving the Controller the opportunity to object on reasonable data protection grounds within 14 days of the notice; a change not objected to in that time is approved. If the Controller objects and the parties cannot agree within 30 days, the Controller may terminate the affected service.

The Processor imposes on each sub-processor the same data protection obligations as set out in this agreement and remains fully liable to the Controller for the sub-processor's performance.

8. INTERNATIONAL TRANSFERS

All processing of uploaded documents takes place in the European Union: storage, the extraction function and model inference run at Scaleway in France, and the API that receives the upload runs at DigitalOcean in Germany. Where a sub-processor listed in Annex III processes personal data outside the EEA, the transfer is based on the European Commission's Standard Contractual Clauses (Implementing Decision (EU) 2021/914), supplemented by the technical measures described in Annex II.

9. DELETION AND RETURN

Uploaded documents and every artefact derived from them (the transcribed text, the prompts and the model output) are deleted 30 days after upload, by a lifecycle rule on the storage bucket that runs once a day, so an object may remain for up to one further day. The Controller may ask for an earlier deletion of a scan at any time. The period exists so the Controller can retrieve the extraction result again and report a faulty extraction, and so the Processor can use the document to keep the extraction working correctly (Section 3); the extraction itself completes within minutes.

A connection is deleted when the Controller deletes it through the API. The billing records keep the Controller's reference and each month in which the connection was billable, without any of the connection's other data, for as long as the Processor must keep its invoicing records.

API request records, which hold the IP address a request came from, are deleted 31 days after the request, once the request has been counted into the daily totals the Processor bills from; records of requests made with a testing token are deleted after 90 days. The Processor's application and access logs hold no IP address: before a log line leaves the Processor's systems, the address is replaced by a keyed hash.

When the main agreement ends, the Processor deletes every connection still registered and all other personal data it processes on the Controller's behalf within 30 days after the end, unless Union or Member State law requires further storage; until the deletion, the Controller may still read its connections through the API. Uploaded documents keep their own period above.

10. AUDITS

The Processor shall, on reasonable written request and not more than once per calendar year, provide the Controller with the information necessary to demonstrate compliance with this agreement. Where the Controller requires an on-site audit, it shall be conducted with at least 30 days' notice, during business hours, without disrupting operations, and subject to confidentiality. Each party bears its own costs of an audit, unless the audit finds that the Processor has materially breached this agreement.

11. LIABILITY AND GOVERNING LAW

Liability follows the main service agreement. Where this agreement and the main service agreement conflict on the processing of personal data, this agreement prevails. This agreement is governed by Austrian law, to the exclusion of its conflict-of-law rules. Place of jurisdiction is Vienna.

ANNEX I - PROCESSING SUMMARY

Subject matter and duration: Section 2
Nature and purpose of processing: Section 3
Categories of data subjects: Section 4
Categories of personal data: Section 5
Retention and deletion: Section 9

ANNEX II - TECHNICAL AND ORGANISATIONAL MEASURES (ART. 32 GDPR)

Pseudonymisation and encryption

Transport encryption (TLS) for all connections to the website, the portal and the API; TLS 1.2 is the minimum, and the portal sends HSTS
TLS between the API and the primary database, with the server certificate verified against the provider's certificate authority
Uploaded documents are stored in Scaleway Object Storage (fr-par) without encryption at rest. The bucket is private, its only grant is the Processor's own Scaleway organisation, it is reached only with the service's API keys, and every object is deleted 30 days after upload (Section 9)
Encryption at rest of the primary database (DigitalOcean Managed PostgreSQL) and of its backups
Logs do not carry document contents: the scan pipeline logs only identifiers, status, timings and error classes, never file contents or extracted values

Confidentiality and access control

API access authenticated by bearer token, issued and revocable per customer
Portal access authenticated by individual user account; administrative functions behind a separate authorisation guard
The Controller uploads documents through the API with its own API token, which identifies its organisation. A scan and its result are served only to the organisation that uploaded it, and only with a token of the same kind (testing or production) as the one used for the upload. The number of scans an organisation may start per day is capped
The Processor's internal scan routes, used in its administration tool, require the administrator role
The extraction function is private and is invoked only by the API, with a bearer token
Production infrastructure access is limited to the Processor's two managing directors, who are its only staff

Integrity

Version-controlled application code
Changes reach production only through a release that a gate refuses unless the test suites scoped to the change pass, and which first takes a backup of the production database
Application and access logging to Grafana Cloud (logs kept 14 days, archived for 365 days) and Scaleway Cockpit (logs kept 7 days)
The logs sent to Grafana Cloud carry no email address and no IP address: email fields are dropped, an address in a message is masked, and a client IP address is replaced by a keyed hash before a line is sent
Raw API request records in the primary database, which hold the requesting IP address, are deleted after 31 days (90 days for requests made with a testing token)

Availability and resilience

Managed platform hosting with provider-level redundancy (DigitalOcean App Platform, Frankfurt)
A full backup of the production database before every release, held on the operator's workstation with an encrypted disk; restores of these backups are exercised in practice
The managed database's own daily backups

Data minimisation by design

The tariff API is addressed by postal code and tariff identifier and never receives end-user identifiers; this is a property of the architecture, not a policy
A connection carries no name, address or metering-point identifier: the API refuses a reference that looks like one. The access logs carry the route pattern in place of the reference, so a reference does not leave the primary database

ANNEX III - SUB-PROCESSORS

Scaleway SAS

Storage of uploaded documents and the artefacts derived from them; the serverless extraction function; model inference (Generative APIs), to extract the tariff data from an uploaded document

Processing location: Paris, France (EU), region fr-par · Transfer basis: Scaleway Data Processing Agreement

DigitalOcean, LLC

Hosting of the API and of the primary database, which receive the upload and store the connections, the scan records and the API request records, to provide and bill the service

Processing location: Frankfurt, Germany (EU) · Transfer basis: DigitalOcean Data Processing Agreement; Standard Contractual Clauses for provider-side access from outside the EEA

The extraction function can be configured to use a second model provider. It is not used for documents the Controller uploads; switching to it would add a sub-processor and is subject to the notice in Section 7. The Processor's own service providers, which process no connection or document content, are listed in its Privacy Policy.

tounify GmbH

Burgring 1 / DG 23
1010 Vienna, Austria

Data Processing Agreement