Reaching the loan ledger inside กู้เงินง่าย ๆ-เงินด่วน รู้ผลไว

A borrower opens this app with nothing but a Thai national-ID card and a phone number, and within minutes the backend is holding a live loan record: an approved credit line between ฿1,500 and ฿90,000, a term of 91 to 180 days, and an interest figure that grows every single day at about 0.05%, per the app's own description. That record — not the marketing around it — is what a third party wants to read. The operator named on the Play listing is WIMUT FAMILY CO., LTD., a Thai pico-finance licensee. This page maps what the account holds and the authorized way to reach it.

There is no single Thai open-banking switch a consumer-lending app like this plugs into; the Bank of Thailand distributes reference data through its own portal, but borrower-level loan records are not part of that feed. So the working route here is authorized protocol analysis of the app's own client-to-server traffic, run with the account holder's consent. The rest of this brief is what that yields and how we build it.

What sits behind a borrower's account

Each row below is a surface the app genuinely exposes to a signed-in user, mapped to where it comes from and what an integrator does with it.

Pulling a current schedule, in code

The shape below is illustrative — exact paths and field names are confirmed against live traffic during the build, not guessed here. It shows the auth step the app's OTP login implies and a ledger read that keeps principal and interest apart.

# Illustrative — endpoints/fields verified during the engagement
POST /api/v1/auth/otp/verify
  { "msisdn": "+66XXXXXXXXX", "otp": "######" }
  -> 200 { "access_token": "…", "expires_in": 3600, "refresh_token": "…" }

GET /api/v1/loans/current
  Authorization: Bearer 
  -> 200 {
       "loan_id": "…",
       "principal_thb": 10000,
       "term_days": 120,
       "daily_rate": 0.0005,          # ~0.05%/day, per the app's worked example
       "accrued_interest_thb": 150,   # grows each day
       "payoff_total_thb": 10600,     # principal + interest at maturity
       "disbursed_on": "2026-0X-0X",
       "status": "active"
     }

# A re-auth that catches an expired session instead of failing silently
def get_schedule(session):
    r = session.get("/api/v1/loans/current")
    if r.status_code == 401:
        session.refresh()              # use refresh_token, then retry
        r = session.get("/api/v1/loans/current")
    r.raise_for_status()
    return normalize(r.json())         # -> principal / interest / payoff split out

What lands in your repo

For this app the handover is built around the loan record, not a generic template:

• An OpenAPI/Swagger spec covering the auth step, the ledger read, and the schedule, with the principal/interest split modelled explicitly.
• A protocol and auth-flow report documenting the OTP login, the token it issues, and how the refresh clock works.
• Runnable source for the key endpoints in Python or Node.js — the session handling, the ledger read, and a normalizer that turns the daily-accrual numbers into clean principal, interest, and payoff fields.
• Automated tests against recorded responses, including the maturity-payoff math and the 401-then-refresh path.
• Interface documentation plus data-retention guidance scoped to PDPA, so what you store matches the consent you collected.

Authorized ways in

Consented protocol analysis of the app traffic

The dependable path. With a consenting account, we observe the client-to-server calls the app makes, document the OTP-to-token chain, and rebuild the loan-ledger and schedule reads as a clean interface. Reachable: everything a borrower sees in-app. Effort: moderate, front-loaded into the first week. Durability: good, with a re-validation pass when the app's front end changes. We arrange the consenting account and the capture environment with you during onboarding.

User-consented credential access

Where your own users are the borrowers, they authorize access to their record and we pull on their behalf — the same reads, driven by each user's consent rather than a single test account. Reachable: that user's loans and schedule. This is the natural shape for a portfolio feed across many borrowers.

Native records, where the app surfaces them

Any in-app statement or exportable record the borrower can already pull is used as a cross-check on the protocol route — a fallback that confirms the numbers, not the primary source for a live feed.

For a recurring repayment or exposure feed across borrowers, consented credential access is what we'd actually run, because it scales with each user's own authorization rather than a single session; the protocol work underneath is what makes those reads reliable.

PDPA, the PICO licence, and consent scope

Thailand's Personal Data Protection Act has been in force since 1 June 2022 and treats a national-ID number and financial records as data needing explicit, purpose-bound consent — exactly the fields this app collects at signup. Our access is consented, logged, and minimized: we capture the consent basis, pull only the fields a use case needs, and document retention so the stored data matches what was agreed. The lending itself sits under a pico-finance licence supervised by the Ministry of Finance's Fiscal Policy Office, which is the regime that governs how the operator may lend; our work is on the data interface, under the account holder's authorization, with an NDA where a client needs one. Consent is revocable, and we design the sync so a withdrawn consent stops the pull rather than orphaning data.

Things we account for on the build

Two specifics about this app shape how we engineer the integration:

• Daily accrual, not a static balance. Interest moves every day at roughly 0.05%, so a balance read at 9am is wrong by lunchtime. We compute the schedule from disbursed principal, accrual rate, and date rather than snapshotting one number, and reconcile it against the app's own worked example (฿10,000 over 120 days landing at ฿10,600).
• OTP-keyed sessions. Login is tied to a Thai mobile number with an SMS OTP. We design token capture and refresh around that step so a consented session keeps reading without a person re-entering a code, and we handle the expiry window explicitly so the feed does not quietly stall.
• Front-end churn. Consumer lending apps reskin often; we build a re-validation step into maintenance so a changed screen surfaces as a test failure, not as silently wrong data.

Access, the consenting account, and any compliance paperwork are arranged with you as part of the engagement — none of it is something you need to have ready before we start.

Where integrators put this data

• A lending aggregator showing a borrower their กู้เงินง่าย ๆ loan alongside others in one repayment calendar.
• A collections or reminder service that needs the next payoff date and the exact amount owed on that date.
• An exposure dashboard for a partner that has referred borrowers and wants live outstanding-principal totals.

Screens we worked from

Public store screenshots used while mapping the surfaces above.

Other Thai lending apps in the same data picture

Apps a client integrating consumer-loan data in Thailand commonly mentions alongside this one, each holding a comparable per-borrower record:

• MoneyThunder — SCB Abacus digital-lending app; holds approved limits and repayment data for a large borrower base.
• FINNIX — MONIX revolving-credit app, regulated by the Bank of Thailand; holds drawdowns and repayment schedules.
• LINE BK — Credit Line product inside LINE; holds personal-loan balances and statements.
• Kredivo Thailand — buy-now-pay-later and cash loans; holds instalment plans and outstanding balances.
• Good Money — GSB's digital-lending app for the underserved; holds loan accounts and repayment status.
• Credit OK — alternative-data lender; holds borrower scores and loan records.
• Dolfin Money — Central JD wallet with lending; holds credit lines and transaction history.
• KTC — card and personal-loan issuer; holds statements and repayment ledgers.

Each is a separate integration; naming them maps the wider Thai lending data landscape, not a ranking.

Questions integrators ask about this app

Can you separate principal from accrued interest in the data you extract?

Yes. The app accrues interest daily at roughly 0.05% per day on a 91-to-180-day term, so a single balance figure is ambiguous. We model the schedule the way the app describes it: outstanding principal, daily accrued interest, and the projected total at maturity as separate fields, reconciled against the disbursed amount rather than read off one stale number.

How do you handle the SMS-OTP login the app uses?

Registration is keyed to a Thai mobile number with an OTP step. We map the token issued after that step and design the sync to refresh it on its own clock, so a consented session keeps pulling the loan ledger without a person re-entering a code each run. The auth chain is documented in the protocol report we hand over.

Does Thailand's PDPA change what borrower fields we can sync?

It shapes them. The Personal Data Protection Act has been in force since 1 June 2022 and treats national-ID and financial fields as needing explicit, purpose-bound consent. We scope the pull to the fields your use case actually needs, record the consent basis, and drop everything else, so the integration matches the consent rather than over-collecting.

We run a Thai lending book and want a recurring repayment feed rather than a one-off pull. Which way works?

A recurring feed usually fits the pay-per-call hosted API: you call our endpoint when you need a borrower's current schedule and pay per call, with nothing to host. If you would rather keep the sync inside your own systems, we deliver the same logic as runnable source you run on your schedule. Either path is a 1 to 2 week build.

What was checked

Mapped from the app's own Play Store description (loan range, term, daily-accrual example, operator) against Thailand's lending and data-protection framework, in June 2026. Sources opened: the pico-finance licensing summary at G.A.M. Legal Alliance, Thailand's PDPA overview at DLA Piper Data Protection, the Bank of Thailand API portal for what national reference data is and isn't published, and FinDev Gateway's writeup of a comparable regulated Thai lender, FINNIX.

Mapped by the OpenBanking Studio integration desk · 23 June 2026.

Source-code delivery starts at $300, billed only after we hand over the runnable build and you have confirmed it reads your borrower data correctly; if you would rather not host anything, the same loan-ledger and schedule endpoints run as a pay-per-call hosted API with no upfront fee. A 1–2 week cycle covers either path. Send the app name and what you need from its data at /contact.html and we take it from there.