Reaching account and transfer data inside Vikki Digital Bank

DongA Bank's customer base moved onto a cloud-native core in 2024, and the app that came out of it is Vikki — HDBank's digital bank, relaunched after the State Bank of Vietnam pushed the troubled DongA into a mandatory transfer to HDBank (the rebrand took effect in February 2025, per The Investor). The platform underneath is Thought Machine's Vault Core, run through the Galaxy FinX joint venture. For anyone trying to read account, card and payment data out of Vikki programmatically, that lineage matters: the data is event-driven and API-shaped at the core, and Vietnam now has its first formal Open API rule sitting on top of it.

The bottom line for an integrator: Vikki holds the usual current-account spine plus a card and rewards layer, and the access question splits into a regulated consent path that is still rolling out and a consented interface path you can run today. We map both and hand back working code against whichever you want first.

Consent and the State Bank's Open API rules

Vietnam's framing instrument is Circular 64/2024/TT-NHNN, which the State Bank of Vietnam issued in late December 2024 and which took effect 1 March 2025. It defines an Open API catalog, the principles for banks and third parties, and the technical standards for the connection. Two tiers matter here: APIs that query information banks must publish anyway, and APIs that query customer information with that customer's consent. The consented tier is the one a Vikki integration leans on, and it is phased — banks filed their API catalogs and deployment roadmaps with the SBV through mid-2025, with broader compliance expected to land by 2027 (per LawNet and Brankas reporting on the circular).

So the durable, regulator-blessed channel exists in law but is mid-rollout at the institution level. Decree 13/2023/ND-CP, Vietnam's personal data protection decree, governs how the consented data is collected, stored and minimized. Practically, we record consent scope and expiry, keep the data set to what the use case needs, and log access — the same posture an SBV-supervised connection expects.

What Vikki holds per account

The surfaces below come from Vikki's own product descriptions and launch coverage. Granularity reflects what a consented read would return, normalized into a stable schema.

Three authorized routes into the data

1 · Circular 64 consent API

The regulated path. Once Vikki's customer-information APIs are live under the SBV catalog, a consented connection reads accounts and transactions through a standardized, supervised interface. Highest durability and the cleanest compliance story; the constraint is timing, since the consented tier is phasing in across the sector rather than being fully switchable today. We set up the onboarding and consent handling with you when this tier is reachable for your scope.

2 · Consented interface integration

Documented analysis of the app's own traffic, run against accounts you control or accounts whose holders have consented. This reaches the full surface set above now, mapping the auth handshake, token refresh and the JSON the app already exchanges with its backend. It needs a maintenance pass when the front end changes; we account for that rather than treat it as a one-off.

3 · Native export fallback

Where a statement or transaction export exists in-app, we wire it as a low-effort supplement for history and audit, behind the live feed rather than as the primary source.

For a build starting now, the consented interface route is the one that actually delivers a working feed this quarter, because it does not wait on Vikki publishing its SBV catalog. We design that integration so the same normalized schema swaps onto the Circular 64 API later with no change to your side — you get data this week and a regulated channel when it opens, off one contract.

The handover

Everything is tied to Vikki's real surfaces, not a template:

• An OpenAPI/Swagger spec covering the account, transfer, card and QR endpoints we map.
• A protocol and auth-flow report: the login, token-refresh and session chain as Vikki implements it.
• Runnable source for the key reads — balance, transfer history, card status — in Python or Node.js.
• Automated tests against the normalized schema, including the available-vs-posted balance case.
• Interface documentation plus consent-scope and data-retention guidance aligned to Decree 13.

A transfer-history call, sketched

Illustrative shape only — exact field names are confirmed during the build against the live app.

POST /api/v1/auth/token/refresh
  { "refresh_token": "<rotated per session>", "device_id": "<bound>" }
  -> 200 { "access_token": "...", "expires_in": 900 }

GET /api/v1/accounts/{acctId}/transactions?from=2026-05-01&channel=all
  Authorization: Bearer <access_token>
  -> 200 {
       "account": "VND-****1182",
       "available": 4820500, "posted": 5010500,
       "items": [
         { "id": "...", "ts": "2026-05-14T09:21:07+07:00",
           "type": "TRANSFER_24_7", "amount": -190000,
           "counterparty": "NAPAS:****", "channel": "p2p" },
         { "id": "...", "ts": "2026-05-14T12:03:55+07:00",
           "type": "QR_PAY", "amount": -64000,
           "counterparty": "MERCHANT:VietQR", "channel": "qr" }
       ]
     }

# normalize: tag channel (p2p|qr|bill), split available vs posted,
# retry token refresh once on 401, back off on 429

Things we plan around on this build

• Event-driven balances. Vault Core posts balance changes as events, not a nightly batch, so we model available and posted separately and reconcile against the event order — a synced ledger that adds raw amounts will drift otherwise.
• Recent rebrand churn. Because Vikki is a fresh relaunch off DongA Bank, screens and endpoints still move. We pin the app build we verify against and re-check the mapping when the front end shifts, so a release does not silently break the feed.
• Consent-window timing. Under the SBV consent model, authorizations expire. We design the sync around the refresh window so a consented feed renews on schedule instead of lapsing unnoticed.
• Channel separation. QR settlements, 24/7 peer transfers and bill payments arrive in one history surface; we tag each by channel and counterparty during normalization so downstream reporting stays clean.

Where integrators put this

• A personal-finance or accounting app pulling a consenting user's Vikki transactions into one ledger alongside other Vietnamese banks.
• A merchant or SME tool reconciling VietQR receipts against its own order records.
• A treasury view syncing balances and term-deposit maturities across several Vikki accounts.

Screens we mapped

Public Play Store screenshots, used to anchor the surface mapping. Tap to enlarge.

What we checked

This mapping was put together from Vikki's Play Store listing and product copy, HDBank/Thought Machine launch coverage, and the State Bank of Vietnam's Open API circular as reported by legal and fintech sources. Primary references:

• FinTech Futures — HDBank launches Vikki on Vault Core
• The Investor — DongA Bank renamed Vikki Bank
• LawNet — Open API implementation from 1 March 2025
• Brankas — Open banking under Circular 64

OpenBanking Studio integration desk · mapping reviewed June 2026.

Other Vietnamese digital banks in the same integration scope

A unified data layer over Vietnamese retail banking usually touches several of these. Listed for context, not ranked.

• Cake by VPBank — digital bank embedded with the Be ride-hailing app; holds accounts, cards and transfer history.
• Timo — early Vietnamese digital bank, now with Viet Capital Bank; current accounts and spend data.
• TNEX — MSB-backed, Gen Z-focused digital bank with accounts and payment records.
• Liobank — OCB's digital offering; deposits, cards and transfers.
• MB Bank — full-service bank app with accounts, QR and transfer surfaces.
• Techcombank Mobile — retail accounts, cards and bill payments.
• VPBank NEO — VPBank's retail app with accounts and statements.
• OCB OMNI — omnichannel banking with account and payment data.

Questions integrators ask about Vikki

Does Vikki's move onto HDBank's cloud-native core change what's reachable?

It helps. Vikki runs on a cloud-native, event-driven core (Thought Machine Vault Core), so balances and postings are versioned rather than batch-stamped. We model the schema against that event stream and separate available balance from posted balance, which keeps a synced ledger accurate between refreshes.

Which Vietnamese rule covers consented access to Vikki account data?

SBV Circular 64/2024/TT-NHNN, effective 1 March 2025, sets the Open API catalog and the consent-based path for customer-information APIs. Banks were due to file their API catalogs and roadmaps with the State Bank of Vietnam by mid-2025, with the consented-data functions phased in over the following 18 months. Personal data handling falls under Decree 13/2023/ND-CP.

Can you split VietQR payments out from ordinary 24/7 transfers in the feed?

Yes. Vikki exposes QR pay/receive and citizen-to-citizen 24/7 transfers as distinct flows. We tag each record by channel and counterparty type during normalization so QR merchant settlements and peer transfers land in separate streams instead of one undifferentiated transaction list.

We only control a handful of Vikki accounts to start — is that enough to build against?

Yes. We build and verify against a small set of consenting accounts you control, then harden the schema once the surfaces are confirmed. The app name and what you want from the data is the starting point; access and compliance are arranged with you as we go.

One closing note on how this runs. You give us the app and the data you need; we map the route, build it, and hand it over inside one to two weeks. Take the source-code path and you pay from $300, after delivery, once it runs against your accounts and you are satisfied — or skip the build and call our hosted Vikki endpoints instead, paying per call with nothing upfront. Either way, tell us what you are after at our contact page and we will scope it.