Vulnerability Disclosure

1. Overview

Fyatu is committed to the security of our platform, our clients, and their cardholders’ data. We welcome responsible security research and appreciate the efforts of the security community in helping us identify and address vulnerabilities.

This policy describes how to report security vulnerabilities to us, what is in scope, what is expected of researchers, and how we will respond.

2. Scope

The following assets are in scope for security research:

• Website — https://fyatu.com and all subdomains
• REST API — All public and authenticated API endpoints (https://api.fyatu.com)
• Business dashboard — The web-based programme management interface
• API documentation — https://docs.fyatu.com
• Webhook infrastructure — Event delivery endpoints and signature verification mechanisms
• Infrastructure — Any Fyatu-owned service accessible from the public internet

Testing must be conducted against the sandbox environment only. Do not test against production systems, production API keys, or data belonging to real clients or cardholders. Sandbox credentials are available at https://docs.fyatu.com.

Out of Scope

The following are not in scope and must not be tested:

• Third-party services and integrations (KYC providers, BIN Sponsors, card networks, payment processors)
• Physical security of offices or data centres
• Social engineering attacks against Fyatu employees or clients
• Denial-of-service (DoS/DDoS) attacks or any testing that degrades platform availability
• Spam or bulk messaging
• Attacks requiring physical access to a device
• Vulnerabilities in third-party software that do not directly affect Fyatu systems
• Production cardholder data, production card programmes, or live transaction flows

3. Qualifying Vulnerabilities

We are particularly interested in vulnerabilities affecting the card issuing platform and API infrastructure, including but not limited to:

• Remote code execution (RCE)
• SQL injection, NoSQL injection, or command injection
• Cross-site scripting (XSS) and cross-site request forgery (CSRF)
• Authentication or authorisation bypass — including API key validation and OAuth flows
• Insecure direct object references (IDOR) — e.g. accessing another programme’s cards or transactions
• Server-side request forgery (SSRF)
• Sensitive data exposure — including card numbers (PANs), CVVs, API keys, or cardholder PII
• Webhook HMAC signature bypass or replay attacks
• Privilege escalation within the dashboard or API (e.g. accessing another client’s programme)
• JIT Authorization flow manipulation
• Cryptographic weaknesses in card tokenisation or API credential storage
• Payment or transaction manipulation

Non-Qualifying Issues

The following are generally not considered qualifying vulnerabilities:

• Missing HTTP security headers with no demonstrable exploit
• Clickjacking on pages with no sensitive actions
• Self-XSS requiring the attacker to inject their own payload
• Rate limiting issues that do not lead to account takeover or data exposure
• Outdated software versions without a demonstrated exploit
• Brute-force attacks against login without a bypass of existing protections
• Content spoofing or text injection without demonstrated impact

4. How to Report

Send your report to [email protected]. If possible, encrypt your message using our PGP key (available upon request).

What to Include

To help us investigate quickly, please include:

• Description of the vulnerability and its potential impact
• Affected asset (URL, API endpoint, dashboard screen, webhook)
• Step-by-step reproduction instructions using sandbox credentials
• Proof of concept (screenshots, video, or code) if available
• Your contact information for follow-up
• Any tools or scripts used during testing

5. Our Commitment

When you report a vulnerability in good faith, we commit to:

• Acknowledge your report within 48 hours
• Assess the severity and provide an initial evaluation within 5 business days
• Remediate confirmed vulnerabilities in a timeframe appropriate to their severity
• Keep you informed of progress toward resolution
• Credit you publicly (with your permission) on our security acknowledgements page once the vulnerability is resolved

6. Researcher Guidelines

To participate in our responsible disclosure programme, you must:

• Act in good faith — Research must be conducted with the intent to improve security, not to cause harm
• Use the sandbox only — Never test against production systems, real client programmes, or live cardholder data
• Avoid data access — Do not access, modify, or exfiltrate data beyond what is necessary to demonstrate the vulnerability
• Minimise impact — Stop testing immediately if you cause unintended disruption
• Do not exploit — Once a vulnerability is confirmed, do not exploit it further or pivot to additional systems
• Maintain confidentiality — Do not publicly disclose the vulnerability until we have confirmed it is resolved and given written permission
• Comply with the law — Your research must comply with all applicable laws and regulations
• One report per issue — Submit a separate report for each unique vulnerability

7. Safe Harbor

Fyatu will not pursue legal action against researchers who:

• Follow the guidelines outlined in this policy
• Act in good faith and without malicious intent
• Test exclusively against the sandbox environment
• Do not access, modify, or exfiltrate real client or cardholder data
• Report the vulnerability directly to Fyatu and do not disclose it publicly before resolution

This safe harbour applies to legal claims under our control and does not bind third parties, including BIN Sponsors or card networks.

8. What We Do Not Offer

This is a responsible disclosure programme, not a bug bounty programme. We do not currently offer monetary compensation for vulnerability reports. Researchers who submit valid, qualifying reports will receive public acknowledgement (with permission) and our gratitude.

9. Contact

• Security reports: [email protected]
• General support: [email protected]