Responsible Disclosure Policy

Report it privately to security@koyabank.com. Give us a reasonable opportunity to investigate and fix it before you disclose it publicly. Follow the boundaries in section 4, and we will not pursue legal action against you for the research.

The rest of this page is the detail behind those three sentences.

This policy applies to anyone who identifies a potential security vulnerability affecting Koya Labs Ltd's products and services, including but not limited to:

• The koyabank.com web platform.
• Customer facing mobile and web interfaces.
• API endpoints operated by Koya.
• Backend infrastructure operated by Koya.
• Any Koya operated service integration, including payment processing, digital asset custody interfaces, and identity verification flows.

If you are unsure whether something falls inside this scope, ask us before you test it. We would rather answer the question than have you guess.

Security is foundational to Koya's operations as a digital asset conversion and remittance platform. We apply security engineering practices throughout our development lifecycle, including code review, infrastructure hardening, and access controls.

Despite these measures, no complex software system is free of vulnerabilities. We welcome responsible reports from the security research community, and we treat a report as help rather than as an accusation.

If you discover a security vulnerability in a Koya product or service, please report it confidentially to security@koyabank.com.

We ask that you do not disclose the issue publicly until we have had a reasonable opportunity to investigate and remediate it.

What to include

When submitting a report, please include as much detail as you can:

1. A description of the vulnerability and its potential impact.
2. Steps to reproduce the issue.
3. Any proof of concept, screenshots, or supporting evidence.
4. Any known mitigations or suggested fixes.

A report we can reproduce is worth far more than one we cannot, so the second item matters most. If you can only describe the issue in general terms, send it anyway and we will come back to you.

What happens next

We will acknowledge receipt of a valid report and keep you informed of remediation progress where it is appropriate to do so. We do not commit to a fixed response time on this page, because committing to one we cannot always meet would be worse than being honest that severity drives our order of work.

In practice a report moves through four stages: acknowledged, meaning we have it and a person has read it; triaged, meaning we have reproduced it and formed a view on severity; remediated, meaning a fix is deployed; and closed, meaning we consider the matter finished and you are free to disclose.

What makes a report we can act on quickly

The difference between a report fixed this week and one fixed next month is almost always reproducibility. The most useful reports tell us:

• The exact URL, endpoint or interface affected, and the environment you tested against.
• The account or role you were using, if any, and whether the issue requires authentication.
• A minimal sequence of steps that reproduces it, ideally with the request and response.
• What an attacker could actually achieve, stated concretely. "Reads another customer's transaction history" is actionable; "information disclosure" is not.
• The date and approximate time you tested, so we can find it in our logs.

Duplicates and reports already known to us

If we are already aware of an issue, or another researcher reported it first, we will tell you that rather than leave you guessing. Being second does not mean your report was unwelcome, and it does not affect the protections in section 8.

Sending something sensitive

If a report contains material you would rather not send by ordinary email, say so in a first message without the detail and we will arrange a secure channel. Do not include real customer data in a report; a redacted example is always sufficient to make the point.

The protections in section 8 apply provided you stay within these boundaries. They exist to keep other people's money and data safe while you work.

• Do not exploit the vulnerability beyond what is necessary to demonstrate it. Proving a door opens is enough; you do not need to walk through it.
• Do not access, modify, or delete customer data beyond what is strictly required to prove the issue exists.
• Do not publicly disclose the vulnerability until we have confirmed remediation.
• Do not attempt to extort payment in exchange for disclosure. Reports are not compensated unless a bug bounty arrangement is explicitly agreed with us in writing.
• Do not perform testing that could disrupt service availability for other users.

The activities below are not authorised under this policy and may result in legal action. They are listed with the reason for each, because a boundary a researcher understands is one they will respect.

These are in scope to report and you will not be penalised for sending them, but they rarely represent real risk on their own and we will usually close them without a fix. They are listed so you can decide whether the write-up is worth your time.

• Missing security headers with no demonstrated impact.
• Reports produced entirely by an automated scanner, with no manual verification and no proof of exploitability.
• Missing rate limiting on an endpoint that carries no sensitive action.
• Self inflicted issues, such as a vulnerability that requires the victim to paste attacker-supplied code into their own console.
• Clickjacking on pages with no state changing action.
• Weaknesses in software we do not control, reported without evidence that Koya is actually exploitable through them.
• Best practice suggestions with no attack path, such as cipher suite or TLS configuration preferences.

If you can chain any of these into a concrete impact, that is a different report and we want it. The distinction we care about is demonstrated impact, not category.

Koya moves money and holds identity documents, so our severity model is weighted towards those two things rather than towards conventional web severity scores. The following would be treated as urgent.

• Anything that allows one customer to see, alter, or move another customer's money or transaction data.
• Anything that allows access to identity documents, national ID numbers, or verification imagery.
• Authentication or session flaws that permit account takeover, including flaws in the sign-in link, device recognition or session handling.
• Anything that allows a payout, refund or conversion to be initiated, redirected or amended without proper authorisation.
• Server side code execution, or access to infrastructure, secrets, or signing material.
• Flaws in the custody path, including anything touching wallet addresses or the construction of a payout.

If you believe you have found something in this list, say so in the subject line of your report and describe the impact before the detail. We will prioritise reading it.

Provided you act in accordance with this policy, Koya will not pursue legal action against you for good faith security research and disclosure.

In addition, we will:

• Acknowledge receipt of valid reports.
• Keep you informed of remediation progress where appropriate.
• At our discretion, credit researchers publicly for confirmed and sufficiently severe findings, unless you prefer to remain anonymous.

On payment, stated plainly

Koya does not currently operate a paid bug bounty programme. We would rather say that clearly than leave it ambiguous and disappoint you after you have done the work.

Recognition may take the form of a public acknowledgment in section 10, linked to a profile or handle of your choosing. If a bug bounty arrangement is ever agreed with you, it will be in writing and in advance.

This policy is intended to be compatible with recognised responsible disclosure practice.

It does not authorise any activity inconsistent with applicable Kenyan law, including the Computer Misuse and Cybercrimes Act, 2018, and does not grant permission to act in a manner that would place Koya in breach of its own legal or regulatory obligations, including obligations owed to its customers and to its regulators.

How this fits with the Terms of Use

Section 8 of the Terms of Use prohibits attempting to circumvent Website security. Research conducted in good faith and within this policy is not treated as a breach of that section. Research outside this policy is.

Nothing in this policy limits the rights of any third party, and it cannot authorise testing of systems Koya does not operate.

This section will list researchers who have responsibly disclosed vulnerabilities to Koya, with their permission.

It is currently empty. No confirmed disclosures have been made under this policy yet. We have left the section in place rather than hiding it, so that the first entry is visibly the first.

Security reports go to security@koyabank.com. Please do not send vulnerability reports to our general or privacy addresses, as they are not handled with the same confidentiality.