Security & Vulnerability Disclosure

Reporting a vulnerability

If you've found a security issue in BankScan AI — a vulnerability in our web application, an exposed credential, a way to access another user's data, anything that could put our users at risk — please tell us. We treat reports seriously and we don't pursue legal action against good-faith researchers.

What to include in your report

• A clear description of the issue and where you found it (URL or endpoint).
• Steps to reproduce — ideally a minimal proof-of-concept.
• The impact (what an attacker could do with this).
• Your name or handle for credit if you'd like to be acknowledged.

What we'll do

1. Acknowledge within 2 working days. We'll confirm we've received your report and assign it a tracking reference.
2. Triage and validate within 5 working days. We'll let you know whether we can reproduce the issue and what severity we've assessed.
3. Fix according to severity. Critical issues (data exposure, RCE, authentication bypass): patched within 7 days. High: 30 days. Medium: 90 days.
4. Coordinated disclosure. We'll work with you on a disclosure timeline. By default we ask for 90 days from report to public disclosure, sooner if a fix ships earlier.
5. Acknowledge you in our security log (with your permission) once the fix is live.

Scope

In scope for this policy:

• https://bankscanai.com and any subdomain we operate.
• Our HMRC MTD ITSA integration endpoints (/api/hmrc/*).
• Data handling for uploaded bank statements, receipts, and HMRC OAuth tokens.

Out of scope:

• Findings from automated scanners (e.g. "no rate limit on the landing page", "TLS configuration warnings already at A+") without a demonstrated security impact.
• Issues in third-party services we rely on (Stripe, Anthropic, Resend, Railway, Vercel) — please report those to the relevant vendor directly.
• Social-engineering attacks against our staff or customers.
• Denial-of-service attacks against our infrastructure.

Safe harbour

If you make a good-faith effort to comply with this policy, we will:

• Not pursue or support any legal action against you in connection with your research;
• Work with you to understand and resolve the issue quickly;
• Recognise your contribution publicly (with your permission) once the issue is resolved.

Please don't access user data beyond the minimum needed to demonstrate the issue, don't degrade the service for other users, and don't publish the vulnerability until we've had a chance to fix it.

What we cover internally

Our security posture is documented for HMRC's MTD recognition review at github.com/mitchell1972/bankparse under hmrc/docs/security-questionnaire.md, hmrc/docs/data-handling.md, hmrc/docs/audit-log.md, and hmrc/docs/incident-response.md (the 72-hour HMRC + ICO notification runbook). Key controls:

• HMRC OAuth tokens encrypted at rest with AES-256-GCM, two-key rotation supported.
• All HMRC API calls write an immutable audit row (bearer tokens stripped before storage).
• Outbound rate limiting on every HMRC call to prevent runaway abuse.
• Sentry-based alerting on HMRC 5xx and network failures (5xx only — 4xx is user error, not alertable).
• CSRF protection on every state-changing endpoint.
• UK/EU data residency (Railway europe-west4).