Privacy Policy
Muntin
1. Who we are and what this policy covers
Muntin (“Muntin”, “we”, “us”) holds a register of the legal entities a customer runs, ingests each entity's payroll register for each period, maps it onto one fixed row contract using a column mapping proposed by a fine-tuned classifier and confirmed by an operator, runs a fixed set of cross-entity reconciliation checks, including identity matches proposed by an embedding model, and holds the period open until every exception has been cleared by a named person. On lock it posts a payroll journal per entity into the customer's ERP, fires headcount and cost center webhooks, and freezes an immutable period record. We do not calculate pay, we do not compute or file statutory deductions, we do not move money, and we do not issue payslips.
Registered at Muntin Systems GmbH, Katharinenstrasse 17, 04109 Leipzig, Germany.
This policy explains how we handle personal data in two distinct capacities, which are governed by different rules:
| Whose data | Our role | Governed by | |
|---|---|---|---|
| Part A | Website visitors, prospects, people who contact us | Controller — we decide why and how | This policy |
| Part B | The entity register, the payroll registers you place in Muntin, the headcount and cost center data derived from them, and the operator accounts you name | Processor — we act only on the customer’s documented instructions | This policy and the Data Processing Agreement signed with that customer |
Where the Data Processing Agreement (“DPA”) and this policy conflict in respect of Part B, the DPA governs.
Part A — When we are the controller
This part covers personal data we collect for our own purposes: running our website, responding to access requests, and communicating with prospective and existing customers.
A.1 What we collect
Information you give us. When you submit the access request form we collect your first name, last name, work email address and company name, together with the fact that you agreed to be contacted. If you email us or talk to us during evaluation or onboarding, we hold the content of that correspondence and any business contact details in it.
Information collected automatically. Our web server records the IP address the request came from, the user agent string, the pages requested, referring URL and timestamp. These logs exist to keep the site available and secure.
We do not knowingly collect special categories of personal data under Article 9 GDPR in this part, and the form should not be used to send us any.
A.2 Why we process it, and on what legal basis
| Purpose | Data | Legal basis (GDPR Art. 6) |
|---|---|---|
| Responding to an access request and evaluating fit | Form submissions, correspondence | Art. 6(1)(b) — steps at your request prior to a contract |
| Administering a customer relationship, billing, support | Contact details, correspondence | Art. 6(1)(b) — performance of a contract |
| Site availability, security, abuse prevention | Server logs | Art. 6(1)(f) — legitimate interest in operating a secure service |
| Direct outreach to business contacts about the service | Work email, company | Art. 6(1)(f) — legitimate interest in B2B marketing, subject to your right to object at any time |
| Meeting tax, accounting and legal obligations | Billing and contract records | Art. 6(1)(c) — legal obligation |
Where we rely on legitimate interest, we have assessed that interest against your rights and are able to provide the assessment on request.
A.3 How long we keep it
- Access requests that do not become customers: 12 months from last contact, then deleted.
- Customer contact and contract records: for the term of the agreement plus 6 years, to meet limitation periods and accounting obligations.
- Server logs: 30 days.
- Records of an objection or opt-out: retained indefinitely, so that we can honour it.
A.4 Your rights
If you are in the EEA or UK you have the right to access your data, correct it, have it erased, restrict or object to its processing, receive it in a portable format, and withdraw consent where consent is the basis. You may exercise any of these by writing to [email protected]. We answer within one month.
You also have the right to complain to a supervisory authority. If you are in the EEA you may complain to the authority in your country of residence or workplace; our EU representative is identified in section 5.
Part B — When we are the processor
Almost everything in this service is personal data about your employees, and none of it is ours. Salary, employer cost, deductions, dates of birth, the last four digits of a bank account and the entity a person is employed by are yours as controller, and we hold them as your processor on your written instruction. Two other things matter here and are easy to overlook. The first is that our checks are cross-entity by design, so a record from one of your entities is compared against records from another, and you should satisfy yourself, and your works council where you have one, that this is within your own lawful basis before you load anything. The second is the exceptions log: who cleared which exception, and when, is a record about your own staff as well as about the data, and it is retained because the value of a locked period is that it can be shown to have been cleared by a person.
B.1 What we process, and why it is personal data
Account data, meaning your work email, your entity, your billing contact and the operators you authorize, we hold as a controller. The entity register, every payroll register you load, the mapped rows, the exceptions and their resolutions, the journals we post and the webhook payloads we send, we process as your processor, on your instruction, for as long as the subscription runs.
- The entity register — Each registered legal entity you operate, its registration number, incorporation date, pay calendar, currency, the payroll system or bureau that runs it, and its cost center tree. This is a description of your corporate structure and we treat it as commercially confidential: it is never published, never aggregated into any coverage or benchmark statistic, and never disclosed to any payroll provider or bureau.
- The payroll register, per entity, per period — The file as you supply it and the rows we map from it: employee identifier, cost center, gross, employer cost, statutory deductions, other deductions, net, currency and pay date. We keep the source file byte for byte alongside the mapped rows, because a posted journal has to be traceable to the file it came from.
- Matching keys — To decide whether two rows in two entities are the same person we read name, date of birth, role and the last four digits of the bank account. We hold no full bank account number, no national identifier, no tax identifier, no absence reason and no health data, and we ask you not to send them. If a file arrives carrying a field we do not need, it is dropped at mapping and not stored.
- Operator accounts and the exceptions log — Who you authorize, what each of them cleared, what they changed, and when. This is the evidence that a locked period was cleared by a person rather than skipped, so it is written on every action and cannot be edited by anyone, including us.
We hold no payment instrument for your employees and we initiate no payment. The file that pays people leaves from wherever it leaves today, and nothing in Muntin is on that path.
Do not load absence reasons, medical certificates, disciplinary records or anything else that is not on a payroll register. We hold no lawful basis for them and no place to put them, and if one reaches us we delete it and tell you in writing.
Our ERP credential is a service user you issue, scoped to posting journals and reading the chart of accounts. We ask for nothing wider and we will refuse a broader scope if you offer one.
B.2 What we do with it
Everything stays in Frankfurt. Ingestion, mapping, the reconciliation checks, both models in service, the identity index, the exceptions queue and the locked period records run on AWS in Frankfurt. The column classifier is retrained on Microsoft Azure in Germany West Central, also in Frankfurt. No processing of any kind happens outside Germany.
The two model corpora are governed differently. The column corpus, which holds a header string and a statistical fingerprint of the column with no cell values, mapped to a field name, is shared across the service. The identity corpus, which holds pairs of payroll rows and a decision about whether they are one person, is employee personal data and is partitioned per customer, never pooled and never used to train anything that touches another customer's account. The column corpus is the only one used on Azure, for training the classifier; the identity corpus stays on AWS.
A locked period is never edited. Once a period locks, its mapped rows, source files, check results and clearance record are immutable. A correction is a new period version carrying a reason and an author. The superseded version stays readable and is marked as superseded, because a journal that was posted from it is in your ledger and has to remain explainable.
Your data is not compared with anyone else's. Reconciliation is cross-entity within your own group and never cross-customer. We publish no benchmark, no salary statistic and no aggregate drawn from any customer's registers, and we would have to build something we have deliberately not built in order to do so.
B.3 Models, inference and training
Where inference runs. All inference runs on EC2 GPU instances we operate on AWS in Frankfurt: the fine-tuned column classifier that proposes a mapping from a header string and a statistical fingerprint of the column, and the embedding model that proposes identity matches across entities. No third-party inference endpoint is used at any point. No payroll row, no header, no employee name, no salary figure and no entity name is sent to a hosted model API, Microsoft's included. Amazon and Microsoft appear on our subprocessor register for compute and storage; no model vendor does, because none is in the path. Nothing is processed outside Frankfurt.
Training. We do not train on your data, and the exception is narrow enough to state exactly. Two corpora accumulate from operator decisions and they are governed differently. The column corpus holds a header string plus a statistical fingerprint of that column, being magnitude, sign, currency formatting, cardinality and null rate, mapped to a field name; it holds no cell values, no names and no salary figures, and it is shared across the service. The identity corpus holds pairs of payroll rows and a decision about whether they are one person; that is employee personal data, so it is partitioned per customer, never pooled across customers, and never used to train, tune or evaluate anything that touches another customer's account. The column classifier is fine-tuned on Azure Machine Learning in Germany West Central, also Frankfurt, and the column corpus is the only corpus that leaves AWS. The identity corpus stays on AWS in Frankfurt and is used only inside its own customer's partition. Your entity register, your journals and your exceptions log are used to train nothing at all.
Human review. The model proposes and a person decides, in both places it runs. A column mapping is applied only after one of your operators confirms it, once per file shape. An identity match is applied only when the embedding score and the similarity margin both clear a fixed threshold and an operator confirms it; below the threshold nothing is guessed at, the row stays in the exceptions queue marked unresolved, and the period cannot lock while it sits there. There is no override on that lock for anyone, including us. No automated decision producing legal effects for any individual is made anywhere in this service: Muntin does not calculate pay, does not determine an entitlement, does not move money and does not file with any authority. Every figure that reaches a person's payslip was calculated elsewhere and was cleared here by a named human being.
B.4 Where the data sits
All storage and all processing sit in Frankfurt. On AWS: source files, the entity register, locked period records and the immutable log in S3, with mapped rows, the exceptions log, both models in service and the identity index. On Microsoft Azure in Germany West Central: the column corpus and classifier training snapshots in Azure Blob Storage. Nothing is held outside Frankfurt.
No inference runs on a third-party endpoint. Column classification and identity embedding are served from EC2 GPU instances we operate on AWS in Frankfurt, the column classifier is fine-tuned on Azure Machine Learning in Germany West Central, and no payroll row, header, entity name or fragment of one is sent to a hosted model API.
Journals and webhooks are delivered to endpoints you nominate. If your ERP or your webhook consumer sits outside the EU, the delivered payload travels there on your instruction; our copy and all processing stay in Frankfurt.
Support access to a customer account is granted case by case, logged in the same immutable log as everything else, and performed by our staff from within the EU.
B.5 Retention, deletion, and the limits of deletion
Source files, mapped rows, check results and locked period records: for the life of the subscription and 24 months after it ends, because a posted journal is audited long after the software is switched off. Earlier deletion on written instruction.
The entity register and cost center trees: for the life of the subscription, deleted within 30 days of its end.
The exceptions log, including who cleared what: for the life of the subscription plus 24 months, matching the period records it explains.
Identity match decisions in the per-customer corpus: deleted with the customer account, within 30 days of the end of the subscription.
The shared column corpus: retained indefinitely. It holds header strings and value-shape fingerprints and contains no cell values, no names and no salary figures.
Account and billing records: ten years after the subscription ends, as German commercial and tax record rules require.
Access and delivery logs without payloads: 90 days.
B.6 Requests from individuals whose data we process
Your employees are your data subjects, not ours. If one of them writes to us directly we will not answer on the substance; we will tell them plainly that their employer is the controller, name you, and forward the request to your nominated contact within five working days. On your written instruction we will locate, export, correct or delete a named individual's rows, and a correction after a period has locked produces a new period version rather than a silent edit, so the change is visible rather than hidden. About your own operators we hold work email, name and the exceptions log entries attributable to them; write to [email protected] and we will answer within 30 days.
Common provisions
5. International transfers
Muntin is incorporated in the United States and serves customers established in the EEA. Personal data transferred outside the EEA is protected by the European Commission’s Standard Contractual Clauses, together with a transfer impact assessment and the supplementary technical measures described in our security documentation. A copy of the clauses is available on request.
EU representative (Article 27 GDPR)
6. Security
We maintain measures appropriate to the risk, including encryption in transit and at rest, credentials scoped to the minimum necessary, access control on the principle of least privilege, isolation of each customer’s data, and audit logging of access to production systems.
We notify affected customers of a personal data breach without undue delay and, in any event, within 36 hours of becoming aware of it, with the information they need to meet their own notification duties.
7. Children
The service is sold to businesses and is not directed at children. We do not knowingly collect personal data from anyone under 16.
8. Changes to this policy
We may update this policy. Material changes are notified to customers by email at least 30 days before they take effect, and the version number and date at the top of this page are updated in every case.
9. Contact
Privacy enquiries and general: [email protected]
Postal: Muntin, Muntin Systems GmbH, Katharinenstrasse 17, 04109 Leipzig, Germany