Data Processing Addendum (DPA)
Version 2026-07-11 · Effective July 11, 2026
Rillis — Data Processing Addendum (DPA)
Version: 2026-07-11 · Effective as of: July 11, 2026 This DPA is incorporated into and supplements the Master Terms. In the event of a conflict regarding the processing of personal data, this DPA prevails.
Courtesy translation. This English version is provided for convenience. The Spanish version is the legally binding text and prevails in case of any discrepancy.
Framework. Rillis operates as a multi-jurisdictional network across the Americas (with a global ambition). This DPA is built on the framework of Article 28 GDPR (portable to most regimes), with a jurisdiction rider (Appendix 3) that activates local requirements (Brazil’s LGPD, Chile’s Law 21.719, Mexico’s new LFPDPPP, Colombia’s Law 1581, Argentina’s Law 25.326, the CCPA/BIPA, and U.S. state laws) and a resilience rider (Appendix 4) for regulated financial clients (e.g., DORA).
1. Definitions and Roles
1.1 Terms. “Controller,” “Processor,” “Sub-processor,” “Data Subject,” “Personal Data,” “Sensitive/Special Category Data,” “Processing,” “Personal Data Breach,” and “International Transfer” have the meaning given under applicable data protection law.
1.2 Ordinary roles. With respect to the verification and screening Services provided on the Client’s behalf, the Client is the Controller and Rillis is the Processor. Rillis processes Personal Data solely in accordance with the Client’s documented instructions (these Terms, the DPA, the Order Form, and the Platform configuration).
1.3 Roles within the Single Verification Network. For each reuse operation: (a) the Donor and the Recipient act as independent controllers with respect to each other; (b) Rillis acts as Processor for each of them with respect to the data it processes on their behalf, and as independent controller solely with respect to the Network infrastructure (matching by verified identifier, consent logging, immutable audit records, and integrity attestation). Details are set out in Appendix 2.
1.4 Rillis as independent controller. Rillis acts as its own Controller only with respect to data it processes for its own legitimate purposes of operation, security, billing, its own compliance, and improvement of the Services using de-identified/aggregated data, in accordance with its Privacy Policy.
2. Object, Duration, Nature, and Purpose of Processing
The details required under Article 28(3) GDPR and its equivalents are set out in Appendix 1 (object; duration; nature and purpose; types of Personal Data, including biometric data as special/sensitive category data; and categories of Data Subjects).
3. Obligations of the Processor (Rillis)
Rillis undertakes to:
3.1 Documented instructions. Process Personal Data only in accordance with the Client’s documented instructions, including international transfers, unless required by law (in which case it will inform the Client before processing, unless prohibited by law on public-interest grounds).
3.2 Confidentiality. Ensure that persons authorized to process Personal Data have committed to confidentiality or are under an equivalent statutory duty.
3.3 Security (Art. 32). Implement appropriate technical and organizational measures (Appendix 5), including encryption in transit and at rest, RBAC, strong authentication, audit logging, minimization, and protection of biometric templates (irreversibility, unlinkability, and renewability in accordance with ISO/IEC 24745; presentation-attack detection in accordance with ISO/IEC 30107-3; and documented accuracy/PAD metrics in accordance with NIST SP 800-63A/B and ISO/IEC 19795-1, including demographic differential testing).
3.4 Sub-processors. Comply with the conditions of Article 28(2) and (4): the Client grants general authorization for the use of the Sub-processors listed in Appendix 6; Rillis will give reasonable advance notice of the addition or replacement of Sub-processors, giving the Client the opportunity to object on reasonable data protection grounds; will impose equivalent contractual obligations on each Sub-processor; and will remain fully liable to the Client for their performance.
3.5 Assistance with Data Subject rights. Assist the Client, through appropriate technical and organizational measures and insofar as possible, in responding to requests to exercise rights (access, rectification, erasure, objection, portability, restriction, and rights regarding automated decisions).
3.6 Assistance with security, breaches, and assessments (Arts. 32–36). Assist the Client in complying with its security obligations, breach notification, impact assessments (DPIAs), and prior consultations, taking into account the nature of the processing and the information available.
3.7 Breach notification. Notify the Client without undue delay and, in any event, within 72 hours of becoming aware of a Personal Data Breach, with the information reasonably available so the Client can meet its own regulatory deadlines.
3.8 Return or deletion. At the Client’s election, return or delete Personal Data upon termination of the Services and delete existing copies, unless legally required to retain them (see Section 6).
3.9 Demonstration and audit. Make available to the Client the information necessary to demonstrate compliance and allow for and contribute to audits and inspections by the Client or an auditor it designates (and by competent authorities, as set out in Appendix 4).
3.10 Duty to warn. Immediately inform the Client if, in its view, an instruction infringes applicable data protection law.
4. Obligations of the Controller (Client)
The Client: (a) warrants that it holds a valid legal basis and the necessary consents and notices with respect to Data Subjects, including biometric data; (b) will issue lawful instructions; (c) is responsible for the accuracy and lawfulness of the Client Data; (d) will comply with its own breach notification, DPIA, and rights-handling obligations as Controller; and (e) for decisions producing legal or similarly significant effects, will maintain meaningful human review and offer the human intervention mechanisms required by applicable law (Art. 22 GDPR and its analogues).
5. Legal Basis for Biometric Data and Automated Decisions
5.1 Biometric basis. The processing of biometric data requires an exception under the special/sensitive category regime. Depending on the jurisdiction (Appendix 3), the basis may be the Data Subject’s explicit consent (universal), and/or — where the law permits and as an alternative or concurrent basis — fraud prevention and security in identification and authentication processes (e.g., Art. 11(II)(g) of Brazil’s LGPD) or substantial public interest with a legal basis (e.g., Art. 9(2)(g) GDPR). The Client determines and documents the applicable basis; Rillis logs and versions the consent to provide auditable proof.
5.2 Automated decisions. Where Results feed into decisions producing legal or similarly significant effects (e.g., approval/rejection of onboarding, offboarding, or scoring on which the Controller “relies in a determinative manner”), the Client will ensure the existence of an enabling legal basis and safeguards (meaningful information about the logic, human intervention, expression of viewpoint, and challenge). Rillis will provide transparency artifacts (model cards, factors and logic at an intelligible level), logs, and re-review tools so the Client can meet those obligations.
6. Retention and Deletion — Reconciling with Regulatory Retention (FATF)
6.1 AML/minimization tension. AML/CFT rules (the FATF standard, Recommendation 11) require retaining identity/KYC records for at least five (5) years from the end of the relationship or the occasional transaction, with the local period potentially reaching ten (10) years (e.g., BCB Circular 3,978/2020 in Brazil; Article 115 of the Credit Institutions Law and CNBV provisions in Mexico; the extension from 5 to 10 years under the EU AML package — Regulation (EU) 2024/1624, applicable from July 10, 2027; 31 CFR 1010.430/1020.220/1020.320 in the U.S.). Minimization and the right to erasure coexist with that obligation through:
(a) Purpose-based, per-Controller retention anchored in a legal obligation. Each Controller determines and retains evidence according to its own regulatory period (configurable per organization on the Platform; 5 years FATF by default, adjustable up to 10 depending on jurisdiction/sector), on the legal-obligation basis (not consent), such that retention survives withdrawal of consent. Deletion requested by the Data Subject does not override that obligation; in that case, the data is moved to a segregated, access-restricted legal-hold store, is blocked/restricted from any use other than legal retention, and is irreversibly deleted or anonymized upon expiry of the period. This carve-out is reflected in the return/deletion clause (Art. 28(3)(g) GDPR: the Processor deletes or returns data upon termination of the service “unless [applicable] law requires storage of the personal data”).
(b) Biometric minimization. Rillis derives and retains irreversible/renewable biometric templates and deletes raw samples (images/audio) once verification is complete, unless instructed otherwise by the Controller. Self-deletion occurs upon fulfillment of the purpose and, in any event, within the strictest applicable outer limits (e.g., 1 year Texas / 3 years BIPA for biometric possession; and “no longer than necessary” under GDPR/local laws).
(c) Public biometric retention/destruction policy. Rillis maintains and makes available a retention and destruction policy for biometric identifiers with a schedule, and offers the Client configurable windows and certificates of destruction/cryptographic erasure.
6.2 Interaction with the blockchain seal. The on-chain hash is not deleted (technical impossibility). Each seal incorporates a random value (“salt”) kept off-chain; once the evidence and the off-chain salt are deleted, the residual hash can no longer be linked to an identifiable person and does not constitute personal data, consistent with data protection authorities’ guidance on blockchain. Immutable audit records are retained without plaintext personal data. (Note: treatment of the hash as personal data where it lacks a salt must be validated against the applicable authority’s current guidance; see the foundations memo.)
7. International Transfers
7.1 Principle. Every International Transfer will be carried out under a valid mechanism in accordance with the law of the exporting country (Appendix 3), including: adequacy decisions; standard contractual clauses (EU SCCs — Decision (EU) 2021/914; Brazilian SCCs — ANPD Resolution CD/ANPD 19/2024, mandatory upon expiry of the grace period; UK IDTA/Addendum); binding corporate rules; or, exceptionally and non-repetitively, derogations (e.g., explicit consent to the transfer).
7.2 Transfer assessment. Where SCCs/the IDTA are used, the exporting party will carry out the transfer impact/risk assessment and adopt supplementary measures where necessary.
7.3 Cross-border reuse within the Network. Where a reuse involves an international transfer, it will be covered by the mechanism applicable to the relevant pair of jurisdictions (matrix documented per network, Appendix 2/3) and will be reflected in advance in the Verified Person’s consent.
8. Appendices
- Appendix 1 — Processing details (Art. 28(3)): object, duration, nature/purpose, types of data (incl. biometric), categories of Data Subjects.
- Appendix 2 — Single Verification Network Annex (reuse): categories, Donor→Recipient communication operation, roles per operation, legal basis, transfers, retention and blockchain seal, network security, rights handling.
- Appendix 3 — Jurisdiction rider (Brazil, Chile, Mexico, Colombia, Argentina, U.S., EU/UK).
- Appendix 4 — Resilience rider for financial clients (DORA / outsourcing / regulator audits).
- Appendix 5 — Technical and organizational security measures.
- Appendix 6 — List of Sub-processors.
Appendix 2 — Single Verification Network Annex (the 5 points of reuse)
(1) Data categories and new operation. The “verification evidence set” is added as a category (declared identity data; document images; facial image/template — biometric/sensitive data; capture metadata; verified network identifier = email), and “Donor→Recipient communication following a match by verified identifier and Data Subject consent” is added as a new operation. Results are expressly EXCLUDED from any communication.
(2) Roles per operation. (a) Ordinary verification: Client = Controller, Rillis = Processor. (b) Reuse: Donor and Recipient = independent controllers with respect to each other; Rillis = Processor for each + independent controller for the network infrastructure. It specifies who handles each Data Subject right (rule: each Controller handles rights regarding the processing under its control; Rillis provides technical assistance and handles matters relating to the network infrastructure).
(3) Legal basis and transfers. The Data Subject’s explicit consent as the basis for the communication and for the biometric data; for cross-border reuses, the transfer mechanism applicable to the pair of jurisdictions, documented per network. Consent is given per reuse and per recipient; its withdrawal switches off future reuses without affecting processing already completed or the Recipient’s legal retention.
(4) Retention and deletion (incl. blockchain seal). (a) Each Controller retains data according to its own period (5 years FATF default). (b) Deletion at the Data Subject’s request operates off-chain: the evidence is deleted and the Controllers are notified. (c) The on-chain hash is not deleted; once the evidence and the off-chain salt are deleted, it can no longer be linked to a person. (d) Immutable audit records without plaintext personal data.
(5) Sub-processors and network security. Sub-processors in the reuse flow: OCR/biometrics provider; email provider for the OTP code; cloud provider; (the blockchain is declared a ledger technology receiving a non-personal hash, not a Sub-processor). Network-specific measures: 1:1 biometric match with a minimum threshold and liveness detection; anti-enumeration (the code is requested before revealing whether a match exists; uniform responses); encryption at rest; access without duplicating data; and an immutable audit record per reuse.