The borrower data behind PakinSpeed, and the authorized way in

A PakinSpeed account carries up to around 40,000 baht of credit line, a 91-to-365-day repayment schedule, and the daily-accrual interest figure the app surfaces before a borrower confirms — per the operator's Play Store listing. None of that sits in a form an outside system can read on its own. The operator, AURORA FIN SYNERGY COMPANY LIMITED of Bangkok, runs the platform under Bank of Thailand supervision and treats borrower records as sensitive personal data under Thailand's PDPA. So the interesting question for anyone wanting to sync this data is not what PakinSpeed stores; it is which authorized route reaches it, and how soon. This page works through that for one app.

The short version: borrower-side loan, repayment and disbursement records all exist server-side, reachable today through an authorized read of the customer's own session, and the regulated BOT channel is arriving but not yet carrying loan data. We would build against the session now and design the output so it migrates onto the BOT route later without a rewrite. The rest of this brief shows the data, both routes, and exactly what gets handed over.

What a PakinSpeed account actually holds

These are the surfaces the app exposes to its own user, named the way PakinSpeed presents them. An integration reads the same records the borrower sees, under that borrower's authorization.

BOT supervision, the PDPA, and where 'Your Data' sits

Two things shape the legal route. First, AURORA FIN SYNERGY operates under Bank of Thailand supervision and the app frames its data handling around Thailand's Personal Data Protection Act — the PDPA classifies borrower identity and financial records as sensitive personal data, which means access has to be consent-based and logged, not scraped. Second, the BOT is standing up a regulated data-sharing regime. Its Your Data programme, announced in October 2024 and given effect by a regulation the central bank enacted on 30 October 2025, lets a consumer direct a provider to share their deposit, loan and payment records with another provider through a standardized, consented API.

The catch is timing. Per the BOT's Open Data material, providers enable the mechanism gradually from the end of 2026, beginning with individual deposit-account information, and loan records fall into the phased expansion across 2027 and 2028. For a loan platform like PakinSpeed that means the regulated channel is the durable destination, not a feed you can call this quarter. The dependable basis for reading the data today is the borrower's own authorization over their session; the BOT route is where that read migrates as the scheme reaches loan data.

Routes into the loan ledger

Two routes genuinely apply here, plus a fallback. We set up access with you as part of the work — a consenting borrower account, or the sandbox a participant gets — so onboarding is our step, not a form you fill first.

1 · Authorized interface integration of the borrower session

PakinSpeed's app talks to its backend at pakinspeed.aurorafinsynergy.co over an authenticated session. Under the account holder's authorization we reconstruct that exchange — the OTP-to-token handshake, then the calls that return loan summary, schedule and transaction history — and wrap it as a clean API. Reachable now: everything the borrower can see. Effort is moderate; durability depends on the app's release cadence, which the maintenance pass covers.

2 · BOT 'Your Data' consented sharing

As loan records come into scope under the BOT regime, the same borrower consent can flow through the central bank's standardized channel instead of the app session. Reachable: whatever the scheme mandates for loan and payment data, on a regulated footing with revocation built in. Effort is lower per-field once it is live; the constraint is the 2027–2028 timeline, not the engineering.

3 · In-app disclosure capture (fallback)

The app discloses full terms — APR, fees, the repayment table — before a borrower confirms. Where a structured read is not needed, that disclosure can be captured and normalized as a lighter-weight fallback for contract terms specifically.

What we would actually recommend for PakinSpeed: build route 1 now so you have loan and repayment data flowing this cycle, and shape the normalized schema to match what the BOT channel will expose, so route 2 becomes a connector swap rather than a second project. The fallback only earns its place if all you need is contract terms.

A session call, sketched

Illustrative shapes for the session route — field names are confirmed during the build, not assumed from the outside. The auth chain is an OTP-issued bearer token; reads carry it forward.

# 1. Exchange phone + one-time code for a short-lived session token
POST /api/v1/auth/otp/verify
  { "msisdn": "+66xxxxxxxxx", "otp": "######" }
  -> 200 { "access_token": "…", "expires_in": 900, "customer_ref": "…" }

# 2. Read the loan summary the borrower sees (bearer token)
GET /api/v1/loan/summary
  Authorization: Bearer 
  -> 200 {
       "currency": "THB",
       "credit_limit": 40000,
       "outstanding": 18234.50,
       "apr_pct": 14.4,
       "status": "active",                # submitted | approved | active | closed
       "schedule": [
         { "due": "2026-07-15", "principal": 6000.00, "interest": 78.90 },
         { "due": "2026-08-15", "principal": 6000.00, "interest": 71.20 }
       ]
     }

# Error handling that matters here:
#  - 401 -> token expired (~15 min); re-run OTP exchange, do not retry blind
#  - 429 -> OTP/verify is rate-limited; back off, never brute the code path
#  - status "submitted" carries no schedule -> not yet an active loan
      

What lands in your repo

Tied to the surfaces above, not a generic checklist:

• An OpenAPI/Swagger spec for the loan-summary, schedule and transaction reads, with the THB money fields typed and the status enum documented.
• A protocol and auth-flow report describing the OTP-to-token chain, token lifetime, and how the session is renewed.
• Runnable source for the key endpoints in Python or Node.js — your choice — including the OTP exchange, the loan read, and pagination over transaction history.
• Automated tests covering the application-state transitions (submitted, approved, active, closed) and the daily-interest reconciliation.
• Interface documentation, plus PDPA-aligned notes on consent capture, access logging and a retention window.

Engineering notes we account for

Specific to this app, and handled on our side:

• Session lifecycle. The OTP-issued token is short-lived, so we build the sync to re-authenticate cleanly on a 401 rather than letting a pull silently expire mid-run.
• Loan-state modelling. A request that is submitted but not yet disbursed carries no repayment schedule. We model the state machine explicitly so an in-progress application is never read as an active loan with a zero balance.
• Daily-accrual math. The app derives interest as APR ÷ 365 × days — the same arithmetic behind its 20,000-baht example. We replicate it so amounts we expose reconcile to the figure the borrower confirmed, baht for baht.
• PDPA minimization. Because identity and loan data are sensitive personal data, we scope the read to the fields you use and keep consent and access logs, with an NDA where the engagement needs one.

Keeping the sync honest

Loan balances and schedules move on a daily cadence, so the integration is built around scheduled reads with conditional fetches rather than constant polling. Two failure modes get explicit handling: the app changing its front end or token format, caught by a versioned parser and a re-validation pass; and OTP throttling, where we back off instead of hammering the verify path. Reads of repayment history are treated as idempotent, so a re-run reconciles rather than double-counts.

Pricing, and how we ship

Source-code delivery for PakinSpeed starts at $300, and you pay only after the integration is in your hands and the loan and repayment reads work against a consenting account — runnable source, the OpenAPI spec, tests and the interface docs included. If you would rather not host anything, the alternative is our pay-per-call hosted API: you call our endpoints, you pay for the calls you make, and there is no upfront fee. A typical build runs one to two weeks. Tell us the app and what you need from its data and we scope it from there — start a conversation here.

Screens we mapped

Store screenshots used while scoping the surfaces above. Tap to enlarge.

Other Thai lending apps in the same data picture

If you are aggregating consumer-credit data across the Thai market, these sit in the same category and hold comparable per-borrower records. Named for context, not ranked.

• FINNIX — MONIX's microloan and revolving credit-line app; holds limit, draw and repayment history per user.
• MoneyThunder — SCB Abacus's AI-underwritten unsecured lending app, with approval and installment records.
• LINE BK — the KBank and LINE venture, carrying a personal Credit Line and nano-finance balances.
• Krungsri i-FIN — Krungsri's personal-loan app, holding account terms and repayment schedules.
• MyMo by GSB — the Government Savings Bank app, with deposit and loan account data side by side.
• TrueMoney — wallet plus lending features, holding balances and transaction history.
• KTC — credit-card and nano/pico-finance balances and statements.
• SCB EASY — Siam Commercial Bank's banking app, spanning accounts, transfers and loan products.

Questions integrators ask about PakinSpeed

PakinSpeed shows an APR up to 14.4% and a 40,000-baht ceiling. Can the integration read those per-contract figures, not just a balance?

Yes. The disclosure the app shows before you confirm carries the APR, the fees and the principal-versus-interest split for each installment, alongside the outstanding figure. We map those fields so your system reconciles to the exact terms the borrower agreed to, with field names confirmed during the build rather than assumed.

Does the Bank of Thailand 'Your Data' regime mean a lender should wait for the regulated channel before integrating PakinSpeed?

The BOT Open Data rules cover loan and payment data but phase in gradually from the end of 2026, starting with individual deposit accounts and expanding to other records across 2027 and 2028. The authorized session-level route reads PakinSpeed now and is built so the same normalized output can move onto the BOT channel once loan records are carried there.

How does Thailand's PDPA change what we can pull and keep from PakinSpeed?

Borrower identity and loan information are sensitive personal data under the PDPA, so access is consent-based and logged, the pull is scoped to the fields you actually use, and a retention window is agreed with you. We keep consent and access records as part of the handover.

If PakinSpeed ships an app update, does the integration stop working?

A front-end or token change can move field names or alter the OTP handshake. We version the parser and include a re-validation step in maintenance, so a release does not quietly halt your loan-status pulls without anyone noticing.

How this brief was put together

Scoped on 23 June 2026 from the PakinSpeed Play Store listing (operator, product terms and contact details), the Bank of Thailand's Open Data material and its 30 October 2025 data-sharing regulation, and Thai PDPA references for the consent and sensitive-data treatment. Primary sources opened:

• PakinSpeed on Google Play
• Bank of Thailand — Open Data
• BOT — data-sharing right enacted (Oct 2025)
• Chambers Banking & Finance 2025 — Thailand

Compiled by the OpenBanking Studio integration desk — reviewed 23 June 2026.