Reaching the deposit, card and transfer records inside Bangkok Bank's mobile app

Open the app and the first thing it loads is a portfolio, not a single balance: deposit and e-Savings accounts, credit cards, mutual funds, government bonds, Bualuang loan accounts, and Foreign Currency Deposit accounts spanning eighteen currencies. Bangkok Bank built one of Thailand's oldest mobile banking products on top of that breadth, and an integrator usually wants the same consolidated read the account holder sees — balances, statements, holdings — pulled on a schedule into their own system. That read is what this brief is about, and the route we would actually run is interface integration against a consenting account, with the country's new data-portability scheme treated as the path the work migrates onto.

What the app holds, surface by surface

Every row below maps to something the app itself exposes to a logged-in user, named the way Bangkok Bank names it. The granularity column is what a consented read can carry through; the last column is the job it tends to feed.

FCD is the surface most integrators underestimate. Those accounts each carry their own currency and an international-transfer context, so they cannot be folded into a Thai baht total without losing meaning. We keep them distinct.

Authorized routes to that data

Three routes apply here, and they are not equal for this app.

Consenting-account interface integration

The dependable path today. With the account holder's authorization, we analyze the app's own client-to-server traffic, model the authentication and session chain, and build a read client that mirrors the surfaces above. It reaches everything the user sees because it asks for it the same way the app does. Effort is moderate; durability depends on the front end, which we plan for. Access is arranged with you during onboarding and the build runs against a consenting account.

Bank of Thailand "Your Data" portability

The forward path. The BOT enacted its Your Data regulation in late 2025; providers are expected to enable individual deposit-data sharing by the end of 2026, with loan and payment categories following between 2027 and 2028, per the central bank's own notice. As each category goes live at Bangkok Bank, a standardized consent-based feed replaces the equivalent scraped surface. We design the integration so that swap is a configuration change, not a rebuild.

Native statement export

A useful fallback for history. The app already emails THB and FCD statements on request; where a one-off backfill or a slow cadence is enough, parsing those exports avoids touching the live session at all.

For most clients the consenting-account route carries the day-to-day load now, because it is the only one that reaches the full portfolio before the scheme matures — and we wire the build to lean onto Your Data deposit feeds the moment Bangkok Bank turns them on. The export route stays available for cheap historical backfill.

What a consented pull looks like

Illustrative, and confirmed against the app's behaviour during a build rather than copied from any published contract. A statement request is asynchronous in the app — you ask, the bank prepares it, you collect it — so the client mirrors that two-step shape.

POST /retail/statement/request        # authenticated session, consented scope
{
  "account":  "xxx-x-xxxxx-x",        # deposit or FCD account ref
  "currency": "THB",                  # FCD accounts carry their own code
  "from":     "2026-04-01",
  "to":       "2026-06-25"
}
-> 202 { "job_id": "stmt_8f21", "status": "preparing" }

GET  /retail/statement/result/stmt_8f21
-> 200 {
     "account":  "xxx-x-xxxxx-x",
     "currency": "THB",
     "as_of":    "2026-06-25T08:14:00+07:00",
     "lines": [ { "date":"2026-06-20", "desc":"PromptPay in",
                  "amount":"1500.00", "balance":"..." } ]
   }

# client concerns we handle, not you:
#  - session/token refresh when the prepared job outlives the login
#  - polling backoff so a slow statement job is not hammered
#  - per-account currency kept on every line; THB and FCD never merged

What lands in your repo

The deliverable is working software plus the documents that make it maintainable, scoped to the surfaces you actually need:

• An OpenAPI specification covering the read endpoints we model — accounts, statements, cards, loans, holdings.
• A protocol and auth-flow report: the login, token and session-refresh chain as it behaves for this app, with the statement job lifecycle written out.
• Runnable source for the key endpoints in Python or Node.js, including the consent capture and the FCD currency handling.
• Automated tests against recorded responses, plus a replay harness so a front-end change is caught before it reaches production.
• Interface documentation and PDPA-aligned data-retention guidance: what is stored, for how long, and how consent is logged and revoked.

Consent, and the Thai law it runs under

Access to a Bangkok Bank customer's records stands on that customer's explicit consent under Thailand's Personal Data Protection Act — the same basis the central bank named when it tied the Your Data programme to PDPA compliance. For this app that means three concrete things we implement: a consent record scoped to the exact account surfaces requested, an expiry and revocation path so a withdrawn consent stops the sync rather than failing quietly, and an access log that shows which records were read and when. Data is minimized to what the use case needs; an NDA covers the engagement where you ask for one. Your Data is the direction of travel, not today's settled plumbing, so we treat its deposit-data milestone as a date to build toward, not a feed to assume is already on.

Engineering we account for up front

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

First, the statement flow is asynchronous and email-delivered. A naive client that expects an instant response will time out; ours treats statement retrieval as a job with backoff, and where the bank only delivers by email we wire the collection step into that channel instead of assuming a synchronous download. Second, the portfolio mixes Thai baht and Foreign Currency Deposit accounts across eighteen currencies, and the app also threads SWIFT and PromptPay International transfers through the same views. We model currency as a first-class field on every balance and line, keep the source amount beside any converted figure, and scope the integration per account type so an FCD position never gets summed into a baht total. When the front end shifts — and a long-lived banking app's front end does shift — the replay harness flags the divergence and the re-validation step is part of how we maintain the integration.

Keeping it current

Banking front ends change on the bank's schedule, not yours. We set the read cadence to what the data warrants — daily for balances, on-demand for statements — and the recorded-response tests double as a tripwire: when a field moves or a flow changes shape, a test fails before stale data does any harm. That maintenance loop is part of the engagement, not an afterthought billed later.

Interface evidence

Screens from the Play Store listing, used to confirm the surfaces named above. Select to enlarge.

Neighbouring apps in the same integration

Teams that ask for Bangkok Bank usually want one or two of its peers covered under the same schema, which is why we map them the same way. Names are listed for context, not ranked.

• K PLUS (KBank) — Kasikornbank's flagship app; deposits, cards, transfers and PromptPay for a very large retail base.
• Make by KBank — KBank's envelope-style companion app, holding goal-based savings and transaction records.
• SCB Easy (Siam Commercial Bank) — accounts, cards, investments and QR payments across SCB's customer base.
• Krungthai NEXT — Krungthai Bank's app, heavily used for government-linked payments and PromptPay.
• krungsri / KMA (Bank of Ayudhya) — deposits, cards and loans with biometric and PIN login.
• TTB Touch (TMBThanachart) — post-merger app with goal-saving and loan servicing for car and home.
• MyMo by GSB — the Government Savings Bank app, common for benefit recipients and small savers.

Because they all expose the same shape of data — balances, statements, cards, transfers — a single normalized schema can carry several of them, which is most of the value when a fintech wants Thai bank coverage rather than one institution.

How this was checked

Reviewed against the app's Play Store description and Bangkok Bank's own digital-banking pages on 25 June 2026, cross-referenced with the Bank of Thailand's open-data and Your Data notices for the regulatory timeline. Primary sources opened:

• Bangkok Bank Mobile Banking — Google Play listing
• Bank of Thailand — data-portability regulation (Nov 2025)
• Bank of Thailand — Open Data programme
• Bangkok Bank — how to use Mobile Banking

OpenBanking Studio · integration-desk mapping, June 2026.

Questions integrators ask about this app

Which Bangkok Bank records can an integration actually read?

The app surfaces deposit and e-Savings balances, Thai baht and Foreign Currency Deposit statements, credit card balances and status, Bualuang loan accounts, and mutual fund, government bond and debenture holdings. A consented integration mirrors those read surfaces; transfer and PromptPay history is reachable as records, not as initiation.

Does Thailand's Your Data scheme change how we reach this app?

It will. The Bank of Thailand enacted the Your Data data-portability regulation in late 2025, with providers expected to enable sharing of individual deposit data by the end of 2026 and other categories phased through 2027 to 2028. Until a given category is live at Bangkok Bank, we build on the consenting-account route and keep the design ready to switch to the scheme as it opens.

How are the FCD and multi-currency balances handled?

Foreign Currency Deposit accounts carry their own currency code and SWIFT-side context. We normalize each balance with its currency and as-of timestamp so a multi-currency treasury view does not silently mix THB and FCD figures, and we keep the source amount alongside any converted value.

Is the PDPA consent record something you produce?

Yes. Access runs on the account holder's explicit consent under Thailand's Personal Data Protection Act, and we ship the consent capture, the scope and expiry handling, and the access log alongside the runnable source so the data trail is auditable from day one.

To start, send the app name and what you need out of it. Source-code delivery starts at $300: you receive the runnable client, the specification, tests and documentation, and you settle only after delivery once it satisfies you. Prefer not to host it yourself? Call our hosted API and pay per call, nothing upfront. Either way the cycle is one to two weeks, and access and PDPA compliance are arranged with you as part of the work. Tell us what you are building at /contact.html.