Trust

Trust center.

What we receive, where it is processed, who the sub-processors are, how long each record lives, how a data subject request is answered, and how to report a vulnerability. Every answer is written so you can paste it straight into your own questionnaire. The engineering behind each one is on the security page.

Processor of record

Heatrail OÜ
Registry code 16731349
Mõisa 4, 13522 Tallinn
Estonia

At a glance

The short answers.

Role under the GDPR: You are the controller. Heatrail OÜ is your processor, acting only on your documented instructions.
Where data is processed: AWS eu-central-1 (Frankfurt), via Laravel Cloud. No transfer outside the EU.
Sub-processors: Two: Laravel Cloud and AWS. Both in the same region. Section 02.
What we receive: Never a name, address, raw e-mail, raw phone or card number. Contact identifiers arrive already hashed by your own server.
Retention: Signal records are deleted 90 days after the check. The derived risk weight a confirmed fraud carries falls to a third by day 365 and is gone at day 400. Section 04.
Data processing agreement: Concluded at registration. No separate paperwork round. Section 06.
Availability risk to your checkout: None by design. The integration fails open at 800 ms. A Heatrail outage cannot stop a sale. Measured in a staging drill at 16 ms to complete a checkout with us unreachable.
Security framework: Controls mapped to OWASP ASVS Level 2, each naming the code that implements it and the test that proves it. We send the current assessment to teams evaluating Heatrail.
Vulnerability reports: security@heatrail.eu, with the machine-readable policy at /.well-known/security.txt. Section 08.

Sub-processors

Two, both in Frankfurt.

Laravel Cloud: Application hosting, managed Postgres, key-value store and queue workers, the platform the service runs on.; AWS eu-central-1 · Frankfurt, EU
Amazon Web Services: The underlying compute, storage and network beneath Laravel Cloud, including database backups.; eu-central-1 · Frankfurt, EU

That is the complete list. There is no analytics vendor, no logging vendor, no customer-data platform, no e-mail marketing tool and no third-party script inside the service. A new sub-processor is announced on this page, and you are notified, before it processes anything.

Two things that are not sub-processors, answered before you ask

Stripe. Billing runs through Stripe Checkout and the Stripe Billing Portal, so card details live only at Stripe and never on our servers. Stripe processes your billing details as our own customer rather than your shoppers' data, which is why it is not a sub-processor under your data processing agreement. Only Heatrail Pro asks for a card.

No third party on this website. Typefaces, styles and scripts are served from this domain, and the content security policy on every page allows this origin only. Reading these pages discloses your address to nobody but us. Details are in the cookie policy.

Residency

All data stays in the EU.

The application, the Postgres database, the key-value store, the queue workers and the database backups all live in AWS eu-central-1 in Frankfurt. There is no replica, no analytics warehouse and no support tool outside that region. There is no international transfer to assess, which is why there are no standard contractual clauses to send you.

Figure 1

One region carries the whole service, including the backups. The path out of the EU is drawn dashed because it is a path the architecture does not have.

Heatrail OÜ is an Estonian company, and our supervisory authority is the Estonian Data Protection Inspectorate, the Andmekaitse Inspektsioon.

Operator work against production data, including anything done in response to a data subject request, runs from an authenticated console session or a supervised database session, and every console read is recorded in an append-only audit log.

Data & retention

What we hold, for how long, and what deletes it.

Retention here is a scheduled command rather than a policy document. The nightly purge at 03:30 UTC deletes expired signal data and the graph nodes and edges that only those records supported.

Hashed contact identifiers: Twice-hashed e-mail and phone values. The raw values never reach us, and the stored value is not even the one your server computed.; 90 days · nightly purge
Network: The order's IP address, canonicalised before it is stored or compared.; 90 days · nightly purge
Order characteristics: Classes and ranges only: product risk class, quantity, amount range, account-age class, referral-source class. Not the amount, not the basket.; 90 days · nightly purge
References: An order reference and a session pseudonym, so every check is anchored to a real checkout you can be asked about.; 90 days · nightly purge
Device characteristics: Optional, and switchable per shop. Bounded, allowlisted fields, screen geometry, time zone, language list, platform class and similar, never a raw user-agent string. A device configuration is not a device, and a device is not a person, so device similarity on its own never raises a warning.; 90 days · nightly purge
Derived risk weight: The weight a confirmed fraud label still lends to the traits it touched. It holds full weight to day 90, falls to a third by day 365, and the entry is gone at day 400. It is derived from the records above and carries none of their fields.; 400 days · decaying
Confirmed fraud evidence: Records tied to an active fraud or chargeback incident are held beyond the window as evidence for legal claims, under GDPR Article 17(3). A real label gets no exception, and a reversed incident stops protecting its records, so a correction genuinely restores the normal window.; Retained while the incident is active
Ledger and audit log: Append-only and never purged, but they carry only identifiers, hash prefixes, digests of order references and event metadata, never raw identifiers or device data. When a referenced record is deleted, the integrity proof survives and the personal data does not. That is how "immutable history" and "90-day retention" are both true at once.; Retained · minimised by construction
Your account data: Contact and billing details for the shop itself, held while the account exists. On termination we delete or return the personal data processed on your behalf, at your choice, except where law requires retention.; Life of the account

Figure 2

Two clocks, and they are not the same one. The record that a score was computed from ends at day 90. The weight a confirmed fraud lends to the network outlives it and reaches zero at day 400.

The purge runs nightly from the schedule, and a test suite ages records artificially and asserts that they are gone after the window.

Disclosure

The page your customers can read.

A shopper can find out what a shop's use of Heatrail means for their order, from one hosted page written for the person buying something rather than for their lawyer. It is public, it names the categories of data involved, and it is live:

Customer disclosure page

You may link it from your own privacy notice. Your privacy notice remains yours to write, you are the controller, but this gives you a stable page to point at instead of paraphrasing us, and it means a shopper who asks "what is Heatrail" gets the same answer you would give.

Data subject requests

Requests reach us through you, never directly, because you are the controller. A data subject who writes to us is not turned away. They are told in writing to route the request through the shop, and we notify you the same day. We then assist you: recomputing the hashes needed to locate records, deleting what is not fraud evidence, and documenting an Article 17(3) refusal in writing where the exception applies, with the weighing decision recorded rather than assumed. The decision is yours. We execute and document it.

Requests are handled through a documented procedure performed by an operator, and every step is recorded. Write to privacy@heatrail.eu.

Agreements

The DPA is concluded at registration.

Registration in the partner portal is where you accept the Terms of Service and the Article 28 data processing agreement together. There is no separate paperwork round, no PDF to chase through signature software and no minimum contract value before we will sign one. The current text of both is on this site, Terms of Service and Data Processing Agreement, so your counsel can read them before anyone creates an account.

Instructions: We process only on your documented instructions, the agreement itself plus your configuration. That includes your right to stop processing at any moment with a single switch in your own integration, without involving us.
Confidentiality: Everyone with access to the processing is under a confidentiality obligation.
Article 32 measures: Encrypted transport, signed requests, an append-only event chain, two-factor authentication on operator accounts, an audit log, and data minimisation through hashing. Each is described mechanically on the security page.
Sub-processors: No new sub-processor without notifying you first. The current list is section 02 and this page is where a change would appear.
Audit and information: We give you the information you need to verify our compliance. In practice that is the current ASVS assessment, this page, and a direct answer from an engineer to a specific question.
Termination: On termination we delete or return the personal data processed on your behalf, at your choice, except where a legal obligation requires us to keep it.

Self-service registration is open, and the agreement is concluded there: the Terms and the data processing agreement are accepted at signup, before any processing begins and before any card details are entered. If you would rather agree the same terms directly and in writing, write to hello@heatrail.eu.

Backups

Seven days of backups, restorable to any point inside them.

Automated backups: Enabled on the production database cluster since 1 September 2026, with seven-day retention and point-in-time restore. Backups stay in the same EU region as the database, under the same two sub-processors.
What a restore recovers: The full database, including the ledger. Because the chain is verified against a signed anchor, a restored ledger can be checked rather than assumed, and the same nightly command that detects tampering also tells you whether a restored copy is the real one.
What a restore does to your checkout: Nothing. The integration fails open, so the cost of any interruption on our side is the signal for the orders placed during it. Your orders complete either way, and the checks queued during the gap are processed when we answer again.
What we keep outside the database: The signing keys the ledger anchors are verified against, and nothing else. Backups carry no raw identifiers, because the live database holds none either.

Incidents

What we owe you if something goes wrong.

If we become aware of a personal data breach affecting data we process for you, we notify you without undue delay. You are the controller, so the Article 33 clock, 72 hours to your supervisory authority, is yours to run. Our obligation is to give you what you need to run it in time, not to notify the authority on your behalf.

The notification tells you what we know at the time of writing:

the nature of the breach and the categories and approximate volume of records
what we have established about cause and blast radius, and what is still unknown
the likely consequences, stated in terms of the data we actually hold, which, for signal data, is hashed identifiers rather than contact details
the measures taken or proposed, including anything you need to do at your end
a named contact who will keep answering as the picture changes

The first notice goes out as soon as there is something to tell you, and it is corrected in writing as the picture changes. Our contact for this is privacy@heatrail.eu.

Reporting a vulnerability

Technical reports go to security@heatrail.eu. The machine-readable policy is at /.well-known/security.txt, published byte for byte at heatrail.eu, api.heatrail.eu and portal.heatrail.eu, so a scanner finds the same policy wherever it looks. We welcome coordinated disclosure and will not pursue good-faith security research. Give us a reasonable window before publishing, and do not run tests that would degrade a shop checkout. That is the one thing this product exists to protect.

How tampering is detected

Tamper detection runs every night against the signed anchors and exits non-zero on any failure. A failed run e-mails the operator and is surfaced in the operator console.

privacy@heatrail.eu: Data protection, data subject requests, breach notification.
security@heatrail.eu: Vulnerability reports and coordinated disclosure.
hello@heatrail.eu: Security questionnaires, written agreements, everything else.

Status

Your checkout does not depend on our uptime.

The integration fails open. If Heatrail is slow or unreachable, the check returns degraded inside the 800 ms budget and the order completes. An outage on our side costs a signal for those orders, never a sale.

Measured on the first day in production, 1 September 2026: a median round trip of 386 ms and a 95th percentile of 610 ms against the hard 800 ms budget, with the slowest call of the day at 799 ms, inside it. In a staging drill the same day, with the service deliberately made unreachable, the checkout completed in 16 ms.

Questionnaire

Frequently asked security questions.

Can Heatrail block one of our orders?: No. There is no mechanism for it. We return a score and reasons, and your code decides what to do. The client abandons the call at 800 ms and the order proceeds.
Do you receive our customers' e-mail addresses?: No. Your server hashes them before the request is built, and we hash the result again before storing it. There is no configuration on our side that can cause us to receive a raw value, because the raw value never enters the request.
Is a hashed e-mail address still personal data?: Yes, and we treat it as such, processed as your processor, under a data processing agreement, in the EU. Hashing reduces the harm of a compromise, but it does not remove the obligation.
Do you use AI or machine learning to score orders?: No. Scoring is rule-based, and the response names the rules that fired, so a decision you make on the back of it can be explained to the person it affected.
Can another shop see our data?: No. A request for a resource belonging to another shop returns 404, not 403, so a competitor cannot even learn that one of your orders exists. Shared state is exposed as categories, never as another shop's records.
Can one merchant put our customers on a blocklist?: No. There is no list, and nothing Heatrail returns can block a purchase. A single shop's fraud label does make the buyer's device and IP hot for every Pro shop at once, as an advisory reason. A typed e-mail or phone carries full weight at other shops only once it is verified or tied to that same device, network-level heat requires two independently owned shops, and an operator cannot write network heat.
Do you hold card data?: Never. Payment details exist only in Stripe. Nothing in the check payload can even express a card number, unknown fields are rejected.
Which security framework do you follow?: OWASP ASVS Level 2. Every control names the code that implements it and the test that proves it. Ask us and we will send the current assessment.
Where do we sign the DPA?: At registration, together with the Terms. The text is public on this site before you create an account, and there is no separate paperwork.
What happens to our data if we leave?: Deleted or returned, at your choice, except where law requires retention. Signal data also ages out on the 90-day window on its own.
Who do we send a security questionnaire to?: hello@heatrail.eu. We answer questionnaires ourselves, directly, rather than through a portal.

If something here is not enough detail, ask for more.

Security & architecture Customer disclosure page Contact