BankLint

Security at BankLint

BankLint is an early, founder-led product in a controlled beta. This page describes how it works today, including its limits. Last reviewed 2026-10-18.

BankLint does not hold SOC 2, ISO 27001 or any bank certification, and does not claim to.

Payment files

  • Uploaded payment files are processed in memory by a private validation service and are not stored by BankLint: not in the database, not in logs and not in file storage. The file name never leaves your browser.
  • What BankLint keeps for signed-in validations is sanitized evidence: findings (rule, location, explanation), semantic facts used for regression comparison, and provenance (rule and schema versions, a SHA-256 of the input). To validate again, you upload the file again.
  • Raw payment files are never sent to the AI provider, never included in email and never used for analytics.

Deterministic decisions, AI explanations

  • PASS / REVIEW / FAIL, findings and regression results are decided by BankLint’s versioned, deterministic rules (ISO 20022 schema checks and SEPA Credit Transfer rules). AI never decides an outcome.
  • “Ask BankLint” is optional and off unless enabled for a workspace. When used, the AI provider (Anthropic) receives only sanitized evidence that BankLint selects and checks (for example finding titles, rule identifiers and statuses) plus your question with account-like identifiers removed. Answers are verified against BankLint’s evidence before they are shown, and AI cannot change results or execute actions.
  • Anthropic’s default API data handling applies: inputs and outputs may be retained for up to 30 days and are not used for model training by default. BankLint has no zero-data-retention agreement.

Access and tenant isolation

  • Sign-in is with Google only. BankLint sessions are encrypted, HttpOnly, Secure cookies.
  • Each customer’s data lives in its own Workspace. Every database query runs with the signed-in user’s context under PostgreSQL row-level security, and every action is authorized by one permission resolver (default deny) shared by the UI, the API and AI tools.
  • Workspace roles (Viewer, Operator, Approver, Auditor, Administrator) can be limited to individual Companies.
  • Security-relevant actions (sign-in, permission denials, configuration changes, baseline promotion, billing changes) are written to an append-only audit trail.

Infrastructure

  • Application and validation services: DigitalOcean App Platform, Amsterdam (EU). The validation service has no public route; each validation runs in a separate worker process with outbound network access disabled at the application level.
  • Database and authentication: Supabase, AWS us-east-1 (United States). BankLint’s data sits in a dedicated schema with its own restricted database roles.
  • BankLint does not claim EU-only hosting: the database is in the United States and the AI provider may process data in several regions.
  • All traffic uses HTTPS (TLS) with HSTS, a strict content security policy and CSRF protection.
  • Abuse protection: shared rate limits on anonymous validation, sign-in, invitations, billing and AI. Rate-limit keys are keyed hashes of an IP prefix that change daily; raw IP addresses are not stored.

Engineering practices

  • Secret scanning (gitleaks) on every commit and on the full history in CI.
  • Dependency vulnerability audits for JavaScript and Python in CI.
  • Automated tests for tenant isolation, authorization, raw-file non-persistence, log leakage, and AI evidence verification.
  • Secrets are held as encrypted platform environment variables, never in source code.

Known limitations (controlled beta)

  • The database runs in a Supabase project shared with other applications of the same owner.
  • Database backups and recovery follow the Supabase project plan; BankLint has no separate backup.
  • The validation service runs on a managed platform that does not let BankLint disable swap or core dumps at the container level.

Contact

Report a security issue (subject “Security”) or ask for support at [email protected]. Please never send payment files or confidential payment data by email; the reference id shown in an error message is enough.

See also the Privacy notice.