A native casino, sports betting or lottery app that complies with the Dutch Remote Gambling Act (Wet Kansspelen op Afstand). Includes CRUKS integration, duty-of-care layer, Wwft onboarding and GLI-19-compliant RNG from the first sprint, not as a last-minute tick box before release.
Since 1 October 2021, the Dutch online gambling market has been open to licensed operators. The Remote Gambling Act (KOA) and its accompanying Decree on Remote Gambling impose a dense set of technical, organisational and duty-of-care requirements that go well beyond what an ordinary B2C app needs to do. The Dutch Gaming Authority (Kansspelautoriteit, KSA) assesses not only organisation and policy, but the technology itself: how the game flow is structured, how the integration with the Central Exclusion Register for Gambling (CRUKS) works, how duty-of-care interventions are embedded in the software, and how gameplay transactions are stored in the Control Database.
We build casino, sports betting and lottery apps for parties active in that field or wanting to become so. Not a front end on a rented platform with your logo on it, but custom applications in which your own wallet, your own duty-of-care model and your own brand play the central role. For the generic app layer we draw on our app development practice, for the wallet and payout layer on our payment platform work, and for the security stack required by the KSA (Dutch Gambling Authority) and our own information security policy baseline, we rely on the patterns from ISO 27001-compliant software development.
The gambling market this app is entering is concentrated: a handful of large licence holders — Holland Casino Online, TOTO, Unibet, Bet365, BetCity — dominate visibility, alongside niche licence holders in poker, horse racing, esports or fantasy sports. The difference between winning and losing rarely lies in the slots library (Pragmatic Play, Evolution, Play'n GO, NetEnt), which is largely shared. It lies in registration conversion, the speed of Wwft onboarding, how natural the duty-of-care layer feels, and how retention mechanisms work without crossing the line set by Borka.
Not every licence holder is the same. We broadly map our work to three use cases, depending on licence type, target audience and which game types fall under your KSA licence.
An iOS and Android app for a casino licence holder that controls its own wallet, accounts, duty-of-care features and data, while integrating slots, table games and live casino from external providers (Pragmatic, Evolution, NetEnt) through standardised aggregator integrations. The app is built natively for performance, supports distribution via the App Store and Google Play within the rules both stores set for gambling products, and has a full-stack wallet layer that manages balances, bonuses, free-play vouchers and deposit limits. Onboarding runs through iDIN or bank account linking, with automated KYC and sanctions list screening.
A native app for sports betting licence holders with live odds from a feed provider (Sportradar, Betgenius, Stats Perform), a match catalogue with deep markets per event, in-play betting and cash-out, plus a horse racing or esports strand where your licence permits. The odds engine and risk management remain with the feed supplier or your own trading desk; we build the mobile betting experience, bet slip management, the promotions engine and the duty-of-care layer around it. Push notifications are configured to the KSA guideline on responsible marketing, and bonuses follow the Borka restrictions.
For state lottery or lotto operators, fantasy sports platforms and social casino apps that fall outside KOA because there is no real-money stake, or that sit within a differently defined licence category. Here the regulation is weighted differently — Wwft is sometimes less relevant, but in-app purchases under the App Store and Play Store policies are not, and the duty-of-care architecture remains important for preventing cross-border play and catching the transition to gambling for money. We build the same audit trail and monitoring foundation there, as this also adds value for a free-to-play proposition for advertising partners and regulators.
A list of features that almost always appear in a Dutch casino, sports betting or lottery app. Not everything needs to be in version one, but the KSA requirements span almost every layer, so delaying a single compliance feature means delaying the entire release.
Many licence holders start on a white-label platform from a provider such as Playtech, EveryMatrix or Pronet Gaming. For a first launch, that is a sound route: fast time-to-market, and much of the compliance is already covered by regulation. However, there are four moments when custom development becomes the better choice.
You find that your brand and your promises to customers are getting lost in a UI that also runs for five of your competitors. The duty-of-care tone, the promotions layer and the retention flow get stuck on standard components you cannot adapt. A dedicated native app is then the logical next step.
On a white-label, the wallet, CRM and responsible-gaming engine sit with your platform provider. When the contract ends or a vendor issue arises, migrating is a nightmare. With your own wallet and back-end layer, you own the relationship and can switch providers (slots, sportsbook) without your players noticing.
Standard white-labels cover slots, live casino and sportsbook well, but for a poker room, a horse-racing app or an esports betting platform the standard flow falls short. A custom app in which your vertical specialism takes centre stage is often the only route.
The KSA raises the bar on duty of care in the market every year. Operators who do not wait for tightening, but want to lead themselves with a sophisticated responsible-gaming engine (player-level behavioural modelling, early-signal intervention, agent coaching tools), rarely achieve that layer on a white-label at their own pace.
You hold a physical casino licence and want to launch an online offering alongside your venue. A white-label leaves the cross-channel layer untouched: loyalty across on-property and mobile, a single wallet across locations, on-property activation via QR. Custom development is often the only way to deliver that omnichannel story.
Building a casino app for the Dutch market is not the same as building a consumer app. We work through a number of steps that take the KSA review into account from the outset, so that the application or change notification does not run into technical surprises.
We discuss which type of licence you hold or are applying for, which gaming verticals it covers, whether there is a group structure with an EU licence behind it, and which supplier relationships are already in place (white-label, sportsbook feed, providers). That determines the direction of the project scope.
Together with your compliance officer, legal adviser or external KSA consultant, we produce a blueprint: what the CRUKS integration looks like, which duty-of-care architecture, which Control Database implementation and which audit flow. This blueprint becomes the framework for the build and the basis for the notification file submitted to the KSA.
Tech stack choice (native iOS and Android), backend on EU cloud, encryption approach, wallet architecture, integration blueprint with providers and feeds. For the security layer we draw on the patterns from ISO 27001-compliant software development, particularly for key management, access control and logging.
A working build every two weeks. A test group, usually your own internal KSA officer plus a number of compliance staff, plays in a staging environment with a test CRUKS integration. Each sprint closes with a short compliance review before the feature may go live.
External penetration test of the app and backend, RNG and game-flow audit by a GLI- or eCOGRA-accredited lab where relevant, and compilation of the certification file that accompanies your KSA application or change notification. Issues raised by the penetration test and audit are resolved before go-live.
Phased rollout, first to a closed test group and then to a wider audience, with publication on the App Store and Google Play in line with the rules both stores set for gambling apps. After that, ongoing maintenance covering security patches, regulatory changes and further development of the duty-of-care layer.
We make a few choices early with you, because they shape the entire rest of the build and because the KSA has specific expectations for them.
For casino apps we almost always opt for native: Swift for iOS, Kotlin for Android. Cross-platform (React Native, Flutter) is fine for lighter use cases, but live-casino streaming, anti-tampering, anti-rooting and the App Store acceptance requirements for gambling products are easier to get right with native. For the back office and agent tools we often work in a React web app.
AWS Frankfurt, Microsoft Azure West Europe or a Tier IV EU data centre, with key management in a Hardware Security Module under EU control. No US region for primary or backup. For parties with particularly strict requirements we can run on-premises or in a private cloud setup, for example a hosted Kubernetes within your own infrastructure.
We build the wallet, covering balances, bonuses, free spins and pending withdrawals, as a service of its own rather than outsourcing it to a provider. This gives you ownership of the player relationship and makes provider changes possible. For the payment foundation we draw on our payment platform expertise, with PSD2-compliant flows, iDEAL integration and withdrawal management to accounts in the player's own name.
For slots, live casino and table games we work with an aggregator such as SoftSwiss, Hub88, Relax or EveryMatrix Casino Engine, or directly with provider APIs. For in-house games we build the RNG and game-outcome engine to GLI-19 level, with independent audit. The choice depends on the scope of your licence and your ambitions for differentiation.
We build models for fraud detection, multi-account screening and behavioural duty-of-care signals separately, with attention to explainability and governance. For this we align with the approach from our AI development practice, including a DPIA, EU AI Act classification and human review of critical interventions.
Identification via iDIN as the main route for Dutch players, with a fallback to passport scan plus a KYC provider for edge cases. For self-exclusion confirmations and limit increases, where it carries significant legal weight, we use an eIDAS-compliant signing flow so that consent holds up as evidence.
With a KOA app, compliance isn't an extra check; it's the architecture. These are the frameworks we design into every project from sprint one.
The parent Act and its implementing decree set the framework for who may offer games, which game types are permitted, and what player protection applies. The technical annexes to the decree cover, among other things, the Control Database, gaming system requirements and the standards the software must meet. We design to those standards and document explicitly where we touch them.
The CRUKS integration is functionally the centrepiece of the duty-of-care layer. A check against CRUKS is made at every login and immediately before every game round. Delay in that check is not an option: if the integration fails temporarily, we end the session rather than let play continue. We build this fail-closed behaviour in by default, even when some product managers push for a smoother experience.
Player onboarding is a trigger under the Wwft (Dutch Anti-Money Laundering and Anti-Terrorist Financing Act). Identification, sanctions list screening, PEP checks and risk-based enhanced due diligence (CDD-plus) are built into the flow. Thresholds for enhanced checks are set in the decision logic, and every onboarding step is held in an audit trail with immutable storage for the retention period the Wwft prescribes.
The duty of care is not a box-ticking exercise. We build a behavioural model that monitors play times, stake escalation, losing streaks and session length, with graduated interventions ranging from a pop-up to a call from an agent to temporary account closure. The decision model is periodically validated against independent gambling research and adjusted when the Gaming Authority (KSA) shifts the standard.
Play history, duty-of-care events and KYC data are high-risk or special category personal data under the GDPR. We carry out a DPIA for every project, limit data collection to what is strictly necessary, and build retention and deletion policies into the data layer itself. Play history is automatically pseudonymised or deleted after the statutory retention period, without manual intervention.
The advertising restrictions under Borka affect the app's marketing layer: push, in-app, email and paid channels. We build filters based on age, CRUKS status, cooling-off status and risk profile, so a campaign cannot accidentally reach a player who isn't eligible. Frequency and channel opt-outs can be set at player level.
For the game layer (RNG, RTP, jackpot distribution and return-to-player reporting), we work to the GLI-19 standard, which the KSA accepts. For in-house games, an independent laboratory provides certification; for external providers, we only work with partners who have had their games tested to this standard.
Apple and Google have specific restrictions on gambling apps: proof of licence, regional restrictions, age verification, no native in-app purchase integration for real-money gambling, and separate distribution routes for some sub-categories. These policies change, so we maintain up-to-date checklists and build the release flow to respect the right subset for each category.
What we often hear from compliance officers, CTOs and product managers at licensed operators.
A no-obligation introductory call of half an hour. We listen to your licence context, compliance approach, supplier stack and product ambitions, and give you direction you can act on. Afterwards, you and we decide whether a follow-up conversation is worthwhile.
Appfront uses cookies and similar technologies to keep the website working properly, for analytics and for marketing. You choose what you allow. Read more in our privacy policy.
