Data Sovereignty for Agentic AI in Vietnam and ASEAN BFSI: A Field Guide

Picture a risk officer at a Vietnamese bank reviewing a vendor's architecture diagram for an AI agent that will help with dispute triage. The database is in-country. The application servers are in-country. Then she finds a small arrow labeled "LLM API" pointing to an endpoint in another jurisdiction, and every customer record the agent reads goes through it.

That arrow is the subject of this guide. For banks and insurers in Vietnam and across ASEAN, the question is no longer whether to adopt agentic AI. It's how to adopt it without unwinding the data-locality work of the last decade. This is written for risk officers, heads of architecture and compliance leaders in BFSI: the regulatory floor as it stands in 2026, how an agent's reasoning loop changes the data surface, the architecture patterns that hold up at audit, and a checklist to run before an agent reads live customer data.

---

1. Why this is the conversation in 2026, not 2024

Two things changed between 2024 and 2026.

First, agentic AI moved from prototype to production for cloud and engineering operations. Banks in Singapore, Vietnam and Indonesia aren't asking whether an agent can resolve a production incident or review a merge request anymore; they've seen it work. They've measured mean time to resolution drop and watched code-review backlogs shrink. Now they want to extend the same model to customer-touching workloads: collections journeys, KYC review queues, dispute triage, lending policy enforcement. Those workloads sit on the most regulated data in the bank.

Second, the regulatory perimeter for cross-border data sharpened across the region. Vietnam's Decree 13/2023/ND-CP on personal data protection took effect on July 1, 2023. The Law on Personal Data Protection (Law No. 91/2025/QH15) took effect on January 1, 2026, putting that regime on a statutory footing, and its implementing Decree 356/2025/ND-CP replaced Decree 13 on the same day. Decree 53/2022/ND-CP, which implements the 2018 Cybersecurity Law, added explicit storage and processing obligations for foreign service providers serving Vietnamese users. Singapore's MAS published the FEAT (Fairness, Ethics, Accountability, Transparency) principles for AI in financial services in 2018, and its outsourcing rules for banks in Notice 658 took effect on December 11, 2024. Indonesia's OJK tightened its rules on bank IT and cloud use. Malaysia's BNM, the Philippine BSP and the Bank of Thailand all moved too.

So every regulated CIO in the region is now asking the same question: if we put an agentic system in front of production banking data, where does that data actually live, and who can see it?

This guide tries to answer that concretely.

---

2. Data sovereignty is not data residency

It's tempting to reduce sovereignty to one field on a procurement checklist: is the cloud region inside the country? That's necessary. It isn't sufficient.

For an agentic system, sovereignty is the property that data, including the inferences drawn from it, never leaves the jurisdictional, contractual and technical boundary the regulator has accepted, at any point in the agent's reasoning loop. That covers five distinct surfaces:

01Storage

Data at rest

Where the raw customer data lives. The surface most teams already control.

02Inference

The model

Where the model that reads the data runs, and on whose hardware.

03Memory

Agent context

Embeddings, summaries and runbooks derived from production data.

04Telemetry

Logs and audit

The record of what the agent did, which often contains the data itself.

05Egress

Outputs

Webhooks, API calls and provider callbacks that leave the boundary.

• Storage. Where the raw data is at rest.
• Inference. Where the model that processes the data is hosted, and whose hardware it runs on.
• Memory. Where the agent's learned context, embeddings, summaries and runbooks are persisted.
• Telemetry. Where the logs, traces and audit records of what the agent did are written.
• Egress. Whether the agent's intermediate or final outputs leave the boundary through a webhook, an API or a model-provider callback.

An agentic system that keeps data in-country but sends every prompt to a model endpoint in another jurisdiction hasn't solved sovereignty. It has moved the problem from the database layer to the model layer.

Every BFSI architecture decision in 2026 turns on this. Each of the five surfaces has to live inside the boundary, or sit behind a documented cross-border transfer regime the bank can defend at audit. Anything else is a finding waiting to happen.

---

3. Why the traditional controls don't cover an agent

Banks already run strong controls on their data. They were designed for a different shape of workload, and they miss an agent for structural reasons.

Residency checks look at where data is stored, not where it's processed. A procurement checklist that asks "which region?" gets an honest "in-country" for the database and never asks about the model.

IAM bounds who can query, not where the result goes next. A traditional analytics query returns a result to a person inside the network. An agent's query result goes into a model's context, possibly into persistent memory, and possibly out through a tool call.

Audit logs record access, not reasoning. A database log says the service account read row 4,217. It doesn't say why, what the agent concluded, or what it did with the row afterwards.

Security and privacy registers are kept separately. A prompt injection that tricks an agent into sending a customer record to an external endpoint is a security incident and an unlawful cross-border transfer at the same time. Most banks only log it as the first.

The rest of this guide is about closing those four gaps.

---

4. The Vietnamese floor

For a bank, insurer or regulated fintech serving customers in Vietnam, the operative instruments are:

• The Law on Personal Data Protection (Law No. 91/2025/QH15) and Decree 356/2025/ND-CP. Decree 13/2023/ND-CP first set out personal data and sensitive personal data, the consent regime, the cross-border transfer regime and the impact-assessment obligation. Since January 1, 2026 the Law carries that regime in statute, and Decree 356 (which replaced Decree 13) implements it. The cross-border regime requires the transferring party to prepare a cross-border transfer impact assessment ("TIA"), file it with the Ministry of Public Security within 60 days of starting the transfer, and keep it current for the lifetime of the transfer. Check the current implementing rules and exemptions before you scope a deployment.
• Decree 53/2022/ND-CP, implementing the Cybersecurity Law of 2018. It sets the in-country data-storage obligation for certain foreign service providers, the licensing path, the requirement to keep a Vietnam-based representative office for in-scope services, and the duty to cooperate when authorities request data.
• The Law on Credit Institutions (2024 revision) and the State Bank of Vietnam's circulars on outsourcing IT operations. For an agentic system that touches the core banking platform, the SBV outsourcing regime is the operative one. The bank keeps primary liability for everything the agent does, and the SBV expects the bank to keep inspection rights all the way through to the vendor's runtime.

The practical upshot: every surface in section 2 has to either run inside Vietnam or sit behind a documented TIA filing the bank can defend at audit. "The model lives in another jurisdiction but the data doesn't leave Vietnam" isn't a defensible position, because the prompt and the response are personal data once they're derived from a customer file.

The same logic applies to the agent's memory. If the agent persists a summary of a customer dispute as learned context, that summary is personal data. If the persistence layer is hosted out of country, that's a cross-border transfer.

---

5. The wider ASEAN map

For a regional bank or a fintech with ASEAN-wide ambitions, five other regulatory environments matter alongside Vietnam.

Singapore runs the Personal Data Protection Act (PDPA), MAS Notice 658 on the management of outsourced relevant services for banks, the MAS Technology Risk Management (TRM) Guidelines, and the FEAT principles for AI in financial services. Under the PDPA, cross-border transfers are allowed if the receiving party is held to a standard of protection comparable to the PDPA. FEAT is a set of principles rather than a rulebook, but for agentic AI it translates into model-governance expectations a bank will want to attach to any third-party agent: explainability of decisions, accountability for outcomes, and a documented process for human review of consequential actions.

Indonesia runs UU PDP (Law 27/2022) and OJK's rules on IT use by commercial banks (POJK 11/POJK.03/2022). The data controller has primary liability for any agentic system's behavior. OJK's IT rules cover how banks use IT service providers and where electronic systems and data are placed, and they expect the bank to keep audit rights over its providers and, by extension, the agent runtime. Bank Indonesia's payment-system regulations add their own requirements for processing payment transactions domestically.

Malaysia runs BNM's Risk Management in Technology (RMiT) and Outsourcing policy documents, and the PDPA 2010 (amended 2024). The Outsourcing policy document requires BNM's written approval before a bank enters a material outsourcing arrangement, and an agentic system with production access to a Malaysian bank's core systems may well qualify. RMiT asks the bank to consult BNM before its first adoption of public cloud for critical systems and to notify BNM for later ones.

The Philippines runs the Data Privacy Act (Republic Act 10173) and the BSP's IT risk and information-security circulars, including Circular 982 (2017) on information security management. The BSP's posture is risk-based: requirements scale with the institution's IT profile, and cloud and outsourced services, an agent runtime included, are expected to sit inside the bank's risk management and business continuity planning.

Thailand runs the PDPA (B.E. 2562, 2019, fully in force since June 2022) and the Bank of Thailand's IT risk regulations. The PDPA's cross-border transfer regime follows a model similar to the GDPR's adequacy and safeguards approach.

The pattern across the region is consistent: data residency is the floor; the bank's accountability for what the agent does with the data is the ceiling. An agentic system that meets the residency rule but can't produce a verifiable trail of what the agent did, why, and with whose data, fails the second test. And the second test is the one a regulator runs after the first incident, not before procurement.

---

6. Following one question through the agent loop

The threat model for a traditional banking analytics workload is well understood. Data sits in a controlled store, a query runs, a result returns, and an audit log records who asked what. Network controls and IAM bound the surface. An agent loop is different, and the clearest way to see it is to follow one question.

01Ask

Question

"Why was this disbursement delayed?"

02Read

Tool calls

Customer record, disbursement system, approval policy.

03Reason

Model context

Personal data sits in the model at inference time.

04Remember

Memory

A summary of the case may be persisted as learned context.

05Record

Audit log

Inputs, outputs and the policy decision for each call.

A collections officer asks: "Why was this disbursement delayed?" The agent breaks the question down. It calls a tool to read the customer record, a second to query the disbursement system, and a third to read the approval policy. It reasons over the results, drafts an answer, logs the interaction, and may escalate to a human reviewer with the context attached.

For each step, ask where the personal data is, and what the answer predicts for your audit:

• At the tool calls. The data is read from systems you already control. If the agent reads through on-demand connections without copying, nothing new is created here. If the vendor replicates the data into its own store first, you have a new storage surface to declare.
• At inference. The customer record is now in the model's context. If the model runs in-country, this is processing inside the boundary. If it runs elsewhere, this step is a cross-border transfer, whatever the database diagram says.
• In memory. If the agent keeps a summary of the case to handle the next one faster, that summary inherits the record's classification. Where it's stored decides whether you have a second transfer.
• In the audit log. The log has to hold enough of the inputs and outputs to replay the decision, which means it holds personal data too, and it needs the same residency as the source.

What follows for sovereignty:

• The model is the new data plane. Whatever the agent reasons over is in the model's working memory at inference time. If that model is hosted in another jurisdiction, the data has crossed the border, even if the database never moved.
• Agent memory is its own residency surface. Most agentic systems persist embeddings, summarized runbooks and learned patterns. Those artifacts derive from production data and inherit its sensitivity. They have to live in-country next to the source data.
• Tool calls are auditable events. When the agent invokes a tool against a banking system, that's materially the same as an analyst running a query, and the same audit standard applies. The agent's chain-of-thought is not the audit log. It's internal reasoning; a regulator wants the durable log of intent and outcome.
• Prompt injection is a sovereignty issue, not only a security issue. A successful injection that makes the agent send a customer record to an attacker-controlled endpoint is a cross-border transfer of personal data with no TIA behind it. It belongs in the privacy register as well as the security one.

The controls a bank already runs on its data warehouse and core banking systems must extend to the agent runtime. The runtime also needs controls the warehouse never did: prompt-injection defense, model-output filtering, and per-tool egress policy.

---

7. Architecture patterns that hold up

In our experience deploying with regulated customers across the region, five patterns survive an audit.

In-country inference

The model that processes customer data runs on infrastructure in the same jurisdiction as that data. For Vietnam, that means a Vietnam deployment: a hyperscaler footprint in-country, a sovereign cloud, or a customer-owned datacenter. Cross-region inference is reserved for non-personal data (synthetic test fixtures, code-only review of public modules, public API documentation lookups) and is policy-gated, not ad hoc.

When a model has no in-country option at the hyperscaler the bank already uses, the right answer is usually to host it on the bank's own GPUs in-country, not to make an exception. The exception is the first thing regulators ask about.

On a hyperscaler, the region boundary can be enforced at the organization level rather than trusted to each team. An illustrative AWS service control policy for a bank whose approved boundary is Singapore (ap-southeast-1):

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyOutsideApprovedRegion",
      "Effect": "Deny",
      "NotAction": ["iam:*", "organizations:*", "sts:*", "support:*"],
      "Resource": "*",
      "Condition": {
        "StringNotEquals": { "aws:RequestedRegion": ["ap-southeast-1"] }
      }
    }
  ]
}

Customer-managed encryption keys

The keys that decrypt data presented to the agent are held in a customer-controlled KMS. The agent runtime authenticates to KMS for each invocation, and the key never leaves the customer boundary. Rotation, audit and revocation belong to the customer, not the vendor. An illustrative key-policy statement that lets the agent's role decrypt only through an in-region service:

{
  "Sid": "AgentRuntimeDecryptInRegionOnly",
  "Effect": "Allow",
  "Principal": { "AWS": "arn:aws:iam::111122223333:role/agent-runtime" },
  "Action": "kms:Decrypt",
  "Resource": "*",
  "Condition": {
    "StringEquals": { "kms:ViaService": "s3.ap-southeast-1.amazonaws.com" }
  }
}

The bank's auditor can then produce a key-usage log on demand and tie every decryption to a specific agent invocation, for example with a CloudTrail Lake query:

SELECT eventTime, userIdentity.arn, eventName, sourceIPAddress
FROM <event-data-store-id>
WHERE eventSource = 'kms.amazonaws.com'
  AND eventName = 'Decrypt'
  AND userIdentity.arn LIKE '%agent-runtime%'
  AND eventTime > '2026-10-01 00:00:00'
ORDER BY eventTime DESC

Memory in the customer boundary

The agent's learned context (runbooks, embeddings, accepted patterns, summarized incident histories) persists inside the customer's account. The vendor's control plane never holds it. For CloudThinker, this is the MemGraph posture: the team's institutional memory is theirs, in their boundary, with the vendor running the compute that writes to it but never the storage that holds it. The platform overview shows where it sits, and the MemGraph technical post covers it in depth.

This matters to regulators because the MemGraph is derived from production data. Inheriting the source's sensitivity classification is the right default, and the only durable way to keep that classification is to keep the storage where the source data already lives.

Sandbox-isolated runtime

Each agent execution runs in a per-tenant sandbox with no shared state and no path to another tenant's data. For CloudThinker this is described in sandbox-secure execution and private connectivity, and it's the default for every customer. The sandbox is also where prompt-injection defenses run: an injected instruction that tells the agent to call an out-of-policy URL is denied at the sandbox egress gate, not at the model.

Per-tenant isolation plus explicit egress allow-listing is what answers the regulator's question, "what could go wrong if a single tenant is compromised?"

Auditable tool invocation

Every tool call the agent makes is logged with the prompt context, the inputs, the outputs and the policy decision that allowed it. The log is replayable, and the replay can be presented to a regulator. For CloudThinker this is enforced by the Guardrails Engine on the platform overview and the Connections architecture, the same architecture we shipped for SOC 2 attestation and described in the Connections blog.

Replay isn't observability. A regulator doesn't want a Grafana dashboard. They want a deterministic trail that, given the same inputs and the same policy version, produces the same outcome. That's the bar.

A deployment that meets all five patterns gives an SBV, MAS or OJK outsourcing review the evidence it asks for, without architectural changes late in the process.

---

8. Residency-only vs sovereignty-grade

The deeper difference is what the bank can prove. A residency-only design is an assurance: the vendor says the data stays put. A sovereignty-grade design produces evidence: key-usage logs, replayable tool calls and a region boundary enforced by policy. Regulators in the region increasingly ask for the second.

---

9. How CloudThinker is built for this

CloudThinker builds Frontier Investigation Agents. It isn't a banking product. It's the substrate that Resolve, Optimize, SecOps and Review run on. We talk to BFSI teams in the region about sovereignty because that substrate is what has to hold the data-residency, key-management and memory-locality guarantees the regulator will ask about.

01Customer boundary

The bank

• Systems of recordCore banking, databases, logs stay in place
• Customer-managed KMSKeys never leave the boundary
• MemGraph storageTeam memory on customer storage and keys
• Audit logReplayable record of every tool call

In-country, customer-owned

02Runtime

CloudThinker

• Region-scoped runtimeNo cross-region inference by default
• ConnectionsRead on demand, no persistent copies
• Per-tenant sandboxEgress allow-list at the gate
• Guardrails and Auto ModeEvery write policy-gated

Same region, or on-prem

03Oversight

Risk and audit

• ApproversNamed people approve writes
• Risk officersKey-usage and tool-call logs on demand
• RegulatorReplay of what the agent did and why

Evidence, not assurances

The platform follows from the five patterns above:

• Region-scoped runtime. CloudThinker runs in the customer's region of choice. For Vietnam customers, we run in a Vietnam region with no cross-region inference path enabled by default. The agent runtime, the MemGraph, the audit log and the telemetry layer all sit inside the same regional perimeter.
• Connections without persistent copies. CloudThinker Connections reads from the customer's stack on demand, scoped to the tool call, with no persistent replication into our control plane. Database reads stay in the database. Logs stay in the customer's log platform. The agent reasons on the data at inference time and doesn't keep a copy. The detail is in CloudThinker Connections: How We Securely Connect to Your Infrastructure.
• MemGraph in the customer's account. The team memory (runbooks, accepted patterns, ADR-linked decisions) persists inside the customer boundary, on customer-managed storage and under customer-managed keys. See the MemGraph post.
• Every write is gated. CloudThinker acts within Auto Mode, so you decide what runs on its own and what waits for approval, with the audit trail attached. The full posture is on the Security page.
• On-prem option. For customers whose regulator doesn't accept hyperscaler regions as in-country (typically state-owned banks in the region), CloudThinker deploys into the customer's own datacenter with the same control-plane shape as the SaaS offering. The agent runtime, the MemGraph and the policy engine all sit inside the bank's perimeter.

That's what "one platform, not a stack of agents" and "centralized MemGraph for the team" mean in practice: every capability shares the same substrate, the substrate carries the controls, and the controls are visible to the regulator at audit.

---

10. A field checklist for BFSI leaders considering agentic AI

We use this checklist with risk officers early in scoping. It's opinionated, and it's the minimum bar we'd ask any vendor, ourselves included, to clear.

1. Can the vendor produce a network diagram showing the path of personal data from the customer's environment to the model and back, end to end, in writing?
2. For each model invocation, where does the model run, and on whose hardware?
3. Where does the agent's memory persist: inside the customer's account or inside the vendor's control plane?
4. What persistent artifacts does an agent run produce, and what is the residency posture of each one?
5. Is there a customer-managed KMS path for every decryption the agent performs?
6. Are tool invocations logged with enough fidelity to replay them deterministically in a regulator's office?
7. What prompt-injection threat model will the vendor present at audit, and what specific controls back it?
8. If the regulator requires a Transfer Impact Assessment, can the vendor provide the data points the TIA template needs, in the regulator's format?
9. Is the agent runtime sandboxed per tenant, or is there shared state with other tenants?
10. What policy gate stops an agent from executing a state-changing operation on production without approval, and who approves it?

A vendor that can't answer all ten in a first conversation isn't ready for BFSI in this region. Neither is a deployment that hasn't been walked through these questions before going live.

We've turned this checklist into a one-page document risk teams can attach to their procurement file. If it would help, contact our team and we'll share it.

Questions to put to your own environment

If you already run CloudThinker on internal operations, you can start the sovereignty review from chat:

"List every connection in this workspace, the region each one reads from, and whether any data is persisted outside our account."

"Show me every tool call that touched the customer database last week, with the policy decision that allowed it."

"Which actions in this workspace run on their own, and which still need approval? Change nothing."

---

Related reading

• AgenticOps needs its own platform: why a coding tool can't safely connect to production
• CloudThinker Connections: How We Securely Connect to Your Infrastructure
• Inside CloudThinker's sandbox: how the AI execution environment is built
• Introducing MemGraph: long-term memory for AI cloud agents
• Auto Mode: graduated autonomy with safe defaults

Closing

BFSI teams in Vietnam and across ASEAN have the opportunity engineering teams elsewhere had eighteen months ago: agentic systems that take routine work off the plate so senior people can focus on the hard problems. The risk is different. The data is more sensitive, the regulator is closer, and the cost of getting it wrong is measured in licenses as well as outage minutes.

The way through isn't to slow down. It's to pick a substrate built to hold the controls a BFSI regulator will ask for (region-scoped, customer-keyed, memory-local, sandbox-isolated, audit-replayable) and to start with the workloads where those controls are clearest. Internal cloud and engineering operations are usually the right place to begin. Customer-facing workloads come after the first audit cycle has been walked end to end.

If you're scoping an agentic deployment for a regulated workload in the region, contact our team. We'll walk you through the deployment shape and the audit posture we've used with banks already live in production.