Connecting to the borrower records behind Loan Hub

A ฿24,000 loan over 120 days closes at ฿24,966.33 across three installments — the reducing-balance schedule Loan Hub prints on every borrower's loan-detail screen, and exactly the structured record an integrator wants pulled out of the app. Loan Hub (package com.aavelo.flowfund, per its Google Play listing) runs provincial micro-lending under Thailand's Pico Finance regime, operated by TEXTME COMPANY LIMITED. The valuable data sits behind a phone-verified account: loan contracts, the installment ledger, application and approval state, KYC status, and disbursement records.

The bottom line for anyone building on Loan Hub: the data is rich and well-structured, and it lives inside an authenticated mobile app. So the work is interface integration — we map the borrower flow under authorization and hand back a clean API over the same records. The practical path is reading the app's own traffic; the consent rails Thailand is building sit alongside it as a more durable successor once they reach loan data.

What the borrower file actually contains

Each row below is a surface Loan Hub renders to a logged-in borrower. The data is per-user and contract-scoped, which is what makes it worth syncing into a lender's own systems, a collections tool, or an affordability model.

Reading the installment ledger

The shape below is illustrative — field names get confirmed during the build by capturing the live flow against a consenting account. It reflects how a Pico app of this kind authenticates (phone plus OTP, exchanged for a bearer token) and how the loan-detail surface returns the reducing-balance schedule.

POST /api/v1/auth/otp/verify
  { "phone": "+66...", "otp": "######", "device_id": "..." }
  -> 200 { "access_token": "ey...", "expires_in": 1800, "refresh_token": "..." }

GET /api/v1/loans/{contract_id}/schedule
  Authorization: Bearer ey...
  -> 200
  {
    "contract_id": "LH-...",
    "principal": 24000.00,
    "term_days": 120,
    "apr_pct": 18.25,
    "method": "reducing_balance",
    "installments": [
      { "no": 1, "due_day": 40,  "amount": 8322.11, "principal": 7842.11,
        "interest": 480.00,  "balance_after": 16157.89 },
      { "no": 2, "due_day": 80,  "amount": 8322.11, "principal": 7998.95,
        "interest": 323.16,  "balance_after": 8158.94 },
      { "no": 3, "due_day": 120, "amount": 8322.11, "principal": 8158.93,
        "interest": 163.18,  "balance_after": 0.00 }
    ],
    "total_repayable": 24966.33
  }

# 401 -> refresh the token; OTP session is short-lived, so the
# client re-authenticates before the window closes rather than
# letting a sync silently stall.

The numbers above mirror the worked example in Loan Hub's own listing, which is the cheapest way to check that our reducing-balance calculation matches the app to the satang before anything goes live.

What lands in your repository

Everything we build for Loan Hub maps to the surfaces above, not a generic template:

• An OpenAPI/Swagger spec for the loan, schedule, application-status, KYC-state and transaction endpoints as they actually behave.
• A protocol and auth-flow report covering the phone-OTP login, the bearer-token exchange, refresh handling and request signing.
• Runnable source for the key calls in Python and Node.js — token lifecycle, schedule pull, status polling, with retry and back-off.
• A reducing-balance reconciliation module that recomputes each installment's principal/interest split and flags any drift from what the app shows.
• Automated tests against captured fixtures, plus a thin live-smoke check for a consenting account.
• Interface documentation and PDPA-minded data-retention notes — which fields to keep, which to drop, and how consent is logged.

Getting to the data

Three routes genuinely apply to Loan Hub. We size each against effort and how long it keeps working.

Authorized interface integration (protocol analysis)

We capture the app-to-backend traffic under the borrower's or the operator's authorization, map the OTP and token chain, and reimplement the loan, schedule and status calls as a stable API. This reaches everything a borrower can see. Durability depends on the app's front end; when screens change, captured endpoints can shift, so we keep a check that re-runs against the live flow and surfaces drift before your sync breaks. Access is arranged with you during onboarding against a consenting account or an operator test environment.

User-consented session access

With a borrower's consent we drive the documented login and read that person's own records. This fits a per-user pull — one borrower wiring their Loan Hub history into a budgeting tool or another lender's affordability check — and keeps the consent trail clean under PDPA.

The "Your Data" consent rail (forthcoming)

The Bank of Thailand's Your Data scheme is building a standardized, consent-based rail for sharing financial data between providers. Its first phase covers personal deposit data from late 2026, with loans and payments in the 2027–2028 expansion as the central bank has described it. It is not available for loan data yet, so it is not something we can ship against today — but it is where a Loan Hub integration becomes durable infrastructure rather than a maintained capture, and we design now so a later switch to it is a swap, not a rebuild.

For most clients today the answer is the first route: read the live borrower flow under authorization, because that is the only path that returns the full installment ledger right now, and fold in the Your Data rail for loan records the moment that phase lands.

Consent and the Thai rulebook

Loan Hub operates under a Ministry of Finance Pico Finance licence — the provincial micro-lending framework that caps a loan at ฿50,000 and an effective rate near 36%, and which requires licensed operators to run KYC on every borrower (per the licensing summaries we reviewed). Personal data is governed by Thailand's PDPA, under which a data controller needs explicit consent before collecting or disclosing personal data and the data subject can withdraw it at any time. That shapes how we work: access is authorized, every pull is logged against a consent record, we take only the fields the integration needs, and we avoid mirroring raw ID images unless a use case genuinely requires them. Where a borrower's own data moves into a third party's hands, an NDA and a data-processing agreement sit under the engagement. The Your Data rail will eventually give this a statutory, standardized footing for loan records; today the dependable basis is the borrower's PDPA consent.

Build notes for this one

• Reducing-balance math has to reconcile exactly. The APR is applied on the declining principal, so a flat-interest approximation drifts within a few installments. We port the exact method and verify our computed split against the app's displayed amounts — the listing's ฿24,000 example totalling ฿24,966.33 is the first fixture.
• Provincial scope is metadata, not a wall. Pico licences are province-limited, so we carry the contract's province and licence context through the schema; it changes how records are tagged, not whether a borrower can authorize the read.
• OTP sessions are short. Thai loan apps gate on phone-OTP and issue brief sessions. We build the sync around that lifecycle, refreshing ahead of expiry and arranging a consenting account during onboarding so the capture is repeatable.
• Data minimization is in the design, not bolted on. The schema keeps loan, schedule and status fields and treats identity documents as references rather than copies wherever a use case allows, which keeps the PDPA footprint small.

Screens we map against

The store screenshots show the surfaces we capture — the loan dashboard, the application steps and the repayment view. Open any to enlarge.

Where Loan Hub sits among Thai lenders

The same integration pattern applies across Thailand's online-lending category, which is useful when a client wants one normalized loan schema across several apps rather than a one-off. Names below are for ecosystem context only.

• มีตัง (Mee Tung) — a near-identical Pico Finance product (฿3,000–50,000, 91–180 days, the same APR band) under Ministry of Finance supervision; holds the same loan-and-schedule records.
• PROMISE — revolving personal loans with fast approval; per-user limit, drawdown and repayment history behind an account.
• Good Money by GSB — personal and nano-finance lending from a Government Savings Bank subsidiary; account-bound loan and repayment data.
• Siam Digital Lending (SiamDL) — personal and nano loans with AI-based approval under Bank of Thailand oversight; structured loan ledgers.
• FINNIX — fintech personal lending with in-app loan accounts and repayment tracking.
• MULA — earned-wage and personal lending built on alternative-data scoring; per-user advance and repayment records.
• Kredivo — revolving credit and pay-later with disbursement to a bank account; transaction and limit data per user.
• UP-Ngern-Yuem (SCB) — a revolving loan for variable-income borrowers; account-held balance and repayment history.
• LoanSure — another Pico Finance cash-loan app holding comparable contract and schedule records.
• ATS PICO (AEON) — a Pico-licensed lender app with per-borrower loan and repayment data.

How this brief was put together

Drafted from Loan Hub's Google Play listing and product description, the Pico Finance licensing summaries, Thailand's PDPA guidance, and the Bank of Thailand's published Open Data / Your Data material, checked on 2026-06-23. Primary sources:

• Loan Hub on Google Play (com.aavelo.flowfund)
• Bank of Thailand — Open Data / Your Data
• BOT Your Data consultation paper (PDF)
• Pico Finance licensing overview (Thailand)

Mapped by the OpenBanking Studio integration desk · June 2026

Questions integrators ask about Loan Hub

Can you reconstruct Loan Hub's full reducing-balance schedule, not just the outstanding balance?

Yes. The loan-detail screen exposes each installment with its principal and interest split and the carried balance. We replicate the reducing-balance math so a synced schedule reconciles to the satang against what the app displays, then expose installments, due dates and the running balance as clean records.

Loan Hub holds a provincial Pico Finance licence — does that limit what can be integrated?

A Pico licence only limits where the operator may lend, not what a borrower can authorize us to read. We model the contract's province and licence context so records map correctly, and the integration reads the same loan, repayment and KYC data the borrower sees in the app.

Which Thai rules govern reading data out of Loan Hub?

Loan Hub operates under a Ministry of Finance Pico Finance licence and handles personal data under Thailand's PDPA, which requires explicit, withdrawable consent. The Bank of Thailand's Your Data scheme will add a standardized loan-data sharing rail in its later phase; until then the dependable basis is the borrower's own consent.

How fresh can the synced installment and approval status be kept?

Loan Hub gates access behind a phone-OTP session, so we design the sync around the session lifecycle and poll the loan-detail and application-status surfaces on a schedule you set. Installment state, days-past-due and disbursement events stay current within that polling window.

From $300 we hand back the loan-ledger work as source you own — the API over the schedule, application-status and KYC surfaces, runnable Python and Node.js clients, tests and documentation — billed only after delivery, once you have checked it works against a Loan Hub account. Prefer not to run anything yourself? Call our hosted endpoints instead and pay per call, nothing upfront. The turnaround either way is one to two weeks. Tell us it's Loan Hub and what you need out of it on the contact page; access and the PDPA paperwork are sorted out with you as part of the work.