We keep almost nothing: a few facts your ID proved, never the document itself, and no website you verify with ever sees any of it. We keep no document images and no selfie photos. We keep no record of which sites you visit. We don't sell anything about you. If you run a website that uses Passwave, we hold your account details, hashed API keys and billing history, and we count your usage without keeping records of your individual users. When you use the app to read a document's chip, nothing from your document ever leaves your phone: what we receive is an anonymous technical report about how the read went, and crash reports if the app goes wrong. One switch turns all of it off. Everything below is the detail behind those sentences.
If you verify with the Passwave app
1. What we collect
Verification, where you prove something about yourself to a website without it ever learning who you are, is not open yet. Nothing in this part applies until it is, and there are no accounts in the meantime. It is set out here so the terms are on the record before anyone can be affected by them.
Deliberately little, but not nothing. To run your account we hold: your email address, a random account identifier, the details your ID proved (your name, date of birth and legal gender, and the document's type, issue date, expiry date and country of issue), a face vector derived from your selfie, the derived answers you've proven (for example "over 18: yes"), a record of each share you make (which service, when, and any follow-up question it asked), one-way hashes used to prevent duplicate accounts, the notifications we send you in the app about your own account, and - if you subscribe - the billing token from our payment processor.
We do not hold your address, your document images, or your selfie. The images are used to run the check and deleted once it completes. Nothing in the list above is handed to a website: a site receives the answers it asked for and a one-way token built from your account and that service, which is how it can tell you're one distinct person without learning who you are. For a short time after a share it can also ask us one further question, whether a name it holds matches the name on your ID, and gets yes, partly or no: never the name. Section 2 says what we keep about that. It never receives the underlying record.
2. What we never do
We never sell, rent, or share your personal data with advertisers. We never build a profile of your browsing, and we still cannot tell which websites you visit: a service asks us a question from its own servers, we answer it, and we never see your browser. What we do keep is a record of the shares you make. For each one we hold which service you shared with, when, and the questions it asked us afterwards, though never the name it asked with. That record exists for you: it is how the app shows you who has asked about you, and how you cut a service off. The share record is deleted 90 days after the share, the log of questions two years after each one, and both go the moment you delete your account. We never give either to anyone, including other services. We do have to count how many people verified at each site, for that site's billing; section 13 says exactly what the counting keeps.
If any of this ever changes, it changes on this page first, with a dated note, before it takes effect.
3. The verification check
When you first verify, your device reads the chip in your ID and takes a selfie to confirm the document is yours. Both are sent to us over an encrypted connection so the checks can run: that the chip's signature is genuine, that the face in the selfie matches the one on the chip, and that the document hasn't already opened another account.
The selfie and the document images are deleted once the check completes. What we keep from them is a face vector - numbers that describe your face, not a picture.
If your document has no readable chip, you can choose a paid document check instead. That check is run for us by an outside provider, named in the appendix below: you give it document images and a selfie, it confirms the document is genuine and that the face matches, and it tells us the result. What you give the provider is held under that provider's own retention terms, which we don't control. We still keep no document images and no selfie photos of our own.
4. Decisions made by software
The verification decision is automated: the chip check, the face match and the duplicate check run as software, and the answer a website receives comes from those checks. No human looks at your face or your document during a normal verification.
If a check goes against you and you think it's wrong, you can ask us to look at it: contact the privacy team below and a human will review what happened and tell you the outcome.
5. Age
Verifying with Passwave is for people aged 16 and over. Your age comes from your ID, so the verification check is where this is enforced: if your ID shows you're under 16, the check is refused and the identity details it read are deleted. We keep one thing, worked out from your date of birth before that goes: the date you turn 16. It is there so we can tell you when you can try again, and so the account can't keep retrying before then. We delete it within six months of that date passing. Until then that account can't be verified, though you can still sign in to it and delete it. If your ID shows you're under 13, we keep even less: the whole account is closed and deleted within a day, and nothing about you is retained.
6. Your rights
You can see everything we hold, correct it, export it, or delete it and close your account. You can also ask us to restrict what we do with your data while a question is resolved, and object to processing we base on our legitimate interests. For now these requests run by email; the data requests page explains how, including acting on someone else's behalf.
Deleting your account removes your answers, your hashes, your face vector, the record of your shares, and the ID details we hold for you. Where a law requires us to keep a minimal billing record, we say so on the data requests page and keep only that.
If you're not happy with how we've handled your data, you can complain to the Information Commissioner's Office at ico.org.uk, or to your local data protection authority if you're in the EU. We'd like the chance to put it right first, but you don't need our permission to go to them.
If you use the app to read a chip
7. Reading a document's chip
The Passwave app reads the chip in a passport or identity card and shows you what is stored on it. Reading a chip needs no account, no sign-in and no payment: you never tell us who you are, and we never ask. It is also how we measure how reliably chips can be read across the many different phones people use, which is what the reports in the next section are for.
Everything the chip holds stays on your phone. Your name, document number, dates of birth and expiry, nationality and sex; your face photo and any biometrics; and, where the chip carries them and the app is asked to read them, your address, telephone number, profession, place of birth, personal number, and the document's own images, issuing authority and endorsements. None of it is transmitted, stored on our servers, or included in any report. The screen that shows you those details is drawn entirely on your phone and works with no connection at all.
The document details you scan or type in to unlock the chip stay on your phone too. Where you use the camera, the text recognition runs on the device: camera frames are never uploaded.
8. What the app sends, if you let it
One switch on the app's first screen, "Help improve the reader", governs everything the app can send. It is on by default, and you can turn it off at any time. When it is off, nothing leaves your phone at all, and anything already waiting to be sent is deleted. With it off, the screen after a read offers to turn it back on and send that one report; that is the same switch, and it stays on afterwards until you turn it off again.
When it is on, the app sends an anonymous technical report after each read, successful or not. A report describes four things: how the read went, what the chip and the document declared about themselves, what your phone is, and how you supplied the details that unlock the chip. That last one is worth spelling out, because it is about you rather than about the equipment: a report says whether you used the camera or typed the details in, how long the camera took to lock on, how far the on-device text recognition got, how many attempts you made, and how many captures were given up on without a read. Section A2 lists every field, and how long each one is kept.
No report carries chip contents, document details, images, or a camera frame. The chip's own serial number is never sent, and we never read your phone's serial number, build fingerprint, device name or advertising identifier. The only country in a report is the one that issued the document, or the one whose authority signed it, never one about you. Before you start, the app shows you what a report looks like; after a read that succeeds, you can open the exact report it sends and read it line by line.
Each report carries a fresh random identifier, used only to discard a duplicate if the same report arrives twice. Nothing in a report ties it to another report, or to you: there is no account and no installation identifier, and the facts a report gives about your phone, such as its model and operating-system version, are identical on every handset of that model running the same firmware. One exception is worth stating: when a read is retried, each attempt carries its attempt number, so the retries of a single capture are visible as a sequence. We do not store the address your report arrives from; it is used to rate-limit the receiving endpoint and then discarded.
Read reports go to servers Passwave runs, and are used only to measure device compatibility and to fix defects in the open-source chip reader behind the app. A report is deleted 12 months after it arrives. Before that, the measurements we track over years are copied out of it and kept indefinitely; section A2 marks which those are, and none of them identifies you. Because a report carries nothing that identifies you, we cannot find yours in order to delete it: turning the switch off is what stops them. Anything else you want to ask goes to the address in the contact section at the end of this policy.
The same switch also governs crash reports. If the app stops unexpectedly, it sends a technical report of what went wrong to Sentry, the error-reporting service we use, which stores it in the EU. A crash report says where in the code the app failed, which screens you had moved between and a short trail of app events leading up to it, such as the app going to the background or the phone changing orientation. It also describes the phone: model, make, processor type, operating system version, screen size, memory and storage figures, battery level, language setting and time zone, plus the app's version. Reports are cleaned on your phone before they are sent: no chip contents, no document details, no screenshots, no camera frames, and nothing about who you are. Sentry is set not to keep the address your report arrives from, nor a location worked out from it.
With the switch on, the app also sends Sentry a run record when a run starts and ends, whether or not anything went wrong. That is how we tell what share of runs crash. A run record carries when the run started and ended, whether it ended cleanly, and the app's version.
Unlike read reports, crash reports and run records carry one value that stays the same on your phone: an identifier for that copy of the app. It is a random code the crash-reporting library created the first time the app ran, and it changes if you reinstall. On an iPhone a crash report also carries a one-way hash of the identifier Apple gives our apps on your device. The identifier exists so we can tell one phone crashing repeatedly from many phones crashing once, and so run records from the same phone are counted as one. It is never shown to you, it is not your phone's serial number or advertising identifier, and we cannot turn it back into a person or a phone, so we cannot pick out your crash reports on request either: turning the switch off is what stops them. Crash reports are kept for 30 days. Run records are folded into counts when they arrive and kept for no longer than 90 days. Both are used only to find and fix defects.
If you run a website that uses Passwave
9. Your account
This part covers your own account data as an operator: what we hold about you, not what your integration sends through Passwave. For the data your integration processes, you are the controller and we are your processor; those commitments live in the developer terms. You must be 18 or over to hold an operator account.
To run your dashboard account we hold your email address, your name, and a random account identifier. If you sign in with Google, Facebook or Apple, we also record which provider you used, the identifier and email that provider confirmed, and when you last signed in with it. We don't receive your password from them, and we never post anything on your behalf.
Signing in by magic link works by emailing you a one-time link; the token behind it is stored hashed and deleted within a day of being used or expiring. Signed-in sessions are identified by hashed tokens, expire after 30 days, and expired sessions are purged daily. We don't store your IP address or browser details against your account. Like any web server, ours records them in its access log with every request; we use that log only to detect and block abuse, and it's deleted within 48 hours. The sign-in page also runs the anti-abuse check described in section 16, which passes your IP address to Cloudflare.
10. API keys and projects
API keys are stored hashed: we keep a one-way hash and the first few characters for display, and the key itself is shown to you once and never stored. We record when a key was last used so you can spot stale ones.
Project and organisation names are whatever you type. If yours contain personal data, a sole trader's own name, say, they're covered by this policy too.
11. Billing
Payments are handled by Paddle, our merchant of record: Paddle's checkout takes your payment and we never see your card details. What we hold is your Paddle customer reference, your billing currency, and a record of each transaction: amount, currency, invoice number, description. We keep transaction records for at least six years from the end of the tax year they fall in, because tax law requires it.
When Paddle notifies us about a payment event, we keep only the event's type and its reference identifiers, not the personal details inside it.
12. Cancellation feedback
If you cancel a subscription and tell us why, we keep what you wrote. Write whatever you like, but it's read by a human and kept with your account until the account closes, so don't put anything in it you wouldn't put in an email to us.
13. Usage statistics
We meter your integration's usage with counters and with HyperLogLog sketches: a counting technique that estimates how many distinct people verified without storing a row for any of them. There are no per-person usage rows and no list of your users. A sketch is not a list, but it isn't nothing either: it's built from account identifiers, so it can answer whether a particular account is among the people counted. We hold sketches only to count: daily and hourly statistics, sketches included, are deleted after 90 days, and monthly statistics are kept only as anonymous aggregate numbers with no sketch attached.
14. Our own audit trail
When our staff act on your account through the admin interface, we record who acted, what changed, and the administrator's IP address. This is our accountability record for actions taken on your data, and we keep it for two years.
15. Closing your account
Ask us to close your account and we delete your personal data within one calendar month of verifying the request, keeping only what a listed legal obligation requires: the transaction records above.
For everyone
16. Cookies and local storage
We run no analytics scripts and no advertising, and we set no cookies for either. Your browser holds what signing in requires, your session and basic app state, and nothing that follows you around the web.
One third-party service runs on two pages: Cloudflare Turnstile, on the contact form and the login page, which tells people apart from bots without a puzzle. Turnstile is provided by Cloudflare and can set Cloudflare cookies while it runs. We use it strictly to prevent abuse; it doesn't track you across sites for us, and we see none of what it measures.
17. Who we share data with
The complete list of recipients is in the appendix below: Paddle for developer-plan payments, Mailgun, Amazon SES and Scaleway for sending email, Cloudflare for the anti-abuse check above, our own verification service, Sentry for the Passwave app's crash reports, and, only if you use them, the social sign-in providers. Nobody on that list buys, rents or receives your data for advertising.
If you verify by reading your document's chip, your ID is checked by us, on our own servers, and no identity-verification supplier receives your document, your chip data or your face. If your document has no readable chip and you choose the paid document check instead, the provider running that check receives the document images and selfie you give it, and handles them under its own retention terms. Which route you use is your choice, and the chip route is the default wherever it is available.
Some of these providers process data outside the UK and EEA. Where they do, the transfer is covered by UK adequacy regulations or standard contractual clauses with the UK addendum.
18. Security
Connections to Passwave are encrypted in transit. API keys and session tokens are stored only as one-way hashes, so a copy of our database would not contain them. Usage is counted without per-person records, and staff actions on accounts are logged, with the audit trail this policy describes.
If a breach ever puts you at risk, we'll tell you what happened and what we're doing about it without undue delay, and notify the ICO where the law requires.
19. Changes
If we change what we collect or how we use it, we update the date at the top of this page and note what changed, before the change takes effect. Material changes are also announced in the app. We won't quietly expand this policy.
27 August 2026: crash reporting is being switched on in the Passwave app, and this policy is published ahead of it. The section on what the app sends, its appendix table and the recipients table now describe what a crash report and a run record contain, and name Sentry as the service that receives them.
2 September 2026: a service you share with can now ask us one follow-up question for a limited time, whether a name it holds matches the name on your ID, and we keep a record of your shares so you can see who asked and cut a service off. Section 2 and appendix A1 describe what that record holds and for how long.
5 September 2026: the Passwave app now shows you notifications about your own account, covering what happened to a verification, a document about to expire, a change of sign-in address, and sign-ins. They are kept on your account for 30 days so a new phone still finds them, then deleted. The section on what we collect and appendix A1 say what they hold and for how long.
20. Who we are, and contact
Passwave Ltd is the data controller for the personal data described in this policy: the company legally responsible for it. Registered office: 20 Wenlock Road, London N1 7GU. Registered in England, no. 17354253.
Questions about privacy go to our data protection team, and a human answers.
Passwave Ltd · 20 Wenlock Road, London N1 7GU · Registered in England, no. 17354253
Appendix: the formal detail
A1. If you verify with the Passwave app
The tables below are the formal summary of this policy: what we hold, why, the lawful basis under UK GDPR, and how long it's kept. First, if you verify with the Passwave app:
| What we hold | Why | Lawful basis | Kept for |
|---|---|---|---|
| Email address and account identifier | Running your account | Contract | Until you delete your account |
| The details your ID proved: name, date of birth, legal gender, document type and dates | The answers you prove to sites | Contract | Until you delete your account |
| Face vector from your selfie | Matching your face to your document; one person, one account | Consent | Until you delete your account |
| Document images and your selfie | Running the verification check | Contract | Deleted when the check completes. On the paid document check, the provider running it keeps its own copy under its own retention terms |
| Derived answers and anti-duplication hashes | Answering sites; preventing duplicate accounts | Contract | Until you delete your account |
| A record of each share you make: the service, when, and a one-way hash of the code it can use to ask about you later | Letting a service ask a follow-up question for a limited time; letting you see and revoke it | Contract | 90 days from the share; deleted with your account |
| The follow-up questions services asked: which service, what it asked, when, and the answer, never the name it asked with | Showing you who has asked about you | Contract | 2 years from each question; deleted with your account |
| Notifications we send you in the app: what happened to a verification, that one of your documents is about to expire, that your sign-in address changed, that a sign-in happened, and any message we send you ourselves | Telling you what happened on your account, and letting a new phone show it to you again | Contract | 30 days from the notification; deleted with your account |
| Billing token (subscribers only) | Passwave Plus billing | Contract | While you subscribe, plus any legally required billing record |
| The date an under-16 applicant turns 16 | Enforcing the minimum age; telling the applicant when they can verify | Legitimate interests | Until six months after that date passes; if the ID showed under 13, the whole account is deleted within a day instead |
A2. If you use the app to read a chip
And if you use the app to read a document's chip. Everything here arrives only while "Help improve the reader" is on, and nothing in it identifies you:
| What we hold | Why | Lawful basis | Kept for |
|---|---|---|---|
| How the read went: success or failure, the error code and the step that failed, the chip's status word, whether BAC or PACE was used and with which parameters, the document type, and the app's own self-check on the read | Measuring how reliably chips read, and finding the failures worth fixing | Consent | Indefinitely |
| The country that issued the document. Nothing else read from the document is sent | Telling which countries' documents read reliably | Consent | Indefinitely |
| How you supplied the details that unlock the chip: camera or typed, how long the camera took to lock on, how far the on-device text recognition got, and how many captures were given up on without a read. Never the details themselves, and never a camera frame | Judging whether the camera path works in the field, and whether a release improved it | Consent | Indefinitely |
| The rest of that picture: the photo-capture stage reached, how many photo attempts were made, the last stage of a capture you gave up on, whether the app offered help because the scan was struggling, and how long the camera took to release | Diagnosing one difficult capture | Consent | 12 months |
| How long each stage of the read took, and how many times each step had to be retried | Finding what is slow, and whether a release changed it | Consent | Indefinitely |
| Your phone: model, make, hardware name, operating system and version, and the app's version. We do not read your phone's serial number, build fingerprint, device name or advertising identifier | Telling which handsets and operating-system builds read chips reliably | Consent | Indefinitely |
| The rest of the phone's build: the Android security-patch month, the processor architectures it supports, and whether it is a real handset or an emulator | Interpreting one failure against the build the phone was running | Consent | 12 months |
| What the chip declares about itself: which contactless standard it speaks, the buffer sizes it states, the file names its security object declares (the names, never the contents), that object's size, version and signature algorithm, and the format of the face record. The chip's serial number is never sent, and neither is the photo | Telling which chips, and which decoders, phones cope with | Consent | Indefinitely |
| The chip's identification bytes from when it is first detected, the face record's pixel size, colour space and quality figure, and which optional files the app asked for that the chip did not have | Diagnosing one failed read | Consent | 12 months |
| The result of the app's on-device signature check and its cause, the version of the certificate list bundled with the app, and, from the certificate that signed the document, the year it was created and its key algorithm and size. Those are facts about a signing batch, shared by every document issued at that time | Telling how often documents verify against the list we ship, and when to refresh it | Consent | Indefinitely |
| The issuing authority's own certificate facts: its country code (the authority's, not yours), the year its signing batch was created, and its key size and curve | Interpreting one read that could not be verified | Consent | 12 months |
| A random identifier, fresh for every report | Discarding a duplicate if a report arrives twice | Consent | With the report it belongs to |
| Crash reports: where in the code the app failed, the screens you had moved between and the app events leading up to it, and the phone's model, make, processor type, operating system version, screen size, memory and storage figures, battery level, language setting and time zone, plus the app's version | Finding and fixing defects | Consent | 30 days |
| Run records: when a run started and ended, whether it ended cleanly, and the app's version | Telling what share of runs crash | Consent | No longer than 90 days |
| An identifier for that copy of the app: a random code created the first time the app ran, and on an iPhone a one-way hash of the identifier Apple gives our apps on your device. Carried by every crash report and run record from that phone | Telling one phone crashing repeatedly from many phones crashing once, and counting run records from the same phone as one | Consent | With the report or record it belongs to |
A3. If you run a website
And if you run a website that uses Passwave:
| What we hold | Why | Lawful basis | Kept for |
|---|---|---|---|
| Email, name, sign-in identities | Running your account, signing you in | Contract | Life of the account; deleted within one calendar month of a verified closure request |
| Magic-link tokens (stored hashed) | Passwordless sign-in | Contract | 1 day after use or expiry |
| Sessions (hashed tokens) and login records | Keeping you signed in | Contract | Sessions expire after 30 days and are purged daily; login records go 90 days after invalidation |
| API keys: hash, prefix, name, last used | Authenticating your servers | Contract | Life of the key |
| Organisation and project names | Running your integration | Contract | Life of the account |
| Paddle customer reference and transactions | Billing and tax records | Contract; legal obligation | At least 6 years from the end of the tax year |
| Payment webhook events (references only) | Reconciling billing state | Contract | 90 days |
| Cancellation feedback | Improving the service | Legitimate interests | Until the account closes |
| Admin audit log, including the administrator's IP address | Security and accountability | Legitimate interests | 2 years |
| Usage statistics | Metering and capacity planning | Contract; legitimate interests | Daily and hourly deleted at 90 days; monthly kept as anonymous aggregates |
| Failed background jobs | Reliability and debugging | Legitimate interests | 30 days |
| Sync bookkeeping | Keeping usage counts consistent | Legitimate interests | 1 day |
A4. Who receives data
Everyone who receives personal data from us, and why:
| Who | What for | Notes |
|---|---|---|
| Paddle | Developer-plan payments, as our merchant of record | A developer plan's purchase contract is with Paddle |
| Mailgun | Sending our transactional email | EU endpoint |
| Amazon SES | Sending our transactional email | EU region; transfers covered by the AWS data processing addendum |
| Scaleway Transactional Email | Sending our transactional email | France; data stays in the EEA |
| Cloudflare | The Turnstile anti-abuse check | Contact form and login pages only |
| Passwave's verification service | Running the verification checks | Operated by Passwave Ltd; described in Part 1 |
| Sumsub | Running the paid document check when your document has no readable chip | Only if you choose that route |
| Google, Facebook or Apple | Social sign-in | Only if you choose to sign in with them |
| Sentry | Receiving crash reports and run records from the Passwave app | EU region (Frankfurt). Only while "Help improve the reader" is on in the app |
A5. Rights and complaints
Access, rectification, erasure, portability, restriction, objection: how to exercise each of them is on the data requests page. Complaints go to the Information Commissioner's Office at ico.org.uk, or to your local supervisory authority if you're in the EU. Chip-read reports are the exception: they carry nothing that identifies you, so there is nothing of yours for us to find, correct or erase. Turning "Help improve the reader" off is how you stop them.