Getting Cloud Pocket and deposit data out of MAKE by KBank

MAKE's e-savings tier pays 1.35% on the first 500,000 baht and 0.35% on anything above that, per the app's own Play Store description, and interest can be checked daily. Every baht of it sits in a per-user ledger that the account holder slices into Cloud Pockets. That structure — one deposit account, many named pockets, some of them shared with friends — is the thing an integrator actually wants out of MAKE, and it is the thing a generic bank connector gets wrong. This brief is about reaching that data the authorized way, what the studio maps, and what lands in your repository at the end.

The near-term workable path is authorized interface integration: we read the app's own traffic against a consenting account and recover the Cloud Pocket, ledger and summary surfaces directly. We build the connector so it can switch over to the BOT consent channel for deposit data as KBank brings that online, which the regulator has scheduled for the end of 2026. Where neither reaches — archived Cloud Chat threads, a month-by-month Expense Summary export — the app's own look-back covers the gap.

What MAKE actually holds

These are the surfaces named the way the app names them, with where each one originates and what a consumer of the data would do with it.

Pop Pay, the proximity transfer that surfaces a nearby friend inside roughly a ten-metre radius, writes into the same ledger as everything else, so it needs no separate handling. Two things shape the whole model: balances are fragmented across pockets rather than held as one number, and shared pockets mean a single sum can appear in more than one member's view.

Authorized ways into a MAKE account

Three routes apply here. Each is described by what it reaches, how much work it is, how durable it stays, and what we set up to run it with you.

1 · Authorized interface integration (protocol analysis)

We capture and replay the app's own session against an account whose holder has authorized the work, then read Cloud Pockets, the Cloud Chat ledger and Expense Summary as the app itself does. Reach is wide — effectively everything the user sees. Effort is moderate, mostly in the device-bound auth bootstrap. Durability depends on the front end staying stable, which we cover with a re-validation pass (see the engineering notes). Access is arranged with you during onboarding, against a consenting account.

2 · Bank of Thailand "Your Data" consent channel

The BOT enacted its Open Data regulation on 30 October 2025; it lets a customer consent to share deposit, loan and payment data held by a supervised provider with another provider through a standardized digital channel. Deposit-account sharing is scheduled to begin by the end of 2026, with the rest phasing in across 2027 and 2028. This is the durable, regulated path for the deposit and payment surfaces. We wire the consent connector now so the integration can migrate onto it the moment KBank exposes the deposit feed, without re-plumbing your side.

3 · Native look-back and export

MAKE keeps Cloud Chat history with no look-back limit and presents the Expense Summary month by month. For one-off backfills or low-frequency syncs, reading those surfaces under the holder's consent is the lightest option and a useful complement to the live read above.

For a build starting this quarter, route 1 is what moves data immediately, while route 2 is the connector we lay down in parallel so the deposit feed becomes consent-governed as Your Data turns on. Route 3 fills the historical edges neither live path bothers with. That ordering is specific to MAKE's timing: the regulated channel is real but not yet switched on for KBank deposits, so the authorized read carries the work today.

How the session and a pocket pull look

Illustrative shapes, confirmed during the build rather than copied from a published spec. The point is the device-bound auth and the pocket-and-ledger structure, not literal field names.

# MAKE pins identity to a K PLUS confirmation or a KBank ATM ID check,
# so the session token carries a device assertion and is short-lived.
POST /v2/auth/token
  { "device_id": "...", "assertion": "<k-plus-or-atm-derived>",
    "grant": "device_session" }
  -> { "access_token": "...", "refresh_token": "...", "expires_in": 900 }

# List the account's Cloud Pockets (one deposit account -> many pockets)
GET /pockets?include=balance,goal,members
  Authorization: Bearer <access_token>
  -> [ { "pocket_id": "...", "type": "wishlist",
         "goal_amount": 30000, "saved": 18450,
         "shared": true, "member_count": 3, "locked": false }, ... ]

# Pull the chat-format ledger for one pocket / counterparty
GET /pockets/{pocket_id}/ledger?cursor=...   # paginated
  -> entries[] { amount, party, ts, memo, attachment_url }

# Refresh before expiry; do not let the device session lapse mid-sync
POST /v2/auth/refresh  { "refresh_token": "..." }
      

Error handling matters more than the happy path. A lapsed device session returns an auth failure that looks like a permission error, so the client distinguishes "refresh and retry" from "consent revoked, stop" before it loops.

What ships at handover

Everything is tied to the surfaces above, not a generic banking template:

• An OpenAPI 3.1 specification covering the pocket list, per-pocket ledger, Expense Summary and balance endpoints as modelled for MAKE.
• A protocol and auth-flow report documenting the device-bound token exchange, the K PLUS / ATM bootstrap, refresh timing and the revocation signal.
• Runnable source in Python and Node.js for the key calls — pocket enumeration, ledger pagination with attachments, monthly summary pull.
• A normalized schema that maps "one account, many pockets, some shared" onto a parent-account / child-pocket model so balances reconcile and shared funds are not double-counted.
• Automated tests run against a consenting account, plus interface documentation.
• PDPA-aligned data-retention and consent-record guidance for whatever you build on top.

Where consent comes from

Two Thai frameworks govern this, and they are not interchangeable. The PDPA (Personal Data Protection Act B.E. 2562, in force and actively enforced — the PDPC issued its first major administrative fines in 2025) treats financial information as sensitive personal data, which requires explicit, informed consent before it is collected or processed. That consent — the account holder authorizing access to their own MAKE data — is the dependable basis the integration rides on today.

The Bank of Thailand's "Your Data" Open Data regulation is the forward-looking layer. It gives a customer the right to share their deposit and payment data through a standardized channel, but deposit sharing is scheduled to begin only by the end of 2026 and is not yet a live feed to build against. We treat it as where the regulated route is heading, not as something already switched on. In practice the build records consent scope and expiry, supports revocation cleanly, minimizes the fields it reads to what the use case needs, logs every access, and runs under an NDA where the engagement calls for one.

Engineering notes specific to MAKE

Three things about this app shape the build, all of which we handle on our side.

• Device-bound enrolment. MAKE ties access to a K PLUS confirmation or a KBank ATM ID check, and the resulting session is short-lived. We design the bootstrap around that device assertion and the token expiry so the sync refreshes on schedule instead of dropping silently; access to a consenting account is arranged with you during onboarding.
• Shared-pocket accounting. A pocket can belong to several members, so the same balance shows up in more than one account's view. We model membership explicitly and tag shared funds so aggregate figures across a household or a group do not double-count, which a flat statement importer would get wrong.
• Front-end drift and the Your Data switchover. Because route 1 reads the live interface, a UI change can move a field. We build a re-validation pass into maintenance that flags shape changes early, and we keep the BOT consent connector ready so the deposit surface can move onto the regulated channel without a rewrite when KBank turns it on.

Screens we worked from

Public store screenshots used while mapping the pocket, ledger and summary surfaces. Select to enlarge.

Keeping the integration current

Deposit balances and the ledger move continuously; the Expense Summary settles monthly. Our sync polls the live surfaces at a cadence the use case needs and the re-validation pass watches for interface drift between releases. The bigger freshness event for MAKE is regulatory: when the Your Data deposit channel opens, the deposit feed moves from an authorized read to a consent-governed one, and we plan the cutover as part of maintenance rather than a second project.

Where MAKE sits among Thai money apps

Same-category apps a unified data layer would commonly cover alongside MAKE. Named for context, not ranked.

• K PLUS — KBank's flagship mobile bank; holds the full deposit, transfer and bill-payment history that MAKE enrolment often confirms identity against.
• SCB Easy — Siam Commercial Bank's app, with accounts, transfers and QR payments; SCB was an early mover on open APIs in Thailand.
• Krungthai NEXT — Krungthai Bank's app, covering deposits, government-scheme payments and transfers.
• Bualuang mBanking — Bangkok Bank's app; Bangkok Bank runs a public developer portal with API docs and a sandbox.
• TTB Touch — the merged TMB-Thanachart app for transfers, payments and savings products.
• Kept by Krungsri — Krungsri's savings app that splits money into spend and save buckets, a close conceptual neighbour to Cloud Pockets.
• LINE BK — social banking inside the LINE messenger, with savings, a debit card and a credit line.
• Dime! — a Thai savings-and-investing app holding cash and brokerage balances behind one login.

Where these facts come from

Checked in June 2026 against primary sources: the app's own store and product descriptions for the Cloud Pocket types, interest tiering and feature names; the Bank of Thailand for the Open Data regulation, its enactment date and rollout schedule; and Thai data-protection references for the PDPA's treatment of financial data. Deep links below.

• Bank of Thailand — data-sharing regulation, enacted 30 Oct 2025
• Bank of Thailand — Open Data ("Your Data") overview
• MAKE by KBank — official product site (KBTG)
• PDPA B.E. 2562 — Thailand data-protection reference

Mapped by the OpenBanking Studio integration desk · June 2026.

Questions integrators ask about MAKE

Does MAKE's Cloud Pocket structure map onto a normal account model?

One MAKE account splits into unlimited Cloud Pockets, and some pockets are shared with two or more members. We normalize that into a parent account with child pockets, so aggregate and per-pocket balances both reconcile and shared-pocket funds are not double-counted across members.

Is MAKE by KBank data covered by Thailand's Your Data open-data scheme?

As a KBank deposit and payment product, it falls inside the scope of the Bank of Thailand regulation enacted on 30 October 2025. Deposit-account sharing is scheduled to come online by the end of 2026, with loan and payment data following in 2027 to 2028, all gated by the account holder's explicit consent.

How do you read a MAKE account given its K PLUS and ATM identity verification?

MAKE binds enrolment to a K PLUS confirmation or a KBank ATM ID check, so the session is device-bound. We bootstrap against a consenting account, capture the device assertion and short-lived token, and design the refresh loop around its expiry so reads do not silently drop.

Can you reach older Cloud Chat threads and the monthly Expense Summary?

Yes. Cloud Chat stores transaction history per counterparty with no time limit on look-back, and we paginate the ledger including memo and photo attachments; the Expense Summary income-and-expense rollups are pulled as monthly snapshots and folded into the normalized schema.

The end product is source code in your repository, not a slide deck. We deliver the MAKE integration from $300 — runnable Python and Node clients, the OpenAPI spec, the auth-flow report, tests and interface docs — and you pay after delivery, once it runs against your consenting account. If you would rather host nothing, the same endpoints are available as a pay-per-call hosted API with no upfront fee. Tell us the account scope and the surfaces you care about at /contact.html and we scope it into a one-to-two-week cycle.