Circular 64/2024/TT-NHNN took effect on 1 March 2025, and it draws the first proper map for reaching a Vietnamese bank account by API with the holder's consent. That changes the conversation around an app like MSB mBank (Cá nhân) — the personal banking app from Vietnam Maritime Commercial Joint Stock Bank (MSB). The account data is real and structured: a free lifetime current account opened by eKYC, online savings deposits, an M-Pro debit card, and Napas 247 transfer history. The question a developer brings us is narrower than the regulation: how do I read and sync that, today, for a real user. This page sets out what the app holds, the route we would take to it, and what we hand over.
MSB mBank at a glance
The short version: everything a customer sees in the app is reachable behind an authenticated, device-bound session. We would build the read path first — balances, statement history, savings and card — under the account holder's authorization, and keep the account-information calls shaped so they can move onto the regulated consent endpoints once MSB exposes them. Payment initiation is a separate, later conversation because of the biometric gate Vietnam puts on it.
What the app keeps behind the login
These rows reflect surfaces the app's own Play Store listing describes, mapped to what an integrator does with each.
| Data domain | Where it lives in the app | Granularity | What an integrator does with it |
|---|---|---|---|
| Current account balance & details | Account home — the free lifetime current account | Per account, real-time balance, account number | Net-position views, balance alerts, multi-account dashboards |
| Transaction & statement history | Account activity feed | Per posting: date, amount, narrative, Napas 247 reference | Reconciliation, categorisation, cash-flow analysis |
| Online savings deposits | Savings section — term deposits with chosen tenor | Per deposit: principal, rate, term, maturity | Goal tracking, maturity reminders, yield reporting |
| Napas 247 transfers | Transfer and scheduled-transfer flows | Per transfer: counterparty, amount, status, schedule | Payout monitoring, scheduled-transfer sync, audit trails |
| M-Pro debit card | Card management | Card status, linked account, recent card activity | Spend feeds, card-state checks |
| Bills & top-ups | Utility payments and auto-recharge | Per biller: payee, amount, recurrence | Recurring-payment tracking, expense rollups |
Authorized routes into the account
Three routes genuinely apply to MSB mBank. They are not equal in effort or in how long they keep working.
1 · Authorized interface integration (protocol analysis of the app traffic)
We capture and document how the app authenticates and how it asks its backend for balances, statements, savings and transfers, working from a consenting test account that you and we set up during onboarding. Reachable: anything the app itself can show. Effort: moderate — the session is bound to an enrolled device and tokens expire, so the auth chain has to be reproduced faithfully. Durability: tied to the app version, so it needs a watch on response shapes. This is what delivers a working integration in the current cycle.
2 · Consent-based AIS under Circular 64
The State Bank of Vietnam's Open API regime defines a standardized, consent-driven account-information path with explicit grant, revoke and monitor controls. Reachable: the catalogued account-information fields a bank publishes. Effort: low once a bank's endpoints are live; high if you are waiting on them. Durability: high, because it is regulated rather than scraped. Banks have until 1 March 2027 to comply in full, so we treat this as where the read calls migrate, not where they start today.
3 · User-held export as a supplement
Where a customer can pull an e-statement or savings record from the app, that export is a cheap way to backfill history or cross-check the live feed. It is a supplement, not a sync — it does not give you real-time balances.
For most MSB requests we would build on route 1 because it returns the live data a user actually sees, and write the account-information layer as a thin adapter so the same calls can be repointed to the route 2 consent endpoints the moment MSB's catalog is published. Route 3 fills in history where a project needs a longer look-back than the app's feed gives.
A statement pull, sketched
Illustrative only — host and field names are confirmed against a consenting account during the build, not lifted from any MSB document.
# Read path: device-bound session -> account statement
import requests
BASE = resolve_mobile_host() # MSB mobile backend, resolved at build time
def login(device_id, username, assertion):
# MSB binds the session to an enrolled device; sensitive actions
# trigger a face-match step under SBV Decision 2345 (not read calls).
r = requests.post(f"{BASE}/auth/token", timeout=20, json={
"deviceId": device_id,
"username": username,
"assertion": assertion, # OTP or biometric token from the device
})
r.raise_for_status()
return r.json()["accessToken"]
def statement(token, account_no, frm, to):
r = requests.get(f"{BASE}/accounts/{account_no}/transactions",
headers={"Authorization": f"Bearer {token}"},
params={"from": frm, "to": to, "channel": "MB"}, timeout=20)
if r.status_code == 401: # token expired or device re-bind needed
raise SessionExpired()
r.raise_for_status()
return [{
"postedAt": t["effectiveDate"],
"amount": t["amount"],
"currency": t.get("ccy", "VND"),
"napasRef": t.get("napas247Ref"), # preserved for reconciliation
"narrative": t["description"],
} for t in r.json()["items"]]
The two things that make this MSB-specific: the device binding in login(), and keeping napas247Ref on every posting so downstream reconciliation can match a transfer back to the Napas 247 rail.
What lands in your repository
The deliverable is the integration, not a report about one. For MSB that means:
- An OpenAPI/Swagger spec for the account, statement, savings, card and transfer surfaces we wire up.
- A protocol and auth-flow report: the device-binding handshake, token issue and refresh, and where Decision 2345's biometric step sits relative to read versus write calls.
- Runnable source for the key endpoints in Python or Node.js — login, balance, statement paging, savings list — not stubs.
- Automated tests against recorded fixtures, plus a normalized account schema that flattens current account, savings and card into one model.
- Interface documentation and data-retention guidance covering consent records and logging.
The consent rules that apply in Vietnam
Two State Bank of Vietnam instruments shape this work. Circular 64/2024/TT-NHNN, in force since 1 March 2025 per the SBV press release, sets the consent-based Open API framework — account information, payment initiation and loan services — and requires participants to run consent-management and Strong Customer Authentication modules, with full bank compliance due 1 March 2027. Decision 2345/QĐ-NHNN, effective 1 July 2024, requires a biometric face-match before a customer's first transaction on a new device and for transfers over VND 10 million each, or over VND 20 million in a day. Read-only account access does not trip that threshold, which is why we scope MSB engagements read-first. Across both, our posture is the same: access is authorized or user-consented, every pull is logged against a consent record, data is minimized to what the integration needs, and an NDA is in place where the work touches anything sensitive.
What we plan for on an MSB build
Two things on this app need deliberate handling, and we account for them rather than hand them back as conditions:
- Device binding and biometric placement. MSB ties a session to an enrolled device, and Decision 2345 puts a face-match in front of sensitive actions. We model the enrolment once during onboarding with a consenting account, keep the read path clear of the biometric gate, and document exactly where that gate would apply if a project later adds payment initiation.
- Mixed product shapes under one login. A current account, a term savings deposit and an M-Pro card each report differently. We normalize them into a single typed account model so a downstream system does not special-case each one, and we preserve Napas 247 references so transfers stay reconcilable.
- App releases. MSB ships updates often, so the maintenance plan includes a monitoring check that flags when a response shape moves, before a parser starts dropping fields quietly.
Access to a sandbox or a consenting account is arranged with you as part of onboarding — it is something the project sets up, not a hurdle you clear before we begin.
Working with us, and the cost
Most MSB builds land inside one to two weeks. You can take it as source you own outright — runnable API source plus the OpenAPI spec, the auth-flow report, tests and interface docs, from $300, billed only after delivery once you have checked it and you are satisfied. Or skip running anything yourself and call our hosted endpoints instead, paying per call with nothing upfront. Same data either way; the choice is whether you want code in your repo or a metered API. Tell us the app and what you need from its data on the contact page and we will scope it.
Where teams point an MSB integration
- A personal-finance app that folds a user's MSB current account and savings into one net-worth and budget view.
- An SME bookkeeping tool that reads MSB transaction narratives and Napas 247 references to auto-reconcile invoices and payouts.
- A lender that, with the applicant's consent, reads MSB statement history to judge cash flow before underwriting.
- A treasury dashboard that mirrors scheduled and future transfers so finance teams see committed outflows ahead of time.
Screens we worked from
The app's published screenshots, used to map the surfaces above. Select to enlarge.
What we checked, and when
We read MSB mBank's Google Play listing for the live feature set and the vn.com.msb.smartBanking package identifier, the State Bank of Vietnam press release issuing Circular 64/2024/TT-NHNN, the published Circular text for scope and timeline, and the SBV statement on Decision 2345 for the biometric thresholds. Citations:
- MSB mBank on Google Play
- SBV — press release on Circular 64/2024/TT-NHNN
- Circular 64/2024/TT-NHNN — full text (English)
- SBV — Decision 2345 biometric authentication
Compiled by the OpenBanking Studio integration desk — 23 June 2026.
Other Vietnamese banking apps in the same picture
An aggregation that reads MSB usually wants to read its neighbours too. These are the apps that show up in the same brief, named for keyword reach, not ranked.
- VCB Digibank — Vietcombank's retail app for accounts, cards and transfers at the country's largest state lender.
- Techcombank Mobile — accounts, savings, cards and spending insights from a leading private bank.
- BIDV SmartBanking — accounts, transfers and bill pay across one of the big-four state banks.
- VietinBank iPay Mobile — accounts, savings and cards; VietinBank also runs its own Open API portal.
- VPBank NEO — accounts, savings, loans and card controls in one app.
- MB Bank (MBBank) — accounts, transfers and in-app savings and lending.
- TPBank Mobile — accounts and LiveBank self-service flows for a digital-first bank.
- Timo — a VPBank-backed neobank with current accounts and goal-based savings.
- Cake by VPBank — a digital-only account known for high-rate savings.
Questions integrators ask about MSB mBank
Can you merge MSB's current account, online savings and card records into one schema?
Yes. The current account, a fixed-term savings deposit and an M-Pro debit card each come back from the app in a different shape, so the build normalizes them into one account model with a typed product field, a balance, a currency (VND by default) and a transaction list, so a downstream system reads them the same way.
Does Decision 2345's biometric rule stop you reading MSB statements?
No. SBV Decision 2345 requires a face-match before the first transaction on a new device and for transfers above VND 10 million per transaction or VND 20 million in a day. Reading balances and statement history does not trip that step, so the read-only account-information build is unaffected; we flag the biometric gate only where a project later adds payment initiation.
Which regulator and rule covers API access to a Vietnamese bank like MSB?
The State Bank of Vietnam. Circular 64/2024/TT-NHNN, in force since 1 March 2025, defines the consent-based Open API path covering account information, payment initiation and loan services, with full bank compliance due by 1 March 2027; Decision 2345 governs the biometric authentication layer for sensitive actions.
If MSB's Open API catalog is not live yet, can you still deliver an integration?
Yes. Working from the account holder's authorization, we map the app's own traffic and deliver runnable source against the live surfaces now, and design it so the account-information calls can be repointed to the regulated consent endpoints as Vietnamese banks publish their catalogs ahead of the 2027 deadline.
App profile — MSB mBank (Cá nhân)
MSB mBank (Cá nhân) is the personal mobile banking app of Vietnam Maritime Commercial Joint Stock Bank (MSB), headquartered in Hanoi. Per its Google Play listing, the package identifier is vn.com.msb.smartBanking and it runs on Android and iOS. Headline features include a free lifetime current account opened by eKYC, choice of account number, online savings with term deposits, an M-Pro domestic debit card, Napas 247 internal and interbank transfers, scheduled and future transfers, bill payment and auto top-up, expense tracking, and an ATM/branch locator. The listing cites a "Best Digital Transformation Bank in Vietnam 2022" award from The Global Economic Magazine. This profile is a neutral recap for context.