Reaching the card, loan, and rewards records inside VIB's MAX app

VIB issues payment and credit cards, cash loans of up to roughly one billion VND (per the MAX store listing), and a Super Cash limit that shuffles between the two — and MAX is the single app where a customer's records for all of it sit behind one EKYC login. That makes it a clean integration target: the data is structured, account-scoped, and tied to a backend a fintech, accounting tool, or treasury system would want to read on a schedule. The route into it is changing right now, because Vietnam has just written open banking into law.

Our read: until VIB's consent endpoints are actually live, the dependable basis for a build is the customer's own authorization over their MAX account, worked through interface analysis. We then migrate that onto the regulated consent API as it becomes callable. More on both below.

Where Vietnam's open-banking rules sit today

The State Bank of Vietnam (SBV) issued Circular 64/2024/TT-NHNN on 31 December 2024, effective 1 March 2025. It is the first formal framework for Open APIs in Vietnamese banking — it defines an API catalogue, technical standards, and the rights and duties of banks and third parties, with explicit customer consent at the centre. Reporting on the circular describes a phased rollout: banks were to submit their API lists and deployment plans to the SBV during 2025, with full compliance required by 1 March 2027. So a VIB consent API is a near-term path, not a present-day given.

Personal data is governed separately. Decree 13/2023/ND-CP took effect 1 July 2023 and treated creditworthiness and financial data as sensitive; from 1 January 2026 the Law on Personal Data Protection (91/2025/QH15) raised that framework to statutory level, with Decree 356/2025/ND-CP as its guiding decree. Consent under these rules is specific: the data subject must know the data types, the purpose, who processes the data, and their own rights. We build to that standard — scoped consent, recorded, revocable.

What MAX actually holds

Mapped from the app's described features and screens. Field labels in the live app are Vietnamese; we normalize them to an English schema during the build.

Routes into the data

1 · Consent-based Open API under Circular 64

The durable path. As VIB exposes the SBV-catalogue endpoints, a third party reads card, loan, and balance data with the customer's recorded consent. Highest stability, cleanest legal footing. Timing depends on VIB's own publication schedule, which the circular pegs to 2025–2027, so this is something we stand the integration up to adopt rather than wait on idle.

2 · Authorized interface analysis of the MAX app

What we run today. With the account holder's authorization, we observe and document the request/response and auth flow the app uses, then implement a clean client against it. This reaches everything the user sees in-app and is available now. It needs a re-validation pass when VIB ships a front-end change, which we fold into maintenance.

3 · User-consented credential access

For a single account or a pilot, a consenting user authorizes access scoped to read-only retrieval. Quick to stand up; we keep the scope and the consent record tight.

4 · Native in-app export

MAX shows statements and contract documents in-app. Where a user can export those, it is a low-effort fallback for periodic snapshots — not real-time, but useful for backfills.

For a VIB MAX build we'd start on route 2 because it works against a real account this week, and wire it so the swap to route 1 is a connector change, not a rewrite — the consent API is where this should live once VIB publishes it.

A worked example

Illustrative shapes, not a published spec — exact field names are confirmed during the build against an authorized account.

# Session — MAX pairs EKYC enrolment with a device-bound token
POST /max/auth/session
{
  "device_id": "<EKYC-bound device handle>",
  "factors": ["otp", "biometric"],
  "scope": ["cards.read", "loans.read", "rewards.read"]
}
-> 200 { "access_token": "...", "expires_in": 900, "refresh_token": "..." }

# Card statement, one cycle
GET /max/cards/{cardId}/statement?cycle=2026-05
Authorization: Bearer <access_token>
-> 200 {
     "cardId": "...",
     "product": "credit|debit",
     "creditLimitVnd": 0,
     "superCashAvailableVnd": 0,    # one pool, shared with the cash-loan side
     "installments": [ { "rate": "0%", "termMonths": 6, "remainingVnd": 0 } ],
     "transactions": [ /* date, merchant, amountVnd, status */ ]
   }

# On 401, refresh once before re-auth; do not loop the device pairing
      

What you receive

Each deliverable is tied to a real MAX surface, not a generic checklist:

• An OpenAPI/Swagger spec covering the card, loan, Super Cash, installment, and rewards reads we map.
• A protocol and auth-flow report: the EKYC/device-bound session, token issue, and refresh chain as observed.
• Runnable source for the key endpoints in Python or Node.js, with the Vietnamese-to-English field normalization built in.
• Automated tests against recorded fixtures, including the Super Cash shared-limit case.
• Interface documentation and data-retention guidance keyed to Decree 356/2025 and the consent scope.

Build notes specific to MAX

Three things we account for on this app:

• Device-bound sessions. EKYC and NFC enrolment ties a session to the device. We capture the issue/refresh behaviour and design the sync so a routine re-auth on the device doesn't kill a running job.
• The Super Cash shared limit. One limit moves between the credit card and the cash loan. We model it as a single pool and derive each product's available balance from the same figure, so a draw on one side is reflected on the other instead of being counted twice.
• Localization and front-end drift. Labels render in Vietnamese; we map them to a stable English schema, and when VIB updates the MAX front end we re-run the capture and refresh the mappings as part of upkeep.

Access to a sponsor sandbox or a consenting VIB account is arranged with you during onboarding — that's our step in the project, handled with you, not a form you fill before we begin. We work authorized and logged, minimize what's pulled, and sign an NDA where the work calls for it.

App screens we worked from

Similar apps in the Vietnamese banking landscape

If MAX feeds a unified view, these are the neighbours an integrator usually wants alongside it:

• MyVIB — VIB's other consumer app, covering everyday accounts and transfers next to MAX's cards-and-loans focus.
• Techcombank Mobile — retail banking with savings, investments, and QR payments.
• MB Bank — personal and SME banking in one app, popular with younger users.
• VCB Digibank — Vietcombank's transfers and card management with a bilingual interface.
• VietinBank iPay — retail mobile banking with bill and card features.
• BIDV SmartBanking — broad retail services from one of the state banks.
• Cake by VPBank — a digital-first bank with accounts, cards, savings, and loans.
• MoMo — the leading wallet, with a large user base and merchant network.
• ZaloPay — a wallet tied to the Zalo messaging app.

How this was checked, and sources

Drafted from the MAX store listing, VIB's product descriptions, and primary legal coverage of Vietnam's Open API and data-protection rules, cross-read in June 2026. Citations below are the documents we leaned on.

• Circular 64/2024/TT-NHNN, effective 1 March 2025 (Lawnet)
• Vietnam's Open API draft circular — analysis (Tilleke & Gibbins)
• Law on Personal Data Protection 91/2025/QH15 (Hogan Lovells)
• MAX listing, Google Play (com.vib.max)

Mapped by the OpenBanking Studio integration desk · June 2026.

Questions integrators ask about MAX

Does Vietnam's Circular 64 already give VIB MAX a consent API we can call?

Not yet as a finished public endpoint. Circular 64/2024/TT-NHNN took effect 1 March 2025 and, per reporting on it, banks were expected to file their API lists and deployment plans with the State Bank of Vietnam through 2025 with full compliance by 1 March 2027. Until VIB's consent endpoints are live, we run the integration on the customer's own authorization through interface analysis of the MAX app, then move it onto the regulated consent API as VIB publishes it.

How do you keep the Super Cash shared limit consistent across the credit card and the cash loan?

Super Cash moves a single limit between a VIB credit card and a cash loan, so the two products are not independent. We model it as one shared pool and derive each product's available balance from the same source figure, so a draw on the loan side correctly reduces the card side in the synced data rather than double-counting.

What authentication does MAX use, and how does that shape the integration?

MAX pairs electronic KYC (EKYC) and NFC document reading at onboarding with device-bound sessions, as its store listing describes. We capture the token issue and refresh chain during the build and design the sync so a session re-auth on the device does not break the running job.

Two figures and the rest is conversation: source-code delivery starts at $300, runnable client plus docs and tests, and you pay only after delivery once you're satisfied; or run on our pay-per-call hosted API with no upfront fee and pay per call. Typical cycle is one to two weeks. Tell us the app and what you need from its data — start a project at /contact.html and we handle the access and compliance with you.