Skip to content

Security and compliance approach

Security is a property of how the platform is built, not a list of features. This page describes our approach in enough detail for your technical and compliance teams to ask the right questions.

Request a DemoContact Sales

01Architecture

Each area below states what the platform is designed to do and how.

01

Tenant isolation

Each operator is a tenant. Isolation is enforced where data is read and written, so a mistake in an interface cannot expose another tenant's data.

How it is designed

  • Every record carries a tenant identifier, and every query is scoped by it in the data layer.
  • API keys and staff sessions are bound to one tenant. A request parameter cannot widen that scope.
  • Events, exports and webhooks are scoped the same way as queries.
  • Inside a tenant, brand-level scoping limits what each team can see.
consoledata layer / scoped query
Sample data
-- scope is added by the data layer, not by the caller
SELECT id, amount, status
FROM transactions
WHERE tenant_id = :session_tenant
  AND brand_id IN (:allowed_brands)
  AND player_id = 'pl_9041';

02

Role-based access control

Staff access follows least privilege. Roles group permissions, and permissions are checked on the server for every action rather than only hidden in the interface.

How it is designed

  • Roles are defined per tenant and can be limited to specific brands.
  • Sensitive actions, such as limit overrides, resettlement and withdrawal approval, can be configured to require a second person.
  • Staff sign-in is designed to support multi-factor authentication.
  • Sessions expire and can be revoked centrally.
consoleplatform / roles
Sample data
RoleCatalogPlayersFinanceConfigAudit
Owner
Operations
Finance
Support
Auditor

03

Audit logging

Administrative actions are written to an append-only log that records who did what, when and from where.

How it is designed

  • Each entry holds the actor, the target, the action, the previous and new values, the time and the origin.
  • Entries cannot be edited or deleted through the application.
  • The log is searchable in the console and exportable for auditors.
  • API activity is attributable to the key that performed it.
consoleaudit / entry aud_77c1e0
Sample data

limit.override.approved

immutable
Actorstaff: finance.lead
Second approvalstaff: ops.manager
Targetplayer pl_9041
Changedeposit_week 500 → 750
When2026-11-13 19:02:11 UTC
Originconsole · session ses_41b0

04

API security

The API is the only way in, for our console and for your integrations alike, so it carries the same controls for both.

How it is designed

  • All traffic uses TLS. Plain HTTP is not served.
  • Bearer keys are scoped per environment and integration, and shown once at creation.
  • Rate limits apply per key and are reported in response headers.
  • State-changing requests accept idempotency keys, so retries cannot double-post.
  • Webhooks are signed with HMAC-SHA256 over a timestamped payload to resist tampering and replay.
  • Input is validated against a schema before it reaches business logic.

05

Data security

The platform is designed to hold as little personal data as it needs, to protect what it holds, and to let operators meet their own retention duties.

How it is designed

  • Designed for encryption in transit on every connection and encryption at rest for data stores and backups. Specifics are documented per deployment.
  • Secrets and provider credentials are kept out of source code and supplied at runtime.
  • Logs are structured to avoid personal data by default.
  • Retention periods are configurable per data category.
  • Access to production data by Poocraft staff is restricted, logged and agreed per engagement.

06

Monitoring and observability

Problems should be seen by us and by you before they are seen by players. Observability is built into each service and each adapter.

How it is designed

  • Structured logs with a request identifier that follows a call across services.
  • Health checks and latency metrics for every service and every provider adapter.
  • Alert thresholds agreed with the operator and routed to the people on duty.
  • Adapter status visible to operators in the console.

07

Backup and disaster recovery planning

Recovery objectives depend on the deployment and are agreed per engagement. What we bring to every engagement is the method.

How it is designed

  • Backup scope, frequency and retention are defined with each operator.
  • Restore procedures are written down and rehearsed rather than assumed.
  • The immutable ledger and its reconciliation reports make it possible to verify a restore.
  • Recovery objectives and responsibilities are recorded in the agreement.

08

Responsible gaming controls

Limits and exclusions are platform primitives. Every product checks them on the same path as the wallet, so a new game or market cannot bypass them.

How it is designed

  • Deposit, loss, stake and session limits per player.
  • Cool-off and self-exclusion, applied across brands where the operator requires it.
  • Integration points for external exclusion registers and affordability checks.
  • Each decision is recorded with its reason for later review.

09

Jurisdiction-specific compliance readiness

Requirements differ by jurisdiction and change over time. The platform treats them as configuration and reporting, so entering a market does not mean rebuilding.

How it is designed

  • Rules per jurisdiction: limits, mandatory messages, and game and market availability.
  • Report and export formats are defined against the regulator's requirements during onboarding.
  • Evidence trails for KYC/AML and responsible gaming decisions.
  • We work with your compliance team. The licence and the regulatory relationship stay with the operator.

02Shared responsibility

A platform does not make an operation compliant on its own. This is the default division; the agreement for each engagement makes it specific.

Shared responsibility between Poocraft and the operator
AreaPoocraftOperator
Licensing and regulationSupplies the technical documentation and evidence the operator needs.Holds the licence and manages the relationship with the regulator.
Platform softwareDevelops, tests and maintains the platform and its adapters.Decides which modules and adapters are used.
ConfigurationProvides the controls and sensible defaults.Sets limits, roles, markets and rules, and reviews them.
Staff accessEnforces roles, sessions and audit logging.Grants and removes access for its own staff.
Player funds and paymentsProvides the ledger and the payment adapters.Holds the funds and the agreements with payment providers.
KYC/AML and responsible gamingProvides integration points, enforcement and evidence trails.Defines the policy, chooses providers and makes the decisions.
Provider credentialsStores credentials as secrets and limits access to them.Owns the provider accounts and rotates credentials.
Infrastructure and availabilityAgreed per engagement and written into the agreement.Agreed per engagement and written into the agreement.
Incident responseDetects, communicates and fixes platform issues as agreed.Handles player communication and regulatory notification.

We describe our engineering approach here. Certifications, audits and service levels are agreed and documented per engagement.

Reporting a security concern

If you believe you have found a vulnerability in this website or in a Poocraft system, write to [email protected]. Please include enough detail to reproduce it and give us time to investigate before sharing it publicly.

Due diligence

Send us your requirements or your due-diligence questionnaire. We answer in writing and walk your team through the architecture.

Request a DemoTalk to Our Team