Responsible Disclosure Policy

1. Introduction 
   
   1. Stitch is committed to maintaining the highest standards of security and protecting the data entrusted to us. We welcome responsible security research that helps us identify weaknesses, provided it is done safely, privately and in line with this policy.
   2. This policy outlines how to report potential vulnerabilities and the rules for conducting security testing against Stitch’s systems. 
   3. If you believe you’ve discovered a potential security vulnerability within any Stitch’s system, we encourage you to let us know right away. We will work with you to address the issue promptly and responsibly.
2. Purpose
   
   The purpose of this policy is to:
   
   1. provide a safe and authorised channel for reporting potential security vulnerabilities; 
      
   2. set clear expectations and boundaries for researchers; 
   3. protect Stitch, our customers and the broader financial ecosystem from harm; and 
   4. ensure all testing is conducted safely and non-destructively.

3. Scope
   
   1. This policy applies only to testing that is non-destructive, non-intrusive and strictly within the permitted in-scope areas listed below.
   2. This policy applies to:
      
      1. Stitch’s public-facing applications, application programming interfaces (“APIs”), software development kit (“SDKs”) and developer documentation;
         
      2. Stitch’s dashboards, authentication systems and management interfaces;
      3. Stitch-owned domains and subdomains; and
      4. Stitch-managed infrastructure or systems that process customer or financial data.

3. If a researcher believes a vulnerability may require intrusive, destructive or high-risk testing to confirm, they must stop immediately and submit the information they have already gathered. Stitch will then either:
   
   1. provide written, explicit permission for additional testing with strict rules; or
   2. perform the intrusive testing internally.
4. Researchers must not attempt to escalate the attack or validate a destructive vector themselves.

4. How to Report a Vulnerability
   
   1. All submissions must be sent to: security@stitch.money. 
   2. Please do not contact individual employees, executives, LinkedIn profiles or personal email addresses. This causes unnecessary disruption and will not accelerate the process.
   3. Your report must include:
      
      1. a clear description of the suspected vulnerability;
      2. steps taken to identify or demonstrate it (required for reproducibility);
      3. safe, non-destructive proof-of-concept (screenshots, URLs, sanitised logs, example payloads); 
      4. the impact as you understand it (why it matters); 
      5. the environment tested (your own account only, where applicable); and
      6. any suggestions for remediation (optional). 
   4. Incomplete submissions that do not include reproduction steps may be rejected.
   5. Stitch will acknowledge your submission at our earliest convenience, but we cannot commit to a strict timeline for response.
   6. Stitch will not provide follow-up updates on fix status. Once we acknowledge and thank you for the submission, that concludes the interaction.
5. Safe Harbour & Legal Position
   
   1. We support good-faith security research aligned with this policy.
   2. If you follow this policy:
      
      1. we will not pursue legal action for your testing; 
      2. we will not pursue law enforcement investigations; 
      3. your testing will be considered "research" that benefits security improvements at Stitch; and 
      4. your actions will be considered authorised for the purposes of cybersecurity and anti-hacking laws.
   3. However, if you do not follow this policy, especially if your actions:
      
      1. risk sensitive, customer, financial or employee data;
      2. impact financial systems;
      3. cause downtime or harm; or
      4. involve prohibited or destructive methods,

Stitch reserves the right to take legal action, including in cases having an operational, reputational or financial impact.

6. No Bug Bounty / No Rewards
   
   1. Stitch does not operate a bug bounty program.
   2. We do not provide monetary rewards, gifts, incentives or compensation of any kind.
   3. Researchers insisting on rewards or attempting to pressure Stitch into payment will not be engaged.
   4. We may, in the future, provide Certificates of Appreciation, for compliant, high-quality reports.
7. Responsible Researcher Expectations
   
   1. Required Conduct: 
      
      Researchers must:
      
      1. perform testing only within the scope of this policy; 
      2. perform testing only on systems owned and operated by Stitch
      3. use only their own accounts for testing; 
      4. ensure testing is non-destructive and non-intrusive; 
      5. immediately stop and report if a finding appears to require destructive testing; 
      6. provide full, accurate reproduction steps; and 
      7. keep all information strictly confidential.
   2. Prohibited Conduct: 
      
      Researchers must not:
      
      1. publish or share vulnerability details anywhere (including on social media, forums or blogs) regardless of whether Stitch fixes the issue; 
      2. access, modify or exfiltrate sensitive, customer, financial or employee data; 
      3. move, alter or steal funds; 
      4. contact individual employees or executives directly; 
      5. run destructive, intrusive or harmful tests; or
      6. insist on rewards or compensation, 
   3. Violations may result in legal action.

8. In-Scope Research Areas (Permitted Non-Destructive Testing Only)
   
   Researchers may submit non-destructive proof-of-concept testing limited to the following:
   
   1. Domains
      
      1. *.stitch.money; and
      2. other Stitch-owned domains (a formal list can be provided on request),
   2. Core Web Applications & APIs
      
      1. public-facing web services; 
      2. REST APIs and GraphQL endpoints; and
      3. public developer documentation services,
   3. Authentication & Authorisation
      
      1. login, signup, multi-factor authentication (“MFA”), password reset; 
      2. Open Authorisation / OpenID or OpenID Connect flows; 
      3. session and identity management; and 
      4. testing using your own account only, 
   4. Privilege Escalation & Business Logic
      
      1. unauthorised access to features within your own account;
      2. workflow bypasses; and
      3. improper enforcement of roles or permissions,
   5. Server- and Client-side Vulnerabilities, including but not limited to:
      
      1. OWASP Top 10 issues (CSRF, IDOR, SSRF, SQLi, XSS, etc.); 
      2. security misconfigurations; and 
      3. broken access controls,
   6. Public-facing Infrastructure
      
      1. public APIs;
      2. web servers;
      3. public domain name system (“DNS”);
      4. cloud storage buckets; and
      5. admin portals only if intended for your own account, 
   7. Network Discovery
      
      1. basic TCP port scanning only; and
      2. no high-volume, aggressive or intrusive scanning,
   8. Customer Communication Channels
      
      1. email, SMS templates or communication workflows; and 
      2. non-intrusive tests only, 

9. Out-of-Scope (Strictly Prohibited) Activities
   
   The following activities are strictly prohibited:
   
   1. User & Data Security:
      
      1. accessing or exploiting real user accounts or data; 
      2. downloading, exfiltrating, modifying or publishing personal or financial data; or
      3. attempting account takeover of any user other than yourself,
   2. Financial Systems & Funds Movement
      
      1. moving, reversing or manipulating money or transactions; or
      2. interacting with production financial flows in any way,
   3. High-Risk / Destructive Activities
      
      1. actions that may cause financial, operational or reputational harm;
      2. defacing systems;
      3. attempting to access payment or cardholder data (primary account numbers (“PANs”), card verification values (“CVVs”), Payment Card Industry (“PCI”) environments);
      4. interfering with fraud detection, anti-money laundering (AML) systems, custody infrastructure, wallets or key material; or
      5. attempting to extract private keys, certificates or hardware security module (“HSM”) secrets,
   4. Network/Service Disruption
      
      1. denial-of-service attacks; 
      2. flooding, fuzzing or aggressive scanning; or
      3. excessive automated testing that degrades service or affects customers,
   5. Authentication Attacks
      1. brute forcing or credential stuffing; 
      2. password spraying; or
      3. automated login attempts against any user other than your own, 
   6. Social Engineering
      
      1. phishing employees; 
      2. impersonation of Stitch staff, customers or partners; or
      3. pretexting or tricking support channels, 
   7. Third Parties & Supply Chain
      
      1. testing banks, processors, payment partners or integrations; or
      2. targeting services not owned by Stitch,
   8. Regulatory & Market Integrity
      
      1. bypassing compliance controls; or
      2. manipulating pricing feeds, foreign exchange rates or settlement cut-offs, 
   9. Remote Code Execution
      
      1. if you suspect RCE, do not attempt to obtain it; and
      2. report the suspicion immediately with a safe, minimal proof of concept.

10. Disclosure & Confidentiality Requirements
    
    1. All information shared with Stitch must be kept private.
    2. Researchers may not publish:
       
       1. vulnerability details;
       2. screenshots or logs;
       3. blog posts or social media content; or
       4. academic papers or presentations,

whether or not Stitch has remediated the issue.

3. Any form of public disclosure is strictly prohibited without prior, explicit written permission from Stitch.

11. Recognition & Future Considerations
    
    1. While Stitch does not offer financial rewards:
       
       1. we may issue Certificates of Appreciation for high-quality, compliant reports; or
       2. we may provide a formal “verification of contribution” for academic programs requiring proof.
    2. Reports that do not adhere to this policy may be rejected.
12. Legal
    
    1. This policy is intended to support security research and provides safe harbour for good-faith actions.
    2. However:
       
       1. this policy does not grant authorisation to access data that is not your own; 
       2. this is not an agreement to provide any form of compensation or bounty; and 
       3. Stitch may update this policy at any time.
13. Closing
    
    1. We appreciate your commitment to responsible security research and for helping us protect our ecosystem.
    2. To report a vulnerability, email: security@stitch.money. 
    3. Please follow this policy carefully to ensure a safe, effective and legally protected process.

‍