Integrating SHB SAHA under Vietnam's new Open API rules

One SHB SAHA login fronts a lot: account balances and transaction history, instant transfers to SHB and other Vietnamese banks, a flexible savings ledger, bill-payment and top-up records across several utilities, card controls, and an asset-management view. That concentration is what makes the app worth integrating — and the timing is unusual. SHB sits under the State Bank of Vietnam's Circular 64/2024, which for the first time puts bank Open APIs on a published schedule. So a team that wants SHB SAHA data right now is working across a regulatory shift, not waiting on it.

This page lays out what the app holds, the authorized ways to reach it, and the working integration we hand over. The client side is short: you give us the app and what you need from its data; we do the rest.

Three authorized ways into SHB SAHA's data

Each route below is something we run on real engagements. They differ in reach, in how much survives an app update, and in what we set up to operate them. Access, the consenting account or sandbox, and any onboarding paperwork are arranged with you as part of the work — not a checklist you clear first.

1 · SBV Open API consent (Circular 64)

Circular 64/2024/TT-NHNN took effect on 1 March 2025 and requires banks to publish standardized, consent-gated Open APIs; per the SBV press release, API catalogs and plans were due by mid-2025 with full compliance by 1 March 2027. As SHB publishes the endpoints that cover your use case, this becomes the durable route: schema-stable, consent-tracked, and unaffected by app-front-end churn. We register the consuming side and wire the consent flow. The constraint is timing — coverage depends on SHB's own rollout against that 2027 deadline.

2 · Consented interface integration / protocol analysis

Under an authorized account holder's consent, we analyze the SHB SAHA client's own traffic, reconstruct the session and token chain, and map the calls behind balances, statements, transfers and savings into a documented interface. This is the route that gives you working data this quarter. It needs a re-validation pass when the app ships an update, which we account for in maintenance.

3 · Native statement export

Where a customer can export a statement from the app or portal, we parse and normalize that file into the same schema as a stopgap or a reconciliation cross-check. Lower fidelity than a live session, but useful for backfill and for proving figures match.

For most teams the practical first move is route 2: a reconciling feed against SHB SAHA's core screens inside a week or two, with the normalizer written so its output never changes shape. As SHB's Circular 64 endpoints come to cover your scope, route 1 takes over that same schema and the migration costs a config change, not a rewrite. Native export earns its keep mainly for historical backfill and for proving the live figures match.

Behind an SHB SAHA login

These are the app's own surfaces, named the way the listing names them, mapped to what an integrator does with each.

What lands in your repository

The deliverable is a working integration for the SHB SAHA surfaces you pick, not a report. For a typical scope built on route 2 and designed to carry onto route 1, that means:

• An OpenAPI/Swagger specification for the normalized endpoints — balances, statement, transfers, savings, card status — with request and response schemas.
• A protocol and auth-flow report: the session, token issue and refresh chain as it actually behaves, plus error and retry handling.
• Runnable source for the key calls in Python or Node.js, including the VND amount handling and the on-us vs NAPAS transfer tagging.
• Automated tests against captured fixtures, so a future app change shows up as a red test, not a silent gap.
• Interface documentation a developer can hand to the next developer, and consent/data-retention guidance written for Vietnam's PDPL.

A balance-and-statement pull, sketched

Illustrative shapes, not copied from any SHB document — field names get confirmed against a consenting account during the build. The normalizer emits the same JSON whether it came from a live session today or SHB's Open API later.

# 1) consented session — token issued, refreshed on 401
POST /saha/auth/session
  { device_id, username, otp }  ->  { access_token, refresh_token, expires_in }

# 2) statement for one account over a date range
GET /saha/accounts/{acctId}/statement?from=2026-05-01&to=2026-05-31
  Authorization: Bearer <access_token>
  ->
  {
    "currency": "VND",
    "opening_balance": 12500000,
    "closing_balance": 9840000,
    "txns": [
      { "ts": "2026-05-04T08:21:00+07:00",
        "type": "transfer_out",
        "channel": "napas",            # "napas" = interbank, "on_us" = SHB-to-SHB
        "counterparty": "VCB ****1234",
        "amount": -2000000,
        "ref": "FT26124XXXX" }
    ]
  }

# on 401: refresh, retry once with backoff; account ref masked in logs

Where integrators wire SHB SAHA in

• A Vietnamese personal-finance or budgeting app pulling balances and categorized bill history into one timeline.
• An SME accounting tool reconciling SHB transfers against invoices, with on-us and NAPAS payments tagged apart.
• A lending or underwriting flow reading consented transaction history and savings to assess affordability.
• A wealth dashboard folding the asset-management and fund holdings into a household net-worth view.

Consent and Vietnam's banking rulebook

Two instruments matter here, and both are settled law. The State Bank of Vietnam's Circular 64/2024/TT-NHNN governs how banks expose Open APIs and centres the customer's explicit consent for any third-party access. Personal data falls under Vietnam's Personal Data Protection Law (Law 91/2025/QH15), in force since 1 January 2026, which replaced the earlier Decree 13/2023 framework; it requires consent that is voluntary, specific and purpose-bound, and it singles out banking and credit data for tighter handling.

Every route we run stands on that consent. We keep consent records and access logs, minimize what we pull to the fields your use case needs, and work under an NDA where the engagement calls for one. Where the data crosses borders, we account for the PDPL's transfer rules in how the pipeline is built.

What we plan around in SHB's stack

These are the things experience says to design for on an SHB SAHA build. We handle each as part of the work.

• Two transfer settlement paths. The app moves money both on-us (SHB-to-SHB) and to other banks over Vietnam's NAPAS switch. Those clear differently, so we tag and reconcile them separately rather than treating every transfer as one type — otherwise statuses and timing drift.
• The Open API rollout clock. Because Circular 64 sets SHB on a fixed path to full compliance by March 2027, we build the normalizer so its schema maps onto SHB's eventual Open API endpoints without touching downstream consumers, and we re-validate against the app front end between now and then.
• Purpose-bound consent lifecycle. The PDPL ties consent to specific purposes, so we design the sync around the consent window — it renews on schedule instead of expiring quietly mid-run.
• Many biller formats, one schema. The bill-payment surface spans electricity, water, telco, toll, cable and ADSL, each with its own reference shape. We normalize those biller codes so downstream categorization sees one consistent structure.

Screens we worked from

Public store screenshots, used to confirm surfaces and labels. Select to enlarge.

Working with us, and the price

Source for a working SHB SAHA feed — say, balances plus statement and transfer tagging — starts at $300, and you pay it after we deliver and you have run it, once you are satisfied. That is the first model: you own the runnable source, the spec, the tests and the docs outright. The second is a hosted option: we stand up the endpoints, you call them, and you pay per call with nothing upfront. Either way the build runs in a one-to-two-week cycle. Tell us the app and what you need from its data, and access, the consenting account or sandbox, and any compliance paperwork get arranged with you from there. Start the conversation at /contact.html.

Other Vietnamese banking apps in the same space

If SHB SAHA is one node in a wider Vietnam integration, these are the apps that usually sit alongside it. Listed for context, not ranked.

• VCB Digibank (Vietcombank) — retail balances, transfers and card management behind a Vietcombank login.
• Techcombank Mobile (F@st Mobile) — accounts, cash-flow tracking and savings, with a behaviour-driven home screen.
• MB Bank — accounts, QR payments and transfers; one of Vietnam's most-used finance apps by installs.
• BIDV SmartBanking — BIDV account balances, transfers and a broad bill-payment catalogue.
• VPBank NEO — VPBank accounts, cards and savings in a single app.
• TPBank Mobile — TPBank accounts, transfers and digital onboarding.
• MSB mBank — MSB accounts, savings and everyday payments.
• Cake by VPBank — a digital-only bank with accounts, cards and small-ticket lending.
• Timo — a Vietnamese neobank with spending accounts and goal-based savings.

How this mapping came together

Checked on 25 June 2026 against the app's store listings, SHB's launch coverage, the SBV's own notice on Circular 64, and Vietnamese data-protection commentary. Primary sources opened:

• SHB SAHA on Google Play — feature list and package id.
• Vietnam News: SHB launches next-gen app SHB SAHA — launch date and scope.
• State Bank of Vietnam: Circular 64/2024/TT-NHNN press release — Open API scheme and timeline.
• Hogan Lovells on Vietnam's Personal Data Protection Law — consent and PDPL.

Mapped by the OpenBanking Studio integration desk · June 2026.

Questions SHB SAHA integrators ask

Does SHB SAHA's account data come through Vietnam's Open API scheme, or straight from the app?

Both are on the table. SHB falls under SBV Circular 64/2024, which puts bank Open APIs on a fixed timeline — catalogs were due to the regulator by mid-2025 and full compliance by March 2027 — so a consented Open API path is arriving. Until SHB's endpoints are live for your use case, we read the same balances, statements and transfers from the app's own consented session and normalize them to one schema, then move onto the Open API as it opens.

Which SHB SAHA screens can you turn into a feed first?

The quickest wins are the account balance and transaction-history view, instant transfers to SHB and other banks, and the flexible savings ledger. Bill-payment and top-up history, card status and limits, and the asset-management view follow once the core feed reconciles.

How do interbank transfers in SHB SAHA settle, and does that change the data?

Transfers to other Vietnamese banks settle over the NAPAS switch, while transfers between SHB accounts clear on-us. We tag the two paths separately so a transfer's status, timing and reference reconcile correctly instead of being lumped together.

What regulator and privacy law cover an SHB SAHA integration?

The State Bank of Vietnam, under Circular 64/2024/TT-NHNN, governs bank Open APIs, and personal data sits under Vietnam's Personal Data Protection Law (Law 91/2025/QH15, in force since January 2026), which builds on the earlier Decree 13/2023. Both put purpose-specific customer consent at the centre, and that consent is the basis every route we run relies on.

Can you build against a single consenting SHB SAHA account?

Yes. The build runs against one consenting account or a sponsor sandbox, arranged with you during onboarding, so we can confirm field names and transfer statuses before anything ships.