Connecting to ABBank under Vietnam's new Open API regime

Since 1 March 2025 every commercial bank in Vietnam has worked under SBV Circular 64/2024/TT-NHNN, the State Bank of Vietnam's first rulebook to put customer-consented account APIs on a legal footing. ABBank, the retail app of An Binh Commercial Joint Stock Bank, sits inside that regime. That changes the integration question. It is no longer whether the account data can be reached in an authorized way — the regulator now defines exactly how, with consent at the centre — it is which surface to read for the data set you need, and how to keep that read working through FIDO logins and an app front end that ships frequent updates.

This page maps what ABBank holds for a logged-in customer, the authorized routes into it, and the source code and documents we hand over. We work from one consenting account or a sponsor sandbox; access and the consent paperwork are arranged with you as part of the job.

What a logged-in ABBank session exposes

The app describes smart financial management with personalized suggestions, real-time balance alerts, transfers, bill payment, phone top-up and an online service to buy US-dollar banknotes for travel. Each of those is a distinct server-side record set. The table maps them to where they surface in the app and what an integrator does with them.

Most demand lands on the first two rows. A balance and a clean, deduplicated transaction feed are what aggregation, accounting and personal-finance products are built on. The transfer and FX rows matter when the integration has to move money or read an order, not only watch it.

Three authorized ways in

Consented AIS under Circular 64

Circular 64 specifies OAuth 2.0 (RFC 6749) for authorization, TLS 1.2 or higher in transit, and JSON over REST with ISO 20022 / ISO 8583 compatibility, all gated by user-controlled, revocable, time-bound consent. Where ABBank has published the account-information endpoints for the fields you want, this is the durable read: it is the route the regulator intends and it survives app updates because it is a contract, not a screen. Banks are rolling these endpoints out on the Circular's phased schedule, so coverage for a specific data set has to be confirmed at build time rather than assumed.

Authorized interface integration

When the consented endpoint for a given surface is not yet live, we analyse the app's own authenticated traffic against a consenting account and implement the same request and response handling in your stack. This reaches anything the app itself can show a logged-in user. It needs more upkeep, because the Backbase-driven front end revises field names and endpoints between releases, and we account for that in the maintenance pass.

User-consented credential access

For a one-account or low-volume need, an integration that runs under the user's own credentials and consent, returning normalized JSON, is the lightest thing to stand up. It carries the FIDO device-binding constraint, so it suits attended or per-user flows rather than a large fan-out.

For most buyers we would build the Circular 64 AIS read as the working integration wherever ABBank exposes the field set, and back it with authorized interface integration for the surfaces that are not yet published — one contract that quietly upgrades from screen-level reads to the regulated endpoints as coverage lands.

What lands in your repo

• An OpenAPI / Swagger specification for the ABBank surfaces in scope — accounts, transactions, transfers, FX orders — with request and response schemas.
• A protocol and auth-flow report covering the OAuth 2.0 token exchange, the FIDO step-up, refresh handling and the consent grant under Circular 64.
• Runnable source for the key endpoints in Python or Node.js: token acquisition, account listing, paginated transaction pull, transfer status polling.
• Automated tests against recorded fixtures so a front-end change surfaces as a failing test, not a silent data gap.
• Interface documentation plus consent-handling and data-retention guidance written to Vietnam's PDP Law and Decree 356.

Each piece is tied to ABBank's real surfaces. The transaction pull, for instance, ships with the deduplication and cursor logic the statement feed actually needs, not a placeholder loop.

Auth and query flow, sketched

Illustrative shape of a consented account-information read. Field names and the exact token endpoint are confirmed against a live consenting session during the build.

# ABBank consented account-information pull (illustrative)

POST /oauth2/token                 # OAuth 2.0 (RFC 6749), per Circular 64
  grant_type = authorization_code
  code       = <consent_code>       # issued after the FIDO step-up
  -> { access_token, refresh_token, expires_in }

GET /ais/v1/accounts               # TLS 1.2+, Authorization: Bearer <token>
  -> [ { accountId, productType, currency, balance, status } ]

GET /ais/v1/accounts/{accountId}/transactions?from=2026-01-01
  -> { items: [ { txnId, postedAt, amount, currency,
                  counterparty, channel, narrative } ],
       nextCursor }

# error handling
#   401              -> refresh_token, retry once
#   403 consent_*    -> consent expired or revoked, re-prompt user
#   429              -> exponential backoff
#   nextCursor set   -> follow until null, dedupe on txnId
        

NAPAS 247 transfers do not confirm in the initiating call. The status read is a separate poll or webhook, and the source treats a pending result as expected rather than as an error.

Things we handle so they do not bite later

Three specifics on ABBank shape the build, and we design for each rather than discover it in production.

• FIDO device binding. The app onboards with face and fingerprint and a FIDO attestation, so a session is tied to a device. We model the attestation and step-up, then the refresh chain after it, so the integration re-authenticates on its own instead of stalling the first time a token ages out.
• Asynchronous settlement. Transfers go over NAPAS 247 and settle out of band. We build status polling or webhook handling into the transfer path so a pending state is read correctly, not mistaken for a failure or double-sent.
• Backbase front-end churn. ABBank runs on the Backbase engagement banking platform, which ships frequent UI and endpoint revisions. Our maintenance pass re-checks the field mapping against a live consenting session before any change reaches your code, and the test fixtures flag a drift the moment it appears.

Access is arranged with you during onboarding — the build runs against a consenting account or a sponsor sandbox, under NDA where you need one. Reads are logged and limited to the fields the integration genuinely uses.

Where this gets used

• A personal-finance app pulling a customer's ABBank balance and categorized transactions into a single multi-bank view.
• An SME accounting tool importing ABBank statements each night for automatic reconciliation.
• A payout platform initiating NAPAS 247 transfers from an ABBank account under PIS, with settlement status tracked to completion.
• A travel product reading a customer's online USD purchase orders and rates alongside their spending.

Cost and timing

A working ABBank account-and-transaction integration is typically ready in one to two weeks. Source-code delivery starts at $300: you receive the runnable source, the OpenAPI spec, the auth-flow report, tests and documentation, and you pay only after delivery, once it runs against your account. If you would rather not host anything, the pay-per-call option lets you call our endpoints and pay only for the calls you make, with no upfront fee. Tell us the data you want from ABBank and which model suits you on the contact page and we will scope it.

App screens we worked from

How this was checked, and against what

Reviewed in June 2026. We read ABBank's store listing for the live feature set, the text of SBV Circular 64 coverage for the Open API standard and its phased dates, ABBANK's own announcement of its Backbase platform, and current guidance on Vietnam's Personal Data Protection Law for the consent and retention rules. Primary sources:

• ABBANK on Google Play (vn.abbank.retail)
• SBV Circular 64/2024/TT-NHNN — Vietnam Open API standard
• ABBANK on its Backbase engagement banking platform
• Vietnam's Law on Personal Data Protection (in force 1 Jan 2026)

Mapped by the OpenBanking Studio integration desk, June 2026.

Other Vietnamese banking apps in the same picture

A unified integration usually spans several of these, since a Vietnamese user rarely keeps everything in one bank. Each holds the same broad record types behind its own login.

• Vietcombank (VCB Digibank) — big-four retail app with accounts, transfers and card data behind a logged-in session.
• Techcombank Mobile — accounts, transactions and payments, with a heavy push on digital onboarding.
• App MBBank (MB Bank) — retail accounts, transfers and a wide services menu.
• VPBank NEO — VPBank's retail app holding balances, statements and payment flows.
• TPBank — retail banking with early adoption of virtual-branch and live-banking features.
• Cake by VPBank — digital-only bank with account and card data and rapid user growth.
• Timo — digital banking platform with accounts, goals and transaction history.
• MoMo — wallet and payment super-app holding balances, transfers and merchant transactions.
• Sacombank Pay — accounts, cards and payment records inside Sacombank's app.

Questions an ABBank integrator tends to raise

Now that Circular 64 is live, can ABBank data be reached through a consent flow?

The SBV Open API regime has been in force since 1 March 2025, and banks are phasing AIS endpoints in on the schedule the Circular sets. Where ABBank's consented account API is exposed for a given data set, we build straight onto it. Where it is not yet live for what you need, we use authorized interface integration against a consenting account, and the customer's own consent is the dependable legal basis either way.

How does ABBank's FIDO login change an automated integration?

ABBank uses FIDO with face and fingerprint onboarding, so sessions are device-bound rather than password-only. We model the attestation and step-up step and the token-refresh chain that follows it, so a sync re-authenticates cleanly instead of breaking the first time the session ages out.

Can you initiate NAPAS transfers from ABBank, or only read balances?

Circular 64 covers Payment Initiation Services alongside Account Information Services, so transfer initiation is in scope where the consented endpoints are available. NAPAS 247 settlement is asynchronous, so we design around status polling or webhooks rather than assuming a transfer confirms in the same call.

Which Vietnamese regulator and data law govern this work?

The State Bank of Vietnam sets the Open API rules through Circular 64/2024/TT-NHNN. Personal data is governed by the Law on Personal Data Protection (91/2025/QH15) and its guiding Decree 356/2025/ND-CP, both in force since 1 January 2026, which replaced Decree 13/2023. We keep consent records and minimize the fields a build actually reads.