Sovereign Cloud for BFSI: Data Storage Infrastructure and Financial Data Control in Vietnam

For banks, insurance companies, and fintechs, data is not merely an operational asset but a core element of business operations. As an increasing number of workloads ranging from core business systems to AI are deployed on Cloud infrastructure, the key challenge is no longer simply where data is stored, but how enterprises can control data, workloads, encryption keys, and access rights throughout the processing lifecycle.

From 2026, Vietnam’s data governance and AI legal framework continues to expand with the Personal Data Protection Law No. 91/2025/QH15 and Decree 356/2025/ND-CP (effective from January 1, 2026); the Law on Artificial Intelligence No. 134/2025/QH15 (effective from March 1, 2026), and Decree 142/2026/ND-CP (effective from May 1, 2026). This evolving landscape is prompting many organizations to re-evaluate their data and AI governance approaches a macro perspective on this topic was introduced in our previous article before we dive deep into specific workloads below.

In addition, organizations in the BFSI sector must strictly comply with industry-specific regulatory frameworks:

1. Customer Information Confidentiality: Law on Credit Institutions No. 32/2024/QH15 and Decree 117/2018/ND-CP on maintaining confidentiality and providing customer information of credit institutions.
2. Information System Safety & Cloud Workload Migration: Circular 09/2020/TT-NHNN of the State Bank of Vietnam governing information system safety in banking operations (permitting Level 3, 4, and 5 systems to migrate to the Cloud provided they satisfy technical security requirements).
3. Cybersecurity & Data Localization: Law on Cybersecurity No. 116/2025/QH15 (effective from July 1, 2026) along with guiding Decrees such as Decree 331/2026/ND-CP (cybersecurity protection for information systems), Decree 333/2026/ND-CP, and Decree 330/2026/ND-CP. Mandatory data localization requirements in Vietnam continue to be maintained and strictly enforced for financial and banking information systems.
4. Sectoral & Use-Case Regulations: Law on Prevention and Combating of Money Laundering No. 14/2022/QH15 (governing KYC and transaction record retention) and Law on Insurance Business No. 08/2022/QH15.
   Consequently, the selection of Cloud and AI infrastructure becomes tightly bound to governance questions: what data is being processed, where, who holds access rights, which legal jurisdiction governs the infrastructure, and how an enterprise can demonstrate compliance during an audit. For the BFSI sector, this challenge must be addressed right from the architectural design and vendor selection stages, rather than being treated as an afterthought post-deployment.

1. Why Financial Institutions Need Data Control from Day One

For banks, insurers, and fintechs, not all data carries the same level of sensitivity, nor do all workloads require identical levels of control. Therefore, when evaluating Cloud solutions, the primary question should not be "Where is data stored?", but rather "What type of data is the enterprise processing, for what purpose, and through where does data flow during its lifecycle?"
This becomes even more critical when AI is integrated into business processes. Beyond source data, an AI workload can generate datasets, prompts, outputs, embeddings, model artifacts, logs, and backups. Enterprises must therefore clearly identify what data is processed, where it is stored and processed, who holds access rights, and which controls must be maintained.
For BFSI, data control does not begin with selecting a Cloud provider; it begins with thoroughly understanding the data and workloads being onboarded to the Cloud.

2. Tiering Data by Sensitivity Level to Determine Corresponding Controls

Once the scope of data and workloads has been defined, the next step is data tiering to map each group to its appropriate control level.
A crucial step prior to Cloud selection is identifying what data is being processed, which tier that data belongs to, and what governance requirements apply to the associated workloads.

You can start with 4 key questions to identify data:

1. Is it personal data?
   If yes, further determine whether it constitutes basic personal data or sensitive personal data. Categories such as financial data, biometrics, health, location, etc., are classified as sensitive personal data. For BFSI, this directly impacts use cases like KYC, identity verification, AI models, and insurance underwriting.
2. Does the data fall under categories requiring additional scrutiny under regulations on important data and core data in Law on Data No. 60/2024/QH15?
   Avoid assuming that all financial data defaults to a single category. Evaluate the nature of the data, scale, application threshold, and processing context. The catalog of important data and core data is promulgated by the Prime Minister; thus, enterprises should cross-reference official current lists rather than speculate.
3. Where and by whom is the data processed?
   This links directly to the Sovereign Cloud equation: whether data is stored in Vietnam or abroad, who the processor is, whether sub-processors are involved, and whether the workload triggers cross-border data processing.
4. What cybersecurity classification level applies to the system processing that data?
   Beyond classifying the data itself, enterprises must determine the security level of the information system handling it. Decree 331/2026/ND-CP dated August 19, 2026 defines criteria, authority, and procedures for classifying information systems across 5 levels based on importance and risk. The volume of processed personal data serves as a key reference criterion, and risk assessment results form a basis for level determination. For BFSI, core operational systems and customer-facing platforms typically fall into high-level tiers, imposing stricter protection mandates and directly governing which Cloud deployment models are permissible.

Looking further ahead, the draft Law on Data Security led by the Ministry of Public Security proposes classifying data into 04 security risk levels: standard data (Level 1), internal data (Level 2), important data (Level 3), and core data (Level 4), based on nature, accumulation scale, and impact severity. The draft also establishes the principle that lower-tier data, when accumulated to a large-scale threshold that fundamentally alters its risk profile, will be reclassified under higher protection levels, requiring system operators to deploy automated mechanisms for monitoring and alerting when accumulation thresholds are breached.
While this draft is not yet in effect and remains subject to revision, adopting this tiering mindset to label data now will prevent BFSI organizations where data accumulates rapidly alongside customer growth and transaction volume from having to reclassify their entire data repository once the formal legal framework is enacted. It is also essential to evaluate two parallel classification axes simultaneously: the information system level under cybersecurity law, and the data tiering level under the aforementioned framework.

Therefore, instead of asking "which data needs compliance?", ask:
What is this data – what is its sensitivity level – which workload utilizes it – where is it processed – who holds access rights – and what controls are required to govern it across its lifecycle?

This represents a far more pragmatic approach when designing Cloud solutions for BFSI.

3. AI Expands the Scope of Governed Data

AI increases data governance complexity because data is utilized across multiple stages throughout the AI system lifecycle.
When AI is deployed into production, governance must be addressed holistically across data, models, workloads, and access rights. Clearly defining roles and responsibilities in AI operations is therefore indispensable. An AI system’s data flow map should not merely depict Database → Application, but must capture the entire processing pipeline.

3.1 AI Data Lifecycle

An AI workload typically progresses through steps such as:
Data Ingestion → Processing → Training/Fine-tuning → Inference → Output → Logging → Monitoring
At each stage, enterprises must identify what data is actively used, where the workload executes, and who holds access permissions. This is particularly critical for AI systems handling customer data, operational documents, or financial transaction logs.

3.2 Training

If data is utilized for model training or fine-tuning, enterprises must establish:

• Where does the dataset originate?
• What data types are contained in the dataset?
• Who is authorized to use it?
• Where is the dataset stored?
• Upon completion of processing purposes, how are the data and its associated copies handled?

At this stage, risk resides not only in the primary dataset but also in copies, snapshots, and model artifacts generated during training which are frequently overlooked during regulatory audits.
Furthermore, under current legal frameworks, major data protection regulations (such as EU GDPR, Singapore PDPA, or domestic data protection laws governing the financial sector) enforce strict purpose limitation and data minimization principles. This implies that customer data should not be funneled into model training simply because it resides in internal systems; enterprises must establish a clear legal basis, processing purpose, and appropriate authorization conditions prior to feeding data into training or fine-tuning pipelines. Additionally, specific financial regulations demand auditability and explainability for data used in AI models, particularly when those models directly influence credit scoring, anti-fraud detection, or risk assessments.

3.3 Inference

During inference, data is transmitted to the model via prompts or integrated application interfaces.
Enterprises should determine:

• What data is embedded in the prompt?
• Where does the model execute the workload?
• Is input data retained or stored?
• Is data repurposed for other secondary uses?
• Can the processing region or environment be strictly controlled?

For GenAI systems, this is the most sensitive touchpoint because prompts may inadvertently contain customer PII, transaction details, or proprietary internal data.
From a compliance perspective, modern legal frameworks treat AI prompts and outputs as personal data processing activities if they contain or imply identifiable information. This triggers data residency rules, cross-border transfer restrictions, and in certain cases, obligations to notify regulators or govern third-party service providers (e.g., external AI model providers).
Moreover, emerging AI governance regulations (such as the EU AI Act, enforced under phased schedules per risk tier) require organizations to maintain explainability regarding how AI systems reach conclusions, especially for high-impact financial use cases.

3.4 Logging

System logs are frequently overlooked when evaluating AI data flows. In practice, logs can capture API requests, model responses, user identifiers, system events, or processing metadata.
Consequently, the question "Where is customer data stored?" must be expanded to:
Where are datasets, prompts, embeddings, outputs, logs, model artifacts, and backups stored and processed?
From a legal standpoint, logging represents a sensitive data domain because logs are often retained far beyond their initial operational purpose, violating storage limitation mandates. If logs contain personal or financial data, enterprises must establish clear retention policies, access controls, and data erasure mechanisms upon data subject request—such as the right to request personal data erasure under Vietnam’s Personal Data Protection Law, or the equivalent Right to Erasure (Right to be Forgotten) under GDPR. This is why Cloud provider selection is increasingly becoming a core pillar of enterprise data and AI governance programs, rather than a mere decision based on pricing, compute performance, or SLAs.

4. Audit Demands Operational Evidence, Not Policy Documents

A corporate policy may state that only authorized roles are permitted to access sensitive data. However, the immediate question from compliance auditors will be: Does the underlying infrastructure actively enforce that policy?
This is where enterprises must demonstrate technical proof:

• For example, if policy dictates data must only be processed within a specific boundary → operational architecture and technical logs are required to prove isolation.
• If only specific roles may access training datasets → IAM controls must enforce and log access permissions.
• If data must be erased upon purpose completion → systems must support execution and auditability of erasure processes.
• If AI requires human oversight → mechanisms must exist for human operators to meaningfully review or intervene where appropriate.

In short:
Compliance is not merely having a policy; it is the technical capability to prove that the policy is actively enforced.
This reflects the engineering approach advocated by GreenNode in translating regulatory control mandates into actionable technical controls and audit-ready operational evidence.

5. Maintaining Human Oversight in High-Impact Customer Decisions

When AI is embedded into financial workflows, governance extends beyond data and physical infrastructure. Enterprises must define the exact role AI plays within decision-making workflows—such as assisting in application analysis, anomaly detection, document processing, or generating recommendations for officers.

For workflows directly impacting end customers, enterprises must clearly establish:

• Is AI rendering final decisions or providing decision-support to human operators?
• When AI outputs exhibit anomalies, who possesses authority to review or override them?
• Can decisions or AI outputs be fully traced back to underlying data, model versions, and processing pipelines?

With the Law on Artificial Intelligence No. 134/2025/QH15 effective from March 1, 2026, alongside Decree 142/2026/ND-CP, AI governance must be evaluated across the full lifecycle and stakeholder roles.
This does not imply that every AI workload requires an identical governance model. The key is accurately determining risk levels, AI operational roles, and party responsibilities within the system.

6. GreenNode Partners with MSB to Build Secure, Compliance-Ready Infrastructure for Financial Sector

In collaborating with MSB, GreenNode deploys a cloud infrastructure seamlessly integrated with the bank's existing environment (Hybrid Cloud). This enables MSB to scale AI workloads on a platform that delivers high compute performance while maintaining rigorous security and empowering the bank to retain full control and data ownership.
On this foundation, MSB has deployed key applications such as AI Agent Gamma and GenAI HR Chatbot. According to MSB, these systems process approximately 20,000 queries per month, analyze over 300,000 document files, and serve over 8,000 internal staff members.
Beyond AI deployment capabilities, the Sovereign AI Cloud model represents a key strategic direction in the partnership between GreenNode and MSB, aiming to support the bank in scaling AI on infrastructure that offers complete control over data, compute, and workloads tailored to the strict requirements of Vietnam's financial sector.

View BFSI Case Study to explore how GreenNode partners with financial institutions to deploy Sovereign AI Cloud infrastructure

Frequently Asked Questions (FAQ)

1. What is Sovereign Cloud for banking?

Sovereign Cloud for banking is a cloud infrastructure model engineered to provide organizations with precise control over where data and workloads are stored and processed, the governing legal jurisdiction, and operational/data access authority. For banks, evaluation must be conducted on a per-workload and data-type basis rather than relying solely on the physical location of a data center.

2. How does Data Sovereignty differ from Data Residency in banking?

Data residency focuses primarily on where data is physically stored or processed. Data sovereignty expands this scope to encompass legal jurisdiction and full authority/control over the data. Therefore, simply hosting data within Vietnam is not the sole criterion when evaluating data sovereignty compliance.

3. When adopting AI, what additional data types must banks govern?

Beyond raw source data, enterprises must govern datasets, prompts, embeddings, vector databases, model artifacts, outputs, logs, and system backups. These components must be mapped into data flow diagrams to establish processing locations, access permissions, and lifecycle policies.

4. Which Cloud platform is suitable for financial enterprises requiring data compliance in Vietnam?

A suitable cloud platform for financial enterprises typically demonstrates three key attributes: transparent visibility into where data is stored and processed, clarity on the exact legal entity operating the infrastructure, and granular control over access rights and encryption keys. Financial institutions should prioritize platforms where both the operating entity and data centers reside within a clearly defined jurisdiction, hold recognized certifications like ISO 27001 and SOC 2, and support comprehensive audit logging for operational verification. Enterprises should engage directly with providers on these three criteria and validate alignment with internal Legal/DPO teams against organization-specific compliance requirements.

(For reference purposes only, does not constitute legal advice)