Reaching a MoneyThunder borrower's loan and repayment records

Every MoneyThunder borrower sits behind an OTP login with two live products under it — a Personal Loan with a limit up to THB 1,000,000 and a Nano Finance line up to THB 100,000, per the app's own Play listing. The interesting server-side records are the loan ledger those products generate: outstanding principal, a daily interest accrual, and a per-installment repayment plan. None of it leaves the phone on its own. Consent is the lever that moves it.

My read, up front: for anything an integrator needs this year, the working route is a PDPA-consented read of the borrower's own session. The app already holds a complete, contract-accurate ledger — the job is reaching it under authorization and normalizing it, not reconstructing it. Thailand's dStatement service and the BOT Open Data timetable matter for later, once loan records enter the scheme, but they don't cover this app's data today. So the build is consent plus interface work now, with a clean path to swap in the regulated feed when loan data lands in it.

The loan ledger MoneyThunder keeps for each borrower

These are the surfaces a MoneyThunder account actually exposes to its own user, mapped to what an integrator would build on. Amounts and terms below come from the app's published product description.

Getting at that data with the borrower's consent

Three routes genuinely apply to this app. They are not equal, so I'll say which one carries the work.

1. PDPA-consented interface integration

The borrower authorizes, and we read the same loan, schedule and payment surfaces the app itself renders — over its mobile session, with token handling as the app uses it. Reachable: the whole ledger above. Effort: moderate, mostly in mapping two product structures cleanly. Durability: good between app releases, with a monitored check for when field names move. Access is arranged with the client as the project starts, against a consenting account — it isn't something you assemble before we begin.

2. Native e-statement / contract export

MoneyThunder can produce statement and contract documents. Where a workflow only needs periodic history rather than live balances, parsing that export is the lowest-touch option. Reachable: settled history, not this-second balances. Effort: low. It pairs well with route 1 as a reconciliation source.

3. BOT Open Data / dStatement, as it opens up

Thailand's regulated data-sharing channel is live for bank statements and expanding on a published schedule. Loan and payment data are slated for the 2027-2028 phase per the BOT. When that lands, a MoneyThunder loan record becomes reachable through a standardized, consent-based feed rather than the app session. Reachable now: nothing for this app's loan data; reachable later: potentially the core ledger. We design route 1 so this can slot in behind the same normalized schema.

For a project starting today, route 1 is the one that returns the ledger, with route 2 filling in history and route 3 kept in view as the regulated feed matures. That ordering is specific to MoneyThunder because its data is loan data — the exact category still a year or two from the Open Data timetable.

What a session read and a loan-account call look like

Shapes below are illustrative — endpoint paths and field names get pinned during the build against a consenting account, not copied from any MoneyThunder document. The installment figures mirror the worked Nano Finance example in the app's own listing, so the accrual math is grounded.

# 1) Authenticate the borrower's own session (OTP + Thai national ID bound)
POST /auth/otp/verify
     { "national_id": "3-1012-#####-##-#", "msisdn": "+66########", "otp": "######" }
  -> { "access_token": "eyJ...", "refresh_token": "...", "expires_in": 900 }

# 2) Both product lines under one borrower
GET  /loan/accounts            Authorization: Bearer eyJ...
  -> { "accounts": [
         { "product": "personal_loan", "credit_limit_thb": 1000000,
           "outstanding_principal": 148230.55, "apr": 24.0, "structure": "revolving" },
         { "product": "nano_finance",  "credit_limit_thb": 100000,
           "outstanding_principal": 9257.11,  "apr": 33.0, "structure": "term" } ] }

# 3) Installment schedule for a term loan
GET  /loan/{account_id}/schedule
  -> { "due_day": 28,
       "installments": [
         { "seq": 1, "due": "2022-01-28", "principal": 742.89,
           "interest": 244.11, "balance_after": 9257.11 }, ... ] }

# 401 -> refresh with refresh_token; back off on 429; re-pin fields on app update.

The reconstruction that earns its keep is the interest engine: balance times 33% times days over 365, applied per due day, so a computed schedule reconciles to the app's own statement figures. Two structures share the code path. Revolving credit accrues on the drawn balance with a THB 200 minimum; the term loan amortizes across a 12-to-60-month tenor.

What lands in your repository

• An OpenAPI/Swagger specification covering the loan-account, schedule, payment-history and statement surfaces, with the two-product model made explicit.
• A protocol and auth-flow report: the OTP session, token lifetime and refresh chain, and how the app scopes a borrower's data.
• Runnable source for the key reads in Python and Node.js — session, account list, schedule pull, payment history — with the actual/365 accrual reconstructed and unit-tested against the app's published example.
• Automated tests, including a fixture that checks a rebuilt schedule to the satang.
• Interface documentation an in-house team can extend, plus PDPA-oriented notes on consent capture, logging and data retention.

Consent, the PDPA, and where BOT's Open Data is heading

MoneyThunder describes itself as supervised by the Bank of Thailand and governed by the PDPA. Both hold here. Consumer-credit licensing for nano finance and personal loans runs through the Ministry of Finance and the BOT, and the nano-finance limit of THB 100,000 per borrower is a regulatory cap, not a product choice.

The dependable basis for access is the borrower's own PDPA consent — specific, revocable, and logged. We scope it to the loan records a project needs, keep consent and access records, minimize retained fields, and work under an NDA where the client requires one. On the regulated side, the BOT launched dStatement for bank-statement portability in January 2022, and in November 2025 enacted a regulation letting consumers and businesses exercise their right to share data held by financial providers. Deposit data sharing is set to begin around late 2026, with loan and payment data following across 2027-2028 per the BOT's own timeline. That last phase is the one that eventually reaches an app like MoneyThunder; until then, consent is the mechanism, and the integration is built to move onto the regulated feed without a rewrite.

What the build has to get right for a Thai nano-finance lender

MoneyThunder's two-product, daily-accrual model is where an integration quietly goes wrong, so the design starts there. The studio carries each of these; none is something a client hands over as a condition.

• One borrower can hold a revolving Personal Loan and a term Nano Finance loan at once, and the two accrue and repay by different rules — 2% minimum on drawn balance versus a fixed installment across a set tenor. We normalize both into a single schema that keeps structure, APR and limit per account, so downstream code never has to branch on which product it received.
• Interest is a daily actual/365 accrual, and the app's statements are exact to the satang. We reproduce that accrual rather than approximating it, so a payoff figure we return matches what the borrower sees. A rounding shortcut here quietly desyncs every balance.
• Sessions are short-lived and OTP-bound to a Thai national ID. We design the sync around token refresh and the consent window so a pull doesn't silently expire mid-run, and access is set up with the client during onboarding against a consenting account.
• When ABACUS ships an app update, field names can shift. A small replay harness watches the live shapes and flags a broken read before it reaches your pipeline, rather than letting stale data through.

Pricing, and how a project runs

Source lands in your repository, and you pay for it after it is delivered and working. The first shape is source-code delivery from $300: runnable API source for the MoneyThunder surfaces above, plus the spec, tests and interface docs, paid once you have it in hand and are satisfied. The alternative is a pay-per-call hosted API — we run the endpoints, you call them and pay only for calls, with no upfront fee. Either way the cycle is one to two weeks. You give us the app name and what you want out of its data; access and the compliance paperwork are arranged with you as part of the work. Start the conversation at /contact.html.

Where integrators point this data

• A lender underwriting a repeat applicant reads the consented MoneyThunder repayment history and current exposure, instead of relying on a self-reported figure.
• A personal-finance app folds a user's outstanding principal and next due date into one debt view alongside their other accounts.
• A servicing or collections platform reconciles payments against the app's own ledger, catching an arrears state the day it forms.

Screens from the listing

Store screenshots, for interface reference. Select one to enlarge.

Other Thai lending apps in the same integration picture

Same category, same normalized target if you are unifying several lenders. Named for keyword and ecosystem context, in no order of preference.

• FINNIX — a nano-finance app by MONIX Co., Ltd. that underwrites on alternative data; loan ledger and repayment schedule map closely to MoneyThunder's.
• Good Money — a Government Savings Bank and Mambu venture offering personal loans and nano finance to underserved borrowers.
• LINE BK — social banking inside LINE, with a consumer credit line whose balance and repayment records sit behind the same consent question.
• KTC — Krungthai Card's personal loans and credit cards, with statements and installment plans up to 60-month terms.
• Credit OK — alternative lending to individuals and small merchants, holding drawdown and repayment history.
• TrueMoney — Ascend Money's wallet under the CP Group, with lending features layered on a payments ledger.
• Siam Digital Lending — personal loan and nano-finance products with fast approval and per-installment schedules.
• Noburo — workplace welfare lending, holding employee loan balances and payroll-linked repayments.
• MoneyTable — consumer alternative lending with account balances and installment records.

Questions integrators ask about MoneyThunder

Is MoneyThunder's loan data already covered by dStatement or BOT Open Data?

Not yet. dStatement moves bank statements between banks, and the BOT Open Data scheme starts with personal deposit data around late 2026, with loan and payment data phased in over 2027-2028 per the BOT. A MoneyThunder loan ledger sits outside the live scheme today, so the near-term route is a PDPA-consented read of the borrower's own account.

How do you tell the Personal Loan apart from the Nano Finance line for one borrower?

Both products live under a single OTP login, so we key on the per-account product type and terms — a revolving Personal Loan up to THB 1,000,000 versus a Nano Finance term loan up to THB 100,000 per the app's own listing — and normalize them into one schema that carries the structure, APR and limit for each.

Can you extract the full installment schedule, not just the current balance?

Yes. The term-loan detail exposes each due date with its principal and interest split and the remaining balance, mirroring the worked example in the app's own listing; we reconstruct the actual/365 daily accrual so payoff figures match the app to the satang.

How is PDPA consent handled when you pull this data?

Access runs on the borrower's own consent, scoped to the loan records requested, with consent and access logged and the data minimized to what the integration needs. Consent scope, expiry and revocation are wired into the sync so a withdrawn consent stops the pull.

What I checked, and when

I read MoneyThunder's Play Store product description for its two loan products, limits, APRs and the worked repayment example; the Bank of Thailand's Open Data and dStatement pages for the consent model and the phased schedule; and the BOT's November 2025 news release on the new data-sharing right. Figures and terms on this page are attributed to those sources rather than assumed. Reviewed by the OpenBanking Studio integration desk, July 2026.

• Bank of Thailand — Open Data initiative
• Bank of Thailand — dStatement (Digital Bank Statement)
• BOT news — right to share financial data (Nov 2025)
• MoneyThunder on Google Play (com.scbabacus.l2020)