Abstract

Historically the company applied this technology in the health and banking sectors. Then about a year ago, Tekkorp made an investment into IXUP for the specific purpose of building a regulated gaming application with the technology.
Banking and health care sectors are both highly regulated markets, so it made sense to steer the tech toward a new vertical like regulated wagering. I learned about the company from Tekkorp's Matt Davey, and then shortly after assembled a team experienced in regulated gaming, and that team started meeting with regulators, sports leagues and operators regarding our initial thoughts and hypothesis.
The first use-case we wanted to tackle was voluntary and involuntary exclusion management. That was an area where we felt inefficiencies in data collaboration existed due to an inability to distribute and share sensitive PII (personally identifiable information) data.
The first problem we now believe we're solving, on the self-exclusion side, is aggregation and optimization. From a state's viewpoint, the gaming authority is typically designed to be an enforcement agency, versus a private industry software development firm. When the U.S. first went online in 2013, companies like GeoComply and LexisNexis were already in place to provide geolocation and KYC (know your customer) services. However, there was no vendor in place to provide exclusion management services. Each state was forced to build their own in-house solution. That created a situation where every operator, if they're in multiple states across the U.S., must do 30 to 40 bespoke integrations with all of these different self-exclusion systems.
And as you can imagine, these systems vary in levels of technical sophistication. Some are sending plain text as part of a CSV file attached to an email. Others have built more sophisticated API (application programming interface) systems, but still inadvertently share plain text competitive patron data. It starts to become cumbersome and piecemeal as operators attempt to manage all of this for each state, while simultaneously planning for how they will handle the emerging topic of sports league involuntary exclusion lists.
Many leagues entered into official league data deals with the likes of Sportradar, Betgenius, and Endeavor because the leagues received lucrative payments for doing so. But a natural byproduct of this was that the leagues were able to avoid the massive undertaking required to build and operate a regulated data dissemination system required to deliver that data to every single operator in every single jurisdiction. As there was no one to provide that data service on the involuntary exclusion side, much like the states before them, the leagues were forced to start building in-house solutions.
One problem that arose was that the leagues could only share publicly available data, meaning first name, last name, date of birth. This is data that can be found on any website roster. In reality, first name is not a very reliable form of data when trying to conduct a matching operation, which means you're now relying upon last name and date of birth. Unfortunately, this limited data causes too many false positives when operators apply that to their patron matching logic. The stats I often use are there are a little under 200 million Americans between the ages of 21 and 65 today. That equates to about 16,500 possible dates of birth for anyone who's between the age of 21 and 65 today, meaning they share their date of birth without about 12,000 other Americans. If you look at the most popular American names, like “Smith”, there's about 1.5 million “Smiths” in America between the ages of 21 and 65. That means every “Smith” shares their date of birth with just under 100 other “Smiths”. When you then look at the “Smiths” that exist in all the leagues, minor leagues, front offices, officials, across men's pro sports, collegiate sports, women's pro sports etc., it starts to add up. Meaning you could have tens of thousands of “Smiths” who match as a false positive, and that's just one last name.
If a league sends you a list that only contains a last name and date of birth, that's not going to be very helpful to you. Therefore, operators cannot automate actions to suspend patron accounts preemptively. This is because they cannot rely upon the accuracy of the data. Operators first need to manually do research to figure out if this person is the front wheel tire changer, or perhaps, the third string quarterback on the practice squad. The challenge becomes how do we get more useful data into the hands of the stakeholders so that the leagues and the operators can collaborate more efficiently?
Ideally, that's where we step in. The product is called PlayPause®; a name and logo that we purchased from Conscious Gaming, which was originally a nonprofit organization started by Anna (Sainsbury) from GeoComply. Though we're taking a different approach from theirs, we are somewhat carrying the baton from that original concept. This past year, via Tekkorp and IXUP, we applied new capital and are now in the process of creating PlayPause LLC, which is a new North American private entity, focused on applying the IXUP technology as a gaming RegTech initiative. The goal of this product is to provide operators with a single point of integration, via a real-time API, that provides both voluntary and involuntary exclusion data from every regulated gaming state and sports league.
The exciting part is, via the IXUP encrypted fuzzy matching engine, we can now do this in a way that never reveals the underlying PII data to PlayPause®, or a network collaborator, or a malicious intruder. What we do is we encrypt the data one-way. Meaning we never receive keys to decrypt the data. Then we aggregate all of these encrypted lists into a central cloud datastore. Since we have no ability to decrypt the data, neither does a third-party who has compromised our environment. In addition to providing each “list owner” with their own unique encryption key, and not sharing any keys that permit the decryption of that data, we also utilize homomorphic encryption which helps defend against attempts to reverse engineer the encryption scheme via brute force dictionary attacks. Likewise, we give the same toolset to the operator, which they can integrate into their patron's registration and login point. The operator then pings the PlayPause® network, via the same one-way encryption API, encrypting the patron's first name, last name, date of birth and last four social digits.
Then the PlayPause® network performs matching analysis upon the encrypted datasets. Meaning, when we receive the data, from either side, it's a giant blob of encrypted gobbledygook, with no ability to access or interpret the underlying source PII. Despite the data being in this encrypted state, the IXUP tech enables PlayPause® to perform a field-by-field fuzzy match analysis whereby we can configure separate matching thresholds upon each field. If an aggregate threshold is exceeded, we can tell the operator, “We don't know who this person is, but whoever it is, League-A says do not let this person gamble upon League-A's events,” or “this state says do not let this person, whoever it is, gamble anywhere online in this state.”
To reiterate, PlayPause® does all of this without knowing the data, and honestly, we don't want to know the data because we're not looking to be the police. We're simply a B2B (business-to-business) information service to help leagues, regulators and operators collaborate to make better decisions regarding their compliance of voluntary and involuntary exclusion laws.
We've built this real-time service, in the hope that operators will integrate at the point of registration or login, so we can provide the most up-to-date and accurate exclusion profile for any person. The operator has the information, and either the league or the state has the matching information. We don't need to see it. We just need to help them collaborate by using the best data possible.
Some matching services use fields like email, mobile phone, or postal code, but because the way KYC services work, as a patron signing up with an operator, could use their childhood home, for example, that's an address associated with me. I am a real person and that's my real address, even though I haven't lived there for the last 30 or so years. That address will still pass the operator's compliant KYC process. Furthermore, I could have multiple phone numbers, I could have multiple emails, and I might not use the same address, phone or email with my employer, or on the self-exclusion list, as I do when I register with an operator.
In order to help prevent people from tricking the system, you must use information that is not easy to frequently change, such as last name, date of birth, and last four social digits. But that means you're now using more sensitive and private data. This is where PlayPause® helps because the matching does not rely upon decrypted data. If it did, even for just a millisecond, then the security is no longer infallible. An intruder can obtain both the list and the tool to decrypt it. This is what happened when the U.S. no-fly list was hacked. The intruder didn't hack the pentagon, they simply hacked the weakest link on the network, meaning the least secure airline who needed the list and the key to check the list before allowing a ticket purchase.
As the industry standards for KYC, patron registration, and self-exclusion typically involve last name, date of birth, and last four social digits, we want to bring that same trust in data to other processes so that everyone can operate more efficiently. That's key to the PlayPause® vision.
With respect to exclusion list management, ideally that's just the beginning for PlayPause®. Once we have proven to the industry that we can safely and securely match data without actually sharing the underlying data, or putting the data at risk of being compromised, then we can add other functionality. We could enable multi-party collaboration across AML (anti-money laundering) data, bonus abuse data, we could help provide access to any network data that helps operators operate more efficiently. For example, operators are often forced to lock a patron's big win to check against a “deadbeat dad” database before releasing the funds. Currently this is a tedious and manual process. With appropriate data protections in place, this could all be automated in real-time, while simultaneously improving the customer experience. Currently we're locking up the funds of the many just to catch the few.
In isolation, improvements in voluntary, or involuntary exclusion, are rarely at the top of anyone's list. Status quo is a powerful thing, and regarding sports exclusion, as states are having a difficult time enforcing a rule outside of their control, it's difficult to generate enough operator interest and inertia. This is why PlayPause® aims to combine our service across both state regulatory and sports league exclusion lists. If you're an operator who still plans to launch in many U.S. states, then you still must integrate your PAM (privileged access management) with each state's self-exclusion list. If PlayPause® can simplify that for you, plus bring you league data, hopefully that is viewed as win-win.
We're successfully building off of our Australian launch, and now aim to bring a pilot into the U.S. for the purpose of demonstrating our capabilities in the market. To start, we will have participation from a top-tier sports league and have obtained conditional permission to operate the pilot in a few states. Now we're trying to secure participation with our first significant U.S. operators. Someone who will say, “yes, I'm willing to go first. I'm willing to take a step and help prove to the industry that we can do this better.”
G2E (Global Gaming Expo) was a good week. We believe we've got some strong candidates.
After 25 years of being on the side of promoting gambling entertainment, both as a supplier and an operator, this is the first time our team finds ourselves on the compliance side of the industry. This is not like selling a PAM, or a sportsbook platform or a new slot title. I often equate it to herding cats. Every day we have to bring everyone one small step closer toward a common industry goal. Eventually we'll get it all to a point where it clicks and falls into place. But this is probably one of the more challenging things we've attempted to do in our careers. Only time will tell of course.
With respect to the state regulators, one of the things that is also challenging is that the language in each state's self-exclusion law typically allows for a lengthy dissemination period between the moment a patron informs the authority or operator, and the moment that patron is successfully blocked from all wagering across the jurisdiction. Examples of these are often 24 hours, 48 hours, five days, seven days, and in some cases even up to 30 days. These laws were written of course before technology like PlayPause® existed.
In contrast, it only takes five minutes to create an account, deposit money, and start wagering on your phone. Personally, I am a supporter of mobile wagering. Having said that, if we're going to make wagering that accessible via your phone, why can't we also have a system that works the same way for self-exclusion? If a patron goes to the lengths of identifying that they have a problem, and then overcomes the further barrier of telling authorities that they need help with that problem, I believe we as an industry should at least make the process of blocking your access to all mobile wagering as quick and easy as the process you experienced when you first started mobile wagering.
I genuinely believe most regulators and operators' heads of compliance would agree with that statement. But of course, regulators can only regulate within the language of the laws that have been handed down to them by state legislatures. Thus, another challenge is asking the operators to integrate PlayPause® at registration and login. However, in reality, that means we're asking operators to help close a time gap that legally is not out of compliance. When you're trying to fit a new feature into an already overcrowded roadmap, if the answer to “are we in compliance?” is “yes,” that can easily, and indefinitely, push that feature into the next sprint.
However, if operators eventually integrate with us at the point of registration and login, then the very minute that person is added to any list, whether that person is newly self-excluded or an athlete just moved up from a practice squad, that exclusion is now immediately available across the entire participating network.
We realize we're not going to change any laws. Instead, we're going to try and remove the technical obstacles, bring added value via more usable content, aggregation, and optimization, while making it very quick and easy to integrate with PlayPause®. That way, when we're asking those involved to help raise the bar, there is a chance they will see the value and voluntarily choose to do so.
• • •
