Privacy, consent and retention

When your organization runs KYC, KYB or AML checks through Zyphe, you are the controller of the verification data and Zyphe is your processor, acting on your documented instructions under a data processing agreement (DPA). You choose the lawful basis for the check, tell your end users about it and keep your own compliance record. Zyphe retains verification results, audit logs and cryptographic proofs; identity documents and biometrics are processed transiently, then encrypted and stored in the end user's own vault rather than in a central Zyphe database.

Sources and scope

This page gathers, for integrators, what these docs and Zyphe's public GDPR statement say about roles, consent, retention and deletion. The GDPR statement restates the DPA, which you can request from privacy@zyphe.com. This page is not legal advice.

Your side and Zyphe's side

Topic	You, as controller	Zyphe, as processor
Role	Controller of the verification data your checks produce	Processor, acting on your documented instructions under the DPA
Lawful basis	You decide the legal basis on which your customers are verified	Processes on your instructions; does not supply the basis
Notice to end users	Your privacy notice says that a verification provider processes their document and face on your behalf	Processes the document and face on your behalf, on your instructions
Biometric data	Cover facial processing in your notice and, where required, in your impact assessment	Processes facial images as special category data, on the person's explicit consent collected at the point of verification
Retention	Your own anti-money-laundering record of the check, typically kept for five years, plus any copies you export	Verification results, audit logs and cryptographic proofs, for the term of the agreement or as required by law
Erasure	Receive and route requests under your own data protection procedures	Executes erasure by revoking access to the encrypted shards, then deletes data as retention obligations lapse
Decisions	The customer risk profile, the decision to enter or end a relationship, reports to the financial intelligence unit, and the agent mode on each step	Runs the automated checks and, depending on the agent mode you set, prepares or enacts reviews
Impact assessment	Yours, if your processing requires one	Supplies the DPA, its annexes and answers on request
Data residency	Nothing to configure	Stores data regionally, following the end user's location

Roles

Zyphe touches two kinds of personal data, and the roles differ:

• Verification data. When you run a KYC, KYB or AML check, the identity data belongs to your relationship with your customer. You are controller; Zyphe processes it under the DPA to return a verification result to you.
• Zyphe's own website, lead and hiring data. Zyphe is controller of that data, as set out in its privacy policy.

Inside your organization, who can see verification data is governed by roles. See PII Access Control for the principles and Manage Users for the permission matrix.

Biometric data and consent

A facial image used to identify a person uniquely is special category data under Article 9 of the GDPR. According to the GDPR statement, Zyphe processes it:

• on the person's explicit consent, collected at the point of verification;
• only to match the face to the document, and not for any other check;
• without using it to train models;
• without disclosing it to anyone other than the company that asked for the verification;
• with destruction within the limits set by BIPA and CUBI, as recorded in section 10.3 of the DPA.

Liveness, face matching and injection-attack detection run in-house rather than through a third-party biometric vendor. The live portrait captured by the liveness step is stored in the user's vault.

Optional biometric uniqueness checks

The liveness step can also run a biometric uniqueness check that detects one person verifying under several identities. It runs in a privacy-preserving way and is off unless Zyphe support enables it for your flows. If you enable it, describe it in your notice and impact assessment; the GDPR statement covers it.

When a user's vault is created, the user is asked to grant permission to store their personal data. See Creation of the User Vault.

What Zyphe retains

Kept by Zyphe

Data	How long, or in what form
Verification results, audit logs and cryptographic proofs	For the term of the agreement or as required by law
Screening identifiers	Only while ongoing monitoring is switched on for that customer
Phone numbers from phone verification	As a SHA-256 hash, with only the last four digits in plain text
TINs from TIN Check and EINs checked on KYB	The last four digits only; the full number is used for the lookup and discarded
AML scoring inputs	Matched topics, jurisdictions, positions, relationships and assigned tags, kept with the result so the score can be re-explained (Risk scoring)
Webhook delivery records	90 days by default, then purged (Webhook Endpoints)

Not held in a central Zyphe database

Identity documents and biometrics are processed transiently, then encrypted with AES-256, split into shards and stored in the end user's own vault. When the user shares that data with an organization, Zyphe re-encrypts the ciphertext for the recipient through proxy re-encryption, without access to the plaintext, and revoking the access deletes the re-encryption key. See Data Sharing and Encryption and Why decentralized PII storage.

When Flow Builder routes on fields from vault documents (such as age or nationality), the workflow keeps only the outcome needed to continue the flow. See Conditions with custom data and vault fields.

Copies that reach you

Data you receive is held under your controls and your retention rules:

Channel	What it can carry
Webhooks	The PII level you configure: no PII (recommended), an identifier only, or PII when you opt in. The Extended Webhook adds extracted document fields and a time-limited selfie URL. See PII Access Control
Export API	Full result details and media: document images, portrait and selfie captures, a liveness video URL and proof-of-address files. Download them promptly and store them under your own access controls
Dashboard	Results and cases, visible according to each member's role
KYC Passport partners	Data a partner has already accessed stays with that partner until its own retention obligations are met

Deletion and erasure

Erasure is executed by revoking access to the shards, because the record is held in the data subject's vault rather than copied onto Zyphe servers. The Data Deletion flow:

1. The user submits a deletion request.
2. Zyphe checks the retention obligations of every recipient.
3. Access that is no longer needed is revoked at once.
4. Data is marked for deletion once every remaining obligation has expired.
5. The user receives an immediate confirmation that the request is in progress.
6. Every 24 hours, Zyphe re-evaluates the obligations, revokes newly ineligible access and deletes data whose retention period has lapsed.
7. The user is notified when deletion is complete.

What stays on your side:

• Your own record. Anti-money-laundering law can require you to keep your record of the check, typically for five years. Zyphe erasing the identity data does not shorten that obligation.
• KYC Passport. Users cannot revoke their sharing consent directly; they request deletion through your data protection procedures, and you revoke partner access as appropriate. Users are not notified automatically when you revoke a partner. See the KYC Passport FAQ.
• Expiry notices. A KYC_RESULT_EXPIRED notification (verification.kyc.expired) tells you when a KYC result has passed its retention or validity window. See Statuses and codes.

Deleting a result from the dashboard is a sandbox testing aid for re-running a flow, not the erasure path; it is not offered in production. See Deleting sandbox results.

Data subject rights requests go to privacy@zyphe.com. The GDPR statement says they are answered within one month, extendable by two further months for complex requests.

Where data is processed and stored

Storage is regional and follows the end user's location:

End user	Processed and stored in
EEA and UK	EEA and UK nodes and cloud regions
United States	US regions

Residency is enforced by the storage layer, as a property of where the encrypted shards live, rather than a per-market setting you configure. The shards are geo-locked, so, as the GDPR statement puts it, a Swiss customer's data stays in Switzerland. Identity verification data does not normally leave the region it was collected in. Where a transfer mechanism is needed, the DPA includes the Standard Contractual Clauses and the UK Addendum.

Sub-processors and the DPA

The DPA includes Annexes I to III (subject matter and duration, technical and organisational measures, and the sub-processor list), the Standard Contractual Clauses and the UK Addendum. The sub-processor list is Annex III, including the register-data supplier used for business verification, and is available on request at privacy@zyphe.com. The agreement and its annexes are part of the customer contract, so they are provided on request rather than published.

Points for your data map that the docs state:

• AML screening shares only the minimum necessary attributes with the screening engine and with third-party sanctions, PEP and adverse-media data sources (AML overview).
• Phone verification sends the one-time code by SMS through AWS SNS (Phone verification).
• SPID / CIE attributes come from the user's identity provider (SPID / CIE).

For what each check is checked against, see Verification types: Data sources.

Zyphe is not yet SOC 2 or ISO/IEC 27001 certified; both audits are in progress. The current status is on zyphe.com/security.

Automated decisions and human review

Article 22 of the GDPR constrains decisions based solely on automated processing that produce legal or similarly significant effects on a person, and the EU anti-money-laundering regulation, Article 18(3), reserves the customer risk profile, the decision to enter a business relationship and reporting to the FIU to the obliged entity. How much a person decides in your setup depends on the configuration you choose:

Check	What is automated	Where a person decides
Document, liveness, proof of address and the other flow steps	Each step's checks return PASSED or FAILED automatically	A document verification result that automated checks cannot finalize goes to manual review by an Admin or Operator
AML screening	With AML Agent Mode on Auto-pilot, the agent may clear a hit when a deterministic guard also passes	Disabled: operators review every hit. Suggest: clears are suggestions a person confirms. The agent never overturns a human verdict, and never auto-clears a high-confidence sanctions match or a Critical risk (AML Agent Mode)
KYB	With KYB Agent Mode on Auto-pilot, the agent may approve under the same rules as a person	A clean company is not approved on its own: it waits in READY_FOR_REVIEW for a reviewer, or for the KYB agent in Auto-pilot. Your approval matrix sets who may decide; an agent or API key can take a first signature, never the second
Transaction Monitoring	Each payment gets a synchronous Allow, Review or Block from your rules	Your platform acts on the verdict, and raised alerts go to your webhook for your own case management. The TM agent is fixed to Disabled

The agent mode on each step, and what your product does with an automated FAILED or BLOCK, are your decisions as controller.

Auto-pilot is switched on per category by your organisation, after you have validated the agent's results on that category. Every agent action is logged with its rationale, and your MLRO keeps final sign-off and responsibility.

KYC Passport and reusable credentials

Sharing a verification with another organization always runs on the user's consent:

• Reusable credentials. The user unlocks their vault and agrees to share an eligible credential; the company receives an access grant. See Reusable Credentials.
• KYC Passport. During verification, the consent screen lists your organization, every partner invited at that moment, and the types of data shared. Consent is specific to the flow; partners invited later get no access to that user's data; without consent no partner grant is created. See User Consent and Privacy and KYC Passport.

A partner organization that accepts an invitation needs a legal basis for processing the shared data, privacy notices for end users where needed, a way to honour user rights, and proper data processing agreements with its partners (Accepting Partner Invitations). How long sharing consent lasts follows your privacy policy and data retention policy (KYC Passport FAQ).

Example end-user notice

Example only

Adapt this with your legal counsel; it is not legal advice. Fill in the bracketed parts. The rest restates Zyphe's GDPR statement, so remove anything that does not match your setup, and add optional features you enable, such as biometric uniqueness checks or KYC Passport sharing.

To verify your identity, [Company] uses Zyphe as a verification provider. Zyphe processes your identity document and an image of your face on our behalf and on our instructions. The legal basis for this check is [lawful basis]. Your facial image is processed only with your explicit consent and only to match your face to your document; it is not used to train models or for any other check. Your document and images are processed transiently, then encrypted and stored in your own Zyphe vault rather than in a central database. Zyphe keeps the verification result, an audit log and a cryptographic proof for the term of our agreement with Zyphe or as required by law. [Company] keeps its own record of the check for [period] as required by [law]. Your verification data is processed and stored in [the EEA and the UK / Switzerland / the United States], following your location. [Describe who reviews the outcome of your application.] To exercise your rights, contact [contact].

Documents you can request

Ask privacy@zyphe.com for any of these:

Document	Contents
Data processing agreement	Annexes I to III, the Standard Contractual Clauses and the UK Addendum
Sub-processor list	Annex III of the agreement, including the register-data supplier used for business verification
Penetration test schedule and latest report	Available to customers under NDA
Certification status	The current status of the SOC 2 and ISO/IEC 27001 audits and the control documentation behind them

Related

• GDPR statement and Security and trust on zyphe.com
• Data Deletion: the deletion sequence
• PII Access Control: roles and webhook PII levels
• Data Sharing and Encryption: how access grants work
• Verification types: every check, what it returns and what it is checked against
• Sandbox and go-live: the privacy items on the go-live checklist