Reaching a borrower's loan limit and repayment schedule inside เงินเหลือในกระเป๋า

Borrowers see a credit line the listing puts at ฿10,000–฿30,000, a term that runs 91 to 365 days, and an APR the same listing caps at 21.9% — and each of those numbers lives as a server-side record behind a login, not as a static page. That is the part worth integrating. The platform is operated by YUANYI TECHNOLOGY COMPANY LIMITED and provided under the pico license of T OFFMONEY KAMPHAENGPHET CO., LTD., per the app's own description. For a lender, collections partner, or personal-finance aggregator that needs a borrower's live position out of this app, the working route is a consent-based interface integration: we analyze the app's own client-to-server traffic under the borrower's authorization and rebuild it as a clean API. That is what this page maps.

What the account actually holds

These are the surfaces a borrower touches in the app, mapped to where each one originates and what an integrator does with it. The schedule rows are the dense ones — the listing spells out a worked example down to the satang.

A repayment-schedule call, rebuilt

Here is the shape of the request we reconstruct once the borrower's session is established during protocol analysis. Field names are illustrative and confirmed against live traffic during the build; the response models the installment plan the listing describes.

GET /v1/loan/{loan_id}/schedule
Authorization: Bearer <session_token>   # captured via consented login, refreshed on 401

# normalized response (we flatten the app's own payload to this)
{
  "loan_id": "LN-…",
  "principal": 10000.00,
  "currency": "THB",
  "apr": 0.219,                 # cap per listing; verified per loan
  "term_days": 150,
  "installments": [
    {"seq": 1, "due_in_days": 50, "principal": 3300.00, "interest": 300.00, "due": 3600.00},
    {"seq": 2, "due_in_days": 100, "principal": 3300.00, "interest": 300.00, "due": 3600.00},
    {"seq": 3, "due_in_days": 150, "principal": 3400.00, "interest": 300.00, "due": 3700.00}
  ],
  "total_repayable": 10900.00
}

# interest per installment we recompute and reconcile:
#   principal_total * apr / 365 * days_in_period
#   10000 * 0.219 / 365 * 50  ->  300.00  (matches the listing's worked example)

The reconciliation comment matters: we do not trust the displayed totals blind, we recompute them and flag any drift. If the app rounds differently from our model, that surfaces in the test suite rather than in production.

What lands in your repo

The deliverable is the integration itself, not a report about it. For this app that means:

• An OpenAPI spec covering loan, schedule, accrual, status and transaction reads — the surfaces in the table above.
• A protocol and auth-flow write-up: the consented login, the session-token chain, and the refresh-on-401 behaviour as it actually runs here.
• Runnable source for the key endpoints in Python and Node.js, including the schedule recompute-and-reconcile step.
• Automated tests that assert the installment math against the listing's worked example and against a consenting account.
• Interface documentation plus data-retention and consent-logging guidance shaped to PDPA.

Routes that apply here

Consent-based interface integration (the one we would run)

We analyze the app's client-to-server calls under a borrower's authorization and rebuild them as the API above. This reaches everything the borrower can see — limit, schedule, accrual, status, transactions — and it is the route that fits a single-issuer app like this one. Durability is good as long as we watch the client; the studio handles access and the consenting test account with you during onboarding. This is the recommendation: for a pico lender with no cross-bank data-sharing scheme to ride yet, the borrower's own session is the cleanest and most complete path to their records.

User-consented credential access

Where a partner already holds a borrower relationship, the same consented session can be driven on the borrower's behalf for periodic sync rather than one-off reads. Effort is low once the interface work above exists; it reuses the same auth chain.

Native export, as a fallback

If a borrower can export or screenshot a statement from the app, that covers a static snapshot only — no live accrual, no event stream. We treat it as a backfill source, not the primary feed.

Consent and the Thai rulebook

Two regimes touch this app. The lending side sits in Thailand's pico-finance framework, supervised through the Ministry of Finance, where the total effective rate a pico lender may charge is capped — the listing's 21.9% APR sits well inside that. The data side is the PDPA, enforceable since June 2022 and built closely on the GDPR, which turns on the data owner's consent for a stated purpose.

So the dependable basis for any extraction is the borrower's own authorization, captured with a defined scope, an expiry, and a revocation path, with consent records and access logs kept. The Bank of Thailand has consulted on a consumer data-portability direction (its "Your Data" public hearing in early 2025); that is where Thai open-data access may go, not a live rail you can call today, so we do not build on it — we build on consent now and leave room to adopt a portability API if one lands. Data is minimized to what the stated purpose needs, and an NDA covers the engagement where the client wants one.

Things we handle on this build

• Uneven principal split. The listing's example splits principal 33% / 33% / 34% across three installments with interest computed per งวด. We replicate that exact split and rounding so our schedule reconciles to the app's baht figures, and we make the period length a parameter rather than hard-coding 50 days.
• Approved limit ≠ advertised range. The real limit comes from the platform's assessment, not the ฿10k–฿30k catalogue band. We model the approved limit as its own field so a downstream system never assumes the maximum.
• Entity of record. Operator (YUANYI TECHNOLOGY) and licensee (T OFFMONEY KAMPHAENGPHET) differ. We tag each extracted record with the licensed lender so the lender of record stays auditable.
• Session lifetime. We design the sync around the app's token expiry and refresh behaviour, so a long-running pull renews rather than silently stalling. When the app's client changes, a re-validation pass in maintenance catches the drift.

How it gets used

1. A collections platform syncs each borrower's live installment schedule nightly and triggers reminders keyed to the next due date and amount.
2. A personal-finance aggregator shows a borrower their full repayment plan and remaining balance alongside accounts from other Thai apps.
3. An audit tool recomputes interest against the 21.9% cap per loan and flags any installment that drifts from the expected accrual.
4. An onboarding dashboard mirrors the smart-assessment approval status so a partner sees applications resolve in near real time.

Interface evidence

Store screenshots of the borrower-facing flows we map. Tap to enlarge.

Similar Thai lending apps

Same category, useful when a borrower or a partner spans several lenders and you want one normalized feed. Listed for context, not ranked.

• MoneyThunder — digital lending from ABACUS digital under the SCBX group; holds loan limits and repayment records behind a login.
• FINNIX — microloans from MONIX, an SCBX affiliate; per-user credit line and installment history.
• Line BK — Kasikornbank and LINE joint venture; deposit and digital-loan balances inside the LINE app.
• PROMISE สินเชื่อส่วนบุคคล — personal-loan accounts with schedules and statements.
• K PLUS — KASIKORNBANK's banking app; accounts, transfers and linked loan products.
• PayPaya — cash-loan app with approval status and repayment ledgers.
• ยืมเลย — online cash-loan app holding limit and repayment data per borrower.
• Muangthai Capital — vehicle-title and personal lending with structured loan accounts.

How this was checked

Mapped against the app's own Play Store description (operator, licensee, loan range, term, APR cap and the worked installment example) on 24 June 2026, then cross-checked Thai pico-finance licensing, the PDPA, and the Bank of Thailand's data-portability consultation against primary sources:

• G.A.M. Legal Alliance — Thailand pico-finance framework and rate cap
• Thailand PDPA overview (effective June 2022, GDPR-aligned)
• Bank of Thailand — "Your Data" consumer data-portability consultation
• Bank of Thailand — licensed-lender check

Mapping reviewed 2026-06-24 by the OpenBanking Studio integration desk.

Questions an integrator asks

Can the repayment schedule be reconstructed exactly, including the uneven 33/33/34 principal split?

Yes. The listing describes principal split across installments at roughly 33%, 33% and 34% with interest of principal times APR divided by 365 times the days in each งวด. We replicate that arithmetic and rounding so our computed schedule reconciles to the app figures down to the satang, then verify it against a consenting account during the build.

Which Thai entity actually holds the borrower data — YUANYI or the pico licensee?

Per the app listing, the platform is operated by YUANYI TECHNOLOGY COMPANY LIMITED and provided under the license of T OFFMONEY KAMPHAENGPHET CO., LTD., which holds the Thai pico-finance license. We tag extracted records with the licensed entity so the lender of record is auditable in any downstream system.

Does Thailand's PDPA let a third party pull a borrower's loan records from เงินเหลือในกระเป๋า?

The PDPA, enforceable since June 2022 and modeled on the GDPR, runs on the data owner's consent for a stated purpose. The dependable basis for any pull is the borrower's own authorization, captured and logged with a defined scope and revocation path. We arrange that consent flow with you during onboarding.

Is the approved credit limit the same as the advertised ฿10,000–฿30,000 range?

No. The listing presents ฿10,000 to ฿30,000 as the catalogue range and states the real limit depends on the platform's assessment result. We model the approved limit as its own field, separate from the advertised range, so downstream systems never assume the maximum.

One build runs one to two weeks. You can take it as source-code delivery from $300, paid after we deliver and you are satisfied, with the OpenAPI spec, runnable Python and Node.js source, tests and docs landing in your repo; or as a pay-per-call hosted API with no upfront fee, where you call our endpoints and pay only for calls. Tell us the requirement and we scope it — start a conversation here.