In the article entitled “International Gaming Standards Association (IGSA) Discusses G2S” posted on June 10th, we described what a standard is and how IGSA has been developing them for over twenty-two years.  Using specific use cases, the article described how the Game To System (G2S) communication protocol can assist Regulatory Authorities as they continue to provide oversight for all types of gaming activity.  It also pointed out that there were two other IGSA standards that were developed specifically with Regulatory Authorities in mind.  Those are the Certification Database Interface (CDI) and the Regulatory Reporting Interface (RRI).

This CDI standard was born from within the IGSA’s Regulatory Committee.  This committee is open only to members of Regulatory Authorities.  It is free to join, and provides a trusted forum where members can openly discuss common issues and brainstorm on potential solutions.  Anything said within the committee is kept in strict confidence within that committee.  Meeting roughly monthly, the Regulatory Committee is facilitated by IGSA’s Executive Director, who shares information with the broader IGSA to address questions or issues raised, only when authorized by the committee.

Regulators within the committee identified three main issues related to the gaming submission, testing and approval process to Independent Third-party Laboratories (ITL).

1. There was no easy way for Regulators to learn about products submitted to ITLs or the status of the testing;
2. There was no standard report format for test results;
3. There was no standardized method for communicating regulatory approval information.

The Regulatory Committee asked IGSA for input on potential solution.  The problem involved three main actors; Suppliers, ITLs and Regulators. Since a solution would require interfaces between systems owned by each of those actors, the IGSA System To System (S2S) Committee took on the task of finding a solution.  S2S is a communication standard designed to allow systems to connect and share information with other systems.  For example, S2S is used between Ticket Redemption Kiosk systems and Casino Management Systems and between Class II gaming systems on a casino floor, for cross gaming device ticket redemption.

The S2S committee designed a simple communication interface using the computer industry standard secure HTTP (hypertext transfer protocol) communication language. This was developed with input from, and is supported by, both the BMM and Gaming Laboratories International (GLI) ITLs.

CDI uses four actions or verbs:

1. Post– allows an actor to submit a request on a target system;
2. Put– allows an actor to put information, such as files, reports, etc., on a target system;
3. Get– allows an actor to retrieve information from another system; and
4. Delete– allows an authorized actor to delete information about a submission from a target system.

CDI allows suppliers to post product submissions to the ITL’s system.  Once the product submission is accepted, the ITL can obtain the required files and documents from URLs supplied in the posted request.

As testing begins, the supplier can get status updates on the testing being conducted.  If changes are needed to address bugs found, the supplier can put those changes on the ITL’s system.

Regulators can also get information on the products submitted to an ITL.  They can get information on the product, status of testing, and potentially issues found, on a specific product or all products submitted.

When testing for a product has been completed, Regulators can get the final test results, evaluate them and then, based on the process in the jurisdiction, either put their approval of the product on the ITL’s system, or get the approval from the ITL’s system.

The post, put, get and delete actions are intended to be used between a Client System and a Host System.  Depending on the nature of the transaction, any one of the actors’ systems can act as either the Client or Host system.

For example, a supplier posts a product testing submission to an ITL.  In this case, the supplier’s system would play the Client System role – sending the request – and the ITL’s system would play the Host System role – receiving, validating and accepting the request.

In another example, a Regulator wishes to get information about a product from a supplier.  In this case, the regulator’s system would play the Client System role – sending the request for information – and the supplier’s system would play the Host System role – receiving the request and sending back the required information.

CDI solves the issues identified by the Regulatory Committee by providing Regulators the functionality requested.

• Full transparent access to information about all products submitted to the ITL’s for regulatory testing;
• Ability to get data on submitted testing status, if it was in progress, and current testing results; and
• Standardization of the final test results and approval recommendation reports so that they are identical across ITLs.

It also provides a means to eliminate paper-based product submissions and approval letters, which expedites the process and creates operational efficiencies.  These benefits can also be applied to two other regulatory related processes – the Work Order and Approval to Ship requests, by introducing a fourth actor, the operator.

Work Orders are requests that a supplier or operator has to submit to a Regulatory Authority to perform certain actions with gaming products, such as moving a product from one location to another, changing the configuration of a product, or converting a product.  This process can be streamlined through the use of CDI.  Approval to Ship requests are generated by suppliers and sent to Regulatory Authorities seeking approval to ship gaming equipment into a jurisdiction.

In both processes, a request is sent by the supplier or operator to the regulator who then sends a response back.  That response may be an approval, a denial, or a request for additional information, which subsequently may result in an approval or denial of the request.

Using the same post, put, and get verbs, the supplier or operator can post a request to the regulatory system, put any additional information required and then get the status of the request.  Similarly, a regulator can get information on, or a status of, the request from the supplier or operator.

In the US, CDI is being used by the Ohio Casino Control Commission and has proven to deliver the desired benefits and address the Regulatory Committee identified issues.

More information on CDI can be found on the IGSA website.

Please contact IGSA for specific questions.

Mark Pace

Managing Director / International Gaming Standards Association Europe