Reaching account, loan and lottery records inside BAAC Mobile

On 30 October 2025 the Bank of Thailand enacted a regulation letting consumers and businesses share deposit, loan and payment data held by BOT-supervised providers with another provider of their choosing — the framework it calls Your Data (per the BOT news release of 10 November 2025). BAAC is one of those supervised banks, and almost everything a farmer touches in BAAC Mobile — a deposit balance, a revolving-credit drawdown, a PromptPay transfer — falls inside that defined scope. That regulatory shift is the cleanest reason to start an integration here now, and it is where we anchor the work.

BAAC sits apart from the big retail banks. It is the government's lending arm for agriculture, so the app carries surfaces the commercial apps do not: a BAAC savings-lottery ledger, revolving farm-credit lines, and a credit-health check run with the National Credit Information Company (per BIIA reporting on the BAAC–NCB tie-up). A connector built for K PLUS or SCB EASY will miss those. The route we recommend leans on the consented Your Data channel as the durable basis, with authorized protocol analysis of the app's own traffic where the live channel has not reached a given record yet — more on the trade-off below.

How Thai rules let this data move

The dependable basis is the customer's own consent. Thailand's Personal Data Protection Act (PDPA, B.E. 2562) requires clear, purpose-bound consent before financial records are shared, and the BOT's Your Data regulation puts a supervised mechanism on top of that for deposit, loan and payment data specifically. The customer authorizes the share, names the purpose, and can revoke it; we build the integration to honor scope and expiry rather than treat a grant as permanent.

Practically, the Your Data feed is new and phasing in across institutions, so live coverage for any one BAAC record is something we confirm during the build rather than assume. Where the regulated channel is not yet serving a surface, the same data is reached through authorized analysis of the app's traffic against a consenting account. Both paths keep the same posture: access is authorized and logged, the data set is minimized to what the purpose needs, and consent records are retained. We work under NDA where the engagement calls for it.

What the app actually holds

Routes to the data

Consented Your Data feed (BOT)

Reachable: deposit, loan and payment records named in the regulation. Durability is high — it is a supervised, consent-backed channel meant to persist. Effort sits in onboarding to the scheme and handling the consent lifecycle. We arrange that access with you as part of the project. The caveat is timing: the mechanism is mid-rollout, so a given BAAC surface may not be live on day one.

Authorized protocol analysis of the app channel

Reachable: whatever the app itself shows — including BAAC-specific surfaces like the lottery ledger and revolving credit that a generic feed may not carry. We study the request and response traffic against a consenting account, document the auth and session model, and reimplement the calls. Durability is medium: the app updates its front end, so we wire periodic re-validation into maintenance. This is the route that covers the gaps the regulated feed leaves.

Native statement export

Reachable: up to 12 months of history through the app's email-statement feature. It is a useful backfill for historical reconciliation, not a real-time source. We parse and normalize those files into the same schema as the other routes.

For most BAAC engagements the consented feed carries the everyday account and payment records, while protocol analysis fills the agricultural surfaces the feed does not yet reach and the email export seeds history. We confirm which surface comes from which channel during the build rather than promising it upfront.

A worked example

Illustrative only — exact field names and the auth handshake are confirmed against a consenting account during the build. This sketches a consent-scoped balance-and-movement pull normalized into one shape.

POST /consent/grant            # customer authorizes scope under PDPA + Your Data
{
  "subject": "consenting-account",
  "scope": ["deposit:balance", "deposit:movement", "loan:balance"],
  "purpose": "accounting-sync",
  "expiry": "2026-12-31"
}
-> 200 { "consent_id": "...", "access_token": "...", "expires_in": 3600 }

GET /accounts?token=...         # device/phone-bound session, per app's anti-spoofing model
-> [ { "acct_id": "...", "type": "savings", "balance": 18250.00, "ccy": "THB" } ]

GET /accounts/{id}/movement?from=2026-01-01&token=...
-> [ { "ts": "2026-06-12T09:21:00+07:00",
       "amount": -500.00, "kind": "promptpay_transfer",
       "eslip_ref": "MINIQR:..." } ]

# normalized record we emit
{ "account": "...", "posted": "2026-06-12",
  "amount_thb": -500.00, "channel": "promptpay",
  "proof": "eslip_ref", "source": "your_data|app_channel" }

# on 401 / consent_expired -> refresh against stored consent, never silently retry past expiry

What you get

Each deliverable is tied to a real BAAC surface, not a template:

• An OpenAPI/Swagger spec covering balances, movement, loan facilities, lottery holdings and PromptPay as normalized resources.
• A protocol and auth-flow report: the token/consent chain, the device-and-phone session binding, and how e-Slip references attach to transactions.
• Runnable source for the key endpoints in Python or Node.js, including the consent-refresh and statement-parsing paths.
• Automated tests against recorded fixtures, including consent-expiry and 401 handling.
• Interface documentation plus data-retention and consent-logging guidance aligned to PDPA.

Engineering notes we account for

• The historical statement is emailed, not served on screen, so we treat statement backfill as a separate parsing job and reconcile it against the live movement feed to avoid duplicate postings.
• BAAC's savings lottery is its own asset class. We model lottery principal and prize credits as distinct records so a balance roll-up does not silently merge them with ordinary deposits.
• The app binds a session to a registered device and phone number and uses facial verification for PIN reset. We design session handling around that binding so a sync does not trip the anti-spoofing checks, and arrange the consenting test account with you during onboarding.
• Revolving farm credit behaves differently from a term loan — balance and available limit both move. We map drawdowns and repayments so the facility's remaining headroom stays correct.
• Because Your Data is rolling out, we design the sync to fall back cleanly between the regulated feed and the app channel per surface, and re-validate when the app front end changes.

Where teams use this

• An agri-lender pulling a BAAC borrower's deposit movement and revolving-credit position, with consent, to assess repayment capacity.
• An accounting tool reconciling a cooperative's BAAC transactions using e-Slip references as proof.
• A personal-finance app folding BAAC deposits and lottery holdings into one net-worth view alongside other Thai bank accounts.

App screens referenced

Related Thai banking apps

The same consent-based approach applies across Thailand's mobile-banking field, which widens what a unified integration can cover:

• K PLUS (Kasikornbank) — deposits, transfers and QR payments for one of the country's largest retail bases.
• SCB EASY (Siam Commercial Bank) — multi-account management and fee-free domestic transfers.
• Krungthai NEXT (Krungthai Bank) — retail banking with heavy government-transaction use.
• Bualuang mBanking (Bangkok Bank) — retail and cross-border services with English support.
• KMA — Krungsri Mobile App (Bank of Ayudhya) — consumer-finance, cards and loan data.
• ttb touch (TMBThanachart) — accounts, cards and lending in one app.
• MyMo by GSB (Government Savings Bank) — the closest peer to BAAC as a state retail bank.
• Make by KBank — a goal-and-cloud-pocket savings app from Kasikornbank.

Sources and how this was put together

This mapping was checked in June 2026 against the app's own listing and Thai regulatory sources. Surfaces are read from the BAAC Mobile store description; the data-sharing regime is read from the Bank of Thailand's own publications. Primary references:

• BOT news release on the Your Data right-to-share regulation (Nov 2025)
• BOT — Project Your Data (open-data programme)
• BAAC Mobile on Google Play (com.baac.amobileplus)
• Bank for Agriculture and Agricultural Cooperatives — official site

OpenBanking Studio integration desk · mapping reviewed June 2026.

FAQ

Does Thailand's Your Data regulation cover the accounts inside BAAC Mobile?

Yes. The Bank of Thailand's Your Data regulation, enacted in late October 2025, names deposit-account, loan and payment data held by BOT-supervised providers as the records a customer can ask to be shared. BAAC is a state-owned bank under that supervision, so the deposit balances, loan balances and PromptPay activity a farmer sees in BAAC Mobile sit within scope. The mechanism is still rolling out, so we also build against a consenting account where the live channel is not yet open.

Can you pull the savings-lottery (salak om sap) holdings and prize history?

That surface is specific to BAAC and is one reason a generic Thai-bank connector will not fit. The app exposes lottery deposits and a win-checking history; we map both as their own structured records, separate from ordinary deposits, so a portfolio view treats lottery principal and prize credits correctly rather than folding them into a single balance.

How do you handle the 12-month statement that BAAC Mobile only emails?

In-app, the historical statement is delivered as an emailed file rather than an on-screen feed. We normalize whichever channel the engagement uses, the consented Your Data feed or the authorized in-app movement list, into one dated transaction schema with e-Slip references, so you get a queryable history instead of a PDF in an inbox.

What about the e-KYC and face-reset device binding when keeping the integration alive?

BAAC Mobile binds a session to a registered device and phone number and uses facial verification for PIN reset. We design the auth and session-refresh handling around that binding so a sync does not trip the anti-spoofing checks, and we re-validate the flow when the app updates its front end.

Two ways to close: we deliver runnable source for the BAAC surfaces you name — the OpenAPI spec, the protocol report, working endpoints in Python or Node.js, tests and docs — from $300, billed only after delivery once you are satisfied; or you skip the build and call our hosted endpoints, paying per call with no upfront fee. Either way the cycle runs one to two weeks. Tell us the app and what you need from its data, and we arrange the access and compliance with you. Start at /contact.html.