Market Intelligence

Security & Vulnerability Disclosure

Version 1 · Effective from 2026-05-01

Current version

Summary: Initial publication.

DRAFT — for demo and vendor-risk-review purposes only. This document has not yet been reviewed by counsel. Final wording will be substituted before pilot launch. Do not rely on this draft for any binding commercial decision.

Security & Vulnerability Disclosure Policy

Effective from 1 May 2026 — Version 1

We take the security of the Market Intelligence platform seriously. If you have discovered a vulnerability or a security weakness in our service, we want to hear from you and we will work with you in good faith to fix it. This Policy describes the rules of engagement under which security researchers can report findings and receive a clear, predictable response from us — including a written commitment that we will not pursue legal action against researchers acting in good faith within these rules.

The Policy is intended to align with ISO/IEC 29147:2018 (Vulnerability Disclosure) and ISO/IEC 30111:2019 (Vulnerability Handling Processes). The single source of truth for the contact and machine-readable metadata is the `security.txt` file at our well-known path, in line with RFC 9116.

1. Scope

This Policy applies to vulnerabilities discovered in:

  • The Market Intelligence platform at `platform.fintum-mi.com`, including its API and any subdomain we operate under `*.fintum-mi.com` that is part of the platform
  • The supporting infrastructure we directly control (DNS, edge configuration, build pipeline)
  • The mobile or desktop clients we publish, if any (none currently in scope)

It does not apply to:

  • Third-party services we integrate with (their own VDPs apply)
  • Customer-side integrations or customer-built applications that use our API — those belong to the customer
  • The marketing site at `www.fintum-mi.com` unless the issue affects authentication, account provisioning, or otherwise crosses into the platform surface
  • The el-fondo consumer application or its infrastructure — that product has its own disclosure programme

2. Safe harbor

If you act in good faith, follow this Policy, and avoid the explicit out-of-scope behaviours listed in §3, we will not pursue legal action against you under §§ 202a, 202b, or 202c of the German Criminal Code (StGB), under §§ 303a or 303b StGB, under the German Civil Code, or under any contract we hold with you, arising from your security research conducted within this Policy. We treat your report as a confidential disclosure under ISO/IEC 29147 and we will not refer your activity to law enforcement, to your employer, or to any third party without your written consent unless we are compelled to do so by lawful court order — in which case we will give you advance notice where the order does not prohibit it.

This safe harbor is a unilateral declaration we make to you. It is binding on us; you do not need to sign anything to benefit from it.

The safe harbor does not extend to:

  • Acts that go beyond what is strictly necessary to demonstrate the existence and impact of the vulnerability
  • Acts that violate the rights of any third party, including our other customers
  • Acts that are independently unlawful even outside the StGB sections listed above

If you are unsure whether a planned activity falls within this Policy, write to security (at) fintum-mi.com before you act and we will give you a written answer within five business days.

3. Rules of engagement

You are welcome to perform good-faith security research within the Scope above, subject to the following rules.

Do

  • Report your finding to us through the channel in §4
  • Stop testing and report immediately if you obtain access to data that does not belong to you
  • Treat any data you incidentally encounter as confidential, do not download it beyond what is strictly necessary to demonstrate the issue, and securely delete it as soon as the demonstration is complete
  • Limit testing to the smallest scope and lowest privilege that still demonstrates the impact
  • Wait until we have either remediated the issue or agreed a public-disclosure date before disclosing any details to third parties

Do not

  • Run denial-of-service or volumetric attacks of any kind
  • Run automated scanners that generate significant traffic without prior agreement on scope and scheduling — credential-stuffing, fuzzing of authenticated endpoints, or large-scale enumeration count as "significant" here
  • Conduct social engineering or phishing of our personnel, contractors, customers, or end users
  • Test against production data when a reproduction in your own test account is possible — create a free trial or contact us first if you need a sandbox
  • Exfiltrate any data beyond the minimum necessary for the demonstration. Read it on the wire; do not save it to a third-party service; do not retain it after the report is filed
  • Use physical access vectors (tailgating, lockpicking, dropping USB sticks)
  • Modify, deface, or delete any data
  • Persist access — install no backdoors, no implants, no credentials
  • Test the third-party services we integrate with (AWS, Resend, etc.) — those have their own VDPs and must be reported there

If your testing accidentally crosses one of these lines (a scanner that escalated, a payload that produced more impact than expected), stop immediately and tell us in your report — we treat self-reported overruns very differently from undisclosed ones.

4. How to report

Send your report to security (at) fintum-mi.com. The same address is the `Contact:` field of our `security.txt`. For sensitive reports we encourage encryption — our PGP key is available at [[FILL: PGP key URL]] (fingerprint: [[FILL: PGP fingerprint]]).

A useful report includes:

  • A description of the issue with the affected endpoint, page, or component
  • Reproduction steps that allow us to reproduce the issue independently
  • An impact assessment in your words — what an attacker could achieve
  • Optional: a suggested remediation if you have one in mind
  • Your preferred contact method and any constraints on attribution or coordinated-disclosure timing

Reports in English or German are equally welcome.

5. What you can expect from us

When we receive your report:

  • Acknowledgment within two business days of the email arriving
  • Triage with a working severity assessment and a working repro within five business days
  • Status updates at least every two weeks while the issue is open, more often for higher-severity issues
  • Remediation scheduled according to severity:
  • Critical (active exploitation possible, data exposed) — fix released as fast as engineering and validation allow, target within 7 calendar days
  • High (no active exploitation but high impact) — target within 30 calendar days
  • Medium — target within 90 calendar days
  • Low — at the next regular release cadence; we will tell you the rough date
  • Closure notice when the fix is in production, including a brief description of what we changed and any user-facing release-note language we plan to publish
  • Coordinated disclosure — if you would like to publish your finding, we ask for at least 30 days from acknowledgment before disclosure, longer for critical issues that require customer-side action. We will coordinate the wording with you in good faith.

If we believe your report is out of scope or not a vulnerability, we will tell you why with enough detail for you to disagree if you want to.

6. Acknowledgments

We maintain a list of researchers who have reported valid vulnerabilities to us, with their permission. Adding you to the list is opt-in and we will ask before naming you. The list is published at the bottom of this page once we have entries to publish.

We do not currently operate a paid bug bounty programme, but we may introduce one in the future. If we do, we will publish the scope, the reward schedule, and any participation rules at this URL or at a clearly-linked successor.

7. Out-of-scope reports

The following classes of report are unlikely to receive a remediation but we appreciate the heads-up and will respond:

  • Missing security headers (CSP, HSTS, etc.) on pages that do not handle sensitive data, where we have already evaluated and accepted the risk
  • Theoretical attacks without a working exploit
  • Vulnerabilities in third-party dependencies that we are already tracking and that have a publicly known patch we have not yet shipped — please reference the CVE and we will tell you our planned ship date
  • "Best-practice" findings without an exploit (e.g. "you should use a different cipher even though TLS 1.2 with the chosen suite is still acceptable")
  • Issues that require physical access, root on the user's device, or a compromised browser

8. Updates to this Policy

We update this Policy from time to time. Each version stays at its permanent URL (this version is `/legal/security/v1`); when we publish a new version we increment the URL path and update the `Policy:` field of `security.txt` accordingly.

9. Contact

Vulnerability reports: security (at) fintum-mi.com General security questions: same address. Privacy and data-protection requests: privacy (at) fintum-mi.com Legal correspondence: legal (at) fintum-mi.com

Information required by § 5 TMG and § 18 (2) MStV is published at https://www.fintum-mi.com/imprint.