Casino Regulations 2013 (SA)

South Australia

Casino Regulations 2013

under the Casino Act 1997

1Short title

These regulations may be cited as the Casino Regulations 2013.

3Interpretation

In these regulations—

Act means the Casino Act 1997.

4Prescribed jurisdictions (section 40A of Act)

For the purposes of section 40A(2) of the Act, the following jurisdictions are prescribed:

1. (a)

   New South Wales;

2. (b)

   New Zealand;

3. (c)

   Queensland;

4. (d)

   Victoria.

5Approval of gaming machines and games

1. (3)

   Subject to subregulation (3a), for the purposes of section 40A(4)(b) and (6)(b)(ii) of the Act, a requirement that a gaming machine or a game to be played on a gaming machine (as the case requires) complies with the Australian/New Zealand Gaming Machine National Standard 2016 (or any subsequent version) as modified by the relevant Appendix is prescribed.

2. (3a)

   Subregulation (3) does not apply in relation to a gaming machine or a game to be played on a gaming machine (as the case requires) if—

   1. (a)

      the gaming machine or game is already approved or taken to have been approved under section 40A of the Act; and

   2. (b)

      it is not economically viable to modify the gaming machine or game to comply with the Australian/New Zealand Gaming Machine National Standard 2016 (or any subsequent version) as modified by the relevant Appendix.

3. (4)

   In this regulation—

relevant Appendix in relation to a version of the Australian/New Zealand Gaming Machine National Standard means—

1. (a)

   the latest South Australian Appendix to that version; or

2. (b)

   the latest Appendix to that version of a jurisdiction referred to in regulation 4.

7Approval of facial recognition system – prescribed requirements

For the purposes of section 40D(2) of the Act, the following requirements are prescribed in relation to an approval of a facial recognition system by the Commissioner under section 40D of the Act:

1. (a)

   the system must be capable of accurately taking account of physical variances in facial features;

2. (b)

   the system must be designed to prevent unauthorised access, use and disclosure of data collected by the system;

3. (c)

   the system must be able to be operated in accordance with—

   1. (i)

      technical requirements; and

   2. (ii)

      security requirements; and

   3. (iii)

      any other criteria,

as determined by the Commissioner.

8Requirement for pre‑commitment system

For the purposes of section 42B(1)(d) of the Act, it is a requirement that a gaming machine or automated table game equipment be operated in connection with a pre‑commitment system that is operated by the licensee in compliance with the requirements of the Voluntary Pre‑commitment Code set out in Schedule 2.

9Operation of gaming machine or automated table game equipment by insertion of a ticket – prescribed requirements

1. (1)

   For the purposes of section 42B(3)(c) of the Act, the licensee must not provide any gaming machine or automated table game equipment that may be operated by insertion of a ticket unless the machine or equipment is operated in connection with a TITO system that complies and is operated in accordance with the requirements set out in this regulation.

2. (2)

   A TITO system must comply with the requirements of, and be operated in accordance with—

   1. (a)

      until 3 December 2020—the TITO technical requirements set out in Schedule 4; and

   2. (b)

      on and after 3 December 2020—the gambling administration guidelines issued under section 17 of the Gambling Administration Act 2019.

3. (3)

   A TITO system must not issue a ticket containing any form of promotional material or advertising.

4. (4)

   A TITO system must not allow a gaming machine to be operated by insertion of a ticket if the cash value of the ticket, when redeemed, exceeds $149.99.

5. (5)

   A TITO system may only issue a ticket with a credit value that is more than $5 000 if the issue of the ticket is manually enabled by a person authorised for that purpose by the licensee.

6. (6)

   The licensee must not allow a person to redeem the credit value of a ticket after 12 months from the date of issue of the ticket (after which time the ticket will be taken to have expired).

7. (7)

   In this regulation—

TITO system means a system that enables the insertion and issue of tickets that may be redeemed for credit or cash value for the purpose of play on a gaming machine or automated table game equipment.

10Operation of facial recognition system – prescribed requirements

1. (1)

   For the purposes of section 42D(1) of the Act, it is a requirement that data collected by an approved facial recognition system must not be used for or in connection with the following:

   1. (a)

      encouraging or providing incentives to a person to gamble;

   2. (b)

      customer loyalty programs;

   3. (c)

      a lottery within the meaning of the Lottery and Gaming Act 1936 or the Lotteries Act 2019;

   4. (d)

      identifying a barred person in respect of premises other than the casino premises;

   5. (e)

      any other purpose notified by the Commissioner to the system provider or licensee.

2. (2)

   For the purposes of section 42D(2) of the Act, the following requirements are prescribed in relation to the recording of a person's facial image by means of an approved facial recognition system:

   1. (a)

      the licensee must, by notice displayed at each entrance to the casino premises, in a manner and form approved by the Commissioner, notify each person who is about to enter the casino premises that a record of the person's facial image will be made by means of the approved facial recognition system;

   2. (b)

      the facial image of a person or any data recorded by the approved facial recognition system that identifies a person (other than a barred person), must not be retained by the licensee or on any system operated on or on behalf of the licensee after 72 hours of being recorded by the system.

Schedule 2—Voluntary Pre‑commitment Code

 

Registration

1.

The licensee must permit a customer who wishes to do so to register with the pre‑commitment system by—

1. 1.1

   completing an application in writing at the casino premises; or

2. 1.2

   making a request in person to casino staff; or

3. 1.3

   completing a form on a website available generally on the Internet.

2.

The licensee must not only offer pre‑commitment in conjunction with a loyalty system.

3.

The licensee must provide a customer who applies for registration with the following information, in writing, regarding the terms and conditions of registration with the pre‑commitment system:

1. 3.1

   the process by which a registered customer may vary his or her expenditure limits and other details, and how and when the variation will apply;

2. 3.2

   privacy protections for the registered customer;

3. 3.3

   the application of a default daily expenditure limit if the registered customer does not specify his or her own expenditure limit;

4. 3.4

   the consequences if the registered customer exceeds an expenditure limit or fails to comply with a break in play period or no play period, in particular—

   1. 3.4.1

      that the pre‑commitment system will monitor the customer's play data to enable a reminder message to be sent to the customer; and

   2. 3.4.2

      that the pre‑commitment system will notify casino staff when a registered customer exceeds his or her expenditure limit or fails to comply with a break in play period or no play period.

4.

The licensee must obtain the customer's consent to the terms and conditions before registering a customer.

5.

The licensee must record on the pre‑commitment system a registered customer's preferred—

1. 5.1

   language for use on the pre‑commitment system (the preferred language); and

2. 5.2

   method of communication (post, email, SMS or in‑venue communication (the preferred communication method)).

Setting and varying limits

6.

The pre‑commitment system must allow a registered customer to—

1. 6.1

   set the following:

   1. 6.1.1

      a daily or weekly expenditure limit (eg $50 per day);

   2. 6.1.2

      break in play periods (eg a 5 minute break every hour);

   3. 6.1.3

      no play periods (eg pay or pension day, the hours when children are picked up from school);

   4. 6.1.4

      a personal reminder message to be displayed at the gaming machine or automated table game when the customer exceeds his or her expenditure limit or fails to comply with a break in play period or no play period; and

2. 6.2

   vary any matter referred to in item 6.1 by completing an application, in writing, at the casino premises, online, at an automated kiosk or by making a request, in person, to casino staff.

7.

If a registered customer does not specify an expenditure limit, the pre‑commitment system must set a default daily expenditure limit of $100 per day.

8.

The pre‑commitment system must apply any variations referred to in item 6.2 as follows:

1. 8.1

   a variation must be applied as soon as practicable if the customer has not played a gaming machine or automated table game since registering;

2. 8.2

   a variation (other than a variation to increase an expenditure limit) must be applied as soon as practicable if the customer has played a gaming machine or automated table game since registering;

3. 8.3

   if the customer has played a gaming machine or automated table game since registering and the requested variation is to increase an expenditure limit, the variation must only be applied if—

   1. 8.3.1

      a period of 24 hours has passed since the making of the request; and

   2. 8.3.2

      the customer has confirmed to the licensee (in person or by any other means) that he or she still requires the making of the variation.

9.

Once a varied expenditure limit is applied by the pre‑commitment system, any previous expenditure limit set by the registered customer has no effect.

Operation of the pre‑commitment system

10.

The pre‑commitment system must comply with the following requirements:

1. 10.1

   the system must use the registered customer's preferred language, if available, but may use English until the data about customer preferences is analysed to identify a minimum set of common languages to be offered by the system;

2. 10.2

   the system must be capable of displaying on‑screen messages on a primary screen or an ancillary screen;

3. 10.3

   the system must enable the display of a reminder message set by the licensee on the primary screen or the ancillary screen when the registered customer reaches 50%, 75% and 90% of his or her expenditure limit;

4. 10.4

   if a registered customer exceeds his or her expenditure limit, the system must enable the display of the customer's personal reminder message (or, if the customer has not set a reminder message, a default message set by the licensee) on the primary screen or the ancillary screen;

5. 10.5

   if the registered customer continues to play after exceeding his or her expenditure limit, the system must enable a further reminder message to be displayed on the primary screen or the ancillary screen when the customer exceeds his or her expenditure limit by 10%, 20% and 50%;

6. 10.6

   the system must notify casino staff when the registered customer exceeds his or her expenditure limit or fails to comply with a break in play period or no play period;

7. 10.7

   if a registered customer fails to comply with a break in play period or a no play period, the system must enable the display of the customer's personal reminder message (or, if the customer has not set a reminder message, a default message set by the licensee) on the primary screen or the ancillary screen;

8. 10.8

   if a reminder message is displayed on a primary screen, the system must not allow the message to be removed from the display until the registered customer acknowledges the message;

9. 10.9

   if a reminder message is displayed on an ancillary screen, the system must not allow a registered customer to continue play until the customer acknowledges the message.

11.

For the purposes of item 10—

primary screen means a gaming machine or automated table game screen;

ancillary screen means a screen measuring not less than 14 cm in width and 5 cm in height that is—

1. (a)

   in the sandwich board of a gaming machine; or

2. (b)

   attached to a gaming machine or automated table game equipment and visible to the registered customer during play.

12.

The registered customer's pre‑commitment data must be usable on the same system if that system is available on another gaming machine or automated table game (whether the machine is in the same or a different venue).

Communication

13.

The licensee must communicate with a registered customer by the preferred communication method.

14.

The licensee must, every 6 months, request by the registered customer's preferred communication method, that the customer confirm or vary his or her expenditure limit.

15.

The licensee must provide the registered customer with a periodic activity statement every 6 months by the customer's preferred communication method. This requirement only applies if the registered customer has played a gaming machine or automated table game in the last 6 months using the pre‑commitment system.

16.

The pre‑commitment system must allow the registered customer to access an on‑demand activity statement for the current session of play, the previous month of play or any period up to the previous 6 months of play. The registered customer may request an on‑demand activity statement from venue staff, online or at an automated kiosk.

17.

The following information must be provided in a periodic and an on‑demand activity statement:

1. 17.1

   the period of the statement;

2. 17.2

   the total amount spent during that period;

3. 17.3

   each amount won and lost during that period;

4. 17.4

   the net amount won or lost during that period;

5. 17.5

   the current expenditure limit;

6. 17.6

   the number of times the registered customer exceeded his or her expenditure limit during that period.

18.

The periodic activity statement and on‑demand activity statement must be in the registered customer's preferred language, if available.

Miscellaneous

19.

The licensee must, on the request of the Commissioner, provide to the Commissioner de‑identified information recorded by the pre‑commitment system to be used for gambling research.

Schedule 3—Savings and transitional provisions

1—Approval of gaming machines and automated table game equipment intended to operate a TITO system

1. (1)

   For the purposes of section 40A(3)(b) and (4)(b) of the Act, a requirement that—

   1. (a)

      any gaming machine that is intended to be operated in connection with a TITO system; or

   2. (b)

      any automated table game equipment that is intended to be operated in connection with a TITO system,

must be able to be operated in accordance with the TITO technical requirements set out in Schedule 4 is, until 3 December 2020, prescribed.

1. (2)

   In this clause—

TITO system means a system that enables the insertion and issue of tickets that may be redeemed for credit or cash value for the purpose of play on a gaming machine or automated table game equipment.

2—Approval of facial recognition system

1. (1)

   For the purposes of section 40D(2) of the Act, a requirement that a facial recognition system must be capable of operating in accordance with the notified facial recognition system requirements is, until 3 December 2020, prescribed.

2. (2)

   In this clause—

notified facial recognition system requirements means any requirements notified by the Commissioner on a publicly available website determined by the Commissioner for the purposes of this clause.

3—Right of review

1. (1)

   Despite the repeal of Part 8 of the Act, until the relevant day, the licensee continues to have the right to apply to the Licensing Court of South Australia for a review of a prescribed decision (in accordance with the provisions of that Part as in force immediately before its repeal).

2. (2)

   In this clause—

prescribed decision means a decision of the Commissioner under the Gambling Administration Act 2019 that is not subject to review on an application under section 54(1) of that Act;

relevant day means a day determined by the Minister by notice in the Gazette for the purposes of this clause.

Schedule 4—TITO technical requirements

 

1.

Interpretation

In these requirements, unless the contrary intention appears—

TITO enabled device means a device such as a gaming machine, automated table game, cash redemption terminal or cashier terminal which is configured to issue tickets or accept tickets for redemption, or both;

TITO host means the core back‑end servers and database of the TITO system;

TITO peripheral means hardware by which a TITO enabled device conducts a TITO transaction;

TITO system means the entire TITO system including TITO enabled devices and the TITO host.

2.

TITO ticket requirement

Tickets must comply with the following requirements:

1. 2.1

   the following information must be printed on the tickets:

   1. 2.1.1

      a heading that uniquely identifies the ticket for TITO purposes (eg. the words "CASH OUT TICKET");

   2. 2.1.2

      venue information regarding where the ticket was printed (eg. venue and venue name details);

   3. 2.1.3

      information identifying the TITO enabled device which issued the ticket;

   4. 2.1.4

      a 16 or 18 digit number (a unique ticket identifier) in—

      1. 2.1.4.1

         a readable format in at least 2 places on the ticket; and

      2. 2.1.4.2

         in a machine readable format such as a barcode;

   5. 2.1.5

      the date and time that the ticket is printed;

   6. 2.1.6

      the value of the ticket expressed in dollars and cents;

2. 2.2

   tickets must include space for a responsible gambling message, either printed by the issuing TITO enabled device or pre‑printed on the ticket (it is acceptable to print this message on the front or rear face of the ticket);

3. 2.3

   tickets may contain location information of the TITO enabled device which issued the ticket (eg. house or bank number);

4. 2.4

   tickets must be designed to be durable for their expected life span and provide clear legibility of text when the ticket is printed;

5. 2.5

   if the ticket is vulnerable to environmental conditions, the ticket should include applicable storage and handling instructions on either the rear or the face of the ticket (eg. do not store in direct sunlight);

6. 2.6

   tickets must not contain any form of promotional or advertising information.

3.

General TITO requirements

1. 3.1

   TITO peripherals must be integrated into and be controlled by a TITO enabled device which is able to—

   1. 3.1.1

      enable or disable the activity of the TITO peripheral at appropriate times (eg. when credits are being accepted or paid out by the TITO enabled device); and

   2. 3.1.2

      manage and diagnose faults and the status of any faults in the TITO peripheral.

2. 3.2

   The installation of a TITO peripheral in a TITO enabled device must not void the regulatory compliance of the TITO enabled device into which it is installed.

3. 3.3

   It must be possible to enable or disable TITO functionality on a TITO enabled device.

4. 3.4

   TITO systems must use an approved communication protocol to communicate with TITO enabled devices which must—

   1. 3.4.1

      implement a means of error checking; and

   2. 3.4.2

      implement a 2 way handshaking process between the initiating TITO enabled device and the TITO host for the redemption of tickets; and

   3. 3.4.3

      be robust and able to handle incomplete, misrouted, duplicated, altered in transit or unauthorised TITO transactions.

5. 3.5

   TITO peripherals such as ticket printers and ticket acceptors must be installed safely and securely to prevent injuries to patrons or attendants using the TITO enabled device.

6. 3.6

   TITO enabled devices must automatically abort a ticket in or a ticket out transaction if connection to the TITO host is detected as lost.

7. 3.7

   TITO operation across a TITO system must be transaction based.

8. 3.8

   TITO systems must use a database or similar managed information system for the storage of TITO data.

9. 3.9

   Each TITO transaction on the TITO system must—

   1. 3.9.1

      be allocated a unique sequence number; and

   2. 3.9.2

      have a time‑date stamp.

10. 3.10

    TITO enabled devices and the TITO system must be configured to ensure synchronicity of time‑date data used to time‑date stamp TITO transactions.

11. 3.11

    TITO enabled devices should not allow TITO operation until they have time‑date synchronised with the TITO system.

12. 3.12

    TITO systems may have—

    1. 3.12.1

       a configurable maximum ticket out limit restricting the cash value of tickets that TITO enabled devices can issue;

    2. 3.12.2

       a configurable maximum ticket in limit where tickets having a cash value in excess of the maximum ticket in limit are rejected;

3.12.3 a configurable minimum ticket out limit which defines the minimum cash value of tickets that can be issued by particular TITO enabled devices; 3.12.4 a configurable maximum credit limit restricting a TITO enabled device from redeeming a ticket if it would cause the credit meter to exceed this value. 3.13 Tickets that have a cash value in excess of the prescribed maximum ticket in limit may be redeemed at a cashier terminal or cash redemption terminal. 3.14 TITO systems— 3.14.1 must have a configurable ticket expiry time which defines the period of time from the time of the ticket issue to the time that tickets may be redeemed by the TITO system before they are considered void; and 3.14.2 may have an additional configurable ticket floor expiry time which defines the period of time from the time of ticket issue to the time that tickets may be redeemed by a gaming machine or an automated table game. 3.15 TITO enabled devices which issue or accept tickets on the TITO system must provide accurate and accountable logging for tickets printed, accepted and rejected. 3.16 Gaming machine based TITO enabled devices must comply with— 3.16.1 the applicable technical requirements defined under the current Australian/New Zealand Gaming Machine National Standards and other applicable technical standards; and 3.16.2 the applicable technical requirements of the communication protocol used for TITO operation; and 3.16.3 the applicable technical requirements for ticket in ticket out as listed in the South Australian Appendix to the Australian/New Zealand Gaming Machine National Standard. 3.17 TITO enabled devices must be able to recover when printing of a ticket fails or is interrupted by a fault.
4.	Ticket in process 4.1 Credits must only be registered for valid tickets. 4.2 Tickets may only be accepted when the TITO enabled device is in an active state and able to receive and credit tickets. 4.3 If the TITO enabled device is active then a ticket may be inserted at any time in accordance with the applicable requirements for insertion in the Australian/New Zealand Gaming Machine National Standards. 4.4 TITO enabled devices must automatically reject inserted tickets when it can detect that the connection to the TITO host is down. 4.5 The TITO system must verify the unique ticket identifier printed on the ticket, and if valid, request and wait for authorisation from the TITO host for the ticket. 4.6 A TITO enabled device must only redeem valid tickets that have been authenticated by the TITO host. 4.7 If a TITO enabled device is not able to receive and process tickets, the inserted ticket must be ejected back to the player. 4.8 If an inserted ticket is detected as invalid by a TITO enabled device then the ticket must be ejected back to the player. 4.9 A TITO enabled device must not accept another ticket until the current ticket in transaction has been completed (ie. either approved or rejected). 4.10 A TITO enabled device must be able to notify the TITO system if an error occurs during the ticket in validation process (eg. a timeout, ticket jam, or other fault). 4.11 Where possible, TITO enabled devices must have ability to hold a ticket in escrow if the TITO host requests additional time to authenticate the ticket. TITO enabled devices that are not able to hold a ticket in escrow may eject the inserted ticket back to the player if requested to hold the ticket in escrow. 4.12 If the ticket is approved by the TITO host, the TITO enabled device must retain the ticket and add the cash amount of the inserted ticket to the credit meter (or equivalent) of the TITO enabled device, and notify the TITO system of the applicable ticket in meter and status updates. 4.13 TITO enabled devices must provide visual or audio feedback to players that the ticket has been accepted and redeemed. 4.14 A ticket in transaction is considered complete when the TITO host has authorised the ticket in request from the TITO enabled device, TITO meters are successfully transmitted to the TITO host, and ticket stacking by the TITO enabled device is complete. 4.15 The TITO enabled device must have a method to display a clear and legible message with the reason for a rejected ticket for a reasonable period of time. 4.16 The TITO system must support the provision of at least the following reasons for rejection: 4.16.1 ticket system unavailable; 4.16.2 ticket expired or too old; 4.16.3 ticket amount too large; 4.16.4 ticket invalid; 4.16.5 ticket not found; 4.16.6 ticket already redeemed; 4.16.7 other reason—see operator. 4.17 If the TITO enabled device is not able to read the unique ticket identifier on the ticket prior to being interrupted, the TITO enabled device must eject the ticket back to the patron. 4.18 The TITO system must ensure that tickets can only be redeemed once. 4.19 TITO enabled devices that can accept and redeem tickets must maintain a log of the last 35 accepted or rejected tickets that must include at least the following details for each record: 4.19.1 time and date; 4.19.2 amount; 4.19.3 unique ticket identifier; 4.19.4 whether the ticket was accepted or rejected.
5.	Ticket out process 5.1 The functionality of ticket out is equivalent to a player pressing collect and collecting credits from a gaming machine. The TITO enabled device will exchange with the system a unique ticket identifier and ticket information which the TITO system will retain and use in the future for ticket redemption. 5.2 Tickets issued by TITO enabled devices must have a unique ticket identifier which is used by the TITO system to uniquely identify tickets. 5.3 The TITO host must be able to cater for the scenario when multiple TITO enabled devices create identical unique ticket identifiers. 5.4 A ticket can be redeemed for cash or inserted into a TITO enabled device with ticket acceptance, in order to transfer the cash value of the ticket to the credit meter (or equivalent) of the TITO enabled device. 5.5 A ticket is printed by the TITO enabled device when a player presses collect or similar on the TITO enabled device subject to any TITO limits for printed tickets. 5.6 A TITO enabled device must not print a ticket with a cash value that exceeds the configured maximum ticket out limit, if such a limit is supported. 5.7 A TITO enabled device must wait for attendant authorisation before printing a ticket with a cash value that exceeds the configured ticket out authorisation limit, if this limit is supported. 5.8 TITO enabled devices must provide feedback or messages to players while a ticket is being printed and issued (eg. "Printing ticket...please wait" during printing and "Please collect your ticket" when printing is complete). 5.9 A ticket out transaction is considered complete when the ticket has been printed and ticket meters and ticket information are successfully transmitted to the TITO system. 5.10 A ticket must only be printed out when the TITO enabled device is actively connected to the TITO system. 5.11 TITO enabled devices must be able to notify the TITO system of faults if they occur and interrupt the ticket out process. 5.12 TITO enabled devices must be able to resume and recover upon any interruption during the ticket out process. 5.13 The TITO system must be able to cater for the potential of orphaned tickets after any interruption, where the ticket has been printed with a unique ticket identifier but does not exist in the TITO database. 5.14 TITO enabled devices that are able to issue tickets must maintain a log of the last 35 issued tickets that must include at least the following details for each record: 5.14.1 time and date; 5.14.2 amount; 5.14.3 unique ticket identifier. 5.15 The TITO system must be able to cater for the scenario of partially printed tickets where a fault has occurred during printing but the complete unique ticket identifier is not clearly visible on the ticket.
6.	Cash redemption terminals 6.1 Cash redemption terminals may issue tickets, redeem tickets, or do both. 6.2 Cash redemption terminals may accept banknotes for the purpose of issuing tickets. 6.3 Cash redemption terminals must not provide any additional functionality relating to banking transactions (including ATM or EFTPOS facilities). 6.4 Cash redemption terminals must communicate in a secure and approved manner with the TITO system using an approved protocol. 6.5 Cash redemption terminals must have sufficient security provisions relative to the amount of cash stored in the terminal. 6.6 Cash redemption terminals may have configurable limits for ticket in and ticket out relevant to TITO enabled devices as defined in this Schedule. 6.7 In situations where a cash redemption terminal has insufficient funds to completely pay out a ticket, the cash redemption terminal may issue a ticket equivalent to the remaining cash value, which may be redeemed at a cashier desk. 6.8 Cash redemption terminals must have the facility to display device software and firmware version for the purpose of software verification. 6.9 Cash redemption terminals must facilitate or allow software signatures to be generated for critical software for the purpose of software verification. 6.10 Cash redemption terminals that are able to issue tickets must maintain a log of the last 35 issued tickets which must include the following details for each record as a minimum: 6.10.1 time and date; 6.10.2 amount; 6.10.3 unique ticket identifier. 6.11 Cash redemption terminals that can accept and redeem tickets must maintain a log of the last 35 accepted or rejected tickets that must include the following details for each record as a minimum: 6.11.1 time and date; 6.11.2 amount; 6.11.3 unique ticket identifier; 6.11.4 whether the ticket was accepted or rejected.
7.	Cashier terminals 7.1 The TITO system may provide cashier terminals as an interface to the TITO host to allow authorised staff to perform TITO operations. 7.2 Cashier terminals may issue tickets, redeem tickets, or do both. 7.3 Cashier terminals must communicate in a secure and approved manner with the TITO host using an approved protocol. 7.4 Access to the TITO functions provided by cashier terminals must be restricted with account and password control. 7.5 Access to the TITO functions provided by cashier terminals may be further restricted and enabled according to staff tiers and privilege levels. 7.6 Cashier terminals may have configurable limits for ticket in and ticket out relevant to TITO enabled devices as defined in this Schedule. TITO limits for cashier terminals may be implemented on a system level across all cashier terminals. 7.7 The TITO system must be able to record all ticket out transactions performed on each cashier terminal. The record must include every new entry that has been printed and include the following details as a minimum: 7.7.1 time and date; 7.7.2 amount; 7.7.3 unique ticket identifier; 7.7.4 staff member identifier. 7.8 The TITO system must be able to record all ticket in transactions performed on each cashier terminal. The record must include every new entry that has been verified by the ticket‑in system and include the following details as a minimum: 7.8.1 time and date; 7.8.2 amount; 7.8.3 unique ticket identifier; 7.8.4 staff member identifier.
8.	TITO host system requirements 8.1 The TITO host system must be of a robust design, able to withstand failures without loss of data. 8.2 There must be some form of redundancy to allow gaming to continue in the event of a TITO host system failure. 8.3 The TITO host system database that holds the TITO data of the TITO system must be secure, fault tolerant and have redundant data storage. 8.4 The TITO host system must have built‑in redundancy for critical components. 8.5 The TITO host system must be able to recover back to an operational state without loss of TITO data following an interruption or outage. 8.6 The TITO host system must provide accountable, transparent and auditable recording and reporting of transactions to enable the accurate calculation and reporting of gaming revenue, player payments, taxation and any other TITO related financial information required for a venue to comply with its regulatory obligations. 8.7 The TITO host system must provide reporting and record keeping for liability for unclaimed and expired tickets. 8.8 The TITO host system must have the ability to record and report on all TITO transactions and TITO activity on the system, including, but not limited to, issued tickets, redeemed tickets, and expired tickets. 8.9 The TITO host system must have the required capacity to be able to store all TITO data for the period of time necessary in accordance with relevant legislation. 8.10 The TITO host system must provide secure access to and storage of TITO data to prevent any unauthorised manipulation of TITO data. 8.11 The TITO host system must be able to correctly handle the situation when duplicate ticket Unique Ticket Identifiers are created by 2 different TITO enabled devices. 8.12 Where applicable, caching of unique ticket identifiers across components of the TITO system components must be robust and designed to propagate to the TITO host without risks of errors, intercept, or tampering. 8.13 The TITO host system must be under version control. 8.14 The TITO host system must be under regulatory approval control in line with the Act. 8.15 TITO host system software must be able to be audited by allowing software signatures to be calculated for controlled files.

Legislative history

Notes

• •

  Please note—References in the legislation to other legislation or instruments or to titles of bodies or offices are not automatically updated as part of the program for the revision and publication of legislation and therefore may be obsolete.

• •

  Earlier versions of these regulations (historical versions) are listed at the end of the legislative history.

• •

  For further information relating to the Act and subordinate legislation made under the Act see the Index of South Australian Statutes or regulations and variations

  New entries appear in bold.

  Year	No	Reference	Commencement
  2013	270	Gazette 5.12.2013 p4455	1.1.2014: r 2
  2013	275	Gazette 5.12.2013 p4475	1.7.2015: r 2
  2015	173	Gazette 18.6.2015 p2874	1.7.2015 immediately after 275/2013 except r 4(4) & (10)—1.10.2015 and except r 4(2), (6) & (8)—1.7.2016: r 2
  2017	204	Gazette 25.7.2017 p2964	25.7.2017: r 2
  2018	237	Gazette 29.11.2018 p4117	1.12.2018: r 2
  2018	246	Gazette 6.12.2018 p4177	6.12.2018: r 2
  2020	245	Gazette 30.7.2020 p4116	30.7.2020: r 2
  2020	246	Gazette 30.7.2020 p4127	28.9.2020: r 2
  2020	247	Gazette 30.7.2020 p4129	3.12.2020: r 2

  Provisions varied

  New entries appear in bold.

  Entries that relate to provisions that have been deleted appear in italics.

  Provision	How varied	Commencement
  r 2	omitted under Legislation Revision and Publication Act 2002	1.7.2015
  r 3
  relevant approved licensing agreement	deleted by 237/2018 r 4	1.12.2018
  r 5
  r 5(1) and (2)	deleted by 237/2018 r 5	1.12.2018
  r 5(3)	varied by 204/2017 r 4(1)	25.7.2017
  varied by 245/2020 r 4(1)	30.7.2020
  r 5(3a)	inserted by 204/2017 r 4(2)	25.7.2017
  varied by 245/2020 r 4(2)	30.7.2020
  r 5(4)
  relevant Appendix	varied by 245/2020 r 4(3)	30.7.2020
  r 6	deleted by 247/2020 r 4	3.12.2020
  r 7	inserted by 246/2018 r 4	6.12.2018
  substituted by 245/2020 r 5	30.7.2020
  r 8	inserted by 245/2020 r 5	30.7.2020
  r 9	inserted by 246/2020 r 4	28.9.2020
  r 10	inserted by 247/2020 r 5	3.12.2020
  Sch 1 before deletion by 245/2020
  cl 1
  cl 1(1)	cl 1 varied by 237/2018 r 6(1)	1.12.2018
  cl 1 varied by 246/2018 r 5(1)	6.12.2018
  cl 1 redesignated as cl 1(1) by 246/2018 r 5(2)	6.12.2018
  cl 1(2)	inserted by 246/2018 r 5(2)	6.12.2018
  cll 2—5	deleted by 237/2018 r 6(2)	1.12.2018
  Sch 1	deleted by 245/2020 r 6	30.7.2020
  Sch 2
  item 1
  item 1.3	inserted by 275/2013 r 4(1)	1.7.2015
  item 3
  item 3.4	varied by 275/2013 r 4(2), (3)	1.7.2015
  item 5
  item 5.2	varied by 275/2013 r 4(4)	1.7.2015
  item 6
  item 6.1	substituted by 275/2013 r 4(5)	1.7.2015
  varied by 173/2015 r 4(1)	1.7.2015
  varied by 173/2015 r 4(2)	1.7.2016
  item 6.2	varied by 275/2013 r 4(6)	1.7.2015
  varied by 173/2015 r 4(3)	1.7.2015
  varied by 173/2015 r 4(4)	1.10.2015
  item 8
  item 8.1	substituted by 275/2013 r 4(7)	1.7.2015
  item 8.2	substituted by 275/2013 r 4(7)	1.7.2015
  item 8.3	inserted by 275/2013 r 4(7)	1.7.2015
  item 10
  item 10.3	varied by 275/2013 r 4(8)	1.7.2015
  item 10.4	varied by 275/2013 r 4(9)	1.7.2015
  varied by 173/2015 r 4(5)	1.7.2015
  varied by 173/2015 r 4(6)	1.7.2016
  item 10.5	varied by 275/2013 r 4(10)	1.7.2015
  item 10.6	varied by 275/2013 r 4(11)	1.7.2015
  item 10.7	inserted by 275/2013 r 4(12)	1.7.2015
  varied by 173/2015 r 4(7)	1.7.2015
  varied by 173/2015 r 4(8)	1.7.2016
  item 10.8 and 10.9	inserted by 275/2013 r 4(12)	1.7.2015
  item 11
  ancillary screen	varied by 245/2020 r 7(1)	30.7.2020
  item 16	varied by 275/2013 r 4(13)	1.7.2015
  varied by 173/2015 r 4(9)	1.7.2015
  varied by 173/2015 r 4(10)	1.10.2015
  item 17
  item 17.3	substituted by 275/2013 r 4(14)	1.7.2015
  item 17.4—17.6	inserted by 275/2013 r 4(14)	1.7.2015
  item 19	varied by 245/2020 r 7(2)	30.7.2020
  Sch 3	inserted by 245/2020 r 8	30.7.2020
  cl 3	inserted by 247/2020 r 6	3.12.2020
  Sch 4	inserted by 245/2020 r 8	30.7.2020

  Historical versions

  1.7.2015

  1.10.2015

  1.7.2016

  25.7.2017

  1.12.2018 (electronic only)

  6.12.2018

  30.7.2020

  28.9.2020