Reading account, statement and V-Wealth records out of VietinBank iPay

On 1 March 2025 the State Bank of Vietnam's Circular 64 turned account lists, account details and transaction history into named, consent-gated Open API surfaces. VietinBank iPay Mobile sits on top of exactly those records for VietinBank's retail customers — plus a handful the regulation's basic catalog does not yet name, such as V-Wealth fund, bond and gold positions, the personal financial manager's spending breakdown, and loyalty points. This page maps what the app holds and the authorized ways to read it programmatically.

What the bank holds for each iPay user

The app is the front end for a full retail relationship, so the server-side record set is broad. These are the surfaces an integrator usually wants, named the way iPay presents them.

Bottom line: the account and transaction tier is the part the regulation already addresses by name, so a consent-based read is the cleanest path there. The investment and PFM tiers are richer than the basic catalog, and we cover those with authorized protocol analysis of the client. Most projects want both, joined into one feed.

Reaching iPay's account data

Four routes apply here. They are not mutually exclusive — a real build usually combines the first two.

1. Circular 64 Open API consent

The SBV's basic Open API list defines customer-information endpoints: consent retrieval, access-token management, account list, account information, and transaction-history retrieval, plus a payment-initiation group. Access runs on OAuth 2.0 and OpenID Connect over TLS 1.2 or higher, with JSON over REST. This is the durable read for balances, statements and transfers, because the contract is set by regulation rather than by an interface that can shift. We handle the onboarding and the consent capture with you.

2. Authorized protocol analysis of the iPay client

For V-Wealth positions, PFM categories and loyalty — fields the basic catalog does not name — we analyze the app's own authenticated traffic under your authorization, replay the documented request shapes, and read the same data the customer sees. This is what we recommend pairing with route 1 so the investment and cash-flow tiers arrive in the same normalized output as the consented account data. It needs a re-validation pass when the client front end changes; we account for that in maintenance.

3. User-consented credential session

Where a single consenting account holder is the subject, we operate against their session directly, honoring the Soft OTP and Facepay Plus step-up the app enforces. Useful for a one-account net-worth or statement feed before a broader consent rollout.

4. Native statement export

iPay can produce statement exports; as a fallback these can be parsed for history where a live read is not yet wired. Lowest effort, lowest freshness — a backstop, not a primary feed.

For a typical VietinBank engagement we read accounts and transaction history through the Circular 64 consent endpoints and pull V-Wealth, PFM and loyalty through authorized protocol analysis, because that split keeps the regulated tier on the most stable contract while still covering the investment data buyers actually ask for.

Circular 64, the consent window, and Vietnam's PDPL

Circular 64/2024/TT-NHNN was issued by the State Bank of Vietnam in December 2024 and took effect on 1 March 2025; member banks file their Open API catalogs with the regulator on the way to a 1 March 2027 full-compliance date (per SBV and the published circular). Consent sits at the center: the bank must let a customer look up the data they have consented to share and withdraw that consent, and access by a third party runs for no more than 180 days after consent unless the customer and bank agree otherwise.

On the privacy side, Vietnam's Personal Data Protection Law (Law 91/2025) has been in force since 1 January 2026, replacing Decree 13/2023. Consent under it must be voluntary and specific — the customer understands the purpose, the data types, who processes the data, and their rights. We work to that standard: access is authorized and logged, consent records are retained, data is minimized to the fields a project needs, and we sign an NDA where the engagement calls for one.

What you get in the handoff

Deliverables are tied to iPay's actual surfaces, not a generic kit:

• An OpenAPI (Swagger) spec covering the consented account, balance and transaction-history endpoints, with the V-Wealth and PFM reads modeled alongside them.
• A protocol-and-auth report: the OAuth 2.0 / OpenID Connect flow, token and refresh handling, and where the Soft OTP and Facepay Plus step-up fires.
• Runnable source for the key reads in Python or Node.js — balances, statement pull, V-Wealth positions — with VND amount handling built in.
• Automated tests against recorded fixtures, plus interface documentation an in-house team can extend.
• Compliance and retention guidance shaped to Circular 64's 180-day window and the PDPL consent requirements.

Reading a statement, in outline

Illustrative shape only — exact paths and field names are confirmed during the build against the consented surface. This sketches a transaction-history pull after the OAuth consent token is in hand.

POST /oauth2/token
  grant_type=authorization_code
  code=<consent_auth_code>
  client_id=<tpp_id>            # third party registered under Circular 64
=> { "access_token": "...", "expires_in": 3600,
     "consent_id": "cns_...", "consent_expiry": "2026-12-23" }   # <= 180 days

GET /accounts/{account_id}/transactions?from=2026-06-01&to=2026-06-26
  Authorization: Bearer <access_token>
=> 200
   { "account_id": "0102xxxx", "currency": "VND",
     "transactions": [
       { "posted_at": "2026-06-24T09:14:05+07:00",
         "amount": -1500000,           # VND, integer, no sub-unit
         "type": "TRANSFER_OUT",
         "counterparty": "NGUYEN VAN A / BIDV",
         "napas_ref": "FT2617xxxxxx",  # NAPAS 247 reference
         "channel": "VIETQR" } ] }

# Handle: 401 expired token -> refresh; 403 consent_revoked -> re-consent;
#         429 -> back off; step-up required -> Soft OTP / Facepay challenge

Normalized output

Whatever the route, the data lands in one stable object so account and V-Wealth records join cleanly:

{ "source": "vietinbank_ipay",
  "account_id": "0102xxxx",
  "posted_at": "2026-06-24T09:14:05+07:00",
  "amount_minor": -1500000, "currency": "VND",
  "direction": "debit",
  "counterparty": { "name": "NGUYEN VAN A", "bank": "BIDV" },
  "rails": { "scheme": "NAPAS247", "ref": "FT2617xxxxxx", "qr": "VietQR" },
  "category": "transfer" }

What teams build on an iPay feed

• An accounting platform syncing a VietinBank business account's statement nightly, with NAPAS references matched to invoices.
• A net-worth app that joins iPay balances with V-Wealth fund, bond and gold positions under a single consent.
• A lender pulling consented transaction history to read cash-flow patterns for underwriting.
• A treasury tool reconciling outgoing NAPAS 247 and VietQR payouts against the counterparty bank.

What we plan around in an iPay build

Concrete things this app makes us design for, all handled on our side:

• The 180-day consent ceiling is scheduled, not discovered — we set the re-consent prompt ahead of expiry and alert as it nears, so a nightly pull never quietly returns empty because the grant lapsed.
• Sensitive reads sit behind Soft OTP and Facepay Plus step-up. We model where the challenge fires and keep the device-binding state the app expects, so a statement pull does not stall on an unexpected re-auth.
• Amounts come through in VND with no decimal sub-unit. We carry them as integers to avoid rounding and tag the NAPAS 247 reference so instant transfers reconcile against the other bank.
• The investment and PFM tiers fall outside the regulation's basic catalog. We read those via authorized protocol analysis and normalize them into the same schema as the consented account data, so downstream code sees one shape.

Screens this mapping drew on

Store screenshots we reviewed while mapping the surfaces above. Tap to enlarge.

Adjacent apps an aggregator would touch

An integration that reaches VietinBank rarely stops there. Same-category apps in Vietnam an aggregator commonly normalizes alongside it:

• BIDV SmartBanking — retail banking app holding accounts, statements and NAPAS 247 transfers for BIDV customers.
• Vietcombank (VCB Digibank) — Vietcombank's app with balances, transaction history and bill payment.
• Techcombank Mobile — Techcombank's banking app (formerly F@st Mobile) with account and card data and transfers.
• Agribank E-Mobile Banking — Agribank's app, with wide rural reach for accounts and payments.
• MBBank — Military Commercial Joint Stock Bank's app, covering accounts, transfers and savings.
• MoMo — Vietnam's largest e-wallet, holding wallet balances, transfers and merchant payment history.
• ZaloPay — wallet tied to the Zalo messenger, with P2P transfers and bill-split history.
• Viettel Money — Viettel's mobile-money service, with wallet and mobile-account transaction records.

Questions we get about iPay integration

Does SBV Circular 64 cover V-Wealth and loyalty data, or only accounts and transactions?

The regulation's basic Open API list names account list, account information, transaction history and payment initiation. V-Wealth fund, bond and gold positions, the personal financial manager's spending categories and loyalty points sit outside that list, so we read them through authorized protocol analysis of the iPay client and normalize them into the same output as the consented account data.

How do you stop a VietinBank consent from expiring in the middle of a sync?

Circular 64 caps third-party access at 180 days after the customer consents, unless the customer and bank agree otherwise. We schedule the re-consent prompt ahead of that ceiling and alert on approaching expiry, so a scheduled pull never silently returns nothing because the grant lapsed.

Can you reconcile NAPAS 247 instant transfers that show up in iPay?

Yes. Each instant credit carries a NAPAS reference and counterparty bank; we tag both on the normalized transaction so outgoing payouts and incoming credits reconcile against the other side, including VietQR-initiated transfers under the 500 million VND NAPAS ceiling.

We hold a consenting VietinBank account and want balances plus V-Wealth in one feed — what does the build produce?

You get an OpenAPI spec for the consented account and transaction endpoints, a protocol-and-auth report covering the OAuth and Soft OTP step-up, runnable Python or Node source for the balance, statement and V-Wealth reads, automated tests and interface docs. A first working version typically lands in one to two weeks.

Starting an iPay build

Source-code delivery starts at $300: you receive the runnable VietinBank iPay integration plus its documentation and pay only after delivery, once it works for you. Prefer not to run it yourself? The same endpoints are available as a hosted, pay-per-call API with nothing upfront. Either way the first working version lands inside one to two weeks. Tell us the account you want read and what you need from it at /contact.html.

How this brief came together

Checked in June 2026 against the State Bank of Vietnam's own circular announcement, the published basic Open API list, NAPAS's service pages, and the app's store listing. Primary sources:

• SBV press release on Circular 64/2024/TT-NHNN
• Basic Open API list for Vietnam's banking sector
• NAPAS FastFund 247 with VietQR
• VietinBank iPay on Google Play

Mapped by the OpenBanking Studio integration desk · June 2026.