Few Malta Gaming Authority (“MGA”) licensed operators (or aspiring to be licensed) look forward to an MGA review or audit. And fewer would enjoy having audit findings thrown at them by the MGA when most of those findings could have been avoided in the first place should they have been picked up months or weeks prior to such MGA audits. Yet this situation is fairly common.
The MGA relies on three external exercises to check that a licensee (or prospective licensee) is doing what it said it would do: the systems audit, the systems review and the compliance audit. Each type of audit has a specific purpose and is conducted by an MGA approved audit service provider, engaged directly by the operator, but who reports to the MGA. The MGA’s in-house audit team reviews the external auditor’s report and issues a final report to the operator listing any findings or, worse still, any breaches.
When an audit is due, an approved auditor has 60 days to submit his/her audit report to the MGA, although there are other timelines depending on the type of audit required.
Sixty days is not long. It certainly is not long enough to rebuild a remote gaming system or a control framework to reflect what was submitted on paper to MGA. That is the case for running a mock exercise first, and is one of the best value for money compliance exercises an operator can make.
The MGA system audit should be the simplest of tasks where in truth it poses the simple question whether the platform the operator is actually running is the same platform it described to the MGA in its application. The provider tests this on the live beta environment against the MGA's System Audit Checklist, and the licensee's own people are expected to demonstrate the functionality and produce the evidence. A system audit is normally one of the final stages of a license application process and is naturally a determining factor if an operator is awarded an MGA license or otherwise.
An applicant tends to be caught up at this stage, when due to a time gap from when the technical documentation is submitted as part of the application process, to the time the MGA instructs the applicant to be subject to a systems audit, improvements (read changes) to the architecture, database structures, APIs, etc happen (even minor ones) many a time for valid technical reasons, but which are either not documented or which just happened on the fly to address a technical issue in the beta environment.
The trouble is that the license application documentation submitted to the MGA usually stays exactly as it was originally. As a consequence, the risk is that the applicant may fail the systems review, and either have a delay in its license issuance as it would need to update all its technical documentation and hold a second systems review, or as a worse case, have its application rejected.
A mock audit puts the live beta system next to the licence documentation and looks for the gaps. Do the critical components, hosting locations and suppliers match what was notified? Are the notified information security measures deployed as specified in the security and architecture documentation? By holding a mock audit, (ideally prior to the initiation of the official MGA audit/review period), allows the operator’s technical team to deal with any gaps either with the submitted documentation (and thus update such documentation to reflect the deployed set-up) or to amend technical matters which would otherwise not pass the compliance test.
The compliance audit covers far more ground. It goes beyond technology, and delves deeply into how the business has actually been run after the license was granted by the MGA. Apart from auditing the technology elements of the operation, other key operational policies, procedures and their implementation on player protection, AML and CFT controls, the safeguarding of player funds, complaints, marketing, regulatory reporting and the licence conditions generally are audited too. The Compliance Auditor has a time defined period to submit the compliance audit report
Whilst the compliance audit is very comprehensive, with administrative, operational, regulatory and technology matters all being assessed, however, the technology element remains the trickiest to address, given that technology compliance rarely fails in one dramatic moment, but instead it shifts over time to a different realm. Couple this with operational compliance on AML, responsible gaming, and reporting, to mention a few, and what individually does not look serious, put together in the same audit report reads badly.
Holding a mock audit, both from the technology front, and the other regulatory elements, allows the licensed operator to run the same checklist an MGA auditor would for the audit, but run informally a few months beforehand thus giving management a candid picture while there is still time to act. It is also a test of available evidence, which is where audits are often won or lost: sampled player files, backup restoration evidence, monitoring alerts and how they were closed, the complaints log, and minutes showing that the board actually oversaw any of this.
The system audit checks the technical build against the licence and the MGA's System Audit Checklist. It is part of onboarding, but it can come back later. Significant changes to critical gaming components are exactly the sort of event after which the Authority may want a fresh look: a move to a new platform, a hosting or database migration, the replacement of the RNG or game server, or a change of nodes on a private cloud set-up.
Anyone who for instance has lived through a platform migration will understand why this is a dangerous moment. The cut-off date is driven by commercial pressure. Getting players back online comes first, and documentation, logging and access controls get tidied up afterwards, if at all. A system audit at that point would examine a system that was rebuilt in a hurry.
A mock systems audit specifically on the beta environment, shortly before the change and ideally before the notification if files with the MGA, is the sensible precaution. It should confirm that the system documentation describes the new architecture rather than the old one, and that logging, replication, backups all work in the live beta environment, before the MGA provides the go-ahead to go publicly live. . Game and RNG certifications should have carried across, and game and jackpot settings should be unchanged where they ought to be. Change management and the separation of environments need to work in practice and not only on paper.
A mock audit needs to emulate the real audit, otherwise it’s purpose is greatly diminished. Using the MGA's own checklists rather than the company’s internal templates is key, so as to ascertain that when the real thing occurs, the evidence produced is exactly what the auditor will be asking for. It is essential that whoever is running the mock exercise is looking at the systems and procedures with an ‘outsider’s perspective’ as otherwise the exercise may be futile. A proper mock exercise would be used to turn every finding into an action with a named owner and a date, and have the gap or finding re-tested before the formal audit starts.
Engaging on such mock exercises at least three months before the expected engagement is usually the best approach, as it leaves room to fix things properly while the environment being tested is still close to the one the auditor will see a couple of months later.
The MGA's audits are built to confirm, not to investigate. They assume the licensee knows its own systems and can prove it within a short window. A mock exercise, whether ahead of the system audit, the compliance audit or a systems review after a platform change, is simply how a licensee makes sure that the assumption holds.
The cost of having a breaches report, an extension request, the need to re-audit or the MGA now watching more closely, is far higher than the cost to perform a mock audit exercise. Furthermore, there is a less tangible benefit as well, that is an operator that has already found and fixed its own problems tends to deal with the Authority and the external auditor from a position of confidence, and that is usually evident during the actual audit.
GTG’s compliance and technology arms have been carrying out mock systems and / or compliance audits for the past 8 years, allowing our clients to face MGA’s audits confidently. GTG’s mock exercises do not only emulate the actual audits, but they also serve as a Gap Analysis exercise and as a dress rehearsal for the operators key people that would have to respond and provide evidence to the MGA auditor. Should you wish to learn more about how GTG’s mock audits can be a value added to your MGA operation, kindly contact our advisory partner Reuben Portanier.