How to integrate Amret accounts and Bakong payments

Amret runs everyday banking for several hundred thousand customers in Cambodia, and the mobile app is the front door to most of it: transfers between Amret accounts, inter-bank money movement, e-wallet top-ups to Wing, True Money and PiPay, loan repayments, new loan requests, phone top-up, bill payments and KHQR scan-to-pay. Two things shape any integration here. The money is dual-currency — a single account holds and moves both Riel and Dollars — and a large share of transfers settle over Bakong, the central bank's instant rail, in a few seconds. An integrator who treats Amret as a plain account API and ignores either of those gets the numbers wrong.

The work we do is authorized interface integration: with the account holder's consent we operate the app's own client-server exchange, normalize what it returns, and hand back runnable code. Where a flow touches the Bakong rail, we reconcile the app's record against the rail's settlement status rather than trusting one side alone.

Reaching Amret account and Bakong data

Three routes apply to this app. They are not mutually exclusive — a real build usually layers two.

1 · Authorized interface integration of the app session

With the customer's authorization we analyze and drive the Amret Mobile client-server protocol — login, token lifecycle, then the calls that back the account dashboard, statement view and the Loans section. This reaches everything the app itself shows: balances, full transaction history, loan accounts and installment schedules, transfer status. Effort is moderate; durability depends on the app's release cadence, so we re-validate after platform updates rather than assuming a frozen contract. This is the route that carries loan and balance detail end to end.

2 · Bakong rail and KHQR interoperability

For transfers, QR payments and their settlement status, the national Bakong system and the KHQR standard are documented interoperability layers maintained by the National Bank of Cambodia. They are stable and well-specified — the right surface for payment generation, deeplink callbacks and confirming that a transfer actually cleared. They do not carry loan schedules or internal balances, so they complement route 1 rather than replacing it.

3 · User-consented session bridging

Where you only need a periodic read for a single consenting account holder — statement pulls, repayment status — we operate an authorized session on their behalf and emit the normalized records. Lighter to stand up, narrower in scope.

For most briefs we build route 1 as the backbone and bolt route 2 onto the payment side, so loan and balance data come from the session while transfer outcomes are confirmed against Bakong. Access — a consenting account or a sponsor sandbox — is arranged with you during onboarding; it is part of the engagement, not something you hand over before we will talk.

What sits behind an Amret login

A worked example: streaming repayment and transfer events

The shape below is illustrative — field names get confirmed during the build, not copied from a public contract. It shows the queue-and-replay pattern we favour for this app: read by cursor, publish to a stream, and let a restarted consumer pick up from its committed offset rather than re-pulling the whole history.

# Authorized, user-consented session against the Amret Mobile backend.
session = AmretClient.authorize(consent=account_holder_grant)

# Read incrementally; the cursor is what makes replay possible.
cursor = store.last_cursor("amret:txn") or "0"
page   = session.transactions(since=cursor, page_size=100)

for txn in page.items:
    event = {
        "ref":       txn.reference,                 # bank reference, stable across reads
        "type":      txn.kind,                      # transfer | loan_repayment | topup | khqr | bill
        "money":     {"amount": txn.amount,
                      "currency": txn.currency},    # never assumed — KHR or USD, kept explicit
        "rail":      txn.via,                        # "bakong" when settled over the national rail
        "loan_ref":  txn.loan_reference,            # set for loan_repayment rows
        "booked_at": txn.posted_utc,
    }
    stream.publish("amret.transactions", event, key=txn.reference)

store.commit_cursor("amret:txn", page.next_cursor)

# For rail-settled rows, confirm against Bakong rather than trusting one side.
# A check-by-hash against the rail closes the gap when the app view lags settlement.

A consumer that dies mid-batch restarts from the last committed cursor and re-reads only what it had not yet processed, so no transfer is silently lost. That replay guarantee is the main reason we model Amret as a stream rather than a nightly dump.

What lands in your repo

The headline deliverable is code that runs against this app, not a binder:

• Runnable client in Python, Node.js or Go for the authorized session, transaction reads and loan-schedule pulls.
• The cursor-paged stream consumer above, wired to your queue of choice, emitting normalized dual-currency events with stable references.
• Webhook handlers for KHQR deeplink and payment-status callbacks, so a completed scan-to-pay lands as an event in your system.
• An automated test harness running against recorded fixtures, so a changed field on the Amret side shows up as a failing assertion rather than a quiet data drift.
• Then the supporting documents: an OpenAPI/Swagger description of the normalized surface, a protocol and auth-flow report covering the token and session chain, interface documentation, and data-retention guidance.

What we account for on an Amret build

Specifics of this app that we handle so you do not have to discover them in production:

Dual currency is structural, not a setting

Riel and Dollar amounts coexist on one account and even on one KHQR code. We carry money as an explicit amount-plus-currency pair from the first read to the last write, and never normalize to a single unit. A loan repaid in KHR and a USD inter-bank transfer stay separable through your ledger.

The app rides the Bank Genie platform

Per its Android package identifier (com.bank_genie.geniemobile_amret), the Amret app is built on the Bank Genie platform. We map that platform's session and token-refresh model so the integration tracks auth the way the app actually does, and we re-validate the protocol after app updates instead of assuming the contract is frozen.

App view versus rail settlement

Bakong settles in seconds, but the app's own activity list can lag the rail briefly. We design the sync to reconcile each rail-settled event against Bakong's status, so a transient mismatch resolves on the next read rather than becoming a permanent discrepancy in your books.

Authorization and the NBC payment framework

Cambodia does not run a PSD2-style consumer-data-sharing mandate, so the dependable footing for reading an individual's Amret data is that person's own authorization, recorded and revocable. We work only from authorized, documented or user-consented access, log consent, minimize what we pull to the fields a project needs, and sign an NDA where the engagement calls for one. On the payments side, Bakong and KHQR sit under the National Bank of Cambodia's payment-services framework — the Prakas on Payment Service Providers and the rules around the Bakong system — which is why we treat the rail's documented behaviour, not guesswork, as the source of truth for settlement status. Consent can be withdrawn; when it is, the session route stops and the records it produced are retired per the retention terms we agree.

Working with us

A first runnable drop for Amret typically lands inside one to two weeks of access being arranged. Source-code delivery starts at $300: you receive the client, the stream consumer, the test harness and the interface docs, and you pay only after delivery, once it works for you. If you would rather not host anything, call our endpoints instead and pay per call with nothing upfront. Tell us the app and what you need from its data; access and the compliance paperwork are arranged with you as part of the work. Start a conversation about an Amret integration.

Screens we mapped

The public store screenshots we reviewed while scoping the surfaces above:

Other Cambodian banking apps in the same integration set

An integrator covering Amret usually wants neighbours on the same rail. These hold comparable account and transaction data and connect to Bakong/KHQR, so a unified ingestion layer can normalize them together:

• ACLEDA Bank — one of Cambodia's largest commercial banks; its mobile app is consistently a top finance app and holds full retail account and transfer data.
• ABA Bank — among the most widely used consumer banks, with rich account, card and QR-payment activity.
• Wing Bank — grew from money transfer into a licensed bank; strong e-wallet and agent-network transaction data.
• AMK Microfinance — a peer MDI with savings, loan and transfer records similar in shape to Amret's.
• Prasac — large deposit-taking institution, now under KB, with extensive loan and account ledgers.
• Sathapana Bank — full-service bank with microfinance roots and comparable repayment data.
• Hattha Bank — MDI-turned-bank holding loan accounts and KHQR payment flows.
• True Money Cambodia — e-wallet with top-up, bill-payment and transfer history that frequently appears alongside Amret as a partner.

How this brief was put together

Scoped on 2026-06-01 from Amret's own product pages, the National Bank of Cambodia's Bakong material, and the public Bakong/KHQR integration documentation, cross-checked against Amret's corporate profile for institution type and ownership. Figures such as client count and asset size are taken from Amret's published profile and stated as the institution describes them, not independently audited here. Sources opened:

• Amret Mobile App — feature list (amret.com.kh)
• Bakong — National Bank of Cambodia
• Bakong Open API integration documentation (PDF)
• About Amret — institution profile and shareholders

Compiled by OpenFinance Lab — engineering notes, 2026-06-01.

Questions integrators ask about Amret

Can Amret transactions be streamed close to real time, or only pulled in batches?

We run an authorized session against the app backend and read transactions by an incrementing cursor, then publish each one onto a stream your services consume. Because the consumer commits an offset, a restarted worker replays from the last committed point instead of dropping events. Where a flow settled over Bakong, we reconcile the app record against the rail's status so a momentary lag closes on the next read.

How is the KHR / USD dual-currency behaviour handled in the data you deliver?

Amret and the KHQR standard both carry Khmer Riel and US Dollar amounts, sometimes on a single QR. We never collapse money to one currency: every amount is delivered as an explicit amount plus currency pair, so a KHR repayment and a USD transfer stay distinct through your ledger.

Does the Bakong/KHQR rail expose loan repayment schedules as well as transfers?

No. The national rail carries transfers, QR payments and their settlement status. Loan accounts, installment schedules and repayment history live behind the Amret account itself, so those come from the authorized session route rather than the rail. We layer the two: rail for payment status, session for loan and balance detail.