Ryan Nguyen

ryannguyenx.com

Who regulates bank technology in Vietnam? A 2026 map

The State Bank of Vietnam (SBV) is the main sector regulator for bank technology. No single SBV unit covers every technology issue.

SBV units share responsibility. The right unit depends on the legal rule, bank, product, system, and data involved.

This engineering map uses public Vietnamese legal sources checked on Jan 2026. It is not legal advice; signed Vietnamese texts are authoritative, and the English unit names and summaries are working translations.

TLDR

  • Treat the SBV as the main banking-sector authority, not its technology unit alone.
  • Use the current legal text to find the responsible unit and report recipient.
  • Start with four core regimes, then add rules for each product, system, and type of data.
  • Keep legal duties separate from engineering interpretation.
  • Link each duty to an owner, evidence, and any reporting deadline.

Start with the SBV's legal role

Decree 26/2025/ND-CP defines the SBV as a ministry-level government agency and Vietnam's central bank. Article 2 gives it broad powers that affect technology:

  • License credit institutions, including banks, and regulated payment service providers.
  • Manage anti-money laundering work.
  • Supervise and inspect banking activity.
  • Organize and supervise national payment systems.
  • Organize the credit information system.
  • Collect, store, analyze, and publish information.
  • Direct the use of science and technology in banking.

Article 3 lists SBV units, but it does not assign every Article 2 power to a specific unit. A unit's name alone does not prove that it owns an obligation.

Decree 198/2026/ND-CP updated the list of SBV units from July 1, 2026. Check the relevant circular, decree, or Governor decision to confirm a unit's responsibility.

Match each responsibility to an SBV unit

This map uses authorities named in current legal texts. It does not assign legal responsibility based only on an English translation.

Information Technology Department

Cục Công nghệ thông tin is the closest SBV unit to a technology regulator. Its authority still depends on the legal text.

For example, the department:

  • Monitors and checks general information system security under Circular 09/2020;
  • Receives online banking security reports and customer data leak notices under Circular 50/2024 as amended;
  • Monitors open application programming interfaces (Open APIs), which let approved systems connect through defined interfaces, under Circular 64/2024;
  • Runs technical infrastructure for the national interbank payment system under Circular 08/2024;
  • Builds technical connections for payment system supervision under Circular 41/2024.

The department can be the technical contact without being the only supervisor, inspector, or enforcement body.

Payment Department

Vụ Thanh toán leads or coordinates oversight of payment systems and payment intermediaries. A payment intermediary is a regulated provider that supports services such as payment gateways or electronic wallets.

Under Circulars 08/2024 and 41/2024, it monitors important payment systems. It can access data, assess operations, and request incident reports. It also works with the Information Technology Department on supervision infrastructure.

The Payment Department is not the same as the SBV Transaction Office. The Transaction Office runs settlement functions. It is not the payment regulator.

Inspection and prudential supervision

Prudential supervision means ongoing checks on the safety and soundness of banks and the banking system. Inspection is a formal investigation or enforcement action.

Thanh tra Ngân hàng Nhà nước performs formal inspection and enforcement. Decree 05/2026/ND-CP defines the central and regional banking inspection bodies.

Circular 50 also assigns online banking inspections and the handling of violations to the Inspectorate and regional branches.

The current structure divides prudential supervision between individual institutions and the wider system. The January 2026 consolidated supervision text assigns the roles:

  • Cục Quản lý, giám sát tổ chức tín dụng performs microprudential supervision, which checks the safety of individual institutions.
  • Cục An toàn hệ thống các tổ chức tín dụng performs macroprudential supervision, which checks risks across the credit institution system.

These units may examine a bank's controls, risks, ability to keep services running, and safety. Neither unit owns every cybersecurity standard.

Anti-Money Laundering Department

Anti-money laundering (AML) work seeks to prevent and detect the movement of criminal proceeds. Cục Phòng, chống rửa tiền administers the banking sector's AML responsibilities.

Its role includes technology-based risk assessment, monitoring, screening, and reporting. Its scope is wider than checking names against sanctions lists. It also covers customer and product risk, service channels, electronic transfers, suspicious activity, and reports in required data formats.

National Credit Information Centre

The National Credit Information Centre of Vietnam (CIC) collects, processes, matches, stores, and provides credit information. This includes data about borrowers and credit accounts.

Circular 15/2023/TT-NHNN requires participating institutions to keep infrastructure and controls for data they send to CIC. This rule applies to credit information. It does not give CIC authority over all banking data.

Map four core regimes first

These four rule families are a useful starting point for a commercial bank. They are not a complete legal inventory. One family can include more than one binding legal text.

General information system security

Circular 09/2020/TT-NHNN is the baseline information system security regime for covered banking-sector entities.

It covers:

  • Information and system classification.
  • Approved security policies.
  • Asset, personnel, physical, operational, and access controls.
  • Supplier and outsourcing controls.
  • Secure design, development, testing, and change management.
  • Vulnerability reviews and penetration tests, which simulate attacks to find weaknesses.
  • Incident management, exercises, and reporting.
  • Backups, disaster recovery, and business continuity for critical services.

Circular 09 remains in force, but Article 25 was repealed by Circular 50/2024. Check the current status of each article. Do not rely on an old compliance summary.

Online banking security

Circular 50/2024/TT-NHNN, as amended by Circular 77/2025/TT-NHNN, governs online banking security. Circular 50 replaced Circular 35/2016.

The current rules cover:

  • System security levels and regular reviews.
  • Secure software development, source review, testing, and release.
  • Encryption and storage of security evidence.
  • Checks that detect compromised mobile devices.
  • Biometric presentation-attack detection, which spots attempts to fool identity checks.
  • Vulnerability scanning and quick treatment of serious exposure.
  • Central security monitoring and unusual transaction detection.
  • Continuity exercises and reports to the SBV.

Use the official consolidated text for a current reading. Then check transition rules in the signed amending text. Public metadata and operative clauses can show different dates. Operative clauses are the provisions that have legal effect.

Internal control, operational risk, and continuity

Circular 83/2025/TT-NHNN became effective on July 1, 2026, for commercial banks and foreign bank branches. It replaced the previous Circular 13/2018 internal-control regime.

Internal control is the bank's system for managing risk and checking that its controls work. Operational risk is the risk of loss or disruption from failed people, processes, systems, or external events.

For technology, this regime covers:

  • Information system resources and management information.
  • Technology and outsourcing risk.
  • Critical data loss and system failure.
  • Network, hardware, software, interface, and operating controls.
  • Incidents, changes, and customer authentication.
  • Continuity plans, backup resources, and annual tests.
  • Internal reports on technology changes and continuity exercises.

Even a sound technical control needs clear ownership, reporting, and independent review.

Anti-money laundering technology and reporting

Circular 27/2025/TT-NHNN implements parts of Vietnam's Anti-Money Laundering Law and replaced Circular 09/2023.

It requires technology support for:

  • Risk scoring across customers, products, locations, channels, and controls.
  • Risk reviews before the bank offers new products or products that use innovative technology.
  • Handling missing information in electronic transfers.
  • Reports about electronic transfers and suspicious transactions.
  • Electronic report submission and correction in the required format.
  • Checks against required lists.
  • Transaction monitoring for signs of suspicious activity.

An AML system is not a standalone compliance database. It depends on customer identity, product design, payment flows, data quality, case handling, reporting, and clear ownership.

Add rules for each product and activity

The four core regimes do not replace rules for the service you are building.

Common product rules include:

Whether a rule applies depends on the entity, service, system, customer, transaction, and data. An electronic wallet rule does not automatically apply to every bank system.

Check laws outside banking

Banking rules are not the full technology law boundary. Cybersecurity, personal data, and regulated data processing can also bring the Ministry of Public Security and laws that apply across sectors into scope.

Current sources include:

A bank system can fall under more than one legal regime at the same time. The SBV remains the main banking-sector regulator.

The National Payment Corporation of Vietnam (NAPAS), the Vietnam Banks Association, standards bodies, auditors, and cloud providers are not regulators. Their standards and contracts can still affect operations.

What I would do

For each new bank technology initiative, I would first answer:

  • What legal entity is delivering the service?
  • Which product, channel, payment system, or regulated activity does it use?
  • Which systems and data does it involve?
  • Which instrument states the duty and names the authority?
  • What evidence will prove the control works in design, delivery, and operation?

I would then maintain:

  • Scope record: Record the entity, product, system, data, customers, and legal requirements currently in force.
  • Authority map: Name the policy owner, report recipient, supervisor, inspector, and accountable bank executive.
  • System register: Record each system's classification, importance, dependencies, data flows, recovery targets, and owner.
  • Control map: Link each legal clause to a control, implementation, evidence, reviewer, and review schedule.
  • Delivery evidence: Save threat models that identify likely attacks. Also save design decisions, code reviews, security tests, approvals, release records, and rollback results.
  • Access evidence: Save privileged access records, approvals, access reviews, administrator sessions, and separation of duties. This separation stops one person from completing a sensitive task alone.
  • Supplier evidence: Record supplier checks, data location, subcontractors, service levels, incident duties, exit terms, data return, and deletion.
  • Operations evidence: Keep logs, alerts, cases, vulnerability records, incident records, exercises, recovery tests, and fixes.
  • Reporting map: Record each trigger, recipient, deadline, approver, channel, and proof of submission.
  • Change watch: Track amendments, repeals, transition dates, guidance, and open legal questions.

This is an engineering interpretation, not a checklist from the law. The bank's legal, compliance, security, risk, and audit teams must review it.

Do not send every issue to the Information Technology Department. Build a traceable map from authority to rule, rule to control, and control to evidence.

Governance does not end with identifying the rules. Using COBIT to govern a bank technology team shows how I connect enterprise goals, technology decisions, and evidence. Buying or building a loan origination system is one example of where those regulatory and ownership questions become an architecture decision.

Sources