Data & privacy

Himmel keeps the evidence that a transaction was checked, and as little about people as that evidence allows.

What you send

Send references that mean something only to your own systems: transaction.ref, an execution report's ref, note_ref, every value in provenance, and transaction.actor.on_behalf_of, the person an agent acts for. Any of them that looks like an email address or an IBAN is refused with pii-in-facts. People in your own account are named by their Himmel id, never by name: see Authentication.

Recipients are the one exception, because some rules total per recipient. A recipient's name, organisation and email address are replaced by tokens before anything is stored, and before anything else reads them. The names are kept apart, encrypted, and read only through the part of the service that resolves recipients. They are shown only to people: someone signed in to the console as an admin or ops sees a recipient's name, and an API key, whatever its scopes, is given ids. A recipient's numbers - a customer number, a supplier number - are your own references for them, kept as sent so that the same number finds the same customer; the console shows them to anyone signed in, and a key is never given them. Anything else that looks like an email address or an IBAN is refused, wherever it appears. A name has no shape to recognise, so none is guessed at: a check takes only the facts its rule set declares — dates, amounts, accounts, codes — and your references should mean something only to your own systems.

No model answers a check

Every answer comes from rules your company confirmed, applied the same way every time: the same facts, the same history and the same rule versions give the same answer, for as long as the check is kept. No check calls a language model, and no answer is a score: never a probability.

A language model is used, optionally, in one place: drafting a policy's rules from an uploaded document. It only ever sees masked text, with the names you list, the people in your account, every word that reads as a name, every email address, IBAN and phone number, and any name you hide on reading the text back replaced by placeholders — before anything is drafted, you read it, and a name still in it is hidden where it stands. Where the document revises a policy, it also sees that policy's rules and the document they were drafted from, masked again the same way. A word hidden because it reads as a name is shown, on the document's page, to an admin or ops in your account, so that they can show it again where it is none; no key is ever given one. What it sends back is kept with the document — each reply, written from the masked text — so that a drafting cut short is taken up again without paying for a reply twice. What it drafts runs only once your rule owner confirms it. See Policies.

What is kept

Every check is kept with everything behind it — the facts, the history it read, your settings, the rule versions and who confirmed them — and so is every transaction a check stored. Checks keep recipient ids and your own references rather than names, so the evidence stands on its own. The retention period for checks is a setting of your account, stated when your account is opened: the period your records must be kept for.

Names are kept only as long as they are needed. A customer's names and addresses are deleted once the fiscal year after the one they were last met in has ended; the address of a person in your account is kept for as long as they are in it, and their name - the one they gave when they joined or opened your account, or the one they sign in to the console with - for as long as the evidence that names them is kept, since every answer, confirmation and approval that names them keeps naming them after they leave; the names a policy document's masking hid, for as long as the document is kept; and anything else 90 days after it was last used. A stored reply to a request sent with an Idempotency-Key is deleted once its 24 hours are past, and what tells a retry from another request is kept as a hash keyed with a secret of the server's own, so it gives nothing it was made from away to whoever reads it without that secret. When an account is opened, the network address the request came from is kept for a day as such a keyed hash - never the address - to count the accounts opened from one address in a day. See Recipients for what a customer whose name was deleted looks like.

Isolation

Every account's data is separated by the database itself: each request runs as a role that can see one account's rows and no others. Live and test are kept apart the same way: what you send with a test key is stored as test data, and is never read by a live request. A check is never updated once stored — a changed answer is a new check that supersedes the old one — and that, too, is a permission rather than a promise.

An account a builder opened for you — a company whose agents act for you — is yours. The builder reads where it stands: whether you have joined, the versions of its playbooks, its own agents there and the keys it made, and, while your invitation waits, the address it sent it to. Never your customers, your people, your settings or what anybody decided, and nothing at all once you cut it off. What its people do in your account is recorded as theirs, by their id in the builder's account. Your invitation reaches you in an email from Himmel, its link yours alone: the builder never sees it.

Where it runs

Himmel is built to run in the EU, on servers in Germany. The security page says how, and lists the sub-processors.