Security at CzynszOK
What happens with the data from your bank, who else touches it, what we do in code and how to report a hole. We write only what we can prove.
The bank connection
One check is one read, read-only. One rule: read, compute, delete.
Your password
You log in with your bank, not with us. We never see or store your login or password.
Who fetches the data
Enable Banking Oy fetches the data from your bank. It is a registered account information service provider (AISP), regulated by the Finnish FIN-FSA and listed in the EBA register.
Which data
The account holder, and the incoming payments and transfers of up to the last 12 months. Read-only: we cannot order or move anything. For the deposit check we read the account balances too.
For how long
The read is one-off. We close the access at the provider right after the read, and the consent at your bank expires on its own anyway, after about 72 hours at the latest.
How to take it back
In the app: “Remove” next to a connected bank closes the access to that bank, and in “Account and data” the button “Delete account and all data” erases everything at once. At your bank: you can close the consent for an outside provider in online banking, if your bank shows it there. Cannot log in? Write to pomoc@czynszok.pl.
Who else touches the data
We use a few companies. For each one we write what it publishes about its own security and link its page. These are those companies’ certificates and audits, not ours.
Enable Banking Oy · reads your bank
Its site says it is a registered account information service provider (AISP) regulated by the Finnish FIN-FSA. It lists no security certifications there, so we attribute none to it.
Neon · database
States annual SOC 2 Type II audits and audits against ISO/IEC 27001 and 27701.
Stripe · payments
States PCI Service Provider Level 1 certification and annual SOC 1 and SOC 2 Type II reports. You enter card details in Stripe’s window, not with us.
We checked these companies’ pages on 13 Oct 2026. CzynszOK holds no ISO 27001 or SOC 2 certificate of its own and we do not claim otherwise.
What we do in code
- We delete the raw bank data (transactions, balances, amounts, account numbers) in the same operation that saves the result, before you see the result screen.
- What we compute from your income (such as the maximum rent) and the access to the session at the provider are stored encrypted in the database with AES-256-GCM. The maximum rent disappears after 24 hours.
- There are no passwords. You log in with a one-time code from an email, and five wrong attempts void the code.
- Every API route has a written access rule, and checks in CI make sure a new route cannot skip it.
- Rate limits protect login, certificate code checks and the start of a check from floods.
- The pages send security headers, including Content-Security-Policy and a ban on embedding in frames.
- You can revoke a certificate yourself, and the verification page shows its state live.
Report a security hole
Found a bug that could put someone’s data at risk? Write to pomoc@czynszok.pl: what you see and how to reproduce it. Please do not go into other people’s data. The same address is in our security.txt file.
Security testing
Only what happens today and can be checked in our repository:
- On every code change: type checks, lint and checks that guard, among other things, the access rules of routes, no personal data in logs and the boundaries between code layers.
- On every code change: unit tests and end-to-end tests in a browser.
- On every code change: a dependency scan (npm audit, critical level) and a secrets scan of the repository (gitleaks). Both fail the check when they find something.
- A threat model (STRIDE and LINDDUN) from 6 October 2026, which every new feature goes back to.
- On every code change: static code analysis (Semgrep). A finding at ERROR level fails the check.
- On every code change: an OWASP ZAP (baseline) scan of the running app, on its public pages. New findings block the build; the report of each run is kept.
- On every pull request: a scan of the whole repository history for live, verified secrets (TruffleHog). It fails the check when it finds one.
- On every pull request and every week: a dependency scan with OSV-Scanner. A new known vulnerability blocks the build.
- Every week Dependabot opens grouped pull requests with the dependency updates it found (dependabot.yml); a weekly routine consolidates all open ones into a single pull request and works on it until every blocking check passes; a human merges it.
How these checks work and what the first run turned up: our checks post
Part of the veinito. group
CzynszOK belongs to the veinito. group: ClassKasa, CzynszOK, Kasandro and veinito.com. CzynszOK has its own code and its own database.