What it takes to integrate VPBank NEO's banking data

Vietnam is one of the few markets where the open-banking question moved from theory to a dated obligation in the last year. That changes how a VPBank NEO integration should be built, so it is where this brief starts rather than ending.

The rules changed in 2025

On 31 December 2024 the State Bank of Vietnam issued Circular 64/2024/TT-NHNN, effective 1 March 2025, which sets the technical and legal frame for Open APIs in banking — standardized Account Information Services (AIS), Payment Initiation (PIS), Loan Origination (LOS) and other financial services, with explicit customer consent as the gate (per the law-firm and Brankas analyses cited below). Banks were asked to submit their API catalogues and deployment plans to the SBV by 1 July 2025, and the Circular sets 1 March 2027 for full compliance. The technical baseline names familiar building blocks: OAuth-style authorization on RFC 6749 and RFC 6750, TLS 1.2 or higher, and ISO 20022 / ISO 8583 message formats.

What this means in practice: a consent-based AIS read of a VPBank NEO customer's balances and transactions is the route the regulation is steering toward, and it is the one we prefer where the endpoint is published. The data-protection side is settled and already in force. Decree 13/2023/ND-CP, effective 1 July 2023, requires clear, voluntary, purpose-bound consent before any personal data is processed, and the banking sector — customer identification, account, deposit and transaction records — sits at the centre of its scope (per Securiti's and Hogan Lovells' summaries). The dependable basis for any read we build is the account holder's own consent under that decree; Circular 64 is what standardizes the pipe.

Data domains held behind a VPBank NEO login

These are the surfaces the app describes and exposes to its own users. Granularity below reflects what a banking back end of this kind typically returns and is confirmed against the relevant surface during the build.

Routes to the data

Two routes genuinely apply to VPBank NEO, and they complement each other.

Consent-based AIS under Circular 64

The regulated path: an account holder authorizes read access, and the integration calls the standardized account-information endpoints over the OAuth/TLS baseline the Circular mandates. Reachable: balances, statements, and the structured account data the AIS catalogue covers. Effort is moderate and front-loaded into onboarding; durability is high because the surface is defined by regulation rather than a UI that shifts. We handle the participant onboarding and the consent-grant flow with you as part of the engagement.

Authorized protocol analysis of the app's traffic

For any surface not yet published as an AIS endpoint — and several will lag the 2027 deadline — we map the app's own request and response traffic under your authorization, document the auth chain (login, Smart OTP / out-of-band step, token refresh), and build a client against it. Reachable: effectively any screen the app itself renders, including loans, installments and rewards. Effort is higher and the durability is medium, because a front-end change can move a field; we account for that with the re-validation work noted below. Access is arranged with you during onboarding — the build runs against a consenting account or an agreed test profile.

The recommendation for VPBank NEO is specific: anchor balances and transaction history on the Circular 64 AIS read because it is the surface the regulator is hardening, and cover the loan, installment and rewards screens that AIS does not yet reach with authorized protocol analysis, both normalized behind one schema so the caller sees a single shape. Native statement export exists inside the app as a manual fallback for one-off reconciliation, but it does not scale to a live feed.

What lands in your repo

Each deliverable is tied to a VPBank NEO surface, not a generic checklist.

• An OpenAPI / Swagger specification covering the account, transaction, card and deposit reads you ask for, with a normalized schema that hides whether a field came from AIS or from protocol analysis.
• A protocol and auth-flow report documenting the login, Smart OTP and out-of-band redirect, and the token-refresh chain as observed during the build.
• Runnable source for the key endpoints in Python or Node.js — a working client, not snippets — with retry and consent-expiry handling.
• Automated tests against recorded fixtures so a VPBank front-end change shows up as a failing test rather than a silent gap.
• Interface documentation plus data-retention and consent-logging guidance written for Decree 13.

A worked request

Illustrative shape of an authorized transaction-history read, normalized for the caller. Field names and the exact auth handshake are confirmed against the live surface during the build.

POST /ais/v1/accounts/{accountId}/transactions
Host: gateway.internal           # AIS gateway, or replay target for protocol-analysis route
Authorization: Bearer {consent_access_token}   # RFC 6749 grant, consent-scoped
X-Consent-Id: {decree13_consent_ref}           # links the pull to a logged consent
Content-Type: application/json

{ "fromDate": "2026-05-01", "toDate": "2026-06-23", "page": 1, "pageSize": 50 }

--- normalized 200 response ---
{
  "account": "VPB-****3271",
  "currency": "VND",
  "transactions": [
    { "postedAt": "2026-06-21T09:14:00+07:00",
      "amount": -180000, "type": "BILL_PAYMENT",
      "counterparty": "EVN Ha Noi", "channel": "NEO", "memo": "Electricity" }
  ],
  "nextPage": null
}

# 401 -> out-of-band re-auth required: surface a re-consent prompt, do not silently retry
# 428 -> consent expired under Decree 13 window: trigger renewal flow

Engineering notes for this app

Two things shape a VPBank NEO build more than anything else, and we handle both on our side.

• Consent and session windows. Smart OTP and the out-of-band redirect mean a session and a consent both expire. We design the sync cadence to land inside those windows and to renew consent ahead of expiry, so a scheduled pull does not fail at 2am with no signal. The 401 / 428 handling in the snippet above is the contract for that.
• Front-end drift on protocol-analysis surfaces. Screens that we map from app traffic — loans, installments, the movement-reward challenges the app promotes — can shift when VPBank ships an update. We wire a re-validation pass into maintenance and gate releases behind the fixture tests, so a moved field is caught before it reaches your feed.
• Two products, one bank. VPBank also ships NEOBiz for business customers and a separate Smart OTP app (com.vpbank.vpbanksmartotp, per its store listing); we scope the integration to the NEO consumer surface you name and keep the auth companion app in the model rather than ignoring it.

Compliance is how we operate, not a hurdle we hand you: access is authorized and logged, data is minimized to the fields a use case needs, consent records are retained, and an NDA is in place where the work touches anything sensitive.

Cost and delivery

Source for the endpoints you name lands in a working repository inside one to two weeks. From there, pick the model that fits. Source-code delivery starts at $300: you receive the runnable client, the spec, the tests and the documentation, and you pay after delivery once it runs against your case and you are satisfied. The hosted alternative is pay-per-call: you call our endpoints and pay only for the calls, with no upfront fee. Tell us the app name and which VPBank NEO surfaces you need; access, consent setup and compliance paperwork are arranged with you as the work proceeds. Start the conversation here with the surfaces you have in mind.

Freshness and reliability

VPBank reports very high availability for the platform — figures around 99.96% system stability and hundreds of millions of online transactions a year appear in its own and trade-press reporting — which matters because a high-throughput back end punishes a brittle client. We build for that: paginated reads, idempotent retries, and a fixture suite that pins the response shape so the feed degrades loudly, not silently. Sync frequency is set to your use case and to the consent window, not to a fixed default.

Interface evidence

Screens from the app's store listing, used to map the surfaces above. Select to enlarge.

How this was checked

Surfaces were drawn from VPBank NEO's own description and store listing; the regulatory frame from the State Bank of Vietnam's Circular 64 coverage and Decree 13 analyses; competitor context from Vietnam digital-banking reporting. Checked June 2026 against the sources below.

• Brankas — Circular 64/2024/TT-NHNN and Vietnam Open API
• Tilleke & Gibbins — Open APIs in Vietnam's banking sector
• Securiti — Decree 13/2023/ND-CP overview
• VPBank NEO — Google Play listing

OpenBanking Studio integration desk · mapping reviewed 2026-06-23.

Adjacent apps in Vietnamese digital banking

Same-category apps a unified integration tends to span. Listed for context, not ranked.

• Timo — Vietnam's first digital bank, holding payment, term-deposit and goal-based saving records behind an account.
• Cake by VPBank — digital bank embedded in the Be ride-hailing app, with account and card data tied to in-app spend.
• TNEX — MSB-backed digital bank with everyday account, transaction and lifestyle data.
• MB Bank — full-service banking app with accounts, transfers and a large bill-payment surface.
• Techcombank Mobile — retail and business banking with statements, cards and investment positions.
• Vietcombank Digibank — one of the largest retail banking apps, holding account and transaction history at scale.
• MoMo — e-wallet with balances, transfers, bill payments and merchant transactions.
• ZaloPay — wallet inside the Zalo ecosystem, holding wallet balance and payment records.

Questions integrators ask

Can VPBank NEO data be reached through Vietnam's Open API rules?

Circular 64/2024/TT-NHNN took effect 1 March 2025 and defines standardized Account Information, Payment Initiation and Loan Origination APIs with customer consent at the centre; banks were asked to submit their API lists to the State Bank of Vietnam by 1 July 2025, with full compliance set for 1 March 2027. Where VPBank exposes a consent-based AIS endpoint, that is the cleanest route for balances and transaction history. Where a given surface is not yet published, we map it through authorized protocol analysis of the app's own traffic under your authorization, and normalize both behind one schema.

How does Smart OTP and out-of-band authentication affect a transaction-history pull?

VPBank NEO authenticates sensitive actions through Smart OTP and an out-of-band step that redirects into the app for password, passcode or biometric confirmation. For a read integration we keep the consent and session model intact rather than working around it: the build captures the token and refresh chain, schedules syncs to land inside the session and consent window, and surfaces a clear re-consent prompt instead of letting a pull fail silently.

Which VPBank NEO surfaces hold the data most worth aggregating?

The account summary and transaction history are the core, alongside card activity, transfer and bill-payment records for electricity, water and telecom, term-deposit and savings positions, and the consumer-loan and installment views. The eKYC profile and beneficiary list round out a know-your-customer or reconciliation use case. We map each surface to where it originates in the app and to what an integrator would do with it.

Does Vietnam's Decree 13 limit what we can store from VPBank NEO?

Decree 13/2023/ND-CP, in force since 1 July 2023, requires clear, purpose-bound consent before processing personal data, and account, deposit and transaction records sit squarely inside its scope. We design the integration data-minimized: pull only the fields the use case needs, hold consent records and processing logs, and retire data on the schedule the consent states. Where an NDA or a specific lawful basis is needed, that is arranged with you as part of the work.