1. Risk Management Policy

Risk management is about understanding and managing the risk environment and taking measures, where necessary, to ensure that risks are contained to acceptable levels consistent with the risk appetite for the relation to products and services in which TMEX Pty Ltd offers to its clients. This document sets out, at a high level, a policy for managing this process.

Scope

This policy applies to all TMEX Pty Ltd (The Company). It forms part of the company governance framework and applies to all employees, contractors, and volunteers.

Objectives

The objective of the Risk Management Policy is to ensure the implementation of an effective risk management framework consistent with the company achieving its policy and operating objectives. In doing so, it follows accepted standards and guidelines for managing risk.

The principle underpinning the company’s approach is that risk management is an integral part of the management function in the organisation and, as such, is the clear responsibility of management. As TMEX Pty Ltd is a currency exchange provider, it must identify different kinds of risks it may face, document them in the AML/CTF program, and take necessary steps to manage them at acceptable levels.

General Responsibilities

Compliance Officer: Provides policy oversight, review of risk management, transaction monitoring, fraud management, AML program oversight, and staff training.

Technology Leads: Continuously improve risk management policy, strategy, and supporting IT framework.

Staff: Comply with risk management policies and procedures.

Policy

The company's framework endeavors to cover the full spectrum of risks faced by the company through evaluating risk from a business perspective. This framework is consistent with the accepted Australian standard (ISO 31000-2018 Risk Management) and comprises several important steps, which are documented in the AML/CTF program of TMEX Pty Ltd:

• Identifying and analyzing the main risks facing the company.
• Evaluating those risks and making judgments about whether they are acceptable or not.
• Implementing appropriately designed control systems to manage these risks in a way that is consistent with the Company's Risk Management Policy.
• Treating unacceptable risks by formulating responses following the identification of unacceptable risks, including actions to reduce the probability or consequences of an event and formulating contingency plans.
• Documenting these processes, with summary tables (risk registers) as the main forms of documentation, supplemented by risk manuals or related documents as appropriate.
• Ongoing monitoring, communication, and review.
• While the framework is applied consistently across the company, individual areas must identify and analyze the risks in their areas, assess the controls in place to deal with those risks, and make decisions about whether to mitigate a particular risk—fully or partially—given its effects and the costs of mitigation. If a residual risk is judged to be unacceptable, the ‘owner’ area is responsible for developing and implementing/overseeing a remedial plan.
• Where risks are considered ‘cross-sectional’ or ‘common’—that is, owned by one area and managed by another (e.g., IT-related risks)—a process is established for ensuring that the risks are both communicated and action is agreed upon between the concerned areas.
• Processes are also in place to facilitate appropriate liaison and consultation with external entities whose activities could inform the company’s risk environment.

2. Access Control Policy

This policy outlines the rules relating to authorizing, monitoring, and controlling access to TMEX Pty Ltd through developed applications and information systems.

Scope

This policy applies to any person or system that is granted or grants access to accounts, information, or information systems owned, developed, or operated by TMEX Pty Ltd (The Company).

Objectives

Compliance with this policy enables consistent controls to be applied to all applications and information systems, minimizing exposure to security breaches while allowing developers, customers, systems, and security administration and technical support staff to conduct their activities within the framework of the law.

This policy aims to ensure that, by having the appropriate access controls in place, the right information is accessible by the right people at the right time and that access to information, in all forms, is appropriately managed and periodically audited.

General Responsibilities

All personnel (e.g., employees, contractors, vendors, and third parties) working with the company must abide by relevant information security and access control policies and procedures.

• Only use their account and access in accordance with the company’s Code of Practice.
• Secure their credentials in line with the password guidance.
• Be responsible for the systems, services, and data within their control.

Access Control Implementation - Developer Guideline for Identity Management Implementation

• All applications must be password protected where necessary, and only authenticated users can access the applications.
• Implement two-factor authentication (SMS and Google Authenticator) for all administrator-level application access.
• All logins must be developed role-based so that users can only perform actions limited to their access and role level.
• Formal user registration and de-registration processes must be implemented to enable the assignment of identities and accounts on an individual basis.
• Provide access to information, accounts, systems, and resources based on the principle of least privilege.
• Implement a One-Time Password (OTP) system where possible; dynamic PINs work as extra layers of protection.
• Recommendation to implement mandatory password changes to significantly reduce security risks by enforcing regular password updates for customers and application users.
• An easy-to-track monitoring system should be in place to detect and analyze suspicious activity. Additionally, a solution to prevent data breaches by blocking an account after several suspicious transactions should always be implemented.

Database Access Control Guidelines

• Our database access should be blocked on the internet, and only applications running in the same Virtual Private Cloud (VPC) should be allowed to access the database with their username and password with restricted permissions.
• Only database administrators should have access to databases via a secure tunnel or a virtual private network.

4. Information Security Policy Scope

All processes, activities, and assets are within the scope of this information security mail, especially:

• Implementation and maintenance of information systems
• Secure development
• Intellectual property and sales / contractual information protection
• Human resources security
• Data and information exchange procedures and interfaces with regulatory authorities, contractual workers, clients, and other relevant parties.

Objectives

• Confidentiality – only individuals with authorization should access data and information assets.
• Integrity – data should be intact, accurate, and complete, as well as IT systems must be kept operational.
• Availability – users should be able to access information or systems when needed.
• Create an overall approach to information security.
• Detect and preempt information security breaches such as misuse of networks, data, applications, and computer systems.
• Maintain the organization's reputation and uphold ethical and legal responsibilities.
• Respect customer rights, including how to react to inquiries and complaints about non-compliance.

Policies, Procedures, and Guidelines

All the Information Security policies and their needs have been addressed below:

1. Information Risk Management Procedure

Detailed risk assessments for information risks shall be undertaken to identify threats, vulnerabilities, and potential impacts. This assessment shall determine acceptable, transferable, and avoidable risks and risk treatments.

2. Access Control Policy

Data must have sufficient granularity to allow authorized access while maintaining security.

3. E-mail Security Policy

TMEX Pty Ltd shall implement systems and procedures to ensure efficient business communication and prevent misuse of the email facility.

4. Internet & Intranet Security Policy

TMEX Pty Ltd should utilize the Internet for business efficiently while ensuring security against unauthorized access.

5. Password Security Policy

All passwords must:

• Be at least eight characters long
• Contain at least one number and one special character
• Expire every six months

6. Application Security Policy

Ensuring proper procedures, access controls, and security requirements for software development and maintenance.

7. Operating System Security Policy

Protecting operating system resources at a level appropriate for the data being processed.

8. Backup & Recovery Policy

Systems and procedures for the backup of business data must be standardized and monitored regularly.

9. Log and Audit Trail Policy

Establishing a framework for logging and auditing system events.

10. Version Control Policy

Managing and controlling version changes in application systems, add-ons, network software, and operating systems.

11. Data Archival Policy

Addressing proper archival of project-related data as per client requirements.

12. Encryption Policy

Using cryptography to meet Information Security Management System (ISMS) requirements.

13. Data Migration Policy

Ensuring proper handling of data migration between systems/databases.

14. Data Security

Implementing physical, technical, and organizational security measures to protect personal data.

15. Database Security Procedure

Ensuring confidentiality, integrity, availability, and accountability of databases.

16. Key Management Procedure

Establishing techniques and procedures for cryptographic key relationships.

17. Cloud Computing

Assessing cloud computing requirements for data security, privacy, legal compliance, and business continuity.

18. Digital Security of Systems Containing Our Data

• Encrypting data at rest using AES-256
• Blocking database access on the Internet
• Using TLS protocol for encryption in motion
• Allowing API requests only over HTTPS
• Implementing geography-based firewalls

19. Physical Security of Systems Hosting Application & Data

All data is hosted on Amazon Web Services (AWS). More details can be found at AWS Data Center Physical Security.

6. Business Continuity Plan & IT Disaster Recovery Plan

Scope

This policy applies to any person or systems that are developed or operated by TMEX Pty Ltd (The Company).

Objectives

The purpose of this policy is to define what would happen to our product(s) if any of the following services running in AWS region XYZ experienced an outage (S3, RDS, Dynamo, SNS, SES, Lambda, etc.).

• How long before we fully recover?
• How much data loss would we incur?
• What process would we follow to recover?
• How would we communicate the status and next steps internally?
• How would we communicate the status and next steps to customers?

These questions quickly reminded us that DR planning requires direction from the business.

Recovery Objectives

• Recovery Time Objective (RTO): The length of time it would take us to swap to a second, hot production service in a separate AWS region.
• Recovery Point Objective (RPO): The acceptable amount of offline time measured in time.

Policy & Procedure

This checklist provides possible initial actions that you might take following a disaster.

Plan Initiation

1. Notify senior management.
2. Contact and set up a disaster recovery team.
3. Determine the degree of disaster.
4. Implement a proper application recovery plan dependent on the extent of the disaster.
5. Monitor progress.
6. Notify users of the disruption of service.

Application & API (Web Services)

All Web services we develop are server-less and auto-scalable. We can redeploy our web services from our CI/CD channel in different availability regions within <15 minutes in case of disaster and redirect all traffic. The UI component will be hosted as static web content and JavaScript.

Database

Failure of the database will be low as we have two instances of the database in two different availability zones. If one data center is affected, the second instance will be available for service.

Disaster Recovery for Database

• Option 1: Restore data using the point-in-time feature.
• Option 2: Restore the database from the latest snapshot.
• Option 3: Restore data from the daily backup (cloud storage).
• Option 4: Restore data from an off-site daily backup.