Wiring SCB EASY into your stack under Thailand's open-data rules

Siam Commercial Bank moves more than 12 million customers through this app, by its own description, and what they tap through each day — balances, PromptPay sends, bill slips, statement lines — lives on SCB's servers, not the handset. That is the data a fintech, a lender, or an SME accounting tool wants to read. The route to it in Thailand is shifting right now: the Bank of Thailand's Open Data framework, launched as the "Your Data" project in October 2024, is the regulated channel through which a consumer will be able to push their bank data to a provider of their choice. Until that channel carries SCB, the working basis is the customer's own consent. This page sets out both, the account surfaces in between, and what an engagement with us produces.

Your Data and the PDPA, in plain terms

Two things govern this work in Thailand, and they sit at different stages. The first is settled. The PDPA, in force since June 2021, classifies financial information as sensitive personal data, which means an account holder's explicit, recorded consent is required before anyone collects or processes it. Consent is revocable, retention is bounded, and a breach carries a 72-hour notification duty. That is the dependable footing for reading a customer's SCB EASY data right now, and every engagement runs on it.

The second is arriving. The Bank of Thailand's Open Data framework — its consumer-facing name is "Your Data" — gives individuals and SMEs the right to share data held by their financial providers through standardized, consent-driven digital channels. Per the BOT's published framework, the first phase covers personal deposit data and is slated to begin around late 2026, with other categories phased in across 2027 and 2028. We treat that as where the regulated route is heading, not as something a third party can call today, and we build toward it so the switch is a configuration change rather than a new project.

What sits behind a SCB EASY login

The app names most of its own surfaces. The table maps the ones an integrator usually wants to where they originate in the interface, how granular they are, and the job they do downstream.

Three workable routes to the data

Consented session integration (the path that works today)

With the account holder's authorization, we map the authenticated session the app itself uses — its device-bound token issuance, refresh cycle and the request shapes behind the account, statement and transfer screens — and read the same surfaces the customer reads. This reaches the full account picture. It needs maintenance when SCB ships a release that moves field shapes, and we account for that in the build. Access to a consenting account is arranged with you during onboarding.

The Open Data channel, as it comes online

As SCB exposes deposit data under the BOT "Your Data" scheme, the integration moves to a standardized, consent-driven channel. Durability is higher and the consent flow is the regulator's own. Reach is whatever the published standard carries at each phase, starting with deposits. We design the client against the framework now so adopting it later does not disturb downstream consumers.

Customer-held export as a backstop

SCB EASY produces e-statements the account holder can export. Where a project needs nothing beyond historical statement lines, parsing those files is a low-effort drop that sidesteps any live session.

If you are starting a build today, the consented session integration is the one we would put in production: it covers everything in the app, and its output is shaped so the regulated deposit feed can source the same records later without a rewrite. The export drop is worth wiring only when historical statements are all a project needs.

What the build hands over

Each engagement produces a working integration for the SCB EASY surfaces you name, not a study. Concretely:

• An OpenAPI / Swagger specification covering the endpoints we implement — account list, balance read, statement query, transfer and PromptPay history.
• A protocol and auth-flow report: the device-binding, token issuance and refresh chain the app uses, the biometric step-up points, and how errors and session expiry behave.
• Runnable source for the key calls in Python and Node.js, structured so the regulated Open Data channel can back the same functions later.
• An automated test suite that runs against a consenting account, including the contract checks that catch a SCB release shifting field shapes.
• Interface documentation and PDPA-aligned guidance on consent capture, retention windows and access logging.

Walking a statement pull

The shape below is illustrative; exact paths and field names are confirmed during the build against a consenting account. It shows the two moves that matter — a device-bound session, then a dated statement read — and where transfer rails get normalized.

# 1) Establish a device-bound session (OAuth2-style, observed in the app)
POST /auth/v1/token
  body: { grant_type, device_id, client_nonce, biometric_assertion? }
  -> 200 { access_token, refresh_token, expires_in: 900 }

# 2) Read a dated statement for one deposit account
GET /accounts/v2/{acctId}/statement?from=2026-05-01&to=2026-05-31
  Authorization: Bearer <access_token>
  -> 200 {
       "acctId": "xxx-x-x1234-x",
       "entries": [
         { "postedDate": "2026-05-04",
           "amount": -540.00, "currency": "THB",
           "rail": "PROMPTPAY",          # normalized: PROMPTPAY | INTRABANK | ORFT
           "counterparty": "PEA bill",
           "balanceAfter": 18460.25 }
       ]
     }

# 3) Token near expiry -> refresh, do not re-prompt the user
POST /auth/v1/token { grant_type: "refresh_token", refresh_token }
# 401 with device-unbound error -> trigger re-enrollment, not silent retry

What we plan around on this app

A few SCB EASY specifics shape how the integration is engineered. We handle these as part of the work.

• Device binding and biometric step-up. The app ties a session to an enrolled device and steps up with fingerprint or face checks. We build the client around the enrollment and step-up points so a re-auth resolves cleanly instead of failing as a blank pull, and we arrange device access with the consenting holder at onboarding.
• Transfer-type normalization. A PromptPay send, an SCB-internal transfer and an interbank ORFT transfer land in the history with different reference fields and rails. We map all three to one transaction schema, so a downstream ledger reads consistent records however the money moved.
• Front-end churn versus data shapes. SCB markets a customizable home screen and a rotating lifestyle menu, so the interface changes often while the underlying data rarely does. We keep a checked-in contract test that fails when a statement or transfer field actually changes, turning a SCB update into a visible signal rather than a quiet break.
• Movement-flow state. Cardless ATM codes expire in 15 minutes and daily transfer limits are adjustable per user; any flow that triggers movement is designed around that state rather than assuming a static ceiling.

Where teams put this data

• A Thai personal-finance app reads a consenting user's SCB deposit balances and categorized statement lines nightly to show real net cash flow across accounts.
• An SME accounting tool reconciles PromptPay receipts against open invoices by matching transfer references straight from the history feed.
• A lender ingests twelve months of statement history, with the borrower's PDPA consent, for cash-flow-based underwriting ahead of the Open Data deposit channel going live.
• A treasury dashboard confirms outbound interbank transfers have settled by reading posting status and the running balance after each entry.

Screens we mapped

Public store screenshots used while mapping the surfaces above. Select one to enlarge.

Sources and review

Surfaces were checked against SCB's own feature pages and the app description; the regulatory timeline was read from the Bank of Thailand's Open Data material in June 2026. Primary sources:

• Bank of Thailand — Project "Your Data" announcement (October 2024)
• Bank of Thailand — Open Data framework and rollout phases
• Siam Commercial Bank — SCB EASY feature pages

Mapped and reviewed by the OpenBanking Studio integration desk, June 2026.

Other Thai banking and wallet apps

The same integration question recurs across the Thai market. These apps hold comparable account or wallet data and would each anchor a unified, consent-driven integration; named here for context, not ranked.

• K PLUS (Kasikornbank) — deposits, QR payments and PromptPay transfers for one of the largest Thai retail bases.
• Krungthai NEXT (Krungthai Bank) — retail banking plus access to government payments and services.
• Bualuang mBanking (Bangkok Bank) — deposits, credit cards, mutual funds, government bonds and loan accounts in one view.
• KMA – Krungsri (Bank of Ayudhya) — deposit accounts, cards and transfers.
• ttb touch (TMBThanachart) — combined retail banking after the TMB–Thanachart merger.
• MyMo (Government Savings Bank) — deposit and savings data for a wide retail and rural base.
• TrueMoney Wallet — a large Thai e-wallet holding balances, top-ups and payment history.
• Rabbit LINE Pay — wallet and transit-linked payment records inside the LINE ecosystem.
• ShopeePay — marketplace-linked wallet balances and transaction history.

Questions integrators ask about SCB EASY

Is SCB EASY data available through the Bank of Thailand's Your Data scheme right now?

Not yet for third parties. By the BOT's Open Data framework, the first phase, personal deposit data, is slated to begin around late 2026, with other categories following through 2027 to 2028. Until a participant channel is live, the dependable basis is the account holder's own explicit consent under the PDPA, and we build the session-level integration now so it can move onto the Your Data channel as SCB exposes it.

How do PromptPay transfers appear versus ordinary SCB transfers in the history?

They arrive as distinct transfer types. A PromptPay send, an SCB-internal transfer and an interbank (ORFT) transfer each carry different reference fields and rails in the feed. We normalize them to one transaction schema so a downstream system reads a single, consistent record regardless of how the money moved.

What is the legal footing for reading a customer's SCB EASY history?

Thailand's PDPA treats financial information as sensitive personal data, so the account holder's explicit, recorded consent is required before anything is collected. That consent is revocable at any time, retention is time-bound, and we keep consent and access logs. The work runs against a consenting account, never around the customer's authorization.

When SCB ships an app update, does the integration break?

Releases that reshuffle the home screen rarely touch the data shapes, but they can. We ship a checked-in contract test that flags when a statement or transfer field changes, so a SCB EASY update surfaces as a failing test rather than a silent gap. Initial builds run one to two weeks.

Pricing starts at $300 for source-code delivery — the runnable client, the protocol and auth-flow report, the OpenAPI spec, the tests and interface docs — and you pay only after we hand it over and you have checked it works. Prefer not to run anything yourself? The same SCB EASY surfaces are available as a hosted API you call and pay per request, with nothing upfront. Either way the build is a one-to-two-week cycle. Tell us which surfaces you need at /contact.html and we will scope it.