Wiring BIDV SmartBanking into your stack under Circular 64

Since 1 March 2025, any third party that wants a BIDV customer's account data in Vietnam works under a named rule: Circular 64/2024/TT-NHNN, the State Bank of Vietnam's Open API framework, which puts the customer's consent at the centre and caps each grant of access at 180 days. That shifts the integration question for BIDV SmartBanking. It is no longer whether the records are reachable but how you reach them cleanly. The data sitting behind a SmartBanking login — balances, statement lines, transfers, online savings, the daily auto-invest, cards — is exactly the customer-information set that regime names.

Account access under Vietnam's Circular 64

Vietnam moved from a patchwork to a named regime fast. The State Bank of Vietnam issued Circular 64/2024/TT-NHNN on 31 December 2024, it took effect 1 March 2025, and it gives the country its first common standard for how banks and third parties share financial data through Open APIs — with the data owner's consent built into the flow. The Open API catalog in the circular is organised into groups, and one of them is querying customer information: account list, account information, and transaction history. That is the heart of what a SmartBanking integration reads.

Two specifics matter for how a feed is built. First, access after consent is time-boxed: the circular sets a window not exceeding 180 days per consent unless the customer and bank agree otherwise, and the customer must be able to look up and withdraw what they have consented to. Second, the rollout is staged — banks were expected to file their API lists and plans with the SBV during 2025, with full compliance required by 1 March 2027. So the consent catalog is real and dated, but not uniformly live across every bank yet. The dependable basis a build rests on today is the account holder's own authorization; the circular is where that consent becomes a standard channel.

Data behind a SmartBanking login

These are the surfaces the app actually exposes to a logged-in individual customer, mapped to what an integrator would do with each.

Authorized routes into the account

Three routes genuinely apply to BIDV SmartBanking. They are not mutually exclusive; most builds combine them.

1 · Circular 64 consent catalog

The regulated channel. As BIDV publishes its customer-information APIs under the circular, a consenting customer can authorize a third party to read account list, account details and transaction history through a standard consent flow with a defined 180-day window. Reachable scope is exactly what the catalog names. Effort is low once the endpoints are live; durability is high because it is the regime's intended long-run path. We set up and operate the consent flow with you as part of the build.

2 · Authorized interface integration

Under the customer's authorization, we map the app's own traffic — the phone-number-and-password session, the balance and statement calls, the Smart OTP and biometric step-up — and implement a documented client against it. Reachable scope is everything the logged-in app sees. Effort is moderate; durability needs a recheck when the app front end changes, which we account for. This route works now, independent of how far any bank has gone with the catalog.

3 · User-consented retrieval

For a single consenting account holder, we drive the documented flows to pull statements and balances on a schedule. It is the lightest option and suits low-volume or proof-of-concept work. Access is arranged with the consenting customer during onboarding.

For a build that has to work this quarter, I would start on the authorized interface route. Circular 64's customer-information APIs are real and dated, but still arriving bank by bank toward the March 2027 deadline, so modelling the app's authenticated flows now gets a working balance-and-statement feed without waiting on the catalog — and the same data model accepts the consent endpoints the moment they go live for BIDV. The consenting-account retrieval underneath is what I reach for when a client only needs one or two accounts to prove value first.

What the build hands over

Every engagement produces artifacts tied to BIDV SmartBanking's actual surfaces, not a generic template:

• An OpenAPI/Swagger specification covering the modelled endpoints — sessions, accounts, statement lines, transfers, savings and card list.
• A protocol and auth-flow report: the single-login session (one registered phone number and password across web, mobile, smartwatch and the smart keyboard), device binding, and where Smart OTP or biometrics step in.
• Runnable source in Python or Node.js for the core reads — balance lookup, statement pull with pagination, savings and auto-invest positions.
• Automated tests, including a consent-window refresh test so the 180-day expiry is exercised, not assumed.
• Interface documentation a second engineer can follow, plus compliance and data-retention guidance — consent records, the 180-day cap, and data minimization.

A statement pull, in outline

Illustrative shape only. The exact endpoints, headers and the Smart OTP step-up order are pinned against the live app during the build, never guessed in a brief.

# Read paths (balances, statement lines) ride the authenticated
# session token. Money-moving paths additionally clear Smart OTP
# or a biometric check — out of scope for a read-only data sync.

def fetch_statement(session, account_id, start, end):
    page = client.get(f"/accounts/{account_id}/txns",
                      params={"from": start, "to": end},
                      headers=session.auth())   # phone + password session
    for tx in page["items"]:
        yield {
            "posted_at":   tx["posted_at"],
            "amount":      Decimal(tx["amount"]),
            "direction":   "debit" if tx["dc"] == "D" else "credit",
            "balance":     Decimal(tx["running_bal"]),
            "counterpart": tx.get("counterparty"),
            "memo":        tx.get("narrative"),
            "channel":     tx.get("channel"),
        }
    # Circular 64: renew the consent grant before the 180-day
    # window lapses, or this session stops being authorized.
      

Engineering specifics we plan around

Three things about this app shape the build, and we handle each on our side:

• One identity, many surfaces. A SmartBanking account is a single phone number and one password used across web, phone, smartwatch and the smart keyboard. We register the integration as a recognised bound device so the session model the app expects holds, rather than tripping its multi-device checks.
• Split authentication tiers. Reads and money movement sit behind different authentication. We scope the read-only data sync to the session tier and leave Smart OTP and biometric step-up on the actions that genuinely need it, so a statement query never blocks on an OTP prompt.
• Version X churn and the consent clock. SmartBanking shipped a full interface rebuild with its version X release, so we treat the captured flows as something to recheck on each app update and budget that into maintenance. We pair it with a refresh that renews access ahead of the 180-day window instead of letting the feed go dark mid-month.

Access, credentials and a sandbox or consenting account are arranged with you during onboarding — that work is part of the project, handled with the client, not a checklist to clear first.

Where this data gets used

• A Vietnamese accounting SaaS pulls a consenting SME owner's BIDV statement lines nightly straight into its ledger, with counterparty and narrative preserved.
• A personal-finance app shows a user's BIDV balances and daily auto-invest positions next to their accounts at other banks, in one normalized view.
• A treasury tool checks scheduled-transfer status after a payment batch, instead of waiting for a manual screen check.
• A lender ingests consented statement history to support an affordability decision, under a time-boxed consent grant.

Keeping the feed current

Read paths are query-time fresh, so balances reflect the moment of the call. We set sync cadence to the data — balances on demand, statements on a daily or hourly pull — and renew consent before it lapses. When a SmartBanking release moves the front end, the maintenance pass revalidates the captured flows before anything breaks downstream.

Price and how a build runs

A finished BIDV SmartBanking integration leaves here as one of two things, and you choose on price. Source-code delivery starts at $300: you receive the runnable API source, the auth-flow report and the interface docs, and you pay only after delivery, once the build does what you asked. The hosted option turns that around — we run the endpoints, you call them and pay per call, with nothing upfront. A first delivery typically runs one to two weeks. Tell us the app and what you need from its data on the contact page and we will scope it back to you.

Screens we mapped against

Public store screenshots used while sketching the flows above.

What was checked

For this mapping I read BIDV SmartBanking's own store listing and feature copy, then the State Bank of Vietnam's press release and the published text of Circular 64/2024/TT-NHNN for the consent rules and the Open API catalog, and BIDV's own page on biometric authentication and Smart OTP for the login model. The dated facts here come from those sources, checked on 24 June 2026.

• State Bank of Vietnam — press release on Circular 64/2024/TT-NHNN
• Circular 64/2024/TT-NHNN — full text (LuatVietnam)
• BIDV SmartBanking — Google Play listing
• BIDV — biometric setting and authentication on SmartBanking

Mapping by the OpenBanking Studio integration desk, checked 24 June 2026.

Other Vietnamese banking and wallet apps in the picture

Teams aggregating BIDV usually need its peers in the same normalized feed. Named here for context, not ranked:

• Vietcombank Digibank — Vietcombank's retail app; balances, statements and transfers for one of the other big-four banks.
• VietinBank iPay — VietinBank's mobile banking; similar account and payment data set.
• Agribank Plus — Agribank's app, with wide rural reach and the same core account records.
• Techcombank Mobile — Techcombank's retail banking, strong on zero-fee transfers and spend data.
• MBBank — Military Commercial Bank's app, accounts plus an embedded marketplace.
• VPBank NEO — VPBank's digital banking, accounts, cards and lending data.
• TPBank — TPBank's mobile app, accounts and savings products.
• Sacombank Pay — Sacombank's payment-led app over its account base.
• MoMo — the leading Vietnamese e-wallet; balances, transfers and a large biller network.
• ZaloPay — wallet tied to the Zalo messaging platform, with payment and transfer history.

Questions integrators ask about BIDV SmartBanking

Now that Circular 64 is in force, is BIDV account data reachable through a single standard consent flow?

The framework exists. Circular 64/2024/TT-NHNN took effect on 1 March 2025 and its Open API catalog explicitly covers customer information — account list, account details and transaction history — released with the customer's consent. Banks were due to submit their API plans to the State Bank of Vietnam by mid-2025 and have until 1 March 2027 to comply fully, so the consent catalog is still rolling out in practice. We build against the app's own authorized flows now and move the integration onto the consent catalog as it lands.

Which BIDV SmartBanking records can a normalized feed expose?

Balances and the available-versus-current split per account, statement lines with counterparty and narrative, the status of 24/7 and scheduled transfers, online savings and the daily auto-invest positions, and the card list including cards issued inside the app. We model those into one schema so your side reads consistent fields rather than the app's raw shapes.

How does the 180-day consent window shape a running integration?

Circular 64 caps third-party access to customer data at 180 days per consent unless the customer agrees otherwise, and the customer can withdraw consent at any time. We design the sync to renew before that window lapses and to handle a withdrawal cleanly, so the feed neither expires silently nor keeps pulling after consent ends.

Do Smart OTP and biometric login get in the way of an automated session?

Not for the data work. Read paths — balances and statements — ride the authenticated session, while Smart OTP and biometric checks sit on the money-moving and high-risk actions. We scope a read-only sync to the session tier and keep step-up only where SmartBanking actually requires it, so a statement pull does not stall on an OTP prompt.