Techcombank Mobile: account and transaction data under Vietnam's new open-API rules

The route Vietnam just drew for this data

On 1 March 2025 the State Bank of Vietnam's Circular 64/2024/TT-NHNN came into force, and it is the cleanest thing that has happened to bank-data access in this market in years. It defines a consent-based open-API path — OAuth 2.0 token flows, TLS in transit, JSON over REST — that every commercial bank, Techcombank included, is expected to expose, with full compliance scheduled for 1 March 2027 and bank API catalogues filed with the regulator from mid-2025 (per Brankas' Circular 64 explainer). That regulated, customer-authorized feed is where a Techcombank Mobile integration wants to end up.

The gap is timing. The rule names the destination; not every data domain is published on day one. So a working integration today blends the two honest sources of this app's data: the consent route as it comes online, and authorized interface integration of the app's own traffic in the meantime. Both rest on the same footing — the account holder's explicit authorization to read their own records.

What the app actually holds

These are surfaces named the way the app and Techcombank's own pages describe them, mapped to what an integrator would do once the records flow.

Reaching the data

Circular 64 consent feed

The regulated path: a user-consented, time-bound grant against Techcombank's open APIs as they publish under the SBV framework. Reachable scope follows the regulation's phases — information query first, then consent-based access, then payment initiation. Durability is the strong point; once a domain is live here it is a supported, audited channel. Onboarding to the SBV sandbox and the consent flows is arranged with you as part of the build.

Authorized interface integration

Documented protocol analysis of the app's own client-to-server traffic, run under the account holder's authorization, to read records the consent feed has not yet exposed. This covers the transaction, statement and transfer surfaces above. Effort is higher and it needs a re-validation pass when the app's front end changes, but it reaches today what the regulated feed will reach over the next year.

Native export

Where an account can produce a statement file, we ingest it as a historical backfill so a new connector starts with prior periods rather than only data going forward.

What we would actually recommend: build the connector against the Circular 64 consent feed as the long-run home for this data, because the regulator has committed Techcombank to it and it is the durable, audited channel — and bridge the present-day gaps with authorized interface integration so you are not waiting on a publication date to start reading transactions. The native export feeds history into either. The mix shifts toward the regulated feed each quarter as more domains go live.

A worked call

Illustrative shape of a consented transaction pull, in the OAuth/JSON form Circular 64 specifies. Field names are normalized by us, not asserted as Techcombank's internal contract; the exact wire schema is confirmed during the build against the live grant or sandbox.

POST /oauth2/token            # consent-backed grant, OAuth 2.0 (RFC 6749)
  grant_type=authorization_code
  scope=accounts.read transactions.read
  -> { "access_token": "...", "expires_in": 900, "consent_id": "cns_..." }

GET /accounts/{accountId}/transactions?from=2026-05-01&to=2026-05-31
  Authorization: Bearer <access_token>
  -> 200 {
       "account_id": "vn-tcb-***",
       "currency": "VND",
       "transactions": [
         { "id": "txn_...", "booked_at": "2026-05-14T03:11:02Z",
           "amount": -250000, "type": "instant_transfer",
           "status": "settled", "card": "primary",
           "counterparty": "0xx-phone-transfer" }
       ],
       "next_cursor": null
     }

# handling the cases this app actually produces:
#  401 invalid_token / consent_expired -> pause sync, raise re-consent
#  202 transfer pending               -> event still in flight, poll status, do not finalize
#  supplementary-card line            -> tag card != "primary", keep cardholder split

What lands at the end

Everything is tied to the surfaces above, not a generic banking stub.

• An OpenAPI/Swagger specification covering the account, transaction, card-statement and transfer endpoints we connect.
• A protocol and auth-flow report: the OAuth token and refresh chain, consent-id handling, and the consent-expiry behaviour the sync depends on.
• Runnable source for the key endpoints in Python or Node.js — balance read, dated transaction pull with cursor paging, statement fetch, transfer-status poll.
• Automated tests, including the supplementary-card split and the in-flight-transfer case.
• Interface documentation plus data-retention and consent-record guidance for VND-denominated, Vietnam-resident data.

Engineering notes we account for

Two things on this app specifically shape the build, and we handle both inside the engagement.

• Primary and supplementary cards share a statement. Techcombank's own listing says the primary card statement includes the supplementary card's transactions. We carry both card identifiers through the pipeline so per-cardholder spend stays separable downstream instead of being flattened into a single statement total.
• Transfers default to 24/7 instant. The app defaults every transfer to round-the-clock instant settlement, which means a transfer status can change after the first response. We design the connector to treat a transfer as an event with a mutable status and to poll for confirmation, with idempotency on our side so a retried poll never double-books a payout.
• The consent grant is time-bound. Circular 64 consent is revocable and expires. We build the sync around the refresh window and emit an expiry signal ahead of lapse, so the feed pauses and prompts re-consent rather than dying mid-pull. Sandbox and account access for the build is arranged with you during onboarding.

Worked scenarios

• An accounting platform pulls dated VND transactions nightly and reconciles them against issued invoices, splitting primary and supplementary card spend per employee.
• A treasury dashboard reads payment-account balances in real time across a group's Techcombank accounts for a single cash position.
• A merchant tool matches incoming QR-pay receipts to open orders and closes them on settlement.
• A personal-finance app ingests the daily transaction stream and savings positions to rebuild the user's spending graph in its own UI.

Pricing

A Techcombank Mobile connector is a one-to-two-week build. From there it goes one of two ways. We can deliver the runnable source, the OpenAPI spec, the tests and the interface docs for your team to host — from $300, and you pay after delivery, once the integration is in your hands and working as described. Or we host the endpoints and you call them, paying per call with nothing upfront. Tell us the data you need and which side of that line you want; start the conversation here.

Screens we worked from

Sources and how this was checked

This mapping draws on Techcombank's own product and FAQ pages for the card-statement and transfer behaviour, the Play Store listing for the package identifier and feature set, and legal/industry coverage of Circular 64 for the open-API timeline and technical standards. Checked late June 2026; the Circular 64 phase dates run through March 2027, so the regulated-feed scope will keep widening after this review.

• Brankas — How open banking is evolving in Vietnam with Circular 64
• Tilleke & Gibbins — Vietnam open-API circular for banking
• Techcombank Mobile FAQ (card statements, notifications)
• Techcombank Mobile — Google Play listing

Mapped by the OpenBanking Studio integration desk, 28 June 2026.

Other Vietnamese banking apps in the same picture

Same market, comparable data, all candidates for one normalized integration layer:

• VPBank NEO — VPBank's retail app, holding accounts, cards and quick-loan records.
• MB Bank — combines personal accounts with SME tooling and a wide transfer set.
• VCB Digibank — Vietcombank's app, with transfers, card management and a bilingual interface.
• Timo — a digital account (on BVBank) with a lean, app-first record set.
• TPBank — retail accounts and a heavy card and QR-payment footprint.
• HDBank — retail and consumer-finance accounts and statements.
• ACB — accounts, cards and transaction history for personal customers.
• Home Credit Vietnam — consumer-lending balances and repayment schedules.

Questions integrators ask about this one

Does Vietnam's Circular 64 change how Techcombank Mobile data can be reached?

It sets the destination. Circular 64/2024/TT-NHNN came into force on 1 March 2025 and defines a consent-based open-API route — OAuth 2.0, TLS, JSON over REST — with full bank compliance scheduled for 1 March 2027. Where Techcombank has not yet exposed a given data domain through that route, we reach it through authorized interface integration of the app's own traffic under your authorization, and migrate the connector onto the regulated consent feed as it lights up.

Can you separate primary-card and supplementary-card transactions?

Yes, and it matters here. Techcombank's listing notes that a primary card statement carries the supplementary card's transactions inside it. We map both card identifiers so the normalized output keeps each cardholder's spend distinct rather than collapsing it into one statement line.

How do you handle the 24/7 instant-transfer events the app defaults to?

We model each transfer as an event with a status that can move after the initial response, so a connector polling for confirmations does not treat an in-flight 24/7 transfer as final. Idempotency keys on our side stop a retried poll from double-counting a payout.

Is consent revocable, and what happens to a running sync when it lapses?

Consent under Circular 64 is user-controlled, time-bound and revocable. We design the sync around the consent-refresh window and surface an expiry signal before the grant lapses, so the feed pauses cleanly and prompts re-consent instead of failing silently mid-pull.