Reaching MyVIB account and transaction data through consented Open API access

Vietnam's banks have until 1 March 2027 to fully comply with Circular 64/2024/TT-NHNN, the State Bank of Vietnam rule that, since 1 March 2025, defines how account data leaves a bank app through a consent-gated Open API. VIB is squarely inside that perimeter, and MyVIB — its retail digital-banking app, package com.vib.myvib2 per its Play Store listing — is where the per-user records sit: Super Account balances, transaction history, transfer orders, card state, savings, and the rewards ledger the app calls MyVIB Rewards. This brief maps what MyVIB holds, the authorized way to reach it, and what we hand over.

Vietnam's consent regime, and what it means for VIB

Circular 64 is recent and prescriptive. The State Bank of Vietnam issued it on 31 December 2024; it took effect 1 March 2025, banks were to submit their API catalogs and rollout plans by 1 July 2025, and full compliance is due 1 March 2027 (per the Brankas and LawNet write-ups cited below). The basic Open API list reads almost like an AIS spec: customer confirmation and consent, retrieve/refresh/revoke access token, retrieve account list, retrieve account information, retrieve transaction history, plus payment-initiation and e-wallet groups. Authentication is OAuth 2.0 (RFC 6749/6750), transport is TLS 1.2 or higher, payloads are JSON over REST with ISO 20022 / ISO 8583 compatibility.

What that means in practice: consent is user-controlled, time-bound and revocable, and every access is auditable. We treat that as the spine of the design rather than a constraint bolted on afterward — the consent record, its expiry, and the revoke path are first-class in everything we ship. Where VIB has not yet published a given endpoint, the same consent from the account holder authorizes us to read the data by analyzing the app's traffic, which is the practical bridge until 2027.

Data surfaces inside MyVIB

Mapped from the app's own feature set as VIB describes it. Granularity below is what an integrator can expect to reconcile against.

Routes to the data

Consented Open API under Circular 64

The cleanest path for accounts, balances and transaction history. The flow is the regime's own: customer confirmation and consent, an access token issued and refreshed over OAuth 2.0, then the account-list and transaction-history reads. Durability is high because it is a regulated standard with a 2027 compliance date behind it. The third-party onboarding with VIB is something we arrange with you as part of the build, not a form you fill out first.

Authorized protocol analysis of the app session

For surfaces the basic catalog does not yet expose — MyVIB Rewards entries, the international-transfer flow, biller payments for electricity, water and ADSL — we map the app's own requests under a consenting account holder. Effort is moderate; the trade-off is that the app's front end shifts over time, so we wire periodic re-validation into the handover. This route reaches more, sooner, while the regulated endpoints are still being published.

User-consented credential access

Where a single account holder wants their own data pulled, we orchestrate the login — including the MyVIB Smart OTP step — on their behalf and against their consent. Narrow in scope, useful for one-account or pilot work.

Our recommendation for MyVIB is concrete: build the consent flow and account/transaction reads on the Circular 64 endpoints as VIB publishes them, and run protocol analysis alongside it for rewards, FX and biller surfaces, with one normalized schema over both so the source of any field is an implementation detail to the consumer. As VIB completes its catalog ahead of 2027, fields migrate to the regulated endpoint without a downstream rewrite.

What lands in your repo

Each item is tied to a real MyVIB surface, not a generic checklist.

• An OpenAPI 3 specification covering the consent handshake, token issue/refresh/revoke, account list, account information and transaction history — modelled on the Circular 64 groups.
• A protocol and auth-flow report: the OAuth 2.0 token chain, how the Smart OTP device binding gates step-up, and the request shapes for the rewards and FX surfaces reached by analysis.
• Runnable source for the key endpoints in Python and Node.js — token lifecycle, paged transaction-history pull, and a transfer-status reader.
• Automated tests against recorded fixtures, including consent-expiry and token-refresh paths.
• Interface documentation and data-retention guidance written for Vietnam's personal-data and cybersecurity rules.

A worked call: paged transaction history

Illustrative, reflecting the Circular 64 account-information surface and confirmed against the live flow during the build. Field names follow the regime's ISO 20022-aligned shape.

# Pull transaction history for a consented MyVIB account
# Auth: OAuth 2.0 bearer (RFC 6750); consent_id scopes the grant
GET /openapi/v1/accounts/{accountId}/transactions?fromDate=2026-05-01&page=0
Host: openapi.vib.com.vn            # endpoint host confirmed during onboarding
Authorization: Bearer {access_token}
x-consent-id: {consent_id}          # time-bound, revocable per Circular 64

# 200 OK
{
  "accountId": "VIB-****-2417",
  "currency": "VND",
  "page": 0, "hasMore": true,
  "transactions": [
    {"txnId": "T...91", "bookingDate": "2026-05-03",
     "amount": -250000, "type": "DEBIT",
     "remittanceInfo": "EVN bill - electricity",
     "counterparty": {"name": "EVN HCMC", "scheme": "NAPAS"}}
  ]
}

# Handle the two failures that matter most here:
#   401 + "consent_revoked"  -> stop, surface re-consent to the account holder
#   401 + "token_expired"    -> refresh via the token endpoint, retry once
#   429                      -> respect Retry-After; back off the paging loop
      

Engineering notes we account for

Two things shape a MyVIB build specifically.

First, the Smart OTP step-up. MyVIB binds OTP generation to the enrolled device rather than sending SMS codes, so a sync cannot treat login as a single call. We model the device binding and token-refresh cadence so a consented integration re-authenticates without tripping the app's fraud controls, and we keep each access tied to its consent record.

Second, the Circular 64 transition window. The catalog VIB submits is being published in stages toward the 2027 deadline, so at any moment some fields come from the regulated endpoint and some from analysis. We track which surface each field currently rides and design the mapping so a field flips to the standardized endpoint when VIB ships it — the consumer schema does not move. Access to a sponsor environment or a consenting account is arranged with you during onboarding; it is part of the engagement, not something to settle before we begin.

Where teams put this to work

• An accounting platform syncing VIB transaction history into its ledger for Vietnamese SME clients, categorized from the remittance fields.
• A treasury dashboard reconciling Super Account balances and scheduled-transfer status across several VIB accounts.
• A personal-finance app aggregating a consenting user's MyVIB cards, savings and rewards into one view.

Interface evidence

Screens from the listing, useful for confirming which surfaces a build needs to cover. Tap to enlarge.

Sources checked

Mapping done on 24 June 2026 from VIB's own MyVIB pages, the app's Play Store listing, and primary write-ups of Circular 64. Citations:

• VIB — MyVIB mobile banking (feature set)
• MyVIB on Google Play (package, platform)
• Brankas — Open banking under Circular 64
• LawNet — Open API implementation from 1 March 2025

OpenBanking Studio · interface mapping, 2026-06-24.

Neighbouring apps in the same data space

Same category, named for keyword reach and because a unified Vietnam-banking integration usually touches several. Each holds comparable per-user records behind its own consent.

• VCB Digibank — Vietcombank's retail app; accounts, transfers, cards, term deposits.
• Techcombank Mobile — accounts, payments and rewards for Techcombank customers.
• VPBank NEO — VPBank's digital banking, with accounts, cards and loans.
• MB Bank — Military Commercial Bank's app; accounts, transfers, savings.
• Timo — a digital-first banking service with payment and deposit accounts and cards.
• Cake by VPBank — a mobile-only bank with accounts, cards and savings.
• TPBank Mobile — accounts, transfers and QR payments.
• ACB ONE — Asia Commercial Bank's app; accounts, statements and payments.
• Sacombank Pay — Sacombank's accounts, cards and bill payments.

Questions integrators ask

Does MyVIB's account data fall under Vietnam's Circular 64 Open API regime?

Yes. VIB is a licensed commercial bank, so the consent-based account-information surface of MyVIB sits inside Circular 64/2024/TT-NHNN, which the State Bank of Vietnam brought into effect on 1 March 2025. The basic catalog covers customer confirmation and consent, access-token issue/refresh/revoke, account list, account information and transaction history, with full bank compliance due by 1 March 2027. We build against that consent flow where VIB has published it and arrange the third-party onboarding with you.

Can you reach MyVIB surfaces that aren't in the basic Open API catalog yet, like MyVIB Rewards or in-app FX transfers?

Yes, through authorized protocol analysis of the app's own traffic under a consenting account holder. The Circular 64 basic catalog centers on accounts, balances and transaction history; rewards-ledger entries, the international-transfer flow across the currencies the app lists, and biller payments are mapped from the live session and normalized to a stable schema. We re-validate that mapping when the app front end changes.

How does MyVIB Smart OTP affect an automated integration?

MyVIB authenticates with a device-bound Smart OTP rather than SMS codes, so an automated sync has to handle device binding and token refresh instead of a one-shot login. We model that step-up so a consented integration re-authenticates cleanly and does not trip the app's fraud controls, and we log every access against the consent record.

Pricing is plain. A finished MyVIB integration — runnable source, the OpenAPI spec, tests and interface docs — starts at $300 under source-code delivery, and you pay after delivery once you are satisfied; if you would rather not host anything, call our endpoints and pay per call with no upfront fee. Either way the cycle is one to two weeks. Tell us the app and what you need from its data and we take it from there — start a brief on the contact page.