Reaching MSB Digital Bank account data under Vietnam's open-API rules

Vietnam got its first binding open-API rulebook on 1 March 2025, when the State Bank of Vietnam's Circular 64/2024/TT-NHNN came into force. For a retail app like MSB Digital Bank — the super app from Vietnam Maritime Commercial Joint Stock Bank — that shifts the cleanest path to a customer's account data toward standardized, consent-based access. The bank's transaction surfaces, savings positions, Napas 247 transfers and expense categories all sit behind an authenticated session today; what the circular adds is a documented way to reach a defined slice of them with the account holder's explicit consent.

This page lays out the data MSB Digital Bank actually holds, the authorized routes into it for your market, and what we hand over at the end. Short version: where MSB has published its Circular 64 catalog, consent-based Account Information Services is the path I would anchor a build on; where a surface you need is not yet in that catalog, we reach it by replicating the app's own authorized calls under your authorization.

Circular 64, consent, and the data-sharing window

The circular sets the technical and legal frame for banks and third parties to exchange financial data through standardized APIs, with the customer's consent at the centre. Its basic catalog (Article 6, per the published text) spans account-information queries — customer confirmation, consent, access-token retrieval, account and balance lookups — alongside payment-initiation calls and reference data such as rates. Authentication leans on OAuth 2.0 (RFC 6749) and bearer tokens (RFC 6750), with TLS 1.2 or higher on the wire and ISO 20022 / ISO 8583 as the data standards.

Two timing facts shape how a sync is built. Banks were to submit their API catalogs and deployment plans to the SBV by 1 July 2025, with full compliance required by 1 March 2027 — so a given surface may be live now or still pending publication. And once a customer consents, the access window runs to a maximum of 180 days unless the customer and bank agree otherwise. The dependable basis for any access we build is that consent: granted, logged, and revocable by the account holder through the bank's consent tools. We design around the renewal point so a feed does not lapse silently.

What sits behind an MSB Digital Bank login

The app is built around a free lifetime current account opened by eKYC, then layered with savings, payments and a personal-finance view. The surfaces below are the ones an integrator typically wants, named the way the app presents them.

Three authorized routes into the account data

1 · Consent-based AIS under Circular 64

Where MSB has published the relevant endpoints, this reaches account and balance queries and the transaction list through the SBV's standardized catalog, authenticated with OAuth 2.0 and scoped by the customer's consent. It is the most durable option because it is a regulated standard rather than a private surface — it survives app releases, and the 180-day consent window is a known quantity. Onboarding (the bank–third-party contract and access credentials) is arranged with you as part of the engagement.

2 · Authorized interface integration

This replicates the calls the mobile client itself makes after an authorized, consenting session signs in — modelling the token and device-attestation chain rather than working around it. Reach is wide: in practice it covers anything the app shows the account holder, including surfaces not yet in the published catalog. Effort is moderate and durability tracks the app version, so we wire a re-validation step into maintenance for when the front end changes.

3 · User-consented export

Where a consenting account is used directly, statement and history exports give a lighter-touch feed for one-off or low-frequency needs, useful as a backstop while standardized endpoints are pending.

For most teams I would anchor on route 1 the moment MSB's catalog covers the surface you need, and use route 2 to fill the gaps until it does — that combination gives you a standardized core without waiting on the full 2027 compliance horizon for everything.

A statement pull, sketched

Illustrative shape of the AIS flow — exact field names are confirmed against the live consent flow during the build, not assumed here.

# Step 1 — consent-scoped token (RFC 6749 / 6750)
POST /oauth2/token
  grant: authorization_code + consent_id
  scope: "ais:accounts ais:balances ais:transactions"
  -> { access_token, expires_in, consent_id }

# Step 2 — balance for a chosen account
GET /accounts/{accountId}/balances
  Authorization: Bearer <access_token>
  X-Consent-Id: <consent_id>
  -> { currency: "VND", available, ledger, asOf }

# Step 3 — Napas 247 transaction history, paged
GET /accounts/{accountId}/transactions?from=2026-01-01&pageSize=100
  -> items[]: {
       bookingDate, amount, currency: "VND",
       counterparty, napas247Ref,
       rail: "internal" | "interbank",
       category            # maps to the in-app expense view
     }

# 410 / consent_expired -> trigger re-consent before day 180
      

What lands in your repo

Each build is scoped to the MSB surfaces you actually need. The hand-over normally includes:

• An OpenAPI / Swagger spec describing the account, balance, transaction, savings and card calls we implement.
• A protocol and auth-flow report covering the OAuth 2.0 token exchange, the consent-id handling, and how the FIDO and device-attestation steps fit the session.
• Runnable source for the key endpoints in Python or Node.js — a working client for balances and Napas 247 history, not snippets.
• Automated tests, including the consent-expiry and re-consent path, and the internal-versus-interbank split.
• Interface documentation plus data-retention and consent-logging guidance aligned to Vietnam's data-protection law.

Where integrators put this data to work

• A bookkeeping tool syncing a customer's MSB current-account transactions each night, categorized and de-duplicated across the two transfer rails.
• A personal-finance app combining MSB savings positions and categorized spend into one budget view.
• A lender pulling consented transaction history for an affordability check, with the consent record kept for audit.
• A treasury dashboard aggregating MSB balances alongside other Vietnamese bank accounts under one consent model.

Engineering details we plan around

Two things about MSB specifically that we account for, so they are handled rather than discovered late:

• Two transfer rails. Napas 247 carries both internal MSB transfers and interbank ones; we tag the rail on every booking and keep them distinct so reconciliation does not count a single movement twice.
• The consent clock. Circular 64 caps an access grant at 180 days. We build the sync to renew consent ahead of expiry and to fail loudly — not silently — if a grant lapses, with the re-consent path covered by tests.
• App shielding and FIDO. MSB runs FIDO transaction authentication, face authentication and Bshield app protection. We model the device-attestation and FIDO step as part of an authorized session, which is what keeps route 2 within authorized use; access to a consenting account or sandbox is arranged with you during onboarding.

Screens from the app

Public Play Store screenshots, used to map the surfaces named above. Select to enlarge.

Pricing and how a build runs

A scoped MSB integration takes one to two weeks. Source-code delivery starts at $300: you get the runnable client, the OpenAPI spec, the tests and the documentation, and you pay only after it is in your hands and you have confirmed it works. The alternative is the pay-per-call hosted API — you call our endpoints and pay per call, with no upfront fee, when you would rather not run the integration yourself. You bring the app name and what you want out of its data; access, sandbox or consenting-account arrangements and the compliance paperwork are handled with you as part of the work. To start a build or talk through scope, get in touch with OpenBanking Studio.

Sources checked for this mapping

Mapped in June 2026 against MSB's own product pages and the published text of Circular 64. Primary sources: the MSB Digital Bank product page; the SBV's press release on Circular 64/2024/TT-NHNN; the full Circular 64 text; and an industry read-out on the new rules. Reviewed by the OpenBanking Studio integration desk, June 2026.

Related apps in Vietnam's banking and wallet space

Useful context for anyone aggregating more than one Vietnamese account. Each holds account or wallet data a unified integration might cover; this is ecosystem context, not a ranking.

• Timo — digital bank holding account, card and savings data, an early adopter of eKYC onboarding.
• Cake by VPBank — digital bank with accounts, cards, savings and lending records behind a login.
• VCB Digibank (Vietcombank) — incumbent-bank app with transfers, card and account data.
• VietinBank iPay — retail banking app holding balances, transfers and bill-payment history.
• BIDV SmartBanking — large-bank app with account, transfer and payment records.
• ViettelPay — digital financial service with wallet, transfer and bill-pay data.
• MoMo — super-app wallet holding balances, payment and merchant-transaction history.
• ZaloPay — wallet app with transfers, top-ups and bill payments tied to the Zalo account.

Questions integrators ask about MSB Digital Bank

Does MSB Digital Bank's data fall under Vietnam's Circular 64 open-API rules?

MSB is a licensed Vietnamese bank, so its account data sits within the State Bank of Vietnam's Open API framework set by Circular 64/2024/TT-NHNN. The circular took effect on 1 March 2025, with full bank compliance due by 1 March 2027, and it covers Account Information Services and Payment Initiation Services under explicit customer consent with an access window of up to 180 days.

Can you reach Napas 247 transfer history, or only current balances?

Transaction-level history is in scope, not just the balance. We pull each booking with its amount in VND, the counterparty, the timestamp and the Napas 247 reference, and we keep internal transfers separate from interbank ones so reconciliation does not double-count.

How do you deal with MSB's FIDO authentication and Bshield app shielding?

We model the device-attestation and FIDO step as part of the authenticated session rather than working around it. The integration mirrors how a genuine, consenting session signs in, which is what keeps it within authorized use and what we write up in the auth-flow report.

If MSB has not published its Circular 64 API catalog yet, can a build still start?

Yes. Until the consent-based endpoints are published, we replicate the app's own authorized calls against a consenting account, then move that integration onto the standardized AIS endpoints once MSB lists them. You get a working result now and a cleaner path later.