Reaching MBBank account data under Vietnam's Circular 64

Getting to MB Group account data

Since 1 March 2025, consented programmatic access to a Vietnamese bank customer's account list, balances and transaction history has had a named legal channel: Circular 64/2024/TT-NHNN, issued by the State Bank of Vietnam. MB — the Military Commercial Joint Stock Bank, whose MBBank app reports more than 41 million users across its Android and iOS builds — operates inside that regime. That shifts the calculus for an integrator. The account-level surfaces most projects want are exactly the ones the regulation puts on a consent-and-token footing; the wider MB Group views sit a layer past the catalogue. This brief covers both, and says which we would build first.

Consented Open API under Circular 64

The circular defines an Open API catalogue that includes customer confirmation and consent, access tokens, account lists, account information and transaction history, plus payment initiation. Access is gated by OAuth 2.0 and OpenID Connect over TLS 1.2 or higher, per the SBV framework. For MB, this is the durable channel: the field semantics are regulation-defined, so a client written against them survives an app redesign. We register as the third party and stand up the consent capture with you.

Authorized interface integration

Several MB surfaces sit outside that catalogue — the consolidated MB Group asset and liability rollup the app calls its digital warehouse, savings terms, loan schedules, bill-pay history and Membership vouchers. For these we analyze the MBBank client's own request and response traffic against a consenting account and build a typed client that mirrors what the app itself calls. Effort here is higher and the client tracks app releases, so we treat maintenance as part of the deliverable.

User-consented export as a backstop

Where a customer can pull a statement or export from within the app, we can normalize that file into the same schema as a lower-frequency fallback. It is a supplement, not the basis of a live sync.

For MB the split is clean, so we state it plainly. Anything the Circular 64 catalogue already names — account list, balances, transaction history, payment initiation — we build on the consented Open API channel, because those fields are regulation-defined and outlast front-end churn. The group asset rollup, deposit and loan detail, and bill-pay history are not catalogued, so those we reach by authorized interface integration against a consenting account. Almost every engagement ends up spanning both, and we scope it as a single client with one normalized output.

What the MBBank app actually holds

Each row below is a surface the app exposes to its own users, mapped to what an integrator does with it.

A consented statement pull, sketched

The shape below is illustrative — the exact paths and field names are confirmed against the live surface during the build. It shows the consent token exchange, then a read of the account list and one account's transaction history, the pattern the Circular 64 catalogue is built around.

# 1. Exchange the customer's consent grant for a scoped access token
#    OAuth 2.0 / OpenID Connect, TLS 1.2+ (Circular 64 baseline)
POST /oauth2/token
  grant_type=authorization_code
  code=<consent_grant>
  scope="accounts:read transactions:read"
-> { "access_token": "...", "expires_in": 3600,
     "consent_expiry": "2026-12-29" }   # <= 180 days from consent

# 2. List the customer's MB accounts
GET /accounts            Authorization: Bearer <access_token>
-> [ { "accountNo": "…", "type": "CURRENT",
       "currency": "VND", "availableBalance": 0,
       "ledgerBalance": 0 } ]

# 3. Read transaction history for one account, date-bounded
GET /accounts/{accountNo}/transactions?from=2026-01-01&to=2026-06-30
-> [ { "txnId": "…", "valueDate": "2026-06-14",
       "amount": -250000, "currency": "VND",
       "counterparty": "…", "channel": "TRANSFER",
       "description": "…" } ]

# Transfer/payment initiation carries the app step-up
# (Digital OTP or e-signature); read calls stay off that path.

What lands in your repository

• An OpenAPI/Swagger specification covering the MB surfaces in scope — accounts, transactions, transfers, savings, loans — with request and response schemas and the VND currency handling made explicit.
• A protocol and auth-flow report: the OAuth 2.0 / OpenID Connect consent-and-token chain for the catalogued surfaces, and the observed request signing and step-up (Digital OTP, e-signature) for the interface-integration surfaces.
• Runnable source for the key endpoints in Python or Node.js — token exchange, account list, transaction history with date bounds, and the MB Group rollup read.
• Automated tests against recorded fixtures, including the 180-day consent-expiry and refresh path.
• Interface documentation an engineer can follow, plus data-retention and consent-logging guidance aligned to how the data may be used.

Consent and Circular 64, in practice

Circular 64/2024/TT-NHNN is the specific instrument here, not a generic open-banking reference. It requires explicit consent from the data owner, gives customers tools to look up which data they have consented to share and to withdraw that consent, and sets the third-party access window at no more than 180 days after consent unless the customer and bank agree otherwise. Security sits on OAuth 2.0 and OpenID Connect, TLS 1.2 or higher, digital signatures and ISO 27001-aligned controls. Vietnam's personal-data protection rules (Decree 13/2023/ND-CP) apply to how the data is then held and used. We operate authorized, logged and data-minimized, with consent records kept and an NDA in place where the work touches sensitive material.

Build details we plan around

The Circular 64 rollout is still in motion. Banks were to submit their API lists and deployment plans to the SBV during 2025, with full compliance due by 1 March 2027, so per-bank catalogue coverage is maturing rather than complete. We design the MB client to detect which catalogued endpoints are live and fall back to interface integration for any that are not yet exposed, then re-check that coverage during maintenance instead of assuming it is fixed.

MB's app consolidates several MB Group entities into one digital warehouse view. We map which figures are single-account level and which are group aggregates, so a downstream net-worth or exposure calculation does not double-count a holding that already sits inside the rollup total.

Read and write paths get different handling. Balance and transaction reads run on the scoped token alone; anything that initiates a transfer or payment triggers the app's Digital OTP or e-signature step-up, and the client carries that challenge through rather than tripping over it. Registration as the third party and the consent capture are set up with you during the build — the client side gives us the app name and what they want out of the data, and we handle the rest.

Cost, and how the hand-off works

Source-code delivery starts at $300, and you pay after we hand the code over and you have confirmed it runs against MB's surfaces. That is one way to work with us. The other is a hosted API: you call our endpoints for MB and pay per call, with nothing upfront. Either way the cycle is one to two weeks from the point access is arranged. Tell us the app and what you need from its data to start — get in touch here.

Staying current as MB ships

MBBank updates often — its listings describe dozens of mini-apps and a steady stream of features. Front-end and traffic changes touch the interface-integration surfaces more than the catalogued ones. After a notable MB release we re-run the client against the live surfaces, compare field shapes, and patch any drift before it reaches your data. The catalogued Open API paths are the stable core; the observed surfaces are where we watch for change.

Screens we mapped

App-store screenshots of MBBank we reviewed while scoping the surfaces above. Select to enlarge.

How this brief was put together

Compiled from MB's own app-store listings for the surface list and user figure, and from the State Bank of Vietnam's own materials on Circular 64/2024/TT-NHNN for the regulatory route, consent window and security baseline. Checked in July 2026 against the sources below.

• State Bank of Vietnam — press release on Circular 64/2024/TT-NHNN
• Circular 64/2024/TT-NHNN — English text (LuatVietnam)
• Brankas — how Circular 64 defines consent, the 180-day window and the API catalogue
• MB Bank on Google Play (com.mbmobile)

Compiled at the OpenBanking Studio integration desk — reviewed 2 July 2026.

Other Vietnamese banking and wallet apps

Same-market apps an aggregator often wants alongside MB, each holding comparable account-level data behind consent:

• Vietcombank (VCB Digibank) — accounts, transfers and card management at Vietnam's largest state-linked bank.
• Techcombank Mobile — retail accounts, savings, investments and QR payments.
• VPBank NEO and Cake by VPBank — traditional and digital-only accounts under the VPBank group.
• VietinBank iPay — retail and SME banking with a broad payment feature set.
• BIDV SmartBanking — accounts, transfers and bill payment at another large state-linked bank.
• ACB (Asia Commercial Bank) — private-bank accounts and card servicing.
• Sacombank Pay — banking plus a wallet layer over Sacombank accounts.
• TPBank — digital-first accounts, including its LiveBank self-service model.
• MoMo — e-wallet holding balances, transaction history and linked-account data.
• ZaloPay — wallet and payments tied into the Zalo ecosystem.

Questions integrators ask about MBBank

Which MBBank surfaces move through the Circular 64 catalogue, and which need interface integration?

The State Bank of Vietnam's Circular 64 catalogue names account lists, account information, transaction history and payment initiation, so those we build on the consented Open API channel. The MB Group asset rollup, savings terms, loan schedules, bill-pay history and Membership vouchers are not in that catalogue, so we reach them through authorized interface integration against a consenting account. Most projects use both, delivered as one client.

Does MBBank's biometric login, Digital OTP and e-signature block a third-party integration?

No. The Circular 64 model issues a scoped access token after the customer consents, so read access does not require sharing the biometric credential. Where a call initiates a transfer or payment, we carry the app's step-up challenge (Digital OTP or e-signature) correctly and keep read-only calls off that path.

How does the 180-day consent window affect a running MB sync?

Circular 64 caps third-party access at 180 days after the customer grants consent, unless the customer and the bank agree otherwise. We design the sync to track that expiry per consent record and prompt renewal before it lapses, so the feed does not go dark unexpectedly.

Are MB balances and transactions returned in VND, and how do international transfers show up?

Domestic account balances and transactions are denominated in VND, and the client normalizes amounts with an explicit currency field so nothing is assumed. MB supports 24/7 domestic and international transfers, so cross-border entries carry the counterparty, channel and any FX detail we can read from the transfer surface.