Accounts, funds and statements behind the ttb touch login

One ttb touch login sits in front of a lot at once: deposit accounts, a mutual-fund portfolio, auto loans, insurance policies and every PromptPay transfer a person has sent or received. TMBThanachart brings all of it together in a single Account Sum view, which is exactly why teams building aggregation, lending or reconciliation want a programmatic way in. The app is the retail banking channel for ttb (the merged TMB and Thanachart), and per its Google Play listing it ships under the package com.TMBTOUCH.PRODUCTION. What follows maps the data that sits behind that login, the authorized way to reach it, and what an engagement with us produces.

What ttb touch holds, product by product

Every row below reflects a surface the app actually presents to its own users. Granularity is what the app displays; the integration returns the same fields, normalized.

Authorized routes into the data

Two routes carry real weight for this app, plus a light export path for statement-only needs. Each is arranged with the account holder's consent; onboarding and access are handled inside the project.

Consent-based interface integration

We work with a consenting account holder, observe how ttb touch authenticates and talks to its back end, and rebuild the calls that return Account Sum, Smart Search history, MF port holdings and loan payment history. This reaches everything the app itself shows. The trade-off is durability: the app front end changes with releases, so a maintenance pass keeps the parser current. For a team that needs live balances and the full transaction window now, this is the route we would build the pipeline on.

Bank of Thailand Open Data (Your Data)

The BOT's Your Data programme establishes a standardized, consented channel for a person to move their financial data between providers. It opens with personal deposit data and expands to further classes in phases, per the Bank of Thailand. Where it covers what a project needs it is the more durable long-run feed, and we register as a data recipient with the consenting user. Because it is still rolling out, we design so the integration can switch onto this channel data-class by data-class as each becomes available, rather than gating delivery on it.

Native e-Statement export

ttb touch lets a user request e-Statements for deposit and loan accounts. For anyone who only needs periodic statements rather than live data, this is a low-effort supplement we can parse into structured records — narrower than the interface route, but simple and stable.

How a balance-and-statement call looks

Illustrative shapes below — field names are normalized and the auth pattern is what we confirm during a consented build. ttb touch activates against a device (with an activation code plus a debit or credit card, or a Hire Purchase number, as the app describes it) and signs in with a PIN or biometric, yielding a short-lived session token the app refreshes.

# 1) Device-bound login -> short-lived session token
POST /auth/device/login
  { deviceId, activationBound: true, pinProof }
  -> 200 { accessToken, refreshToken, expiresIn: 900 }

# 2) Account Sum: every product behind the login in one list
GET /accounts/summary            Authorization: Bearer <accessToken>
  -> 200 {
       deposits: [ { acctId, type: "all_free", ccy: "THB", balance } ],
       mfPort:   [ { fundCode, units, nav } ],
       loans:    [ { loanId, outstanding, nextInstalment } ]
     }

# 3) Transaction history for one deposit account
GET /accounts/{acctId}/transactions?from=2026-01-01&to=2026-06-30
  -> 200 { items: [ { postedDate, amount, direction,
                      counterparty, promptpayRef, channel } ] }
  # postedDate arrives in the Buddhist-era calendar; we convert to CE

on 401 -> refresh(refreshToken)    # keep the session alive
on 429 -> exponential backoff
log consentId + requestId per pull  # for the consent record
      

What we hand over for ttb touch

Everything below is scoped to the surfaces above, not a stock feature list.

• An OpenAPI/Swagger specification covering the endpoints you need: Account Sum, transaction history, e-Statement retrieval, MF port holdings, loan payment history.
• A protocol and auth-flow report — the device-binding, PIN/biometric sign-in, bearer-token and refresh chain as observed during the build.
• Runnable source for the key endpoints in Python and Node.js: login and token refresh, account list, statement fetch, transaction pull, with the Buddhist-era to CE date conversion built in.
• Automated tests that replay recorded responses as fixtures, so the parser is checked without hitting a live account on every run.
• Interface documentation an engineer on your side can pick up, plus data-retention and consent-record guidance for PDPA.

Consent and the Bank of Thailand rules

Two frameworks apply in Thailand. The Personal Data Protection Act (PDPA) governs how personal financial data is collected, stored and processed, so every pull runs on the account holder's consent, is logged with a consent identifier, and keeps only the fields a project actually uses. The Bank of Thailand's Open Data / Your Data programme adds a standardized data-portability channel: a customer can give recurring consent — up to twelve months, per the BOT consultation — to share account data through a secure digital channel, and the BOT requires that withdrawing consent be as easy as granting it. We build revocation and re-consent into the sync rather than bolting them on. The regulated deposit-data channel is opening in phases, so the dependable basis a project relies on today is that consumer consent, with Your Data folded in as it goes live.

Build notes specific to this app

Each note below is a concrete characteristic of ttb touch that the build accounts for.

Device binding and session lifetime

The app binds to an activated device and runs on a short-lived session token behind a PIN or biometric. We design the auth flow around that device-bound session and its refresh so the pipeline holds a stable session instead of re-enrolling on every run; the device enrolment is arranged together with the consenting account holder as part of getting started.

One view, several back ends

Account Sum shows deposits, mutual funds, loans and insurance in one place, but they come from different systems with different fields and granularity. We map each product type to its own normalized schema — a fund NAV row and a deposit transaction row stay distinct — so downstream code isn't handed a flattened blob it has to untangle.

Thai text and Buddhist-era dates

Statements and transaction labels come through in Thai, and dates arrive in the Buddhist-era calendar. We convert BE to CE on the way out and keep the Thai labels mapped to stable English keys, so your data layer sees consistent field names regardless of the display language.

Where teams put this data

• A personal-finance app that shows a user's TTB balances and transactions next to their other bank accounts in one dashboard.
• A lender that, with the applicant's consent, reads twelve months of transaction history and loan payment history as underwriting inputs.
• An SME accounting tool reconciling PromptPay inflows and outflows against invoices.
• A wealth view tracking MF port holdings and NAV movement over time.

Pricing and how delivery runs

A working ttb touch integration — runnable endpoints, the auth-flow report, tests and interface docs — lands in one to two weeks. You can take it as source-code delivery: the full source and documentation for the endpoints you need, from $300, invoiced only after it's delivered and you're satisfied it runs. Or call it as a hosted API, where we stand up and maintain the endpoints and you pay per call with nothing upfront. Tell us the app is ttb touch and what you want out of it, and access, sandboxing and compliance paperwork are arranged with you from there. Start a conversation about your ttb touch project.

Screens from the app

Public Play Store screenshots, for interface reference. Select one to enlarge.

Other Thai banking apps in the same picture

An integrator rarely wants one bank in isolation. These are the apps that typically sit alongside ttb touch when a project aggregates Thai retail banking data, named for keyword and ecosystem context only.

• K PLUS (Kasikornbank) — the largest Thai mobile banking base by users; holds deposits, transfers, cards and investment data.
• Make by KBank (Kasikornbank) — a lifestyle-focused companion app centred on organizing spending and transfers.
• SCB Easy (Siam Commercial Bank) — accounts, transfers, cards and a broad set of personal-finance products.
• Krungthai NEXT (Krungthai Bank) — retail banking with heavy use for government-related payments and transfers.
• KMA (Krungsri / Bank of Ayudhya) — accounts, credit cards, loans, PromptPay and international transfers in one app.
• Bualuang mBanking (Bangkok Bank) — deposits, mutual funds, government bonds and international transfers.
• MyMo (Government Savings Bank) — retail deposit and payment app widely used across Thailand.

Questions integrators ask about ttb touch

Can you get full transaction history out of ttb touch, or only recent activity?

Smart Search inside the app exposes searchable history per account, and a consented interface integration pulls the same records the app itself shows — counterparty, amount, PromptPay reference, channel and date. We normalize each row to JSON and convert the Buddhist-era dates the app returns to the Gregorian calendar.

How does the mutual-fund port data come through compared with deposit accounts?

The MF port shown in Account Sum comes from a different back end than deposit transactions, with its own fields — fund code, units and NAV rather than posted balance and counterparty. We keep them as separate normalized schemas so a fund holding and a deposit transaction are never merged into one shape.

Does the Bank of Thailand Your Data scheme let us just request TTB data officially?

The BOT Your Data / Open Data channel is in phased rollout, opening with personal deposit data before it expands to loans and payments, per the Bank of Thailand. Until it carries what a given project needs, the dependable basis is the account holder's own consent through interface integration, and we design the pipeline so it can migrate onto the Your Data channel as each data class becomes available.

What happens when TTB ships a new ttb touch release and the screens change?

We re-capture the affected flows against a consenting account and update the parser and field maps. Keeping the extraction stable across app updates is part of the maintenance we run, not something that resets the build.

Sources and review notes

Data domains were read from ttb's own ttb touch user guides (e-Statement, PromptPay and loan-history pages) and the Google Play listing; the regulatory picture is from the Bank of Thailand's Open Data programme and its Your Data announcement, checked July 2026. Primary sources: BOT Open Data, BOT — Project “Your Data”, ttb touch e-Statement guide, ttb touch on Google Play.

Compiled by the OpenBanking Studio integration desk, July 2026.