Getting structured loan and repayment data out of มินิแคช

Every approved borrower in มินิแคช carries a server-side loan ledger: an approved line described in the listing as up to 50,000 baht, a 91–180 day term split into installments, and a per-งวด breakdown of principal against interest. That ledger, not the marketing screen, is the asset an integrator wants. The product is operated by SONGPHINONG PICO SPEEDY CASH COMPANY LIMITED under a provincial Pico Finance licence the listing gives as 838/2563, supervised by Thailand's Ministry of Finance. This page maps what the app holds and the authorized way to reach it.

Bottom line: this is a single-account portal app with a well-structured amortization schedule behind login. The route we would take is authorized protocol analysis of the app's own traffic, run on a consenting borrower's session, normalised into a small loan-and-schedule schema. The reducing-balance math is the part worth getting exactly right, and the app already exposes the inputs for it.

Data inside the app

The fields below are drawn from the app's described product flow — an approved line, a fixed-term installment plan, and a transparent fee structure quoted in the contract.

Routes to the data

Authorized protocol analysis of the app session

We observe the traffic between a consenting borrower's app and the มินิแคช backend, document the auth handshake and the JSON shapes for the account, schedule and payment-log calls, and re-implement those calls as a clean client. Reachable: the full loan ledger and amortization detail listed above. Effort is moderate; durability is good between front-end revisions and is the thing we keep watch on. Access is arranged with you during onboarding, on a test or consenting account.

User-consented credential access

Where a borrower authorizes it, a session runs under their own login to pull their own records on a schedule. This is the lighter path for a single-borrower or servicing use case and keeps the data strictly first-party. We hold the consent record and scope it to named fields.

Native export as a fallback

Any statement or contract document the app lets a user save is a low-effort supplement — useful for backfill and reconciliation, weaker for live sync because it is point-in-time. We treat it as a cross-check on the parsed schedule, not the spine of the feed.

For มินิแคช, protocol analysis on a consenting session is the route I would build the integration around — it is the only one that returns the per-installment principal/interest split as live structured data rather than a flattened PDF, and that split is the whole point of a reducing-balance product. Credential access rides alongside it for single-borrower servicing.

What lands in your repo

• An OpenAPI 3.1 spec covering the account, schedule and payment-log endpoints as observed, with the loan and installment object shapes.
• A protocol & auth-flow report: the login/token handling and the request sequence to reach the amortization data, with the error and retry behaviour seen during the build.
• Runnable client source in Python and Node.js for the key calls — pull account, fetch schedule, list payments — with the reducing-balance reconstruction included.
• A normalised loan-and-schedule schema so installment rows map cleanly into your own ledger.
• Automated tests against captured fixtures, plus interface documentation and PDPA-aligned retention guidance.

Schedule query

Illustrative shape of the schedule call and the installment array we normalise it into — field names confirmed against the live response during the build, not assumed here.

GET /api/v1/loan/{loanId}/schedule
Authorization: Bearer <session-token>
Accept-Language: th-TH

# normalised response (reducing-balance, ลดต้นลดดอก)
{
  "loanId": "…",
  "principalApproved": 30000.00,
  "currency": "THB",
  "termDays": 180,
  "installments": [
    { "seq": 1, "due": "2026-07-28", "payment": 5319.68,
      "principal": 4779.68, "interest": 540.00, "balanceCarried": 25220.32 },
    { "seq": 2, "due": "2026-08-27", "payment": 5319.68,
      "principal": 4865.71, "interest": 453.97, "balanceCarried": 20354.61 }
    /* … through final installment, balanceCarried -> 0.00 */
  ],
  "totalRepayable": 31918.08
}

# guard: re-derive interest from balanceCarried * periodRate and
# compare to the server figure; a mismatch flags a parse/version drift.

The values mirror the worked example the app itself publishes (a 30,000 baht line over six งวด). We carry the server's own figures and use the derivation only as a tripwire, because the borrower-facing number is the one that must reconcile.

Consent & PDPA

This is Thai data, so the regime is the Personal Data Protection Act, in force since June 2022, with the Pico lending activity itself supervised by the Ministry of Finance's Fiscal Policy Office. The dependable basis for the integration is the account holder's own explicit consent — PDPA requires it to be specific and freely withdrawable, so we capture a logged consent record, bind it to a named scope, and wire revocation into the sync rather than bolting it on later. Borrower loan data is sensitive; national-ID and contact fields are redacted at the boundary unless an in-scope reason exists, retention is bounded, and access is logged. NDAs are standard where the engagement touches a lender's own systems.

Build notes

Two things on this app specifically that we plan around, both handled on our side.

• The reducing-balance schedule is computed, not stored as a flat APR. We design the parser to carry the per-installment principal/interest split and the carried-forward balance, and validate the reconstruction against the app's own totals so a rounding difference surfaces in tests rather than in someone's ledger.
• Pico Finance is licensed per province to one operator, so a borrower record belongs to a specific licence and จังหวัด. We keep the licence number and province as first-class fields, which keeps the data correct if an aggregator later pulls from more than one Pico lender instead of treating every loan as one national pool.
• The app warns borrowers about look-alike fakes and off-app transfers; we treat the in-app official payment account as the authoritative reconciliation key and key inbound payments to it.

Where teams use it

• A debt-advisory or PFM tool that shows a borrower their real reducing-balance payoff curve and the saving from paying ahead.
• A servicing back office reconciling inbound repayments against the official in-app account and flagging missed installments early.
• An aggregator normalising มินิแคช alongside other Thai micro-lenders into one loan schema for an affordability view.

Sources

Checked in June 2026 against the app's own Google Play listing (operator, licence reference, the 50,000-baht ceiling, the worked six-installment example), the Fiscal Policy Office material on provincial Pico Finance supervision, and current Thailand PDPA guidance on consent and enforcement. Citations:

• มินิแคช on Google Play
• Fiscal Policy Office — Pico Finance supervision
• Thailand PDPA — data-protection law summary

OpenBanking Studio · integration desk mapping, June 2026.

Comparable lenders

Same Thai consumer-credit space, named for keyword and ecosystem context — neutral, no ranking. Each holds account data a unified integration would normalise alongside มินิแคช.

• MoneyThunder — ABACUS digital lending app with personal and nano-finance lines and per-account installment data.
• PROMISE — revolving personal-loan app holding reusable credit-line balances under Bank of Thailand rules.
• Good Money (Money DD) — GSB-linked digital lender with nano-finance accounts and repayment records.
• Kredivo Thailand — buy-now-pay-later and cash-loan revolving accounts with disbursement and statement data.
• LINE BK Nano Credit Line — Kasikorn Line credit line inside LINE, holding loan-account and behavioural data.
• Siam Digital Lending — fully digital personal and micro-loan products for working capital.
• Credit OK — alternative-data lender serving merchants with account and scoring records.
• KTC — card and personal-loan accounts with statement and transaction history.

Screens

Questions

MiniCash quotes a reducing-balance (ลดต้นลดดอก) rate — does the extracted data carry the per-installment principal and interest split, or only a total?

The amortization screen exposes both. Each งวด row carries the payment amount, the principal portion, the interest portion and the carried-forward outstanding principal, which is what reducing-balance accounting needs. We model the schedule as an installment array so a downstream system can reproduce the effective-rate math rather than store a single APR figure.

MiniCash is a provincial Pico Finance lender — does that provincial licensing limit affect how the integration is scoped?

It shapes the data model more than the engineering. Pico Finance licences in Thailand are issued per province by the Ministry of Finance's Fiscal Policy Office, so a borrower record is tied to one licensed operator and one province. We keep the licence and province as first-class fields rather than flattening every loan into a single national namespace, which matters when an aggregator pulls from more than one Pico lender.

How do you keep extraction of มินิแคช borrower records aligned with Thailand's PDPA?

Access runs on the consenting account holder's own authorization, with a logged consent record and a defined scope and retention window. We minimise what is pulled to the fields the integration actually uses, redact national-ID and contact fields at the boundary unless they are in scope, and keep an audit trail. PDPA has been in force since June 2022 and requires explicit, withdrawable consent, so revocation is wired in from the start.

Can you deliver a sandbox-safe build before touching live MiniCash borrower data?

Yes. We arrange access with you during onboarding and build first against a consenting test account or captured fixtures, so the parsing, schema and tests are proven before any production borrower record is read. The runnable source and OpenAPI spec land in one to two weeks.

Working with us

You give us the app name and what you need from its loan data; we work out the route, arrange access with you, and build it. The schedule parser and reconstruction land first so the numbers reconcile before anything goes near a production account. Two ways to pay for it: a source-code delivery starting at $300, where you receive the runnable client, OpenAPI spec, tests and documentation and pay only after delivery once it works for you; or a pay-per-call hosted API with no upfront fee, where you call our endpoints and pay for the calls you make. Either way the build cycle is one to two weeks. Tell us the data you want and the use case at /contact.html and we will scope it.