Trust by construction: multi-tenant architecture and data protection in CETAIN

01Why architecture is a buying question

A transport management system holds commercially sensitive data — customers, lanes, volumes, prices — and personal data about drivers, receivers and staff. In a multi-tenant platform, many companies share the same application and database, sometimes including competitors. The single most important property of such a platform is that one company can never see another's data, and the second most important is being able to show why that is true.

This paper explains the design decisions behind CETAIN that answer those questions, and the ones that follow from them: who can do what, how changes are recorded, how the rules adapt between India and Europe, and how privacy rights are handled. It describes the platform's design; for which parts have a finished screen today, see the platform status page.

02Entities and jurisdiction profiles

Every company on CETAIN is an entity — either a sender (a company that books transport) or a transport company. An entity is created by a platform administrator with three key inputs: its country, which selects the jurisdiction, currency and time zone; its default language; and, for transport companies, its consignment document — CMR in Europe, LR or GC note in India.

Rules that used to be hard-coded per country live in a jurisdiction profile. Today there are two: one for India, and one for the EU-27 plus Norway, Iceland, Liechtenstein, Switzerland and the UK. A profile decides, among other things:

• which tax identifier is valid and how it is checked (GSTIN, or VAT with a VIES lookup);
• postal-code formats and how rate zones are resolved;
• which driver and vehicle documents are required before assignment;
• the dangerous-goods regime and the certificate it requires;
• driving-time thresholds, and whether they block or only warn;
• which data-subject request types exist and when they are due.

Changing those settings is split by responsibility. A transport company's administrator can edit its own entity's name, language, document type, tax identifiers and GST option. Only a platform administrator can change the jurisdiction, the currency, or any setting that switches a compliance gate on or off — and a jurisdiction must match the entity's country, so an Indian company cannot quietly be given European rules.

03Isolation by construction

Tenant isolation usually fails in a mundane way: a new query, written in a hurry, forgets the filter. CETAIN closes that gap structurally. Every table that holds an entity's data is listed with the column that identifies its owner, and those tables can only be queried through a single helper that adds the entity filter. A test in the repository scans the code for raw queries against those tables and fails the build if it finds one. A forgotten filter becomes a failed build, not a data leak.

Feature switches follow the same principle. Each module — ADR, CO₂ reporting and others — can be switched on or off per entity. When a module is off, its screens are hidden and its API answers 403. Hiding a button is a convenience; refusing the request is the control.

The exceptions, named

Two features deliberately look beyond a single entity, and both are kept narrow:

• Receiver identity. A receiver often deals with several carriers. CETAIN gives them one account that links to bookings across carriers, but only through an e-mail address the receiver has verified. It is the only place built to join across entities, and it is isolated as its own module.
• Public tracking. Anyone with a tracking code and the delivery postal code can see a shipment's status timeline — and nothing else. Lookups are rate-limited per IP address, and a wrong combination returns exactly the same response as a non-existent code, so the page cannot be used to discover valid codes.

04Roles and sign-in

CETAIN has six roles: sender user, receiver user, dispatcher, driver, transport administrator and platform administrator. Each sees only what its job needs — a driver sees an itinerary, not the company's rate rules.

Sign-in is designed around common attack patterns^[1]. Passwords are stored as bcrypt hashes. Every authentication endpoint is rate-limited and failed attempts are tracked per account and per IP address, with progressive throttling and lockout. Password reset uses single-use tokens. Staff sessions use signed access tokens that expire after 15 minutes by default and are renewed with refresh tokens.

The sign-in method is a property of each user rather than of the company, so one company can mix methods — email and password for some users, a Google or Microsoft account for others, or a one-time code sent to a phone number stored in international (E.164) format once an SMS provider is connected. Enterprise single sign-on is planned on demand, through an established identity provider rather than a hand-built implementation.

05Evidence and auditability

In transport, software is regularly asked to settle an argument: was the booking accepted, when did the truck arrive, who changed the delivery window. CETAIN is built so that the answer comes from the system, not from memory.

• Attributed history. Every status change and every edit to a booking after submission is recorded with the user and the time. Consent changes and data-subject requests are recorded the same way.
• Server time, not phone time. Charges such as detention are computed from server-recorded arrival and proof-of-delivery timestamps. Times typed into a device are never the basis for money.
• Documents are never rewritten. Regenerating a consignment note inserts a new version; the snapshot of an issued note is not modified.
• Safe to repeat. Bulk imports keep a per-row ledger so a re-uploaded file does not duplicate bookings; e-way bill generation skips invoices that already have a bill; an escalation fires once per booking and trigger.

06Language as data

A platform used by a Dutch shipper, a German carrier and an Indian transporter cannot treat translation as an afterthought. In CETAIN every interface string lives in a flat key-to-text JSON file per language, with English as the source. A list of languages declares which are available; adding a language means adding its file — no code change. Administrators can override individual strings in a translation manager, stored as overrides and exportable as JSON.

The browser ships with English built in, fetches the chosen language from the server, caches it, and only switches once the fetch has succeeded — so a slow network never leaves a screen half-translated. Language also follows the record: consignment documents are issued in the entity's language, and notifications and one-time-code messages use the recipient's preferred language, falling back to their entity's.

The first release supports English, Hindi, Dutch and German. Strings outside English were drafted with machine assistance and are reviewed by native speakers before each rollout.

07Privacy rights as workflows

Privacy law gives individuals rights and gives organisations deadlines. In practice the hard part is not knowing the law but handling a request on time, without an engineer and without destroying records that other laws require. CETAIN models the request types and deadlines per jurisdiction:

Erasure without breaking the record

Deleting a driver's row would break every delivery record that driver signed — records that tax and transport law may require a company to keep. CETAIN therefore erases by anonymisation: name, e-mail, phone number, external sign-in identifiers and the password hash are replaced or removed, while legal records such as issued consignment notes keep their now-anonymous reference. What was anonymised is logged so the action can be reviewed.

Breaches, consent and offboarding

A breach register records incidents per entity and counts down the 72-hour notification deadline. Consent is recorded per purpose, with withdrawal recorded the same way. When a customer leaves — or exercises portability — an entity export produces a copy of that entity's data.

08Features that ship switched off

Some features are only safe once a decision has been made outside the software. CETAIN ships them switched off.

The clearest example is CO₂ reporting. A per-shipment emissions figure is easy to compute and easy to get wrong, and a shipper may put it in its own sustainability report. CETAIN's CO₂ estimate is therefore gated twice: the module must be switched on for the entity, and the platform must be explicitly configured to say that an emission-factor methodology has been agreed. Until both are true, no figure is produced — because a confident wrong number is worse than none.

The same thinking applies to India's driver working-hour limits, which run as warnings until the applicable limits are confirmed, and to integrations with outside providers, which are built as adapters but stay in placeholder mode until a provider is contracted and tested.

09Platform and integration posture

• Stack. A Node.js REST API with versioned endpoints, a MySQL/MariaDB database and a React single-page web client. The same build runs on ordinary managed hosting.
• Versioned API. Endpoints live under a version prefix so integrations are protected from internal changes.
• Adapters, not hard dependencies. E-mail, SMS, WhatsApp, one-time codes, e-way bill generation and verification, and route suggestion are each behind an adapter. Each is switched on per deployment once a provider is chosen.
• Browser-first. All five surfaces — sender, receiver, operations, driver and administration — run in a desktop or phone browser, without an app-store install.
• Accessibility. The application targets WCAG 2.1 level AA^[5], increasingly a procurement requirement for larger customers.

10Questions to ask any TMS vendor

Whether or not you choose CETAIN, these questions separate a platform you can trust with your customers' data from one you cannot:

1. How is tenant isolation enforced — by convention, or by something that fails when it is broken?
2. Which features cross tenant boundaries, and how are they restricted?
3. When a module is switched off, is its API closed or only its menu item hidden?
4. Are charges computed from server timestamps or device times?
5. Can you show the history of a booking: who changed what, and when?
6. How is an erasure request handled without destroying legally required records?
7. Where do rules for my country live, and who is allowed to change them?
8. Which integrations are live, and which are placeholders waiting for a provider?

We are happy to answer each of them for CETAIN in a demo — including the ones where the honest answer is "not yet".

SourcesReferences

1. Authentication Cheat Sheet — OWASP Cheat Sheet Series
2. Regulation (EU) 2016/679 — General Data Protection Regulation — EUR-Lex
3. Government notifies DPDP Rules to empower citizens and protect privacy (14 November 2025) — Press Information Bureau, Government of India
4. Digital Personal Data Protection Rules notified by MeitY — EY India tax alert, November 2025
5. Web Content Accessibility Guidelines (WCAG) 2.1 — W3C