Vulnerability Disclosure Policy

Effective September 9, 2026 | Version 1.0

Digits Financial, Inc. (“Digits,” “we,” or “us”) welcomes good-faith reports from security researchers. This Policy explains which systems may be tested, how to test them safely, and how to report a potential vulnerability. Digits does not currently offer a paid bug bounty.

1. Safe Harbor

If you make a good-faith effort to follow this Policy, Digits will treat your research as authorized under the Computer Fraud and Abuse Act, comparable state computer-crime laws, and the anti-circumvention provisions of the Digital Millennium Copyright Act. We will not pursue or support legal action against you for that research and will waive claims under our Terms of Service to the extent they arise from activity permitted by this Policy.

This safe harbor does not cover unlawful conduct, bad-faith activity, or testing outside this Policy. We cannot authorize testing of third-party systems, accounts, or data, and third parties are not bound by this Policy. If you are unsure whether proposed testing is permitted, contact security@digits.com before proceeding.

2. Scope

This Policy applies to the following assets, but only to the extent they are owned, operated, or controlled by Digits:

  • digits.com and Digits-controlled subdomains;
  • the Digits platform, including Digits’ web and mobile applications;
  • Digits’ public APIs and Digits-controlled integration endpoints; and
  • authentication, authorization, account-recovery, permissions, and customer-organization separation for those assets.

A third-party platform, cloud service, financial institution, customer environment, or integration is not in scope merely because it is linked to or used by Digits. Vulnerabilities in Digits-controlled code or configurations remain in scope, but do not test the third party’s infrastructure without its separate authorization.

3. Research Guidelines

When conducting research:

  • Use only accounts you own or test accounts you create, and use synthetic data whenever possible.
  • Use the least-invasive method available and stop once you have confirmed the vulnerability.
  • Keep automated testing low-volume, targeted, and non-disruptive, and independently verify scanner or AI-tool output.
  • If you encounter data that is not yours, stop immediately, do not copy or retain it, and report the exposure with sensitive details redacted.
  • Protect all information obtained through your research and securely delete it when it is no longer needed for reporting.

The following activities are not authorized:

  • Denial-of-service, load, stress, resource-exhaustion, or rate-limit testing;
  • credential stuffing, password spraying, brute force, account-lockout testing, or use of credentials or tokens not issued to you;
  • social engineering, phishing, impersonation, physical intrusion, malware, spam, mass account creation, persistence, privilege escalation beyond a minimal proof, or lateral movement;
  • accessing, changing, downloading, transmitting, or retaining another person’s data beyond the minimum observation needed to report the issue;
  • creating or altering real accounting records, payments, transfers, invoices, payroll, tax items, bank connections, or other financial workflows;
  • testing third-party systems or contacting affected customers, users, vendors, or financial institutions; or
  • demanding payment or another benefit in exchange for withholding or disclosing a finding.

4. Reporting a Vulnerability

Submit reports through the Digits Vulnerability Disclosure Program web form.

Do not include unredacted customer data, credentials, authentication tokens, malware, destructive code, or weaponized payloads in the form. If sensitive supporting material is necessary, use the encryption instructions as outlined at digits.com/.well-known/security.txt and include in your form submission for a secure transfer method.

A useful report includes:

  • the affected product, URL, endpoint, feature, or application version;
  • a clear description of the issue, its security impact, and a realistic attack scenario;
  • concise, reproducible steps and a safe proof of concept;
  • relevant screenshots, logs, requests, or responses, with sensitive information redacted; and
  • whether you encountered or affected any real data, accounts, or services.

When submitting a report, you will also be asked to attest that you acted in good faith and within the published scope, minimized any access to or impact on data, independently verified the issue rather than relying solely on automated or AI-generated output, and agree to our coordinated disclosure requirements.

Submit one vulnerability per report unless multiple issues are needed to demonstrate a single attack chain.

5. Reports We May Close as Informational

We may close a report that is out of scope, not reproducible, duplicative, or lacks meaningful security impact. Examples include:

  • raw or unverified scanner or AI-tool output;
  • missing security headers, cookie attributes, email-authentication records, weak or outdated TLS configurations, or other hardening recommendations without a working exploit;
  • self-XSS, low-impact clickjacking or CSRF, open redirects, enumeration, or verbose errors without material impact;
  • AI-output quality issues, including hallucinations or prompt injection, that do not produce unauthorized access, cross-customer exposure, an authorization bypass, or an unauthorized action; and
  • product feedback, fraud or account-support requests, privacy requests, or vulnerabilities solely in a third-party product.

6. What You Can Expect

We will make reasonable efforts to acknowledge your report, investigate it, request additional information when needed, and keep you informed of material progress. We prioritize issues based on severity, exploitability, affected systems and users, and risk to customer data, credentials, organization separation, or financial workflows. Remediation timing will depend on the nature and complexity of the issue.

7. Coordinated Disclosure and Recognition

Do not publicly disclose a vulnerability, exploit details, proof-of-concept code, screenshots, data, or related information until Digits has remediated the issue or otherwise agrees in writing. Any public disclosure must not include personal information, financial information, credentials, customer data, or other sensitive material.

At your request, we may recognize you for a valid report when appropriate. We will not identify you publicly without your permission. No payment, reimbursement, employment, or other compensation is offered or owed for reports submitted under this Policy.

8. Questions and Policy Updates

Questions about this Policy or whether an asset is in scope may be sent to security@digits.com. Submit vulnerability reports through the web form, not by email.

Digits may update this Policy from time to time. Review the version posted on our website before beginning new research. Good-faith research conducted under the version in effect when the research began will remain covered by that version’s safe harbor.