Compliance is, unfortunately, not a set-it-and-forget-it affair. It isn’t something to be reactionary about either. Odds On Compliance Technical Director Michael Mignone discusses the importance of how to handle those changes and the importance of change management, its impact on the iGaming industry, the variance between markets, and the importance of correct implementation.
Change management in the United States is probably one of the most overlooked areas of development for sports betting and iCasino companies looking to launch in the U.S. However, ignoring change management can lead to severe delays in pushing out updates and can result in starting your relationship with the regulator on the wrong foot. The requirements surrounding change management can and do vary from market to market in terms of the classification of changes, what documentation needs to be retained, what changes constitute a need for additional lab testing, and what procedures must be followed for submission/approval of release notes. However, a decent amount of overlap will allow you to implement a change management protocol internally to help get release notes approved on time and stay on good terms with the regulator. This article will discuss, at a high level, when this plan should be developed, when it needs to be implemented, and some common overlaps that can assist in its design.
When does change management start?
Let’s assume your mobile apps, website, back-end, and third-party integrations are ready to go, you have your lab certification, and you are ready to go live in the US market. At this point, you are on the cusp of putting your change management plan into action, but until you are live, you should consider your platform frozen for all intents and purposes. When you receive your lab certification report, there will be a list of components on the report with a corresponding signature; these are your controlled or tracked components. Most markets want to see that the signatures for these components match what is listed on the certification report before you get the “go-ahead” to start accepting wagers. It is precisely after this validation that your change management plan is now in motion. Any planned changes will have to be evaluated against your plan to determine the action needed to move forward.
Market similarities
As previously mentioned, there will be a decent amount of variance between markets, but there will also be overlaps and similarities. Most markets require that all changes be recorded into a change log as well as any controlled components that were affected and the old/new signatures for those components as a result of the change. The most common similarity between markets is the three-level classification system for changes, which starts at 1 (lowest level) and increases to 3 (highest level). Changes that don’t affect the signature of a controlled component can usually be classified as the lowest tier, Level 1. Usually, these changes can be done without regulator approval. Still, some will require that they be documented in a change log, which you will submit at the specified time interval (usually quarterly).
If a change alters the signature for a controlled component, that change can almost always be classified as a Level 2 or 3. Some markets require approval of Levels 2 and 3, while others only want to be alerted of Level 2s and require approval for Level 3s. Each market varies on the classification definitions, so it is important to review each change and assign the correct level for that market.
Every US market has a carve-out for emergency changes. These are changes that can be made immediately, with notification of the change occurring directly before or after the change (depending on the market). These are usually items where the platform can’t function correctly without the update, correcting a non-compliance that has arisen or is necessary for platform security. The change manager and technical compliance team should always discuss these to ensure it fits the target market’s classification for an emergency change and to prepare for any additional scrutiny that might follow from the regulator. Some markets will require an incident report describing what happened, why it happened, how it was fixed, and internal changes to ensure it will not happen moving forward.
Plan development
Developing your plan/policies/procedures for change management should begin well before you plan to submit it to the lab for testing. As you get closer to your go-live, last-minute fires tend to happen and require a significant amount of work hours to address so your target go-live date is met. This means things like your change management plan should be ready to go prior to your lab submission. Change management development should focus on a few key areas:
Leveraging your internal systems
All companies use some form of issue/bug tracking software to plan releases, assign development work and track progress. These systems can be leveraged to export your release notes with some minor updates to the fields included within the tickets. Subsequently, what controlled component versions are running in each market (typically outside of the issue/bug tracking system) is something that will also need to be developed. Knowing the current versions of these components in each market and the signature history is something that is needed in most markets as part of their change management directives/requirements.
Training your personnel
With your internal systems now exporting release notes and controlled components being altered (with signatures), it’s important to train your change manager AND your development team on the following items:
⦁ How your systems are being used to get releases approved,
⦁ How to classify each change in different markets,
⦁ The lead time required for release note approval in each market, and
⦁ What information needs to be shared with the regulator.
Ensuring accuracy
Getting accurate and complete information in your release notes, as well as the proper change classifications will reduce the amount of questions/pushback you can expect from regulatory bodies. For example, if your target market for release ‘X’ doesn’t require approval for level 1 changes and they are misclassified (or classified correctly but sent for approval), this turns what could be a twenty-change review for the regulator into possibly hundreds. This also holds up your change manager, giving them more to review before they can send it over to the regulator and subsequently making the regulator’s review take longer, getting more questions back and likely missing your targeted release date. In addition, clear and concise change descriptions should always be used for the release notes, not your developers’ comments field from the change ticket. Your change manager should always review the release notes with the question in mind: “can someone completely unfamiliar with our platform understand what this is changing?”
Knowing and documenting your lead time
Lead time on release notes will vary from market to market, from three days to five days to ten days. A good strategy is to determine what is the longest lead time required in the markets you are currently live in and make that your default release timeframe. If five days is the longest, send your release notes to all markets getting the update five days in advance. In the event that the regulator with the shorter lead time has questions on the changes, you will have a head start on resolving them for regulator #2, before your release date, meaning you won’t be scrambling to get information gathered and a response issued to the regulator before they leave for the day, the night before you plan on pushing the update out.
Implementing these steps for a thorough change management process can help keep your launch plans running smoothly, and your relationships with regulatory bodies in good standing. The team at Odds On Compliance is here to assist with getting your change management plan ready to go.
