Reaching ACB ONE account and card data under Vietnam's new Open API rules

Vietnam's State Bank brought Open APIs into force on 1 March 2025 under Circular 64/2024/TT-NHNN, and ACB ONE — the retail app of Asia Commercial Bank — sits squarely inside that regime. The circular spells out account information, payment initiation, loan origination and other financial-product API groups, with full bank compliance required by 1 March 2027 according to the State Bank's press release. That timeline matters for how you reach this app's data today: the regulated consent rail is being built, and where it is not yet published we integrate the customer's own authorized access instead. Either path lands the same thing for you — a working, documented interface to the balances, statements, cards and transfers the app holds.

ACB ONE bundles an online account, a debit card and digital banking into one signup, charges no transfer or account-management fee, and carries savings, card management, bill payment and e-wallet links to Momo, ShopeePay and ZaloPay. Most of that is per-user, server-held state behind an authenticated session. That is exactly the kind of surface a third party wants to query or sync, and it is what we map.

Routes to the data, and the one we'd take

Three paths genuinely apply to ACB ONE. They differ in how durable they are and how much consent plumbing they need.

Authorized interface integration

We analyse the app's own traffic under your authorization and rebuild the calls behind the screens you already use — login and SafeKey token exchange, account list, statement query, transfer status. Reachable: effectively everything the app shows a logged-in user. Effort is moderate; durability depends on the app's release cadence, which we account for with a re-validation step. This is the path that works today, before the Circular 64 catalogue is live.

Regulated Open API consent (AIS / PIS)

As ACB submits and publishes its API list to the State Bank — banks were required to file catalogues by 1 July 2025 per the circular — account-information and payment-initiation calls move onto a consented, standardized rail using OAuth2 (the circular references RFC 6749 / 6750) over TLS 1.2 or higher. Most durable route; we set up the consent registration and onboarding with you when the endpoints are available.

User-consented native export

ACB ONE produces statements and transaction histories a customer can pull themselves. Lightweight, good as a backfill or reconciliation feed, weaker for real-time needs. We treat it as a supplement.

For most projects we'd build on authorized interface integration first because it delivers the full retail surface now, then migrate the account-information calls onto ACB's Circular 64 endpoints as they publish, so the consent rail becomes the long-run home for the data without holding up delivery. We say which calls move and when, in writing.

What ACB ONE actually holds

What lands in your repo

The output is a working integration for the surfaces above, not a report. Concretely, for ACB ONE that means:

• An OpenAPI/Swagger spec covering the account, statement, transfer-status and card endpoints we map.
• A protocol and auth-flow report documenting the login, ACB SafeKey OTP/token step, session refresh and the cookie or bearer chain as it actually behaves.
• Runnable source for the key calls in Python and Node.js — fetch balances, page through a statement, read a transfer status by Napas reference.
• Automated tests against those calls, including the SafeKey-expiry and re-auth paths.
• Interface documentation plus data-retention and consent-logging guidance keyed to Vietnamese law.

How the auth flow looks

Illustrative shape of a session-and-statement call, confirmed against the live flow during the build. ACB SafeKey is modelled as an explicit step rather than an afterthought.

POST /auth/token                      # OAuth2 password/device grant (RFC 6749)
  body: { username, device_id, client_id }
  -> 200 { access_token, refresh_token, safekey_required: true }

# SafeKey second factor (in-app OTP / soft token)
POST /auth/safekey/verify
  headers: { Authorization: Bearer <access_token> }
  body: { challenge_id, otp }            # auto-fill OTP bound to registered device
  -> 200 { access_token (elevated), expires_in }

GET /accounts/{acct}/statement?from=2026-06-01&to=2026-06-27
  headers: { Authorization: Bearer <elevated_token> }
  -> 200 { entries: [ { id, amount, currency: "VND",
                        counterparty, napas_ref, posted_at } ], next_cursor }

# on 401 expired_token -> refresh; on safekey_expired -> re-challenge, do not retry blind

Field names and grant type are reconstructed from observed behaviour and normalized in the deliverable; the point is that token refresh and SafeKey re-challenge are handled as named states, so an overnight sync recovers instead of failing on a stale session.

Consent and Vietnamese law

The governing instrument is Circular 64/2024/TT-NHNN, which places explicit customer consent at the centre of any Open API data sharing and requires banks, customers and third parties to follow Vietnam's confidentiality and personal-data rules. Personal data handling runs under Decree 13/2023/ND-CP (the Personal Data Protection Decree) and the Law on Cybersecurity, as the secondary sources describe them. In practice that means consent is scoped to named data — accounts, statements, transfers — with an expiry and a revocation path the customer controls, and data is minimised to what the integration needs.

How we operate: access is authorized or user-consented, every pull is logged against a consent record, data is kept to the agreed fields and retention window, and an NDA is in place where the work touches anything sensitive. Compliance posture, not paperwork we hand you to clear first.

Things we account for on this build

Two ACB-specific points that change the engineering:

• SafeKey is device-bound. The OTP auto-fills because the second factor is tied to the registered handset, and codes arrive even abroad. We design the session model around that binding so re-authentication is deterministic, and we capture the elevated-token lifetime rather than assuming a single flat session.
• ACB ONE and ACB ONE Biz are separate products. The business app (com.acb.acbb.prod, per its own listing) carries different roles, approval limits and entitlements. We scope to the retail app by default and, where both matter, map the entitlement differences so corporate approval chains are not treated like a single-user retail flow.
• The front end changes. ACB ships frequent app updates, so we add a re-validation pass to maintenance that flags when a mapped call shifts, instead of letting a sync drift silently.

Access for any of this — a consenting test account or, later, an ACB sandbox under Circular 64 — is arranged with you during onboarding. It is our step, not a wall you stand in front of.

Working with us

Source code lands in your repository, runnable, with the ACB ONE auth flow documented end to end. Source-code delivery starts at $300: you get the runnable API source and docs, and you pay only after delivery, once you have seen it work. Prefer not to host it yourself? Call our hosted endpoints and pay per call, no upfront fee. Typical cycle is one to two weeks. Tell us the app — ACB ONE — and what you need from its data; the access and compliance pieces we arrange with you. Start a conversation on the contact page.

App screens we worked from

Other Vietnamese apps in the same data picture

Same category, same kinds of server-side records — useful if you are unifying several Vietnamese banking sources behind one interface. Named as ecosystem, not ranked.

• VCB Digibank (Vietcombank) — retail accounts, transfers and cards for Vietnam's largest bank by branch reach.
• VietinBank iPay — accounts, statements, QR payments and savings.
• Techcombank Mobile — accounts, cards and a strong digital-banking feature set.
• MB Bank — accounts, transfers and embedded financial services.
• TPBank — app-first banking with LiveBank servicing.
• VPBank NEO — retail accounts plus digital lending.
• BIDV SmartBanking — accounts, bill pay and transfers at scale.
• Cake by VPBank — a digital-only bank with app-native accounts and cards.
• MoMo and ZaloPay — e-wallets ACB ONE links to, holding balances and payment histories.

What we checked

Reviewed on 27 June 2026 against the Play and App Store listings for the app's stated features, and the primary regulatory material for Vietnam's Open API regime. Citations:

• State Bank of Vietnam — press release on Circular 64/2024/TT-NHNN
• Circular 64/2024/TT-NHNN, full text (LuatVietnam)
• ACB ONE — Google Play listing
• Brankas — how Circular 64 changes Vietnamese open banking

Mapped by the OpenBanking Studio integration desk · June 2026.

Questions integrators ask about ACB ONE

Does ACB ONE fall under Vietnam's new Open API rules?

Yes. ACB is a licensed Vietnamese commercial bank, so it is in scope for Circular 64/2024/TT-NHNN, which the State Bank of Vietnam brought into effect on 1 March 2025 and requires full compliance with by 1 March 2027. That gives a regulated consent route for account information and payment initiation once ACB publishes its API catalogue; until then we integrate the customer's own consented access.

How do you handle ACB SafeKey OTP during an integration?

ACB SafeKey is an in-app OTP and soft-token step, and the auto-fill OTP behaviour described in the listing means the second factor is bound to the registered device. We model the SafeKey challenge as an explicit state in the auth flow, capture where the token is issued and validated, and document how a session is re-established on expiry so a sync does not stall on an unexpected OTP prompt.

Can you separate ACB ONE retail data from ACB ONE Biz?

They are different apps with different package IDs and different entitlements. We scope the build to the retail ACB ONE surface unless you need the business product, and where both are in play we map the entitlement differences so corporate accounts, approval limits and user roles are handled correctly rather than assumed identical.

What does the QR and Napas side look like for transfers?

ACB ONE issues and reads VietQR codes and routes interbank transfers over Napas, including the auto-split Napas behaviour in the listing. For an integration we capture the transfer-status lifecycle and the QR payload format so a downstream system can reconcile a payment to a Napas reference rather than polling a screen.