Skip to content

Regulatory Frameworks for Core Banking Systems in Southeast Asia

Core banking system vendors entering Southeast Asian markets must navigate a complex web of banking regulations and technology risk guidelines. Each country – Singapore, Vietnam, Thailand, Malaysia, and Indonesia – has its own regulatory bodies and frameworks governing financial technology. These rules affect retail and commercial banks, new digital-only banks, and in some markets, Islamic banks. Key considerations include data residency, personal data protection, system uptime requirements, notification duties, Shariah compliance, cybersecurity standards, and recommended certifications. This report compares the regulatory landscape across the five countries, highlighting country-specific requirements and strictness, to inform a core banking provider’s strategic compliance planning.

Singapore

Regulatory Body: The Monetary Authority of Singapore (MAS) oversees banks and technology risk. MAS is the central bank and unified financial regulator. Singapore also has the Personal Data Protection Commission (PDPC) for personal data laws.

Key Frameworks and Guidelines: MAS has issued comprehensive guidelines on technology risk and outsourcing:

  • Technology Risk Management (TRM) Guidelines (2021): Detailed best practices for managing IT risks. Accompanied by MAS Notice on TRM (Notice FSM-N05, 2024) which imposes binding requirements on banks.
  • Outsourcing Guidelines (2016): Requirements for risk management of outsourced services, including cloud computing. Banks must ensure service providers (e.g. core banking vendors) meet MAS’s expectations for confidentiality, security, and regulator access.
  • Business Continuity Management: MAS expects robust BC planning; critical systems must have quick recovery (aligned with TRM requirements).
  • Digital Bank Framework: Digital banks licensed by MAS must comply with the same MAS rules as traditional banks, with emphasis on strong IT governance.

Data Residency and Local Infrastructure: Singapore does not mandate local data centers for banks. MAS permits cloud and cross-border data outsourcing but requires rigorous risk assessments and controls. Banks must ensure that outsourcing abroad does not hinder MAS’s supervisory access or violate banking secrecy. Under Singapore’s Personal Data Protection Act (PDPA), personal data can only be transferred overseas if equivalent protection is assured or with consent. This means core banking vendors can host data outside Singapore provided they uphold PDPA standards and the bank has confidence in data security and availability. There is no blanket data localization rule, reflecting Singapore’s generally flexible yet risk-based approach.

Handling of Personal Data (PII): Banks in Singapore must comply with the PDPA 2012 for customer personal data. This entails obtaining consent for data collection and using personal data only for stated purposes. Banks also abide by Banking Act confidentiality provisions which impose strict bank secrecy (customer financial information cannot be disclosed without consent or legal basis). Core system vendors handling bank customer data are typically bound by contractual and legal confidentiality to meet these laws. MAS guidelines require banks to ensure third-party vendors protect customer information from unauthorized access or disclosure. In practice, vendors should implement strong data encryption, access controls, and data segregation when serving Singapore banks.

Data Storage and Retention: Singaporean banks are required to retain transaction and customer records for set minimum periods, both for regulatory compliance and audit. For example, MAS anti-money-laundering rules mandate keeping records (e.g. customer due diligence, transactions) for at least 5 years after the transaction or account closure. This ensures auditability. Core banking systems must facilitate archival of data and logs in compliance with these retention periods. Data can be kept in electronic form as long as it’s admissible in court. Banks also need to maintain audit trails of system activities, with MAS expecting timely retrieval of records during inspections.

System Uptime and Downtime Penalties: MAS has very strict requirements on core system availability. Unscheduled downtime for each critical system must not exceed 4 hours in any 12-month period. Banks are also required to recover any critical banking service within 4 hours of disruption (Recovery Time Objective of 4 hours). These rules mean a core banking outage cannot last long, nor happen frequently, without breaching regulations. MAS takes supervisory action if a bank exceeds these limits. For example, after a major outage, MAS forced a bank to engage independent experts and even imposed additional capital requirements as a penalty. Core banking vendors must design highly resilient systems (with redundancy, failover, etc.) to meet Singapore’s stringent uptime standards.

Notification of Downtimes or Changes: MAS requires incident reporting within 1 hour of discovery of a major system incident. Banks must notify MAS promptly about outages or severe system malfunctions. Planned maintenance downtimes are generally managed by banks internally, but if a scheduled change is significant (e.g. a core system replacement or major downtime affecting customers), banks typically inform MAS as a courtesy and ensure customer communication. Under MAS Outsourcing rules, any material system outsourcing or migration (like moving core banking to a new vendor or cloud) should be communicated to MAS early. While MAS approval is not formally required in most cases, regulators expect advance engagement with MAS on major outsourcing arrangements to ensure risks are addressed. In summary, unexpected issues must be reported immediately, and big changes should not surprise the regulator.

Shariah Compliance: Singapore’s banking sector has a limited Islamic banking presence. There are no specific Shariah regulations for core banking IT because Islamic banking is not a major segment. Any Islamic banking products offered would be under MAS’s general framework. Thus, no special Shariah compliance requirements apply to core system vendors in Singapore beyond conventional risk and compliance checks. (By contrast, Malaysia and Indonesia have detailed Islamic finance regimes – see their sections below.)

Cybersecurity and IT Risk Guidelines: MAS is known for robust cybersecurity guidelines that cover banks and extend to their vendors:

  • MAS TRM Guidelines devote extensive sections to cybersecurity controls (access management, incident response, cryptography, etc.). MAS explicitly mandates certain baseline controls via the Notice on Cyber Hygiene (e.g. multi-factor authentication, timely security patching, malware protection, secure admin accounts). Banks must ensure these controls apply to outsourced systems as well.
  • Incident Response: Banks must have 24/7 monitoring and an incident response plan. Significant cyber incidents (like system breaches or attacks) must be reported to MAS within hours and a detailed root-cause analysis submitted within 14 days.
  • Penetration Testing and Audits: MAS expects regular independent vulnerability assessments of critical systems. Vendors providing core platforms might be asked to undergo penetration tests or provide service organization control (SOC) reports.
  • Regulator Access: Under outsourcing rules, MAS reserves the right to audit service providers. Core banking vendors may be required to grant MAS inspectors access to their operations or independent audit reports. Overall, Singapore’s regime emphasizes international standards and best practices in cybersecurity. The MAS TRM guidelines align with ISO/IEC 27001 controls, and MAS encourages banks to leverage standards like NIST or ISO for their security frameworks.

Certifications and Standards: While not explicitly mandated by law, Singapore banks often require their tech vendors to have internationally recognized certifications. ISO/IEC 27001 (information security management) is commonly expected to demonstrate strong security controls. For any solutions dealing with payment card data, PCI DSS compliance is necessary (per card network rules, supported by MAS expectations). MAS itself references standards like ISO 27001, 27017 (cloud security), 27018 (cloud privacy) and PCI-DSS as relevant benchmarks. Additionally, having ISO 22301 (business continuity) or ISO 27032 (cybersecurity) can bolster a vendor’s credibility. In summary, certifications are highly recommended in Singapore as proof of alignment with best practices, even if not legally required.

Vietnam

Regulatory Body: The State Bank of Vietnam (SBV) is the central bank and principal regulator for banking activities. The SBV issues regulations on banking operations and IT risk for banks. In addition, the Ministry of Public Security (MPS) plays a role in cybersecurity (enforcing the Cybersecurity Law), and the new Personal Data Protection Commission (under the Ministry of Public Security) oversees personal data protection rules.

Key Frameworks and Guidelines: Vietnam’s regulatory framework for bank IT has evolved significantly in recent years:

  • SBV Circular No. 18/2018/TT-NHNN: A crucial regulation on “assurance of information systems safety and security in banking operations”. Effective 2019, this circular updated prior rules and introduced requirements for system classification and cloud usage. It classifies bank IT systems by importance (Level 1 = normal, Level 2 = important, Level 3 = especially important) with corresponding uptime requirements.
  • Cloud Computing Regulations: Circular 18/2018 imposes specific conditions before a bank can use third-party cloud services. Banks must conduct IT risk assessments and classify which operations will go on cloud. They must also set criteria for cloud provider selection (e.g. provider must be an enterprise established in Vietnam). Contracts with cloud vendors must include provisions for the vendor to provide IT audit reports and allow supervision of service quality. These rules directly affect core banking vendors offering cloud-based systems to Vietnamese banks – local presence and auditability are key.
  • Law on Cybersecurity (2018) & Decree 53/2022: These impose data security and localization obligations on certain services. Banks, being critical infrastructure, are expected to comply with any cybersecurity requirements such as local data storage for sensitive data and cooperation with authorities. (Details under Data Residency below.)
  • Draft Personal Data Protection Law (Decree 13/2023): Vietnam’s first comprehensive personal data protection regulations, effective 2023, set out how PII must be handled (consent, purpose limitation, etc.). Banks must align their data processing with these rules.

Data Residency and Local Data Centers: Vietnam has strict data localization tendencies. Under the Cybersecurity Law and Decree 53, both domestic and foreign service providers in Vietnam are required to store certain data (including personal information of Vietnamese users) on servers located in Vietnam. For foreign companies, if authorities determine their services are used to violate the law or they don’t cooperate with law enforcement, they can be ordered to locate data and a local office in Vietnam within 12 months. In practice, virtually all Vietnamese banks keep their core banking systems and customer data in-country. Circular 18/2018 reinforces this by effectively requiring cloud providers for banks to be locally incorporated, which implies using local data centers. There is no explicit SBV rule outright banning offshore hosting, but the layered regulations make overseas core banking deployment impractical. A core banking vendor should plan to utilize Vietnam-based data centers or partner with local cloud providers when serving this market.

Handling of Personal Data (PII): Vietnam’s legal regime for PII is rapidly maturing. The new Personal Data Protection Decree (13/2023) establishes principles for processing personal data: requiring consent for collection/use of personal data, providing rights for data subjects, and placing restrictions on sensitive data. Although as of 2025 Vietnam doesn’t have a standalone PDPA law like others, this decree functions similarly. Banks must secure customers’ personal and financial data, and vendors processing such data must implement protective measures (encryption, access controls, etc.) to comply. Separately, the Law on Cybersecurity also requires organizations to protect users’ personal information and to verify and secure user data. In sum, core banking vendors in Vietnam should treat customer PII with GDPR-level care – ensure consent is obtained by the bank, data is stored securely (preferably in Vietnam), and not shared without authorization.

Data Storage and Retention: Vietnamese regulations require banks to maintain thorough records for audit and oversight. Circular 18/2018 itself classifies data by confidentiality but does not specify exact retention periods. Other laws fill the gap: for instance, the Law on Credit Institutions and SBV guidelines likely mandate retaining accounting and transaction records for a number of years (often 10 years for financial records in Vietnam’s banking practice). Additionally, anti-money-laundering rules (e.g. Vietnam’s AML Decree) typically require banks to keep customer identification and transaction logs for at least 5 years. Core banking systems should support archival of historical data to meet these retention requirements and provide readily accessible audit trails. Given the regulatory emphasis on security, vendors may need to implement secure backup and recovery solutions (possibly with backups stored domestically as well).

System Downtime and Reliability: Vietnam’s SBV expects high availability for critical banking systems, though the rules are framed slightly differently from Singapore’s. Under Circular 18’s classification: an “Important Information System” (Level 2) is defined in part by having non-operating (downtime) periods not exceeding 4 working hours. This implies that for any important banking system (which would include core banking), any planned downtime should be under 4 hours and availability should be around the clock for customer-facing services. In practice, Vietnamese banks strive for minimal downtime; prolonged outages could draw SBV scrutiny. While there isn’t a published numeric penalty (like MAS’s 4-hour rule), an outage beyond a few hours or a pattern of instability would likely trigger regulatory intervention. Vendors should ensure robust failover and quick disaster recovery for deployments in Vietnam.

Regulatory Notifications: Banks in Vietnam are generally required to report major incidents to the SBV, especially if they affect customer services or data security. For instance, a significant core system failure or data breach would need to be communicated to the SBV promptly (though specific time frames may be defined in internal SBV guidelines rather than publicly available rules). Circular 18/2018 obliges banks to have incident response processes, and it’s expected that banks notify the SBV of incidents that could disrupt operations or compromise data. Scheduled changes such as a core banking migration would typically require SBV approval or notification if they fall under large-scale IT projects. While Vietnam doesn’t have a formal “notify X hours in advance” rule for planned downtime, banks often coordinate with SBV for major system go-lives or migrations, to ensure regulatory comfort. In summary, any core system vendor should be prepared that their client bank might ask for detailed risk assessments to submit to SBV before using the vendor’s solution (especially if it’s a cloud-based core or a significant change).

Shariah Compliance: Vietnam does not have Islamic banking as part of its mainstream financial system, hence no Shariah-specific regulations apply. There are no Islamic banks in Vietnam requiring Shariah governance. Core banking vendors do not need to account for Islamic finance principles in this market. The focus remains on conventional banking compliance only.

Cybersecurity Guidelines: Vietnamese regulators enforce cybersecurity through a combination of SBV directives and national law:

  • SBV IT Security Circular 18/2018: Imposes requirements for security controls based on system classification. For example, higher-classified systems must implement stronger access control, monitoring, and encryption measures. Banks must also periodically evaluate vulnerabilities and have an information security committee in place. The Circular introduced formal requirements for third-party cloud security (risk assessments, audits) as noted above.
  • National Cybersecurity Law (2018): Treats banking as critical infrastructure, so banks must conform to standards set by the government for network security. This can include mandatory annual network security exercises and audits by authorities. Banks may be required to undergo inspections by the MPS for cyber readiness. Vendors, consequently, might have to cooperate with these audits or information requests through their client bank.
  • Cyber Incident Response: Banks are expected to report cyber incidents (like data breaches) to the authorities. The law and subsequent regulations (Decree 85/2016 on information system security by classification) likely compel banks to notify regulators of incidents affecting “important” or “especially important” systems. A core banking breach would fall in this category, necessitating immediate containment and notification.
  • Standards Alignment: Vietnam has been moving towards international standards – for example, many banks adopt ISO 27001 and PCI DSS on a voluntary basis. The SBV has encouraged improving cyber maturity; indeed, a recent SBV strategy aims for most banks to use cloud and modern security by 2025. While not explicitly codified, using standards like ISO 27001 or following frameworks like PCI DSS for card data can demonstrate compliance with the broad requirements of ensuring data security and safety.

Certifications and Standards: Vietnamese regulations do not mandate specific certifications, but in practice banks prefer vendors with strong credentials. ISO/IEC 27001 certification (or equivalent security attestations) for a core banking vendor can be a significant differentiator when SBV approval is needed for using that vendor. Circular 18/2018’s requirement that a cloud provider furnish IT audit reports suggests that independent audits (e.g. SSAE18 SOC 2 reports or ISO 27001 certificates) are expected to verify the provider’s security. For handling card data in core banking, compliance with PCI DSS is necessary (Vietnam’s card networks and international networks require it). Additionally, Vietnam’s approach to data privacy is aligning somewhat with global norms, so adherence to standards like ISO/IEC 27701 (privacy information management) could become relevant. In summary, while not explicitly required by law, demonstrating adherence to international standards greatly facilitates regulatory approval in Vietnam’s banking sector.

Thailand

Regulatory Body: The Bank of Thailand (BOT) is the central bank and main regulator for banks and financial services. The BOT issues policy guidelines and notifications that banks must follow. Thailand also established a Personal Data Protection Committee (PDPC) under the PDPA for personal data issues, and a National Cybersecurity Committee under the Cybersecurity Act (2019) that oversees critical information infrastructure, including banking.

Key Frameworks and Guidelines: Thai banks operate under a range of regulations that impact core banking systems:

  • BOT Notifications on IT Risk and Outsourcing: The BOT has specific rules for technology outsourcing by banks. Notably, Notification No. FPG 19/2559 (2016) on IT Outsourcing sets out conditions for using cloud services and third parties. It distinguishes between strategic functions and non-strategic functions, requiring prior BOT approval for outsourcing certain functions and ensuring providers meet qualification criteria. In essence, critical systems like core banking can be outsourced only if the bank maintains oversight and the vendor meets BOT standards (financial stability, competent service, etc.).
  • IT Security Guidelines: The BOT issued policies on IT security measures (e.g., an earlier notification SorNorSor 8/2557 and updates) which outline baseline security controls for banks. These align with international practices in access control, data security, and network resilience.
  • Bank of Thailand Virtual Bank Framework (2022–2023): Thailand is introducing digital-only banks. The BOT’s virtual bank licensing guidelines require applicants to have independent, robust IT systems. For instance, virtual banks must not share critical IT systems (like core banking) with other institutions, to ensure full control and accountability. They also must meet all existing IT risk regulations plus additional scrutiny on technology governance. This indicates that any vendor serving a virtual bank in Thailand will face close regulatory evaluation.
  • Personal Data Protection Act (PDPA) 2019: Though not banking-specific, this law (effective June 2022) imposes obligations on banks as data controllers. It also influences how vendors handle customer data on behalf of banks.
  • Cybersecurity Act 2019: Designates banking as critical infrastructure, meaning banks must implement cybersecurity standards and potentially submit to government cyber audits or drills.

Data Residency Requirements: Thailand does not have explicit data localization laws for banking as some neighbors do. Banks are allowed to use cloud or overseas data centers, provided they comply with BOT oversight requirements. Before using foreign-based services, a bank must ensure the provider can meet Thai regulations and that regulators and auditors will have access to data. In practice, many Thai banks keep primary systems in Thailand, but some use regional or global data centers for certain functions (with BOT’s knowledge). The PDPA adds a constraint on cross-border personal data transfers: personal data may not be transferred out of Thailand unless the destination country has adequate data protection standards or appropriate safeguards are in place. There are exemptions (such as customer consent, contract necessity, or approved Binding Corporate Rules). For a core banking vendor, this means if hosting Thai customer data abroad, they must ensure PDPA conditions are satisfied (often done via contracts with EU-standard clauses or obtaining consent). While BOT doesn’t mandate local hosting, it will look at risk, data criticality, and recovery – a core system holding critical data offshore might be acceptable only if strong controls and legal arrangements ensure Thai authorities’ access when needed.

Handling of Personal Data (PII): Thai banks must abide by the Personal Data Protection Act B.E. 2562 (2019). The PDPA is largely modeled on GDPR principles: requiring consent or other legal basis for data processing, giving individuals rights to access/correct their data, and imposing breach notification duties. Banks as data controllers must have agreements with any data processors (like an IT vendor) to ensure PDPA compliance. Core banking vendors handling customer PII need to implement appropriate security measures and possibly assist the bank in fulfilling data subject rights (e.g., retrieving or deleting data upon request). Under PDPA Section 28 and related regulations, cross-border data transfers require either an adequacy decision by the PDPC or use of standard contractual clauses/safeguards. As of 2025, the PDPC has begun issuing guidance (e.g., rules in late 2023 for cross-border transfer conditions). In summary, any core banking system for Thailand must support data privacy compliance – e.g., segregating personal data, allowing extraction for PDPA requests, and protecting data as per PDPA security standards.

Data Storage and Retention: Thai law and regulations require banks to retain certain data for defined periods. For instance, anti-money laundering laws compel banks to keep customer identification and transaction records for 5 years (common across many jurisdictions). Separately, the Thai Civil and Commercial Code and Revenue Code often effectively require financial records to be kept for 5–10 years. In practice, most Thai banks keep extensive archives (7 years is a common business practice for general records). The BOT may have specific rules for retention related to electronic banking transactions or audit trails, ensuring that records are available for supervisory review. Core banking systems in Thailand should therefore have features to store transaction history and customer account data for extended periods (often up to 7–10 years) either online or in backups, and be able to reproduce these records for regulators. The PDPA’s data minimization principle does require that personal data not be kept longer than necessary, but financial regulations usually override this by defining “necessary” as at least those regulatory minimum years. Banks will balance these by purging data after the required period. Vendors should allow configurable retention policies to meet both regulatory and PDPA requirements.

System Downtime and Reporting: The Bank of Thailand expects banks to manage IT reliability proactively, though it doesn’t publicly dictate a fixed maximum downtime like MAS. Instead, Thai regulators emphasize service continuity and prompt incident handling. Banks are required to report major IT disruptions to the BOT immediately, especially if customer-facing services (ATM networks, online banking, etc.) go down. The BOT has previously shown concern over repeated outages among Thai banks, pushing for improvements. For example, if a core banking failure led to a multi-hour nationwide outage, the BOT could demand a remediation plan or even take enforcement action for weak IT controls (this is somewhat analogous to how MAS reacts, though BOT’s thresholds might be less formally defined). Scheduled downtimes (like maintenance) typically must be done in agreed maintenance windows, and banks usually notify customers in advance. There isn’t a specific rule to notify the BOT of routine maintenance, but if a planned system upgrade is large-scale (such as a core banking replacement requiring a long cutover window), the BOT would expect to be informed as part of the oversight process. Overall, Thai banks have internal policies aligning to an IT Service Availability target (often 99.9% uptime for critical services). A vendor should design the core system for high availability (clustering, disaster recovery). Additionally, given the Cybersecurity Act, if an incident is due to a cyber-attack causing downtime, the bank might need to report it to the National CERT or cybersecurity regulators within a specified time. Vendors should support forensic analysis and timely recovery to help the bank fulfill these duties.

Shariah Compliance: Thailand has a very small Islamic banking sector (e.g. one state-owned Islamic Bank of Thailand). There are no extensive Shariah regulations for commercial banks as seen in Malaysia or Indonesia. The Islamic Bank of Thailand operates under a separate act but for general commercial banks, Shariah compliance is not a factor. Thus, core banking vendors in Thailand typically do not need to provide specialized Islamic banking modules unless specifically serving that one Islamic bank. For completeness, any service to the Islamic Bank of Thailand would need to allow operation without interest (using profit-sharing, etc.), but that is a niche case. In broad terms, Shariah requirements are not applicable in the Thai regulatory environment for core banking systems.

Cybersecurity Guidelines: Thailand’s approach to cybersecurity in banking is codified in both BOT guidelines and national law:

  • BOT IT Security Policy: Banks must implement robust information security programs. The BOT expects banks to follow frameworks akin to ISO 27001. Controls like multi-factor authentication for sensitive transactions, encryption of sensitive data, and continuous monitoring are emphasized. The BOT issued guidance in 2020 requiring commercial banks to enhance cyber resilience (post some high-profile breaches in the region). Banks are also encouraged to conduct cyber drills and penetration tests regularly.
  • Personal Data Security (PDPA): Section 6 of the PDPA and associated regulations require banks (and their processors) to maintain appropriate security measures to protect personal data from unauthorized or accidental access, alteration, or loss. The PDPC has published security standards that effectively align with ISO27001’s controls (access control, encryption, etc.). Non-compliance can lead to penalties under PDPA.
  • Cybersecurity Act (2019): For critical infrastructures like banking, this law empowers the government to impose certain cybersecurity standards and incident reporting. Banks may need to undergo compliance audits and must report severe cyber incidents to the National Cybersecurity Agency. While this is more macro-level, a core banking vendor should be aware that any serious breach in a bank’s core system could involve government agencies beyond the BOT (for instance, the bank might have to allow government cyber investigators to review the system).
  • Incident Reporting: Thai banks are generally expected to inform the BOT of cyber incidents immediately. The BOT often coordinates with the Thailand Computer Emergency Response Team (ThaiCERT) on sector-wide threats. Vendors may be called to assist in incident response. Overall, Thailand urges banks to benchmark against global standards. It’s common for Thai banks to achieve ISO/IEC 27001 certification for their IT operations and require key vendors to do the same. The BOT doesn’t list specific certifications in regulations, but having them is considered good practice. The BOT also participates in regional cyber resiliency initiatives, so banks in Thailand push their IT providers towards strong cybersecurity postures.

Certifications and Standards: Although not explicitly mandated by the BOT, having recognized certifications significantly eases compliance in Thailand. Many banks will prefer core banking vendors with ISO/IEC 27001 for information security and ISO/IEC 20000 for IT service management, reflecting a mature process. If the core banking system handles payment cards, PCI DSS compliance is a must (the Thai Bankers’ Association enforces PCI standards for any card-related systems). Furthermore, vendors might consider aligning with the Bank of Thailand’s IT Audit guidelines, which likely reference COBIT or similar frameworks; being certified or audited for those can be beneficial. The new digital banks are likely to demand certified systems since they have to prove to regulators that their outsourced technology meets top security and reliability standards. In summary, while Thai regulations don’t explicitly list certifications, the market expectation is that vendors adhere to international standards (with ISO 27001 and PCI DSS being most pertinent) to ensure trust and smooth regulatory approval.

Malaysia

Regulatory Body: Bank Negara Malaysia (BNM) is the central bank and regulator for banking and insurance. BNM is very active in issuing detailed regulatory policy documents that banks must follow. Malaysia also has a dedicated Islamic banking regulatory framework, as well as a Personal Data Protection Department (under the communications ministry) enforcing personal data laws.

Key Frameworks and Guidelines: Malaysia’s regulations affecting core banking systems are particularly comprehensive:

  • BNM Risk Management in Technology (RMiT), 2019 (updated 2023): A landmark policy document that lays out BNM’s requirements for FIs on technology risk management. RMiT covers governance, operations, cybersecurity, data center standards, and more. It explicitly addresses expectations for outsourcing and cloud in Appendix 10 (2023 update). Banks and their critical IT service providers must adhere to RMiT’s principles.
  • BNM Outsourcing Guidelines (2018, updated): These rules require banks to obtain prior written approval from BNM before entering any new material outsourcing arrangement. A core banking system provided by a vendor usually qualifies as a material outsourcing of IT infrastructure. Thus, banks must submit an application to BNM and get consent before engaging a core system vendor or making major changes. Non-material outsourcings must still be recorded and subject to BNM review upon request.
  • Shariah Governance Policy (2019): For Islamic banks, BNM’s Shariah Governance framework ensures all operations (including IT systems supporting Islamic products) comply with Shariah. Islamic banks must have Shariah Committee approvals for new products and possibly systems.
  • Digital Banking Framework: BNM awarded digital bank licenses in 2022 with a framework that includes stringent technology risk expectations. These new digital banks must follow RMiT and show robust, secure IT architecture from day one.
  • Personal Data Protection Act (PDPA) 2010: Though overseen by a different authority (JPDP), it applies to banks and their IT processing of personal data.

Data Residency and Local Data Centers: Malaysia historically leaned towards on-shore data hosting for banks, and this is evident in BNM’s stance. Under BNM RMiT, banks can outsource IT infrastructure including cloud, but BNM’s prior approval is required for material outsourcings, especially if they involve cross-border data transfer. BNM permits overseas outsourcing only if the bank addresses additional risks (country risk, access issues) and ensures the foreign host provides equal oversight and recovery capabilities. In practice, many Malaysian banks keep their core banking systems and primary data center domestically, often due to regulatory preference and data sovereignty concerns. BNM doesn’t outright ban foreign data centers, but conditions are stringent – for example, the bank must ensure regulators and auditors have full access to data even if stored abroad, and that data is not subject to foreign laws that breach Malaysian confidentiality. Additionally, the PDPA 2010 restricts transferring personal data overseas unless the recipient country is whitelisted by the government or certain safeguards (or consent) are in place. As of now, no official whitelist exists, so transfers require individual conditions (like consent or contractual clauses). Combining these, a core banking vendor offering a cloud solution to a Malaysian bank will likely need to set up a local data center or use a Malaysia availability zone to satisfy BNM. At minimum, keeping a secondary copy of data in Malaysia is often expected. Overall, data residency is a critical consideration: Malaysia stands out for insisting on local control, even if not an absolute mandate, through its approval process and risk requirements.

Handling of Personal Data (PII): Malaysia’s PDPA 2010 governs how banks and vendors treat personal data. Banks must obtain consent for personal data processing, disclose purposes, and protect the data against misuse. They also must honor individuals’ rights to access and correct their data. Under PDPA, personal data should not be kept longer than necessary, which ties into data retention policies. For vendors, this means they will be contractually obligated to implement PDPA-compliant measures: e.g., not using customer data for anything outside the bank’s instructions, providing reasonable security (the PDPA’s Security Principle), and notifying the bank of any data breaches. Notably, financial institutions in Malaysia are also bound by BNM’s secrecy provisions in the Financial Services Act and Islamic Financial Services Act, which prohibit disclosing customer information to unauthorized parties. Any core banking vendor must sign confidentiality undertakings to comply with these secrecy laws. Furthermore, if the vendor handles credit card data or other sensitive info, additional sectoral guidelines (like by Payments Network Malaysia for card security) come into play.

Data Storage and Retention: BNM’s expectations on record-keeping are strict. Under various guidelines (including AML/CFT rules and possibly RMiT), banks must retain transactional and customer records typically for at least 6 to 7 years. For example, BNM’s AML regulations (similar to MAS 626) require at least 6 years retention after a transaction or account is closed. The Malaysian Companies Act also mandates businesses to keep accounting records for 7 years. Therefore, core banking systems in Malaysia need to ensure no data is prematurely purged and that archival mechanisms are in place. BNM RMiT specifically mentions that banks should maintain complete and up-to-date records of system activities and ensure audit logs are retained to facilitate forensic investigations. Additionally, the Shariah Governance framework for Islamic banks may require documentation of Shariah-related decisions and transactions (e.g. contracts, profit calculations) to be kept for regulator or Shariah committee review. Vendors must accommodate these retention needs, possibly storing data encrypted if on cloud but accessible onshore when required.

System Downtime and Unscheduled Outages: BNM’s RMiT establishes clear metrics for system availability. Unplanned downtime for critical systems (especially customer-facing channels) is capped at a cumulative 4 hours over any 12-month period, with no single incident exceeding 2 hours. In August 2024, BNM underscored this by fining major banks for outages that breached these limits. This requirement is very much in line with MAS’s rule, reflecting a regional trend for near-zero downtime tolerance. Core banking vendors must engineer systems with high availability (99.9% uptime or better). Disaster Recovery (DR) expectations are similarly stringent – RMiT mandates that critical systems have a Recovery Time Objective (RTO) not more than 2 hours (120 minutes) per incident. Banks are expected to test failovers to meet this RTO. If a vendor-hosted system goes down beyond these thresholds, the client bank faces regulatory penalties, so the vendor will be under intense pressure to avoid such incidents. BNM has shown it will use enforcement (fines, supervisory actions) if outages indicate insufficient IT controls. Consequently, any core system provider in Malaysia should have local support, emergency response teams, and possibly dual-site setups (production and DR site) ideally both in Malaysia to rapidly recover services.

Regulatory Notification of Downtime/Changes: BNM requires banks to notify the central bank of major IT incidents promptly (the exact timeframe might be specified in RMiT or an incident reporting rule). Generally, banks should inform BNM as soon as possible after critical system failures or cyber incidents so that BNM is not caught off guard. Scheduled core banking system downtimes, if part of an approved change, do not always require direct notification, but if a downtime could significantly impact customers (e.g., an extended outage during a migration), BNM would expect advance notice and possibly an approval. Moreover, because material system changes often fall under the outsourcing policy, a planned core system replacement or migration is typically pre-approved by BNM. As part of that, the bank must present a robust transition plan including any downtime. In summary, unscheduled outages – notify immediately; scheduled major changes – seek approval/notify well in advance. BNM also often engages with banks in supervisory meetings about IT projects, so a core vendor might indirectly be subject to questions or assessments via the bank.

Shariah Compliance Requirements: Malaysia has a dual banking system (conventional and Islamic banks). For Islamic banking operations, Shariah compliance is a legal requirement under the Islamic Financial Services Act (IFSA) 2013. BNM’s Shariah Governance Policy mandates that Islamic banks have internal Shariah Committees overseeing all aspects of operations. For a core banking system vendor, this means: if the vendor’s system is to be used in an Islamic bank (or an Islamic window of a bank), it must support Islamic banking products and accounting. For instance, the system should be able to handle profit-sharing investment accounts, calculate profit instead of interest, prevent interest posting, segregate Islamic funds from conventional, and enforce any Shariah-compliant contract terms. During implementation, the bank’s Shariah Committee will likely review the system workflows for compliance. While there is no separate “IT certification” for Shariah, BNM requires any new product or system that could affect Shariah compliance to be approved by the Shariah Committee. Additionally, BNM’s Shariah Advisory Council issues binding resolutions – e.g., on hibah (gifts), tawarruq transactions – and the core system must be configurable to adhere to these rulings. In practical terms, a core banking vendor entering Malaysia should either have an Islamic banking module or be prepared to customize their software to meet Shariah requirements. This is a unique aspect of Malaysia (and Indonesia) not present in the other markets. Failing to support Shariah compliance could exclude the vendor from nearly half the banking market, given Malaysia’s large Islamic finance sector.

Cybersecurity Guidelines: Malaysia’s BNM RMiT is very detailed on cybersecurity expectations:

  • Governance: Banks must establish a robust IT risk governance structure, including appointing a dedicated Chief Information Security Officer (CISO) and team. The board and senior management are accountable for cyber risk oversight.
  • Baseline Security Controls: RMiT specifies controls such as multi-factor authentication for system administrators, secure coding practices for software, encryption of data at rest and in transit, and continuous monitoring of networks. Banks are required to implement network resilience measures and have 24/7 security monitoring.
  • Testing: Regular penetration testing and vulnerability assessments are mandated for critical systems. BNM even suggests engaging qualified external testers to ensure independent assessments.
  • Cyber Incident Response: Banks must report significant cyber incidents to BNM within hours and follow up with investigation reports. BNM may require an incident to be escalated to law enforcement if it involves breaches of customer data. RMiT also instructs banks to participate in sector-level cyber drills.
  • Third-Party Security: Importantly for vendors, BNM expects banks to ensure service providers uphold equivalent security standards. Contracts with vendors should include right-to-audit, requirement to comply with bank’s security policies, incident reporting duties, and BCP arrangements. If a core banking vendor operates a cloud service, BNM’s 2023 RMiT update (Appendix on Cloud) provides additional controls – e.g., data segregation in multi-tenant environments, robust encryption key management (preferably keys controlled by the bank), and ensuring cloud providers obtain relevant certifications.
  • Cyber Hygiene and Surveillance: BNM often aligns with global cyber guidance. For example, after some regional Swift payment hacks, BNM required banks to strengthen endpoint security and user access management. Vendors might need to implement specific security configurations (like compliance with CIS benchmarks or Swift CSP for payment modules). In short, Malaysia’s cyber regulations are among the strictest in the region, on par with Singapore’s. A core banking provider must demonstrate an advanced security posture – likely through audits – to satisfy BNM and client banks.

Certifications and Standards: BNM doesn’t explicitly list required certifications in RMiT, but it’s almost implicit. ISO/IEC 27001 certification is commonly pursued by Malaysian banks to comply with RMiT’s broad requirements. BNM itself often expects banks to benchmark against ISO standards. In fact, many Malaysian banks will only consider vendors who are ISO 27001 certified or can produce a recent SOC 2 Type II report, as part of their vendor due diligence (which BNM scrutinizes). PCI DSS is mandatory for any system touching card data – BNM has endorsed the Payment Card Industry Data Security Standard through its payment department oversight. Additionally, RMiT mentions data center resilience – typically Malaysian banks use Tier III or Tier IV certified data centers to satisfy uptime and redundancy criteria. BNM doesn’t mandate Uptime Institute certification per se, but RMiT’s specifications essentially map to Tier III standards (concurrently maintainable infrastructure, etc.). ISO 22301 (Business Continuity) is another relevant standard given BCP importance; banks or their key providers often have this to prove robust disaster recovery processes. For Islamic banking aspects, there’s no ISO standard – compliance is validated by Shariah audits and the Shariah Committee. In summary, to align with regulatory expectations in Malaysia, a core banking vendor is strongly advised to have multiple internationally recognized certifications (ISO 27001, PCI DSS, etc.) and adhere to standards like ITIL for service management and COBIT for IT governance, as these will be looked upon favorably by both BNM and the banks’ own risk committees.


Comparative Summary Table

Below is a side-by-side comparison of key regulatory factors across Singapore, Vietnam, Thailand, Malaysia, and Indonesia as they pertain to core banking system vendors and their client banks:

Aspect Singapore (MAS) Vietnam (SBV) Thailand (BOT) Malaysia (BNM) Indonesia (OJK)
Regulatory Body & Scope Monetary Authority of Singapore (integrated regulator) – issues MAS Notices and Guidelines for banks. State Bank of Vietnam – central bank issuing banking and IT circulars. MPS oversees cybersecurity law enforcement. Bank of Thailand – central bank issuing notifications; PDPC for data protection under PDPA. Bank Negara Malaysia – central bank with detailed tech risk policies; separate PDPA authority (JPDP). Also dual conventional/Islamic banking oversight. Otoritas Jasa Keuangan (Financial Services Authority) – regulates banks; Bank Indonesia co-regulates payments. New comprehensive IT regulations via OJK.
Key IT Risk Frameworks MAS TRM Guidelines (2021) – comprehensive IT risk management practices. MAS Notice on TRM (2024) – sets binding rules (e.g. 4-hour recovery). Outsourcing Guidelines (2016) – risk management for third-party IT. SBV Circular 18/2018 – info systems safety, classifies systems & regulates cloud use. Cybersecurity Law 2018 and decrees – impose security and data rules. Draft PDP decree 13/2023 – personal data protection rules. BOT IT Outsourcing Notification (2016) – requires approval for key IT outsourcing. BOT IT Security policies – baseline cybersecurity measures. PDPA 2019 – data protection law affecting banks. 2023 Virtual Bank rules – additional IT criteria. BNM RMiT (2019, updated 2023) – detailed mandatory tech risk management (covers cyber, DC, cloud). BNM Outsourcing Policy – BNM approval needed for material IT outsourcing. Shariah Governance Policy – Islamic banks’ operations compliance. PDPA 2010 – data protection law (separate enforcement). OJK Regulation 11/2022 – new comprehensive IT implementation rules for banks (replaced older 2016 regs). OJK Reg 9/2016 – outsourcing prudential principles. OJK Circular 29/2022 – cybersecurity and resilience guidelines. Personal Data Protection Law 2022 – general data protection.
Data Residency No strict localization: Data can be offshore with proper controls. MAS allows cloud/outsource abroad if confidentiality & MAS access assured. PDPA restricts cross-border transfer unless adequate protection or consent. Generally flexible, but banks often keep critical data readily accessible in SG. Strict localization: Cybersecurity Law + Decree 53 mandate local storage of Vietnamese users’ personal data. Banks use local DCs; Circular 18 effectively requires cloud providers to be Vietnam-based. Cross-border data transfer is sensitive and typically avoided. Moderate: No explicit law forcing local DCs, but PDPA requires adequacy or safeguards for overseas transfers. BOT allows cloud/overseas outsourcing if provider meets qualifications & risk mitigated. Many banks keep core systems in TH for comfort, but hybrid models exist. Strong localization preference: BNM often expects critical systems hosted in Malaysia. Overseas outsourcing allowed only with BNM approval and risk mitigation. PDPA prohibits sending personal data abroad without consent or equivalent protection. Most banks maintain primary DC and data in-country, using foreign cloud only under strict conditions. Strict: Regulation 11/2022 requires banks to locate data centers and DR centers in Indonesia unless OJK permits otherwise. Default rule is local DC for all banking systems. Cross-border data storage needs OJK approval. Aligns with Indonesia’s broader data sovereignty laws.
Personal Data Protection PDPA 2012: Consent-based, covers customer PII. Banks must protect customer info and ensure vendors do likewise. Banking Act secrecy also applies. Cross-border: must ensure comparable protection abroad. Mandatory breach notification to PDPC for significant leaks. Draft PDP Decree (2023): Lays down consent requirements, purpose limitation, data subject rights. Not yet an Act, but in force as decree. Cybersecurity law adds obligations to protect user data. In practice, banks treat customer data confidentially by law; breaches could invoke MPS action. PDPA 2019: GDPR-like. Requires consent or legal basis, data subject rights, and “adequate standard” for foreign transfers. Financial data also protected by banking secrecy under Financial Institutions Business Act. Data processors (vendors) are directly liable under PDPA for security and misuse. PDPA 2010: Requires consent for processing personal data and reasonable security measures. Cross-border transfer tightly restricted (no whitelist in effect). Banking secrecy under BNM’s laws adds another layer – customer info cannot be divulged except under permitted situations. Vendors must sign confidentiality undertakings. Personal Data Protection Law 2022: Modeled after GDPR, mandates consent, rights, and data security. (Transition period into 2024 for full enforcement.) Banking Law secrecy provisions also protect customer financial data. Transfers abroad require certain conditions (e.g., similar protection level or explicit consent). Vendors need compliance programs for new PDP law.
Data Retention & Audit Trails Typically 5 years minimum for key records (e.g. transactions, KYC) per MAS/AML rules. Many banks keep 7 years or more. Core systems must retain audit logs and data to satisfy regulators and allow investigations. Electronic records acceptable if reproducible. Common practice \~5–10 years for banking records (no single law; various requirements). E.g., SBV/AML rules = 5 years for transaction data. Accounting laws lean to 10 years. SBV expects robust audit logs for IT systems; Circular 18 requires ability to trace and audit changes. 5 years is standard for AML and finance records, 10 years for some company records. BOT examiners expect to see several years of history in core systems. PDPA says not to keep data longer than needed, but regulatory needs define “needed”. Banks balance both by purging after min. periods. 6–7 years minimum retention: AML/CFT rules = 6 years; Companies Act = 7 years. BNM likely expects \~7 years of records accessible. RMiT requires maintaining complete and accurate logs and records for audit and investigations. Islamic banks also retain records to demonstrate Shariah compliance decisions. >5 years common. Banking regulations (e.g., anti-fraud, AML) require at least 5 years. Some Indonesian laws require 10-year retention for certain documents. OJK’s IT rules mandate banks keep logs of all IT activities and be able to provide data to regulators on request. Strong audit trail capability is a must.
Uptime & Downtime Limits Highly stringent: Critical systems downtime <4 hours per year max. RTO (recovery time) for core systems ≤4 hours. MAS penalizes breaches (e.g., additional capital requirements). Essentially 99.9% availability expected. Strict for critical systems: SBV defines important systems as those with downtime ≤4 hours per incident. 24/7 service expected for customer-facing functions. While no explicit annual cap, prolonged outages would violate SBV’s standards and invite intervention. Banks target >99.9% uptime. High expectation but no fixed number: BOT expects “continuous service”. No formal 4-hour rule, but serious outages must be reported and justified. Banks generally aim for 99.9% uptime. Repeated or extended downtimes would prompt BOT scrutiny. Virtual banks explicitly must ensure robust uptime (since no branches). Highly stringent: RMiT sets 4 hours max cumulative downtime/year, 2 hours max per incident for critical channels. BNM enforced this via fines in 2024. RTO targets often 2 hours or less for core systems. Essentially zero tolerance for prolonged outages, matching MAS-level strictness. Strict: OJK requires robust continuity – implicit expectation of near 24/7 operations for core banking. Regulation 11/2022 likely requires banks to set short RTOs (e.g., 4 hours). While an explicit “4 hour” rule isn’t widely publicized, large outages (ATM network down, etc.) lead to OJK sanctions. Banks strive for Tier III reliability.
Incident Reporting Notify MAS within 1 hour of discovering major IT incidents (system outage or breach). Detailed root cause analysis due within 14 days. MAS monitors incident trends closely. Planned core system changes – coordinate with MAS in advance, though formal approval not always needed. Notify SBV: Banks should report critical incidents promptly (guidance but not public exact timing). Cybersecurity incidents may also need reporting to regulators under law. Typically, any outage or breach with broad impact is quickly elevated to SBV. Major IT projects (core upgrades) often need SBV sign-off. Notify BOT ASAP: Banks inform BOT of major service disruptions or breaches in a timely manner (internal rule of thumb: within hours). The Cybersecurity Act could require reporting severe cyber incidents to the national agency. BOT expects proactive communication; for significant upgrades/downtime, banks often brief BOT beforehand. Notify BNM promptly: RMiT mandates immediate notification of “material incidents” (exact timeframe likely within hours). Banks must also file incident reports post-recovery. BNM approval is needed ahead for major changes (new core system, etc.) via outsourcing application, so scheduled migrations are pre-discussed. Notify OJK: Under OJK’s cybersecurity circular, banks must report cyber incidents to OJK and even provide self-assessed cyber risk ratings annually. Any major system failure would be reported swiftly to OJK’s Banking Supervision. Planned major IT changes (core system relocations, etc.) often require OJK notification/approval, especially if involving new DC or vendor.
Shariah/Islamic Banking Not applicable (no separate Islamic banking framework in MAS regime). A few Islamic windows follow general MAS rules. No special IT requirements beyond product-level compliance. Not applicable (Vietnam has no Islamic banking sector). Minimal: One Islamic bank exists separately. Most banks don’t have Shariah operations. Thus, core vendors usually don’t need Islamic functionality for Thailand. Highly relevant: \~half the industry is Islamic. BNM requires Islamic banks to comply with Shariah laws, overseen by Shariah committees. Core systems for Islamic banks must support Shariah-compliant contracts (no interest, profit-sharing, zakat calculations, etc.). BNM checks that IT systems do not trigger Shariah non-compliance. Highly relevant: Large Islamic banking sector. OJK and the National Sharia Board (DSN-MUI) ensure Shariah compliance. Islamic banks must have Shariah Supervisory Boards that will vet the core system’s adherence to Islamic finance principles. Vendors need to support Islamic product structures (e.g. murabahah, mudharabah) and reporting.
Cybersecurity Requirements MAS TRM & Notices: Banks must implement strong cyber controls (MFA, encryption, logging). MAS Notice on Cyber Hygiene mandates specific measures. Regular penetration testing and threat monitoring required. Critical systems must be resilient to attacks (DDoS, etc.). Vendors subject to bank’s oversight and MAS’s right to audit. SBV Circular 18: Enforces security by system tier – higher-tier systems need stricter access control, etc. Banks must do IT risk assessments annually. Cyber Law: banks (as CI) must allow govt inspections if needed and follow any additional MPS security guidelines. Independent audits of IT security for third-party providers are required before use. BOT Guidelines: Banks should align with ISO 27001 and other best practices. PDPA Security Principle requires appropriate security measures for personal data. Cybersecurity Act: Banks may be audited by the Thai Cybersecurity Agency for compliance. Emphasis on network security, incident response and user protection (e.g., transaction monitoring to prevent fraud). BOT encourages industry cyber drills. BNM RMiT: Very granular cyber controls – e.g., 24/7 Security Operations Center, secure software development, data loss prevention. Periodic IT audits and penetration tests mandated. Banks must also ensure vendors comply (contractually enforce infosec controls). BNM’s 2023 update provides cloud-specific security controls. Reporting of cyber incidents to BNM is compulsory, and banks should join Cyber Threat Intelligence programmes. OJK Cyber Circular 29/2022: Banks must perform annual cyber risk self-assessments and report results. They must establish dedicated cybersecurity functions and frameworks. Any cyber incidents must be reported to OJK. Technical requirements likely align with international standards (firewalls, IDS/IPS, access management, etc.). BI also has security rules for payment systems that banks must follow.
Required/Recommended Standards ISO 27001 recommended (MAS aligns with ISO27001 controls in TRM). PCI DSS required if handling cards. MAS also references ISO 27017/27018 for cloud security/privacy. Not legally mandated but banks strongly prefer certified vendors. Other common standards: ISO 22301 for BCM, SOC 2 reports for cloud services. No specific mandate, but ISO 27001 or equivalent audit reports effectively required by SBV for cloud providers. Banks likely require vendors to have strong international certifications to satisfy SBV due diligence. PCI DSS compliance needed for card-related systems (via card network rules). No explicit requirement in regs. However, ISO 27001 is widely adopted by banks; vendors are often asked for it. PCI DSS mandatory for card data environment. Thai PDPC accepts standard contractual clauses akin to GDPR – implies alignment with international privacy standards. Overall, global standards are considered best practice, though not spelled out by law. Expected by BNM: While not itemized in RMiT, ISO/IEC 27001 certification (or similar) is effectively expected for critical IT providers. Banks must do due diligence – having ISO 27001, Tier III DC certification, PCI DSS (for cards) greatly facilitates approval. BNM has cited international standards as benchmarks in various guidance. Strongly encouraged: OJK’s rules emphasize meeting “best practices”. Many banks insist on ISO 27001 certified vendors and ISO 22301 for BCM. The regulator itself might ask if a service provider has relevant certifications during approval. PCI DSS is required by Indonesian payment networks for any card processing part of core. Given data center rules, even Uptime Institute Tier certifications for DCs in Indonesia are relevant.

Sources: The above comparison references each country’s regulatory documents and official guidelines, such as MAS Notices, SBV Circular 18/2018, BOT notifications and PDPA provisions, BNM’s RMiT policy, and OJK regulations, among others, to ensure accuracy and currency of the information. This comparative overview can serve as a strategic guide for core banking system providers to tailor their compliance and product strategies for each Southeast Asian market.