By Filippo Ferri, Chief Compliance Officer, Delasport
When we first looked at Alberta’s iGaming framework, much of it felt familiar from Ontario. That familiarity was useful, but it could also be misleading. It is quite easy to read the two sets of requirements and conclude that moving an existing platform into Alberta should be a relatively small project. Once you get into the implementation, you start to see why that is not always the case.
At Delasport, we have now successfully launched full turnkey solutions in both jurisdictions, including our sportsbook, Player Account Management system and the integrations needed to support the operation. Getting there meant working closely with operators during their licensing processes. Some of what we had built for Ontario carried across quite well. Other parts required considerably more work than a first reading of the Alberta framework might suggest.
I think that experience is worth sharing, particularly with operators comparing potential platform providers. Having a supplier licence is important, but it does not tell you whether a particular integration is complete, how reporting works in practice or who will deal with the operational tasks that technology cannot perform on its own. Those are the areas I would spend time discussing with a supplier.
Self-exclusion: a familiar requirement with a different implementation
Central self-exclusion is a good place to start. Both markets need a way to identify players who should not be allowed to gamble, and Alberta required its central integration before launch. However, having already connected to Ontario’s system did not mean that we had an Alberta solution ready to use.
For example, Ontario’s BetGuard returns a Boolean match – in other words, whether a match has been found – but no information about the exclusion term. Alberta can also return an expiry date, and its registry covers AGLC-banned individuals as well as self-excluded players. The information used to identify a player differs too. Ontario uses six attributes, with fuzzy matching in production, while Alberta uses first name, optional middle name, last name and date of birth.
There are further differences in how checks are processed. Ontario supports batches of up to 1,000 records. Alberta documents individual player checks and separate scheduled batch processing, alongside a dedicated marketing opt-out endpoint. Authentication, response handling and health monitoring also need their own implementation. Individually, these may sound like relatively small technical details. Taken together, they affect the work needed to connect the platform and keep the service running.
We could reuse some of our player-blocking and exclusion-management logic, which helped. But we still had to build around the way Alberta’s system works. An expiry date, for example, gives us information for a status review; it should not be interpreted as an instruction to reopen an account automatically.
If I were discussing this with a potential supplier, I would ask them to show me the Alberta implementation: how it handles self-exclusions and prohibited players, how the marketing opt-out is synchronized, and how individual and batch checks affect player access. That tells you more than a general confirmation that the platform supports self-exclusion.
Reporting involves more than producing the same figures
We found a similar issue with reporting. The daily and weekly reports in Ontario and Alberta concern much the same subjects: anti-money laundering, player transaction activity, gaming transaction activity and weekly gross gaming revenue. Even the names are familiar. But there is enough difference in the file structures that we had to build the Alberta reports specifically for that market, including hashing the files before sending them through secure SFTP.
The periodic reports were a more substantial undertaking. In Ontario, the processes have involved exchanging Excel spreadsheets or CSV files with iGaming Ontario. In Alberta, the information is submitted through an API integration in JSON format. To someone looking at the finished submission, that might appear to be a technical change in how a file is sent. For the platform provider, it affects how the information is collected and prepared in the first place.
Some of that information comes from the platform, but not all of it. Reports about Responsible Gambling interactions or complaints (for example) require input from operational teams. There are also inventories of certified games and their digital signatures, which can take considerable effort to keep up to date as the games on a website change and certifications are renewed annually by game suppliers.
We therefore needed back-office interfaces through which teams could enter their information, and workflows to combine it with platform data, check it and, where necessary, consolidate or summarize it before submission. Connecting to the API is only one part of that work.
This is an area where I would be quite specific when speaking to a supplier: have you already integrated with AGLC’s API for periodic reporting in JSON? Can you show how information from operational teams gets into those reports? Have you also built the Alberta-specific daily and weekly files, including the required hashing? These are practical questions with answers that should be possible to demonstrate.
The operator remains ultimately responsible for submitting its reports. Our role is to provide the interfaces and processes that help it do that properly, including where information cannot be generated automatically.
Some requirements only become available as the operator progresses
There was another complication with Alberta’s periodic reporting. The detailed specifications were not publicly available, nor did they come to us simply because we were going through our own supplier licensing process. We received them through working with an operator undergoing licensing. Without that relationship, a standalone platform provider would have found it difficult to develop the complete solution.
That experience reinforced something we had already learned in Ontario: the operator’s licensing work and the supplier’s development work need to be coordinated. The operator receives information that the supplier needs, and the supplier must translate it into something that works within the operation. We entered both markets alongside operators going through that process, which allowed us to work through those requirements together.
Nor does the work stop once the market is entered. Ontario has now begun its own project to automate reporting exchanges. Supporting both jurisdictions means continuing to invest time and resources as their arrangements evolve, even where we have already completed an implementation.
I would therefore ask a potential supplier whether it has implemented the detailed requirements received through an Alberta operator’s licensing process, and how it will handle subsequent changes. It is worth establishing who receives new specifications, who develops the necessary changes and who will maintain them after launch.
KYC needs a process for the cases automation cannot complete
Of course, reporting and self-exclusion are only part of the operation. The platform also needs tools that help establish who the player is and whether they are eligible to play. We work with Jumio for government-ID verification and name screening, including politically exposed persons, sanctions and adverse media. The vast majority of players pass through the automated process, but there will always be cases that need manual attention.
One quite practical example of the need for local responsiveness was the introduction of a new driving licence in Alberta around the market-launch period. A global KYC provider still needs to keep up with local document changes. Jumio acted quickly to address recognition of the new document. For me, that is an important part of the relationship: knowing that the provider can respond when something changes in the market where our clients operate.
Where the automatic tool cannot complete identity verification, our KYC and Risk Managed Services team can review the documentation manually and enter the relevant information into the back office. That last step matters. Reviewing a document and capturing the information needed for the ongoing relationship and reporting are both part of completing the process.
Screening and fraud detection also need attention beyond the initial integration. It is important to understand what risk signals the tool provides and who will investigate a possible match. Adverse media can be relevant to an AML assessment, but a name match is not, by itself, evidence that the player has done something wrong.
When comparing suppliers, I would ask which tools they use for ID verification and PEP, sanctions and adverse-media screening, whether they support Alberta’s current documents, and what happens when the automatic checks cannot be completed. Who reviews the documentation, who captures the missing data and who deals with unresolved screening concerns?
Risk assessment has to follow the customer relationship
We use ComplyRadar to monitor information from player registration, financial transactions and wagering on a continuous basis. One of its main uses is customer AML risk assessment, starting at the beginning of the relationship. In Ontario, that assessment is supported by the risk matrix issued by iGaming Ontario.
The benefit of an automated, ongoing assessment is that it can take account of information we did not have when the player first registered. As activity develops, the risk profile may change. Our AML Managed Services team can then investigate the cases that need closer attention, including requesting source-of-funds or source-of-wealth documentation where appropriate.
The monitoring goes down to individual wagers and casino spins. That detail also helps with Responsible Gambling, where a change towards more intensive play may indicate a need to review the account and contact the player. It does not tell us that someone has a gambling disorder. It gives the team information to assess alongside the rest of what it knows about that customer.
I would ask a supplier whether its customer risk assessment is automated from the start and updated as new information arrives, whether monitoring covers individual wagers and spins, and who investigates the resulting alerts. If an operator needs support with those investigations, it should also establish whether the supplier can provide the AML specialists, rather than just the monitoring tool.
The people behind the Responsible Gambling service
However useful transaction monitoring and internal reports are, they cannot replace the judgment of experienced customer protection agents. That is what we call the people on our Responsible Gambling team. They review customer interactions, support other departments and provide an immediate escalation point when someone is concerned about a player.
A player may appear to be venting frustration about a losing bet or the wagering requirements of a promotion. Sometimes there is more behind the comments, and recognizing that requires experience. Our Responsible Gambling Managed Services team, which supports operators in Ontario and Alberta, has worked with local police in cases where concerns about possible self-harm required escalation. These are serious situations, and they are a reminder of the responsibility involved in handling a customer conversation properly.
For an operator entering the market, having access to an established team can reduce the work of recruiting, training and supervising specialists from scratch. It does not transfer the operator’s responsibility to the supplier, but it can provide practical support with carrying it out.
TitanPlay, which uses Delasport technology and is powered by our managed services, achieved RG Check accreditation on its first attempt. I see that as a useful example of the technology, procedures and people working together in an actual operation.
This is why I would ask a supplier quite directly whether it provides experienced customer protection agents, whether other teams can escalate concerning interactions to them immediately, and how interactions and resulting actions are recorded for oversight and reporting. Having the monitoring tool does not answer those questions.
Some integrations carried across more easily
It would be wrong to suggest that everything we had done in Ontario needed rebuilding. Geolocation was one area where the existing implementation was genuinely useful. We work with Xpoint, and its established footprint allowed us to extend our Ontario implementation to Alberta relatively easily, with the necessary jurisdiction-specific configuration.
That is part of the value of having worked through both markets: being able to distinguish what can be reused from what needs a separate implementation, rather than assuming that all the work will fall into one category.
With sportsbetting integrity, the question is also about what comes with the sportsbook. In our case, integrity monitoring is included. Our sportsbetting risk managers, commonly called traders, review the event offering for integrity concerns as well as managing the odds. Those responsibilities sit alongside each other, but reviewing the integrity of an event is not the same as managing the commercial risk of the bets taken on it.
The traders work with Integrity Compliance 360, or IC360, and the relationship goes both ways. The monitor may alert us to concerns it has identified through information gathered across the industry. It also asks for information from individual operations to support further analysis. Our traders contribute findings and respond to those requests; they are not simply reading notifications from a dashboard.
An operator should therefore establish whether geolocation is already configured and operating for Alberta, and whether its sportsbook service includes both an integrity-monitoring tool and a team that investigates alerts and responds to information requests. Otherwise, it needs to understand what it must arrange separately.
What I would want to understand before choosing a supplier
Having been through these implementations, I would spend less time on a general assurance that a platform is compliant and more time looking at how particular requirements have been addressed. Can the supplier demonstrate the Alberta reporting integration? How are exclusion and marketing-suppression results applied? What happens when identity verification or a risk alert needs a person to investigate?
At Delasport, we have brought those elements together within a full turnkey solution, including the Player Account Management system, sportsbook, integrated compliance tools and the option of specialist managed services. We have successfully launched in both Ontario and Alberta, but getting there involved detailed work with our operator partners. The similarities between the frameworks helped us in some areas; the differences required us to develop and adapt others.
The appropriate level of managed support will depend on the operator. An experienced team may want to run more of the processes itself. Another may need help with KYC, AML or Responsible Gambling operations. In either case, it is worth being clear about what the technology does automatically, what the supplier’s people do and what remains with the operator.
My advice would be to work through those questions with the people who will actually deliver the service. Ask to see the interfaces and processes, including how information moves between teams. That should give you a much better understanding of whether the supplier has already worked through the details of Alberta, and what partnering with it will involve after launch.
