Getting BIDV SmartBanking account data into your own systems

BIDV runs SmartBanking as the retail front end for one of Vietnam's four large state-owned commercial banks, and behind a single phone-and-password login the app keeps a deep set of per-customer records: live balances, a running transaction ledger, internal and interbank transfers, online term deposits, an auto-invest sweep, monthly spend-and-income reports, and a stack of biller and lifestyle payments. That is exactly the kind of server-side state a bookkeeping tool, a lender, or a personal-finance aggregator wants to read on a customer's behalf.

The honest read on this app: the data is rich and well-structured, the authentication is layered but predictable, and Vietnam now has a written consent framework to anchor the work to. For a project starting today we map the app's own traffic under your authorization to stand up a working transaction feed inside a week or two, then move the same client onto the regulated consent grant as BIDV's Circular 64 endpoints come online. The rest of this page sets out the surfaces, the routes, and what arrives in your repo.

Account records inside SmartBanking

Each row below is a surface the app actually exposes to a logged-in customer, named the way SmartBanking presents it, with the granularity an integrator gets and a typical use.

Authorized ways into the data

Three routes genuinely apply to SmartBanking. We set up access for whichever ones you choose during onboarding — credentials, a consenting test account, and any authorization paperwork are arranged with you, not asked of you up front.

Authorized protocol analysis of the app traffic

We instrument the client under your authorization, map the login and token handshake, and reproduce the calls behind the balance, statement, savings and biller screens. Reachable: everything a logged-in customer sees. Effort is moderate; durability tracks the app's front end, which is why we keep a re-validation pass in maintenance. This is the route that gives a working feed first.

Consent-scoped reads under Circular 64

Vietnam's open-API rules establish a consent grant — OAuth 2.0 and OpenID Connect, revocable and time-bound — that Vietnamese banks are bringing online on the SBV timetable, with full compliance due March 2027. As those consent endpoints land, the same integration moves onto them. Reachable: account and transaction data in the early information-query phase, with payment initiation arriving in a later phase. This is the most durable long-run basis because it rests on the customer's own standing authorization.

Native in-app export

Where a one-off pull is all you need, the app's own statement export covers a date range without any standing connection. Low effort, narrow scope, no live sync.

For work starting now we recommend building against the app traffic under your authorization, because it produces a real transaction feed inside the 1–2 week cycle instead of waiting on the phase-in; we then carry that client onto the Circular 64 consent grant as BIDV exposes it, so what you pay for today keeps running when the regime is fully in force. Export stays in the kit for quick historical backfills.

Where it gets used

A few end-to-end shapes we have built around banking apps of this kind:

• A nightly reconciliation job pulls a small business's SmartBanking transaction ledger into accounting software, matching invoices to incoming transfers without anyone re-keying a statement.
• A personal-finance aggregator merges a customer's BIDV balances and spend reports with positions held at other Vietnamese banks, so one dashboard shows the whole picture.
• A lender reads ninety days of consented transaction history to run an affordability check, then drops the connection once the decision is made.

What we hand over

The handoff is built for SmartBanking's actual surfaces, not a generic banking template:

• An OpenAPI / Swagger specification covering the balance, statement, transfer, savings and biller endpoints we map.
• A protocol and auth-flow report documenting the phone-and-password sign-on, the Smart OTP and facial-biometric step-up, and the token and consent-id chain.
• Runnable source for the key reads in Python or Node.js — token acquisition, paginated statement retrieval, savings and bill-payment parsing.
• Automated tests against recorded responses, plus a re-validation script for when the front end shifts.
• Interface documentation and a short data-retention and consent-logging note aligned to Vietnamese rules.

A consent-scoped statement read, sketched

Illustrative shape of the request and response for a transaction pull; exact field names are confirmed against live responses during the build.

# 1) consent grant — OAuth 2.0 + OpenID Connect, Circular-64 style
POST /oauth2/token
  grant_type = authorization_code
  code       = <consent code from the customer's approval screen>
  scope      = accounts:read transactions:read
  -> { access_token, refresh_token, expires_in: 1800, consent_id }

# 2) statement read for one account and date range
GET /accounts/{accountId}/transactions?from=2026-01-01&to=2026-03-31
  Authorization: Bearer <access_token>
  X-Consent-Id: <consent_id>
  -> 200
     { "accountId": "...", "currency": "VND",
       "balance": { "available": 0, "current": 0 },
       "transactions": [
         { "txnId": "...", "postedAt": "...", "amount": 0,
           "direction": "CREDIT|DEBIT", "counterparty": "...",
           "narrative": "..." } ],
       "nextPage": null }

# 3) step-up only where the SBV rule requires it
#    (transfers over the threshold, first use on a new device — since Jul 2024)
  -> 401 { "error": "step_up_required", "method": "FACE_BIOMETRIC" }

# 4) consent gone or window closed -> explicit auth error, never stale data
  -> 403 { "error": "consent_revoked" }
      

Consent and the SBV rulebook

Vietnam moved from soft guidance to a written framework with Circular 64/2024/TT-NHNN, issued by the State Bank of Vietnam and in effect since 1 March 2025. It puts customer consent at the centre: grants are revocable and time-bound, and the bank caps third-party access at up to 180 days after consent unless the customer agrees otherwise. Data handling also answers to the Law on Protection of Personal Data and the Law on Cybersecurity, and a companion rule, Circular 50/2024/TT-NHNN, covers online-banking security and transaction verification.

We operate consent-first regardless of route. Access is authorized and logged, consent records are retained, pulls are tied to a live authorization, and we work under an NDA where the engagement calls for one. Data is minimized to the fields you actually need — a budgeting feed does not collect card numbers, an affordability check keeps only the window it was granted.

Engineering realities we plan around

Two specifics on this app that shape how we build:

The biometric step-up sits on transactions, not reads. Since July 2024, BIDV applies facial-biometric verification to transfers above the SBV-set limit and to the first transaction after install on a new device. We design the client so that step-up is invoked only where the rule requires it, while balance and statement reads run off the consent token — that keeps an account-data sync from tripping a verification it never needed.

The consent window expires by design. Because Circular 64 caps the access period and the grant is revocable, we build the sync around the refresh and renewal cycle so it does not silently go dark, and we treat revocation as a distinct, surfaced state. We also keep a re-validation pass in maintenance for when the SmartBanking front end changes, since the version-X release shipped a full interface redesign and BIDV iterates on it.

How an engagement runs and what it costs

Source-code delivery starts at $300: you get the runnable integration, the OpenAPI spec, the auth-flow report, tests and interface docs, and you pay after delivery once the build does what you needed. If you would rather not host anything, the pay-per-call hosted API has no upfront fee — you call our endpoints and pay only for the calls you make. Either way the cycle is one to two weeks. You bring the app name and what you want out of its data; access and compliance steps are arranged with you. Start the conversation at /contact.html.

Screens we worked from

Published SmartBanking screenshots used while mapping the surfaces above. Tap to enlarge.

What we checked, and when

This brief was put together in June 2026 from the app's own store listing and BIDV's customer guidance for the data surfaces and authentication, and from the State Bank of Vietnam's own materials plus legal commentary for the Circular 64 framework and its timeline. Primary sources:

• State Bank of Vietnam — press release on Circular 64/2024/TT-NHNN
• Circular 64/2024/TT-NHNN — English text and timeline
• BIDV — biometric setup and authentication on SmartBanking
• BIDV SmartBanking — Google Play listing

Mapped and reviewed by the OpenBanking Studio integration desk, June 2026.

Other Vietnamese banking apps in the same picture

A customer rarely banks in one place, so the same integration work usually spans several of these. Named here for context, not ranked:

• VCB Digibank — Vietcombank's retail app for transfers, card management and savings.
• VietinBank iPay — personal banking, transfers, bill pay and deposits for VietinBank customers.
• MB Bank App — MBBank's app, blending personal and SME banking; among the most-downloaded in Vietnam.
• Techcombank Mobile — retail accounts, savings, investments and QR payments.
• Agribank E-Mobile Banking — accounts and transfers across Agribank's wide rural network.
• VPBank NEO — VPBank's mobile banking with accounts, cards and quick loans.
• ACB ONE — ACB's retail app for transfers, deposits and card control.
• Sacombank Pay — Sacombank's payment and account app with QR and transfers.
• MoMo — Vietnam's leading e-wallet super app, holding wallet balances, linked-bank transfers and bill payments.

Questions integrators ask about SmartBanking

Does the facial-biometric check BIDV rolled out in 2024 stop an automated read?

No, because it sits in a different place. BIDV applies facial biometric verification to transfers above the SBV threshold and to the first transaction after the app is installed on a new device, per BIDV's own guidance. A read against balances or transaction history runs off a standing consent token and does not trip that step. We build the client so the biometric step-up is only invoked where the rule actually requires it, and the data-read paths stay on the token.

What does Circular 64 change about reaching SmartBanking data?

Circular 64/2024/TT-NHNN, effective March 2025, sets a consent-based open-API framework for Vietnamese banks, with full compliance due by March 2027. It calls for OAuth 2.0 and OpenID Connect grants, time-bound and revocable consent, and a third-party access window the bank caps at up to 180 days. For an integrator that means the durable route is consent-scoped reads, so we design the sync to renew inside that window rather than let access lapse without notice.

Can the personal-finance and bill-payment surfaces be pulled apart, or do they arrive together?

They are separate surfaces in the app. The spending-and-income reports, the savings and auto-invest ledger, and the biller transactions each originate on their own screens and carry their own fields. We map each one to its own object so your system receives a labelled transaction stream, a savings position, and a bill-payment record rather than one undifferentiated blob.

What happens to the feed when a customer revokes consent or the token expires?

Revocation and expiry are handled as first-class events in the build. When a consent is withdrawn or its window closes, the read endpoints return an authorization error rather than stale data, and we surface that to your system as a distinct state so it can prompt the customer to re-consent. Consent records and access logs are kept so each pull ties back to a live authorization.