{"id":"casino-regulations-2013","name":"Casino Regulations 2013","slug":"casino-regulations-2013","collection":"regulation","jurisdiction":"sa","status":"in_force","isInForce":true,"actNumber":null,"makingDate":null,"administeringDepartment":null,"currentVersion":{"id":235259,"registerId":"sa-casino-regulations-2013-current","compilationNumber":null,"startDate":"2026-04-06","status":"InForce","reasons":null,"registeredAt":null},"sections":[{"sectionNumber":"1","sectionType":"section","heading":"Casino Regulations 2013","content":"South Australia\nCasino Regulations 2013\nunder the Casino Act 1997\n\nContents\n1\tShort title\n3\tInterpretation\n4\tPrescribed jurisdictions (section 40A of Act)\n5\tApproval of gaming machines and games\n7\tApproval of facial recognition system—prescribed requirements\n8\tRequirement for pre‑commitment system\n9\tOperation of gaming machine or automated table game equipment by insertion of a ticket—prescribed requirements\n10\tOperation of facial recognition system—prescribed requirements\nSchedule 2—Voluntary Pre‑commitment Code\nSchedule 3—Savings and transitional provisions\n1\tApproval of gaming machines and automated table game equipment intended to operate a TITO system\n2\tApproval of facial recognition system\n3\tRight of review\nSchedule 4—TITO technical requirements\nLegislative history\n\n1—Short title\nThese regulations may be cited as the Casino Regulations 2013.\n3—Interpretation\nIn these regulations—\nAct means the Casino Act 1997.\n4—Prescribed jurisdictions (section 40A of Act)\nFor the purposes of section 40A(2) of the Act, the following jurisdictions are prescribed:\n\t(a)\tNew South Wales;\n\t(b)\tNew Zealand;\n\t(c)\tQueensland;\n\t(d)\tVictoria.\n5—Approval of gaming machines and games\n\t(3)\tSubject 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.\n\t(3a)\tSubregulation (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—\n\t(a)\tthe gaming machine or game is already approved or taken to have been approved under section 40A of the Act; and\n\t(b)\tit 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.\n\t(4)\tIn this regulation—\nrelevant Appendix in relation to a version of the Australian/New Zealand Gaming Machine National Standard means—\n\t(a)\tthe latest South Australian Appendix to that version; or\n\t(b)\tthe latest Appendix to that version of a jurisdiction referred to in regulation 4.\n7—Approval of facial recognition system—prescribed requirements\nFor 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:\n\t(a)\tthe system must be capable of accurately taking account of physical variances in facial features;\n\t(b)\tthe system must be designed to prevent unauthorised access, use and disclosure of data collected by the system;\n\t(c)\tthe system must be able to be operated in accordance with—\n\t(i)\ttechnical requirements; and\n\t(ii)\tsecurity requirements; and\n\t(iii)\tany other criteria,\nas determined by the Commissioner.\n8—Requirement for pre‑commitment system\nFor 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.\n9—Operation of gaming machine or automated table game equipment by insertion of a ticket—prescribed requirements\n\t(1)\tFor 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.\n\t(2)\tA TITO system must comply with the requirements of, and be operated in accordance with—\n\t(a)\tuntil 3 December 2020—the TITO technical requirements set out in Schedule 4; and\n\t(b)\ton and after 3 December 2020—the gambling administration guidelines issued under section 17 of the Gambling Administration Act 2019.\n\t(3)\tA TITO system must not issue a ticket containing any form of promotional material or advertising.\n\t(4)\tA 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.\n\t(5)\tA 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.\n\t(6)\tThe 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).\n\t(7)\tIn this regulation—\nTITO 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.\n10—Operation of facial recognition system—prescribed requirements\n\t(1)\tFor 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:\n\t(a)\tencouraging or providing incentives to a person to gamble;\n\t(b)\tcustomer loyalty programs;\n\t(c)\ta lottery within the meaning of the Lottery and Gaming Act 1936 or the Lotteries Act 2019;\n\t(d)\tidentifying a barred person in respect of premises other than the casino premises;\n\t(e)\tany other purpose notified by the Commissioner to the system provider or licensee.\n\t(2)\tFor 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:\n\t(a)\tthe 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;\n\t(b)\tthe 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.\nSchedule 2—Voluntary Pre‑commitment Code\n\nRegistration\n1.\nThe licensee must permit a customer who wishes to do so to register with the pre‑commitment system by—\n\t1.1\tcompleting an application in writing at the casino premises; or\n\t1.2\tmaking a request in person to casino staff; or\n\t1.3\tcompleting a form on a website available generally on the Internet.\n2.\nThe licensee must not only offer pre‑commitment in conjunction with a loyalty system.\n3.\nThe 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:\n\t3.1\tthe process by which a registered customer may vary his or her expenditure limits and other details, and how and when the variation will apply;\n\t3.2\tprivacy protections for the registered customer;\n\t3.3\tthe application of a default daily expenditure limit if the registered customer does not specify his or her own expenditure limit;\n\t3.4\tthe 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—\n\t3.4.1\tthat the pre‑commitment system will monitor the customer's play data to enable a reminder message to be sent to the customer; and\n\t3.4.2\tthat 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.\n4.\nThe licensee must obtain the customer's consent to the terms and conditions before registering a customer.\n5.\nThe licensee must record on the pre‑commitment system a registered customer's preferred—\n\t5.1\tlanguage for use on the pre‑commitment system (the preferred language); and\n\t5.2\tmethod of communication (post, email, SMS or in‑venue communication (the preferred communication method)).\nSetting and varying limits\n6.\nThe pre‑commitment system must allow a registered customer to—\n\t6.1\tset the following:\n\t6.1.1\ta daily or weekly expenditure limit (eg $50 per day);\n\t6.1.2\tbreak in play periods (eg a 5 minute break every hour);\n\t6.1.3\tno play periods (eg pay or pension day, the hours when children are picked up from school);\n\t6.1.4\ta 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\n\t6.2\tvary 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.\n7.\nIf a registered customer does not specify an expenditure limit, the pre‑commitment system must set a default daily expenditure limit of $100 per day.\n8.\nThe pre‑commitment system must apply any variations referred to in item 6.2 as follows:\n\t8.1\ta variation must be applied as soon as practicable if the customer has not played a gaming machine or automated table game since registering;\n\t8.2\ta 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;\n\t8.3\tif 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—\n\t8.3.1\ta period of 24 hours has passed since the making of the request; and\n\t8.3.2\tthe customer has confirmed to the licensee (in person or by any other means) that he or she still requires the making of the variation.\n9.\nOnce a varied expenditure limit is applied by the pre‑commitment system, any previous expenditure limit set by the registered customer has no effect.\nOperation of the pre‑commitment system\n10.\nThe pre‑commitment system must comply with the following requirements:\n\t10.1\tthe 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;\n\t10.2\tthe system must be capable of displaying on‑screen messages on a primary screen or an ancillary screen;\n\t10.3\tthe 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;\n\t10.4\tif 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;\n\t10.5\tif 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%;\n\t10.6\tthe 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;\n\t10.7\tif 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;\n\t10.8\tif 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;\n\t10.9\tif 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.\n11.\nFor the purposes of item 10—\nprimary screen means a gaming machine or automated table game screen;\nancillary screen means a screen measuring not less than 14 cm in width and 5 cm in height that is—\n\t(a)\tin the sandwich board of a gaming machine; or\n\t(b)\tattached to a gaming machine or automated table game equipment and visible to the registered customer during play.\n12.\nThe 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).\nCommunication\n13.\nThe licensee must communicate with a registered customer by the preferred communication method.\n14.\nThe 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.\n15.\nThe 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.\n16.\nThe 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.\n17.\nThe following information must be provided in a periodic and an on‑demand activity statement:\n\t17.1\tthe period of the statement;\n\t17.2\tthe total amount spent during that period;\n\t17.3\teach amount won and lost during that period;\n\t17.4\tthe net amount won or lost during that period;\n\t17.5\tthe current expenditure limit;\n\t17.6\tthe number of times the registered customer exceeded his or her expenditure limit during that period.\n18.\nThe periodic activity statement and on‑demand activity statement must be in the registered customer's preferred language, if available.\nMiscellaneous\n19.\nThe 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.\nSchedule 3—Savings and transitional provisions\n1—Approval of gaming machines and automated table game equipment intended to operate a TITO system\n\t(1)\tFor the purposes of section 40A(3)(b) and (4)(b) of the Act, a requirement that—\n\t(a)\tany gaming machine that is intended to be operated in connection with a TITO system; or\n\t(b)\tany automated table game equipment that is intended to be operated in connection with a TITO system,\nmust be able to be operated in accordance with the TITO technical requirements set out in Schedule 4 is, until 3 December 2020, prescribed.\n\t(2)\tIn this clause—\nTITO 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.\n2—Approval of facial recognition system\n\t(1)\tFor 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.\n\t(2)\tIn this clause—\nnotified 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.\n3—Right of review\n\t(1)\tDespite 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).\n\t(2)\tIn this clause—\nprescribed 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;\nrelevant day means a day determined by the Minister by notice in the Gazette for the purposes of this clause.\nSchedule 4—TITO technical requirements\n\n1.\nInterpretation\nIn these requirements, unless the contrary intention appears—\nTITO 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;\nTITO host means the core back‑end servers and database of the TITO system;\nTITO peripheral means hardware by which a TITO enabled device conducts a TITO transaction;\nTITO system means the entire TITO system including TITO enabled devices and the TITO host.\n2.\nTITO ticket requirement\nTickets must comply with the following requirements:\n\t2.1\tthe following information must be printed on the tickets:\n\t2.1.1\ta heading that uniquely identifies the ticket for TITO purposes (eg. the words \"CASH OUT TICKET\");\n\t2.1.2\tvenue information regarding where the ticket was printed (eg. venue and venue name details);\n\t2.1.3\tinformation identifying the TITO enabled device which issued the ticket;\n\t2.1.4\ta 16 or 18 digit number (a unique ticket identifier) in—\n\t2.1.4.1\ta readable format in at least 2 places on the ticket; and\n\t2.1.4.2\tin a machine readable format such as a barcode;\n\t2.1.5\tthe date and time that the ticket is printed;\n\t2.1.6\tthe value of the ticket expressed in dollars and cents;\n\t2.2\ttickets 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);\n\t2.3\ttickets may contain location information of the TITO enabled device which issued the ticket (eg. house or bank number);\n\t2.4\ttickets must be designed to be durable for their expected life span and provide clear legibility of text when the ticket is printed;\n\t2.5\tif 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);\n\t2.6\ttickets must not contain any form of promotional or advertising information.\n3.\nGeneral TITO requirements\n\t3.1\tTITO peripherals must be integrated into and be controlled by a TITO enabled device which is able to—\n\t3.1.1\tenable 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\n\t3.1.2\tmanage and diagnose faults and the status of any faults in the TITO peripheral.\n\t3.2\tThe 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.\n\t3.3\tIt must be possible to enable or disable TITO functionality on a TITO enabled device.\n\t3.4\tTITO systems must use an approved communication protocol to communicate with TITO enabled devices which must—\n\t3.4.1\timplement a means of error checking; and\n\t3.4.2\timplement a 2 way handshaking process between the initiating TITO enabled device and the TITO host for the redemption of tickets; and\n\t3.4.3\tbe robust and able to handle incomplete, misrouted, duplicated, altered in transit or unauthorised TITO transactions.\n\t3.5\tTITO 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.\n\t3.6\tTITO enabled devices must automatically abort a ticket in or a ticket out transaction if connection to the TITO host is detected as lost.\n\t3.7\tTITO operation across a TITO system must be transaction based.\n\t3.8\tTITO systems must use a database or similar managed information system for the storage of TITO data.\n\t3.9\tEach TITO transaction on the TITO system must—\n\t3.9.1\tbe allocated a unique sequence number; and\n\t3.9.2\thave a time‑date stamp.\n\t3.10\tTITO enabled devices and the TITO system must be configured to ensure synchronicity of time‑date data used to time‑date stamp TITO transactions.\n\t3.11\tTITO enabled devices should not allow TITO operation until they have time‑date synchronised with the TITO system.\n\t3.12\tTITO systems may have—\n\t3.12.1\ta configurable maximum ticket out limit restricting the cash value of tickets that TITO enabled devices can issue;\n\t3.12.2\ta configurable maximum ticket in limit where tickets having a cash value in excess of the maximum ticket in limit are rejected;\n\t3.12.3\ta configurable minimum ticket out limit which defines the minimum cash value of tickets that can be issued by particular TITO enabled devices;\n\t3.12.4\ta configurable maximum credit limit restricting a TITO enabled device from redeeming a ticket if it would cause the credit meter to exceed this value.\n\t3.13\tTickets 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.\n\t3.14\tTITO systems—\n\t3.14.1\tmust 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\n\t3.14.2\tmay 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.\n\t3.15\tTITO enabled devices which issue or accept tickets on the TITO system must provide accurate and accountable logging for tickets printed, accepted and rejected.\n\t3.16\tGaming machine based TITO enabled devices must comply with—\n\t3.16.1\tthe applicable technical requirements defined under the current Australian/New Zealand Gaming Machine National Standards and other applicable technical standards; and\n\t3.16.2\tthe applicable technical requirements of the communication protocol used for TITO operation; and\n\t3.16.3\tthe applicable technical requirements for ticket in ticket out as listed in the South Australian Appendix to the Australian/New Zealand Gaming Machine National Standard.\n\t3.17\tTITO enabled devices must be able to recover when printing of a ticket fails or is interrupted by a fault.\n4.\nTicket in process\n\t4.1\tCredits must only be registered for valid tickets.\n\t4.2\tTickets may only be accepted when the TITO enabled device is in an active state and able to receive and credit tickets.\n\t4.3\tIf 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.\n\t4.4\tTITO enabled devices must automatically reject inserted tickets when it can detect that the connection to the TITO host is down.\n\t4.5\tThe 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.\n\t4.6\tA TITO enabled device must only redeem valid tickets that have been authenticated by the TITO host.\n\t4.7\tIf a TITO enabled device is not able to receive and process tickets, the inserted ticket must be ejected back to the player.\n\t4.8\tIf an inserted ticket is detected as invalid by a TITO enabled device then the ticket must be ejected back to the player.\n\t4.9\tA TITO enabled device must not accept another ticket until the current ticket in transaction has been completed (ie. either approved or rejected).\n\t4.10\tA 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).\n\t4.11\tWhere 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.\n\t4.12\tIf 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.\n\t4.13\tTITO enabled devices must provide visual or audio feedback to players that the ticket has been accepted and redeemed.\n\t4.14\tA 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.\n\t4.15\tThe 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.\n\t4.16\tThe TITO system must support the provision of at least the following reasons for rejection:\n\t4.16.1\tticket system unavailable;\n\t4.16.2\tticket expired or too old;\n\t4.16.3\tticket amount too large;\n\t4.16.4\tticket invalid;\n\t4.16.5\tticket not found;\n\t4.16.6\tticket already redeemed;\n\t4.16.7\tother reason—see operator.\n\t4.17\tIf 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.\n\t4.18\tThe TITO system must ensure that tickets can only be redeemed once.\n\t4.19\tTITO 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:\n\t4.19.1\ttime and date;\n\t4.19.2\tamount;\n\t4.19.3\tunique ticket identifier;\n\t4.19.4\twhether the ticket was accepted or rejected.\n5.\nTicket out process\n\t5.1\tThe 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.\n\t5.2\tTickets issued by TITO enabled devices must have a unique ticket identifier which is used by the TITO system to uniquely identify tickets.\n\t5.3\tThe TITO host must be able to cater for the scenario when multiple TITO enabled devices create identical unique ticket identifiers.\n\t5.4\tA 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.\n\t5.5\tA 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.\n\t5.6\tA 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.\n\t5.7\tA 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.\n\t5.8\tTITO 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).\n\t5.9\tA 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.\n\t5.10\tA ticket must only be printed out when the TITO enabled device is actively connected to the TITO system.\n\t5.11\tTITO enabled devices must be able to notify the TITO system of faults if they occur and interrupt the ticket out process.\n\t5.12\tTITO enabled devices must be able to resume and recover upon any interruption during the ticket out process.\n\t5.13\tThe 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.\n\t5.14\tTITO 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:\n\t5.14.1\ttime and date;\n\t5.14.2\tamount;\n\t5.14.3\tunique ticket identifier.\n\t5.15\tThe 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.\n6.\nCash redemption terminals\n\t6.1\tCash redemption terminals may issue tickets, redeem tickets, or do both.\n\t6.2\tCash redemption terminals may accept banknotes for the purpose of issuing tickets.\n\t6.3\tCash redemption terminals must not provide any additional functionality relating to banking transactions (including ATM or EFTPOS facilities).\n\t6.4\tCash redemption terminals must communicate in a secure and approved manner with the TITO system using an approved protocol.\n\t6.5\tCash redemption terminals must have sufficient security provisions relative to the amount of cash stored in the terminal.\n\t6.6\tCash redemption terminals may have configurable limits for ticket in and ticket out relevant to TITO enabled devices as defined in this Schedule.\n\t6.7\tIn 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.\n\t6.8\tCash redemption terminals must have the facility to display device software and firmware version for the purpose of software verification.\n\t6.9\tCash redemption terminals must facilitate or allow software signatures to be generated for critical software for the purpose of software verification.\n\t6.10\tCash 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:\n\t6.10.1\ttime and date;\n\t6.10.2\tamount;\n\t6.10.3\tunique ticket identifier.\n\t6.11\tCash 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:\n\t6.11.1\ttime and date;\n\t6.11.2\tamount;\n\t6.11.3\tunique ticket identifier;\n\t6.11.4\twhether the ticket was accepted or rejected.\n7.\nCashier terminals\n\t7.1\tThe TITO system may provide cashier terminals as an interface to the TITO host to allow authorised staff to perform TITO operations.\n\t7.2\tCashier terminals may issue tickets, redeem tickets, or do both.\n\t7.3\tCashier terminals must communicate in a secure and approved manner with the TITO host using an approved protocol.\n\t7.4\tAccess to the TITO functions provided by cashier terminals must be restricted with account and password control.\n\t7.5\tAccess to the TITO functions provided by cashier terminals may be further restricted and enabled according to staff tiers and privilege levels.\n\t7.6\tCashier 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.\n\t7.7\tThe 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:\n\t7.7.1\ttime and date;\n\t7.7.2\tamount;\n\t7.7.3\tunique ticket identifier;\n\t7.7.4\tstaff member identifier.\n\t7.8\tThe 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:\n\t7.8.1\ttime and date;\n\t7.8.2\tamount;\n\t7.8.3\tunique ticket identifier;\n\t7.8.4\tstaff member identifier.\n8.\nTITO host system requirements\n\t8.1\tThe TITO host system must be of a robust design, able to withstand failures without loss of data.\n\t8.2\tThere must be some form of redundancy to allow gaming to continue in the event of a TITO host system failure.\n\t8.3\tThe TITO host system database that holds the TITO data of the TITO system must be secure, fault tolerant and have redundant data storage.\n\t8.4\tThe TITO host system must have built‑in redundancy for critical components.\n\t8.5\tThe TITO host system must be able to recover back to an operational state without loss of TITO data following an interruption or outage.\n\t8.6\tThe 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.\n\t8.7\tThe TITO host system must provide reporting and record keeping for liability for unclaimed and expired tickets.\n\t8.8\tThe 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.\n\t8.9\tThe 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.\n\t8.10\tThe TITO host system must provide secure access to and storage of TITO data to prevent any unauthorised manipulation of TITO data.\n\t8.11\tThe 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.\n\t8.12\tWhere 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.\n\t8.13\tThe TITO host system must be under version control.\n\t8.14\tThe TITO host system must be under regulatory approval control in line with the Act.\n\t8.15\tTITO host system software must be able to be audited by allowing software signatures to be calculated for controlled files.\nLegislative history\nNotes\n\t•\tPlease 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.\n\t•\tEarlier versions of these regulations (historical versions) are listed at the end of the legislative history.\n\t•\tFor further information relating to the Act and subordinate legislation made under the Act see the Index of South Australian Statutes or www.legislation.sa.gov.au.\nPrincipal regulations and variations\nNew entries appear in bold.\nYear\nNo\nReference\nCommencement\n2013\n270\nGazette 5.12.2013 p4455\n1.1.2014: r 2\n2013\n275\nGazette 5.12.2013 p4475\n1.7.2015: r 2\n2015\n173\nGazette 18.6.2015 p2874\n1.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\n2017\n204\nGazette 25.7.2017 p2964\n25.7.2017: r 2\n2018\n237\nGazette 29.11.2018 p4117\n1.12.2018: r 2\n2018\n246\nGazette 6.12.2018 p4177\n6.12.2018: r 2\n2020\n245\nGazette 30.7.2020 p4116\n30.7.2020: r 2\n2020\n246\nGazette 30.7.2020 p4127\n28.9.2020: r 2\n2020\n247\nGazette 30.7.2020 p4129\n3.12.2020: r 2\nProvisions varied\nNew entries appear in bold.\nEntries that relate to provisions that have been deleted appear in italics.\nProvision\nHow varied\nCommencement\nr 2\nomitted under Legislation Revision and Publication Act 2002\n1.7.2015\nr 3\n\n\nrelevant approved licensing agreement\ndeleted by 237/2018 r 4\n1.12.2018\nr 5\n\n\nr 5(1) and (2)\ndeleted by 237/2018 r 5\n1.12.2018\nr 5(3)\nvaried by 204/2017 r 4(1)\n25.7.2017\n\nvaried by 245/2020 r 4(1)\n30.7.2020\nr 5(3a)\ninserted by 204/2017 r 4(2)\n25.7.2017\n\nvaried by 245/2020 r 4(2)\n30.7.2020\nr 5(4)\n\n\nrelevant Appendix\nvaried by 245/2020 r 4(3)\n30.7.2020\nr 6\ndeleted by 247/2020 r 4\n3.12.2020\nr 7\ninserted by 246/2018 r 4\n6.12.2018\n\nsubstituted by 245/2020 r 5\n30.7.2020\nr 8\ninserted by 245/2020 r 5\n30.7.2020\nr 9\ninserted by 246/2020 r 4\n28.9.2020\nr 10\ninserted by 247/2020 r 5\n3.12.2020\nSch 1 before deletion by 245/2020\n\n\ncl 1\n\n\ncl 1(1)\ncl 1 varied by 237/2018 r 6(1)\n1.12.2018\n\ncl 1 varied by 246/2018 r 5(1)\n6.12.2018\n\ncl 1 redesignated as cl 1(1) by 246/2018 r 5(2)\n6.12.2018\ncl 1(2)\ninserted by 246/2018 r 5(2)\n6.12.2018\ncll 2—5\ndeleted by 237/2018 r 6(2)\n1.12.2018\nSch 1\ndeleted by 245/2020 r 6\n30.7.2020\nSch 2\n\n\nitem 1\n\n\nitem 1.3\ninserted by 275/2013 r 4(1)\n1.7.2015\nitem 3\n\n\nitem 3.4\nvaried by 275/2013 r 4(2), (3)\n1.7.2015\nitem 5\n\n\nitem 5.2\nvaried by 275/2013 r 4(4)\n1.7.2015\nitem 6\n\n\nitem 6.1\nsubstituted by 275/2013 r 4(5)\n1.7.2015\n\nvaried by 173/2015 r 4(1)\n1.7.2015\n\nvaried by 173/2015 r 4(2)\n1.7.2016\nitem 6.2\nvaried by 275/2013 r 4(6)\n1.7.2015\n\nvaried by 173/2015 r 4(3)\n1.7.2015\n\nvaried by 173/2015 r 4(4)\n1.10.2015\nitem 8\n\n\nitem 8.1\nsubstituted by 275/2013 r 4(7)\n1.7.2015\nitem 8.2\nsubstituted by 275/2013 r 4(7)\n1.7.2015\nitem 8.3\ninserted by 275/2013 r 4(7)\n1.7.2015\nitem 10\n\n\nitem 10.3\nvaried by 275/2013 r 4(8)\n1.7.2015\nitem 10.4\nvaried by 275/2013 r 4(9)\n1.7.2015\n\nvaried by 173/2015 r 4(5)\n1.7.2015\n\nvaried by 173/2015 r 4(6)\n1.7.2016\nitem 10.5\nvaried by 275/2013 r 4(10)\n1.7.2015\nitem 10.6\nvaried by 275/2013 r 4(11)\n1.7.2015\nitem 10.7\ninserted by 275/2013 r 4(12)\n1.7.2015\n\nvaried by 173/2015 r 4(7)\n1.7.2015\n\nvaried by 173/2015 r 4(8)\n1.7.2016\nitem 10.8 and 10.9\ninserted by 275/2013 r 4(12)\n1.7.2015\nitem 11\n\n\nancillary screen\nvaried by 245/2020 r 7(1)\n30.7.2020\nitem 16\nvaried by 275/2013 r 4(13)\n1.7.2015\n\nvaried by 173/2015 r 4(9)\n1.7.2015\n\nvaried by 173/2015 r 4(10)\n1.10.2015\nitem 17\n\n\nitem 17.3\nsubstituted by 275/2013 r 4(14)\n1.7.2015\nitem 17.4—17.6\ninserted by 275/2013 r 4(14)\n1.7.2015\nitem 19\nvaried by 245/2020 r 7(2)\n30.7.2020\nSch 3\ninserted by 245/2020 r 8\n30.7.2020\ncl 3\ninserted by 247/2020 r 6\n3.12.2020\nSch 4\ninserted by 245/2020 r 8\n30.7.2020\nHistorical versions\n1.7.2015\n\n1.10.2015\n\n1.7.2016\n\n25.7.2017\n\n1.12.2018 (electronic only)\n\n6.12.2018\n\n30.7.2020\n\n28.9.2020\n\n","sortOrder":0}],"analysis":{"flash_summary_failed":{"failed":true,"reason":"A positive credit balance is required for all requests, including BYOK, so fallback providers remain available. Add credits at https://vercel.com/d?to=%2F%5Bteam%5D%2F%7E%2Fai%3Fmodal%3Dtop-up to continue.","source":"analysis-cron"},"issue_detection":{"absurdities":[],"contradictions":[]},"flash_summary":{"complexity_score":7,"scope_assessment":{"changed":true,"description":"Yes. The regulations were expanded by later amendments to add a mandatory pre‑commitment framework (r8 and Schedule 2), a prescriptive TITO technical and operational regime (r9 and Schedule 4), and detailed facial recognition approval, use and retention controls (r7 and r10). Transitional arrangements and review rights were also inserted (Schedule 3). These amendments broaden operational, technical and privacy obligations on licensees and increase the Commissioner's approval and specification powers."},"complexity_factors":["Detailed technical TITO standards spanning hardware, host, logging, redundancy and transaction flows (Schedule 4) create substantial IT, operational and audit requirements.","Cross‑references to external technical standards for gaming machines (Australian/New Zealand Gaming Machine National Standard 2016 or subsequent versions) add dependency on evolving national documents (r5).","Regulatory discretion: Commissioner can determine additional technical, security and other criteria for facial recognition approval (r7(c)), and may notify further prohibited uses (r10(1)(e)).","Operational thresholds and manual controls increase process complexity (eg. TITO max ticket cash value $149.99 (r9(4)); manual enablement for tickets > $5,000 (r9(5)); default and variation timing for pre‑commitment limits (Sch 2 items 7–8)).","Privacy and data‑retention constraints for facial images impose short retention windows and signage/notice obligations (r10(2)(a)–(b)).","Functional and customer‑facing requirements for pre‑commitment systems impose multi‑channel registration, communication, on‑demand and periodic reporting, multilingual support and mandatory reminder/acknowledgement flows (Schedule 2 items 1–6, 10–17).","Transitional and savings provisions plus a complex amendment history require attention to commencement dates and phased application of rules (Schedule 3; Legislative history).","Multiple compliance touchpoints (technical approvals, operational procedures, staff authorisations, reporting to Commissioner) increase administrative and evidentiary burdens on licensees (r5, r7, r8, r9, r10; Sch 2; Sch 4)."],"plain_english_summary":"These regulations set technical, operational and privacy rules for South Australian casinos. They require licensed casinos to use approved gaming machines, operate a pre‑commitment system, implement controlled ticket‑in‑ticket‑out (TITO) systems with value and expiry limits, and use approved facial recognition systems with strict retention and use limits. The licensee pays to implement and operate systems; the Commissioner approves systems and sets technical/security criteria. The rules change casino transaction processes, data‑handling and reporting obligations."},"summary":{"complexity_score":1,"scope_assessment":{"changed":false,"description":"Unable to assess scope change — no legislative text was provided. The submission contained only a 'Page Not Found' error from the South Australian legislation website. A scope assessment requires the actual text of the Casino Regulations 2013 and, ideally, its enabling Act (the Casino Act 1997 (SA)) for comparison."},"complexity_factors":["No legislative content was retrievable — the submission contains only a website error page","Complexity cannot be meaningfully assessed without access to the actual text of the Casino Regulations 2013 (SA)","Score of 1 reflects absence of content, not simplicity of the underlying law"],"plain_english_summary":"## ⚠️ Content Unavailable\n\nThe legislation you've submitted — the **Casino Regulations 2013 (SA)** — could not be analysed because the source link returned a **'Page Not Found' error** from the South Australian legislation website.\n\nThis appears to be a broken or outdated hyperlink, likely created before a website update on **24 March 2026** that changed how the SA legislation site works.\n\n### What you can do:\n- Visit [www.legislation.sa.gov.au](https://www.legislation.sa.gov.au) and search directly for *'Casino Regulations 2013'*\n- Email the site administrators at **OPCWeb@sa.gov.au** to report the broken link\n- Try searching for the regulations via the [Index to SA Legislation](https://www.legislation.sa.gov.au/lists-and-index-to-sa-legislation/understanding-legislation)\n\n**No legal analysis can be provided without access to the actual legislative text.**"},"kimi_summary":{"content_quality":"ok","complexity_score":7,"scope_assessment":{"changed":true,"description":"The legislation has grown significantly from its original 2013 form. The legislative history shows multiple amendments (2013, 2015, 2017, 2018, 2020) adding substantial new regimes: facial recognition systems (2018/2020), mandatory pre-commitment systems (2020), and detailed TITO technical requirements (2020). The original regulations appear to have been simpler gaming machine approval rules, but have expanded into a comprehensive harm minimisation and surveillance framework covering biometric data collection, voluntary self-exclusion systems, and complex cashless gaming infrastructure. The addition of Schedule 4 alone (TITO technical requirements) represents a major expansion into granular technical standards that likely exceeded the original regulatory scope."},"complexity_factors":["Extensive cross-referencing to the Casino Act 1997 and Gambling Administration Act 2019 (e.g., sections 40A, 40D, 42B, 42D)","Multiple defined terms including 'TITO system', 'relevant Appendix', 'primary screen', 'ancillary screen', 'notified facial recognition system requirements'","Nested conditional logic in Schedule 2 (Voluntary Pre-commitment Code) with multiple tiers of requirements (items, sub-items, sub-sub-items)","Temporal cut-off dates creating different regulatory regimes (e.g., 'until 3 December 2020' vs 'on and after 3 December 2020')","Technical specifications in Schedule 4 running to 8 major sections with detailed hardware and software requirements","Exception to exception structure in regulation 5(3) and 5(3a) regarding gaming machine standards","Multiple schedules with different purposes (Schedule 2: operational code, Schedule 3: transitional provisions, Schedule 4: technical requirements)","Interaction between regulations and 'gambling administration guidelines' issued under separate legislation"],"plain_english_summary":"**What this legislation does:**\n\nThese regulations set the technical and operational rules for South Australia's only casino (the Adelaide Casino). They cover three main areas:\n\n**1. Gaming Machine Standards**\n- Requires gaming machines to meet the Australian/New Zealand Gaming Machine National Standard (with some exceptions for older machines where upgrades aren't economically viable)\n- Recognises gaming standards from NSW, New Zealand, Queensland and Victoria as acceptable alternatives\n\n**2. Facial Recognition Systems**\n- Requires casinos to use approved facial recognition technology to identify barred or excluded gamblers\n- Sets strict privacy rules: images of regular customers must be deleted after 72 hours\n- Bans using facial recognition data for marketing, loyalty programs, or encouraging gambling\n- Requires clear signage warning people that facial scanning is in use\n\n**3. Pre-commitment and Ticket Systems**\n- **Voluntary Pre-commitment**: Requires a system where gamblers can voluntarily set spending limits ($100/day default), time breaks, and self-exclusion periods. The system sends warnings when limits are approached and alerts staff when limits are exceeded.\n- **TITO (Ticket-In-Ticket-Out)**: Sets detailed technical rules for cashless gaming tickets, including:\n  - $149.99 maximum ticket value for machine redemption\n  - 12-month expiry dates\n  - No advertising on tickets\n  - Detailed technical specifications for printers, scanners, and database systems\n\n**Who it affects:**\n- The casino operator (SkyCity Adelaide)\n- Casino staff\n- Gaming machine manufacturers and technicians\n- Casino patrons, particularly those who choose to use pre-commitment tools or who have self-excluded\n\n**Why it matters:**\nThese rules try to balance the casino's commercial interests with harm minimisation. The pre-commitment system and facial recognition for barred persons are designed to help problem gamblers control their behaviour, while the TITO rules ensure cashless gaming is secure and auditable for taxation and anti-money laundering purposes."}},"importantCases":[],"_links":{"self":"/api/acts/casino-regulations-2013","history":"/api/acts/casino-regulations-2013/history","analysis":"/api/acts/casino-regulations-2013/analysis","conflicts":"/api/acts/casino-regulations-2013/conflicts","importantCases":"/api/acts/casino-regulations-2013/important-cases","documents":"/api/acts/casino-regulations-2013/documents"}}