How to integrate Krungthai NEXT account and card data

On 30 October 2025 the Bank of Thailand enacted a rule that lets a customer move their own financial data out of one provider and into another, under what the regulator calls its Your Data project. Krungthai NEXT, the retail app of Krungthai Bank (KTB), is squarely inside that scope. Behind its login sit deposit balances, a full transfer and bill-payment ledger, personal-loan accounts, Krungthai Travel Card foreign-exchange balances, insurance policies, and KTC card usage. This brief maps what is reachable, the authorized route to each domain, and what we hand over when the work is done.

The bottom line is short. The richest data is the per-user banking record, and the dependable way to it today is authorized protocol analysis of the app's own traffic against an account whose holder has consented. As the BOT channels open — deposit accounts first, by the end of 2026 — we move each domain onto the regulated consent path. We design the build so that switch is a configuration change, not a rewrite.

What sits behind a Krungthai NEXT login

These are the surfaces the app exposes to its own user. Each maps to a server-side record a third party would want to read or sync.

Routes in, and the one we'd use first

Two or three routes genuinely apply to this app. Here is what each reaches and how durable it is.

Consented data sharing under the BOT rule

The regulated path. Once a domain's channel is live, the customer consents and the data flows through a standardized BOT channel rather than the app. Per the BOT announcement, deposit-account information leads the rollout at the end of 2026, with loan and payment data following through 2027 and 2028. Reach is bounded by the published phase; durability is high because the interface is governed, not scraped. We handle the third-party-provider onboarding and consent capture with you as part of the engagement.

Authorized protocol analysis of the app

This is what works right now. We observe the Krungthai NEXT client talking to its backend against a consenting account, document the auth and device-binding chain, and rebuild the calls behind balances, statements, loans and cards as a clean API. It covers everything the user can see in the app. It needs a re-validation pass when the app front end changes, which we wire into maintenance.

Native statement export

Krungthai publishes a statement-history export for products such as the Travel Card. Where an export exists, parsing it is a low-cost supplement for back-dated records, though the format is coarser than the live interface and tied to whatever the bank chooses to print.

Which route comes first depends on your timeline. Nothing in the regulated channel reaches loan or card data before 2027, so a team that needs the full record now starts with protocol analysis against a consenting account, since that path reaches everything the user sees. We then re-point each domain at the BOT channel on the date its phase opens, and pull in the native export only where you need history older than the live interface returns. The spec says which surface sits on which route, so nothing is ambiguous.

What lands in your repo

Every engagement ships the same kind of artifact set, tied to this app's surfaces:

• An OpenAPI/Swagger specification describing each modelled endpoint — balance read, statement query, loan account, card and points lookup — with request and response schemas.
• A protocol and auth-flow report covering the login, token issuance, refresh and device-binding sequence as it behaves on Krungthai NEXT.
• Runnable source for the key endpoints in Python and Node.js, with retry and error handling around session expiry.
• Automated tests against recorded fixtures, so a changed field is caught before it reaches production.
• Interface documentation: field meanings, THB and multi-currency handling, KTC-versus-deposit separation, pagination of statement history.
• Compliance and data-retention guidance — consent records, logging, and a data-minimization note tied to PDPA.

A statement pull, sketched

Illustrative only — exact field names and the token chain are confirmed during the build against a consenting account. It shows the shape: an authenticated session, a device-bound token, and a paged statement response normalized to one schema.

POST /ktb/next/auth/session        # device-bound login, returns short-lived token
  body  { device_id, credential_proof }
  200   { access_token, refresh_token, expires_in: 900 }

GET  /ktb/next/accounts/{acct}/transactions?from=2026-01-01&cursor=
  hdr   Authorization: Bearer <access_token>
        X-Device-Binding: <device_id>
  200   {
          "account": "xxx-x-x4821-x",
          "currency": "THB",
          "balance": 18452.10,
          "page": { "next_cursor": "X1c9..." },
          "transactions": [
            { "ts": "2026-06-21T09:14:02+07:00",
              "type": "transfer_out", "channel": "promptpay",
              "counterparty": "K-PLUS 081xxx4417",
              "amount": -650.00, "running_balance": 18452.10 }
          ]
        }

# 401 -> refresh once via /auth/refresh, then re-issue; never replay a stale token
# normalize: map type|channel onto the unified ledger enum, keep THB minor units exact

Where teams point this

• An accounting tool that imports a Krungthai NEXT customer's transfers and bill payments into its books without manual CSV handling.
• A lending or BNPL provider reading the loan account and installment schedule to keep an affordability view current.
• An expense product that reconciles Travel Card FX spend and KTC card points alongside the deposit ledger.
• A personal-finance app that aggregates a Thai customer's balances across banks into one position.

Thailand's data-sharing rule, and consent in practice

The governing instrument here is the Bank of Thailand's data-sharing regulation announced on 30 October 2025, which gives consumers and businesses the right to share data held by financial providers — deposit, loan and payment information including e-money and credit cards. Thailand's Personal Data Protection Act (PDPA) sets the privacy floor underneath it. Consent on this app is per-domain and revocable: the customer authorizes a defined scope, the access is logged, and we pull only the fields the use case needs. Where the BOT channel for a domain is not yet live, the same data moves under the account holder's direct authorization, captured and recorded the same way. We operate authorized, documented, data-minimized, and under NDA where the client needs it.

Things we plan around on this build

A few specifics shape how we scope a Krungthai NEXT integration:

• KTC card data comes from Krungthai Card, a separate issuer in the group, so we model card balances and reward points as their own object graph rather than merging them into the bank's deposit schema — the identifiers and refresh cadence differ.
• Registration uses face verification and device binding, so we design the session handling around a bound device and a short token lifetime, and build the refresh path so a sync does not silently drop when the token rotates.
• The scheduled-transaction feature reaches 24 months ahead, which means the statement model has to carry future-dated instructions distinctly from settled history, or forecasting views double-count.
• Loan figures the app surfaces — a credit limit up to 1,000,000 THB and an 11–24% annual rate band as the listing describes — are presentation values; we read the authoritative account record rather than the marketing copy for anything financial.
• We schedule a re-validation pass for app releases, because Krungthai NEXT ships updates regularly and a moved field should surface in our tests, not in your data.

Cost and how we ship it

Source-code delivery starts at $300: you get the runnable API source, the OpenAPI spec, tests and the interface docs for the Krungthai NEXT surfaces you need, and you pay after delivery, once the build works to your satisfaction. The alternative is the hosted API — you call our endpoints and pay per call, with no upfront fee and nothing to run yourself. Either way the cycle is one to two weeks, and you give us only the app name and what you want from its data; we arrange access and the compliance side with you. Tell us which surfaces matter and we will scope it — start a conversation here.

App screens

Reference screenshots from the Krungthai NEXT store listing — useful for pointing at the exact surface you want mapped. Click to enlarge.

What we checked, and where

We read the Krungthai NEXT store listing for the feature and product set, the Bank of Thailand's October 2025 data-sharing announcement for the regulatory route and its phase dates, and Krungthai's own product pages for statement-export and Travel Card details. Dates and figures above are attributed to those sources; anything we could not confirm is flagged rather than asserted. Mapped by the OpenBanking Studio integration desk, June 2026.

Primary sources: Bank of Thailand — data-sharing regulation · Krungthai NEXT on Google Play · Krungthai NEXT product page

Other Thai bank apps in the same integration picture

Teams aggregating Thai retail finance usually need more than one of these. Named for context, not ranked:

• K PLUS (Kasikornbank) — the largest Thai banking app by users; holds deposits, transfers and QR payments.
• SCB EASY (Siam Commercial Bank) — accounts, transfers, cards and investment surfaces.
• Bualuang mBanking (Bangkok Bank) — deposit accounts, bill payment and transfer history.
• TTB Touch (TMBThanachart) — accounts, cards and lending in one app.
• Krungsri Mobile App, KMA (Bank of Ayudhya) — balances, transfers and loan accounts.
• Paotang — KTB's wallet and government-services platform, with its own payment ledger.
• TrueMoney Wallet — a non-bank e-money wallet with balances and transaction history.
• MyMo by GSB (Government Savings Bank) — deposit and savings records for a large retail base.

A single integration that normalizes balances and statements across several of these is a common ask; the per-app interface work is what differs.

Questions integrators ask about Krungthai NEXT

Can KTC card data be pulled separately from the bank's deposit accounts?

Yes. The KTC card balance, usage and reward-point surfaces in Krungthai NEXT come from Krungthai Card, a separate issuer in the group, so we model them as their own object graph with their own identifiers rather than folding them into the deposit-account schema. That keeps card-spend analytics and reward ledgers cleanly distinct from bank statement data.

Does the Bank of Thailand 'Your Data' rule already cover the transaction history I need?

Not yet for everything. Per the BOT's 30 October 2025 announcement, the consented data-sharing channels open in phases: individual deposit-account information by the end of 2026, then loan and payment data across 2027 to 2028. We pull deposit and statement data through an authorized account today and switch each domain onto the regulated consent channel as that phase comes online.

What keeps the integration working when Krungthai NEXT ships an app update?

The app updates often, so we version the captured request and response shapes, pin the token and device-binding chain, and run a re-validation pass that flags a changed field or moved endpoint before it reaches your data. When a surface shifts we patch the mapping; that maintenance is part of how we run the build, not an afterthought.

Can we begin before the deposit-data phase goes live at the end of 2026?

Yes. The protocol-analysis route runs now against a consenting account and does not wait on the regulatory rollout. Give us the app name and what you want out of its data; access and the compliance paperwork are arranged with you during onboarding.