veinito.
PLENDE
Menu
Contact

How the veinito. group handles security

ClassKasa, CzynszOK, Kasandro and this site are one group, and they connect to your bank the same way. We write only what we can show: every sentence here traces back to an app's code or to a vendor's own page.

As of

You log in at your bank, not with us

When you connect an account, you go to your own bank and log in there with your usual credentials. The connection is handled by Enable Banking Oy, a licensed account information service provider (AIS) supervised by the Finnish FIN-FSA. Neither the group's apps nor we see your bank password.

  • Read-only. The group's apps use the account information service (AIS) only: they cannot initiate a payment or change anything on your account.
  • You confirm consent in your bank. The bank sets how long it lasts, and when it runs out you renew it.
  • You can withdraw consent at any time in your bank. What exactly happens inside each app is described below.

How it works in each app

ClassKasa
Connecting the class account is a Premium feature. The treasurer turns it on, and only the treasurer can disconnect it, with one button, "Disconnect the bank". The transfer history stays; the treasurer can then delete it together with the stored consent. ClassKasa asks for 90 days of consent; the real expiry comes from the bank through Enable Banking.
CzynszOK
It is a one-off read, with no standing access to the account: we read your bank account data when a certificate is issued. We delete the raw bank data in the same operation that writes the result, before you see the result screen. For a joint certificate, the encrypted data needed for the calculation is kept for 72 hours at most, as the privacy policy describes. You can withdraw consent to the read at any time.
Kasandro
Kasandro is "Coming soon". Its site describes the same rules: read-only, login at your bank, consent you can withdraw at your bank, and one tap that deletes all your data.

The chain of trust: who we rely on

We use providers that publish how they handle security themselves. Below is what each one says about itself, with a link to the source. These are those companies' certificates and reports, not ours.

  • Enable Banking Oy, the bank connection. A registered AIS provider supervised by FIN-FSA and listed in the EBA register. It publishes its information security policy and states there that its information security management system uses the ISO/IEC 27001:2022 standard. Vendor's page ↗
  • Netlify, hosting for all the group's apps and this site. Its security page lists a SOC 2 Type 2 report and an ISO 27001 certificate. Vendor's page ↗
  • Neon, the Postgres database of the apps. Its compliance page lists SOC 2 reports (Type 1 and Type 2) and ISO 27001 and ISO 27701. Vendor's page ↗
  • Stripe, payments in ClassKasa and CzynszOK. States that it is certified to PCI Service Provider Level 1 and that SOC 1 and SOC 2 Type II reports are produced every year. Vendor's page ↗

What we do ourselves

Only what can be checked in the repositories. A scan that finds something new fails the build, and a change is merged only after a green result. Where we write "on every pull request", we mean pull requests that change code; documentation-only and content-only changes take a shortened path. Technical details that would help an attacker stay off this page.

ClassKasa Live

  • On every pull request these fail the build on new findings: static analysis (Semgrep, ERROR level), dependency scans (npm audit, critical level; OSV-Scanner), secret scanning (gitleaks, TruffleHog) and a passive scan of the running app with OWASP ZAP (Baseline).
  • API endpoints are listed in a permissions matrix (CI checks this), and tests check that one class cannot reach another class's data.
  • HTTP security headers, HSTS among them, are set in the app's configuration.

CzynszOK Beta

  • On every pull request these fail the build on new findings: static analysis (Semgrep, ERROR level), dependency scans (npm audit, critical level; OSV-Scanner), secret scanning (gitleaks, TruffleHog) and a passive ZAP (Baseline) scan of the pages reachable without signing in.
  • A threat model dated 6 October 2026 (data-flow diagram, STRIDE, LINDDUN; status "proposed") and a permissions matrix are kept in the repository.
  • HTTP security headers (CSP, HSTS, no framing) are set in the app's code.

Kasandro Coming soon

  • On every pull request these fail the build on new findings: static analysis (Semgrep, ERROR level), dependency scans (npm audit, critical level; OSV-Scanner, which runs on every change to the dependencies, on main and every week), secret scanning (gitleaks, TruffleHog) and a passive ZAP (Baseline) scan of the built site (marketing, blog and legal pages; the bank flow does not exist yet).
  • A threat model dated 10 October 2026 describes the system as designed. Its status is "proposed" because the product is not live yet.
  • HTTP security headers (CSP, HSTS, no framing) are set in the app's code.

veinito.com

  • This site is static: no database and no third-party scripts. A CI test fails the build on new findings, a third-party script included. The site runs with a strict CSP and HSTS.

In ClassKasa, CzynszOK and Kasandro, Dependabot opens grouped pull requests with dependency updates every week. Each one goes through the same CI that fails the build. In CzynszOK and Kasandro a person merges them. In ClassKasa patch updates and security-alert updates merge by themselves only after the required checks pass, and major updates always wait for a person. A weekly routine consolidates the open pull requests into one and works on it until the required checks pass.

Found a vulnerability? Write to us

The address for reports is the one in this site's security.txt: hello@veinito.com. Tell us what you found and how to reproduce it.

Each app has its own security.txt (links below). Please do not test on other people's data: steps to reproduce are plenty.

Security testing: where we stand today

A passive OWASP ZAP (Baseline) scan runs on every pull request in ClassKasa, CzynszOK and Kasandro and fails the build on new findings. The scan does not sign in, so it does not cover signed-in screens. What ZAP is and what it checks is explained in a separate article.

ClassKasa: on 29 May 2026 (version 3.27.0) the fixes from an authorized penetration-test round shipped. The owner ran it with Claude Code and the open-source pentest-ai-agents toolkit (catalogue page): 8 fixes, 3 of them High (server-side role checks, sanitising of chat content, a clamp on reconciliation amounts). The same day (3.27.1) every attack was re-run: the fixes held, and 3 further vulnerabilities of the same classes were found and closed, each with a regression test that failed first and then passed. This applies to ClassKasa only, and the full account is in a separate article.

The group holds no ISO 27001 certificate and no SOC 2 report. The certificates of the vendors listed above are theirs, not ours.

Each app's security page

Each app describes security in its own terms, because each does something different with your data.