Mittkurs

Privacy Policy

Mittkurs Oy

Last updated: 5 January 2026 · Version 1.0

1. Who we are and what this policy covers

Mittkurs Oy (“Mittkurs”, “we”, “us”) runs a web app where a company holds prepaid balances in EUR, SEK, USD, NOK, DKK and GBP, issues virtual and physical Visa cards to its employees and its subscriptions, and turns the card charges and their receipts into a monthly journal for its accounting system. Cards are issued through an e-money institution licensed in Finland, and company balances are kept in segregated accounts under the e-money rules. A model reads receipts and invoices and suggests account codes, and nothing is posted until the company confirms its close. We give no credit, we don’t handle supplier invoices, and we don’t process mileage, per diems or out-of-pocket claims.

Registered at Lönnrotinkatu 5, 00120 Helsinki, Finland.

We handle personal data in two different situations, and different rules apply to each:

Whose dataOur roleWhat applies
Part APeople who visit this website, ask about the service or write to usController: we decide why and how the data is usedThis policy
Part BThe company account: legal name, business ID, registered address, the identity and ownership documents the e-money rules require from the signatories, and the bank accounts top-ups come from. The cardholders: name, work email, phone number for card verification, their cards and limits. The transactions: every authorization, settlement, decline, top-up and conversion, with merchant, amount, currency, rate and time. The documents: every receipt and invoice forwarded, uploaded or photographed, the fields read from them, the confirmed values, the suggested and confirmed account codes, and the line-and-code pairs that come from confirmations. The exports: every journal built, where it went and its status. And the payment and identity data the card issuer and the card network require, held under their rules as well as ours.Set out in B.1, because it depends on the dataThis policy and the data processing agreement we sign with each customer

If the data processing agreement (“DPA”) and this policy ever disagree about Part B, the DPA wins.

2. Part A: this website and our contact with you

This part covers the personal data we collect for our own purposes: running this website, answering requests, and staying in touch with people who are or might become customers.

A.1 What we collect

What you give us. When you send the form on this site, we collect what you type into it, such as your name, email address, phone number or company, and the fact that you agreed to be contacted. If you email or talk to us, we keep that correspondence and any contact details in it.

What is collected automatically. Our web server records the IP address a request came from, the browser used, the pages requested, the page you came from and the time. These logs exist to keep the site running and secure.

We don’t ask for sensitive data (the “special categories” in Article 9 GDPR) through this website, so please don’t send any through the form.

A.2 Why we use it, and what allows us to

WhyWhatLegal basis (GDPR Art. 6)
Answering your request and working out whether the service fitsWhat you sent in the form, our correspondenceArt. 6(1)(b): steps you asked for before a contract
Looking after customers, billing and supportContact details, correspondenceArt. 6(1)(b): carrying out a contract
Keeping the site running, secure and free of abuseServer logsArt. 6(1)(f): our legitimate interest in running a secure service
Contacting you about the serviceEmail address, companyArt. 6(1)(f): our legitimate interest in business-to-business marketing. You can object at any time
Meeting tax, accounting and legal dutiesBilling and contract recordsArt. 6(1)(c): a legal obligation

Where we rely on legitimate interest, we have weighed that interest against your rights, and you can ask to see the assessment.

A.3 How long we keep it

A.4 Your rights

If you are in the EEA or the UK, you can ask to see your data, correct it, have it deleted, limit or object to how we use it, get a copy you can take elsewhere, and withdraw consent where we rely on it. Write to [email protected] and we will answer within one month.

You can also complain to a data protection authority. If you are in the EEA, that can be the authority where you live or work.

3. Part B: data inside the service

Two kinds of people appear in our data, and they stand in different positions. The first is the company, our customer, which opens the account, holds the balances and confirms the close. Its finance lead acts for it. The second is the cardholder, an employee of that company, whose name is on a card and whose taxi receipt is in the record. The company gave us that person’s data so we could issue a card and the app could code that person’s charges for its close. This part covers both, in that order, and ends with a cardholder’s rights.

B.1 What we handle, and in what role

For the company account, the balances, the cards and the transactions, we are a controller together with the e-money institution that issues the cards, each for the duties the law puts on it. The institution and the card network are named on our subprocessor list. For cardholder data, receipts and the journal, we are the company’s processor and act on its instruction. The company decides what is coded where, what is exported and when a cardholder’s data is deleted, and our data processing agreement sets out the terms. For the line-and-code pairs, stripped as described below, we are the controller.

We never hold a company’s bank login. A top-up is a transfer the company sends from its own bank to the account number shown in the app.

The e-money institution and the card network see transaction data under their own duties. Neither sees a receipt, a suggested account code or a journal.

A personal card, like the one the founder used for subscriptions before, is not connected to anything here, and we never ask for it.

B.2 What we do with it

Everything runs in Stockholm. The ledger, balances, cards, documents, journals and accounting connections run on cloud infrastructure in Stockholm, Sweden. The three models and their fine-tuning run on cloud GPU capacity we control in Stockholm. No document and no transaction leaves Sweden for processing. The card network itself carries each authorization to wherever the merchant is, under the network’s rules.

No hosted model provider. No receipt, invoice, transaction or journal line is sent to a third-party model API. The models are ours and run on capacity we control. The third parties involved are the cloud provider named on our subprocessor list, whose infrastructure in Stockholm the service runs on, the e-money institution, the card network, and the accounting system the company chose to connect.

The model suggests, the company posts. A value read with confidence below 0.85 is left blank and typed by a person. A suggested account code takes effect only when the finance lead accepts it, changes it or writes a rule for that merchant. No journal is posted anywhere until the company confirms its close, and the model never declines, freezes or reissues a card.

Currency follows a rule, not a model. If the company holds a balance in the currency of a charge, the charge is paid from it. If not, it is converted from the EUR balance at the reference rate plus the published margin. A conversion between balances happens only when someone at the company orders it and confirms the quoted rate.

Confirmed lines are stripped before we keep them. When a person confirms a value the model read or a code it suggested, we keep the merchant name and a crop of that one document line, together with the confirmed code. The company name, the card number, the cardholder’s name and everything outside the line are removed. These pairs are used only to fine-tune our own models. They are never given to anyone else, and they are deleted with the company’s record on request.

B.3 AI models: where they run and what they learn from

Where models run. All models run on cloud GPU capacity we control in Stockholm, Sweden. One finds the fields on a receipt or invoice. One reads merchant, date, net, VAT, currency and total, with a confidence score. A classifier suggests an account code from the merchant name, the document and the company’s own coding history. No receipt, invoice, transaction or journal line is sent to a third-party model API, and there is no hosted model provider on our subprocessor list. The models are fine-tuned on the same capacity in Stockholm. From Q1 2027 the reader is one fine-tuned open-weight vision-language model, self-hosted on that capacity. From Q2 2027 embedding search, on the same capacity, gives each new document the code of the nearest merchant among that company's own confirmed lines. From Q3 2027 the month-end bursts run on GPU capacity reserved in advance in Stockholm.

Training. We don’t train any model on a company’s ledger, documents, journals or cardholders, and no third party receives them to train on. There is one narrow exception. When a person confirms a value the model read or a code it suggested, we keep the merchant name and a crop of that single document line, together with the confirmed code. The company name, the card number, the cardholder’s name and everything outside the line are removed. Those pairs are used only to fine-tune our own models. They are pooled across companies, because a vendor’s invoice layout is not personal to anyone. They hold no totals, no balance and no identity, and they are deleted with the company’s record on request.

Where a person decides. The model suggests and a person decides, twice. A value read with confidence below 0.85 is left blank for the person closing the month to type. A value above it is shown and used only once confirmed. A suggested account code takes effect only when the finance lead accepts it, changes it or writes a rule for that merchant, and no journal is posted anywhere until the company confirms its close. Card issuing, limits, declines and currency handling follow rules the company sets and a person can read. They are not model decisions. This service takes no decision with a legal or similarly significant effect on any person, and no cardholder is assessed, scored or declined by a model.

B.4 Where the data is kept

All processing and storage is on cloud infrastructure in Stockholm, Sweden. The models and their fine-tuning run on cloud GPU capacity we control in Stockholm.

No receipt, invoice, transaction or journal line is sent to any hosted model API. No outside company runs a model on any of it.

Card authorizations travel over the card network between the merchant’s bank and the issuer, wherever the merchant is, under the network’s rules. The e-money institution keeps its own records under its license in Finland.

The suppliers that handle data in the service are named on our subprocessor list, which comes with the data processing agreement and which we send to anyone who asks: write to [email protected].

B.5 How long we keep it, and what deleting can’t remove

The ledger, transactions, top-ups and conversions: seven years from the end of the financial year they fall in, because the company’s accounting law and ours require it. The company can export them at any time in that period.

Receipts and invoices, with their confirmed values and codes: for the period the company sets, seven years by default to match the bookkeeping rule. A company that shortens it remains responsible for its own legal retention duty.

Company account, signatory identity and ownership documents: while the account is open and five years after it closes, as the anti-money-laundering rules require.

Cardholder name, email and phone: until the company removes the cardholder, then deleted within thirty days. That person’s charges stay in the ledger under the card’s last four digits.

Line-and-code pairs: until the company’s record is deleted, and deleted with it on request.

Accounting connection access: until the company disconnects the system or closes the account, then deleted within twenty-four hours.

B.6 Requests from people whose data is in the service

A company can read, export, correct and delete its record from the account settings at any time without asking us, within the limits the bookkeeping and anti-money-laundering rules put on deletion. If the settings can’t do what you need, we answer within thirty days. A cardholder’s request for access, correction, deletion, objection or a portable copy goes to the company that issued the card, and we act on the company’s instruction within ten working days. A cardholder who writes to us directly is told which company holds their data, and how to reach it, within five working days. Closing the account returns every balance to the bank account the top-ups came from within five working days, and leaves only the records those two laws require us to keep.

For everyone

4. Moving data between countries

Mittkurs Oy is a company in Finland, inside the EEA. Section B.4 says where the data in the service is kept. If any personal data we control ever has to leave the EEA, for example because a supplier named on our subprocessor list handles it elsewhere, it is protected by the European Commission’s Standard Contractual Clauses or another safeguard the GDPR accepts. You can ask us for a copy.

5. Security

We protect data in line with the risk. That includes encryption in transit and at rest, access limited to the people and systems that need it, each customer’s data kept separate from every other’s, and a log of every access to production systems.

If a personal data breach affects you, we tell you without undue delay, and at the latest within 36 hours of finding out, with the information you need to meet your own reporting duties.

6. Children

The service is sold to businesses and is not meant for children. We don’t knowingly collect personal data from anyone under 16.

7. Changes to this policy

We may update this policy. If a change matters, we email customers at least 30 days before it takes effect. The version number and date at the top of this page change every time.

8. Contact

Privacy questions and anything else: [email protected]
By post: Mittkurs Oy, Lönnrotinkatu 5, 00120 Helsinki, Finland

← Back

Your request has been received.

Expect a message from Mittkurs. It goes to the address you gave.