Reaching TPBank Mobile account data under Vietnam's Open API regime

As of December 2024, Vietnam has a named framework for exactly this kind of work: State Bank of Vietnam Circular 64/2024/TT-NHNN, which took effect 1 March 2025 and obliges commercial banks to share customer-consented data through standardized Open APIs, with full compliance due 1 March 2027 (per the SBV press release). TPBank is one of those licensed commercial banks. That changes how we approach pulling data out of TPBank Mobile — there is a supervised, consent-anchored path to balances and transaction history, not only the app's own session traffic.

The app itself, per its Google Play listing (package com.tpb.mb.gprsandroid), opens an account after a roughly five-second online eKYC check, lets customers use a nickname or shop name as the account number, and exposes in-network and interbank transfers, bill payments, savings, cards, and an AI-assisted spending-statistics view. Every one of those is server-side state a payments processor, accounting tool, or PFM product would want to read on a recurring schedule.

What sits behind the login

These are the surfaces an integrator can target, named the way the app presents them.

How we get to it

Three routes genuinely apply to TPBank Mobile. We set up access for each with you during onboarding.

Open API consent (Circular 64)

Reachable: customer-consented account and transaction data through TPBank's scheme-aligned endpoints as they come online under the SBV mandate. Effort is moderate once a sandbox and client registration are arranged; durability is high because it is supervised and standardized rather than tied to a private app build. We handle the registration and consent-screen wiring as part of the project.

Authorized protocol analysis of the app session

Reachable: anything the app itself can see for a consenting account — including surfaces the scheme has not yet published. We map the token and request flow against a test account you authorize, document each endpoint, and reproduce the calls in clean source. Effort is higher and the result needs a maintenance pass when the app front end shifts; the upside is full coverage now.

User-consented credential access

Reachable: the same account scope, driven by a customer who logs in and grants access for an agreed purpose. Useful as a bridge for a single-tenant deployment while scheme endpoints firm up. We keep this consent-scoped and logged.

For TPBank specifically, the consent route under Circular 64 is the one we would build the integration to settle on, because it is the only path that does not silently break when TPBank reskins its app — but we wire the protocol-analysis route alongside it so coverage is complete from day one rather than gated on every scheme endpoint going live.

What lands in your repo

• An OpenAPI/Swagger spec covering the TPBank surfaces you select — accounts, transfer log, payments, savings.
• A protocol and auth-flow report documenting the OAuth2 consent grant and the token-refresh chain as observed during the build.
• Runnable source for the key endpoints in Python and Node.js — balance read, transaction pull, pagination, refresh.
• Automated tests against recorded fixtures so a TPBank front-end change surfaces as a failing test, not a silent gap.
• Interface documentation an engineer who has never seen the app can follow.
• Consent-handling and data-retention guidance aligned to Decree 13/2023 and the new PDPL.

A statement pull, sketched

Illustrative shape of the consent-then-read flow; field names and exact paths are confirmed against live endpoints during the build, not asserted here.

# 1. Exchange the customer's consent grant for an access token
POST /openapi/oauth2/token
  grant_type=authorization_code
  code=<consent_code>
  client_id=<registered_tpp_id>
→ { "access_token": "...", "refresh_token": "...", "expires_in": 1800 }

# 2. List consented accounts
GET /openapi/v1/accounts
  Authorization: Bearer <access_token>
→ [ { "accountId": "AC...", "nickname": "shopname", "currency": "VND",
      "balance": { "amount": "...", "asOf": "2026-06-23T..." } } ]

# 3. Page the transfer log for one account
GET /openapi/v1/accounts/{accountId}/transactions?from=2026-05-01&page=1
  Authorization: Bearer <access_token>
→ { "items": [ { "txnId": "...", "amount": "-250000", "type": "transfer_out",
                 "counterparty": "...", "bookedAt": "...", "memo": "..." } ],
    "nextPage": 2 }

# Handle 401 → silent refresh with refresh_token; consent expiry → re-prompt
        

Consent and the rules around it

Two instruments govern this. Circular 64/2024/TT-NHNN puts customer consent at the centre of any data share and gives third parties a supervised channel — the SBV's stated aim is letting fintechs access bank and customer data with the data owner's agreement. On the privacy side, Decree 13/2023/ND-CP has required clear, specific, purpose-bound consent since July 2023, and Vietnam's Law on Personal Data Protection took effect 1 January 2026 with Decree 356/2025 as its guiding decree (per the Tilleke and Hogan Lovells write-ups we read). Bank account, deposit and transaction data are named categories under that regime, so consent scope, expiry and revocation are not optional decoration.

We build to that: every read is tied to a recorded consent with a defined purpose and window, access is logged, the data set is minimized to what the integration actually needs, and we work under an NDA where the engagement calls for one.

Things we account for on this build

Two TPBank-specific details shape the implementation:

• Nickname and shop-name accounts. TPBank lets a customer use a chosen nickname or shop name as the account identifier. We normalize that against the canonical account number in our schema so downstream reconciliation does not key off a string the customer can change.
• Consent-refresh windows under the scheme. Open API consents carry an expiry. We design the sync to track that window and re-prompt ahead of it, so a long-running feed does not lapse mid-cycle and drop transactions.
• Voice Pay and AI suggestions are UI, not new endpoints. The voice-transfer and content-suggestion features ride the same money-movement backend; we map the underlying calls so the integration is unaffected by which input method a customer used.

Access to a sandbox or a consenting test account is arranged with you during onboarding — the build runs against whichever is ready first.

Interface evidence

Store screenshots we reviewed while scoping the surfaces above. Tap to enlarge.

What we checked

Scoped in June 2026 from the app's Google Play listing and its own description, the SBV press release on Circular 64/2024/TT-NHNN, and Vietnamese data-protection commentary on Decree 13/2023 and the 2026 PDPL. Primary sources:

• SBV — press release on Circular 64/2024/TT-NHNN (Open API)
• Tilleke & Gibbins — Vietnam's Open API circular
• Tilleke & Gibbins — Decree 13/2023 on personal data
• TPBank Mobile on Google Play

OpenBanking Studio · integration desk, mapping reviewed 23 June 2026.

Where TPBank sits among Vietnamese banking apps

A unified integration usually spans several of these, since a business rarely banks with one institution. Listed for context, not ranking.

• VPBank NEO — VPBank's retail app; accounts, cards and transfers behind login.
• Cake by VPBank — digital-only bank; balances, virtual cards, transaction history.
• MB Bank — accounts, loans and bill payments with a transfer ledger.
• Vietcombank (VCB Digibank) — multi-currency accounts and cross-border transfers.
• Techcombank Mobile — accounts plus financial-planning data and spend tracking.
• ACB ONE — ACB's retail and SME accounts, transfers and statements.
• BIDV SmartBanking — accounts, deposits and payment records at one of the largest state banks.
• Sacombank Pay — wallet-style payments, cards and transaction data.
• Timo — digital bank account, spending buckets and transfer log.

Questions an integrator asks first

Which TPBank surfaces actually hold the data worth syncing?

The account ledger behind eKYC login: current balance, the in-network and interbank transfer log, bill and QR payments, savings and deposit records, card data, and the app's spending-statistics view that buckets transactions by category. The transfer log and balance are the two surfaces most projects want first.

Is TPBank covered by Vietnam's Open API rules, and what does that mean for a consent flow?

TPBank is a licensed commercial bank, so it falls under State Bank of Vietnam Circular 64/2024/TT-NHNN, which took effect 1 March 2025 with full compliance due by 1 March 2027 per the SBV press release. That route puts customer-consented data sharing on a standardized, supervised footing. Where a scheme endpoint is not yet live, we run authorized protocol analysis of the app's own session against a consenting account in the meantime.

How do you handle the Voice Pay and AI-suggestion features when mapping the API?

Those are client-side conveniences layered on the same backend money-movement and transaction endpoints. We map the underlying calls, not the voice UI, so the integration reads the same balances and transfer records the app shows after a voice command resolves.

How far back does the transfer history go, and how fresh is a synced feed?

TPBank does not publish a retention window, so we do not assert one; in practice we page the full transaction log the consented account can return and let you set the sync cadence. We pace that against the Open API consent expiry so a recurring feed stays fresh without the consent lapsing mid-cycle.