Ask a bank CISO in Jakarta and a bank CISO in Singapore what data sovereignty means for their institution, and you will receive two different answers. Both are right within their own regulatory context, and that is precisely the challenge facing financial institutions operating across Asia-Pacific today.
The region is splitting into two distinct philosophies on how banks and financial institutions must handle sensitive data. One treats physical location as the answer. The other puts the burden on the institution to prove it remains in control, wherever the data actually sits.
For decision-makers investing in cross-border infrastructure, this is no longer a compliance footnote. It has become an ongoing operational reality that shapes where they can deploy, which vendors they can use, and how quickly they can expand into a new market.
The localisation camp
India's Reserve Bank requires payment system data to stay on servers inside the country under its payment data framework. If data must leave briefly for processing, it has to return and be deleted from the foreign system within a business day.
Indonesia's financial regulator, the OJK, takes a similar position for banks. Its rules on IT implementation require banks to maintain control over the data centres and disaster recovery sites supporting their banking systems, which effectively turns the location of infrastructure into a regulatory decision rather than an operational one.
China goes furthest. Financial institutions face strict controls on local storage and on any export of important data or personal information with heavy scrutiny applied to any data leaving the country regardless of the business case for moving it.
In these markets, the rule is blunt but clear. Data does not leave without going through a formal process, which makes day-to-day compliance harder but easier to explain to auditors and supervisors.
The accountability camp
The Monetary Authority of Singapore (MAS) takes the opposite approach. It treats cloud usage as a form of outsourcing rather than a location question, and its cloud advisory places responsibility on the bank to demonstrate, through audit rights, contract terms, and ongoing risk assessment, that it retains control over its data no matter where it physically resides. The question is not where the data lives; it is whether the institution can prove it still governs it.
Bangko Sentral ng Pilipinas (BSP) has built a comparable framework. Its IT outsourcing rules require cloud providers to grant the BSP direct access to audit their infrastructure and place ultimate responsibility for outsourcing risk on the bank's own board and senior management rather than on a residency rule.
Japan follows similar logic. There is no blanket data localisation rule. Instead, the Personal Information Protection Commission requires businesses to guarantee adequate protection before personal data leaves the country, whether through consent, contractual safeguards, or recognised international frameworks. The obligation follows the data rather than fixing it in place, which grants organisations more flexibility but also more responsibility.
Neither regulatory posture is unreasonable. Localisation-first regulators are responding to genuine national security and law enforcement concerns. Accountability-first regulators are responding to the risk that rigid localisation concentrates exposure in one place and removes the redundancy that comes from distributing infrastructure across regions.

Both set of regulators are attempting to answer the same underlying problems: Who is accountable when a financial institution's data goes wrong, and how is that accountability proven before something does?
- Arun Kumar, Regional Vice President, APAC, ManageEngine.
Why this becomes a boardroom problem, not just an IT one
Most large financial institutions do not operate under a single model. A bank running core systems in Jakarta, treasury operations in Singapore, and a card processing link touching India needs technology that satisfies a hard residency rule in one country and an audit-based accountability model in another, without three separate stacks, vendor relationships, and governance approaches.
This is where security and IT strategy most often breaks down without leadership realising it early enough. Teams that build for the localisation model, with dedicated and often air-gapped infrastructure, tend to be underprepared when a regulator such as BSP or MAS asks them to demonstrate continuous, auditable control over a cloud deployment.
Teams that build cloud first for the accountability model often discover they cannot comply when a market such as India, Indonesia, or China requires the data to physically stay put. Retrofitting one posture into the other under regulatory pressure, or in the middle of an acquisition, is slow, expensive, and exactly the kind of scramble that draws an examiner's attention.
What decision makers should take from this
Boards and technology leaders navigating this landscape need to stop treating data sovereignty as a single-policy decision made once and revisited only when a regulator complains. It needs to be an architectural principle built in from the start.
The steadier path is to separate the security and governance model from the deployment model, so the same controls, audit trails, and access policies travel with the data whether it sits on-premises in Jakarta, in a locally operated cloud instance in Singapore, or across a hybrid setup spanning both. That is different from choosing the cloud over on-premises. It means governance and reporting that work identically whether the infrastructure is air-gapped, hybrid, or fully managed, producing the evidence a regulator wants regardless of which rulebook applies.
Leaders should also resist solving this market by market. A governance framework stitched together retroactively, one jurisdiction at a time, tends to be the most expensive and fragile version of the solution. The institutions managing this well treat regional expansion and regulatory mapping as a single conversation from day one, rather than sequencing compliance after the infrastructure decision has already been made.
Keep the data local, or prove ongoing control. APAC's two models are not going to converge anytime soon. The institutions that treat this as an architecture problem, solved once and applied consistently, rather than a policy argument to be refought in every new market will be the ones regulators trust either way.
Arun Kumar is Regional Vice President, APAC, ManageEngine.





