2025

Customer First - Why Prioritizing Customer Needs Beats Chasing Resources

In today’s fast-moving world, companies often face a fundamental question: Should we prioritize resources or customers? For many, the answer seems obvious—resources drive innovation, scale, and growth. But in reality, neglecting customer needs is one of the fastest ways for a business to lose relevance.

Many companies that once thrived eventually plateau—not because they stop innovating, but because they stop innovating for the customer. They shift their attention toward internal efficiency, competitor benchmarking, or stakeholder management. In doing so, they lose sight of the very people who fuel their business: their customers. One classic example is when businesses continue investing in new features or technologies that seem impressive but fail to meet what their customers actually want—whether that’s better entertainment, smoother communication, or easier access to information. This disconnect is what decoupling theory refers to. It shows us that stagnation isn’t a symptom of lacking creativity—it’s often the result of a company turning inward instead of outward.

Let’s be clear: putting customers first doesn’t mean blindly giving in to every request. It means making strategic decisions with the customer at the core. When leaders prioritize customer insight over internal politics, or long-term satisfaction over short-term gains, they create solutions that resonate. Being customer-centric means asking: What pain point are we really solving? How will this decision enhance the customer’s experience or outcome? Are we building loyalty or just checking boxes?

Most successful startups begin with a deep understanding of their customers' unmet needs. This empathy drives their initial growth and adoption. But as they scale, many fall into the same trap as incumbents—focusing on partnerships, processes, or prestige rather than people. The antidote? Never lose that connection to your customer.

At its core, this is a conversation about priority and purpose, not compliance. When customer value becomes the North Star, every other decision—resource allocation, technology investment, marketing strategy—falls into place. So ask yourself: Is your company listening to customers or just surveying them? Are your priorities aligned with what your customers truly need? Are you building for them—or building around them?

The companies that win aren’t just the ones with the most capital or the best technology. They’re the ones who never forget who they’re building for. In the choice between resources and customers, always bet on the customer.

顧客至上 - 為什麼優先考慮顧客需求比追逐資源更重要

在這個瞬息萬變的時代，企業經常面對一個根本性的問題：我們應該優先考慮資源，還是顧客？對許多人來說，答案似乎顯而易見——資源驅動創新、擴展與成長。但事實上，忽略顧客需求是企業最容易失去市場相關性的方法之一。

許多曾經成功的公司最終陷入停滯，不是因為他們停止創新，而是因為他們停止為顧客而創新。他們的注意力轉向內部效率、競爭對手分析，或利益關係人的需求，結果反而忽視了企業最重要的力量來源：顧客。經典的例子包括企業持續投入看似炫目的新功能或技術，但這些東西卻無法真正滿足顧客的實際需求，例如更好的娛樂體驗、更順暢的溝通或更容易取得資訊。這種脫節正是「脫鉤理論」所指出的問題。它告訴我們，企業停滯的原因往往不是缺乏創意，而是企業的關注點從外轉向了內部。

當然，把顧客放在首位並不代表要盲目地滿足他們的每一個要求。它的真正含義是在做出關鍵決策時，始終以顧客為核心。當領導者能夠將顧客洞察置於內部政治之上，並優先考慮長期滿意度而非短期利益時，他們就能創造真正有共鳴的解決方案。以顧客為中心，意味著我們應該不斷反問自己：我們真正解決的是什麼痛點？這個決策是否能改善顧客的體驗或結果？我們是在建立忠誠，還是在敷衍了事？

多數成功的新創企業，都是從深刻理解顧客的未被滿足需求出發的。正是這種同理心，推動了它們早期的成長與擴展。但隨著企業規模壯大，許多公司卻掉入與傳統企業相同的陷阱——將焦點從顧客轉移到合作夥伴、流程或企業聲望。要避免這種情況，唯一的方法就是：永遠不要失去與顧客的連結。

本質上，這是一個關於「優先順序與目標」的問題，而不是「服從與否」的問題。當顧客價值成為企業的北極星時，所有其他決策——資源配置、技術投資、市場策略——都會自然地排列到正確的位置。所以你應該問問自己：你的公司是在傾聽顧客，還是只是例行調查？你的優先事項是否與顧客真正的需求一致？你是在為顧客建構價值，還是繞著他們在運作？

最終，真正成功的企業，從來不只是那些資本最多、技術最先進的，而是那些永遠不會忘記自己為誰而建的企業。在資源與顧客之間，請永遠選擇顧客。

From Insight to Impact - How Applying What You Read Makes You a Better Leader

Like many aspiring leaders, I once believed that reading business books from cover to cover would somehow make me a better leader. I highlighted key lessons, absorbed powerful insights, and felt a sense of accomplishment just by finishing them. But over time, I realized that simply reading wasn’t enough. Not even close.

The true shift happened when I started asking myself a simple but powerful question during my second read-through: “How will I change my behavior because of this?” That question marked the beginning of a deeper transformation. I started highlighting not just what was interesting, but what resonated with my strengths. I wrote down how I would apply those lessons. That’s when the real work began.

This is where so many well-meaning leaders lose their way. They think that reading a book makes them better. But the truth is: until you apply what you’ve learned, you haven’t even started the journey. Leadership isn’t about collecting ideas; it’s about changing how you show up every day. Knowledge is only the beginning—what you do with it is what defines your growth.

I made a list of changes I was going to make. I shared it with others. I asked for guidance from people who had walked the same path, who had wrestled with the same questions. I wanted to know what worked for them, and what didn’t. Those conversations kept me honest and helped me stay committed.

Of course, it wasn’t easy. In the early days of leadership, I was consumed by chaos. There were always more problems than hours in the day. I felt like being a student was a luxury I couldn’t afford. I was just trying to survive—just trying to keep the lights on. I believed that grit, hustle, and resilience were enough. I thought I could lead by simply working harder than everyone else—being the first one in and the last one out. I told myself that work ethic and charisma would carry me through.

I was wrong.

I had the instincts. I had the drive. But I lacked the discipline to grow intentionally. I knew how to sound smart in meetings. I could drop the right buzzwords and fake confidence when I needed to. But deep down, I knew it couldn’t last. One particularly tough meeting opened my eyes. I realized I had to change—not just how I worked, but how I learned.

Leadership isn’t about having all the answers. It’s about knowing your strengths and relentlessly refining them. It’s about recognizing your weaknesses and surrounding yourself with people whose strengths complement your own. Most people understand that in theory, but few commit to the practice. And that’s what separates good leaders from great ones.

Over time, I learned that leadership requires you to stay a student—forever. It demands humility. It demands consistency. And it demands the courage to keep learning, even when you feel like you should already know it all. I’m still on that journey. I’m still reading, still reflecting, still asking how I’ll change my behavior because of what I’ve learned.

The biggest mistake I made was believing that learning was enough. It’s not. The real transformation lies in the application. That’s where growth happens. That’s where leadership is born—not in the pages of a book, but in the choices you make after you close it.

I’ve been clumsily applying what I’ve learned from the greatest minds in business, and in doing so, I’ve slowly begun to shape a leadership style that’s my own. I’m deeply grateful for the thought leaders who’ve lit the path. And I remain humble—and hungry—to keep learning, keep applying, and keep growing.

Because leadership isn’t something you claim. It’s something you earn—every single day.

從洞察到影響力 -應用所學如何讓你成為更好的領導者

像許多有抱負的領導者一樣，我曾經以為只要把商業書籍從頭讀到尾，就能讓自己成為更好的領導者。我畫重點、吸收箴言，對自己讀完一本書感到滿足。但隨著時間推移，我逐漸意識到：光是閱讀，遠遠不夠。

真正的轉捩點，是當我在第二次閱讀時開始問自己一個簡單但深刻的問題： 「我會因為這段話改變自己的行為嗎？」 這個問題，讓我的思維產生了質變。我開始不只劃出有趣的內容，而是找出與我優勢相符的觀點，並寫下我會如何實踐。從那一刻起，真正的功課才開始。

許多有心的領導者常在這一步迷失。他們以為讀完一本書，就代表自己進步了。但事實是：在你真正應用學到的知識之前，你甚至還沒開始成長。領導不是知識的累積，而是你每天如何展現這些知識的結果。學習只是起點，真正塑造你的是你的行動。

我列下因閱讀而決定要改變的具體行為，並與他人分享。我向那些走過相同道路的人請教，他們也曾經歷一樣的掙扎。我想知道他們實踐後的成果與失敗，這些交流讓我更加堅定地走下去。

當然，這過程並不輕鬆。領導的早期階段充滿混亂，總有解不完的問題，時間永遠不夠用。我曾經覺得學習是奢侈，因為我每天都在忙著讓公司運作。我以為，只要有堅韌與拼勁就夠了。我努力工作，比任何人都早到、晚走，認為只要夠努力、夠有魅力，就能成為好領導。

我錯了。

我有本能、有幹勁，但我缺乏刻意成長的紀律。我知道怎麼在會議中講得頭頭是道，也會用流行語術掩飾自己的不安。但我心裡知道，這樣撐不久。一次會議讓我徹底清醒。我開始明白，自己需要的不只是努力，而是徹底改變學習的方式。

真正的領導，並不是什麼都懂，而是清楚知道自己的強項，並持續精進。同時也能正視自己的弱點，並建立一支團隊，成員的強項能互補而非重複。很多人明白這個道理，但真正能持續實踐的人卻不多。而這，正是卓越領導者與一般領導者的分水嶺。

我學到，領導者必須永遠保持「學生心態」。要謙虛、要穩定、要有勇氣在任何階段都不斷學習，即使你已經身居高位。我至今仍在這條路上，依然閱讀、反思，每一次都問自己：「我會因此改變嗎？」

我曾經犯過最大的錯誤，就是以為學習本身就夠了。事實不是這樣。真正的轉變，發生在你把學到的知識「付諸行動」的時候。那才是成長的起點，領導力也是在這裡誕生的——不是在書頁中，而是在你闔上書本後的每一個選擇裡。

我一路跌跌撞撞地應用從頂尖商業思想家那裡學來的觀念，也正是在這樣的實踐中，我慢慢地發展出屬於自己的領導風格。我由衷感激這些知識領袖為我指引方向，也謙遜地持續尋找新的導師、新的啟發。

因為領導力，從來不是一張證書或頭銜。 它是一場每天都要重新贏得的修練。

Monte Carlo Method - From Statistics to Smart AI Agents

The Monte Carlo Method is one of the most powerful and versatile tools in the world of computation and statistics. Though it might sound like a gambling strategy from a casino, it's actually a rigorous and indispensable approach for solving complex problems through randomness and probability. In this blog post, we’ll explore what the Monte Carlo Method is, why it matters, and how it powers applications like game-playing AI through Monte Carlo Tree Search (MCTS).

What is the Monte Carlo Method?

The Monte Carlo Method refers to a class of computational algorithms that rely on repeated random sampling to obtain numerical results. The core idea is to simulate a system or process many times over and analyze the outcomes to make estimations or predictions.

Instead of trying to solve a complex problem analytically—especially when a closed-form solution is impossible—the Monte Carlo approach uses probabilistic simulation. This makes it ideal for high-dimensional, non-deterministic, or chaotic systems.

A Simple Example

Let’s estimate the value of π using a Monte Carlo method:

1. Imagine a square enclosing a quarter circle.
2. Randomly throw points into the square.
3. Count how many fall inside the quarter circle vs. the whole square.
4. The ratio of the points in the circle to the square approximates π/4.

Multiply that ratio by 4, and you get an approximation of π.

Why is it Important in Statistics?

In statistics, the Monte Carlo method is vital for:

• Simulating distributions: Especially when analytical forms are unavailable.
• Solving integrals: Particularly in high dimensions where traditional methods fail.
• Risk analysis and forecasting: By simulating scenarios with random variables (e.g., financial models).
• Bayesian inference: Monte Carlo methods underpin techniques like Markov Chain Monte Carlo (MCMC), essential for posterior sampling in Bayesian analysis.

Applications in Artificial Intelligence

The Monte Carlo method has had a profound impact on AI, especially in areas involving uncertainty, exploration, and decision-making.

1. Monte Carlo Tree Search (MCTS)

One of the most notable applications is Monte Carlo Tree Search, a heuristic search algorithm used for decision processes, particularly in games.

How MCTS Works:

MCTS is used to determine the best move by simulating many random playouts of a game. It balances two core principles:

• Exploration: Trying out less-visited branches to discover potentially better outcomes.
• Exploitation: Favoring branches that have historically yielded good results.

The process involves four steps:

1. Selection: Traverse the tree from root to leaf using a selection policy (e.g., UCT: Upper Confidence Bound for Trees).
2. Expansion: Add a new child node to the tree.
3. Simulation: Run a random simulation from this new node to the end of the game.
4. Backpropagation: Update the nodes on the path based on the result.

MCTS powered DeepMind’s AlphaGo, which defeated world champions in Go—a game considered intractable for traditional AI approaches due to its immense search space.

2. AI Agents and Planning

Beyond games, Monte Carlo methods help AI agents deal with uncertain environments and incomplete information. In reinforcement learning, for example:

• Monte Carlo methods can estimate the expected return by sampling episodes.
• They're useful in policy evaluation and improvement when the environment model is not known.
• Partially Observable Markov Decision Processes (POMDPs) often rely on Monte Carlo simulations for belief updates and planning.

Other Use Cases

• Physics: Simulating particle interactions.
• Finance: Valuation of derivatives, portfolio risk analysis.
• Robotics: Localization and mapping (e.g., Monte Carlo Localization).
• Medicine: Dose distribution modeling in radiation therapy.

Final Thoughts

The Monte Carlo Method’s brilliance lies in its simplicity and flexibility. By embracing randomness, it offers a practical way to approximate solutions to problems that are otherwise unsolvable. From theoretical statistics to high-performance AI systems, its impact is far-reaching—and as computing power grows, its relevance only continues to increase.

蒙地卡羅方法 - 從統計學到智慧型 AI 智能代理

蒙地卡羅方法（Monte Carlo Method） 是計算與統計領域中最強大且用途廣泛的工具之一。雖然它的名字讓人聯想到賭場策略，但其實這是一套嚴謹且極具實用性的隨機模擬方法，用來解決各種複雜問題。本文將介紹什麼是蒙地卡羅方法、它為何如此重要，以及它在遊戲人工智慧（如蒙地卡羅樹搜尋）與智慧代理中的應用。

什麼是蒙地卡羅方法？

蒙地卡羅方法是一類基於**重複隨機抽樣（random sampling）**來獲得數值解的計算演算法。核心思想是：透過大量模擬實驗來逼近實際結果，尤其是在解析解不可得的情況下。

換句話說，與其嘗試使用代數或微積分精確求解複雜問題，不如使用機率與統計的力量進行模擬與估計。

簡單範例

假設我們想用蒙地卡羅方法估算 π 值：

1. 想像一個正方形中內切一個四分之一圓。
2. 在正方形中隨機投點。
3. 計算落在四分之一圓內的點數與總點數的比例。
4. 此比例約為 π/4，乘以 4 即可估算 π。

為何在統計學中如此重要？

在統計學中，蒙地卡羅方法用於：

• 模擬機率分布：當分布無法用解析式表示時特別有用。
• 解高維積分：傳統數值積分法在高維空間效率低下，而蒙地卡羅方法則仍可適用。
• 風險分析與預測：例如財務模型中的不確定性模擬。
• 貝式推論：如 Markov Chain Monte Carlo（MCMC）在後驗分布取樣中的應用。

在人工智慧中的應用

蒙地卡羅方法在人工智慧中同樣扮演關鍵角色，尤其在不確定性處理、策略搜尋、與決策制定方面。

1. 蒙地卡羅樹搜尋（MCTS）

最著名的應用之一是 Monte Carlo Tree Search（蒙地卡羅樹搜尋），這是一種啟發式搜尋演算法，常用於策略型遊戲與決策系統。

MCTS 的工作流程：

MCTS 藉由模擬大量隨機遊戲進行來選擇最佳決策，其核心在於平衡：

• 探索（exploration）：嘗試新路徑以發現潛在好結果。
• 利用（exploitation）：傾向選擇過去表現佳的選項。

整體流程包含四個步驟：

1. 選擇（Selection）：根據策略從根節點往下選擇子節點。
2. 擴展（Expansion）：新增一個尚未擴展的子節點。
3. 模擬（Simulation）：從該節點進行隨機遊戲模擬至終局。
4. 回傳（Backpropagation）：將結果反向更新至路徑上的節點。

MCTS 是 DeepMind 的 AlphaGo 所採用的核心技術之一，幫助其在複雜的圍棋遊戲中擊敗世界冠軍。

2. 智慧型代理與規劃

在強化學習與智慧代理領域中，蒙地卡羅方法有以下應用：

• 估算回報值：透過樣本來估計策略的預期效益。
• 策略評估與改進：在未知環境下進行政策迭代。
• 部分可觀測馬可夫決策過程（POMDP）：透過蒙地卡羅模擬來進行信念更新與決策。

其他應用範疇

• 物理學：模擬粒子交互與能量分布。
• 金融工程：衍生品定價、風險模型。
• 機器人學：如蒙地卡羅定位（MCL）。
• 醫學：放射治療中的劑量分布模擬。

結語

蒙地卡羅方法的精妙之處，在於它將隨機性變為解題工具。當問題過於複雜、無法解析時，它提供一條可行的數值近似之路。從統計推論到智慧代理，從遊戲 AI 到財務模型，蒙地卡羅方法不僅是數學的藝術，更是現代科學與工程的基石之一。

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:

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.

東南亞核心銀行系統的監管框架

以下是針對東南亞五個主要市場（新加坡、越南、泰國、馬來西亞、印尼）核心銀行系統供應商（如 Neo Core）在零售銀行、商業銀行、數位銀行和伊斯蘭銀行領域的監管要求總結。

🇸🇬 新加坡

• 監管機構：新加坡金融管理局（MAS）(Cloud4C)

• 主要法規：

• 《個人資料保護法》（PDPA）

• 《科技風險管理指引》（TRM Guidelines）

• 《雲端服務指引》(Baker McKenzie Resource Hub, Silverfort)

• 重點要求：

• 資料駐留：無強制要求，但需確保資料跨境傳輸的安全性和合規性。

• 個人識別資訊（PII）處理：需取得明確同意，並遵守PDPA規定。
• 資料儲存與稽核：需保留完整的稽核記錄，並接受MAS或其指定機構的稽核。
• 停機管理：重大事件需通報MAS，並制定業務持續計劃（BCP）。
• 伊斯蘭合規：適用於伊斯蘭銀行，需遵守相關的伊斯蘭金融指引。
• 資訊安全：鼓勵遵循ISO 27001、PCI DSS等國際標準。(Sangfor Technologies, Baker McKenzie Resource Hub)

🇻🇳 越南

• 監管機構：越南國家銀行（SBV）(Moody's)

• 主要法規：

• 《個人資料保護法》（PDPL，預計2026年生效）

• 《網絡安全法》及其實施細則（Decree 53）(Sangfor Technologies, DLA Piper)

• 重點要求：

• 資料駐留：需在越南境內儲存特定類型的資料，包括用戶個人資訊和交易資料。

• PII處理：需取得用戶同意，並遵守PDPL規定。
• 資料儲存與稽核：需保留至少24個月的資料，並接受相關部門的檢查。
• 停機管理：需通報用戶和主管機關，但具體時限和方式尚未明確。
• 資訊安全：需建立資訊安全管理體系，並定期進行風險評估。(Sangfor Technologies)

🇹🇭 泰國

• 監管機構：泰國銀行（BOT）

• 主要法規：

• 《個人資料保護法》（PDPA）

• 《支付系統法》

• BOT相關通知和指引(Baker McKenzie Resource Hub, Deloitte United States, Baker McKenzie Resource Hub)

• 重點要求：

• 資料駐留：無強制要求，但跨境傳輸需確保接收方具備足夠的資料保護措施。

• PII處理：需取得用戶同意，並遵守PDPA規定。
• 資料儲存與稽核：需保留完整的稽核記錄，並接受BOT的檢查。
• 停機管理：需制定業務持續計劃，並定期進行測試。
• 資訊安全：需建立資訊安全管理體系，並定期進行風險評估。(Sangfor Technologies)

🇲🇾 馬來西亞

• 監管機構：馬來西亞國家銀行（BNM）(Thales Cyber Security Solutions)

• 主要法規：

• 《個人資料保護法》（PDPA）

• 《科技風險管理政策》（RMiT）(Thales Cyber Security Solutions)

• 重點要求：

• 資料駐留：無強制要求，但跨境傳輸需確保接收方具備足夠的資料保護措施。

• PII處理：需取得用戶同意，並遵守PDPA規定。
• 資料儲存與稽核：需保留完整的稽核記錄，並接受BNM的檢查。
• 停機管理：需制定業務持續計劃，並定期進行測試。
• 伊斯蘭合規：適用於伊斯蘭銀行，需遵守相關的伊斯蘭金融指引。
• 資訊安全：需建立資訊安全管理體系，並定期進行風險評估。

🇮🇩 印尼

• 監管機構：印尼金融服務管理局（OJK）

• 主要法規：

• 《個人資料保護法》（PDP Law）

• OJK第11/POJK.03/2022號規定(OJK Portal)

• 重點要求：

• 資料駐留：金融機構需將資料儲存在印尼境內，除非獲得OJK批准。

• PII處理：需取得用戶同意，並遵守PDP Law規定。
• 資料儲存與稽核：需保留完整的稽核記錄，並接受OJK的檢查。
• 停機管理：需通報OJK，並制定業務持續計劃。
• 伊斯蘭合規：適用於伊斯蘭銀行，需遵守相關的伊斯蘭金融指引。
• 資訊安全：需建立資訊安全管理體系，並定期進行風險評估。

🌏 比較總結

整體而言，印尼和越南在資料駐留方面的要求較為嚴格，而新加坡、馬來西亞和泰國則在資訊安全和稽核方面有更高的標準。對於核心銀行系統供應商而言，需根據各國的監管要求，調整產品設計和合規策略。

Understanding MCP (Model Context Protocol) - What It Is, How It Works, and Why It Matters

In the rapidly evolving world of AI and large language models (LLMs), context management is becoming a cornerstone for building smarter, more efficient, and reliable applications. Enter MCP (Model Context Protocol) — a protocol designed to help developers and systems define, organize, and control the context passed into AI models. In this post, we’ll explore what MCP is, how it works, and real-world use cases that demonstrate its value.

🔍 What is MCP (Model Context Protocol)?

MCP, or Model Context Protocol, is an open protocol for specifying and managing the context that gets sent to language models. Context, in this sense, refers to the structured information provided to an LLM during inference—everything from user inputs and chat history to documents, tools, and system instructions.

MCP is part of a broader movement to standardize how AI applications interact with LLMs, making it easier to build reproducible, debuggable, and modular AI workflows.

Think of MCP as the equivalent of an API contract, but for LLM context. It tells the model what to expect, how to behave, and what tools it has access to—all in a consistent, declarative format.

⚙️ How MCP Works

MCP operates through a YAML-based declarative configuration, where the developer defines a context schema that the model runtime interprets. This configuration can include:

• System instructions: Base directives that set the model’s behavior (e.g., “You are a helpful assistant.”).
• Memory objects: Previous messages or facts the model should remember.
• Tools and functions: Descriptions of callable tools available to the model (like a calculator, API, or database).
• User inputs: Current prompts or queries from users.
• Artifacts: Structured data, like documents or JSON blobs, that the model should reference.

Each item in the MCP context is versioned and traceable, enabling better observability and debugging during LLM usage.

An example MCP file might look like:

version: "1.0"
system: "You are a coding assistant."
inputs:
  user_message: "Write a Python function that merges two dictionaries."
memory:
  - type: chat_history
    content:
      - role: user
        content: "Hi, can you help me with Python?"
      - role: assistant
        content: "Sure! What do you need?"
tools:
  - name: code_linter
    description: "Lint and format Python code."

🧠 Why Use MCP?

As applications become more complex, prompt engineering becomes less scalable. Developers need:

• Modularity: Reuse context components like tools or user profiles across sessions.
• Auditability: Track what was sent to the model and why it responded the way it did.
• Interoperability: Use a shared context format across multiple model vendors or frameworks.
• Observability: Inspect and debug the actual context used during inference.

MCP helps solve these problems by separating context building from business logic, and promoting reproducibility.

✅ Example Use Cases

1. Agent-Based Applications

MCP enables advanced agents (like LangChain or Autogen) to clearly define toolkits, memory, and goals. You can declaratively list the tools available to the agent and pass them as structured context to the model runtime.

2. Enterprise Chatbots

In customer service, MCP can define rules, FAQs, and access control logic for LLMs. By declaring memory, user roles, and pre-approved documents, you ensure compliance and consistency.

3. Coding Assistants

By declaring available functions (e.g., a code executor or documentation fetcher), coding assistants can use tools intelligently without hardcoding them into the prompt.

4. Observability and Debugging

When models hallucinate or fail, MCP context logs provide full transparency into what information was available to the model—helping teams debug issues faster.

🚀 Final Thoughts

MCP is still evolving, but it’s already proving essential for production-grade LLM applications. By abstracting and standardizing model context, it empowers teams to build smarter, safer, and more maintainable AI systems.

Whether you're building a chatbot, an agentic system, or a retrieval-augmented generation (RAG) pipeline, embracing MCP can offer a cleaner, more scalable path forward.

認識 MCP（模型上下文協議）- 什麼是 MCP、如何運作，以及它的重要性

在快速發展的人工智慧（AI）與大型語言模型（LLM）領域中，上下文管理成為打造更聰明、更高效、更可靠應用程式的關鍵。這時候，**MCP（Model Context Protocol，模型上下文協議）**登場，它是一項協助開發人員與系統定義、組織並控制傳遞至 AI 模型之上下文的協議。本文將探討 MCP 是什麼、如何運作，並透過實際案例來說明其價值。

🔍 MCP（模型上下文協議）是什麼？

MCP 是一種 開放協議（open protocol），用來定義與管理提供給語言模型的「上下文」（context）。所謂上下文，指的是推論時傳遞給 LLM 的結構化資訊，涵蓋使用者輸入、聊天紀錄、文件、工具以及系統指令等。

你可以將 MCP 想像成 API 契約的語境版本：它讓模型知道該期待什麼、有何工具可用、應如何回應，而且這一切都是以一致、宣告式的格式來進行。

⚙️ MCP 如何運作？

MCP 透過 YAML 格式的宣告式設定檔運作，開發人員可在此定義模型運行時所需的上下文結構，內容包括：

• 系統指令（System Instructions）：定義模型的基本行為（例如：「你是一位有幫助的助理」）。
• 記憶物件（Memory Objects）：模型應該記住的對話或事實。
• 工具與函數（Tools and Functions）：模型可調用的功能描述（例如計算機、API 或資料庫）。
• 使用者輸入（User Inputs）：目前使用者輸入的提示或問題。
• 人工製品（Artifacts）：模型需要參考的結構化資料（如文件或 JSON 檔）。

MCP 的每一個部分都具備版本控制與可追蹤性，有助於提升 **可觀測性（observability）**與除錯能力。

範例 MCP 設定如下：

version: "1.0"
system: "You are a coding assistant."
inputs:
  user_message: "Write a Python function that merges two dictionaries."
memory:
  - type: chat_history
    content:
      - role: user
        content: "Hi, can you help me with Python?"
      - role: assistant
        content: "Sure! What do you need?"
tools:
  - name: code_linter
    description: "Lint and format Python code."

🧠 為何要使用 MCP？

隨著 AI 應用的複雜性增加，純粹依賴提示工程（prompt engineering）已不具可擴展性。開發者面臨以下挑戰：

• 模組化（Modularity）：可在不同會話中重複使用使用者資料、工具設定等上下文元件。
• 可稽核性（Auditability）：追蹤模型接收到的上下文，以及模型如何生成回應。
• 互通性（Interoperability）：跨多個模型供應商或框架使用共通的上下文格式。
• 可觀測性（Observability）：方便檢查與除錯模型實際運行時使用的上下文。

MCP 的出現正好解決這些問題，將上下文建構與業務邏輯分離，提升 AI 系統的可維護性與擴展性。

✅ 使用範例

1. 代理型應用（Agent-Based Applications）

MCP 可清楚定義智能代理可用的工具、記憶、目標等資源，支援如 LangChain 或 AutoGen 這類框架的先進代理架構。

2. 企業級聊天機器人

客服應用中，可透過 MCP 宣告規則、FAQ、使用者角色與授權資訊，確保一致性與合規。

3. 程式碼助理

開發工具助理可利用 MCP 宣告可用的函數（如程式執行器、說明文件查詢器），使模型能智慧地選擇並調用工具。

4. 觀測與除錯

當模型產生錯誤回應或幻覺時，MCP 的上下文紀錄能提供完整資訊，有助於快速找出問題根源。

🚀 結語

雖然 MCP 尚在發展中，但它已成為建構生產級 LLM 應用的核心組件之一。透過標準化與模組化上下文管理，MCP 協助開發者打造更聰明、更安全、更易維護的 AI 系統。

無論你是在開發聊天機器人、智能代理，或是 RAG（檢索增強生成）應用，採用 MCP 都將成為未來的主流方式。