Reaching the records behind Krungsri's KMA app

Krungsri puts an unusually wide product spread behind one login. The KMA home screen, by the bank's own feature description, ties deposits, credit cards, Krungsri iFIN, Car4Cash, home loan, insurance and mutual-fund holdings into a single summary view, with online statements reaching back twelve months. For anyone building lending, accounting, or personal-finance tooling for the Thai market, that single account is a dense source: balances and posting history sit next to installment-loan schedules and a mutual-fund portfolio, all keyed to the same customer.

The dependable way in is consent. A Krungsri customer who authorizes the work lets us observe and re-implement the KMA app's own data calls, then expose them as a clean interface. Thailand is also building a national lane for exactly this — the Bank of Thailand's Your Data programme — which makes a consent-first design the right bet rather than a workaround.

What the account exposes

Each row below is a surface KMA actually presents to a logged-in user, mapped to where it comes from and what an integrator does with it.

How we'd reach it

Two routes carry real weight for KMA, with a third worth naming.

Authorized session analysis

We instrument the KMA app under a consenting account, document the auth handshake and the per-product data calls behind the dashboard, and re-implement them as stable endpoints. This reaches everything the user can see — balances, postings, loan schedules, fund holdings — at full granularity. It is the most complete route and the one we would build the core integration on. The maintenance cost is honest: when Krungsri ships a front-end change, some calls shift, so we keep a re-validation step in the support cycle.

Native online statement as a feed

The twelve-month statement the app already generates is a clean, lower-effort source for transaction history and balances when a full live sync is more than a use case needs. It durable and easy to schedule, but narrower — no live loan or portfolio state. We often run it alongside route one for backfill and as a cross-check.

Your Data consented transfer

As the Bank of Thailand's open-data standards come online through 2026, consented institution-to-institution transfer becomes a first-class path. We design the consent and token handling so the integration can adopt that lane as it matures, rather than treating it as a separate rebuild later.

For most buyers the answer is route one carrying the live product data, with the statement feed wired in for history and verification — that combination gives both depth and a durable fallback for a single Krungsri account.

What lands in your repo

The output is a working integration for the surfaces above, not a report. Concretely:

• An OpenAPI specification covering the KMA endpoints we implement — balances, transactions, statements, loan and card detail, fund holdings.
• A protocol and auth-flow write-up: the login, device-binding, OTP/biometric step-up and token-refresh chain as observed during the build.
• Runnable source for the key calls in Python or Node.js, with a normalized schema that keeps each Krungsri product as its own record type.
• Automated tests against recorded responses, so a front-end change surfaces as a failing test rather than silent drift.
• Interface documentation plus PDPA-aligned guidance on consent records, logging and data retention.

A session sketch

Illustrative only — field names and the exact step-up sequence are confirmed against a live consenting account during the build, not asserted here as Krungsri's published contract.

# Authorized KMA session — illustrative shape, verified at build time
session = kma.authorize(
    device_profile=clean_profile,      # app rejects rooted / remote-access env
    credential=consenting_user,
)

# high-value reads trigger biometric / OTP step-up
if session.requires_step_up():
    session.satisfy(otp=consent_channel.fetch_otp())

stmt = session.get_statement(
    account_id="xxx-x-xxxxx-x",
    months=12,                          # trailing online-statement window
)

for tx in stmt.transactions:
    emit({
        "posted_at": tx.value_date,
        "amount":    tx.amount,
        "currency":  tx.currency,        # THB, plus FX legs for Boarding Card
        "counter":   tx.counterparty,
        "ref":       tx.eslip_ref,       # QR / PromptPay slip reference
    })

# on 401 / session-expired: refresh within consent window, re-validate, retry once

Where this gets used

• A Thai SME lender pulling balance and statement history from a borrower's consenting Krungsri account for an affordability decision.
• A personal-finance app aggregating a user's deposits, cards, loans and mutual funds into one net-worth view.
• An accounting tool reconciling PromptPay and QR-slip payments against invoices using the e-slip reference.
• A wealth dashboard tracking mutual-fund holdings alongside Krungsri Auto and insurance positions.

Consent and the Thai data regime

Financial data in Thailand is sensitive personal data under the Personal Data Protection Act, in force since 2022, which means explicit, granular, logged consent is the legal footing for any collection. We build to that: every integration runs on a recorded consent from the account holder, with scope and revocation handled in the flow, and data minimized to the domains a use case needs. The Bank of Thailand's Your Data initiative, introduced in October 2024 with operation expected through 2026, is establishing national consent standards for moving financial data between institutions — a "digital remote control" over personal data, as the central bank frames it. Designing now to those standards is why the consent-first route is the durable one rather than the convenient one. NDAs cover the engagement where a client requires them.

Engineering the studio handles

A few things about KMA specifically shape how we build, and we carry them rather than hand them to you:

• Multi-product aggregation. One KMA login fans out to deposits, loans, cards, mutual funds, debenture/equity, insurance and Krungsri Auto, each with a different record shape. We model them separately so an installment loan's schedule never gets flattened into a deposit balance, then unify them behind one interface.
• Device and integrity controls. The app declines to run on a rooted or jailbroken OS or with remote-access software active, and steps up to biometric or OTP on high-value actions. We run the build against a clean, consenting device profile and design the session layer around that step-up so reads stay authorized and the sync does not break.
• Statement window and refresh. Online statements cover roughly twelve months. We design the first-run backfill to page that window and a refresh cadence that keeps the consent token alive between syncs.
• Front-end churn. Krungsri ships app updates regularly, so a re-validation pass sits in the support cycle to catch shifted calls early.

Access, the consenting account and any sandbox arrangement are set up with you during onboarding — part of the project, not something to clear first.

Interface evidence

Store screenshots of KMA, useful for reading the surfaces named above. Select to enlarge.

Where KMA sits among Thai apps

The same integration approach maps cleanly across Thailand's banking and wallet apps, which is also where a buyer's wider data needs tend to land:

• K PLUS (Kasikornbank) — one of the most-used Thai banking apps; holds the same balance, transfer and statement records for KBank customers.
• SCB Easy (Siam Commercial Bank) — deposits, cards and transfers with an English interface.
• Krungthai NEXT (Krungthai Bank) — retail account, transfer and bill-payment data.
• Paotang (Krungthai) — government-linked wallet and benefit data alongside everyday payments.
• Bualuang mBanking (Bangkok Bank) — account balances, statements and transfers.
• TTB Touch (TMBThanachart) — deposits, loans and card records in one app.
• TrueMoney Wallet — e-wallet balance, top-up and payment ledger.
• Rabbit LINE Pay — wallet and transit-linked payment history.

Across a portfolio of these, the value is one normalized schema over many institutions; each app carries the same kind of consented financial record.

How this was checked

This mapping draws on the Bank of Ayudhya KMA feature pages and Play listing for the app's surfaces, and on Bank of Thailand and Thai privacy sources for the regulatory frame, reviewed in June 2026. Primary sources:

• Krungsri — KMA key features
• krungsri on Google Play
• Bank of Thailand — Project "Your Data"
• Bank of Thailand — Open Data

Mapped by the OpenBanking Studio integration desk · June 2026.

Integrator questions

Can you pull more than 12 months of statement history out of KMA?

The app exposes online statements for the trailing 12 months, as its own listing describes. We page through that window on first sync and then keep an incremental cadence so each new posting is captured going forward; anything older than the visible window has to come from a consenting account's archived statements, which we fold into the same normalized schema.

Does Krungsri's root, jailbreak and remote-access detection get in the way of integration?

KMA refuses to run when it detects a rooted or jailbroken OS or an active remote-access tool, per its security notes. We account for that by running the build against a clean, consenting device profile and designing the session layer around the biometric and OTP step-up the app asks for on high-value reads, so the sync does not trip those controls.

Which Krungsri products end up in the unified data schema?

The KMA dashboard aggregates deposits, loans, mutual funds, credit cards, debenture and equity holdings, insurance and Krungsri Auto on one page. We model each as its own record type so an installment loan's amortization is not flattened into a deposit balance, then expose them through a single consistent interface.

Is the Your Data scheme required to integrate now, or is consent enough?

Authorized, consent-based access works today and is the dependable basis. The Bank of Thailand's Your Data initiative, announced in October 2024 and slated to become operational through 2026, standardizes consent-based transfer between institutions; we design the integration so it can ride those national standards as they come into force without re-plumbing.

One last practical note on how the work is bought. Two engagement shapes run here: a source-code delivery, from $300, where you receive the runnable integration, spec, tests and docs and pay after delivery once it does what you needed; or a hosted pay-per-call API, where you call our endpoints and pay only for the calls, with nothing upfront. Either way the build runs on a 1–2 week cycle, you bring the app name and what you want from Krungsri's data, and we arrange access and the compliance side with you. Start the conversation at our contact page.