Data Processing Agreement

1. Parties and incorporation

This Data Processing Agreement (the "DPA") forms part of the Terms of Service between Lalalu Marketing SL, Travessera de Gràcia 73, 4-2, 08006 Barcelona, Spain (the "Processor", "AgeRail", "we") and the customer organisation that accepts the Terms (the "Controller", "Customer", "you").

This DPA is incorporated by reference into the Terms of Service at /terms. Acceptance of the Terms binds the Customer to this DPA. No separate signature or click-through is required for this DPA to take effect.

2. Roles

For personal data of end users that the Customer submits to the Service (or causes end users to submit) so that AgeRail can perform age verification on the Customer's instructions, the Customer is the controller and AgeRail is the processor under GDPR Article 28.

AgeRail acts as an independent controller for (a) tenant-user account and billing data needed to operate the commercial relationship, and (b) the operator-only calibration scalars described in section 6, which AgeRail processes for its own model-accuracy purposes under GDPR Art. 6(1)(f). Those two controller activities are described in the Privacy Policy at /privacy and are outside the processor mandate of this DPA except where this DPA expressly discloses the calibration carve-out so the storage statements of section 6 are not overstated.

AgeRail is also an independent controller for (c) the platform request logs its cloud provider writes for every request to an AgeRail service, which AgeRail reads for the security of its own network and information systems under GDPR Art. 6(1)(f) and Recital 49. That activity is described in section 10 of this DPA and is likewise outside the processor mandate. AgeRail is likewise an independent controller, under GDPR Art. 6(1)(f), for (d) the verification log line, (e) the vision call record, both described in section 10, and (f) the daily counts of the document judgement described in section 6. AgeRail is likewise an independent controller, under GDPR Art. 6(1)(f), for (g) the records of requests to support countries or document types and the overall totals derived from those requests, described in section 6.

3. Subject matter, nature, and purpose

The Processor provides a hosted age-verification service: the Customer redirects an end user to the Processor-hosted flow; the Processor estimates age from a selfie, performs a liveness check, and returns a signed result to the Customer with one of three statuses: verified, routed to fallback, or spoof detected. Where the Customer has enabled estimated age visibility and the end user has consented, the Customer can also obtain the estimate for that session. Processing is limited to delivering that Service and related support under the Customer's documented instructions (including configuration of target age, redirect URLs, and webhooks).

Where the Customer has the document check switched on, the Service also offers an end user whose age estimate did not clear the threshold one further step instead of a dead end: photographing a passport of a supported country, or a Great Britain photocard driving licence, full or provisional, on that end user's own explicit consent given by a tap before the camera opens. An identity card, a residence permit and a US or Canadian driving licence are not supported yet, and an end user who chooses one is told so before taking any photo. The step runs in a fixed order. Free local checks come first — the frames open, a face is found on the document, the chosen type is supported. The Processor then cuts the face out of the document and compares it with the selfie already captured, on its own systems and with nothing sent to any third party for it; no match, or no face found on the selfie, ends the attempt and the document is never read. Only on a clear match does the Processor read the document's date of birth, expiry, kind and issuing country, and its document number to bind the two frames of a two-sided document. The comparison therefore also happens for a document that is then refused. The setting is on by default for a Customer account created after this capability ships and off for an account that existed before it, and the Customer can switch it off at any time in the dashboard. What the step establishes is stated without inflation: it reads a document and compares a face. It makes no judgement of whether a document is genuine and performs no revocation or cancellation check, so a well-made forgery carrying a consistent date of birth and the presenter's own face can pass every check in this flow. A match against the issuing country's official specimen designs shows that a document looks like its country's official design, not that it is genuine or that it was issued to the person presenting it. A document edited or made up from scratch that carries the presenter's own face, an image edited before it is sent, or a photograph of a screen can still pass: the document judgement of section 8 can be wrong, and where its answers are not used to decide a result, they refuse nothing. Because no check is linked to another, one genuine document can be used by several different people in different checks. The Service claims no conformance with ISO/IEC 27566 and does not verify identity.

4. Duration

This DPA applies for as long as the Processor processes personal data on behalf of the Controller under the Terms, and thereafter for any wind-down period needed to return or delete Customer personal data under section 13.

5. Categories of data subjects and personal data

Data subjects under this DPA are primarily end users who complete a verification session.

Categories of personal data processed as processor include: verification flow metadata (session identifiers, status, the configured age threshold, redirect and webhook endpoints, timestamps) and transient biometric inputs (the face image and features derived from it) processed only as described in section 6. The verification response returned to the Customer is limited to a signed result with one of three statuses — it contains no age estimate and no liveness score. Optionally, a Customer who enables estimated age visibility in the dashboard can obtain an age estimate through the separate authenticated operation, dashboard, or export, only for sessions whose shoppers accepted that disclosure on the hosted consent screen. The estimate is stored only for those consented sessions and is deleted when its session record is deleted; session records currently have no fixed automatic deletion period, and their retention and deletion are governed by this DPA. That optional share is a documented Customer instruction; it does not widen the verification response, webhook, redirect, or session status response.

Where the document check of section 3 runs, the categories additionally include the document images the end user submits; two kinds of image derived from them, the cut-out of the face on the document and the masked image of each submitted photograph described in section 6; and, read from the submitted images, the date of birth, expiry, document kind, issuing country and document number, the last used only to bind two frames of one card and then dropped. Every other field the document carries, the end user's name included, is dropped unread, and no document field reaches the verification response, a webhook, a redirect, the dashboard or an export.

The Processor does not require the Customer to send end-user names, emails, or other direct identifiers to complete a verification.

6. What is kept, where and for how long

The Processor does not write the face image, any reusable biometric template or other representation derived from it, or the model's full age-estimate distribution to disk, a database, an object store or a backup. Images may be kept in memory for up to 24 hours for quality assurance, and may leave sooner when capacity is reached or the service restarts. They may be subject to human review for quality assurance and validation of verification results. Each review record includes the reason for access. The fixed numerical measures disclosed below are the only capture-condition exception to this statement.

At the document check of section 3, the document images are released as soon as the submission that used them ends, and no route serves one afterwards. Two kinds of derived image are kept: the face image taken from the document and used for the comparison, and a masked image of each submitted photograph, including submissions the Processor refuses. The masked image is intended to conceal the document’s text while leaving its design, background and portrait visible; some text may remain readable. These images are kept only in memory for quality assurance for up to 24 hours from registration and may be removed sooner if capacity is reached or the service restarts. They may be subject to human review for that purpose. Neither is ever written to disk, a database, an object store or a backup. After the images are deleted, verification records, aggregate daily counts, records of requests to support countries or document types, and the overall totals derived from those requests are still kept, subject to the retention and deletion provisions on this page.

The Processor's records for verification sessions, transactions and tenant operational data hold no face image, no reusable biometric template and no identifier-linkable biometric data, apart from the numerical outputs described below.

Narrow operator-only calibration carve-out (disclosed so the commitments above are not read as "no data is retained"): when calibration monitoring is enabled, the Processor may retain per-verification pseudonymous outputs — four numerical outputs relating to age estimation, liveness, decision confidence, and the configured age threshold; the vision model's paired reading described in section 8 (its age estimate, its live-person reading, its confidence, whether and why no reading came back, and how long the call took); which model decided age and which decided liveness; and the version of the decision policy in force — for up to 30 days in operator-only storage within the European Union, for model calibration and drift detection under GDPR Art. 6(1)(f). Tenants cannot read that store. After deletion, provider-managed recovery copies may remain for up to approximately 14 further days. That residual window is disclosed rather than described as an immediate hard purge.

A second, narrower operator-only record may hold a fixed set of pseudonymous capture-condition measurements — how the face was framed, the lighting and sharpness of the capture, and the type of device used — together with one model-confidence measure. They are recorded only while an operator setting that is off by default is enabled, in operator-only storage within the European Union. The record is deleted when its verification session record is deleted; session records currently have no fixed automatic deletion period. It holds no image, no biometric template or derived representation, and no identifier beyond the verification session it belongs to. No merchant or shopper can read it.

A one-time bounded archive may copy a defined subset of the 30-day calibration records — those covering a complaint under investigation and those from a healthy period held for comparison — into a non-expiring operator-only store within the European Union. Its exact dates and record counts are recorded when the snapshot is taken. No other calibration data is authorised for that archive.

A third operator-only carve-out, beside the calibration one and on the same footing, covers the daily counts of the document judgement of section 8, whether or not the answers are used to decide a result. The two answers themselves are kept only beside the masked image they describe, in the quality-assurance hold described above and for as long as that image is held. What this carve-out keeps is a daily count of each answer — a day, the answer and a number — in operator-only storage within the European Union. Those counts hold no session identifier, no Customer, no country and nothing that identifies an end user. AgeRail is the controller for those counts, on the ground of its legitimate interest in measuring how a control of its own service behaves (GDPR Art. 6(1)(f)). This is AgeRail's own purpose and not the Customer's instruction; the assessment is in AgeRail's document-check impact assessment, available on request. The Customer and its end users receive a result of the same form whether or not the answers are used to decide a result.

A fourth operator-only carve-out covers records kept only when an end user selects the optional button asking AgeRail to support an unavailable country or document type. Each record contains the issuing country, the document type and the calendar month; no document type is recorded where the whole country is unsupported. It contains no name, image, session identifier, Customer, address, device details or time more precise than the month, and is never linked to the end user’s verification session. AgeRail keeps this information in operator-only storage within the European Union. AgeRail is the independent controller, on the ground of its legitimate interest in deciding which countries and documents to support next (GDPR Art. 6(1)(f)), for a statistical purpose under GDPR Art. 89(1). This is AgeRail’s own purpose and not the Customer’s instruction; the assessment is in AgeRail’s document-check impact assessment, available on request. Records are retained for the current calendar month and the preceding twelve months, approximately thirteen months. After that period, each record is deleted and only overall totals by country and document type, without a month, are retained with no end date. Database backups are kept for a limited period, as for AgeRail’s other records. Only AgeRail’s operators can view the information, as counts; it is not made available to the Customer or its end users and is not exported. Whether or not the end user asks, the Customer and its end users receive a result of the same form, and the request does not change any result the Customer receives.

7. EU residency for verification processing

The Processor configures the biometric and verification workloads it controls, and the storage of the data they produce, to run within the European Union. Vendor support, security, and telemetry activities incidental to those services are governed by the applicable vendor terms referenced in section 8. Delivery of verification results to the Controller's own configured redirect or webhook endpoints is Controller-directed; the location of those endpoints is the Controller's choice and responsibility. The EU-only residency claim in this DPA is scoped to processing on AgeRail-controlled workloads.

Payment data and transactional email data are processed by the controller-side service providers disclosed in section 8 and on /subprocessors, under the transfer mechanisms summarised in section 9.

8. Sub-processors

EU AI inference providers process facial and document data for age verification, including any document text that remains readable, and return judgements without providing any reusable representation of a face. The Processor’s calibration and quality-assurance processing is described in section 6.

Where the Processor's decision policy says so, that judgement decides the verification; a document question the model is asked and does not answer decides nothing and costs the end user no attempt. The document judgement's answers may be used to decide a result. If they are, a refusing or unclear answer costs the end user one attempt; the end user may try again within the document step's attempt limit. If they are not, they change no result and cost the end user no attempt. The Processor sets which applies through its decision policy; the Controller's document-check setting of section 3 turns the step on or off and does not set it. Daily counts of the answers are kept in either case under the carve-out of section 6. The judgement itself is disclosed neither to the Controller nor to the person captured, who receive a result of the same form under every setting.

The Controller authorises the Processor to engage sub-processors for Controller Personal Data under this DPA: Google Cloud, which hosts the Processor's workloads within the European Union, and providers of AI inference capacity within the European Union. Inference providers process data only to answer a request and keep none of it beyond the request, save for a limited period where security requires. The Processor imposes data-protection obligations equivalent to this DPA on each sub-processor and remains fully liable to the Controller for their performance (Art. 28(4)).

Stripe (payments), and Postmark and Resend (transactional email), process payment data and email data as controller-side service providers of AgeRail for AgeRail's own commercial and operational purposes; they are not Article 28 sub-processors for Controller Personal Data under this DPA. Their data categories and transfer mechanisms are disclosed at /subprocessors for transparency. That page describes the service providers and sub-processor categories, their roles, data categories and processing locations.

The Processor keeps its list of sub-processors current and provides it to the Controller, and to competent supervisory and certification bodies, on request. The Controller may object to an added or replaced sub-processor on reasonable data-protection grounds; if the parties cannot resolve an objection, the Controller may terminate the affected Service as its sole remedy.

9. International transfers

Verification processing on AgeRail-controlled infrastructure is configured to occur within the European Union, so it involves no transfer of Controller Personal Data outside the EEA by the Processor. Delivery of verification results to the Controller's own configured redirect or webhook endpoints is Controller-directed; the location of those endpoints is the Controller's choice and responsibility.

Stripe processes payment data globally, including in the United States, under Stripe's Data Processing Agreement and transfer mechanisms (EU-US Data Privacy Framework certification and Standard Contractual Clauses where applicable).

Postmark processes transactional email data under Postmark's Data Processing Agreement and transfer mechanisms (EU-US Data Privacy Framework certification and Standard Contractual Clauses where applicable).

Resend processes transactional email data, and stores it in the United States, under Resend's Data Processing Addendum and transfer mechanisms (EU-US Data Privacy Framework certification and Standard Contractual Clauses).

Details of role, data category, region, transfer mechanism, and classification for each vendor are published at /subprocessors.

10. Security

The Processor implements appropriate technical and organisational measures for the risk, including access controls on the principle of least privilege; encryption in transit; enforced location controls that stop verification services running outside their approved region; controls that prevent face images, any reusable biometric template or other representation derived from them, and the model's full age-estimate distribution from being written to disk, a database, an object store or a backup, so that face images are held only in memory during a check and the hold of section 6 — the Processor's records have no field for them; and restricted operator-only access to any calibration record store. The Processor may change these measures over time, provided the overall level of protection is not lowered.

Operating that security requires the Processor to keep records of the requests its own infrastructure receives. The Processor's cloud provider writes one record per request to an AgeRail service, covering the IP address it came from, the browser or app that made it, the address requested, and other security and abuse-prevention telemetry — and AgeRail personnel may read those records through an operator-only console to diagnose failures, latency and abuse. That is AgeRail's own network-and-information-security processing under Art. 6(1)(f) and Recital 49, in which AgeRail is controller rather than the Controller's processor, so it falls outside the processor mandate of this DPA. Those records are held for thirty days by the provider's logging retention and are then deleted; no record is copied into an AgeRail application database, exported, or offered as a download; values that carry a password or an access token are removed before a record is shown; the audience is AgeRail operator personnel alone, and no Customer, end user or other vendor receives them. Where a request carries a verification session identifier, the record shows that identifier beside the IP address; these request records hold no image, no age estimate and no biometric value. A request record and the vision call record described below can carry the same session identifier. AgeRail also records IP addresses used during verification and information about their country and network to detect automated or fraudulent use and VPN or proxy use, acting as controller for its own security purposes outside the processor mandate of this DPA; this information is available only to AgeRail operator personnel, each address is deleted thirty days after it is recorded, and the country and network information remains with the verification record for as long as that record is kept.

Two further records describe a verification rather than a request. When a verification is scored, the Processor's own service writes a log line that counts how many images were submitted and how many of them the age estimate used, beside that verification's session identifier. The line carries no image, no age estimate and no biometric value. Its purpose is to diagnose how a result was aggregated and to evaluate the accuracy of the Service over time. It is held for 90 days in a logging store the Processor's cloud provider operates within the European Union, and is then deleted; the audience is AgeRail operator personnel alone.

The second record is written for each call to the vision model of section 8: the prompt texts in force, the parameters, how long the call took and, for the age and liveness questions, the model's answer — including its age estimate and its live-person reading — beside that verification's session identifier. For the document questions of section 8 the record holds no answer. No image of any kind is in that record. Its purpose is to let an operator tell a wrong reading, a refusal and an outage apart. It is held for up to 30 days in that same provider-operated logging store within the European Union, and is then deleted; the audience is AgeRail operator personnel alone.

For both records AgeRail is controller under Art. 6(1)(f), as it is for the request records above, and both fall outside the processor mandate of this DPA.

This DPA states the Processor's technical and organisational measures at the level a Controller needs to assess them, rather than describing how they are built. A Controller who needs further detail — the composition of the calibration records, the specific controls behind a measure, or the Processor's security documentation — may request it at privacy@agerail.com, and the Processor will make available the information necessary to demonstrate compliance with this DPA (Art. 28(3)(h)), subject to confidentiality and to the audit terms in section 11.

The Processor ensures that any person it authorises to process Controller Personal Data commits to confidentiality (contractually or under statutory obligation) before being given access (Art. 28(3)(b)).

11. Assistance, rights requests, and audits

Taking into account the nature of processing, the Processor will assist the Controller with reasonable requests related to data-subject rights and with information reasonably needed for the Controller's data-protection impact assessments, where such assistance relates to personal data processed under this DPA.

The Processor will allow for and contribute to audits by the Controller (or an independent auditor mandated by the Controller) of the Processor's compliance with this DPA, limited to once per calendar year unless a personal-data breach or competent authority requires an additional audit. Audits are by written request with reasonable notice, during normal business hours, without disrupting Service operations, and subject to confidentiality. The Processor may satisfy an audit request by providing recent independent security reports, certifications, or written answers to a reasonable questionnaire where those materials address the request.

12. Personal-data breach notification

The Processor will notify the Controller without undue delay and, where feasible, within 72 hours after becoming aware of a personal-data breach affecting personal data processed under this DPA, providing information reasonably available at the time to help the Controller meet its own notification obligations. Further information will follow as it becomes available.

13. Return or deletion on termination

On termination or expiry of the Service, the Processor will, at the Controller's choice, return or delete the Controller Personal Data it processes under this DPA and delete existing copies from active systems, unless Union or Member State law requires the Processor to retain them (Art. 28(3)(g)). After that deletion, residual copies may remain in provider-managed database backups and, in production, recovery logs retained up to 7 days, for a bounded further period before they expire; during that residual window they remain subject to this DPA's confidentiality and security terms and are not used for any other purpose. The Controller makes that choice by written request to privacy@agerail.com within 30 days of termination; if the Controller makes no choice within that period, the Processor will delete. A return is provided as an export of the Customer's session and billing records.

The following applies to that process. (a) Processing under this DPA stops and the Customer's account is deactivated. (b) Session and transaction records hold pseudonymous flow and commercial metadata; where Spanish or EU accounting and tax law requires the Processor to retain them, they are retained for that period only, and the Processor deletes or anonymises the remainder from active systems (with the residual provider-managed backup window described above). (c) Copies the Processor must retain under applicable law remain subject to this DPA's confidentiality and security terms until deletion, and are not processed for any other purpose. (d) The operator-only calibration records described in section 6 are AgeRail-controller data outside this processor mandate. The 30-day calibration records expire on their own schedule; capture-condition records are deleted with their verification session, whose records have no fixed automatic deletion period today; and the disclosed one-time bounded archive is non-expiring. The residual provider-managed recovery window in section 6 applies after a 30-day calibration record is deleted.

14. Customer instructions

The Processor processes personal data under this DPA only on documented instructions from the Controller, including instructions given through the Service configuration and API, unless EU or Member State law requires otherwise. If an instruction appears to infringe GDPR or other applicable data-protection law, the Processor will inform the Controller.

Where the document check of section 3 is on and the Customer is required by a Union or Member State law to check the age of its users, the Customer will name that law to the Processor at privacy@agerail.com. Comparing a face with the portrait on a document is special-category processing under GDPR Art. 9: for an end user able to give it, the Processor relies on that end user's explicit consent, taken by a tap before the camera opens (Art. 9(2)(a)); where the named law applies, Art. 6(1)(c) with Art. 9(2)(g) is the parallel basis the Customer supplies for its own users. Where no such law is named, the Customer accepts that an end user below the digital-consent age in their country cannot give that consent validly, and that the step nonetheless runs on the necessity of the age decision it serves — the position the published Privacy Policy states rather than claims to have solved.

15. Liability and order of precedence

Liability under this DPA follows the Terms of Service. If there is a conflict between this DPA and the Terms on a data-protection subject matter, this DPA controls for that subject matter.

16. Contact

Data-protection contact for this DPA: privacy@agerail.com.