Responsible disclosure policy

A service that moves money always ends up being tested, by well-meaning people or otherwise. We would rather learn about a flaw from a report than from an incident, and we commit to pursuing nobody for research carried out in good faith within the scope described here.

No financial reward is offered at this stage. We do not announce a bounty programme we could not honour. What we offer is concrete: a fast acknowledgement, a technical counterpart, tracking through to the fix, and public credit if you want it.

In scope

• The public site and its application pages.
• Publicly exposed programming interface endpoints.
• Authentication, session and password reset mechanisms.
• Any flaw leading to reading, altering or diverting another user’s data.
• Any flaw allowing an amount, a beneficiary, a rate or an order state to be changed.
• Configuration mistakes exposing a secret, a backup or an internal environment.

Out of scope

• Our vendors’ own services: report those directly to the publisher concerned, who runs their own programme.
• Reports produced by an automated scanner with no proof of exploitability.
• Header or configuration findings with no demonstrated impact — a missing recommended header, a cookie without an attribute on public content.
• Social engineering against our staff, our vendors or our users.
• Denial of service, flooding and load testing, in any form.
• Vulnerabilities requiring physical access to an already compromised device.

These rules are not formalities: they define exactly what stays covered by our commitment not to pursue.

1. Use only your own accounts and your own data. Create a second account if you need to test isolation between users.
2. Stop as soon as access is demonstrated. Do not read, copy or exfiltrate data belonging to a third party.
3. Do not degrade the service: no flooding, no deletion, no modification of production data other than your own.
4. Do not make the flaw public before it is fixed, or before the deadline we agree together expires.
5. If you unintentionally reach personal data, stop immediately, do not keep it, and say so in your report.

A useful report holds five elements: the component affected, the real impact, reproduction steps, a minimal piece of evidence, and the timestamps of your testing. The rest is comfort.

Never include in a report personal data belonging to a third party, a real identifier or a complete secret. A partially redacted capture is enough to demonstrate access.

You then get a status update at least every two weeks until closure, even when there is nothing new to announce. Silence is what pushes a researcher to publish: we would rather avoid it.

• We confirm the fix and let you verify it before any closure.
• We publish an incident note where the flaw could have exposed data, even if no abuse is found.
• We credit you publicly if you want, under the name or handle of your choice, or not at all if you prefer anonymity.
• We agree a publication date with you if you want to write up your own analysis.