Reaching account and payment data inside Hattha Bank's mobile app

Hattha Bank received a commercial banking licence from the National Bank of Cambodia in 2020 and runs as a Krungsri company — Bank of Ayudhya in Thailand, part of the MUFG group, which acquired the former Hattha Kaksekar microfinance institution in 2016 (per its Wikipedia entry). That lineage matters for an integrator, because the app's most distinctive data is not just balances. It carries a working cross-border leg into Thailand over Krungsri rails, and it sits on the NBC's Bakong network for interbank KHQR transfers. Two currencies, a domestic rail, and an FX rail all show up in one transaction list.

The bottom line for a team that wants Hattha data: there is no Cambodian open-data mandate to plug into, so the path is a consented integration of what the app itself shows a logged-in customer. That is routine work for us. The session exposes the same balances, transaction detail and statement downloads the user sees, plus the KHQR and cross-border records that make this app worth integrating in the first place. Below is the data, the route we would take, what we hand back, and the things a Hattha build has to account for.

Account data the app puts in front of a logged-in user

Each row below names the surface the way the app's own listing describes it, where the record originates, how fine-grained it is, and what an integrator does with it.

Routes to that data that actually apply here

Consented interface integration and protocol analysis

This is the spine of a Hattha build, and the one we would recommend. We work against the authenticated mobile session, map its login and token handshake, and model the request and response shapes behind balances, transaction detail, statements and KHQR records. Reach is everything the app shows. Effort is moderate. Durability is tied to app releases, which we account for in upkeep. Access — a consenting Hattha account or test credentials — is arranged with you during onboarding; it is part of the project, not something you have to line up first.

User-consented read-only sync

Where the goal is ongoing balance and transaction sync rather than one-time extraction, we run the same integration in a scheduled, read-only posture under the account holder's consent. This suits aggregation and accounting feeds. It carries the same release-tracking maintenance as the route above.

Native statement export as a batch fallback

The app already lets a customer download statements. Driven on a schedule, that becomes a low-effort batch path for teams that only need periodic, document-level data. It is slower and coarser than the session route, so we treat it as a complement, not the primary plan.

For most teams the consented session integration is what gets built, with statement export wired alongside it for backfill and reconciliation. We would put the session route at the centre and use export to fill gaps, and we say so plainly when we scope the work.

What lands in your hands at the end

The deliverable is a working integration for Hattha Mobile, not a report. Concretely:

• An OpenAPI/Swagger specification covering the endpoints behind balances, transaction detail, statement retrieval and KHQR records.
• A protocol and auth-flow report: the login exchange, token or cookie chain, refresh behaviour, and the currency tagging that runs through Hattha's KHR/USD records.
• Runnable source for the key calls in Python and Node.js — authenticate, list accounts, page transactions, fetch a statement, read a KHQR transfer.
• Automated tests against representative responses, including the dual-currency and cross-border cases.
• Interface documentation an in-house team can extend, plus data-retention and consent-logging guidance for Cambodian operation.

A balance-and-KHQR pull, sketched

Illustrative shapes only — field names and the exact handshake are confirmed during the build against the live session, since Hattha revises the app often. The point is the structure an integrator should expect: a token step, currency-tagged amounts, and a separated cross-border leg.

POST /auth/login
  { "username": "<deposit-acct>", "device_id": "<bound>", "otp": "<sms>" }
  -> 200 { "access_token": "...", "refresh_token": "...", "expires_in": 900 }

GET /accounts            (Authorization: Bearer <access_token>)
  -> [ { "acct": "0012...", "type": "savings", "ccy": "USD", "balance": 1840.55 },
       { "acct": "0007...", "type": "savings", "ccy": "KHR", "balance": 742000 } ]

GET /accounts/0012.../transactions?from=2026-04-01&to=2026-04-30
  -> [ { "id": "...", "ts": "2026-04-12T09:21:00+07:00",
         "ccy": "USD", "amount": -25.00, "channel": "KHQR",
         "counterpart": { "scheme": "BAKONG", "qr_id": "..." } },
       { "id": "...", "ts": "2026-04-18T14:03:00+07:00",
         "type": "cross_border_TH",
         "legs": [ { "ccy": "USD", "amount": -100.00, "leg": "domestic" },
                   { "ccy": "THB", "amount": 3550.00, "leg": "fx",
                     "rail": "KRUNGSRI_TH" } ] } ]

# error handling: 401 -> refresh once, then re-auth; 423 -> account
# locked, surface to caller; 429 -> backoff, respect retry-after

Cambodian rules that shape this

Hattha Bank is supervised by the National Bank of Cambodia, which issued its 2020 banking licence (per Wikipedia and the bank's stated history). Interbank and QR movement runs over Bakong, the NBC's interoperable payment backbone, and the KHQR standard the NBC publishes for participating institutions. Cambodia does not run a PSD2-style consumer data-portability regime, and as of this writing a comprehensive personal-data-protection statute is still in preparation rather than in force, so the legal anchor for this work is the account holder's own consent plus the bank's confidentiality obligations. We do not assert a numeric threshold or a switch-on date that Cambodian law has not settled.

Practically, that means access is user-consented and authorized, with a consent record and request logs kept, data minimized to what the integration actually needs, and an NDA in place where the engagement calls for one. This is how we operate, not a checklist handed to you.

What a Hattha build has to plan around

Two things specific to this app drive design decisions, and we handle both rather than passing them back as conditions.

KHR and USD live side by side

A single customer commonly holds both a riel and a dollar account, and amounts move between them. Khmer riel and US dollar values differ by orders of magnitude and by minor-unit handling, so we keep an explicit currency tag on every account and every transaction through normalization, and we never scale a riel figure into a dollar field. Bakong and KHQR records carry a currency identifier; we preserve it end to end.

The Thailand leg is not a single line

A cross-border payment to Thailand can produce a domestic debit and an FX conversion over Krungsri rails from one user action. We model it as separated legs with the FX rate attached, so reconciliation and remittance reporting stay correct instead of collapsing into one ambiguous amount.

The app reworks itself between versions

The Play listing's own notes describe a full 3.0 rework for performance and experience. When Hattha ships a new build, response field names and the login handshake can shift, so we keep a versioned capture of the flow and re-check it on each release as part of ongoing maintenance — the integration is built to be re-validated, not assumed stable forever.

What teams build on top of this

• An accounting tool that ingests a Cambodian SME's Hattha statements and transaction detail nightly, split by KHR and USD ledgers.
• A remittance dashboard that tracks Thailand-bound payments with the FX leg and Krungsri counterpart shown separately from the domestic debit.
• A reconciliation service that matches inbound KHQR transfers against invoices using the Bakong QR identifier.
• A treasury view that aggregates Hattha balances alongside other Cambodian bank accounts into one consented feed.

Screens this brief was mapped from

Store screenshots used to confirm the surfaces named above. Select one to enlarge.

How this brief was checked

Surfaces were taken from Hattha Mobile's own Play Store listing and screenshots. Corporate structure, the National Bank of Cambodia licence and the Krungsri/MUFG lineage were read from the bank's Wikipedia entry and a Krungsri banking-news item, which also gave the 2022 figures cited here. The Bakong and KHQR framing comes from the NBC's published KHQR integration material. Sources opened:

• Hattha Bank — Wikipedia (history, NBC licence, Krungsri/MUFG ownership)
• Krungsri — Hattha Bank mobile banking (cross-border to Thailand, 2022 registration figures)
• National Bank of Cambodia — KHQR Content Guideline (Bakong/KHQR integration spec)
• Hattha Mobile — Google Play listing (feature set, 3.0 release note, package id)

Mapping reviewed 2026-05-16 by the OpenBanking Studio integration desk.

Other Cambodian bank and wallet apps in the same space

Named for ecosystem context — a unified integration usually spans several of these, since Cambodian customers and merchants hold accounts across them and they share the Bakong/KHQR rails.

• ABA Mobile — ABA Bank's app; balances, transfers, ABA Pay QR and merchant data, one of the most used finance apps in Cambodia.
• ACLEDA mobile — ACLEDA Bank; deposit accounts, loans, transfers and KHQR, with broad rural reach.
• Wing Bank — wallet and bank accounts, agent network, bill pay and top-up records.
• Bakong — the NBC's own wallet app on the Bakong backbone; interbank transfers and KHQR at the rail level.
• Sathapana Mobile — Sathapana Bank; accounts, transfers and statement data for retail and SME users.
• Canadia Bank — Canadia Bank's app; accounts, cards and QR payment history.
• J Trust Royal Mobile — J Trust Royal Bank; retail and business account data, transfers and statements.
• Pi Pay — a Cambodian payment wallet; QR payments, top-up and merchant transaction records.

Questions integrators raise about Hattha Mobile

Can the integration keep KHR and USD balances separate for the same customer?

Yes. Hattha accounts run in both Khmer riel and US dollars, and a customer often holds both. We carry the currency tag per account and per transaction through normalization, so a USD bill payment and a KHR transfer never get merged into one figure.

Does a cross-border payment to Thailand arrive as one record or as separate legs?

The Thailand path runs over Krungsri and Thai QR rails, so a single user action can produce a domestic debit and an FX conversion. We split and label those legs rather than flattening them to one amount, which keeps reconciliation honest.

We already download statements from the app by hand — can that become a feed?

Yes. The app's print and download statement function is a workable batch fallback we can drive on a schedule. The durable path is the authenticated session integration, which gives transaction-level data without waiting for a statement cycle.

What is the Cambodian regulatory backdrop for this work?

Hattha Bank is licensed and supervised by the National Bank of Cambodia, and interbank and QR movement runs over the NBC's Bakong system and the KHQR standard. There is no consumer data-portability mandate in Cambodia, so access is user-consented and authorized, with consent and logs kept as a matter of how we operate.

Source code lands at the end, and you pay for it after you have seen it run — from $300 for a delivered Hattha Mobile build, settled once you are satisfied it works. The other option skips delivery entirely: call our hosted endpoints for Hattha data and pay only per call, with nothing up front. A build of this kind runs one to two weeks. You give us the app name and what you need from its data; the consenting account, credentials and compliance paperwork are arranged with you as part of the work. Start by telling us the requirement at /contact.html, and we will come back with the route and the scope for your case.