Pulling balances and statements out of LPBank Plus

Since 1 March 2025, banks in Vietnam have had a named, consent-based way to share account data: Circular 64/2024/TT-NHNN, the State Bank of Vietnam's Open API rule. LPBank Plus — the retail app from Ngân hàng TMCP Lộc Phát Việt Nam (LPBank), launched in late March 2026 per the bank's own announcement — sits squarely inside that rule's scope. It holds per-customer balances, transaction history, term deposits and saved beneficiaries behind an authenticated login, which is exactly the material a third party wants to read, sync or verify.

Two facts shape how we'd approach it. LPBank's published API catalog under Circular 64 is still rolling out toward the 2027 compliance date, so a consent endpoint for every field is not yet there to call. And the app is AI-first: Smart Nav and the LP Pay transfer assistant wrap a language model around the same underlying account calls. We read the structured records underneath, under your authorization, and shape the build so the regulated consent path can take over the durable parts as LPBank publishes it. No rewrite when that day comes.

Where the data lives in the app

Each row below is a surface LPBank Plus actually renders, mapped to what an integrator does with it. The app describes a deliberately minimal interface that fronts core financial records, so most of what matters sits a tap or two from the home dashboard.

Three authorized ways into the data

These are the routes that genuinely apply to LPBank Plus. Access — a consenting account or, where it exists, an LPBank sandbox slot — is arranged with you during onboarding; it is part of the project, not something you hand us up front.

1 · Authorized protocol analysis of the app's traffic

We observe how the mobile client talks to LPBank's backend under your authorization, document the auth handshake and the account, transaction and transfer calls, then re-implement them as a clean client. This returns exactly the fields the app shows today, including Sinh lời Lộc Phát positions. It is the fastest path to a working pull and the one most exposed to front-end change, which we account for in maintenance.

2 · Circular 64 Open API / Account Information Services

As LPBank publishes consent-based endpoints under the SBV rule, these become the durable path: OAuth 2.0 authorization, TLS in transit, JSON over REST, and consent the account holder can revoke. Coverage tracks whatever LPBank has listed in its catalog at the time, which is still widening, so today this route is partial rather than complete.

3 · User-consented session access

For fields the catalog does not yet expose, the consenting account holder authenticates and we drive the session — including the OTP or biometric step-up — to read records the structured calls miss. It fills gaps while route 2 matures.

For a build you want running this quarter, we would start on route 1 against a consenting account, because it returns the live records LPBank Plus renders without waiting on a catalog entry, then migrate the balance and statement reads onto the Circular 64 endpoints as they appear so the long-lived parts ride the regulated rail. That migration is designed in from day one, not bolted on.

Circular 64 and how consent works here

The relevant instrument is Circular 64/2024/TT-NHNN, issued by the State Bank of Vietnam and in force from 1 March 2025. It frames Open APIs across Account Information Services, Payment Initiation, loan origination and other financial services, and names concrete technical standards: OAuth 2.0 for authorization, TLS 1.2 or higher in transit, JSON over REST, and consent that the account holder controls, can revoke, and that expires on a clock. Banks were to file their API catalogs and roadmaps with the SBV during 2025, with full compliance set for 1 March 2027; a 2024 draft sketched a query-then-consent-then-payment sequence, but the exact per-phase windows are best treated as still settling rather than fixed dates.

Whichever route carries a given field, our footing is the same: the account holder's own authorization, recorded. We log what was accessed, keep only the fields the use case needs, and work under an NDA where the engagement calls for one. Consent records and a revocation path are part of what we hand over, not an afterthought.

What lands in your repo

The deliverable is working software for LPBank Plus's surfaces, not a slide deck:

• An OpenAPI / Swagger spec covering the account, transaction, transfer and deposit reads we implement.
• A protocol and auth-flow report: the device-bound login, the token and refresh chain, and how the OTP / biometric step-up fits in.
• Runnable source for the key endpoints in Python or Node.js — authenticate, list accounts, page transactions, read Sinh lời Lộc Phát positions.
• A normalized schema that maps LPBank's VND records into stable field names, so a core-migration rename doesn't ripple into your code.
• Automated tests against captured responses, plus interface documentation a new engineer can follow.
• Compliance and data-retention notes tied to Circular 64 consent and revocation.

A statement pull, sketched

Illustrative shape of the transaction read — field names get confirmed during the build, not lifted from a published spec:

# 1. Device-bound login, OAuth2-style
POST /auth/token
  body: { deviceId, credentials }
  -> { access_token, refresh_token, expires_in }

# 2. Enumerate accounts (Bearer access_token)
GET /accounts
  -> [ { accountId, productCode, currency: "VND", balance } ]

# 3. Page a statement window
GET /accounts/{accountId}/transactions?from=2026-06-01&to=2026-06-30
  -> { items: [ { txnId, postedAt, amount, direction,
                  counterparty, remark } ],
       nextCursor }

# Step-up: some statement ranges and any transfer trigger
# an OTP or biometric challenge. We carry the refresh +
# step-up handshake so a long pull doesn't drop the session,
# and surface a typed error rather than a half-empty page.

What we plan around for this app

A few things specific to LPBank Plus that the build accounts for from the start:

The AI layer is not the data layer

Smart Nav runs an LLM over navigation and search, and LP Pay completes transfers from typed or spoken instructions. Some responses are composed text rather than stable records. We map which surfaces return structured JSON and target those; for the conversational flows we capture the transfer and lookup calls the assistant makes underneath, so you get records, not paraphrase.

A core migration is in motion

LPBank has been modernizing onto a Temenos core, per Temenos's own announcement, which means account and product identifiers can shift during cutover. We keep the normalized schema decoupled from raw field names and add a re-check step so a changed response shape fails loudly instead of quietly writing bad data.

Priority and standard logins parse differently

Priority customers see extra blocks — the assigned PRM relationship-manager contact, privilege tiers, upgrade criteria — that a standard account never renders. We scope the parser per tier so both kinds of login return clean output and one shape doesn't break the other.

Where teams put this to work

• A personal-finance app showing a customer's LPBank balances and Vietcombank or MB balances on one screen.
• An accounting tool that imports LPBank Plus transaction history nightly and categorizes it for SMEs.
• A treasury dashboard reconciling Sinh lời Lộc Phát and term-deposit positions against expected yield.
• A payout platform that name-matches a saved beneficiary before releasing funds.

Cost and cadence

Source-code delivery starts at $300, and you pay only after we hand the build over and you've run it. That buys the runnable endpoints, the OpenAPI spec, the auth-flow report, tests and documentation for the LPBank Plus surfaces you need. If you'd rather not host anything, the second model is a pay-per-call hosted API — you call our endpoints, you're billed for calls, there's no upfront fee. Either way a typical build runs one to two weeks. Tell us the app and what you want out of it and we'll point you at the right model: start a project at /contact.html.

Screens we mapped

Store screenshots used while tracing the app's surfaces. Tap to enlarge.

How this brief was put together

Checked in June 2026 against the app's Google Play listing, LPBank's own launch announcement, and current coverage of Vietnam's Open API rule. Where a detail is not public — internal endpoint names, the exact contents of LPBank's filed API catalog — this brief says so rather than guessing.

• LPBank Plus on Google Play — package, description, screenshots.
• LPBank's LPBank Plus launch announcement — features and positioning.
• Circular 64/2024/TT-NHNN — Open API in Vietnamese banking — scope and effective date.
• LPBank's Temenos core selection — context for the core migration.

Mapped by the OpenBanking Studio integration desk, June 2026.

The Vietnamese banking apps around it

The same authorized methods apply across Vietnam's retail banking and wallet apps, which matters if you're aggregating more than one source. A unified integration normalizes them to one schema.

• Vietcombank (VCB Digibank) — accounts, transfers and cards for one of the Big Four state banks.
• Techcombank Mobile — retail accounts, payments and savings on a modernized core.
• MB Bank — consumer banking plus an in-app marketplace and QR payments.
• VPBank NEO — VPBank's retail app spanning accounts, loans and cards.
• BIDV SmartBanking — accounts, transfers and bill pay from another state-owned bank.
• VietinBank iPay — retail accounts, deposits and payments.
• Timo — a digital-only bank with payment and term-deposit accounts and NAPAS cards.
• Cake by VPBank — a mobile-first bank with accounts, cards and savings.
• MoMo — an e-wallet and super app holding balances, bills, micro-loans and investments.
• ZaloPay — a wallet tied to the Zalo messenger, with balances and P2P transfers.

Questions integrators ask about LPBank Plus

Does Circular 64 mean LPBank Plus data is reachable through a consent API today?

Not fully yet. Circular 64 took effect on 1 March 2025 and Vietnamese banks were to file their Open API catalogs with the State Bank of Vietnam through 2025, with full compliance set for 1 March 2027. Until LPBank's catalog covers the fields you need, we read the same records through authorized protocol analysis of the app against a consenting account, and fold in the consent endpoints as they publish.

Can you separate LP Pay's conversational layer from the actual transfer records?

Yes. LP Pay and Smart Nav compose text with a large language model, but the money movement still runs through the bank's transaction calls underneath. We target that structured transfer and history API, not the chat text, so what you get is typed records with amounts, counterparties and status rather than rendered sentences.

LPBank is moving to a Temenos core mid-build — how do you handle that?

We treat account and product identifiers as values that can change during a core cutover, keep the normalized schema decoupled from raw field names, and include a re-check step so a changed response shape surfaces as a clear failure instead of silently corrupting data. That work is part of the maintenance handover.

Which LPBank Plus fields differ for a Priority (PRM) account versus a standard one?

Per LPBank's description, Priority accounts surface extra blocks — the assigned PRM relationship-manager contact, privilege tiers and upgrade criteria — that a standard account does not render. We scope the parser per tier so both a Priority and a standard login return clean records without one breaking the other.