Integrating Techcombank Business after Vietnam's open-API turn

On 1 March 2025 the State Bank of Vietnam brought Circular 64/2024/TT-NHNN into force, and Techcombank Business — the corporate banking app at vn.com.techcombank.bb.corp.app — sits squarely inside that scope. The corporate audience here is real: Techcombank's own communications put the business app at over 100,000 customers in 2024, 89% of them active, with a 4.9 / 5 store rating on both platforms. That is the population an integrator is being asked to plug treasury and ERP systems into.

Our read of the data surfaces is below. The route we run today is authorized interface integration against a consenting corporate account, with the surfaces designed so they migrate onto Techcombank's Circular 64 open API as soon as the bank publishes its catalog.

Data domains we map for this app

Authorized routes to that data

Route 1 — regulated open-banking surface under Circular 64

The SBV regime requires banks (and foreign-bank branches) to expose standardized open APIs with explicit, per-customer consent. Per the SBV press release, banks must submit their API catalogs and roadmaps by 1 July 2025; the regulation's full-compliance horizon is 1 March 2027. This is the durable forward route. Today it is partially scoped rather than universally callable, so the build cannot rely on it alone yet.

Route 2 — authorized interface integration against a consenting account

Protocol analysis of the Techcombank Business mobile and web client traffic, then a reimplementation of the same login, listing, statement-query, transfer-submission and approval calls. Run under the corporate customer's authorization. Reachable: every surface in the table above. This is the route we recommend as the working spine for the next 12–18 months; it ships fast and is mechanical to maintain.

Route 3 — user-consented credential access via a corporate operator

Narrower path. A consenting operator delegates read-only credentials for treasury aggregation only. Useful when the customer wants a fast read-only feed and is not yet ready to scope the writing side (transfer initiation, approval). It survives until Route 1 is fully callable.

Route 4 — native export

CSV / PDF statements out of the app. Reconciliation and backfill only. Not real-time; not workflow-aware. Worth wiring as a fallback for end-of-day catch-up where Route 2 is paused for maintenance.

What we usually ship is Route 2 today, with the data model already shaped so that swapping the underlying transport to Route 1 — once Techcombank publishes its Circular 64 catalog — is a transport change rather than a rewrite of consumers.

What a typical call looks like

Illustrative pseudo-code for a statement query — exact field names are confirmed during the build against the real client traffic.

# Illustrative — confirmed during the build against the consenting account
from auth import refresh_session   # FIDO UAF token shim, operator-seeded

session = refresh_session(corp_id="TCB-CORP-001", operator_id="OPER-12")

resp = session.get(
    "/v1/corp/accounts/{accountRef}/statements",
    params={"from": "2026-04-01", "to": "2026-04-30", "page": 1},
)
resp.raise_for_status()

for item in resp.json()["transactions"]:
    yield {
        "tx_id":      item["referenceNo"],
        "value_date": item["valueDate"],
        "amount":     item["amount"]["value"],
        "ccy":        item["amount"]["currency"],   # VND, USD, EUR, ...
        "channel":    item.get("channel"),          # Citad, Napas247, internal
        "narrative":  item["description"],
        "counter":    item.get("counterparty"),
    }

Pagination, idempotency keys on initiation calls, and the maker / checker state transitions are all carried in the OpenAPI we hand over; this snippet shows the shape only.

What lands at handover

• OpenAPI 3.1 specification covering accounts, balances, statements, transfer initiation, approval status, QR receipt, corporate card list, FX payroll beneficiary.
• Protocol & auth-flow report: the FIDO UAF device binding, the server-side token refresh chain, the cookie / header sequence on each surface.
• Runnable source in Python and Node.js for each of the endpoints above, with a fixture-replay scaffold so reviewers can step through a real request without touching the bank.
• Automated tests covering happy path, maker / checker rejection, channel fallback (Napas247 down), and FX-account edge cases.
• Interface documentation in English; field-level mapping notes for VND ⇄ FX accounts; ledger-import samples for two common ERPs.
• A consent and audit specification aligned to the consent-dashboard requirement Circular 64 puts on the bank side, so the customer sees who has access, scope, and duration.

Normalized schema we hand to consumers

{
  "account":     {"ref": "VND-...", "ccy": "VND", "type": "current", "company_id": "..."},
  "balance":     {"available": 12500000, "ledger": 12500000, "as_of": "2026-05-20T08:12:00+07:00"},
  "transaction": {"id": "...", "amount": -2500000, "ccy": "VND",
                  "channel": "Napas247", "ref": "PO-2026-...", "narrative": "...",
                  "counter": {"name": "...", "account": "..."}},
  "approval":    {"id": "...", "state": "awaiting_checker", "submitted_by": "OPER-12",
                  "submitted_at": "2026-05-20T08:11:00+07:00"}
}

The shape is deliberately flat. ERPs the customer is feeding rarely want the bank's native envelope; they want this.

Circular 64, consent and audit

Circular 64/2024/TT-NHNN is the rule that frames anything we ship into a Techcombank Business pipe. The SBV press release confirms the legal definition the build has to honour: customer consent must be free, unambiguous, and bounded by purpose. Personal data of a customer may only be processed for that customer's benefit unless other law overrides it. A consent dashboard — who, what, how long — is required on the bank side.

What that means for the integration we deliver: every consent grant, scope and revocation is recorded; every read is logged; the operator can revoke at any time and the next call fails closed; data minimization is scoped per the integration contract, not per what the surface happens to expose. Decree 94/2025/ND-CP (29 April 2025) set up the fintech sandbox where open-API data sharing can be tested under SBV certification — when the build wants regulator-supervised cover, that is the path the studio walks the customer through, on the customer's behalf.

Practical notes from the build

• Multi-user entitlements. Corporate banking is not single-operator. The Techcombank Business app exposes maker / checker / approver roles. We map an operator's entitlement scope before the build so a maker credential can submit but never auto-approve, mirroring the in-app workflow rather than papering over it.
• FIDO UAF as device factor. The biometric is bound to the operator's device. We pair a server-side token-refresh shim seeded by a consenting operator with a clear re-seeding procedure for when the operator rotates devices, so live biometric prompts do not appear in the integration path while the human is still in the loop for approvals.
• Channel-selection parity. The app auto-picks the fastest payment rail (Napas247 for instant retail, Citad for high-value clearing). We replicate the channel-decision logic and expose channel as an output so the customer's ERP sees the same routing the app would have picked.
• Circular 64 transition shape. The surfaces we deliver are designed so each call has a Circular-64-compatible parallel. When Techcombank publishes its catalog under the SBV deadline, swapping the transport is a single layer change, not a rewrite of the customer's ERP integration.
• Front-end drift. Bank web fronts move. We bake a small drift-check job into the maintenance handover so signature changes show up as test failures the day they ship, not the day the customer's payroll bounces.

Interface evidence

Screens from the live Play Store listing, cited for what they show about the data surfaces above. Click to enlarge.

Sources we worked from

Cross-checked May 2026 against the SBV's own press release on Circular 64/2024/TT-NHNN, the English text of the circular as published by Luatvietnam, the Backbase case study covering Techcombank's business-banking platform build, and the live Play Store listing for the app.

• State Bank of Vietnam — press release on Circular 64/2024/TT-NHNN
• Circular 64/2024/TT-NHNN — English text (Luatvietnam)
• Backbase — Techcombank Business Banking case study
• Techcombank Business — Play Store listing

Mapping reviewed May 2026 — OpenBanking Studio integration desk.

Other Vietnam business-banking apps an integrator hits next door

Listed as ecosystem context. Same regulator, same Circular 64 horizon, different surface details. None of the below is endorsed or disparaged; they are named because real treasury teams hold accounts at several at once and a unified integration eventually touches them all.

• VCB DigiBiz — Vietcombank's 24 / 7 business platform; broad SME and large-corporate footprint, similar account / statement / transfer set.
• VPBank NEOBiz — VPBank's continuous-transaction app aimed at SMEs, with management tools layered on top of the same data domains.
• BIDV iBank — BIDV's corporate mobile front; pairs with BIDV Direct on web for the writing side.
• BIZ MBBank — Military Commercial Joint Stock Bank's business app; strong instant-payment posture inside Napas247.
• VietinBank eFAST — VietinBank's long-running corporate channel; deep cash-management and trade-finance surface.
• HDBank Biz — HDBank's business mobile front for SMEs.
• ACB Business — Asia Commercial Bank's corporate mobile app.
• TPBank Biz — TPBank's business mobile front, sharing many transfer and approval patterns.
• Sacombank mBusiness — Sacombank's corporate mobile channel.

FAQs integrators ask about Techcombank Business

Does Circular 64 mean we should wait for Techcombank's published catalog before we start building?

No. The Circular 64 deadlines are catalog filings by 1 July 2025 and full compliance by 1 March 2027. What we build today against a consenting corporate account maps onto the regulated surface as it lands; the build does not stall waiting for it.

Can the integration honour the maker, checker and approver workflow inside Techcombank Business?

Yes. We model the operator entitlement scope before the build so a maker-only credential submits a transfer while approvals queue to the right human exactly as they do inside the app.

Will the FIDO UAF biometric break the integration in production?

The biometric is a device-bound factor for the human operator. For the API path we run a server-side token-refresh shim seeded by a consenting operator, so calls do not trigger a live biometric prompt each request.

Are VND-only treasury teams stuck with FX payroll noise in the response?

No. The OpenAPI we hand over keeps foreign-currency accounts and payroll beneficiaries as separate resources from the VND account list, so a VND-only integrator can ignore them cleanly.

Source-code delivery of this Techcombank Business integration starts at $300 — runnable Python and Node.js for the endpoints above, the OpenAPI, the protocol report, tests, and English interface documentation — paid only after you have the bundle and are satisfied. The same surfaces are available as a pay-per-call hosted endpoint with no upfront fee. Typical delivery cycle is 1–2 weeks. Start the conversation at /contact.html.

Last walked through 2026-05-20.