Last updated: 6 September 2026 · Terms of Use · Refunds · DPA
This policy explains how Anasa (anasaapp.com) handles personal data, in accordance with the General Data Protection Regulation (GDPR) and Greek Law 4624/2019.
Anasa — sole proprietorship Eleftheria Tsapaki of Polydoros, 1st Parodos Malindretou, Kato Stalos, 735 00 Chania, Crete, VAT no. 112393497, G.E.MI. (General Commercial Registry) no. 152207758000. Contact: info@anasaapp.com. For the data of a client company's drivers & passengers, the controller is that company itself; Anasa acts as the processor (see the DPA).
| Category | Examples | In readable form for us? |
|---|---|---|
| Account | email, company details (name, telephone) that you provide | Yes |
| Booking | passenger name/telephone, pick-up/destination, stops, number of passengers | No — encrypted on your device (§7) |
| Booking | date, time, status, driver assignment, flight number | Yes — queries and notifications are executed on these (§7) |
| Fleet & staff | driver register, vehicles, price list | No — encrypted (§7) |
| Fleet & staff | driver working hours & shifts | Yes — your office staff read them (§7) |
| Fleet & staff | driver's daily equipment declaration (how many child seats he has with him) | Yes — your office reads it in order to assign trips |
| Vehicle position | last GPS position — temporary (see §4) | Yes — only when it is sent: while the driver is sharing his position or is on shift, or if the company has 24/7 equipment. The owner switches off 🗄️ Storing position on the servers (Settings → 🚐 Fleet / Drivers) and then all position storage for the fleet stops. The customer link keeps working: when the driver taps "📍 Share your position" for a specific trip, the position reaches the customer's page and is erased by itself after 2 minutes |
| Your device's position (office) | current position, only when you tap "📍 How far is it from here?" in the booking form or in the map search | No — it is sent once to the routing provider (TomTom, §5) so that the travel time can be calculated, it is not stored anywhere, and your browser asks for permission every time it is needed |
| Technical data | IP address, device/browser type, time of the request — the IP is used transiently for abuse rate-limiting and is not recorded in any document; the exception is "💬 Tell us", where it is kept truncated (without the last number) together with your message | Yes |
We neither request nor seek special categories of data (Article 9) and no field of the application provides for them. The booking note is free text: the transfer company, as controller, must not enter health data there — and if it does, such data is kept encrypted (§7) and is deleted together with the rest of the passenger details (§4). §7 describes in detail what is encrypted and what remains readable, in every case.
The live position is temporary: it ceases to be valid after ~30 minutes, it is continuously replaced while the driver is on shift, and the record is deleted automatically within 24 hours of the last position.
The incident marker on the map (closed road, traffic jam) keeps the point, the time and who placed it. It stops being displayed after 6 hours and the record is deleted automatically within those same 6 hours — no file of the day's incidents remains. By contrast, a point shared by someone (a pick-up, an address) stays until it is deleted by the owner or the office: it is a working tool that you need next time too, not a temporary marker. It keeps whatever was written on it — name, address, note and to whom it was sent.
The passenger's contact details — name, telephone, email, note and the personal tracking link — are deleted automatically 3 months after the trip, from all bookings and from the archive. Two more items leave on the same clock, items that do not look like "contact details" but are: the intermediate stops of a shared transfer — each stop keeps, along with the point, the surnames and telephone numbers of the passengers boarding there — the escort or tour guide of the trip, where there is one (the field asks for a name and telephone, and this is a third party: neither a passenger nor a driver of yours) and the attached document of the booking (agency voucher, PDF, photograph), which states whatever the person who issued it wrote on it. All three are deleted permanently: the document is erased from the file store as well, not only from the booking. On the same clock, the text of the notifications sent to mobile phones is also erased (the "the customer is ready" notification contains a name and a pick-up point) — what remains in the archive is which notification was sent, when, and whether it was delivered; the separate delivery receipt (device, time — without text) erases itself after 90 days. On the same clock, the original message from which the booking came (email, WhatsApp or form) is also erased — in its entirety, not only the fields that were recognised. The transfer company can make this shorter (1 month), but never longer than 6 months, and cannot switch it off: after the trip these details serve no purpose, and what we do not keep can neither leak nor be requested.
Outgoing email passes through the sending service (Resend). That service keeps a copy of the message and the delivery history for up to 30 days from dispatch — this is how it can be seen whether an email was delivered or failed — and deletes them afterwards. Only what the message itself states reaches that service, never the bookings archive. The window belongs to that service and runs independently of our own retention periods.
The line of work (date, route, time, amount, payment method, driver) constitutes the business records of the transfer company — that company is the controller and determines how long they live, from Settings → 👤 Account → "🗑️ Data retention": 3, 6, 12 or 24 months, or no limit. Default: 12 months. Before the first line is deleted, we send two notifications by email: one 14 days beforehand and a final reminder 2 days before, with a button that downloads the entire archive in Excel. The deletion is final.
Team messages — two different periods. The office ↔ driver conversation is workplace documentation and is not deleted automatically: it is kept for as long as the company's account lives. Driver ↔ driver messages are deleted automatically after 3 months, in their entirety — text, sender and time. The reason is that nobody else reads them: neither the owner nor the office has access, so they serve no purpose of the company beyond their moment. The controller for both is the transfer company. Write there what you would write in a shift log — and not details that should not remain.
Deletions take place only according to this schedule — there is no "delete now" button. A request for the deletion of a specific passenger is carried out by the company by deleting the booking itself. Immediately erased are the booking, the amount, the attachment and the record of the tracking link (name and pick-up point). The original message from which the booking came and the text of the notifications follow the clock above — at most 3 months, or whatever the company has set — and backups for up to 35 days. For permanent deletion or the return of all the data of your organisation, send us a written request at info@anasaapp.com — we carry it out within 30 days and give you written confirmation if you ask for it (DPA §5). There is no instant-deletion button, and that is deliberate. You can download your archive (bookings, shifts, cash) in Excel/CSV whenever you want, and before every deletion.
Technical records and support. We do not keep request logs of our own: the IP address is used transiently for abuse rate-limiting and erases itself within hours. One thing you should know clearly: every request to the application passes through the hosting provider (Cloudflare), which keeps whatever it keeps for its own operation and security, under its own terms — we neither create, nor read, nor control those. The tracking link that the passenger receives carries the details of the trip inside the address itself, in plain text — passenger name, pick-up point, destination, driver name and number plate — but after the "#" symbol. That is not a detail: whatever comes after the "#" never leaves the passenger's device. The browser does not send it to the server, so it reaches neither us, nor the hosting provider, nor any intermediate hotel or company network. Only the bare address of the page arrives. What still applies is that anyone who has the link sees the details — which is why the Passenger Notice you give your customers says not to forward it. Whatever you send from "💬 Tell us" (message, any reply email, screen diagnostics and a truncated IP) is kept for up to twelve (12) months from the last communication on that particular matter and is then deleted; it also arrives as an email at info@anasaapp.com, where the support-correspondence period below applies. Support correspondence at info@anasaapp.com is kept for up to twenty-four (24) months from the last communication.
Are you a passenger and want your details deleted? Address the transfer company that made the booking — we act as processor and carry out that company's instructions.
Your own details as a customer (email, company details, settings) are kept for as long as you have an account and are deleted together with it. Tax records are the exception: the accounting documents for your subscription and the related accounting records are kept for five (5) years — for as long as the period within which the tax administration may request them. They are not deleted at your request, because we do not keep them because we want to but because the law requires it (Article 17(3)(b)). A second exception, if you received a refund under the guarantee: the one-way fingerprint of §5 remains, for five (5) years and only so that the same guarantee is not given again to a new account. If you never received a refund, no such record exists for you.
Cloudflare (hosting, server records in KV and a daily backup of the database for up to 35 days), Google Firebase/Firestore (authentication & database), Firebase Cloud Messaging (notifications), Resend (outgoing email), OpenAI (automatic reading of a booking from text or a screenshot — the content of the message is sent to it, which it keeps for up to 30 days for abuse monitoring and does not use for training models), TomTom (address search, routing, traffic), Photon/Komoot (address search & conversion of a point into an address) and OSRM (road travel time — coordinates only; two independent public servers, router.project-osrm.org and, as a fallback when the first does not respond, routing.openstreetmap.de), Cloudflare Email Routing (receipt of messages sent to info@anasaapp.com) and Google (Gmail) — the support mailbox: that is where whatever you send from "💬 Tell us" or write to info@anasaapp.com arrives and is kept, for the periods stated in §4. Within the same Google, Drive / Sheets: an account management spreadsheet that we produce ourselves, manually, from the database — email, name, company, telephone, role, plan and activity dates of each account, usage metrics (number of bookings and trips and, only where the amounts are not encrypted, their sum as turnover), together with the messages from "💬 Tell us" — so that we can see who has signed up and what they need. It is rewritten in full at every refresh; when an account is deleted, it is regenerated without that account and the previous versions of it are deleted (§4). What goes to Photon is the text you type into the address search — that is, the pick-up or destination point; never a name, telephone or any other passenger detail. Separately, only for the public presentation pages and only with your consent: Google Ireland Ltd (Google Analytics 4 — §6; on the presentation page and on the four feature pages) and Meta Platforms Ireland Ltd (Meta Pixel — §6; only on the presentation page). They do not touch the application or any booking data. For your subscription: if you pay by card, Stripe (Stripe Payments Europe, Ltd. — a group headquartered in the USA) acts as intermediary payment provider. It receives your full name or company name, your billing address, your VAT number (if you provide it) and your email. Your card details are given directly to Stripe and never pass through Anasa — we keep only subscription and invoice identifiers. If you are given a refund under the guarantee, we keep a one-way fingerprint (SHA-256) of the VAT number, the billing email and the stable card identifier from Stripe — never the values themselves and never a card number. Purpose: the guarantee applies once per customer (Refund Policy) and without this it would be given again with a new email. Legal basis: legitimate interest (Article 6(1)(f)) — prevention of the abuse of a term that is stated in advance. The fingerprints do not leave us: the collection is closed to every application and to every third party and is not transmitted anywhere. They are not, however, anonymous: they remain personal data in pseudonymised form — they do not by themselves reveal your name or your email, but they do allow anyone who already has a value to check whether it matches. That is why all your rights apply to them (§8). They are kept for five (5) years from the refund — the same horizon as the accounting records of the same transaction — and are deleted automatically afterwards. They survive the deletion of your account: if they left with it, the "once per customer" term would be abolished by closing and opening an account. For fraud prevention and its own regulatory compliance, Stripe acts as an independent controller — for those purposes it does not act on our instructions and your rights are exercised directly against it. If you pay by bank transfer, the payment details remain between you and your bank. Only if you enable them yourself: Meta/WhatsApp Business (incoming WhatsApp messages and your replies to passengers — number and text), Epsilon Net (issuing receipts — only when you issue an accounting document, the passenger's name and email and the amount are sent to it) and the GPS provider you choose (Wialon, GPSWOX, Traccar, Mapon, Navixy). Your Epsilon Smart subscription details (subscription key, API user, password) are stored only on your device — they are not uploaded to your account nor synchronised to other devices. Every time you issue a receipt they travel encrypted through our server to Epsilon and are not stored there; we keep only the indication that a receipt was issued for that particular trip, so that a second one is not transmitted. The WhatsApp Business token (Meta), if you connect your account, is the only one of the three that is stored on our servers: it needs to be there so that a message can go out on your behalf while the application is closed. It is kept encrypted, but with a key of our own — therefore, unlike your booking data, we are technically able to read it, and we say so openly. In clear form we keep only the display number/name and the last 4 digits of the token, so that you can recognise which one you entered. It is deleted when you tap Disconnect — and if the deletion fails, we tell you instead of showing you "done". For flights & the map: AeroDataBox via RapidAPI (flight schedule — the flight number & airport are sent to it, never passenger details), airplanes.live and adsbdb (aircraft position & route — transponder code only), Esri (satellite map tiles), OpenFreeMap (vector map tiles), Open-Meteo (weather on the hotel page — hotel coordinates only) and unpkg (map library). The last four, like every tile or file provider, see the visitor's IP address — not bookings or names. Where the data sits: the database (Firestore) is located in Google's eur3 multi-region — data centres in Belgium and the Netherlands. Your bookings, drivers and customer details remain stored within the EU. Authentication (email and user identifier), the Cloudflare network and the remaining providers above operate on global infrastructure. Some of the above providers are established outside the EEA. Where the recipient is certified under the EU-US Data Privacy Framework, the transfer is based on the relevant adequacy decision of the European Commission; in every other case it is based on the Standard Contractual Clauses (SCC) of the European Commission, with the supplementary measures they require. You may request a copy of the safeguards applying to a specific provider at info@anasaapp.com.
In the application we use only necessary cookies and local storage — and local storage keeps all of your work on the device: your login session, your preferences (theme, layout, screen settings), the local encryption key, the trip archive, your drivers, vehicles, price lists, partners and points, and any third-party credentials you provide (Epsilon Smart, GPS provider). They do not require consent (Law 3471/2006, art. 4(5)), because without them the application does not work. Bear this in mind if you clear your browser data: whatever has not managed to be synchronised to your account goes with it. Inside the application there is no advertising tracking: you work, you are not advertised to.
On the public presentation pages — the presentation page (anasaapp.com/landing) and the feature pages /stolos, /krathseis, /programma and /xrimata — we use Google Analytics 4 (Google Ireland Ltd; the infrastructure includes Google LLC in the USA, certified under the EU-US Data Privacy Framework): it records which sections are read and which buttons are pressed, so that we can improve the page. No measurement or advertising script loads before you press "OK" — not even in a "limited" form. If you press "No", it never loads and we do not ask again.
One Google item loads before any choice of yours, and we write it down because
your browser does indeed talk to Google: the Firebase sign-in SDK
(www.gstatic.com/firebasejs/…), so that the Sign in button works. It is
necessary for the operation of the page (Law 3471/2006, art. 4(5)) and it sets no cookie,
does not count visits and sends nothing for advertising; Google sees what every file provider
sees — your IP address and which file was requested. It is the same authentication
provider as in §5.
On the same page, and only there, we also use the Meta Pixel (Meta Platforms Ireland Ltd): it records the visit and the pressing of buttons, so that we know which advertisement brought people in and so that we do not show an advertisement again to someone who has already signed up. The legal basis is your consent (Law 3471/2006, art. 4(5) · GDPR Article 6(1)(a)); it loads with the same "OK" and, if you press "No", it never loads. We do not send it an email, telephone number or any other identifying detail.
| Name | Where it lives | Purpose | Duration | Recipient |
|---|---|---|---|---|
_ga | cookie | distinguishing visitors | 24 months | |
_ga_TD0ESNXQXM | cookie | GA4 session state | 24 months | |
_fbp | cookie | identifying a visitor for advertising measurement | 3 months | Meta |
anasa_consent | local storage | your own answer to the question ("OK" or "No") | until you clear your browser | nobody — it stays with you |
anasa_noga | cookie | your choice not to be counted at all | 12 months | nobody — it stays with you |
anasa_seen | cookie | remembers that you have an account, so that your next visit takes you straight into the application instead of to the presentation page; it is erased on sign-out | 12 months | nobody — it stays with you |
anasa_* | local storage | your work on the device: sign-in, preferences, encryption key, trip archive, drivers, vehicles, price lists, partners, points, third-party credentials (§6) | until you sign out — except for appearance (theme, layout) and the encryption counter, which remain | nobody |
firestore/… | IndexedDB | a local copy of the company's database, so that the application opens even without a signal — the same ciphertexts that live in the database (§7), not clear names or amounts | until you sign out — it is erased on sign-out; if it cannot be (a second tab is open), you are asked | nobody |
anasa_mcry | IndexedDB | the encryption key, wrapped with your passphrase (§7) | until you sign out — it is erased on sign-out; if it cannot be, you are asked | nobody |
anasa_*, co_intent, __authlog | tab memory (sessionStorage) | the state of the open tab: that you are signed in, that you have seen the showroom, that you asked to go straight into the application from the home page, a temporary cache of the map's flights, which plan you went to buy, and a diagnostic trace of the sign-in (path and parameters of the application's address) | until you close the tab; the sign-in and the showroom are also erased on sign-out | nobody — it stays on your device |
How you withdraw your consent: inside the application, Settings → 🩺 Diagnostics, with the button "🙈 Don't count me in the statistics". It applies immediately, for the whole device, and does not affect the lawfulness of what was done before. The same button puts you back in if you change your mind.
Transport encryption (TLS), data isolation per company, identity verification before every write, per-organisation tokens/signatures.
On-device encryption (enabled by default). Every account sets a secret passphrase when it
starts using the service; without it the application does not work. From that point on, the following are encrypted: the
monetary amounts of the bookings (trip price, cost to a partner or commission from a partner), the pick-up/destination
details, the intermediate stops, the geographical coordinates, the number of passengers,
the passenger details (full name,
telephone, email, note), the list of partner hotels and partners, as well as
the vehicle fleet and the driver register, his price list (trip prices,
chargeable extras and the no-show fee), as well as the cash of each driver (what he collected, what he
handed over, the shift expenses with their description, the float carried over, the cash difference) and
the pay rule of each driver (hourly rate, overtime hourly rate, percentage of revenue), as well as
the tracking link sent to the passenger and kept in the booking — which
contains in its address the passenger's full name, pick-up point and destination, number of passengers,
geographical coordinates of the pick-up and the temporary access credential for the trip.
A consequence of these latest additions: Anasa no longer calculates
any amount — chargeable extras are priced exclusively on the device of the customer or of
his driver, the cash is closed and payroll is calculated entirely on the device, and on our
servers only the quantities are recorded (waiting minutes, number of stops). Three additional options remain at the discretion of the
customer and are disclosed to him before the choice, together with any operating cost they carry: hiding
the number of bookings by creating records with no real substance
("filler records"), which only the device holding the key can distinguish; the
encryption of the flight number, which limits flight-delay notifications;
and the encryption of the tracking link, which is enabled by default and
entails no loss of functionality — the customer may disable it, in which case the link
and the details it contains are kept in readable form until the end of the retention period.
This data is encrypted on the customer's device with AES-256-GCM, with a key
generated locally from a secret passphrase of his own (PBKDF2-SHA256, 600,000 iterations). The passphrase and
the key are neither transmitted to nor stored on our systems; we receive and keep only the
ciphertext, which we have no technical ability to decrypt. The customer may
give each driver a separate access code to the same key, without disclosing his passphrase.
What remains in readable form, in every case: date, time,
trip status, driver assignment, the indication of whether the trip ends at an airport, the extras
that the server records upon completion, the working hours of each driver (start and
end of shift, scheduled hours, overtime hours, vehicle of the day) and the indication that
cash was handed over — without any amount; this data remains readable because it is
read by the customer's office staff, to whom he chooses not to give access to
financial data. Also the total number of records,
which by its nature is not covered by content encryption; level (c) does not hide it
but makes it unrepresentative of the real volume of business.
In the same category belongs the text of the team's messages (office ↔ driver and
driver ↔ driver), together with the sender's name and the time. The messages are written by the
server — and not by the browser — so that nobody can send a message in another person's name;
this means they are kept in readable form. When notifications are enabled, the first
120 characters of the message also travel as a push preview. Access is restricted
technically: the office ↔ driver thread is read by the owner, the office and the particular
driver; driver ↔ driver messages are read by only the two drivers — neither the
owner nor the office, and the thread itself does not even appear in their list.
Do not write there details that you do not want kept in readable form.
Finally, for as long as the tracking link of a trip lives (up to 30 days, and only
if the customer activates it by assigning a vehicle), the server keeps in readable form
the passenger's full name and the pick-up point. The reason is specific and
unique: when the passenger presses "I am ready", the notification that reaches the driver's mobile
must say who is ready and where — a notification saying "some customer is
ready" serves nobody. No destination is kept, nor telephone, nor email, nor
note. The record is erased when the link expires. And when you reply to a passenger via WhatsApp
from "📥 Messages", the server keeps for 90 days a fingerprint (SHA-256) of the
number — not the number — so that the passenger's information link is sent once, not with every
message.
Likewise, when you give a hotel or agency its own portal, the server keeps in
readable form the trade name you typed for it, without expiry, for as long as the
link lives: the page is opened by a hotel employee, who does not have your key and
must see whose portal he is on. The PIN is not stored — only a
cryptographic fingerprint of it is kept, bound to that particular link. When the link is deleted,
the record is deleted too.
Portal notifications. If the reception desk presses "🔔 Notify me", we keep the
push identifier of its device (Google's Firebase Cloud Messaging) bound to that
particular link — for up to 12 months, or until the reception desk disables it or you delete
the link. The notification says only that the request was accepted or that a vehicle was assigned,
with the pick-up time — without a passenger name, driver name or number plate.
The portal's history. So that the reception desk can see what it has sent you, the server also keeps
a copy of every booking and message from that portal — encrypted with a key of
our own, like every incoming item. It keeps it at two levels: in full up to six (6)
months, and afterwards — up to twelve (12) — without any passenger detail.
Name, email and note are deleted, and free-text messages are erased
in their entirety; what remains is the line the reception desk needs in order to prove what it submitted to you:
route, number of people, date and time, flight, child seats, status. At 12 months
the whole thing goes. Why two levels: a city hotel or a corporate account works with you
all year round, and a billing dispute often comes at the end of the year — but the
passenger's personal details may not live in a third party's portal for longer than the
six-month maximum that also applies to your own archive. The full period
is independent of your own setting: if you have set 1 or 3 months, the portal's copy
may live longer — but never more than 6. The Passenger Notice you give your customers
states this too. When the portal's link is deleted, its history
is deleted too.
Incoming messages are the one exception — and we say so plainly. Whatever arrives from outside (an email to your bookings address, WhatsApp, your website's form, the hotel/agency portal, a driver's refund request and the request that the passenger himself sends from the tracking page — receipt, return transfer, extra service) is written by the server, at the moment it arrives: the sender does not have — and must not have — your secret passphrase. Such items are kept on our servers encrypted with a key of our own, which means that, unlike booking data, we are technically able to read them — and we decrypt them every time you open Messages, because otherwise we would not be able to show them to you. The content includes whatever the sender wrote: the passenger's name and telephone, route, note, the entire body of the email — and, when the passenger requests a receipt from the tracking page, the company name, VAT number and email he provided for issuing it. We do not read them — access is restricted to what is necessary for the maintenance, support and security of the service, as set out in §4 of the processing agreement — but the ability exists and there is no point in hiding it. They are erased on the same clock as the passenger details of §4 (3 months by default, 6 at most), in their entirety and not only the fields that were recognised.
The date and the driver assignment are technically necessary: the queries against the database and the isolation of each driver's access are executed on them. Consequently, regardless of encryption, the server knows the mapping of a member account to a set of trips (not their content), since that mapping constitutes the access-control mechanism itself; it also knows the email address of every account created for authentication. The time and the status remain readable for the operation of the notifications generated by the server and of the passenger page.Access, rectification, erasure, restriction, portability and objection. Withdrawal of your consent where the processing is based on it (§3, §6) — without affecting the lawfulness of what was done before the withdrawal.
We reply within one month of receiving the request (Article 12(3)); if the request is complex, the deadline may be extended by two months and we tell you within the first one. To exercise them: info@anasaapp.com.
Right to lodge a complaint with the Hellenic Data Protection Authority (HDPA) — 1-3 Kifisias Ave., 115 23 Athens, tel. 210 6475600, dpa.gr.
For material changes we update this page with a new date and ask you for explicit acceptance inside the application before you continue — your silence is not enough. For non-material changes we do not stop you: the date changes and you see, inside the application, a notice of what changed. We record that it was shown to you, marked as an update — it does not count as explicit acceptance and we never invoke it as such.