Loan ledgers, schedules and QR repayments inside ยืมคล่อง

Every approved loan in ยืมคล่อง comes with a four-installment reducing-balance plan, and the per-cycle split between principal and interest is exactly what a partner wants out of it. The app describes itself as a provincial micro-loan service (Pico Finance) under Thailand's Ministry of Finance, lending up to 50,000 baht with an APR the listing puts at no more than 35.8% a year. The data worth integrating is the borrower's own ledger: the contract, the schedule, what has been paid, and what is still owed.

Here is the bottom line. The records render inside the borrower's authenticated session, so a consented session capture reaches every field without depending on a published feed. That is the build we would scope for ยืมคล่อง today, with the regulated data-sharing rail as a second path once it firms up.

The borrower records behind the app

These map to surfaces a real ยืมคล่อง user moves through — registration by phone, the loan request, the repayment screen, and the support menu. Granularity is what the app actually exposes per borrower.

Authorized routes to the loan ledger

Authorized interface integration under borrower consent

We analyze the app's own client-to-server traffic in a consenting borrower's session and rebuild the calls behind the loan and repayment screens. Reach is everything that borrower can see — contract, schedule, status, QR. Effort is moderate; durability depends on the app's release cadence, which we account for with a re-validation step. Access is arranged with you during onboarding, against a consenting test account.

Consent-based credential access

Where a borrower (or a lender acting for its own book) authorizes it, we drive the same session through stored credentials and a token refresh, so a sync runs unattended on a schedule. This sits on the same surfaces as the route above and is governed by the same PDPA consent record.

Thailand's "Your Data" data-sharing rail

The Bank of Thailand announced "Your Data" in October 2024 — a national, consent-based framework letting people share data held by a provider with the financial firm of their choice, with an operational target around 2026. It is not a finished standard yet, so we treat it as a forward path rather than something to build against now, but it is the direction this kind of sharing is headed.

For ยืมคล่อง as it stands, the authorized interface route is the one we would build against: the schedule and status render in the borrower's session, so a consented capture gets the full per-installment detail without waiting on the national rail to standardize.

A session against the loan and schedule endpoints

Illustrative shape of the calls — field names get confirmed during the build, not from any published document. It mirrors the worked example in the app's own listing: 30,000 baht over four 30-day cycles, a fixed 7,968.01 baht payment, and a final installment that settles to zero at 7,967.99.

# 1) Borrower session: mobile-number registration returns a bearer token.
POST /api/v1/auth/otp/verify
  { "msisdn": "+66xxxxxxxxx", "otp": "######" }
  -> 200 { "access_token": "...", "refresh_token": "...", "expires_in": 1800 }

# 2) Active contract + reducing-balance schedule (ลดต้นลดดอก)
GET /api/v1/loans/active        Authorization: Bearer <access_token>
  -> 200 {
       "contract_id": "...",
       "principal": 30000.00, "currency": "THB",
       "term_days": 120, "installments": 4,
       "apr_max_pct": 35.8,                # as the listing states
       "schedule": [
         { "seq": 1, "payment": 7968.01, "interest": 739.80,
           "principal_paid": 7228.21, "balance_after": 22771.79 },
         { "seq": 2, "payment": 7968.01, "interest": 561.55,
           "principal_paid": 7406.46, "balance_after": 15365.33 },
         { "seq": 3, "payment": 7968.01, "interest": 378.91,
           "principal_paid": 7589.10, "balance_after": 7776.23 },
         { "seq": 4, "payment": 7967.99, "interest": 191.76,
           "principal_paid": 7776.23, "balance_after": 0.00 }
       ]
     }

# 3) Repayment is in-app QR only — capture the payload, match on settlement.
GET /api/v1/repayments/{contract_id}/qr
  -> 200 { "qr_payload": "<EMVCo string>", "amount": 7968.01, "expires_at": "..." }

# Errors seen in practice: 401 -> refresh; 409 -> no active contract; 429 -> back off.

What lands in your repo

• An OpenAPI/Swagger spec for the contract, schedule, repayment-status and QR endpoints, normalized to clean JSON.
• A protocol and auth-flow report: the OTP-to-token exchange, the refresh chain, and how the session is held.
• Runnable source in Python or Node for OTP login, token refresh, the active-loan fetch, the schedule parser, and a repayment-status poll.
• Automated tests against captured fixtures, including a check that the parsed schedule reconciles to the displayed totals.
• Interface documentation mapping each app screen to the fields it yields.
• PDPA-aligned consent and data-retention guidance, with logging of every pull and an NDA where you need one.

Consent and the Thai rules that apply

The governing instrument is Thailand's Personal Data Protection Act (B.E. 2562 / 2019), in force since mid-2022 and overseen by the Personal Data Protection Committee. Borrower records here are personal data, so access rests on the borrower's explicit, withdrawable consent — and because the PDPA makes withdrawal as easy as granting it, we capture consent state and honor revocation in the sync. Pico Finance lending itself sits under the Fiscal Policy Office at the Ministry of Finance, with the all-in annual charge capped by regulation, which is why the contract and schedule fields matter for any partner that has to evidence cost of credit. We keep access authorized, logged and data-minimized to the fields a given use actually needs.

Engineering details we account for

Two things about ยืมคล่อง shape the build, and we handle both rather than hand them to you as conditions.

• The reducing-balance rounding. The listing's worked example pays 7,968.01 baht for three cycles and 7,967.99 on the fourth so the balance lands exactly at zero. We reproduce the per-installment interest-then-principal math and reconcile to the shown totals, including that two-satang adjustment on the last cycle, so the export ties out rather than drifting by a rounding cent.
• QR-only repayment. The app's own notice says repayments go through the in-app QR and warns against transfers to any personal account. We build payment matching around the QR payload the app issues, not an external bank reference, so settlements close the right installment.
• Provincial scoping. Pico loans are tied to borrowers in the operator's province, so we keep the jurisdiction attached to each contract record and design the data model to carry it.
• Front-end drift. Registration and repayment screens change between releases, so we keep a re-validation step in maintenance that re-checks the captured calls when a new version ships.

What I checked, and where

I read the app's Play listing for the loan terms, the worked amortization example and the QR-only repayment notice, then cross-checked the regulatory frame against primary Thai sources. Citations: the Bank of Thailand's "Your Data" project announcement, the Fiscal Policy Office's Pico Finance public-service page, the official PDPA B.E. 2562 text, and the Bangkok Post report on the central bank's open-data initiative.

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

Interface evidence

Screens from the Play listing, as a quick reference for the surfaces above. Tap to enlarge.

Other Thai lenders in the same data picture

Same category, same kind of per-borrower ledger. A partner that wants one normalized loan feed usually wants several of these mapped the same way; names are for context only.

• FINNIX — nano-finance lending app; holds borrower profiles, credit lines and repayment ledgers.
• เงินทันเด้อ (MoneyThunder) — digital personal-loan app with per-user loan accounts and schedules.
• KKP Dime — Kiatnakin Phatra's digital finance app; balances across lending and investment.
• CardX — SCB's consumer-lending arm; card and loan statements per account.
• Kredivo — buy-now-pay-later and cash loans; credit limits and installment plans.
• Good Money by GSB — Government Savings Bank digital lending aimed at the underbanked.
• มีตัง (MeeTang) — small-ticket micro-loan records.
• Loter เงินกู้ — a Pico Finance lender app with provincial micro-loan contracts.
• EASYสินเชื่อ — another Pico Finance lender app on provincial loan accounts.

Questions integrators ask about ยืมคล่อง

Can you rebuild the reducing-balance schedule field for field, including the rounding on the final installment?

Yes. We parse each installment's payment, interest and principal portions and the carried-over balance, then reconcile to the totals the app shows, including the small rounding on the last installment, where the listing's own worked example pays 7967.99 baht instead of 7968.01.

Repayment is QR-only with no bank-transfer reference, so how do you reconcile payments?

We capture the in-app QR payload the app generates for each repayment and match settlements against it, rather than expecting an external transfer reference. The listing itself states that repayment runs through the in-app QR only, so payment matching is built around that payload.

Which Thai data rules cover a consented integration of borrower records?

Thailand's PDPA (B.E. 2562) governs collection, use and disclosure of personal data, and a borrower can withdraw consent at any time, so consent capture and revocation are built in from the start. The Bank of Thailand's Your Data consent-based data-sharing framework, announced in October 2024 with an operational target around 2026, is the rail we expect this kind of sharing to move onto as it standardizes.

We already run a licensed Pico lender, so can you scope this to just the amortization export?

Yes. We can limit the build to the loan-contract and schedule endpoints and hand back a normalized schedule export plus repayment status, without touching the registration or KYC surfaces.

Source code lands in your repo from $300, billed only after delivery once you have checked it works; if you would rather not host anything, the same loan-account, schedule and repayment endpoints run as a pay-per-call hosted API with no upfront fee. Either way the build runs on a one-to-two-week cycle. Tell us the app and what you need from its records at /contact.html and we will scope it.