Reaching account, statement and transfer records inside K PLUS

Around 17 million people run their daily banking through K PLUS, the figure cited in Thai digital-banking coverage for KASIKORNBANK's app. Behind that login sits the data a third party usually wants: deposit balances, a rolling income-and-expense summary, e-statements going back twelve months, PromptPay and QR transfers, credit-card and Xpress Cash positions, mutual-fund holdings, and a K Point loyalty ledger. This page sets out what those surfaces hold, the authorized way to reach them from Thailand, and what an integration of them looks like when it lands as code.

The bottom line: K PLUS is account-gated, server-backed, and multi-product, which is exactly the kind of app worth integrating and exactly the kind where a generic export will not do. The route we run is authorized interface work against a consenting account — the account holder permits the read, we map the traffic the app produces, and we hand back a normalized API over those surfaces.

What sits behind the K PLUS login

Each surface below is named the way the app and KASIKORNBANK's own help pages name it. The granularity column is what an integrator actually gets per record.

How we reach it

Two routes genuinely apply to K PLUS today, with a third coming into view as Thai infrastructure matures.

Consent-based interface integration

The account holder authorizes the read; we observe and reproduce the request and response shapes the app uses for the surfaces you need — login and session establishment, the statement query, the transfer history, the K Point ledger. Reachable: effectively everything the user sees in-app. Effort: this is the bulk of the work, because the auth chain and the per-product response shapes have to be mapped accurately. Durability: good while the app's traffic shape holds, with maintenance when the front end changes. We arrange the consenting test account and the working environment with you during onboarding.

Native e-statement export

K PLUS already emits e-statements to email, up to twelve months back, in a fixed format. Where you only need periodic statement data rather than live balances, parsing that emitted artifact is the cheapest and most stable path. Reachable: statement line items only. Effort: low. Durability: high, since the export format changes rarely. We build the parser and the ingestion around it.

Regulated consent sharing (forward path)

The Bank of Thailand's "Your Data" program is set to carry consent-based personal deposit data from late 2026, then loans and payments across 2027-2028. As that channel becomes available for KASIKORNBANK data, parts of the integration can migrate onto it. We design the first build so that migration is a swap of the access layer, not a rewrite.

For most K PLUS projects the consent-based interface route does the heavy lifting and the e-statement export covers the slower-moving reporting need; we wire the two so a single normalized feed comes out regardless of which one served a given field. Where your use is purely statement reporting, we would start and often finish on the export alone.

The auth flow, sketched

K PLUS binds a session to a registered device and steps up to facial verification on sensitive actions. The shape below is illustrative — the exact headers, token names and step-up triggers are confirmed during the build against a consenting account, not asserted here.

# 1. Device-bound session establishment (mutual-TLS channel)
POST /auth/v2/session
  device_id:      <registered-device fingerprint>
  credential:     <PIN or biometric assertion>
-> 200 { session_token, refresh_token, step_up_required: false }

# 2. Statement query, scoped to the consented window
GET /accounts/{acct}/estatement?from=2025-07&to=2026-06
  Authorization: Bearer <session_token>
-> 200 { period, items:[ {date, desc, amount, balance, channel} ] }

# 3. Step-up on a sensitive read
GET /cards/{id}/installments
-> 401 { step_up_required: true, method: "face" }
   # re-auth: submit biometric assertion, retry with fresh token

def pull_statement(acct, frm, to):
    s = establish_session(device_id, credential)   # handles refresh
    r = get(f"/accounts/{acct}/estatement",
            params={"from": frm, "to": to},
            token=s.token)
    if r.status == 401 and r.json().get("step_up_required"):
        s = step_up(s, method="face")              # re-establish, retry
        r = get(...)
    return normalize(r.json()["items"])            # -> unified schema

What lands at the end

Each deliverable maps to the K PLUS surfaces above, not to a generic checklist.

• An OpenAPI specification covering the endpoints we map — balances, e-statement, transfers, cards/loans, funds and K Point — with the normalized schema that flattens their differing shapes.
• A protocol and auth-flow report: the device-binding, session, token-refresh and facial step-up chain as it actually behaves for this app.
• Runnable source for the priority endpoints in Python or Node.js, including the statement pager and the step-up retry logic.
• Automated tests against recorded responses, plus the e-statement parser as a standalone module.
• Interface documentation and data-retention guidance keyed to PDPA and to your consent records.

Consent and PDPA

Thailand's Personal Data Protection Act (PDPA, B.E. 2562) has governed personal-data processing in force since 2022, and it is the regime this work sits under. The account holder's explicit consent is the legal and technical basis for every read: scope is limited to the surfaces you need, consent is logged with a timestamp and a revocation path, and we keep the data minimized to the fields the use case requires. The Bank of Thailand's consent-sharing mechanism, when it reaches deposit data from late 2026, adds a regulated channel for the same principle. Access is read-oriented, logged, and covered by an NDA where the engagement calls for it. We do not move money through these surfaces; we read what the consenting user already sees.

Things we account for in the build

K PLUS is not a single flat feed, and a few specifics shape how we build against it.

• Device binding and biometric step-up: the app re-establishes trust per device and demands facial verification on higher-risk reads. We model both inside the auth layer so a session re-establishes cleanly instead of failing silently mid-pull.
• The 12-month statement ceiling: the app exposes e-statements only as far back as the previous twelve months. We page the pull within that ceiling and archive each delivery, so a longer history builds up on your side rather than being demanded from the app in one shot.
• Mixed product shapes: the deposit account, credit cards, mutual funds, Wealth PLUS and the K Point ledger each return different fields. We normalize them into one schema so downstream code reads them the same way.
• Front-end churn: KASIKORNBANK updates K PLUS often, and updates can reshape the traffic. We build a re-validation pass into maintenance so a changed app version is caught and patched rather than discovered as broken data.

Engagement

Source delivery starts at $300 and is invoiced only after the code is in your hands and runs against your consented K PLUS access — if it does not do what the brief said, you do not pay for it. The alternative is the hosted route: we stand up the mapped endpoints, you call them, and you pay per call with nothing upfront. A typical K PLUS build runs one to two weeks depending on how many of the surfaces above you need. You bring the app name and what you want out of its data; the consenting access, the environment and the compliance paperwork are arranged together as part of the project. Tell us what you are pulling and from which surfaces, and we will scope it: start an enquiry.

Interface evidence

Screens from the K PLUS store listing, showing the surfaces referenced above. Tap to enlarge.

Where this was checked

Checked in June 2026 against KASIKORNBANK's own K PLUS help pages for the statement and feature behavior, the Bank of Thailand's open-banking material for the consent-sharing timeline, and Thai digital-banking coverage for the user-scale figure and the peer set. Primary references:

• KASIKORNBANK — K PLUS Request Statement
• Bank of Thailand — Open Data
• Bank of Thailand — Open Banking Data consultation feedback
• K PLUS — Google Play listing

Mapped by the OpenBanking Studio integration desk — reviewed June 2026.

Similar apps in the same integration picture

Teams aggregating Thai financial data rarely stop at one bank. These sit in the same category and the same normalization problem.

• SCB Easy — Siam Commercial Bank's app; deposit accounts, transfers and statements with a comparable login model.
• Krungthai NEXT — Krungthai Bank's app, widely used for government-scheme and welfare payouts alongside everyday banking.
• Bangkok Bank Mobile Banking — strong cross-border and international transfer data on top of standard account surfaces.
• TrueMoney Wallet — e-wallet at similar scale, heavy on top-ups, bill pay and 7-Eleven cash-in/out records.
• LINE BK — social-banking service holding deposit, transfer and nano-loan data inside the LINE app.
• Paotang — Krungthai's super-app for state wallets, bond holdings and government disbursements.
• ShopeePay — marketplace wallet with payment and top-up ledgers tied to e-commerce activity.
• GrabPay — mobility-and-delivery wallet holding ride, food and payment transaction history.

FAQ

Can you read more than 12 months of K PLUS statements?

K PLUS exposes e-statements up to the previous 12 months, as KASIKORNBANK describes the request-statement feature. We page the pull within that window and archive each delivery, so a history longer than 12 months accumulates on your side over time rather than appearing in a single call.

Does Thailand's open banking regime already cover K PLUS account data?

Not yet for general third-party access. The Bank of Thailand's Your Data project plans consent-based sharing of personal deposit data from late 2026, expanding to loans and payments through 2027-2028 per BOT material. Until that infrastructure carries K PLUS, the dependable basis is the account holder's own authenticated consent to read their data.

How do you handle the facial-recognition and device step-up in K PLUS?

K PLUS binds a session to a registered device and asks for facial verification on higher-risk actions, as the app describes its security. We model the device-registration and biometric step-up inside the auth flow so the session the integration uses stays valid and is re-established cleanly when it expires.

Can K Point and Wealth PLUS balances be read the same way as the bank account?

They are separate surfaces with their own response shapes. The K Point ledger, mutual-fund holdings and the Wealth PLUS portfolio each return different fields from the deposit account, so we map them individually and normalize them into one schema you can query consistently.