Data processing addendum

1. Who this is between, and how you accept it

This addendum is between Yumankind OÜ, Sepapaja 6, 15551 Tallinn, Estonia, registry code 16232402, VAT number EE102378229 ("Prson", "we", the processor), and the organisation that uses the services in section 2 ("you", the controller).

It is part of the Verifications API terms and the Requester and API terms (together, "the terms"). You accept it for your organisation when you accept those terms: when you sign in to the developer console, create an organisation, an app or an API key, or connect an app with OAuth. You confirm you may bind your organisation.

It meets Article 28(3) of the General Data Protection Regulation (EU) 2016/679 ("GDPR"). Words such as "personal data", "processing", "controller", "processor" and "personal data breach" mean what they mean in the GDPR. If this addendum and the terms disagree about personal data, this addendum wins. If you are a processor for someone else, you pass their instructions to us and we deal only with you.

2. What we process for you

We act as your processor for the personal data we handle to provide these services to you:

• Verifications API: the requests you send to people to prove something or sign a PDF, and their answers.
• Sign in with Prson: relaying sign-ins to your website, and delivering the notifications your website sends to people who allowed them.
• Human-agents API (the API, the console at agents.prson.net and the MCP server): the content of your tasks and the work agents hand in.

The Verifications API and Sign in with Prson belong to the Prson wallet. The human-agents API is a separate product. If you use only one product, the parts of this addendum about the other don't apply to you. Annex 1 describes the processing for each.

3. Where we are not your processor

For the following, we decide why and how data is used. We are an independent controller, and our Privacy Policy applies:

• The person's own wallet: their account, keys, identities, verified details and proofs they make for themselves, and their choice of what to share with you.
• Verifying identity documents: reading and checking a passport or ID card chip, matching the face on the phone, the verification level we give, and our signed statements about them.
• Prson's signing certificates: we issue a certificate naming the person so they can sign PDFs, keep a record of each certificate, and publish revocations.
• Human agents' accounts: their profiles, verification, matching to tasks, and payouts.
• Keeping Prson safe and lawful: fraud and abuse prevention, rate limits, device checks, screening tasks against our content policy, handling reports, and the records the law requires us to keep, such as accounting records.
• Your organisation's account: the people with access, apps, API keys, balance, billing and usage.

Once you receive data from us (through the API, webhooks, the console or a download), your copy is your responsibility.

4. Your instructions and your responsibilities

• We process the data only on your documented instructions. These are the terms, this addendum, your API calls and console settings (for example the requirements of a verification, or a task's settings), and other written instructions we agree to.
• If the law requires us to process the data in another way, we tell you first, unless the law forbids it.
• If we think an instruction breaks data protection law, we tell you at once and may hold it until you confirm or change it.
• You are responsible for your instructions being lawful. You need a legal basis for what you ask, and must give the people concerned the information Articles 13 and 14 GDPR require, including that you use Prson.
• Ask only for what you need. Each requirement should have a purpose, such as asking for "over 18" instead of a date of birth.
• Don't use the services to identify people across websites or organisations, or to ask for data our content policy forbids.

5. Our duties

Confidentiality

Only people who need the data to run the services can access it. Everyone who can is bound by a duty of confidentiality, by contract or by law.

Security

We protect the data with the measures in Annex 2 (Article 32 GDPR). We may change them as technology moves on, but never in a way that lowers the protection.

Sub-processors

• You give us general authorisation to use sub-processors. The ones we use today are those marked "Yes" under "For organisations" on the sub-processors page (Annex 3).
• We tell you at least 30 days before we add or replace one, and you can object, as section 8 of that page sets out.
• Each sub-processor is bound by a written contract with data protection duties no weaker than these (Article 28(4) GDPR). We remain responsible to you for their work.

Requests from the people concerned

• You see each person only by an identifier made for your organisation, or for your website, so requests about your data should go to you.
• If a person asks us about data we process for you, and we can tell it is yours, we pass the request to you without undue delay. We don't answer it ourselves, except to tell the person to contact you.
• We help you answer requests to access, correct, delete or restrict data, as far as we can. You can read results through the API at any time. If you need data deleted sooner than Annex 1 says, for example after an erasure request, write to [email protected] and we delete it.

Help with your other duties

We give you the information we reasonably can to help with security, data protection impact assessments and consultations with supervisory authorities (Articles 32 to 36 GDPR), taking into account what we process and the information we have.

Personal data breaches

• We tell you without undue delay, and at the latest 48 hours after we become aware of a personal data breach that affects data we process for you.
• We email the people who have access to your organisation's account. We tell you what we know: what happened, the kinds and rough number of people and records concerned, the likely consequences, what we have done and will do, and who to contact. If we don't know everything yet, we tell you what we know and add the rest as we learn it.
• We take reasonable steps to contain the breach and limit its effects, and help you notify the supervisory authority and the people concerned where you must.
• Telling you about a breach is not an admission of fault.

Deletion and return

• While you use the services, we delete the data automatically on the schedules in Annex 1, with a daily job.
• Before the end, you can fetch what you need through the API. When the terms end, and on your written request, we delete the data we still hold for you within 30 days, unless EU or Estonian law requires us to keep it.
• Deleted data can remain in our databases' recovery history for up to 30 days, and then it is gone.

Information and audits

• We give you the information you need to check we meet this addendum: this page, Annex 2, the sub-processor list, and answers to a reasonable security questionnaire once a year.
• If that isn't enough, you may audit us, yourself or through an independent auditor bound by confidentiality. Give us 30 days' notice. Audits take place once a year at most, unless a breach or a supervisory authority requires one, during business hours, without access to other customers' data, and at your cost.

6. Transfers outside the EU

• We store the data in the European Union. Some sub-processors process it outside the European Economic Area, as the sub-processors page shows.
• For each such transfer we rely on an adequacy decision, including the EU–US Data Privacy Framework where the sub-processor is certified, or on the Standard Contractual Clauses (Commission Implementing Decision (EU) 2021/914), Module 3 (processor to processor), with additional safeguards where needed.
• If your organisation is outside the European Economic Area, data we send back to you is covered by Module 4 (processor to controller) of those clauses, which are part of this addendum.
• Where the clauses ask for a choice, Estonian law and the courts of Estonia apply, and the annexes of this addendum fill in the annexes of the clauses.

7. Liability

The limits of liability in the terms apply to this addendum, together with the terms and not on top of them. They don't limit what the law doesn't allow to be limited, or either party's liability to the people concerned under Article 82 GDPR.

8. How long this lasts, changes and law

• This addendum lasts as long as we process personal data for you, including after the terms end until the data is deleted.
• We tell you about changes by email at least 30 days before they apply, as the terms say. Changes the law requires may apply sooner.
• This addendum is governed by Estonian law, and the courts of Tallinn (Harju County Court) have jurisdiction.

9. Contact

• Privacy and this addendum: [email protected]
• Security issues and suspected breaches: [email protected]
• Yumankind OÜ, Sepapaja 6, 15551 Tallinn, Estonia. Registry code 16232402. VAT number EE102378229.

Annex 1. Description of the processing

• Subject matter: providing the services in section 2 to you.
• Duration: while you use the services, then until the data is deleted as below.
• Nature: collecting, storing, checking, signing, sending (by email, push notification, API and webhook), deleting.
• Purpose: asking the people you choose for what you need, delivering their answers or work to you, and delivering your notifications.
• Special categories: none are asked for by design. Photos, videos and voice recordings can show health, beliefs or other sensitive details by chance. We don't run face matching on photos taken for you.

Verifications API

Sign in with Prson and website notifications

Human-agents API

Annex 2. Technical and organisational measures

Where data is stored

• Our databases (Cloudflare D1) and file storage (Cloudflare R2) are created in Cloudflare's EU jurisdiction, so the data is stored in the EU.
• Cloudflare encrypts stored data at rest.
• Each product has its own database: wallet and verifications, human agents, the marketplace, and shared accounts.

Encryption in transit

• Our API and websites are served only over HTTPS (TLS), and our websites tell browsers to use HTTPS only (HSTS).
• Webhooks go only to public HTTPS addresses.
• Push notifications to iPhones that support it are sealed end to end: Google and Apple see only a generic line.
• A sign-in travels between the browser and the phone over an encrypted WebRTC connection, through our relay.

Pseudonymisation and data minimisation

• Each organisation and each website sees a person under a different identifier, made with a keyed hash (HMAC-SHA256) from a secret key only we hold. Two organisations can't link their identifiers.
• For verified details we keep keyed hashes and salted commitments, not the values. The salts stay in the person's wallet.
• We check the data read from a passport or ID card chip and discard it. Face matching happens on the person's phone; we never receive the photos.
• People share only what your requirements ask for, and only after they approve it. Location is recorded only when a requirement asks for it.
• An email address a person is verifying is replaced by a keyed hash once the code email is delivered.
• Our request log has one line per request: the method, the path with tokens removed, the status and the time. It has no IP addresses and no request bodies. Cloudflare's own invocation logs and traces are turned off.

Integrity and authenticity

• Results, credentials and inbox messages are signed with Prson's keys. Revoked credentials and certificates are published in status and revocation lists.
• Photos and videos are signed by the phone that took them. The wallet only works on a phone that proves it is genuine (Apple App Attest, Android key attestation).
• Each webhook message is signed (HMAC-SHA256 with a timestamp), so you can check it came from us and is recent.

Access control

• API keys are random, shown once, and stored only as hashes. Each key has scopes and can have an expiry and a spending cap. You can revoke a key at any time.
• Apps you connect with OAuth use PKCE, get access tokens that last 1 hour and refresh tokens that last 30 days, act only within the scopes and cap you grant, and can be disconnected at any time.
• Our staff tools need a separate staff sign-in. Signing keys, hashing keys and provider credentials are kept as Cloudflare secrets, not in our code.

Abuse limits

• Public endpoints are rate limited per IP address.
• A website can notify a person at most 3 times in 24 hours, with a daily cap per app. Sending stops when too many people tap stop.
• Tasks are screened against our content policy before agents see them.

Availability and recovery

• The service runs on Cloudflare's global network.
• Email, push notifications and webhooks go through queues that retry, and messages that keep failing are set aside rather than lost.
• Our databases can be restored to any point in the last 30 days.

Retention, testing and incidents

• A daily job deletes data on the schedules in Annex 1.
• Changes to our code are tested automatically before they are deployed.
• Security issues can be reported to [email protected]. We handle breaches as section 5 says.

Annex 3. Sub-processors

The sub-processors you authorise are those marked "Yes" under "For organisations" on the sub-processors page, as it stands when you accept this addendum and as changed under its section 8.