Valnivo Professional
Data processing agreement — Valnivo Professional
Who you are dealing with
Valnivo Professional is operated from Luxembourg by Valnivo Labs. Valnivo Labs is a trade name, not a registered company. The name of the person responsible is given on request — write to privacy@valnivo.eu — and is given without condition for a formal data-protection request or a complaint to a supervisory authority, so no right of yours depends on it being printed here.
This is weaker than the law wants, and it is said plainly rather than hidden. Art. 13(1)(a) GDPR and the Luxembourg e-commerce law of 14 August 2000 both expect the controller to be named. The same is true of the consumer app's notice, and the real fix in both cases is a legal entity rather than better wording.
No lawyer has reviewed these documents. That is stated because a firm deciding whether to rely on them is entitled to know it.
What is in force today
Valnivo Professional is an early-stage service and there is no charge for it. No price is quoted anywhere, nothing is invoiced, and no payment method is taken — so any clause below about fees describes an arrangement that does not yet exist. If that changes it changes by agreement, in a new version, and never by a figure appearing on a screen.
The processing agreement is the exception, and it is in force. An art. 28 agreement attaches to processing and not to payment: the moment a firm puts a client's figures into this service there has to be one, whether or not anybody is being charged. It is accepted when a firm claims its account, and that acceptance is what executes it.
The parties
The controller: the firm that claims its account, identified by the name and country of establishment it gave when it asked to be enrolled, and by the account that claimed it.
The processor: Valnivo Labs, of Luxembourg — a trade name, not a registered company, because there is no legal entity yet. The name is given on request, and without condition for a formal data-protection request or a complaint to a supervisory authority, so no right under this agreement depends on it being printed. That is weaker than art. 13(1)(a) wants and it is said plainly rather than papered over; the real fix is an entity.
When it is executed: on acceptance, when the firm claims its account — which is recorded with the version accepted, the account that accepted it and the date. An art. 28 agreement attaches to processing rather than to payment, so it is in force from the first client a firm enters, whether or not anything is being charged for.
This agreement forms part of the terms of use for Valnivo Professional and prevails over them on anything to do with the processing of personal data.
The agreement
1. Subject matter, duration, nature and purpose. The processor performs financial projections on figures the controller supplies, and returns them; and it stores, sealed, the clients the controller enters in the application, so that the controller's members can open them again. A case sent to the API is processed for the duration of the request; a stored client for as long as the controller keeps it, until it deletes the client or the agreement ends. The agreement lasts for the term of the contract. The purpose is that calculation, and keeping the controller's book for it, and nothing else.
2. Processing only on documented instructions — art. 28(3)(a). The processor processes personal data only on the controller's documented instructions, which are: this agreement, the terms, and the requests the controller sends. A request is the instruction. The processor does not process the data for its own purposes, does not derive statistics from case content, and does not use any of it to train anything. If the processor believes an instruction infringes the GDPR it says so before acting on it. No personal data is transferred outside the EEA except as Annex 3 states.
3. Confidentiality — art. 28(3)(b). Everyone the processor authorises to process the data is bound to confidentiality, by contract or by statute. Today that set is the people of Valnivo Labs; when it changes, the list in Annex 2 changes with it.
4. Security — art. 28(3)(c) and art. 32. The measures are Annex 2. They are the ones the product actually has, not a catalogue: anything aspirational belongs in a roadmap, and a measure named in an art. 28 contract is a measure a regulator will ask to see working.
5. Sub-processors — art. 28(3)(d) and art. 28(2) and (4). The controller gives a general authorisation. The list is Annex 3. The processor gives 30 days' notice of any addition or replacement, and the controller may object on reasonable data-protection grounds and, if the objection cannot be resolved, terminate the affected service without penalty. Every sub-processor is bound by terms no less protective than these, and the processor stays liable for them.
6. Assisting with data subject rights — art. 28(3)(e). The people concerned are the controller's clients and their rights are exercised against the controller. The processor helps by appropriate technical and organisational measures, and specifically: a stored client is deletable on its own, not only in bulk, and a handover document can be written for any one of them, because a controller with one month to answer one person cannot work against a bucket. Any request the processor receives directly is passed on without answering it.
7. Assisting with arts 32–36 — art. 28(3)(f). The processor assists with the security of processing, with breach notification, with data protection impact assessments and with prior consultation, so far as the nature of the processing and the information the processor holds allow.
Breach notification. The processor tells the controller without undue delay after becoming aware of a personal data breach affecting the controller's data, with what it knows at the time rather than waiting to know everything, and keeps the controller informed as more is known. The processor does not notify the controller's supervisory authority or the people concerned; that is the controller's decision and its 72 hours.
8. Deletion or return at the end — art. 28(3)(g). At the end of the contract the processor deletes the controller's personal data, or returns it if the controller asks, and deletes existing copies unless EU or member-state law requires retention. What there is to delete is the controller's stored clients: each is sealed with keys the controller's members hold and the processor does not, so the processor can delete one but cannot read it — returning a client therefore means the controller opening it itself before the end, and a handover document can be written for any one of them. The account records the processor is the controller of are covered by its own privacy notice. The retention period is agreed with the controller rather than imposed — a regulated firm may be obliged to keep records for five years.
9. Information and audits — art. 28(3)(h). The processor makes available the information needed to show compliance with art. 28 and allows and contributes to audits, including inspections, by the controller or an auditor it mandates: once a year, on reasonable notice, at the controller's cost, and subject to confidentiality. The processor may answer with an up-to-date report or certification where one exists and it genuinely answers the question — today none does, which is stated rather than implied by silence.
10. Records. Each party keeps the record of processing activities art. 30 requires of it. The processor's record has this product's own entries rather than borrowing the consumer app's.
11. Liability and law. As the terms provide (clause 10, which is itself awaiting a lawyer). Luxembourg law.
Annex 1 — the processing
| Categories of data subject | Natural persons whose financial position the controller plans for: its clients, its members, or its employees. They are not users of any Valnivo product and have no account, no device and no login in this arrangement. |
| Types of personal data | The controller's own reference for each client, a pseudonymous identifier the controller alone can resolve, at most 64 characters and stored in the clear. Sealed with it: a country of residence and a currency; an amount already put by and an amount added monthly; each plan's label, horizon, assumed rate of return and monthly amount; a target amount and year, if the controller records one; when the client was last reviewed and how often; income and spending in six fixed groups, if recorded; and holdings — a ticker, a number of units and, once priced, a closing price and its date. A case sent to the API carries the same kinds of figure and a reference. |
| Special categories | None. The service has no field for health, and a controller that encodes one into a reference is in breach of clause 3(c) of the terms. |
| Nature of the processing | For the API, computation on data in transit and the transmission of the result back. For the application, storage of each client sealed with a key the controller's members hold and the processor does not, so the processor keeps and deletes records it cannot read; the computation runs in the controller's own browser. |
| Where | Cloud Firestore in this product's own Google Cloud project, in the European Economic Area (Berlin, europe-west10); the API on Cloud Run in Belgium (europe-west1). |
| Duration | A case sent to the API: the life of the request, and nothing is written down. A stored client: until the controller deletes it or the agreement ends (clause 8). |
| Frequency | Whenever the controller sends a request or saves a client. |
Annex 2 — technical and organisational measures (art. 32)
The measures that exist, each with where it is implemented, so that an auditor can check rather than take a word for it:
| Measure | Where |
|---|---|
| Identity is refused at the boundary, by name, before any arithmetic runs; the request comes back naming the field it will not take | One rule, used by both the API and the product page, so it cannot become two that drift |
| Nothing about an API case is stored: no case, figure, projection or result is written to any medium | The API server; the design refuses result storage by name |
| A stored client is sealed with its own key, which the processor does not hold. The key is wrapped for each member allowed to open it by ECDH P-256 — the same tested scheme the consumer app's joint spaces use — and only the reference, capped at 64 characters, rests in the clear | The encryption code shared with joint spaces, under a written key-custody design; the database rules close a client record to six fields |
| Access follows the organisation's own record. Every read and write of a client is checked against the controller's membership list and roles; administering the firm does not open a client, and removing a member ends their access at once | This product's database rules, proved against the emulator |
| A member's key reaches only that member's own approved devices. A new browser waits until one of the person's own devices approves it; an optional recovery code, held only by the person, can stand in for a lost device | The device record in this product's own database, readable by that member alone |
| The service is closed by default. It runs with no anonymous access at all: a caller without our own credentials is refused before the container sees the request | Cloud Run, deployed without unauthenticated access; the deployed configuration is checked by an automated test |
| Keys are held as hashes, never as keys, with the scope, the issuer, the date and the revocation date | keys, in this product's own database |
| Its own Google Cloud project, sharing no database, rule, index or key with any other product | The product's own Google Cloud project |
| Encryption in transit everywhere; encryption at rest by the platform, beneath the sealing above | Cloud Run, Firestore |
| No content in a log. The API writes no usage record; an audit trail, when one is recorded, holds a member, a client's id, an action and a time and nothing else, and is append-only | The database rules; the API server |
| The limits of all of the above, written down rather than asserted | The key-custody design, which states what it does not protect against |
Annex 3 — sub-processors
| Sub-processor | Entity / country | What it does | Transfer basis |
|---|---|---|---|
| Google Ireland Ltd; Google LLC (US) | Cloud Firestore storage of the sealed clients and the account records, and Firebase Authentication, in this product's own project; Cloud Run execution of the API | Google Cloud DPA; EU–US DPF (Google LLC certified) and SCCs |
And nobody else. No analytics provider, no advertising network, no error-reporting service, no content delivery network of our own. A price service the controller chooses for its holdings is not a sub-processor: the controller's own browser sends it a ticker with the controller's own key, under the controller's own agreement with it, and the processor is not a party. Additions follow clause 5.
What changed in this version
| Version | Date | What changed |
|---|---|---|
| v2 | 30 September 2026 | Clause 1, clause 8 and Annex 1 describe the storage of the clients a controller enters in the application — sealed, with the reference in the clear — where v1 described computation in transit only. Annex 2 adds the measures that protect that storage and drops a usage record nothing writes. Annex 3 names Firebase Authentication and says a price service the controller chooses is not a sub-processor. |
| v1 | 22 September 2026 | First published. |