Reaching Cake by VPBank account, deposit and fund records

The route runs through Vietnam's new consent rules

On 31 December 2024 the State Bank of Vietnam issued Circular 64/2024/TT-NHNN, the country's first formal Open API framework; it took effect 1 March 2025, with full compliance due by 1 March 2027 (per the regulator's published timeline as summarized by Vietnamese law firms and Brankas). That circular puts consent-based Account Information Services at the centre and names the technical baseline — OAuth-style authorization per RFC 6749 and 6750, TLS 1.2 or higher, and ISO-20022 / ISO-8583 data exchange. Cake is operated by VPBank, a licensed bank, with BeFinancial. So the data sitting behind a Cake login is exactly the kind of record this regime is built to share under the customer's authorization.

That shapes how we approach it. Where the standardized AIS endpoints are live for VPBank, a consented integration is the durable path; where they are not yet exposed for a given surface, authorized protocol analysis of the app's own traffic reaches the same records, with native in-app export as a backstop. The point of this page is the data and the working integration we hand over.

What Cake actually holds per user

Cake is not a single-product wallet. Behind one phone-number login sit several distinct ledgers, each described in its own listing copy. The table maps the real surfaces.

How we get to that data

Consent-based AIS (SBV Open API)

Under Circular 64 the authorized path is a customer-consented read against VPBank's standardized account-information endpoints, OAuth-authorized. Reachable: account balances and transaction history, and over time the broader product set as endpoints publish. Durability is the strongest of the routes because it tracks the regulator's own standard. Onboarding — registering the integration and arranging the consent flow — is something we set up with you during the engagement.

Authorized protocol analysis

For surfaces not yet exposed through standardized endpoints, we analyze the app's own client-server traffic under your authorization and rebuild the calls: the auth/token chain, the request fields, the response shapes. This reaches term deposits, the credit-card statement, Ung Tien Nhanh balances and the Dragon Capital holding in the way the app itself reads them. Effort is higher and it needs a re-validation pass when the app front end changes; we account for that in maintenance.

User-consented credential access & export

Where a person authorizes access to their own Cake account, a consented session can drive the same reads, and any in-app export serves as a backstop for one-off pulls. Lighter to stand up, narrower in scope.

For most buyers the consented AIS read is what we would build toward, because it is the path the State Bank of Vietnam is actively standardizing and it ages best; the protocol work fills the gaps for products the standard has not reached yet, so the two are designed together rather than ranked against each other.

What lands in your repo

The handover is a working integration for the Cake surfaces you name, not a report:

• An OpenAPI/Swagger spec covering the account, deposit, card, loan and fund-certificate reads you need.
• A protocol & auth-flow write-up — the OAuth/token chain (RFC 6749/6750 where the AIS route applies) and session handling as it behaves for Cake.
• Runnable source for the key endpoints in Python and Node.js, with a normalized schema that reconciles the several Cake ledgers into one model.
• Automated tests against recorded fixtures, plus interface documentation.
• Compliance and data-retention guidance aligned to Decree 13/2023/ND-CP and the Law on Cybersecurity.

One read, end to end

Illustrative shape of a consented account-statement read, confirmed against the live behaviour during the build:

POST /oauth/token            # RFC 6749 authorization_code grant
  grant_type=authorization_code
  scope=ais.accounts.read ais.transactions.read
  code=<consent_code>

=> { "access_token": "...", "token_type": "Bearer", "expires_in": 900 }

GET /ais/accounts/{accountId}/transactions?from=2026-06-01&to=2026-06-26
  Authorization: Bearer <access_token>

# normalized to a single model across Cake's ledgers:
{
  "account_key": "ck_9f3a...",        // canonical key, NOT the phone number
  "msisdn_alias": "+849xxxxxxxx",     // displayed account id, kept separate
  "currency": "VND",
  "available_balance": 4185000,
  "transactions": [
    { "id":"tx_55…","ts":"2026-06-24T09:11:05+07:00",
      "type":"transfer_out","amount":-250000,"counterparty":"…" }
  ]
}
# 401 -> refresh; consent expiry surfaces as a typed error, not a silent empty page

Things we plan for on this build

A few Cake specifics shape the work, and we handle them rather than hand them back as conditions:

• Phone number as account id. Cake's account number is an easy-to-remember phone number. We keep a separate canonical account key in the schema and never key reconciliation on the MSISDN string, so transfers and statement matching stay correct even if the alias is reused or reformatted.
• Several ledgers, one login. Current account, term deposits, cards, Ung Tien Nhanh and the Dragon Capital fund are distinct resources behind a single session. We model each independently so a daily NAV pull does not block on transaction polling, and a card-statement read does not wait on deposit accruals.
• Consent lifetime. The AIS route carries a token and a consent window. We design the sync around the refresh and re-consent cycle so it does not silently expire mid-month, and surface expiry as a typed error your scheduler can act on.
• Moving target. As VPBank publishes more standardized endpoints toward the 2027 deadline, we re-point surfaces from protocol-analysis calls onto the official AIS path during maintenance.

Access, sandbox and authorization are arranged with you during onboarding; the build runs against a consenting account or VPBank's AIS environment. Everything we touch is authorized, logged and data-minimized, under NDA where you need one.

Interface evidence

App screens we referenced while mapping the surfaces. Tap to enlarge.

Where Cake sits among Vietnam's neobanks

Useful context if a unified integration needs to span more than one app. Each name below holds comparable per-user records that a single normalized model could fold in.

• Timo — early Vietnamese digital bank; payment and term-deposit accounts plus its expense-jar feature, all account-bound.
• TNEX — digital-only bank with MSB; current accounts and spend data on a tech-first stack.
• ZaloPay — wallet with balances, P2P transfers and bill-payment history.
• VNPAY — payment rail and QR ecosystem holding transaction records across merchants.
• MoMo — large super-app wallet with payments, mini-loans and savings positions.
• Liobank (OCB) — digital bank with accounts, cards and savings ledgers.
• YOLO by VPBank — VPBank's lifestyle banking app with account and payment data.
• ShopeePay — wallet tied to marketplace spend, with transaction and balance records.

What was checked, and when

Surfaces were read from the app's own Google Play and App Store listings; the regulatory route from Vietnamese legal and fintech write-ups of Circular 64; market position from Mambu's neobank coverage. Reviewed June 2026 by the OpenBanking Studio integration desk.

• Cake by VPBank — Google Play listing
• Tilleke & Gibbins — Vietnam Open API circular
• Brankas — Circular 64 / Open Banking in Vietnam
• Mambu — Timo, TNEX and Cake

Questions integrators ask about Cake

Which Cake products does one consent actually reach — just the current account, or the term deposit and Dragon Capital fund balance too?

Each lives behind the same login but is a separate ledger. We scope the consent and the resource map per product, so a single integration can read the current account, term-deposit positions, credit-card statement and the fund-certificate holding rather than only the headline balance. Granularity differs by product, and we document what each surface returns.

Does Vietnam's Circular 64 cover Cake, and what changes by 2027?

Circular 64/2024/TT-NHNN from the State Bank of Vietnam took effect 1 March 2025 and sets a consent-based Open API framework with full compliance due by 1 March 2027, per the regulator's published timeline. VPBank is the licensed institution behind Cake, so as those standardized AIS endpoints come online we move the integration onto them; until then the consented and protocol-analysis routes carry it.

Cake account numbers are phone numbers — does that break statement matching?

It is a known quirk we handle. The account identifier is an MSISDN-style phone number, as the app describes it, so we keep a separate canonical account key in the normalized schema and never key reconciliation on the phone string alone, which keeps transfers and statement matching stable.

For a recurring pull of fund-certificate NAV and deposit interest, is pay-per-call or owning the source cheaper?

If you want a scheduled daily read of the Dragon Capital fund value and term-deposit accruals with no infrastructure to run, the hosted pay-per-call endpoints fit and you pay only for calls. If the sync sits inside your own systems or volume is high, owning the source from $300 is usually cheaper over time. Tell us the cadence and we will say which is the better buy.