Reaching HDBank account data under Vietnam's Circular 64

On 1 March 2025 a new rulebook started governing how Vietnamese banks share account data: Circular 64/2024/TT-NHNN from the State Bank of Vietnam, which puts customer consent and standardized Open APIs at the centre of bank-to-third-party data sharing, with banks given until 1 March 2027 to comply in full (per the published legal analyses cited below). HDBank — Ho Chi Minh City Development Joint Stock Commercial Bank, packaged as com.vnpay.hdbank per its Play Store listing — sits squarely inside that regime. This brief maps what its app holds, the authorized ways to reach it, and the source code we hand over at the end.

The short version: HDBank holds the full set of retail-banking records a third party would want to sync, and Vietnam now has a named open-banking instrument for reaching them with consent. Where HDBank has published a live consent endpoint we build against it; where the schedule hasn't reached a given surface yet, we work from the app's own authenticated traffic under your authorization and design the result so it can swap onto the standardized endpoint later. More on that trade-off below.

Circular 64, consent, and Vietnamese data law

Circular 64/2024/TT-NHNN defines the technical and legal frame for Open APIs in Vietnamese banking: standardized interfaces for Account Information Services, Payment Initiation, loan origination and other financial products, with OAuth-style authentication (the analyses reference RFC 6749 and RFC 6750), TLS 1.2 or higher in transport, and ISO 20022 / ISO 8583 message formats. Consent from the account holder is the gate on every data pull, and it carries a scope and an expiry — a sync built without respecting revocation will quietly break, so we treat consent lifecycle as a first-class part of the design.

Personal data sits under Decree 13/2023/ND-CP, in force since 1 July 2023, which sets data-subject rights, a 72-hour breach-notification window, and impact-assessment duties for cross-border transfers of Vietnamese citizens' data. We operate inside that: authorized or user-consented access only, access logged, data minimized to the domains your project needs, NDA where the engagement calls for one. Compliance is how we work, not a hoop we hand you.

What sits behind an HDBank login

The surfaces below come from the app's own feature list and store description. Granularity is what an integrator should expect to see once a session is established.

Routes in

Three approaches genuinely apply to HDBank. They are not mutually exclusive — a build often starts on one and folds in another.

Circular 64 AIS / PIS consent

The regulated path. Reachable: account information and payment initiation as HDBank publishes them under the SBV standard. Effort: moderate where an endpoint and a consenting account are live, since the auth and message shapes are specified. Durability: high — a standardized interface changes slowly and is the long-run home for this integration. We handle the consent onboarding and the registration steps with you as part of the project.

Authorized protocol analysis

Where a given surface isn't yet on a published consent endpoint, we map the app's own client-server exchange under your authorization: the token and HDBank-OTP handshake, the account-inquiry and statement calls, the transfer flows. Reachable: anything the app itself shows. Effort: higher up front. Durability: tied to the app's front end, so we add a re-validation pass to maintenance and design the client to re-point onto the Circular 64 endpoint as those go live.

User-consented credential access

For a one-account or low-volume need, a consenting account holder can authorize a session we drive directly. Reachable: that account's full view. Effort: low. Durability: fine for narrow scopes; it doesn't scale to many users the way the consent API does.

For most HDBank projects the Circular 64 consent path is the one worth committing to, because it is the surface the regulator is steering the whole market onto by March 2027 — we'll typically stand up protocol analysis alongside it only to cover the domains that haven't reached a live endpoint yet, then retire that scaffolding as they do.

Engineering details we plan around

• HDBank separates three transfer rails — internal, NAPAS 24/7 to other member banks, and card-to-card. We model each as its own flow because the status lifecycle and reference fields differ, then normalize them into a single transaction schema so the consumer of the feed never special-cases the rail.
• The login mixes biometric unlock with an HDBank OTP step that the State Bank requires for transaction authentication. Biometrics release a device-local credential; the OTP is server-validated. We map the exchange the server actually checks and run against a consenting account or sandbox that completes the OTP, so sessions establish the same way the app establishes them.
• Consent under Circular 64 carries a scope and an expiry. We build the sync around the refresh window so it renews on schedule and surfaces a clear signal on revocation, rather than failing silently mid-cycle.
• Several non-banking surfaces — VNPAY-QR history, flight bookings, the chatbot-driven actions — share the authenticated session with the bank accounts. We scope each domain explicitly so the integration pulls only what your project needs and nothing it doesn't.

Access, sandboxes and the consent paperwork are arranged with you during onboarding; that setup is our job on the engagement, not a checklist you clear before we begin.

A statement query, sketched

Illustrative only — exact paths and field names are confirmed during the build against the live surface. This shows the shape: a consented token, then a per-account statement pull, normalized.

POST /oauth2/token            # Circular 64-style, RFC 6749
  grant_type=authorization_code
  code=<consent_grant>         # account-holder consent, scoped + expiring
  -> { access_token, expires_in, scope: "ais:accounts ais:transactions" }

GET /ais/v1/accounts/{accountId}/transactions?from=2026-05-01&to=2026-05-31
  Authorization: Bearer <access_token>     # TLS 1.2+
  -> 200 {
       "account": "HDB-****1234",
       "currency": "VND",
       "transactions": [
         { "postedAt": "2026-05-14",
           "amount": -250000,
           "rail": "NAPAS_247",            # internal | NAPAS_247 | card
           "counterparty": "VCB ****8890",
           "ref": "IBFT..." }
       ]
     }
  -> 401  refresh via /oauth2/token or re-consent if revoked
  -> 403  scope outside the consent grant — narrow the request

The same pattern covers balances, card movements and the three transfer flows; we wire retry, token refresh and a revocation path into the runnable client so it doesn't fall over on the first expired session.

What you receive

Each item below is tied to an HDBank surface, not a generic checklist.

• An OpenAPI/Swagger spec covering the account-inquiry, statement, transfer and card endpoints as modelled for HDBank.
• A protocol and auth-flow report: the token exchange, the HDBank-OTP step, session handling, and how consent scope and expiry behave.
• Runnable source for the key calls in Python or Node.js — balance read, statement pull, transfer-status lookup — with retry and refresh built in.
• A normalized transaction schema that flattens the three transfer rails into one consistent shape.
• Automated tests against recorded responses, plus interface documentation and data-retention guidance keyed to Decree 13.

Pricing and how to start

Source code lands in your repository, not ours. For a fixed delivery you pay from $300 for the runnable integration and its documentation, settled after delivery once you've checked it does what the brief promised. If you'd rather not run anything yourself, we host the endpoints and you pay per call, with nothing upfront. Either way the build runs on a 1–2 week cycle, and you bring only the app name and what you want out of its data. Start the conversation at /contact.html.

Where this gets used

• An accounting tool pulling an SME's HDBank statements nightly so VND ledgers reconcile without manual export.
• A treasury dashboard reading balances across deposit and card accounts for a daily cash position.
• A payout platform tracking NAPAS 24/7 transfer status to confirm settlement to other Vietnamese banks.
• An expense app capturing VNPAY-QR payments and flight bookings against the same authenticated session.

Screens we worked from

Public store screenshots used while mapping the surfaces above. Click to enlarge.

Other Vietnamese banking apps in the same picture

Circular 64 applies across the market, so a unified integration usually spans several of these. Listed for context, not ranked.

• Vietcombank (VCB Digibank) — the largest retail base; deposit, card and transfer data behind a consented login.
• Techcombank Mobile — a digital-banking leader with rich account and payment surfaces.
• VPBank NEO — retail accounts, cards and fast digital loans.
• MBBank — very high digital-transaction share; large account and transfer dataset.
• BIDV SmartBanking — broad state-bank account and statement coverage.
• ACB ONE — private-bank accounts, cards and transfers.
• TPBank — mobile-first accounts and payment history.
• VietinBank iPay — accounts, cards and bill-payment records.
• Sacombank Pay — accounts, QR payments and transfer data.

Questions integrators ask about HDBank

Does Circular 64 mean HDBank already exposes a consent API I can call today?

Circular 64/2024/TT-NHNN took effect on 1 March 2025 and sets full-compliance for banks by 1 March 2027, so the consent endpoints are arriving on a phased schedule rather than all at once. Where an HDBank AIS or PIS surface is live and a consenting account is available, we build against it; where it is not yet published, we run authorized protocol analysis of the app's own traffic so the integration works now and can re-point to the standardized endpoint later.

Can you read both the NAPAS outbound transfers and the in-bank movements?

Yes. The app separates transfers within HDBank from 24/7 NAPAS fast transfers to other member banks and from card-to-card sends. We model each as its own flow because the status lifecycle and the reference fields differ, and we normalize them into one transaction schema so a consumer of the feed does not have to special-case the rail.

How do you handle the biometric and HDBank OTP step during login?

Fingerprint and face unlock are device-local gestures that release a stored credential; they are not a server secret we reproduce. We map the actual token and OTP exchange that the server validates, and the integration runs against a consenting account or sandbox that completes the HDBank OTP challenge, so the session is established the same way the app establishes it.

Is the airline-booking and VNPAY QR data in scope or just bank accounts?

Both can be in scope. The QR payment history and the flight bookings the app describes for around 30 domestic and international carriers sit behind the same authenticated session as the deposit and card accounts, so once the session and consent are established those surfaces are reachable. We scope to whatever data domains your project actually needs.

How we checked this, and against what

Mapped in June 2026 from HDBank's own store description and feature list, cross-read against the State Bank of Vietnam's Open API circular and Vietnam's personal-data decree. Primary sources:

• HDBank on Google Play (com.vnpay.hdbank)
• Brankas — Open banking and Circular 64 in Vietnam
• Tilleke & Gibbins — Open APIs in Vietnamese banking
• DLA Piper — Vietnam Decree 13/2023 on personal data

OpenBanking Studio · integration desk mapping, 27 June 2026.