Least privilege by default
Every account, service and key starts with nothing and earns exactly what the job needs.
Security is how the code is written
Not a badge, not a paragraph in a contract. This page describes how we build, what we protect, who can reach what, and exactly what happens on the worst day — in enough detail that you can hold us to it.
- Last reviewed
- July 2026
- Applies to
- Everything we build and everything we operate
- Disclosure address
- [email protected]
- First response
- Within 72 hours
Row-level security on every table
Isolation is enforced by the database itself — not by remembering to write the right filter.
Secrets never live in the database
Keys sit in the environment and the secret store. They are not rows, and they are never inside a backup.
Money is verified on the server
Nothing that moves value is trusted from a browser. The server recalculates from the source, then decides.
How we build
Most breaches are not exotic. They are an ordinary mistake that nothing was in place to catch. These are the defaults that make the ordinary mistake harmless.
Least privilege, everywhere
Every identity in the system starts with no access and receives only what it must have to work.
- A service account is scoped to one job and cannot touch what sits beside it
- Public keys read only what is public anyway
- Sensitive operations run server-side, behind an explicit check
Row-level security on every table
Every table is created with policies enabled, and the policy is written before the feature that needs it.
- A tenant can only ever see rows that belong to it
- A player can only ever see their own records
- A missing policy fails closed — no rule means no access
Secrets stay out of the database
Private keys, provider tokens and passwords never become a row in a table — not even temporarily.
- Secrets live in environment configuration and a dedicated store, separated per environment
- A database backup contains no live key, so a leaked dump is not a leaked wallet
- Rotating a key is a planned operation, not an emergency
Anything that moves money is verified server-side
An amount, a balance, an odds value or a permission arriving from the client is a request — never a fact.
- Figures are recomputed from the source of truth instead of accepted from the payload
- Writes are idempotent, so a retry or a double click can never credit twice
- Every movement leaves a record that cannot be edited afterwards
Fail closed, then fail loudly
Deny is the default. An error is never allowed to degrade into permissive behaviour.
- Anything not explicitly allowed is refused
- Refusals are logged, including the routine ones
- Security checks run in the build, not only in review
Review, dependencies and change control
Nothing reaches production without a second pair of eyes and a way back.
- Every change is reviewed before it is merged
- Dependencies are updated on a schedule, and urgent fixes jump the queue
- Nobody edits production by hand
The money rule
In every system we build there is a point where a number becomes real value. That point always sits on the server. This is the full chain, and every link in it exists to cancel an assumption somebody might otherwise make.
01 The request arrives
The client asks. Asking is the entire extent of what the client gets to do.
02 Identity is re-established
The session is verified against the server's own store, not against whatever the caller attached to the request.
03 Amounts are recomputed
Prices, odds, balances and bonuses are read from the source of truth. Numbers sent by the browser are simply not used.
04 Rules are applied
Limits, permissions, risk rules and tenant configuration are all evaluated before anything is written.
05 Written once, recorded forever
The write is idempotent, so a retry cannot duplicate it, and it leaves an audit record nobody can quietly revise.
Things we refuse to do
- Trust a price, a balance or a permission because it arrived from a browser.
- Store a private key, an API secret or a password as a row in a database.
- Give a service account broader rights because it was faster that way.
- Ship a table without a policy and promise to add one later.
Data protection
Encryption is the floor, not the achievement. What really decides the outcome is how little data reaches us at all, and where the wall between one brand and the next actually stands.
Encrypted in transit
TLS on every connection — browser to server, server to database, service to service. No internal hop is treated as safe just because it is internal.
Encrypted at rest
Storage-level encryption across databases, backups and files. Particularly sensitive fields get a second layer on top of that.
Isolation between brands
One codebase, many brands, and no route between them. Every query is bound to its tenant at the database level, not in the application's good intentions.
We hold less
Data we never store cannot leak. Card numbers stay with regulated processors, private keys never reach us, and logs are stripped of anything they do not need.
How the isolation actually works
Each brand is a tenant with its own identifier. That identifier is never taken from the request — it is resolved on the server and then enforced by a database policy. Even if application code forgets to filter, the database does not forget.
- Brand AIsolated tenant
- Brand BIsolated tenant
- Brand CIsolated tenant
Row-level security policy
Shared databaseCross-brand read: blocked by policy
The same boundary protects the other direction too: a bug in one brand's configuration cannot spill into another brand's data, because the policy does not care which code asked.
Who can reach what
Access control is only real when it is boring: a small number of roles, each with an obvious ceiling, and a record of everything anyone did above the ordinary line.
- Role
Player
Can reachTheir own account and nothing elseGuardrailEnforced by policy, not by the interface - Role
Brand operator
Can reachOne brand's data and settingsGuardrailCannot see another brand under any circumstance - Role
Support staff
Can reachWhatever the ticket genuinely requiresGuardrailRead first, and every action logged by name - Role
Platform engineer
Can reachProduction only when there is a reasonGuardrailNamed account, two factors, time-boxed
The rules behind the table
- Two-factor authentication on every staff account. Not optional, not skippable, not deferred.
- Named accounts only. Shared logins do not exist, so every action has an owner.
- Rights are granted per role and re-examined the moment a role changes.
- Offboarding revokes everything the same day — keys, sessions and third-party seats included.
- Sessions expire, and privileged sessions expire considerably sooner.
- Administrative areas are gated separately, even for someone who is already signed in.
Audit logging
Every privileged action writes a record: who, what, when, from where, and what changed. Those records are append-only, so the people able to perform an action are not able to quietly rewrite the history of it. When something looks wrong, the first question always has an answer.
Running it safely
A system that is secure on launch day has achieved nothing. The achievement is staying that way through two years of changes, new people and features nobody planned for.
Backups that are actually restored
Automated, encrypted and retained to a schedule — and restored on purpose, because a backup nobody has ever restored is a rumour rather than a plan.
Monitoring somebody reads
Health, errors, latency and security events, with alerting tuned so that an alert means something. Noise is a security problem: it trains people to ignore alarms.
Patching on a schedule
Dependencies are tracked and updated deliberately, and an urgent fix jumps the queue instead of waiting politely for the next release.
Controlled change
Every change goes through review and a repeatable deploy, with a way back. Production is never edited by hand, however small the fix looks.
If an incident happens anyway
Every serious operator has a plan for the bad day. Ours is written down, and short enough that people actually follow it under pressure.
Contain
Stop the bleeding first — revoke, isolate, or take the affected path offline. Explanations come afterwards.
Assess
Establish what was reached, by whom and for how long, from logs that were designed to answer exactly this question.
Notify
Affected customers hear it directly from us, and regulators within the window the law sets. No spin, and no waiting for a more comfortable version of the story.
Remediate
Rotate the credentials, close the path, and verify the fix instead of assuming it worked.
Learn
A written review that names the systemic cause rather than a person, and produces changes that actually ship.
Found something? Tell us.
If you have found a weakness in anything we run, we would much rather hear it from you than from someone else. Report it in good faith and you will be treated as an ally, not a threat.
- Security contact
- [email protected]
- Acknowledgement
- Within 72 hours
- Initial assessment
- Within 10 business days
- Credit
- In your name, if you want it
Write in whatever language you are comfortable with, and include the steps to reproduce. A short, reproducible report beats a long, impressive one every time.
Send a report by emailWhat we ask of you
- Report privately first, and give us a reasonable window to fix it.
- Use the minimum access needed to demonstrate the issue — no data extraction, no moving deeper in.
- Do not degrade the service: no denial of service, no spam, no social engineering of staff or users.
- Stay away from other people's data. If you reach it by accident, stop and tell us.
What you get from us
- A human acknowledgement, quickly, from someone who understands the report.
- An honest assessment — including where we disagree, and why.
- No legal action against good-faith research that follows the guidance above.
- Credit when the fix ships, if that interests you.
In scope
- The sites and platforms we run in production
- Our APIs and integration endpoints
- Anything that can affect customer data, money or access
Out of scope
- Automated scanner output with no demonstrated impact
- Third-party services outside our control — those belong with their owners
- Theoretical findings with no realistic path to exploitation
Where we stand on compliance
We would rather be precise than impressive. Here is our actual posture, described in plain terms.
Privacy by design
Data protection principles — minimisation, purpose limitation, retention limits — sit inside the architecture rather than being stitched on in a hurry before a review.
Contracts that mean something
Data processing agreements with the providers we use and the clients we build for, so responsibility is written down before any data moves.
Engineering for regulated sectors
We build for gambling, payments and messaging — fields where auditors, processors and regulators ask hard questions. The architecture is designed to survive them.
Due diligence, answered
Security questionnaires, architecture documentation and a written description of the access model, answered by the people who built the system rather than a sales team.
Independent testing
We support penetration testing and security review commissioned by our clients against what we built, and we fix what it turns up.
What we do not claim
We do not advertise certifications we do not hold, and we do not turn audit findings into marketing copy. If a mark ever appears on this site, it will be because the work behind it was genuinely done. Until then the honest answer is this page: here is how the system is built, and here is how you can check us.
Talk to us
Want the deeper version?
Architecture diagrams, the access model, a security questionnaire that needs answering, or a project you want built properly from day one — same window, real engineers on the other side.
No form to fill in. The chat opens right here.