Pulling account and payroll data out of Techcombank Business

Techcombank moved its corporate clients onto a Backbase-built business app — per Backbase's own write-up of the rollout — where balances, transaction status, batch payroll and card controls all sit behind one FIDO-secured login. For a treasury team or a fintech building on top, the value is the structured ledger underneath: per-account balances that update with each transaction, posted and pending entries, payroll batches, and VietQR collections that clear through NAPAS in real time. Our work is to make that ledger reachable from your own code, under authorization, as a client library you can run.

The short version: the data is rich and well-structured, the access path in Vietnam is consolidating around a real consent regime, and an SDK that handles login, balance reads, transaction deltas and payroll status covers most of what teams actually ask for. The harder parts are the approval state machine and the device-bound auth — both of which we plan around rather than around the customer.

What the app holds, surface by surface

Authorized routes into the data

Three paths genuinely apply to this app, and we usually combine them rather than pick one.

Consent-based SBV Open API

Circular 64/2024/TT-NHNN puts a consent-driven Open API framework over Vietnamese banks, with customer-information functions phased in across the rollout. Where the account's bank channel exposes it, this is the durable route: REST, JSON, OAuth 2.0, TLS, and JWS signing, with the customer holding consent and revocation. Reachable here are account, balance and transaction reads scoped to what the corporate consents to. We arrange the consent registration and onboarding with you as part of the build.

Authorized interface integration

Against a consenting corporate login, we map the app and web-app traffic to reach everything the dashboard itself shows — balances, the full transaction stream, payroll batches, card and approval state. Effort is moderate; durability is tied to app releases, so we version the captured surfaces and re-validate on a cadence. This is the fastest way to broad coverage today, before the consent API is fully live for a given account.

Native export as backfill

The web app at business.techcombank.com.vn produces statement and transaction exports. These are low-effort and useful for one-time history backfill, but they are not a live feed, so we treat them as the seed for a delta sync rather than the sync itself.

For most teams the practical build leans on authorized interface integration now for breadth, with the consent API wired in as it becomes available for the corporate's bank channel — so the integration gets more durable over time without a rewrite. We say which path fits once we see the account.

What lands in your repo

The headline deliverable is runnable code, not a document set:

• A client library in Python and Node.js covering login and consent, balance reads, transaction listing with a delta cursor, batch and FX payroll submission plus status, and card-status queries.
• A poller/handler harness for the pending-to-posted transition and for instant VietQR collections, so a status change becomes an event in your stack.
• An automated test suite exercising each surface against a sandbox or a consenting account, so a release-driven change to the app shows up as a failing assertion before it reaches your production sync.
• A normalized schema for accounts, transactions and payroll, mapped to ISO 20022 fields where they apply, so the output drops into existing accounting or ERP models.
• Secondary, and included: an OpenAPI description of the implemented surface, an auth-flow report (OAuth 2.0 bearer, token refresh, FIDO binding), interface documentation, and consent/retention guidance for Decree 13.

A look at the transaction pull

Illustrative client usage against the transaction surface — field and endpoint shapes are confirmed during the build, not published constants:

from tcbb import Client

# OAuth 2.0 bearer, scoped to the consenting corporate account
client = Client(consent_token=token)

# delta sync: resume from the last cursor, take posted + in-flight entries
page = client.transactions.list(
    account_id=acct,
    since="2026-05-01",
    status=["POSTED", "PENDING_APPROVAL", "QUEUED"],
    cursor=cursor,
)

for txn in page.items:
    # match VietQR receipts to a virtual account; upsert keyed on the
    # bank-side reference, so a replayed page never posts a line twice
    store.upsert(key=txn.bank_ref, record=normalize(txn))

cursor = page.next_cursor   # persist for the next run

# response carries: bank_ref, amount, currency, value_date,
# status, counterparty, channel (e.g. NAPAS/VietQR), approval_stage

Errors split into auth-expiry (re-run the FIDO-bound refresh) and rate/availability (back off and retry the same cursor). The harness keeps the two apart so a token timeout never looks like missing data.

Consent and the SBV Open API rules

Two instruments govern this. Circular 64/2024/TT-NHNN — issued by the State Bank of Vietnam in late 2024 and effective from 1 March 2025 per Brankas's reporting — defines the Open API regime: banks remain the data controller and security owner, third parties process only within the customer's granted scope, and the customer can consent, withdraw, and review sharing history. Customer-information functions are phased in across the rollout window rather than switched on at once. Separately, Decree 13/2023/ND-CP, in force since 1 July 2023, makes explicit, informed consent the main basis for processing personal data. We build to both: consent records and access are logged, data is minimized to the agreed scope, and an NDA covers the engagement where the client needs one. Our posture is authorized, documented, consent-backed access — not workarounds.

Engineering details we plan around

Two things about this app shape the build, and we handle both on our side.

Device-bound auth and token life. The app uses FIDO UAF with biometric binding, per its store listing. A long-running sync has to re-authenticate cleanly, so we model the device-bound credential and refresh the token ahead of its expiry inside the harness — the sync stays live across a multi-hour backfill instead of dropping partway.

Queued approvals that settle later. Batch and payroll approvals can be submitted against an insufficient balance and then settle automatically once funds arrive. We represent that pending-then-settled state machine explicitly, so an ingestion job treats a queued approval as in-flight and only records settlement when the entry actually posts. The maker-checker approval stage rides along on each record for audit.

Access to a sandbox or a consenting corporate account is arranged with you during onboarding; it is part of how we run the engagement, not something you line up first.

Where teams plug this in

• A treasury dashboard reading multi-account balances each morning and intraday whenever a transaction changes status.
• Nightly accounting reconciliation: posted transactions matched to invoices, with pending entries flagged but not booked.
• Payroll automation that pushes local and FX batches and tracks each beneficiary's approval and settlement.
• Real-time collection matching: VietQR receipts reconciled to orders through virtual accounts as they clear over NAPAS.

Screens from the app

Listing screenshots, for interface reference. Click to enlarge.

How this brief was put together

Checked on 31 May 2026 against the app's own store listing, the SBV Open API coverage, Vietnam's data-protection decree, and reporting on Techcombank's corporate API work. Primary sources opened:

• Techcombank Business — Google Play listing (features, version history)
• Circular 64/2024/TT-NHNN — Vietnam Open API regime
• Decree 13/2023/ND-CP — Vietnam Personal Data Protection
• Techcombank API-driven corporate cash management

OpenFinance Lab · interface engineering team — notes compiled 31 May 2026.

Other Vietnamese business-banking apps in the same orbit

Same category, all holding corporate account and transaction data a unified integration would normalize side by side:

• BIDV iBank — BIDV's corporate platform for accounts, transfers and approvals across a large state-bank network.
• VietinBank eFAST — VietinBank's business banking app covering payments, statements and cash management.
• BIZ MBBank — MB Bank's SME and corporate app, pairing accounts with merchant collection tools.
• VPBank NEOBiz — VPBank's business app aimed at SMEs, with onboarding and transaction flows.
• OCB OMNI Corp — OCB's corporate tier of the Backbase-built OMNI platform for accounts and payments.
• ACB ONE Biz — ACB's business banking app for account management and approvals.
• Sacombank corporate online banking — Sacombank's omnichannel business platform for transactions and treasury.
• TPBank Biz — TPBank's SME-focused digital banking app for everyday business transactions.

Questions integrators ask

Can the transaction feed run as near-real-time as the app's dashboard, or only as a daily batch?

Both. The dashboard updates balances on transaction status and surfaces pending entries, so we poll for status transitions on a short cursor-driven cadence and reconcile against a daily backfill. Instant VietQR collections route through NAPAS in real time, so a virtual-account match can fire within seconds of the receipt; slower-moving statement history is pulled as a delta and backfilled once.

Does the corporate maker-checker approval flow show up in what you pull?

Yes. Corporate transactions move through an approval chain, and batch or payroll approvals can be queued against an insufficient balance and settle when funds arrive. We model the awaiting-approval, queued and posted states so a sync distinguishes a request still in the approver queue from one that has actually settled.

Which authorization basis do you build against in Vietnam — the SBV Open API or direct?

It depends on what is live for the corporate account at the time. Circular 64/2024/TT-NHNN sets the consent-based Open API path, with customer-information functions phased in over its rollout, so where that channel is available we build to it. Where it is not yet exposed for the account, we work from authorized interface integration against a consenting corporate login, and migrate to the consent API as it lands.

We pay foreign-currency payroll through the app — can that be reconciled too?

The app supports buying foreign currency in-app to pay overseas staff and batch-payroll submission, so the payroll surface carries per-beneficiary lines plus the FX leg. We map both the local and foreign-currency batches to a normalized payroll schema and track each beneficiary's settlement status, which is what an ERP or accounting push needs.

Working with us

Delivery for Techcombank Business runs one to two weeks: a runnable Python and Node.js client, an auth-flow report, the test suite and interface docs against the surfaces above. You can take that as source code from $300, paid only after delivery once it works for you — or skip the build and call our hosted endpoints instead, paying per call with nothing upfront. Tell us the app and what you need from its data, and we arrange the access and compliance side with you. Start the conversation on our contact page.