Data Processing Addendum

This addendum forms part of the Terms of Service between TacLine LLC (“we”, “the Service Provider”) and the subscribing agency (“you”, “the Business”). Where it and the Terms disagree about personal information, this document wins.

It is written to California’s Consumer Privacy Act as amended by the CPRA, and to the comparable laws of Colorado, Connecticut, Texas, Virginia and other states that follow the same shape. The defined terms (business, service provider, personal information, sell, share, business purpose) carry their statutory meanings.

Scope note. This addendum covers United States privacy law only. If you book travelers resident in the EU or the UK, the GDPR reaches that processing and this document does not address it. Tell us and we will agree the additional terms; do not assume this one covers it.

1. Who is who

You are the business. You decide what personal information goes into ONE Travel OS, whose it is, why you hold it, and how long. You are the one who owes your households, travelers and advisors a privacy notice and an answer to their requests.

We are your service provider. We process that information only to provide ONE Travel OS to you, on your instructions, and for nothing of our own.

This holds for every category an agency puts in: households and travelers, trips and bookings, financial records, uploaded documents, supplier contacts and credentials, correspondence where a mailbox is connected, and your own advisors’ payout and tax records.

2. Your instructions

The Terms, the app’s own settings, and anything you tell us in writing are your instructions. We follow them.

If an instruction would in our view break the law, we will say so and will not carry it out until we have both looked at it.

What reaches the document parsers, and on whose instruction

The two document-parsing services in section 3 are the one place where a document of yours is read by a machine-learning model, and one of them is a party we cannot fully bind, so it is worth being exact about what starts that. Nothing is sent to either on a schedule, in a sweep, in bulk, or because we decided to. One document goes at a time, and only when a person acts:

• Somebody at your agency uploads it, on a deposit or on a trip.
• Somebody emails it to one of the forwarding addresses your agency has handed out, having been shown, at the place they got the address, where a document sent to it goes.
• Somebody at your agency asks us to read a traveler’s passport (one already on that traveler’s record) after confirming, on the screen that sends it, that the traveler agreed to have it read by an outside service. We record who confirmed that, and when.
• A traveler of yours asks us to read their own identity document: a passport they have just photographed in your client portal, where they pressed a button that says the scan goes to an outside service to be read, and where not pressing it costs them nothing but typing the details themselves.

Each of those acts is an instruction under this section, and they are the only things that begin a transfer. We do not read your mailboxes for documents to parse, and we do not parse a document twice because a job ran again.

The last two acts are not the same as the first two, and they have their own switch. The document is an identity document rather than a commercial one, and it belongs to a traveler, who is not the one agreeing to this addendum. So they are governed separately: an agency that has enabled document parsing has not thereby enabled either of them. See section 3, “Only if you switch it on”: there are two switches and the second is off until it is deliberately turned on, whatever the first one says.

Switch a control off and none of it can happen: the upload control and the forwarding addresses are not shown anywhere, including in your households’ portals, and a document that reaches us regardless is refused, sent nowhere, and not kept.

3. What we will not do

We will not, and we are contractually barred from:

• Selling personal information, or sharing it for cross-context behavioral advertising, as those terms are defined in California law.
• Retaining, using or disclosing it for any purpose other than providing ONE Travel OS to you, including any commercial purpose of our own.
• Retaining, using or disclosing it outside our direct business relationship with you.
• Combining it with personal information from another agency, from another service, or from any other source, except as the law expressly permits a service provider.
• Using it to develop, train, benchmark or improve any machine-learning or artificial-intelligence model of our own, or handing it to anyone else so that they can, except for Reducto, one of the two document-parsing services, immediately below.

We certify that we understand these restrictions and will comply with them.

Two document-parsing services

Two outside services read documents for us, and section 10 names both: Reducto, and Google Cloud (Vertex AI), which reads them with Google’s Gemini models. They are not under the same terms, and this section says where each one stands.

Google Cloud (Vertex AI) is under the bar above. It acts as our processor under Google’s Cloud Data Processing Addendum, and Google’s own terms for the service bar it from using what we send to train or fine-tune its models without our permission, which we have not given and will not give. It is bound by the sentence at the head of section 10 like the other services there.

Nothing we send it is kept. By Google’s own account, a request its automated abuse checks flag could be stored for up to 90 days (never for training), and Google lifts that logging for a project only on approval. On 29 September 2026 it approved ours, for both the projects ONE Travel OS uses. The service’s own cache of what we send is switched off in those projects too, and we use no feature of it that would keep anything else: no grounding against Google Search or Google Maps, no stored conversation state, no batch processing. What we send it is read, answered, and not retained.

Which service reads a given document is our choice, made for the whole of ONE Travel OS rather than agency by agency, and two things are never chosen. Commission statements are read by Google Cloud (Vertex AI) or not at all: we never choose Reducto to read one, and where Google Cloud (Vertex AI) is not configured, statement parsing is off and statements are imported as CSV. (A statement somebody uploads on a trip is treated as the booking confirmation it was uploaded as.) And an identity document is never sent to Reducto to be read; see below.

The one exception, stated plainly

Reducto, the other document-parsing service in section 10, is permitted by its own terms to use documents submitted to it to train and improve its own models and services. Their terms take a license over what is submitted “to develop and improve the Services, to develop new offerings or features, and for our other business purposes”: wording broad enough to cover training, and they publish an undertaking never to train on customer data as a feature of a higher plan than ours, which is the clearest evidence of what our plan does not include.

We are on Reducto’s Standard plan; they do not offer an agreement barring this at our level, and we asked. So for the documents that go to it, and only those, we cannot make you the promise the last bullet above makes about everything else. Assume a document sent to Reducto may be used to train it.

That sentence is why we never choose Reducto to read an identity document. A commission statement is commercial paperwork; a passport is a person’s identity, and it belongs to a traveler who is not the one agreeing to any of this. We are not going to put it in front of a service that may train on it. So a passport is read only by Google Cloud (Vertex AI), only where you have turned on the second switch below, only on one of the two acts in section 2 that ask for it (the traveler’s own press in the portal, or your staff’s after the traveler agreed) and never as the price of using the portal: a traveler who declines types the details in instead, and nothing they get is worse for it.

How that is kept true when somebody sends one anyway. Before anything reads an emailed document, or any document bound for Reducto, Google Cloud (Vertex AI) is asked one question about it, namely what kind of document it is: a statement, a confirmation, an identity document, or something else. Nothing else is asked for and nothing else comes back. An identity document is then refused: it is not read for its details, nothing is sent to Reducto, the file is not kept, and where it was emailed the advisor is asked to get it through the portal instead. An emailed document that is not the kind its address is for is refused the same way. So a passport emailed to a trip’s forwarding address is seen by Google Cloud (Vertex AI) only long enough to be recognized, and by nobody else.

We would rather write that down than let the sentences above quietly cover something they do not.

What limits both services:

• Only documents. Each receives the commission statement, booking confirmation, or traveler’s identity document handed to it and nothing else: no household list, no trip history, no mailbox, no database access.
• Only the fields we ask for, and the list depends on which kind of document it is. For a statement or confirmation: references, names, dates and amounts. For an identity document: the names, date of birth, document number, issuing country, and issue and expiry dates, plus the two machine-readable lines at the foot of the page, which we use only to check the others against their check digits and then discard. Nothing read from a passport is written to the traveler’s record until a person has checked it and saved it. A document’s other contents are not returned to us. That limits what we receive; it does not limit what Reducto holds.
• Only if you switch it on, and there are two switches. Both are off until one of your admins turns them on, under “Document parsing” in Agency settings, on a screen that states what this section states before either can be ticked.
  • Document parsing covers the statements and confirmations your agency uploads or forwards.
  • Identity documents covers the last two acts in section 2: a traveler asking us to read their own passport, and your staff asking us to read one with the traveler’s agreement. Enabling the first does not enable this one. It was added after document parsing, and an agency that agreed to send us commercial paperwork has not thereby agreed to send us its travelers’ identity documents. If you never turn it on, no passport of your travelers’ is ever read for its details, and the option to have one read is offered to nobody. One that is emailed anyway is only recognized, refused and not kept, as described above.

  While a switch is off, an agency sends neither service anything of that kind; see section 2 for what happens to a document that arrives anyway.

• Only on somebody’s deliberate act. Nothing is swept, scheduled or sent in bulk; section 2 sets out the acts that send a document and says they are the only ones.
• Never a card number we can read. A document’s own text is read for card numbers when it arrives, and the answer a parser returns is read again; one found at either point is refused outright and not imported. A card in a photograph, or in a scan with no text in it, leaves nothing for that reading to find.

If this is not acceptable to you, do not enable document parsing, and tell us; it is the kind of objection section 10’s notice provision exists for.

4. Ownership

The personal information stays yours. Nothing here transfers any right in it to us, and our holding it creates no claim over it.

5. Confidentiality and the people who touch it

Access is limited to the people who need it to run ONE Travel OS and support you. Each is bound to confidentiality that outlives their engagement, and each has only the access their job requires.

Two access paths exist, and both are recorded:

We do not read your data for any other purpose.

6. Security

We maintain reasonable security appropriate to the sensitivity of what we hold. In particular:

• Each agency’s records are scoped to that agency and the scoping is enforced by the application on every query.
• Passwords are hashed. Passport numbers, dates of birth, known traveler and redress numbers, loyalty membership numbers, advisor taxpayer numbers and bank details, supplier portal credentials, mailbox tokens and two-factor secrets are each encrypted at rest, so database access is not the same as reading them.
• Two-factor authentication is available to all users and on by default for administrators.
• Documents are served behind an authenticated check with links that expire after five minutes.
• Payment card numbers are refused in ordinary use: notes and outgoing mail are scanned and rejected if they contain one, an uploaded file is scanned wherever it has text to read and refused the same way, and brand and last four digits are the only card facts our own records hold. A file we cannot read the text of is not checked: a photograph, a screenshot, a scan with no text in it, a password-protected document. We record that it was not checked rather than treating it as clean. ONE Travel OS does not hold a card for a household in any form, encrypted or not.
• Record changes are versioned, giving an audit trail of who changed what.
• Error reports carry no personal information and no performance traces.
• Traffic is encrypted in transit.

Breach notification. If we learn of a breach of security leading to the unauthorized disclosure of, or access to, your personal information, we will tell you without undue delay and within 72 hours of becoming aware, with what we know, what we are doing, and what we suggest you do. We will help you meet your own notification duties.

7. Helping you answer requests

Where one of your households, travelers or advisors exercises a right against you, we will help you honor it.

• ONE Travel OS already lets you do most of it yourself: erase a household’s or a traveler’s personal information, look up everything held against an email address, and export it.
• Where the app cannot, ask us and we will assist within a timeframe that lets you meet your own deadline.
• If a request reaches us directly, we will not act on it. We will pass it to you and tell the person we have done so, because deciding whether one of your records should exist is yours and not ours.

8. Deleting and returning it

During your subscription you can export your data at any time, and erase household and traveler personal information yourself.

When the subscription ends you have thirty days to export. After that we delete your agency’s data, backups included, within ninety days.

Two exceptions, both narrow: anything we must keep by law, and anything under a legal hold. Either is kept under the same protections, used for nothing else, and deleted when the reason for keeping it ends.

9. Checking that we do this

You may ask us, once a year, for the information reasonably needed to confirm we are meeting this addendum, and we will provide it. Where a written answer is not enough for a genuine concern, we will agree a proportionate way for you or an independent assessor to check, at your cost, on reasonable notice, and without access to another agency’s data.

We may take reasonable and appropriate steps to stop and remediate any unauthorized use we discover.

10. Other services we use

We use the services below to run ONE Travel OS. Each except Reducto, Google (Maps Platform), Creem and Unsplash is bound to use what it holds only to provide its service to us. Several are optional and off unless configured, and the table says which.

Five things this table is careful about.

Google appears twice, under two different arrangements. Google Maps Platform runs under Google’s own controller-to-controller terms, in which each party is an independent controller of what it receives. For maps, Google is not a service provider acting on our instructions; we cannot restrict what it does with what it receives the way we can the other services here, and section 3’s bar on training machine-learning models does not reach it. Its row therefore sets out exactly what reaches Google and what never does. Google Cloud (Vertex AI) is the opposite case: there Google is our processor, bound by the sentence above the table, and section 3 says what its terms bar. Nothing sent to one reaches the other through us.

Unsplash decides its own purposes for what it receives. Unsplash’s API terms bind us, not Unsplash: they set how we may show its photographs, and require us to tell it when one is chosen. What Unsplash does with the searches it answers and the image requests browsers make to it is governed by its own privacy policy, and we cannot restrict it the way we can the services bound by the sentence above the table. That is why its row limits what is sent to a destination’s text and nothing about the people traveling, and why it is named as an exception.

Creem is a seller, not a processor, and that is why it is an exception. Creem is the merchant of record for your subscription to ONE Travel OS: when your agency subscribes, Creem is the party that sells to you and takes your money, and we are paid by Creem afterwards. It is therefore not acting on our instructions about your billing information the way a service provider would; it has obligations of its own that we could not instruct away if we wanted to, chiefly keeping transaction records and registering for, collecting and remitting the tax on the sale. What that means in practice is narrower than it sounds, and the row says so: what Creem receives is your agency’s own billing details, and nothing your households or travelers ever gave you goes to it. Creem is not involved in the planning fees you collect from your households; that is Stripe, in the row above, and the two are separate arrangements pointing in opposite directions.

Documenso is not on it. Electronic signature runs on a Documenso instance we host ourselves, on our own infrastructure. No signing company receives your agreements. The documents it stores land in the object storage row above.

Your own connected services are yours. A mailbox you connect, a Stripe account you own, a Mercury account you connect to pay your advisors, a mail server you run: your agreement is with that provider, and they are not our subprocessors. When you connect Mercury, we send it, on your instruction, the advisors you pay and each contractor’s signed W-9, which carries their taxpayer identification number, so that Mercury can ask them for the bank account their payouts go to. If you also choose a Mercury account that commission payments arrive in, we read the payments into it once an hour: each payment’s amount, the date it posted, the payer’s name and the bank’s description of it, so that your staff can record it as a deposit. We do not keep the payer’s account or routing number, which Mercury sends with each payment, and we delete a payment nobody recorded 90 days after it posted.

Changing this list

We will tell you at least thirty days before adding a service that will handle your personal information. If you reasonably object on privacy grounds, tell us within those thirty days and we will work it out with you; if we cannot, you may end your subscription for the affected service without penalty.

11. Where the data is

ONE Travel OS and its database run in the East US 2 region (United States), and we do not move your data outside it except through the services in section 10.

12. Term

This addendum lasts as long as we hold any of your personal information, which is longer than the subscription. Sections 3, 4, 5, 6 and 8 survive termination.

Changes to this addendum

---

Questions about this addendum go to onetravelos@taclinetech.com.