Connecting to VCB Digibank under Vietnam's Open API rules

Where VCB Digibank's data sits today

Vietcombank's retail app runs inside a banking sector that, since 1 March 2025, operates under a written Open API rulebook — Circular 64/2024/TT-NHNN from the State Bank of Vietnam. That circular names Account Information Services and Payment Initiation as standard API categories and gives an account holder a consent-based path to their own data. For an integrator, this is the cleanest thing that can happen: a regulator has spelled out the route, the auth method, and a deadline.

The app itself, per its store listing, holds the day-to-day money records of tens of millions of personal customers — balances, statement history, transfers, savings deposits, loan disbursement, and a long tail of bill and top-up flows. Our job is to reach a defined slice of that, with the customer's authorization, and hand back code that pulls it on a schedule. Where a particular bank endpoint is not yet live under the phased rollout, we read the same surface from the app's own traffic instead. Either way the deliverable is the same: a working integration, not a feasibility memo.

What the app actually holds

These rows map the surfaces a VCB Digibank integration would touch, drawn from the app's own description and Vietcombank's published feature notes.

How we reach it

Two routes fit this app, and they overlap rather than compete.

Consented Open API access (Circular 64)

The regulated path. With the account holder's consent, the bank's Open API surface exposes account information and payment initiation under OAuth 2.0 and OpenID Connect. Reachable: balances, statement history, payment status. Durability is high — it is the path the regulator is steering the whole sector onto by 1 March 2027. Effort sits mostly in onboarding and the consent handshake, which we set up with you. Coverage today depends on which phase Vietcombank has shipped for the service you want.

Authorized protocol analysis of the app

Where a bank endpoint is not yet live, or where you need a surface the Open API does not expose, we analyse the app's own traffic under your authorization and implement against it. Reachable: effectively what a logged-in user sees. Durability is lower — the app front end changes, and we account for that in maintenance. This route fills the gaps the phased rollout leaves and is often the faster way to a first working pull.

For most VCB Digibank work the consented Open API route is the one we build the core read path on, because it is where the regulator is taking the bank and it survives front-end changes; the protocol route runs alongside it to cover services the bank has not yet published. We tell you which surfaces each one reaches before any code is written.

What lands in your repository

Concrete artifacts, tied to the surfaces above:

• An OpenAPI / Swagger specification for the endpoints we integrate — account read, statement query, transfer status.
• A protocol and auth-flow report: the OAuth 2.0 / OIDC consent handshake for the regulated route, or the observed token and session chain where we work from app traffic.
• Runnable source for the key calls in Python or Node.js — balance fetch, paged statement pull, transaction normalization.
• Automated tests against recorded responses, including the cross-border QR case where FX fields appear.
• Interface documentation and data-retention guidance written for Vietnam's personal-data and cybersecurity laws.

The consent-to-balance call, sketched

Illustrative, not copied from a live endpoint — field names and the exact flow are confirmed during the build against the consenting account. It shows the shape of the Circular 64 read path: an OIDC-authorized token, a consent id, a JWS-signed request, then a normalized balance.

POST /aisp/v1/accounts/{accountId}/balances
Host: openapi.vietcombank.example
Authorization: Bearer <oidc_access_token>
x-consent-id: cns_8f12c4...           # from the consent handshake
x-jws-signature: <detached_jws>       # body signed per Circular 64
Accept: application/json

# 200 OK
{
  "accountId": "VCB-****-2317",
  "currency": "VND",
  "balances": [
    { "type": "available", "amount": "4825100.00" },
    { "type": "current",   "amount": "4825100.00" }
  ],
  "asOf": "2026-06-24T03:11:09Z"
}

# our client normalizes, then handles the consent-expiry case
def fetch_balance(account_id, token, consent_id):
    r = session.get(url(account_id), headers=auth(token, consent_id))
    if r.status_code == 403 and r.json().get("code") == "CONSENT_EXPIRED":
        token, consent_id = refresh_consent()   # re-run handshake, log it
        r = session.get(url(account_id), headers=auth(token, consent_id))
    r.raise_for_status()
    return to_ledger_row(r.json())

Consent, the regulator, and data handling

The named authority is the State Bank of Vietnam; the instrument is Circular 64/2024/TT-NHNN, in force since 1 March 2025. Under it the bank is the data controller and stays responsible for security; a third party may only process data within the scope the customer granted; and the customer keeps the right to grant, monitor and withdraw consent, with a sharing history. Our integration treats that consent record as the spine — scopes are minimal, every access is logged, and the sync is built to stop cleanly when consent is revoked rather than failing silently.

Beyond the circular, two laws bear on the data: Vietnam's personal-data protection rules and its cybersecurity law, which govern how financial and personal information is stored and moved. We work authorized and documented, keep only the fields the use case needs, and sign an NDA where the engagement calls for one. None of this is a hoop we ask you to jump through up front — access and consent are arranged with you as the project starts.

Things we plan around on this app

Concrete points that shape the build for VCB Digibank specifically:

• Phased endpoints. The circular brings query, consent and payment APIs in over a staged timeline toward 1 March 2027. We design the read path to use whichever phase is live for your service and to switch onto a richer bank endpoint as it ships, so the integration does not break on a single cut-over.
• Two QR rails. Domestic VietQR transfers and the outbound Alipay+ QR settle differently. We map them as distinct transaction types, carrying the FX fields on the cross-border one, so a unified ledger never mislabels a foreign payment as a local transfer.
• Vietnamese field encoding. Labels, diacritics and the VND amount formatting come through in Vietnamese; we normalize encoding and money types on ingest so downstream systems get clean UTF-8 and decimal values.
• Consent-refresh window. The bank's consent platform expires and revokes access on its own schedule. We build the sync around that window and wire a re-check into maintenance so a quiet expiry does not look like missing data.

How fresh the data stays

Balances and transaction status read live on each call through the consented route, so a treasury view reflects the account within seconds of a request. Statement backfill is paged and idempotent — a re-run fills gaps without duplicating rows. For the protocol route, freshness tracks the app's own update cadence, and we note any caching the front end imposes so you are not reading stale figures without knowing it.

Interface evidence

Store screenshots of the surfaces an integration reads. Select one to enlarge.

What was checked, and against what

On 24 June 2026 we read the app's store listing and feature notes, then the State Bank of Vietnam's Open API circular as covered by legal and industry write-ups, plus Vietcombank's own announcement of cross-border QR. The data domains here come from the app's published description; the regulatory route from Circular 64 and its technical standard. Sources:

• VCB Digibank on Google Play
• How open banking is evolving in Vietnam with Circular 64 (Brankas)
• Vietnam's open API circular (Tilleke & Gibbins)
• Vietcombank cross-border QR payments announcement

Mapped by the OpenBanking Studio integration desk — reviewed 2026-06-24.

Nearby apps in the same data picture

Apps an integrator often ends up unifying alongside VCB Digibank, each holding its own slice of a Vietnamese user's money data:

• MB Bank — retail and SME banking in one app; balances, transfers, QR, popular with younger users.
• Techcombank Mobile — full retail banking with savings, investment and QR payment records.
• VietinBank iPay — account, card and bill-payment data for another large state-linked bank.
• BIDV SmartBanking — transfers, statements and utility payments across a wide branch base.
• Agribank E-Mobile Banking — strong rural reach; account and transfer records.
• MoMo — wallet leader with transfers, bill pay, insurance and investment ledgers.
• ZaloPay — wallet tied to the Zalo messenger; social transfers and bill splitting.
• VNPay — the VietQR infrastructure behind merchant QR acceptance.
• ViettelPay — telecom-backed wallet with national, rural-leaning reach.

Listed as a map of the landscape, not a ranking — the shared problem is one consented, normalized view across several banks and wallets.

Questions integrators ask about this app

Does VCB Digibank's data sit under Vietnam's Open API circular?

Yes. Vietcombank is a licensed bank, so its retail data falls inside Circular 64/2024/TT-NHNN, which the State Bank of Vietnam brought into force on 1 March 2025 and which covers Account Information Services and Payment Initiation. That gives an account holder a consent-based path to balances, statement history and transfers. Where a bank endpoint for a given service is not yet live under the phased rollout, we reach the same surface through authorized protocol analysis of the app's own traffic.

Can the cross-border QR payments be reached the same way as domestic transfers?

They behave differently. Vietcombank's outbound QR, announced in 2026 and built on the Alipay+ network for use across 50-plus markets, runs through a different settlement path than a domestic VietQR transfer. We map the two flows separately so a unified ledger labels each transaction with its rail rather than flattening them into one type.

Which authentication does a VCB Digibank integration use?

Under Circular 64 the bank's Open API surface uses OAuth 2.0 with OpenID Connect, TLS 1.2 or higher, and JWS signing on the message body, per the published technical standard. The consented-access route inherits that. Where we instead work from the app's traffic, the auth report documents the token and session chain we observe during the build rather than any published standard.

How do you handle the March 2027 compliance deadline for the bank's APIs?

The circular phases query, consent and payment endpoints in over a staged timeline, with full compliance required by 1 March 2027. We design the integration to use whichever phase is live for the service you need and to switch onto a richer bank endpoint as it lands, so the build keeps working across the rollout instead of breaking on a single cut-over.