Pulling balances, pockets and the Cloud Chat ledger out of MAKE by KBank

One MAKE account splits into an unlimited set of Cloud Pockets, and almost every transfer, top-up or QR receipt lands in a per-contact thread the app calls Cloud Chat. That shape — a single e-Savings balance carved into named, goal-bearing sub-pockets sitting on top of a chat-format ledger — is the thing an integrator is actually after, and it is where this brief spends its time. MAKE is built by KBTG for Kasikornbank and, per its Google Play listing, ships under the package com.kasikornbank.makebykbank; it is reported at more than 2.5 million users.

Bottom line: MAKE keeps real per-user structure, not a flat balance, so the value is in mapping the pocket model and the ledger cleanly rather than scraping a number off a screen. The route we would run today is authorized interface integration against an account the holder consents to share, capturing the JSON its own screens consume. When the Bank of Thailand’s deposit-data phase opens for KBank, the same pipeline moves onto the regulated consent channel with little rework.

The data behind the pockets

These are MAKE’s real surfaces, named the way the app names them. Granularity below is what we have seen the screens render; exact field names are confirmed during the build.

Reading a session: pockets and the Cloud Chat ledger

The two calls that matter are the pocket list behind the home screen and the per-pocket Cloud Chat ledger. Sketch below; shapes are illustrative and get pinned down against a consenting account during the build, not lifted from any published document.

# Illustrative. Authorized session from a consenting MAKE account;
# token taken after the holder's own K PLUS / ATM identity binding.

POST /auth/session/refresh
  body: { device_id, refresh_token }
  -> { access_token, expires_in }            # short TTL; drives the sync cadence

GET /pockets                                  # the Cloud Pocket list
  auth: Bearer <access_token>
  -> [ { pocket_id,
         type: "classic|wishlist|saving|credit_card",
         name, balance_thb, goal_thb, locked, shared } ]

GET /pockets/{id}/chat                         # Cloud Chat ledger for one pocket / contact
  -> { items: [ { txn_id, ts, direction,       # direction: in | out
                  amount_thb, counterparty,
                  note, attachment_url } ],
       cursor }                                # backfill via cursor, then poll on token TTL

# Error handling we wire in: 401 -> refresh once; cursor gaps -> re-walk; THB amounts kept in minor units.

What lands in your repository

Every deliverable is tied to the surfaces above, not a generic kit.

• An OpenAPI/Swagger spec covering the pocket list, the Cloud Chat ledger pull and the Expense Summary roll-up, with the auth flow described.
• A protocol and auth-flow report: the session/token chain, refresh behaviour and how the screens request data.
• Runnable source for the key endpoints in Python or Node.js — pocket fetch, ledger backfill with cursor paging, monthly summary.
• A normalized mapping from MAKE’s four pocket types and chat ledger to a single account/transaction shape (see below).
• Automated tests against recorded fixtures, plus interface documentation an engineer can hand to the next person.
• Consent-handling and data-retention guidance for Thai PDPA and the BOT data-sharing regime.

Authorized ways to the data

Three routes genuinely apply to MAKE. Each notes what is reachable, the effort, how durable it is, and what we set up to run it — access is arranged with you during onboarding, against a sponsor sandbox or a consenting account, not a hoop you clear first.

Authorized interface integration of a consenting session

We map the authenticated mobile session of an account the holder agrees to share, then read the JSON its own Cloud Pocket and Cloud Chat screens consume. Reach: the full pocket model and ledger. Effort: moderate. Durability: re-validated when MAKE ships front-end changes. This is the route we would run for MAKE today, because it returns the whole pocket-and-ledger structure now rather than waiting on a phase-in.

Regulated data sharing under BOT “Your Data”

The Bank of Thailand’s consumer-consented data-sharing mechanism reaches deposit, payment and credit-card data through standardized digital channels. Reach (for MAKE): deposit data once the phase opens for KBank. Effort: gated by the rollout calendar. Durability: high, since it is the regulated path. We design the integration so it can adopt this channel as KBank’s deposit phase lands.

Native export as a backstop

Where a consenting user can export Cloud Chat history or an Expense Summary, we ingest that as a fallback for backfill or audit. Reach: historical records only. Effort: low. Durability: depends on what the app offers at the time. Useful as a supplement, not the spine of a live sync.

Thailand’s Your Data rule, and what consent means here

MAKE is a Thai deposit product, so the relevant frame is the Bank of Thailand, not a generic PSD2 reference. On 30 October 2025 the BOT enacted a regulation giving consumers and businesses the right to share personal financial data — deposit, loan, payment, e-money and credit-card information — with other supervised providers through standardized digital channels. Per the BOT, individual deposit-account sharing starts by the end of 2026, with other categories phased across 2027 and 2028. An earlier piece, dStatement, has supported bank-to-bank statement exchange since January 2022.

What that means in practice: today the dependable basis for reaching MAKE’s data is the account holder’s own authorization, and the regulated Your Data channel is where the deposit route opens for KBank from late 2026 — described here as where the rule is going, not as already in force for this app. Either way we operate the same way: scoped consent for named data only, an expiry and revocation path, data minimized to the fields a use case needs, consent and access logged, and an NDA where the engagement calls for one. Thailand’s PDPA governs the personal data throughout.

Engineering notes we account for on a MAKE build

• Pocket-type semantics. The four Cloud Pocket types behave differently — Classic runs budget windows, Wishlist auto-calculates a monthly target, Saving counts streaks and can hide its balance, Credit Card schedules payment reminders. We model each so a downstream “balance” is not flattened across types that mean different things.
• Identity binding stays with the user. MAKE onboarding verifies through K PLUS or a KBank ATM with a national ID card. We build against an already-verified, consenting account and capture the post-login session; the verification step itself is the holder’s, arranged with you during onboarding.
• Shared pockets need per-member resolution. Owner-and-member contributions and the money/withdrawal requests in a shared pocket are split out so group reconciliation does not double-count a single transfer.
• Session TTL drives the sync. The access token is short-lived, so we design the cadence around its refresh window and build a re-validation pass for when the app front end shifts, rather than letting a pull silently expire.
• Bilingual, THB-native fields. MAKE renders Thai and English labels and Baht amounts; we normalize currency to minor units and keep both label languages so nothing is lost in mapping.

Where teams plug this in

• A personal-finance aggregator that wants MAKE’s Cloud Pockets to appear as envelopes beside a user’s other Thai accounts.
• A consent-based underwriting flow reading the Cloud Chat ledger as cash-flow evidence ahead of the Your Data deposit phase.
• An accounting or household tool reconciling shared-pocket contributions across members each month.
• A savings-coaching product tracking goal progress from Wishlist and Saving pockets.

A normalized shape for pockets and transactions

We collapse MAKE’s types and ledger into one account/transaction model so downstream code does not special-case the app:

{
  "account":     { "provider": "make_by_kbank", "currency": "THB" },
  "pocket":      { "id": "...", "kind": "wishlist",
                   "balance_minor": 0, "goal_minor": 0,
                   "locked": false, "shared_members": [] },
  "transaction": { "id": "...", "ts": "2026-06-25T09:00:00+07:00",
                   "amount_minor": 0, "direction": "in|out",
                   "counterparty": "...", "category": "...",
                   "note": "...", "source": "cloud_chat" }
}

Screens we work from

Public store imagery of MAKE, used to anchor the surface mapping. Tap to enlarge.

The Thai money-app neighbourhood

Same-category apps an aggregator usually has to sit MAKE alongside. Listed for ecosystem context, not ranked.

• K PLUS — Kasikornbank’s flagship app; full account, transfer and payment records.
• SCB EASY — Siam Commercial Bank’s app; accounts, cards and transfers.
• Krungthai NEXT — Krungthai Bank’s app; PromptPay transfers and account data.
• Bualuang mBanking — Bangkok Bank’s app; account balances and payments.
• MyMo by GSB — Government Savings Bank app; deposits, income/expense tags and MyFund investing.
• LINE BK — social banking inside LINE; savings, debit and a credit line.
• TrueMoney Wallet — e-wallet; balances, top-ups, bill pay and small loans.
• Rabbit LINE Pay — wallet within LINE; payments and transit.
• Dime! — investing app pairing savings with Thai and US stocks, gold and funds.

Sourcing and review

We read MAKE’s own feature pages and store listing for its surfaces, then checked the Thai regulatory timeline against the Bank of Thailand’s primary releases on 25 June 2026. Citations open in a new tab.

• BOT — Your Data data-sharing regulation (enacted 30 Oct 2025)
• BOT — Open Data programme overview
• MAKE by KBank — Cloud Pocket feature page
• MAKE by KBank — App Store listing

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

Questions integrators ask about MAKE

What does MAKE hold beyond a single account balance?

Quite a lot. One MAKE account splits into unlimited Cloud Pockets across four types (Classic, Wishlist, Saving, Credit Card), each with its own balance, goal and lock state. Transfers, top-ups, bill payments and QR receipts are recorded in Cloud Chat as a per-contact thread with amounts, timestamps, notes and attachments, and Expense Summary rolls those up by month and custom category. That structure, not just a headline balance, is what an integrator works with.

Does Thailand’s Your Data rule already cover MAKE?

Not for deposit data yet. The Bank of Thailand enacted its Your Data regulation on 30 October 2025, with individual deposit-account sharing scheduled to start by the end of 2026 and other categories phased in across 2027 and 2028. Until that deposit phase is live for KBank, the dependable basis is the account holder’s own consent, which is the route we build against today and migrate onto the regulated channel as it opens.

How is MAKE’s K PLUS or ATM identity check handled in a build?

The account holder completes that step. MAKE onboarding verifies identity through the K PLUS app or at a KBank ATM with a national ID card; we work against an account that is already verified and consenting, capturing the post-login session and the data its screens consume. We do not touch the identity-verification step itself.

Can shared Cloud Pocket contributions be reconciled per member?

Yes. Shared Cloud Pockets let an owner invite others to save together and exchange money requests and withdrawal requests. We resolve contributions and requests per member so a group or household pocket reconciles correctly instead of collapsing into one undifferentiated balance.

Working with us

Most MAKE builds wrap inside one to two weeks. Take it as source you own — runnable endpoints for the pocket list and the Cloud Chat pull, an OpenAPI spec, automated tests and interface docs — for $300 and up, paid only after delivery once you are satisfied with it; or skip hosting entirely and call our endpoints, paying per call with nothing up front. You bring the app name and what you want from its data; access, sandbox and compliance paperwork are arranged with you as part of the work. Tell us what you are building at /contact.html and we will scope the MAKE integration from there.