Security
What we have actually done, and what we have not.
No "bank-grade" and no "enterprise-grade". Those phrases exist because they cannot be checked. Below is the specific work, with the mechanism named — and the certifications we do not hold, named just as specifically.
Authentication
Two-factor, verified against the specification itself
RFC 6238 TOTP, enforced at three levels — an individual player, an individual staff member, and a brand-wide policy that can make it mandatory. The implementation is verified against the official Appendix B test vectors from the specification, then cross-checked a second time against an independent Python implementation.
- A stolen session cannot replace the second factor that protects the account — re-enrolment is gated on more than being logged in.
- Sign-in has brakes, applied per account as well as per address, so distributed guessing against one account is throttled rather than only bursts from one IP.
- A stranger's failed guess does not accuse the customer. A failed password attempt against an account does not raise a fraud signal on the account owner — which sounds obvious and is a mistake we made and fixed.
- The client IP is pinned as unforgeable rather than read from a header an attacker controls, which is what makes every rate limit above meaningful.
Authorization & audit
Two locks on every path that moves money
Capability, then ceiling
Manual wallet adjustment — the only operation that creates money — is refused by the capability layer for roles that should not have it, and bounded by a per-role, per-day monetary ceiling for roles that should. Either lock alone is defeatable.
Ownership, not just role
Having the "players" capability does not mean having it on another brand's players. Tenant ownership is checked in addition to role, and we ran an audit specifically to find the places it was not.
Audited by default
Back-office writes are captured by the framework, not by each endpoint choosing to log. The endpoint that forgets is otherwise always the one that mattered.
How we would rather be judgedNot on whether we have had bugs — we have, and the commit history names them in plain English: an unauthenticated price walk worth +52.45% risk-free, a limits bypass through deletion, an anonymous operator token that could move money. Judge us on the fact that each one is described in a commit message a non-engineer can read, and held closed by a test.
Data protection
GDPR as operations
- Subject access export is an operation, not a manual assembly job.
- Erasure is an operation too — and it refuses while a self-exclusion is active, funds remain, or bets are pending. A platform that always honours an erasure request is a platform that will delete a self-excluded customer's exclusion.
- Identity documents are gated separately from ordinary player reads, so a reporting role cannot reach a passport scan.
The certifications we do not holdNo ISO/IEC 27001 audit. No RTS test-house certification. No penetration test by an external firm. No SOC 2. The architecture is built to narrow the scope of the first of those — the regulated systems sit behind the API, so a CMS rendering a balance is not storing one — but narrowing scope is not the same as passing an audit, and we have not been through any of them.
Send us your security questionnaire.
We will answer it honestly, including the rows where the answer is "no, and here is what it would take". That is faster for both of us than a discovery call.