Data Processing Agreement

Between the Parties

[Customer] — company name, registered office, and authority of representation as per the registration data stored in the Flonk dashboard

– hereinafter "Controller" or "Customer" –

and

SIA "Flonk Identity"
Piekrastes iela 41A – 120
LV-5422 Daugavpils, Latvia
represented by Member of the Board Maksims Baduļins
Commercial register: Komercreģistrs (Latvia), No. 40203761523

– hereinafter "Processor" or "Flonk" –

– jointly the "Parties", individually a "Party" –

Preamble

The Controller uses the Software-as-a-Service platform for digital identity verification provided by the Processor under the "Flonk" brand at the domain https://flonk.id (hereinafter the "Flonk platform" or "Service"). In the course of providing the Service, the Processor processes personal data on behalf of the Controller subject to instructions, within the meaning of Art. 4(8), Art. 28 of Regulation (EU) 2016/679 (General Data Protection Regulation — "GDPR").

This agreement specifies the data protection obligations of the Parties arising from processing on behalf within the meaning of Art. 28 GDPR. It applies to all activities related to the main contract (General Terms and Conditions, enterprise contract, or other agreement on the use of the Flonk platform — "Main Contract") in which the Processor's staff or sub-processors engaged by it process personal data of the Controller.

§ 1 Subject Matter and Term

(1) Subject Matter. The subject matter of this DPA is the processing of personal data of End Users of the Controller (in particular persons identifying themselves via the Flonk platform — hereinafter "End Users" or "data subjects") by the Processor for the purpose of providing the Services described in the Main Contract, in particular:

• a) reading and authenticity check of official identity documents;
• b) biometric 1:1 matching (selfie ↔ document photo);
• c) liveness detection;
• d) provision of API, SDKs, webhooks, and dashboard;
• e) documentation and reporting of verification results;
• f) where the Controller enables it, screening of End Users against sanctions, PEP and watchlists and adverse media, including ongoing monitoring (AML screening).

(2) Term. The term of this DPA corresponds to the term of the Main Contract. Obligations that by their nature are intended to continue beyond the term (in particular confidentiality, return/erasure of data, cooperation in official proceedings) shall remain in force after termination.

(3) Precedence. This DPA takes precedence over the provisions of the Main Contract on data protection matters. Otherwise, the provisions of the Main Contract apply in addition.

§ 2 Nature and Purpose of Processing

(1) Nature of Processing. Processing comprises in particular: collecting, recording, organising, structuring, storing, adapting, altering, retrieving, consulting, using, disclosing by transmission, dissemination, or otherwise making available, alignment or combination, restriction, erasure, or destruction (Art. 4(2) GDPR).

(2) Purpose of Processing. Processing is carried out exclusively for the purpose of digital identity verification of the Controller's End Users and for the provision, operation, and further development of the technical infrastructure required for this, including security, fraud prevention, and audit purposes. Where the Controller enables AML screening, processing also serves to screen End Users against sanctions, PEP and watchlists and adverse media on the Controller's instruction, in support of the Controller's obligations to prevent money laundering and terrorist financing (AML/CFT). The Processor does not inform End Users of potential matches; reviewing matches and any further steps towards the End User are the Controller's responsibility under its own AML obligations.

(3) No Independent Purposes. The Processor does not carry out processing for its own purposes; this excludes anonymised statistical analyses and the improvement of models and algorithms on the basis of fully anonymised data, provided that no conclusions can be drawn about individual persons.

§ 3 Types of Personal Data and Categories of Data Subjects

(1) Categories of Data Subjects. End Users of the Controller who have themselves verified via the Flonk platform; where applicable, employees/authorised persons of the Controller using the dashboard.

(2) Categories of Data:

• a) Identification and master data: first/last name, birth name, date of birth, place of birth, country of birth, nationality, gender, address, signature.
• b) Identity document data: document type, document number, issuing authority, issue and expiry date, MRZ data, NFC chip data, security features.
• c) Biometric data (Art. 9(1) GDPR): photo from the document, live selfie(s), video / 3D depth data for liveness, biometric templates.
• d) Verification / result data: session ID, timestamp, result (successful/rejected/manual review), confidence and risk scores.
• e) Technical metadata: IP address, device type, operating system, browser, device fingerprint, language, approximate location.
• f) Communication / mapping data: reference IDs, email addresses, and other client metadata transmitted by the Controller.
• g) Dashboard user data: name, business email, role, login data, access logs.
• h) AML screening data (only where the Controller enables AML screening): name, date of birth, and nationality from the identity document; potential matches returned by the screening provider (including list source and category), match assessment, adverse media results, and review decision. Only the name is transmitted to the screening provider, together with a pseudonymous verification ID where ongoing monitoring is enabled; date of birth and nationality are not transmitted.

(3) Special Categories. As biometric data is processed for unique identification, special categories of personal data within the meaning of Art. 9 GDPR are involved. The Controller ensures that a valid legal basis exists pursuant to Art. 9(2) GDPR (typically explicit consent pursuant to Art. 9(2)(a) GDPR).

§ 4 Responsibility and Right of Instruction

(1) Responsibility. The Customer is the controller within the meaning of Art. 4(7) GDPR. The Processor processes personal data exclusively within the scope of the contractually agreed services and on documented instructions of the Controller, unless required to process by Union or Member State law to which it is subject; in such case, the Processor shall inform the Controller of these legal requirements before processing, unless the law in question prohibits such information on important grounds of public interest.

(2) Instructions. Instructions are in principle issued in text form by persons authorised for this purpose. Oral instructions must be confirmed in text form without undue delay. Standard instructions result from the parameters laid down in the Main Contract, the documentation, and the API configuration (e.g. workflow settings in the dashboard).

(3) Notice of Unlawfulness. If the Processor is of the opinion that an instruction infringes data protection law, it shall inform the Controller thereof without undue delay (Art. 28(3) sentence 3 GDPR). The Processor is entitled to suspend execution of the relevant instruction until confirmation or modification by the Controller.

(4) Contact Persons. The Parties shall each designate competent contact persons for data protection matters. The Processor has designated a contact for data protection matters; contact details are provided in the dashboard and on request.

§ 5 Obligations of the Processor

The Processor undertakes in particular as follows:

(1) Processing in accordance with the GDPR. Processing exclusively within the scope of the documented instructions of the Controller and in accordance with Art. 28, 29, and 32 GDPR.

(2) Confidentiality (Art. 28(3)(b) GDPR). All persons engaged in data processing are committed to confidentiality, unless they are already subject to an appropriate statutory duty of confidentiality, and to compliance with data secrecy.

(3) Technical and Organisational Measures (Art. 32 GDPR). Implementation and maintenance of the technical and organisational measures (TOMs) defined in Annex 1. The measures may be further developed in line with the state of the art but must not fall below the agreed level of protection.

(4) Support of the Controller (Art. 28(3)(e) and (f) GDPR). Support in fulfilling obligations under Art. 12–22 GDPR (data subject rights) and Art. 32–36 GDPR (data security, notification obligations, data protection impact assessment, prior consultation). The Processor is entitled to charge a reasonable extra fee separately for support that goes beyond the contractually agreed standard scope.

(5) Notification of Personal Data Breaches (Art. 33 GDPR). Information to the Controller without undue delay, generally within 48 hours, after becoming aware of a personal data breach. Notification is made to the contact designated by the Controller and contains at least the information specified in Art. 33(3) GDPR, to the extent available.

(6) Data Protection Contact. The Processor has designated a contact for data protection matters; contact details are provided in the dashboard and on request.

(7) Records of Processing Activities (Art. 30(2) GDPR). The Processor maintains a record of all processing activities and provides it on request to the supervisory authority or the Controller.

(8) Data Minimisation and Storage Limitation. Data are processed only to the extent and stored only for as long as necessary to fulfil the contractual obligations and to comply with statutory retention periods.

(9) Return and Erasure (Art. 28(3)(g) GDPR). Upon completion of the provision of processing services, all personal data shall — at the Controller's choice — be either erased or returned; existing statutory retention obligations remain unaffected. Details are governed by § 11.

§ 6 Obligations of the Controller

(1) Lawfulness. The Controller is solely responsible for the lawfulness of data processing and for safeguarding the rights of data subjects, in particular for the existence of a valid legal basis (including consents under Art. 9(2)(a) GDPR).

(2) Information and Consent. The Controller ensures that data subjects are duly informed about the data processing (Art. 13, 14 GDPR) and — where required — valid consents are in place that can be evidenced at any time.

(3) Issuing Instructions. The Controller designates one or more persons authorised to issue instructions and notifies the Processor of changes without undue delay.

(4) Cooperation Obligations. The Controller supports the Processor in fulfilling its statutory obligations, in particular by responding promptly to enquiries.

(5) Information on Breaches. The Controller reports personal data breaches that come to its knowledge and may be connected with processing by the Processor, without undue delay, to support@flonk.id with the subject „DRINGEND! DATENSCHUTZPANNE!" (URGENT! DATA PROTECTION INCIDENT!).

(6) Requirements for End Users. The Controller integrates the Flonk platform into its processes in such a way that End Users are shown the privacy notice and consent declaration in a transparent form before verification begins.

§ 7 Sub-Processors

(1) Authorisation. By concluding this DPA, the Controller grants the Processor general written authorisation within the meaning of Art. 28(2) sentence 2 GDPR to engage sub-processors. A current list of the sub-processors engaged at the time of contract conclusion is attached as Annex 2.

(2) Contractual Commitment. The Processor shall, by means of a contract, commit each sub-processor to data protection obligations that essentially correspond to those of this DPA, in particular with regard to sufficient technical and organisational measures.

(3) Change of Sub-Processors. The Processor shall inform the Controller of intended changes (addition or replacement of sub-processors) at least 30 calendar days before they take effect, in text form (by email to the data protection contact address stored in the dashboard), stating the date on which the change takes effect. The current list of sub-processors is Annex 2; the Processor provides it in its current version on request.

(4) Right of Objection. The Controller may object to the change within 14 calendar days of being informed, for important data protection reasons. In the event of a legitimate objection, the Parties shall seek an amicable solution in good faith. If no agreement is reached, the Controller is entitled to extraordinarily terminate the Main Contract and this DPA.

(5) Intra-Group Service Providers. Activities that the Processor uses from third parties as merely ancillary services (e.g. telecommunications, cleaning, or security services) do not constitute sub-processing within the meaning of this contract, provided that there is no regular access to personal data.

§ 8 Third-Country Transfers

(1) Principle. Data processing in principle takes place within the European Union or the European Economic Area (EEA): application hosting in Amsterdam (Netherlands), database in the EU, object storage (document images, selfies) and biometric processing in Frankfurt (Germany), proof-of-address inference in EU regions only, and key management in the EU. Where the Controller enables AML screening, names are screened by dilisense GmbH (Zurich, Switzerland; processing in the EU, according to the provider), by OpenSanctions Datenbanken GmbH (Berlin, Germany; processing in Frankfurt, Germany (Google Cloud EMEA)), or by both; Switzerland is covered by an adequacy decision of the European Commission (Art. 45 GDPR). Transactional emails to End Users (such as verification-outcome notifications) are sent from a mail server in London (United Kingdom), a country covered by an adequacy decision of the European Commission (Art. 45 GDPR).

(2) Third-Country Transfers. Transfers to third countries only take place where the requirements of Art. 44 et seq. GDPR are met, in particular through:

• a) adequacy decision of the European Commission (Art. 45 GDPR), where applicable;
• b) EU Standard Contractual Clauses (Art. 46(2)(c) GDPR) in their respective valid version, supplemented where appropriate by additional technical and organisational protective measures (transfer impact assessment). The EU Standard Contractual Clauses (Module 3) are the transfer mechanism used for the US-headquartered sub-processors listed in Annex 2; the data itself remains within the EU.

(3) Prohibition of Transfer of Raw Biometric Data. Transfer of raw biometric data (selfies, liveness videos, biometric templates) to third countries does not take place without express written agreement with the Controller.

§ 9 Support for Data Subject Rights

(1) The Processor supports the Controller with suitable technical and organisational measures in fulfilling data subject requests to exercise their rights under Art. 15–22 GDPR (access, rectification, erasure, restriction, data portability, objection, withdrawal of consent, right to human intervention in automated decision-making).

(2) Direct Contact by Data Subjects. If a data subject contacts the Processor directly, the Processor shall forward the request to the Controller without undue delay. The Processor does not independently provide substantive information unless the Controller has expressly permitted this.

(3) Authorities and Courts. Where personal data are requested from the Processor by government bodies, the Processor will inform the Controller without undue delay, to the extent legally permissible, and — to the extent reasonable and legally possible — work toward prior consultation of the Controller.

§ 10 Audit Rights

(1) Duty to Provide Evidence. The Processor demonstrates compliance with the agreed obligations on request in a suitable manner, in particular through:

• a) provision of its written, up-to-date TOM documentation (Annex 1);
• b) presentation of current audit reports or certificates of the Processor, where available;
• c) presentation of current audit reports or certificates of the sub-processors engaged, where available;
• d) answering written questionnaires.

(2) On-Site Audit. Where the evidence referred to in paragraph 1 is not sufficient in an individual case, the Controller is entitled to conduct an audit of the Processor's processing facilities during normal business hours and with reasonable notice (at least 30 calendar days), or have it conducted by an independent auditor bound to confidentiality. The auditor may neither be a competitor of the Processor nor in any other conflict of interest.

(3) Frequency. Such audits generally take place no more than once a year; in cases of justified suspicion of data protection violations and at the request of a supervisory authority, ad-hoc audits are permissible.

(4) Costs. The costs of an audit are borne by the Controller; the Processor is entitled to charge for its cooperation effort at the rates applicable at the time, unless the audit reveals material violations on the part of the Processor.

(5) Confidentiality and Security. Audits may not disproportionately impair business operations and may not lead to disclosure of trade secrets of third parties or other customers. All information obtained in the course of the audit shall be treated as strictly confidential.

§ 11 Erasure and Return of Data

(1) Upon termination of the provision of processing services, the Processor shall, at the Controller's choice, erase or return all personal data.

(2) Retention Obligations. Retention only takes place to the extent required by statutory retention obligations under Union or Member State law applicable to the Processor or the Controller. During retention, the protective measures set out in this DPA remain in force unchanged.

(3) Early Anonymisation. The Controller may at any time arrange for the irreversible anonymisation of individual or all data sets, provided no statutory obligations preclude this.

(4) Evidence. On request, the Processor shall provide suitable evidence of proper erasure.

§ 12 Liability and Contractual Penalties

(1) External Liability. Vis-à-vis the data subject, each Party is liable in accordance with Art. 82 GDPR.

(2) Internal Liability. Internally, liability between the Parties is governed by the provisions of the Main Contract. To the extent the Main Contract contains no provisions, the statutory provisions apply.

(3) Fines. Fines under Art. 83 GDPR are borne by the Party whose breach of duty was causative for their imposition. In the event of mutual fault, an allocation is made according to the respective contribution.

§ 13 Final Provisions

(1) Written Form. Amendments and supplements to this DPA require text form. This also applies to the waiver of this text form clause.

(2) Severability. Should individual provisions of this DPA be or become invalid, this shall not affect the validity of the remaining provisions. In place of the invalid provision, the valid and enforceable provision that comes closest to the economic purpose of the invalid provision shall be deemed agreed.

(3) Choice of Law and Jurisdiction. The laws of the Federal Republic of Germany apply, excluding the UN Convention on Contracts for the International Sale of Goods. The exclusive place of jurisdiction for all disputes is — to the extent legally permissible — Hannover, Germany.

(4) Annexes. The following annexes are part of this DPA:

• Annex 1: Technical and organisational measures (TOMs) pursuant to Art. 32 GDPR
• Annex 2: List of sub-processors

Annex 1 — Technical and Organisational Measures (TOMs) pursuant to Art. 32 GDPR

The following measures are continuously adapted to the state of the art.

1. Confidentiality (Art. 32(1)(b) GDPR)

1.1 Physical Access Control

Processing takes place in data centres of the sub-processors listed in Annex 2 within the EU (application hosting in Amsterdam, Netherlands; object storage and biometric processing in Frankfurt, Germany). Physical security of these facilities (access control, surveillance, visitor management) is provided by the respective data-centre operators in accordance with their published security documentation. The Processor does not operate its own premises for processing personal data.

1.2 System Access Control

Protection against unauthorised system use by:

• two-factor authentication (TOTP) available to all dashboard users; mandatory for the Processor's staff with administrative access, whose high-impact administrative operations additionally require a step-up one-time code,
• passwords stored only as bcrypt hashes,
• API access via secret keys (server-side) and publishable keys (browser); short-lived, session-scoped signed tokens for the verification widget,
• role-based access controls (RBAC) on a need-to-know basis,
• review and clean-up of permissions, and prompt removal of permissions on off-boarding.

1.3 Data Access Control

Ensuring that authorised persons can only access data within their authorisation:

• granular authorisation concept,
• append-only audit trails for verification actions, administrative actions, identity-vault events (creation, reuse, revocation, consent change) and security/anti-spoofing events,
• field-level encryption at rest (AES-256-GCM) for identity fields (date of birth, nationality, sex, document number, address, place of birth), storage object paths, customer API secret keys, webhook secrets and consent metadata,
• envelope encryption: data keys are generated by a key management service (AWS KMS) and each data key is additionally wrapped with a backup key held in a self-hosted key vault (HashiCorp Vault); plaintext data keys exist only in process memory with a short inactivity timeout,
• keyed blind index (HMAC-SHA256) for searchable identifiers; no plaintext is stored for that index,
• TLS 1.2 minimum (TLS 1.3 preferred) in transit for all external connections,
• logs record identifiers and outcomes, not personal data.

1.4 Segregation Control

Logical tenant separation: all data records are assigned to a customer project and every access is checked against the project and API key of the requesting party; separate staging and production environments with separate credentials and separate databases.

1.5 Pseudonymisation

Where functionally possible, data is processed in pseudonymised form: searchable identifiers are stored as a keyed blind index (HMAC-SHA256) rather than in plaintext; logs, monitoring and webhook notifications reference records by identifiers and outcomes rather than by personal data.

2. Integrity (Art. 32(1)(b) GDPR)

2.1 Transfer Control

Encrypted transmission of all data over external connections (TLS 1.2 minimum, TLS 1.3 preferred); the connection to the biometric processing server additionally uses mutual TLS, an IP allowlist and an API key, and the server's host firewall exposes only HTTPS and SSH; webhooks are signed with HMAC-SHA256; API authentication via high-entropy secret keys; per-project CORS allowlist; no transfer of personal data on physical data carriers.

2.2 Input Control

Append-only audit trails for verification actions and administrative actions (who, when, what); step-up one-time codes for high-impact administrative operations; idempotency keys prevent duplicate processing of repeated API requests.

3. Availability and Resilience (Art. 32(1)(b) and (c) GDPR)

3.1 Availability Control

Data storage within the EU; managed database backups provided by the hosting sub-processor; availability monitoring of production services; physical availability measures (power, fire protection, climate control) are provided by the sub-processors' data centres (Annex 2).

3.2 Restorability

Restorability of encrypted data is ensured by the key-recovery design: each data key is wrapped twice (key management service master key and a backup key in the self-hosted key vault), so that either path alone can recover the data; offline cold copies of key material are held for last-resort recovery. Database contents are restorable from the managed backups of the hosting sub-processor.

3.3 Protection Against Attacks

Network-level protection provided by the hosting infrastructure; rate limiting, per-project CORS allowlist and HTTP security headers at application level; host firewall and Fail2Ban on the biometric processing server; security reviews of the platform; patch management of application dependencies and operating systems.

4. Procedures for Regular Review (Art. 32(1)(d) GDPR)

4.1 Data Protection Management

Designated contact for data protection matters, record of processing activities (Art. 30 GDPR), documented internal data protection policies; an information security management system aligned with ISO/IEC 27001 is being established.

4.2 Incident Response Management

Incident response procedure with defined escalation paths, 48-hour notification chain to controllers (§ 5(5)), post-incident reviews.

4.3 Privacy by Design / by Default (Art. 25 GDPR)

Privacy-friendly defaults, data minimisation in product development, retention configured per project, security and privacy review before release of features that change the processing of personal data.

4.4 Order Control

Careful selection of sub-processors, written contracts pursuant to Art. 28 GDPR with each sub-processor, regular review of their TOMs, documented commitment to the level of protection of this Annex.

5. Personnel Measures

• Written commitment of all staff to confidentiality and data secrecy (Art. 28(3)(b) GDPR),
• access to personal data restricted to staff who need it for their role,
• off-boarding processes with prompt removal of all permissions.

6. Certifications

• The Processor operates an information security management system aligned with ISO/IEC 27001; certification is in preparation. The Processor does not currently hold an ISO/IEC 27001 or SOC 2 certificate.
• Biometric processing (document reading, liveness detection, face matching) runs on licensed software self-hosted on a dedicated server under the Processor's control in Frankfurt, Germany; images are not transmitted to the software vendor.
• Certifications of the sub-processors' data centres are listed in their respective security documentation (Annex 2).

Annex 2 — List of Sub-Processors

The following list reflects the status as of the contract date above.

AML screening. For AML screening the Processor uses dilisense, OpenSanctions, or both. These providers are engaged only where the Controller enables AML screening. For ongoing monitoring, dilisense stores the name and verification ID until monitoring ends; the Processor deletes the profile when monitoring is stopped, the verification is rejected or erased, or the project is deleted.

Key management (no personal data)