Privacy Policy

1. Controller

This Privacy Policy describes how Lalalu Marketing SL, Travessera de Gràcia 73, 4-2, 08006 Barcelona, Spain ("AgeRail", "we", "us") processes personal data in connection with the AgeRail hosted age-verification service (the "Service").

Contact for data-protection enquiries and data-subject rights: privacy@agerail.com.

2. Who this policy covers

We process personal data about three groups of people, each described separately below.

• Tenant users — people who create or administer a customer organisation account (for example portal login, billing, and API configuration).
• End users — people who complete a verification session after a tenant redirects them to the hosted AgeRail flow.
• Business contacts: People a member of our team knows in a business role and contacts about our services.

3. Tenant users

3.1 What we process

For tenant users we process account and service-administration data, including:

• Email address and role within a tenant organisation
• Organisation name and configuration (redirect URLs, webhook URL, default target age)
• Billing and prepaid-credit records (balance, ledger entries, Stripe customer and payment references, VAT and billing country where provided)
• Transactional service email metadata delivered through our email providers
• Records of Terms acceptance at self-serve signup where applicable
• Information about how you reached our marketing site, including campaign source, campaign name and advertising click identifier, kept with your account whether or not you accepted the cookie banner.

3.2 Purposes and legal bases

We process tenant-user data to:

• Provide, secure, and administer the Service under the contract with the customer organisation (GDPR Art. 6(1)(b))
• Bill for prepaid credit and keep accounting records (Art. 6(1)(b) and, where required for tax and bookkeeping, Art. 6(1)(c))
• Communicate about the account and Service (Art. 6(1)(b); operational notices under Art. 6(1)(f) where needed to protect the Service)
• Measure which marketing-site visits become paying tenants, how tenant accounts are set up and used, and how many verification visits the Service receives by country, by sending signup, payment, account-activity and anonymous verify-visit events to Google Analytics (Art. 6(1)(f); you can object — see section 7)

3.3 Retention

Tenant account data is retained for the life of the customer relationship. When the account ends: (a) processing stops and the account is deactivated; (b) AgeRail-controller 30-day calibration records continue to expire on their own schedule, capture-condition records are deleted with their verification sessions, and the disclosed one-time bounded archive is non-expiring, as described in section 4.4; (c) session and transaction records hold pseudonymous flow and commercial metadata only and are retained as needed for statutory accounting and legal obligations; (d) on request via privacy@agerail.com, we provide an export of the Customer's session and billing records, and delete or anonymise non-statutory tenant account contact data from active systems. 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 which they are unavailable for ordinary processing and are not used for any other purpose. These on-request actions are performed on request and are not an automatic anonymisation sweep. Billing and tax records are retained for as long as Spanish or EU law requires. Contact us via the route below for rights requests.

4. End users

4.1 Verification processing

AgeRail uses a selfie to estimate whether you meet the requesting service’s age requirement and to check that a live person is present. The result is produced automatically by software. We do not identify you: we search no database of faces, and we keep nothing that could recognise you in a later check. If you choose the document step described below, one comparison is made between your selfie and the portrait on the document you present in the same check. That comparison measures both faces on our own systems and keeps neither measurement: they exist for that one comparison, are never stored or sent anywhere, and are linked to no session and to no person. Nothing else we do makes such a measurement.

For a check where estimated age visibility is off: The requesting service receives a signed result with one of three statuses: the check passed, you were routed to the service's fallback, or the liveness check did not pass.

For a check where estimated age visibility is on: The requesting service receives a signed result with one of three statuses: the check passed, you were routed to the service's fallback, or the liveness check did not pass. Because it has enabled estimated age visibility, it can also obtain the estimate through separate authenticated account tools, only for this consented session.

Images from this check are not retained as a persistent record. Verification data may be subject to limited quality review under restricted and audited access.

The requesting service is the controller for this check, and AgeRail operates it on the service’s behalf. The full Privacy Notice explains AgeRail’s separate calibration processing and your privacy rights.

When an end user completes a verification, AgeRail estimates age from a selfie and performs a liveness check. The face image and features derived from it are not written by AgeRail 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. Any reusable biometric template or other representation derived from the image, and the model's full age-estimate distribution, are not written by AgeRail to disk, a database, an object store or a backup either. The fixed numerical measures described in section 4.2 are the only capture-condition exception to this statement. The result is produced automatically by software: no person at AgeRail takes part in producing it, and the quality review described above never changes a result already issued. If the check cannot reach a conclusive result, the end user is returned to the tenant, which may offer an alternative way to verify.

Where the requesting service has the document step switched on, AgeRail offers one such alternative itself before returning you: photographing a passport of a supported country, or a Great Britain photocard driving licence, full or provisional. Those two are what the step accepts today; an identity card, a residence permit and a US or Canadian driving licence are not supported yet, and if you choose one we tell you so before you take any photo. Nothing happens until you tap “Agree and open camera” under one sentence that asks your consent for AgeRail to read your ID and compare its photo with your selfie, and links here; declining leaves the earlier result as it stands and costs you nothing. From the document we read five things and nothing else — the date of birth it states, its expiry, the kind of document, the issuing country, and the document number, which is used only to check that a two-sided document’s front and back are the same card and is then dropped. Every other printed or encoded field, including your name, is dropped unread, and no document field is written to a database, a log, an export, a webhook or the result the requesting service receives.

Some countries and document types are not yet supported. If we cannot check your chosen document, the screen tells you and keeps a link to this Privacy Policy. You can select “Return to shop” without creating a request record. Only if you select the separate button asking us to add support does AgeRail keep a record. It contains the issuing country, the document type and the calendar month. If the whole country is unsupported, no document type is recorded. The record contains no name, photo, session details, requesting service, address, device details or time more precise than the month. It is never linked to your verification session. The record holds nothing that identifies you.

AgeRail is the controller for this record. We use it to decide which countries and documents to support next. This is our own purpose, not an instruction from the requesting service. Our legal basis is our legitimate interest in planning document support (GDPR Art. 6(1)(f)). We use these records for statistics under GDPR Art. 89(1). Choosing to ask is optional.

We keep records from the current month and the previous twelve months, giving a retention period of about thirteen months. After that, we delete the record and keep only overall totals by country and document type, without a month, with no end date. Backup copies are kept for a limited period, as for AgeRail’s other records.

Only AgeRail’s operators see the information, as counts. Neither you nor the requesting service can see it. It is not exported and does not change any result the requesting service receives.

You have the right to object to this processing at any time by contacting privacy@agerail.com (GDPR Art. 21). Your objection can name the country, the document type and the month you asked about.

The order matters, so here it is. Three checks run first on AgeRail’s own servers with nothing sent anywhere: your photographs open, a face is found on the document, and the document type you chose is one we accept. Then the photo of the face is cut out of the document and compared with the selfie already captured — on our own servers too, with nothing sent anywhere for it. If the faces do not match, or no face is found on the selfie, the attempt ends there and we never read the document. Only on a clear match do we read it. That means the comparison also happens for a document we then refuse: if your document turns out to be expired, below the age or unreadable, the photo on it has already been compared with your selfie.

With your explicit consent, we compare the portrait on your identity document with your selfie to check that the document belongs to you. No data is sent to a third party for this comparison. We do not send facial data to third parties for the comparison or use it to link you across checks. We keep the face cut-out for quality assurance as described in this notice. EU AI inference providers receive facial and document data for age verification, as described in section 5. An AgeRail operator can see both the cut-out and the masked image for up to 24 hours, as section 4.4 describes. We build a masked image from every photograph you submit, whatever we then decide, and we need no reference images to build one: the masked image is intended to conceal the document’s text while leaving its design, background and portrait visible. This is not a guarantee that all text will be concealed. Any remaining document text may be visible to our authorised operators and to EU AI inference providers, even if the submission is subsequently rejected. You can withdraw this consent until you send the photos by choosing “No thanks, return to shop”. Withdrawal does not affect the lawfulness of processing based on consent before its withdrawal.

The inference providers return their answers without providing any reusable representation of a face. The answers may be used to decide a result. If they are, a refusing or unclear answer costs you one attempt; you may try again within the document step's attempt limit. If they are not, they change no result and cost you no attempt. The answers are shown to no requesting service and not to you. The result the requesting service receives has the same form whether or not the answers are used to decide a result. We keep daily counts of the answers in either case. 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)); your rights over processing on that ground are described in section 7. What we keep for it is a daily count of each answer: a day, the answer and a number, with no session, no requesting service, no country and nothing that could identify you.

What the document step does not establish, stated plainly. It does not judge whether a document is genuine, and it does not check whether one has been reported lost, stolen, cancelled or revoked, so a well-made forgery carrying a consistent date of birth and the presenter’s own face can pass every check in this flow. The model’s judgement that the document matches one of its country’s official specimen designs shows that a document looks like its country’s official design — not that it is genuine, and not 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 model can be wrong, and where its answers are not used to decide a result, they refuse nothing. And because AgeRail never links one check to another, one genuine document can be used by several different people in different checks, and nothing here would notice.

The face comparison at this step is special-category data under GDPR Art. 9, and your own explicit consent — the tap described above — is the route AgeRail relies on for it. A person under the digital-consent age in their country cannot give that consent validly. Where the requesting service’s own national law requires it to check age, that law is the parallel basis (GDPR Art. 6(1)(c) with Art. 9(2)(g)), and the Data Processing Agreement asks the service to name it. Where no such law is named, we state the position rather than claim it is solved: the processing rests on the necessity of the decision you are already the subject of, which is the decision that protects people under the threshold.

Providing a selfie is not a statutory duty you owe AgeRail; it is the method the requesting service has chosen for its age check, and that service may itself be under a legal duty to check your age. If you do not provide one, the check cannot be completed, and the requesting service decides what happens next — including whether it offers you another way to verify.

The tenant receives a signed result with one of three statuses: the check passed, you were routed to the service's fallback, or the liveness check did not pass. The Service does not return an estimated age or liveness score to the tenant in the verification response.

Optionally, a tenant who enables estimated age visibility in the dashboard can obtain an age estimate through the separate authenticated operation, Sessions pages, and 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 the data-processing agreement. The Service does not add the estimate or a liveness score to the verification response, webhook, redirect, or session status response. The calibration records remain operator-only.

Persistent records that remain after a verification include service configuration, verification status, timestamps, security records, and commercial or billing information needed to provide the Service. They can also include a session-keyed age estimate in a merchant display table, only when estimated age visibility is on and the shopper accepted that disclosure. That estimate feeds merchant surfaces only 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 the data-processing agreement. It is separate from the pseudonymous calibration records described below, which tenants cannot read. These records contain no face images and no reusable biometric templates, and their structure defines no place to store them.

4.2 Operator-only calibration scalars (carve-out)

Narrow operator-only carve-out: when calibration monitoring is enabled, AgeRail may retain per-verification pseudonymous outputs for model accuracy monitoring. Those outputs are values relating to age estimation, liveness, decision confidence, and the configured age threshold; the vision model's paired reading described in section 5 — 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. They are kept for 30 days in operator-only storage within the European Union.

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 tenant 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.

Calibration records carry a pseudonymous session reference only, which tenants cannot link back to a verification. Access is limited to authorised operator personnel. Tenants cannot read the calibration store.

Legal basis for this calibration processing is GDPR Art. 6(1)(f) — legitimate interest in operating an accurate age-verification service, detecting model drift, and maintaining the reliability of the under-age blocking decision. A balancing analysis is maintained internally for that purpose.

4.3 Roles for end-user verification data

For end-user verification data processed on a tenant's instructions, the tenant is the controller and AgeRail is the processor. That relationship is governed by the Data Processing Agreement at /dpa, incorporated into the Terms of Service. For the operator-only calibration scalars described above, AgeRail determines the means and purposes and acts as controller.

4.4 Retention of end-user related records

The face image and features derived from it are not written by AgeRail 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. Any reusable biometric template or other representation derived from the image, and the model's full age-estimate distribution, are not written by AgeRail to disk, a database, an object store or a backup either. The fixed numerical measures described in section 4.2 are the only capture-condition exception to this statement.

At the document step described in section 4.1, the document photographs are released as soon as the submission that used them ends, and no route serves one afterwards. Two kinds of image are kept and no others: the cut-out of the face that was compared, and the masked image of each photograph, for every submission, including one we refused. Each may be kept in memory for up to 24 hours from the moment it is registered, 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. The masked image is intended to conceal the document’s text while leaving its design, background and portrait visible, but some text may remain readable, as section 4.1 describes. Neither image 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.

Per-verification pseudonymous calibration records are retained for 30 days and then deleted. After deletion, residual copies may remain in provider-managed recovery systems for a further window of up to approximately 14 days before final deletion, during which they are unavailable for ordinary processing. That residual platform window is a property of the underlying storage service and is disclosed here rather than claimed as an immediate hard purge.

The fixed operator-only capture-condition measurements described in section 4.2 are deleted when their verification session record is deleted. Session records currently have no fixed automatic deletion period. A one-time bounded archive copies a defined subset of complaint and comparison records into a non-expiring operator-only store; its exact dates and record counts are recorded when the snapshot is taken.

Verification session and transaction metadata used for the Service and billing is retained as needed to operate the account, resolve disputes, and meet legal obligations, and is not used to reconstruct biometrics.

4.5 Operational records of a check

Two operational records describe a check rather than a request to our systems. When a check is scored, our own service writes a log line that counts how many images were submitted and how many of them the estimate used, beside the session reference for that check. The line holds no image, no estimated age and no biometric value. We keep it to diagnose how a result was put together and to follow the accuracy of the Service over time. It is held for 90 days in a logging store our cloud provider operates within the European Union and is then deleted, and only AgeRail operator personnel can read it.

When the vision model described in section 5 is asked about a capture, we write one record of that call: the questions put to the model, the settings used, how long the call took and, for the age and liveness questions only, the model's answer — including its estimate of the apparent age and its reading of whether a live person was present — beside the session reference. For the document questions no answer is written. No image of any kind is in that record. We keep it so that an operator can 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, and only AgeRail operator personnel can read it.

AgeRail is the controller for both records, on the ground of its legitimate interest in operating the Service correctly and following its accuracy (GDPR Art. 6(1)(f)). Neither record is part of the processing AgeRail performs on the requesting service's instructions. You can object to this processing under GDPR Art. 21 — see section 7.

5. Recipients and vendors

We use the service providers and sub-processor categories described at /subprocessors for infrastructure hosting, AI inference, payments and transactional email. That list includes Google Cloud, EU-hosted AI inference providers, Stripe, Postmark, and Resend.

Google Analytics is a controller-side recipient of these streams, not an Article 28 sub-processor of Controller Personal Data. The marketing-site stream is a visitor identifier written after you accept the banner. The server stream carries conversion events — a signup completed, a top-up started, a payment confirmed — under a tenant-derived identifier, or under that visitor identifier if you accepted the cookie banner on the marketing site before signing up. If you accepted the banner, Google Ads can also count which of our ads led to your signup or a payment, and nothing is used to personalise ads. Account-activity events — an API key created, a webhook configured, a dashboard viewed — report under the tenant-derived identifier only, never under a visitor identifier, and go to a separate analytics property used for operating the Service. There is no second analytics box on the signup form. That operational property also receives one anonymous verify-visit event per verification visit, sent from our servers, never from the verification page itself: it carries an event name, an identifier minted at random for that single event, and a country derived from the browser's timezone — no verification session identifier, no outcome, no timing, no city, and no IP address. Because the identifier is never reused, no two of these events can be linked to each other or to any person, session or account. No stream carries biometric data, a verification session identifier, or an email address, and beyond that anonymous count, nothing about an individual verification is sent to Google Analytics in any form. That statement is about the analytics streams described here. It is not about the platform request logs in section 8, which the cloud infrastructure provider writes for every request and which can carry a verification session identifier.

Calibration scalar data, including the operator-only capture-condition measurements and the bounded archive, is limited to operator personnel and is not made available to tenants or used as a marketing dataset.

EU AI inference providers receive facial and document data to support age verification. They return their results without providing any reusable representation of a face. 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. Where our decision policy says so, that reading decides the verification; either way you receive a result of the same form and the reading reaches no merchant. Our calibration and quality-assurance processing is described in section 4.

No answer from the provider is shared with a merchant or with you. We do not send facial data to third parties for the comparison or use it to link you across checks. We keep the face cut-out for quality assurance as described in this notice.

The cookies this site may write, their purpose, lifetime and recipient, and the control that changes a stored answer, are on the Cookie Policy page.

6. International transfers

AgeRail 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 summarised at /subprocessors. 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. Current hosting-location detail is available to customers on request under confidentiality.

Payment data is processed by Stripe under Stripe's own data-processing terms and transfer mechanisms (including the EU-US Data Privacy Framework and Standard Contractual Clauses where applicable). Transactional email data is processed by Postmark under its own data-processing terms and transfer mechanisms (including the EU-US Data Privacy Framework and Standard Contractual Clauses where applicable), and by Resend (Plus Five Five, Inc.), which stores message content and delivery logs in the United States under its EU-US Data Privacy Framework certification and the Standard Contractual Clauses in its Data Processing Addendum. Website-visitor analytics data and the server-side signup, payment, account-activity and anonymous verify-visit events are processed by Google under Google's own terms and transfer mechanisms (including the EU-US Data Privacy Framework and Standard Contractual Clauses where applicable). See /subprocessors for the per-vendor transfer summary. To obtain a copy of the safeguards a vendor relies on, or to see where they are available, write to privacy@agerail.com.

7. Your rights

Depending on your role and applicable law, you may have rights of access, rectification, erasure, restriction, portability, and objection (including under GDPR Art. 21 for processing based on legitimate interests).

To exercise these rights, contact privacy@agerail.com. This notice describes what we process, why, for how long and who sees it, rather than how our systems are built; if you need further detail about any processing described here, ask us at the same address.

Calibration records are pseudonymous and carry no name, email, or other direct identifier. We will handle an objection or erasure request covering them using the information reasonably available to identify the relevant verifications, in line with GDPR Art. 11 and Art. 12, and will delete affected 30-day calibration records ahead of their expiry where that is feasible, and address a related capture-condition record or bounded archive where the relevant verification can be identified. The residual provider-managed recovery window described in section 4.4 still applies after a calibration record is deleted.

The result of a verification is produced automatically: no person at AgeRail takes part in producing it, and the quality review described in section 4.1 never changes a result already issued. The requesting service is the controller for it, and it is the party that owes you a way to contest it: if a check refuses you and you believe that is wrong, ask that service for a human review of the refusal and for another way to prove your age. Under GDPR Art. 22(3) it must consider that request and must not leave the refusal standing on the automated result alone. Simply taking the check again is not that route, and you should not have to rely on it. Where a refusal was decided at the document step described in section 4.1, the only material anyone can examine afterwards is the two images described there, which are kept for up to 24 hours and may leave sooner when capacity is reached or the service restarts: a request that turns on what they showed has to reach privacy@agerail.com within 24 hours of the check, and after that the outcome and timing recorded for the session are all AgeRail can provide. AgeRail does not write your image to disk, a database, an object store or a backup. The in-memory copy described in section 4.1 is kept for up to 24 hours for quality assurance, and may leave sooner when capacity is reached or the service restarts: a fixed overall memory budget releases the oldest capture first when that budget is reached. Once it is released, AgeRail cannot re-examine the original capture. What AgeRail can give the requesting service, on request through privacy@agerail.com, is the outcome and timing recorded for that session; the calibration measures described in section 4.2 are pseudonymous: they carry no name, image or account, and AgeRail does not use them to identify you. Where the requesting service gives us the session identifier while a record exists, we can locate the measures recorded for that session.

End users who verified through a tenant's product should also contact that tenant for requests about the tenant's own processing of their data outside AgeRail.

You may lodge a complaint with a supervisory authority. In Spain the lead authority is the Agencia Española de Protección de Datos (AEPD).

To withdraw a stored answer to the cookie banner, use the control on the Cookie Policy page. That deletes the cookies and brings the banner back. To object to the legitimate-interest measurement of tenant activity described in section 3.2, contact privacy@agerail.com.

8. Security

We apply technical and organisational measures appropriate to 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 persistent storage — our records have no field for them; and restricted operator-only access to calibration records. We may change these measures over time, provided the overall level of protection is not lowered.

Running that security means keeping a record of the requests our own systems receive. The cloud provider that hosts AgeRail 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. That record is created for every request, whether or not anyone reads it, and it is not part of the calibration records described in section 4.2.

AgeRail operator personnel may read those records through an operator-only console to diagnose failures, latency and abuse against the service. The legal basis is AgeRail's legitimate interest in the security of its own network and information systems (GDPR Art. 6(1)(f), Recital 49), and AgeRail is the controller for it rather than a merchant's processor. Records are held for thirty days by the provider's logging retention and are then deleted. Nothing read from them is written to an AgeRail application database, exported, or offered as a download, and values that carry a password or an access token are removed before a record is shown. The audience is operator personnel alone; no merchant, 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 in section 4.5 can carry the same session identifier. For the same security purpose, 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; 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. You can object to this processing under GDPR Art. 21 — see section 7.

9. Business contacts

We receive business contact details from members of our team who know these people in a professional capacity. We use those details to tell them about our age-verification services by email.

Our legal basis is our legitimate interest in developing business relationships under Article 6(1)(f) of the GDPR, balanced against the person's rights and interests. In Spain, Article 19 of the LOPDGDD provides a presumption of legitimate interest for professional contact details where its conditions are met, including limiting the data to what is needed for professional contact and using it to maintain business relationships.

We process the person's name, business email address, company, notes our team adds about each contact, and a record of which emails we sent and whether they asked us to stop. Our team and the service providers that deliver our email receive this data. Those providers may process it outside the EU under the safeguards described in section 6.

We keep contact details until the person objects or we delete the contact, and we review the list regularly. If someone asks us to stop, we keep only a minimal record of their email address in a form that cannot be read back, solely to make sure we do not email them again.

You can object at any time by replying to any of these emails or writing to privacy@agerail.com. You do not need to give a reason, and we will stop using your details to send these emails.

10. Changes

We may update this Privacy Policy by publishing a new version on this page with an updated version line. Material changes will be reflected in the version and effective date shown at the top of this page.

11. Contact

Lalalu Marketing SL
Travessera de Gràcia 73, 4-2
08006 Barcelona, Spain
privacy@agerail.com