Reaching MyMo by GSB account records under Thai consent rules

Government Savings Bank's MyMo carries the full retail-banking ledger of a Thai GSB account — balances, every transfer, each bill and loan repayment, MyFund holdings and Digital Salak certificates — behind one device-bound login. That ledger is what a payroll system, an accounting tool or a lender wants to read, and the timing matters: the Bank of Thailand's Your Data consent rail is due to let individuals start sharing banking data in the second half of 2026, right as this is written. So the integration question for MyMo is less about whether the records exist and more about which consented route reaches them cleanly.

Routes to the data, and the one we would take

Three routes genuinely apply to MyMo. They are not equal, and the choice depends on how long you need the feed to last.

Consent-based account information (Your Data / PDPA)

With the account holder's explicit consent, MyMo's balances and history are read as account-information data. Under Thailand's PDPA this is the documented, revocable basis available right now; the Bank of Thailand's Your Data programme is standardising it into a national consent mechanism, with individual sharing expected from the second half of 2026 per the central bank. Effort is moderate, durability is high, and we set up the consent capture and records as part of the work.

Authorized interface integration (protocol analysis)

For data that the consent rail does not yet expose, we analyse MyMo's own client traffic under the customer's authorization — the login and token-refresh chain, the statement and transfer calls, the e-Slip verification flow — and rebuild those as a documented client. This reaches whatever the app itself reaches. It needs more maintenance, since a MyMo release can move a screen, and we account for that in the build.

User-consented credential access

Where a person wants their own data pulled, a consented session against their account covers the same surfaces with the lightest setup. It is the quickest to stand up and the right fit for one-off exports or a single user's reconciliation.

For most MyMo projects we would start on a consenting GSB account through protocol analysis to get a working read of balances and history quickly, then shift the same integration onto the Your Data consent rail as it opens through late 2026 — that keeps the feed on a basis the account holder can revoke and Thai regulators recognise, without waiting on the rail to ship before you have anything usable.

What sits behind a MyMo login

These are the surfaces MyMo actually presents to a signed-in user, mapped to what an integrator does with each.

The build you receive

Every engagement ends in code you can run, not a report. For MyMo that means:

• An OpenAPI/Swagger spec describing the account, transaction-history, transfer and e-Slip surfaces as clean endpoints.
• A protocol and auth-flow report covering the login, the bearer-token refresh and the device-binding handshake MyMo uses.
• Runnable source for the key reads — balance, dated statement, transfer list, e-Slip verify — in Python or Node.js, whichever you build on.
• Automated tests against recorded responses, including the token-expiry and retry paths.
• Interface documentation plus consent-capture and data-retention guidance aligned to the PDPA.

Each deliverable maps to a real MyMo surface; nothing here is a generic banking template with the name changed.

A statement pull, sketched

Illustrative shape of the read path — exact field names are confirmed during the build against a consenting account.

# Refresh the session: MyMo binds the token to the registered device.
POST /mymo/session/refresh
  headers: { Authorization: Bearer <access_token>, X-Device-Id: <bound_device> }
  -> 200 { access_token, expires_in: 900 }

# Dated statement for one account.
GET /mymo/accounts/{accountId}/transactions?from=2026-05-01&to=2026-05-31
  headers: { Authorization: Bearer <access_token> }
  -> 200 {
       account: { id, balance: 18450.27, currency: "THB" },   # illustrative figures
       items: [
         { ref, postedAt, type: "TRANSFER_OUT",
           amount: -500.00,
           counterpartyAlias: "08xxxxxxxx",   # PromptPay phone alias
           tag: "#rent",                        # user-entered, may be absent
           eslip: { qr, verified: true } },
         ...
       ],
       nextCursor
     }

# 401 -> token expired: refresh once, retry, then surface to the caller.

Consent, the PDPA, and Your Data

Thailand's Personal Data Protection Act classes financial information as sensitive personal data, which means explicit, informed and withdrawable consent from the account holder is the basis any MyMo read stands on — and the regulator has teeth, with the PDPC issuing its first major fines in August 2025 per reporting. That consent is the dependable footing today. The Bank of Thailand's Your Data project, announced in October 2024, is building the national consent rail on top of it: a standard way for a person to authorise moving their banking data to a provider of their choice, with individual sharing expected to begin in the second half of 2026 according to the central bank. We treat PDPA consent as the present-day basis and Your Data as the rail to migrate onto as it goes live — not as something already settled. In practice we capture consent with scope and expiry, log every pull against a consent reference, minimise stored fields to what you actually use, and work under an NDA where the data warrants it.

What we plan around on MyMo

Access to a consenting account or a sandbox is arranged with you at the start of the project — it is something we handle together, not a hurdle you clear before we begin. A few app-specific things shape how the build is engineered:

Device binding and Secure Plus

MyMo ties a session to one registered device, and the Secure Plus option — added in 2024 per GSB's own reporting — blocks third-party transfers by default for accounts that turn it on. We scope the integration as read-only consented access, so it reads balances and history without touching the transfer paths Secure Plus guards. The two never collide.

User-entered annotations

The #Tag labels and e-Slip notes are entered by hand and often missing. We treat them as optional fields, normalise the e-Slip QR proof into a stable object, and keep every transaction whether or not it carries a tag.

PromptPay alias resolution

Transfers reference phone numbers and PromptPay IDs rather than raw account numbers. We map each alias to a consistent internal key so repeated payees line up across the history and reconcile against PromptPay records.

App-update drift

GSB ships MyMo updates regularly. When one moves the statement or history screen, a scheduled re-validation run catches the change before the feed drifts, and the fix folds into maintenance.

Keeping the feed honest

Balances and the transaction list change in real time, so the integration polls on a schedule you set or refreshes on demand. e-Slip proofs are immutable once issued, so they cache safely. We add retry-and-backoff around the session refresh and timestamp every consented pull against its consent reference, so a missed sync shows up rather than passing silently.

Working with us

Source for the MyMo statement and transfer reads, with its tests and docs, lands in one to two weeks once there is a consenting account or sandbox to build against. You can take the work as a one-off source-code delivery starting at $300 — you get the runnable code, the OpenAPI spec, the auth-flow report, the tests and the interface docs, and you pay only after delivery, once it runs to your satisfaction. If you would rather not host anything, call our endpoints on a pay-per-call basis instead: no upfront fee, billing only for the calls you make. Tell us the account data you need from MyMo and we will scope it — start a project.

Screens we worked from

Store screenshots of MyMo used while mapping the surfaces above. Select to enlarge.

Other Thai banking apps in the same picture

If MyMo is one account in a wider sync, these neighbouring Thai apps come up constantly — named here for context, not ranked.

• K PLUS (Kasikornbank) — holds balances, PromptPay transfers and QR payments for one of Thailand's largest retail bases.
• SCB EASY (Siam Commercial Bank) — accounts, transfers, bill pay, lending and investments in a single app ledger.
• Krungthai NEXT (Krungthai Bank) — retail accounts plus the government-payment flows many residents rely on.
• Bualuang mBanking (Bangkok Bank) — accounts and a strong cross-border transfer story.
• TTB Touch (TMBThanachart) — accounts, cards and mutual-fund holdings together.
• Krungsri Mobile App (KMA) (Bank of Ayudhya) — accounts, transfers and in-app investments.
• Make by KBank — pocket-based money management running on Kasikornbank rails.
• TrueMoney Wallet — an e-wallet balance with top-ups and bill payment rather than a bank account.

Questions integrators ask about MyMo

Does MyMo's Secure Plus mode stop a consented data feed?

Secure Plus restricts outbound third-party transfers for accounts that switch it on; it is a payment guard, not a read block. A read-only consented integration that only queries balances and history sits alongside it, and we design the build that way so enabling Secure Plus never breaks the feed.

How do you handle the hashtag notes users add to MyMo transactions?

The #Tag labels and e-Slip notes are free text a user attaches per transaction, so they are optional and inconsistent. We carry them through as a separate metadata field, keep transactions that have no tag, and leave categorization rules to your side rather than guessing them.

Which Thai rules cover pulling data from a GSB account?

Thailand's PDPA classes financial data as sensitive personal data, so explicit, withdrawable consent from the account holder is the working basis today. The Bank of Thailand's Your Data programme adds a national consent rail for moving banking data between providers, with individual data sharing expected to begin in the second half of 2026 per the central bank.

Can you match MyMo transfers back to their PromptPay references?

Yes. Transfers in MyMo carry a payee alias such as a phone number or PromptPay ID plus an amount and timestamp, and the e-Slip gives a verifiable proof object. We normalize the alias, amount and reference into one record so a transfer can be reconciled against a PromptPay payment on your books.

Sources & review

This mapping was put together on 24 June 2026 from GSB's own MyMo page for the feature set, the Bank of Thailand's Your Data announcement and Bangkok Post's reporting for the consent-rail timing, and a PDPA reference for how Thai law treats financial data. Primary sources opened:

• Government Savings Bank — MyMo official feature page
• Bank of Thailand — Project “Your Data” announcement
• Bangkok Post — central bank introduces open banking data initiative
• DLA Piper — Thailand PDPA data-protection reference

Mapped by the OpenBanking Studio integration desk, June 2026.