Ann: Terminal connectivity issue, page-120

Of course they can criticise them. Here are some basics they could and should have done:

1. Test the firmware in lab
2. Test the firmware in field on very small select friendly and easy to touch
3. Notify customers that a firmware update was taking place and allow them to nominate the preferred time by an online form which would digitally schedule them
4. Do post firmware follow up surveys digitally to gauge any issues
5. Assess the merchants low or idle time based on historic transaction times and set this as the default time
6. Do no more than batches or 1%, 3%, 5%, 7%, 10%, 25% etc incremental post batch assessments which validate success
7. If the firmware was of significantly high risk identified in steps 1, 2 & 4, advance ship patched and setup units as an option in step 3 and return existing units (repeat)
8. Have a disaster plan which already fully planned for such an unlikely scenario and exactly the steps that would be taken to limit impact and recover services
9. Have a crisis management plan which included a suspension of trading of shares until the crisis could be understood, disclosed, and resolved.

IMO the full nature or the issue and its impact to an orderly trading of our stock could not be guaranteed and warranted a suspension. The likelihood of suspicion and possibility of certain parties being availed information not available to all holders either indirectly or inadvertently was very real and high. Not suspending trading allowing and continues to allow sustained losses due to this poor crisis management.

This all goes directly to the skill of those in charge and responsible. I say many times to all my peers, the quality of a technology engineering is measured in the outage response not the ability to follow an instruction manual in build phase.