Data Processing Agreement (DPA)

Last updated: 21 July 2026

This agreement governs the processing, by JAAY Solutions, of the personal data you entrust to the Solveraa platform in the course of your business. It supplements the Terms of Service for Trades Businesses and prevails over them on any question concerning personal data.

You accept this agreement when you register your business. A copy is sent to you by email.

1. Parties and roles

1.1. The processor. JAAY Solutions (https://jaay.solutions), operator of the Solveraa platform, referred to below as "we", "us", "the processor" or "Solveraa".

[TO BE COMPLETED BEFORE PUBLICATION — THIS BLOCK MUST NOT GO LIVE AS IT STANDS] Legal form: to be completed Registered seat and address: to be completed UID / CHE number: to be completed VAT number: to be completed Address for notices under this agreement: to be completed Contact address for data protection matters: to be completed

1.2. The controller. The company or sole trader that opens a business account on Solveraa, referred to below as "you" or "the Business". Your details are those recorded on your account.

1.3. Allocation of roles. For the data of your own customers, your quotes, your invoices, your job sites, hours worked and your staff, you are the controller and we are your processor. You decide the purposes; we host and process that data on your instruction.

1.4. What this agreement does not cover. We act as an independent controller, not as your processor, for:

1. your business account, your subscription and the related payments;
2. the vetting documents you provide to us (commercial register extract, UID certificate, ESTI installation permit, liability insurance, VAT certificate, qualifications, identity documents of sole traders) and our operators' internal review notes relating to them;
3. household accounts and their marketplace requests, before a request is awarded.

Our privacy policy applies to that processing.

1.5. The hand-over at award. When a marketplace request is awarded to you, the client's data passes into your workspace. From that moment it falls under this agreement and you are its controller.

1.6. Your warranties. You warrant that you have a lawful basis and the right to enter into the platform the personal data you enter there, including that of your staff and of customers you create manually outside the marketplace.

2. Subject matter, duration, nature and purpose of the processing

2.1. Subject matter. The processing of personal data necessary to provide the Solveraa platform: customer relationship management, quotes, invoices, scheduling, job site management, time recording and check-ins, and the communications attached to them.

2.2. Duration. This agreement takes effect when your account is opened and ends with your subscription agreement, subject to the retention obligations described in clause 12.

2.3. Nature of the processing. Collection, recording, organisation, structuring, storage, adaptation, retrieval, use, disclosure to sub-processors, restriction, erasure within the limits of clause 12, and making available in the form of exports.

2.4. Purposes. Exclusively:

1. operating the platform functions you use;
2. the technical support you request;
3. security, logging of sensitive actions and prevention of abuse;
4. compliance with our own legal obligations, in particular retention.

2.5. No use for our own purposes. We do not use the data covered by this agreement for our own purposes. We do not sell or rent it, and we do not use it for advertising, commercial profiling or model training.

3. Categories of data subjects and of personal data

3.1. Categories of data subjects

1. Your customers and prospects, and the contact persons at those customers.
2. Persons present or reachable at a job site.
3. Your staff, employees and subcontractors recorded on your account.
4. The persons you designate as users of the platform.

3.2. Categories of data relating to your customers and job sites

1. Identity and contact details: name, email address, telephone number, contact language.
2. Addresses: street, floor or flat, postcode, town, canton, property type, and the corresponding geographic coordinates.
3. Access notes: a free-text field that in practice contains door entry codes, parking directions and which bell to ring. We treat it as the most sensitive field in the system.
4. Commercial content: quotes, invoices, line items, amounts, due dates, payment status.
5. Work: appointments, job sites, descriptions of work, notes.
6. Attachments and uploaded photographs, held in private object storage.

3.3. Categories of data relating to your staff

1. Role, access level, employment type, job title, display colour.
2. Home town: town and postcode only — never a street address. The data model has no street column, and the geocoder is handed only the postcode and the town. The finest location data we hold about a member of staff is therefore the locality they set out from. It is used to rank who to send to a job.
3. Maximum travel distance accepted.
4. The member of staff's trades and skills.
5. Hours worked: start, end, source of the entry (check-in, timer, manual), approval, billing status.
6. Check-ins on site: arrival and departure timestamps, note, photographs, and a position reading at arrival within the meaning of clause 3.4.

3.4. The position reading at check-in

Since 21 July 2026 the platform can record a position at check-in. This processing is deliberately narrow, and the following limits form part of its legal basis:

1. A single reading, triggered by the person. It is taken when the artisan presses "I have arrived", and once more when they close the check-in. Nothing is recorded in between, nothing in the background, and there is no code path that could.
2. Never a precondition. A refusal, a device with no fix, a browser without the geolocation interface and a dismissed prompt all produce a check-in with no coordinates, and the hours are recorded in exactly the same way.
3. Compared, not tracked. The straight-line distance between the reading and the job site is computed once at arrival and then stored. It answers the question "was this visit made at the address" and nothing else.
4. Qualified. The accuracy radius reported by the device is stored beside the reading, so that an imprecise measurement cannot be read as evidence of absence.
5. Frozen. The distance is stored rather than recomputed, so correcting a job site's address later cannot silently rewrite what was recorded about a visit that has already happened.
6. The autosave is excluded. Saving a draft note takes no reading.

3.5. Your obligations as an employer. Swiss law prohibits surveillance systems intended to monitor the behaviour of workers (Art. 26 OLT 3, in conjunction with Art. 6 LTr). The functions described in clauses 3.3 and 3.4 are designed as time-recording and travel-substantiation instruments, not as a monitoring system. It is for you:

1. to inform your staff, before any use, of the time recording, the check-ins, the position reading and the home town, and of the purposes pursued;
2. to hold a valid legal basis under employment and data protection law;
3. not to use this data for continuous monitoring of behaviour;
4. not to require a member of staff to enable geolocation as a condition of recording their hours.

You warrant that you have complied with these obligations. The employment relationship is yours; we provide the tool.

3.6. No sensitive data expected. The platform is not designed to receive sensitive personal data within the meaning of Art. 5 let. c FADP (health, opinions, trade union membership, biometric or genetic data). You undertake not to enter such data in free-text fields.

3.7. Automated individual decisions. The crew suggestion ranks your own staff by trade, availability and travel distance, and shows why someone would not be suggested. It never removes anyone from the list: the decision remains human. There is no scoring, no personalised pricing and no automated rejection of anyone.

4. Processing on documented instruction

4.1. Principle. We process the data covered by this agreement only on your documented instruction, including as regards transfers abroad, unless required otherwise by law. In that case we inform you before the processing, unless the applicable law prohibits it on important grounds of public interest.

4.2. What counts as an instruction. Your documented instructions consist of:

1. this agreement and its annexes;
2. ordinary use of the platform by you and by the users you have authorised: creating a customer, sending a quote, issuing an invoice, scheduling work, approving hours, exporting data. Configuring and using the product is the instruction;
3. the support requests you send us in writing, including by email or from within your account.

4.3. Instructions outside the product. Any instruction that cannot be carried out through the platform's functions must be sent in writing to the contact address in clause 1.1. We may charge, at the rate in force, for the work required by an instruction that goes beyond the ordinary functions of the product.

4.4. Unlawful instruction. If we consider that an instruction infringes Swiss or European data protection law, we will inform you without delay and may suspend its execution until you confirm or amend it.

5. Confidentiality

5.1. The persons authorised to process the data covered by this agreement are bound to confidentiality, by contract or by law. That obligation survives the end of their engagement.

5.2. Limited access. Access is restricted to persons who need it in order to operate the platform, provide support or handle an incident.

5.3. Something we state openly. Two operator accounts have, by design, platform-wide visibility. They are necessary for operating the service, vetting businesses and handling incidents. They are held by persons subject to the confidentiality obligation in clause 5.1. We do not claim that a technical partition prevents us from reaching your data: it does not, and framing that is precisely what this agreement is for.

[TO BE COMPLETED BY THE OPERATOR — THIS BLOCK MUST NOT GO LIVE AS IT STANDS] Staff access control: procedure for granting, periodically reviewing and revoking operator access, and logging of its use. to be documented.

6. Security measures

6.1. Measures currently in place. The following measures are implemented and verifiable in the product:

1. Passwords. They are never stored in clear text. They are hashed using bcrypt.
2. Documents and photographs. They are held in private object storage, never publicly reachable. Access is through signed links with a short validity period.
3. Tenant scoping. Every query over business data is scoped to your workspace, and that scoping is enforced in the data access code, not by a display rule.
4. Contact masking. On the marketplace, the requester's precise address, access notes, email address and telephone number stay hidden until a business has won the request. This masking is enforced in code.
5. Encryption in transit. Traffic to the platform uses TLS, terminated at the reverse proxy.
6. Logging. Sensitive actions (quotes, invoices, time entries, changes to the business) are logged with the actor and the IP address.

6.2. Measures whose status the operator must document. The following points are not asserted in this agreement until they have been established and documented:

[TO BE COMPLETED BY THE OPERATOR — THIS BLOCK MUST NOT GO LIVE AS IT STANDS] Encryption at rest: scope (database, object storage, backups), mechanism and key management. to be documented. Backups: frequency, storage location, retention period, encryption, frequency of restore tests, recovery objectives (RPO / RTO). to be documented. Staff access management: see clause 5.3. to be documented. Incident management: detection, triage, escalation and communication procedure; responsible person; internal deadlines. to be documented. Business continuity and disaster recovery: plan and test frequency. to be documented. Security testing: code review, dependency scanning, penetration testing, frequency. to be documented. Secure disposal of media. to be documented.

6.3. Changes. We may change the technical and organisational measures, provided the level of security is not lowered.

7. Sub-processors

7.1. General authorisation. You authorise the use of the sub-processors listed in Annex 2.

7.2. Obligations. We conclude with each sub-processor a contract imposing data protection obligations substantially equivalent to those in this agreement. We remain liable for their failures as for our own.

7.3. Changes, notification and objection. We will inform you of any addition or replacement of a sub-processor at least thirty (30) days before that sub-processor begins to process your data, by email to the address on your account and by a notice on the public page carrying this list.

7.4. You may object in writing, on serious data protection grounds, within thirty (30) days of the notification. We will then seek a reasonable solution. Failing agreement within a reasonable period, you may terminate your subscription, free of charge, for the part of the service concerned, with effect from the date the change takes effect; amounts paid in advance and unused are refunded pro rata.

7.5. Emergency replacement. If a sub-processor must be replaced immediately for reasons of security or availability, we will inform you as soon as possible after the replacement, and the right of objection in clause 7.4 runs from that information.

8. International transfers

8.1. Hosting. The platform and its database are hosted with DigitalOcean, in the Frankfurt region (Germany), not in Switzerland. Personal data of persons located in Switzerland therefore leaves Switzerland for the EEA on every request.

8.2. Basis for the Switzerland → Germany transfer. Germany, a member of the European Economic Area, appears on the list of States whose legislation the Federal Council recognises as providing adequate protection (Art. 16 para. 1 FADP). No additional safeguard is required for that transfer.

8.3. Onward transfers to the United States. Certain functions involve providers established in the United States or liable to process data there:

1. Stripe — your business's billing identity and subscription amounts;
2. Google Geocoding API — address strings, including a job site's precise address when it is geocoded;
3. Google OAuth — email address, name and profile picture, for sign-in;
4. Firebase Cloud Messaging — device token and notification payload;
5. the outbound email provider — recipient address and the full message body.

These transfers rely on the European Commission's standard contractual clauses, recognised by the Federal Data Protection and Information Commissioner with the necessary Swiss adaptations, and on each provider's contractual undertakings.

8.4. Limitation at source. Geocoding results are cached, so the same address is not sent twice. Push notifications are optional, per device.

8.5. Disclosure by the browser. The map background is provided by default by the OpenStreetMap tile server (OSMF foundation, European Union). The tiles are loaded by the browser of the person viewing the page: their IP address is therefore disclosed to that server without passing through our servers. The Google map background is disabled by default.

[TO BE COMPLETED BY THE OPERATOR — THIS BLOCK MUST NOT GO LIVE AS IT STANDS] Exact reference of the standard contractual clauses signed with each US provider, date of signature, and the corresponding transfer impact assessment (TIA). to be documented.

9. Assistance to the controller

9.1. Data subject requests. Taking into account the nature of the processing, we assist you by appropriate technical and organisational measures in responding to requests for access, rectification, erasure, restriction, objection and portability. The platform's functions — viewing, editing, exporting — allow you to respond yourself in most cases.

9.2. Requests received directly. If a data subject contacts us directly about data for which you are the controller, we will not respond on the substance. We will direct them to you and forward the request to you within five (5) working days.

9.3. Impact assessment. On written request and so far as reasonable, we will provide the information in our possession needed for a data protection impact assessment (Art. 22 FADP, Art. 35 GDPR) and for any prior consultation of the authority, in particular concerning clauses 3.3 and 3.4.

9.4. Records. We keep a record of the categories of processing activities carried out on your behalf and make it available to you on request.

9.5. Scope. Assistance is provided free of charge so far as it is ordinary. Manifestly disproportionate assistance, in particular bespoke technical extractions, may be charged at the rate in force, against an accepted quote.

10. Notification of personal data breaches

10.1. Deadline. We will inform you without undue delay and at the latest within forty-eight (48) hours of becoming aware of a personal data breach affecting the data covered by this agreement.

10.2. Content. The notification will describe, so far as the information is available: the nature of the breach, the categories and approximate number of data subjects and records concerned, the likely consequences, the measures taken or proposed to address it and mitigate its effects, and a point of contact. Where all that information cannot be provided at once, it will be supplied in stages without further delay.

10.3. Allocation. Notifying the competent authority and, where required, communicating with the data subjects is for you: you are the controller. We will assist you in doing so.

10.4. Our own breaches. Where the breach concerns data for which we are ourselves the controller under clause 1.4, we make the required notifications ourselves.

[TO BE COMPLETED BY THE OPERATOR — THIS BLOCK MUST NOT GO LIVE AS IT STANDS] Internal incident management procedure: detection, triage, escalation, customer notification channel, responsible person and deputy, notification template. to be documented.

11. Audit and inspection

11.1. Information. On reasonable written request, we make available to you the information necessary to demonstrate compliance with this agreement, including the up-to-date description of the technical and organisational measures and the list of sub-processors.

11.2. Documentary evidence first. Where audit reports or certifications exist, they are provided in the first instance: they satisfy the obligation in clause 11.1 where they cover the scope requested.

11.3. Inspection. Failing that, you may carry out an inspection, or have one carried out by an independent auditor who is bound by confidentiality and is not one of our competitors. Such an inspection:

1. is announced in writing at least thirty (30) days in advance;
2. takes place during business hours, without disrupting operations;
3. takes place at most once in any twelve-month period, except following a personal data breach affecting you or on the order of an authority, in which cases an additional inspection is permitted;
4. does not extend to other customers' data, to our trade secrets, or to our shared infrastructure beyond what concerns you.

11.4. Costs. Each party bears its own costs. Time we spend on an inspection exceeding one working day may be charged at the rate in force, unless the inspection reveals a material failure on our part.

11.5. Authorities. The inspection powers of the Federal Data Protection and Information Commissioner and of any competent supervisory authority are reserved and are not limited by this clause.

12. Return and deletion at the end of the agreement

12.1. Export. Throughout the agreement and for thirty (30) days after it ends, you may export your data using the platform's export functions. On your written request and against reasonable remuneration, we can produce a full technical export.

12.2. Deletion — and its limit. After that period we delete or render inaccessible the data covered by this agreement, except what the law requires us to keep.

12.3. The ten-year retention. Invoices, and quotes that became invoices, must be kept for ten years under Art. 958f of the Swiss Code of Obligations. That obligation prevails over deletion. Accordingly:

1. those documents are not deleted, but at most marked as deleted and withdrawn from ordinary use;
2. a business account is therefore never hard-deleted. This is a structural property of the system: every record depends on the account, so removing it would remove the documents that must be kept;
3. the personal data appearing on those documents — the customer's name and address, the description of the work, the amounts — is kept with them.

12.4. The honest consequence. The right to erasure (Art. 32 FADP, Art. 17 GDPR) is therefore limited for that data for ten years. We prefer to write this down rather than promise a deletion we cannot perform. Other data — quotes that came to nothing, notes, scheduling, attachments not linked to an invoice — can be deleted.

12.5. Other statutory retention. Any other statutory retention obligation binding on us is reserved, to the same extent and for the same reason.

12.6. Audit log. The log of sensitive actions keeps, in denormalised form, the actor's name and email address as well as their IP address, so that it remains readable after an account is deleted.

[TO BE COMPLETED BY THE OPERATOR — THIS BLOCK MUST NOT GO LIVE AS IT STANDS] Retention periods to be fixed: the audit log and the IP addresses it contains; position readings at check-in; vetting documents after a business leaves. to be fixed.

12.7. Confirmation. On written request, we confirm in writing the deletion carried out and the extent of what has been retained under clauses 12.3 and 12.5.

13. Liability, governing law and forum

13.1. Liability. Each party is liable for damage caused by its own breach of this agreement or of applicable data protection law. The limitations and exclusions of liability agreed in the Terms of Service for Trades Businesses apply equally to this agreement, so far as mandatory law permits.

13.2. Allocation between the parties. If one party has to compensate a data subject or pay a fine for a failure attributable to the other, it has a right of recourse against that other party to the extent of its share of responsibility.

13.3. No limitation of data subjects' rights. This clause governs the relationship between the parties. It does not limit in any way the rights data subjects derive from the law.

13.4. Governing law. This agreement is governed by Swiss law, excluding its conflict-of-law rules and the Vienna Convention. Mandatory data protection law applicable to a given processing operation is reserved.

[TO BE COMPLETED BEFORE PUBLICATION — THIS BLOCK MUST NOT GO LIVE AS IT STANDS] Forum: the registered seat of JAAY Solutions has not yet been settled. The exclusive forum is the place of the processor's seat: to be completed. The forum must be aligned with that of the Terms of Service for Trades Businesses.

13.5. Amendments. This agreement may be amended only in writing. We may adapt it where a change in the law, an authority's decision or our infrastructure so requires, informing you at least thirty (30) days in advance; clause 7.4 applies by analogy to your right to terminate.

13.6. Survival. Clauses 5, 12 and 13 survive the end of the agreement.

13.7. Severability. If a provision is invalid, it is replaced by the valid provision that comes closest to it, the remainder of the agreement staying in force.

13.8. Language. This agreement is published in French, German, Italian and English. In the event of divergence, the French version prevails.

Annex 1 — Processing operations

Annex 2 — Sub-processors

What we do not use, and which is worth stating: no analytics, no advertising pixels, no tag manager, no third-party fonts loaded at runtime, no session recording, no A/B testing service.

We are not a payment intermediary. Payments between your customers and you never pass through Solveraa. We do not collect, hold or forward any funds on your behalf, and we hold no card data belonging to your customers.

Points to confirm

The following points require a legal decision before this agreement is published or signed. They are deliberately grouped here.

1. Operator identity. Legal form, seat, registered address, UID number, VAT number and address for notices of JAAY Solutions (clause 1.1).
2. Forum. The forum in clause 13.4 depends on the seat, which is not yet settled, and must be aligned with that of the Terms of Service for Trades Businesses.
3. One text or two. Are a FADP version and a GDPR version required, or a single text covering both regimes, as here? The choice depends on how many business customers fall under the GDPR.
4. The hand-over at award (clause 1.5). The legal basis for the client's data passing from our controllership into yours must be characterised: disclosure, successive processorship, or joint controllership for the moment of transition.
5. Position reading at check-in (clause 3.4). The legal basis chosen, the minimum content of the notice the employer must give staff, whether an individual right to object exists and its scope, and the retention period for the readings — currently tied to that of the check-in, with no period of its own.
6. Staff home town (clause 3.3 no. 2). Legal basis, and whether to require an express warranty from the Business that it has informed its staff. Note the reduced scope: this is a locality, never a street address.
7. Access notes containing door codes (clause 3.2 no. 3). Should a specific security or access-restriction obligation be imposed on the Business after a request is awarded?
8. Retention period for the audit log, including the IP addresses it contains — currently unbounded. Twelve or twenty-four months have been suggested (clause 12.6).
9. Retention period for vetting documents after a business leaves, bearing in mind that they include identity documents of sole traders. Those documents fall under our own controllership (clause 1.4), but the period must be consistent with this agreement.
10. Breach notification deadline. The forty-eight hours in clause 10.1 must be confirmed as achievable in light of the incident procedure, once that procedure is written.
11. The thirty-day export window after the end of the agreement (clause 12.1): to be confirmed, as no period is fixed today in the Terms of Service.
12. Standard contractual clauses. Should the SCCs signed with Stripe, Google and the email provider be annexed to this agreement, or does a reference suffice? Is a transfer impact assessment required for each?
13. GPS metadata (EXIF) in uploaded photographs: strip on upload, or disclose as retained? The decision determines whether an additional row belongs in Annex 1.
14. Minimum age. None is enforced by the product; to be decided whether this bears on data relating to apprentices who are minors.
15. Order of precedence between this agreement, the Terms of Service for Trades Businesses and any individually negotiated price, to be confirmed in both documents.