How a third party gets structured data out of M-PAiSA

Since 14 October 2024, money moves directly between M-PAiSA and Fijian bank accounts over the Reserve Bank's National Payment System, per Vodafone Fiji's own notice and the Reserve Bank's go-live release. A wallet that used to be a closed loop now records bank-side counterparties alongside local transfers, QR receipts and inbound remittances. That is the practical reason a fintech, a lender, an accounting tool or a remittance operator wants a clean feed out of it.

M-PAiSA is Vodafone Fiji's mobile money account, running since 2010 per UN Capital Development Fund coverage. It does not need a bank account to open, it carries per-user balances and a full transaction ledger, and it now bridges to the national rail. The question this brief answers is narrow: what data sits in an M-PAiSA account, and what is the authorized way to read it for a third party that has the account holder's consent.

M-PAiSA at a glance for an integrator

The short version: route the work through a consenting account, read what the app itself shows that user, and normalize the ledger so a downstream system can tell a remittance from a bill payment from an NPS bank transfer. That is the spine of every M-PAiSA build we have scoped.

What sits inside an M-PAiSA wallet

Everything below is visible to the account holder inside the app today. The integrator's job is turning it into a stable, typed feed.

Reaching that data under the account holder's consent

Three routes apply to M-PAiSA. Which one leads depends on whether the client holds the account, runs the merchant, or sits on the national rail.

Consented interface integration / protocol analysis

This is the working route for almost every case. We analyse the app's own traffic against a consenting account: a mobile-number plus PIN sign-in, an OTP step, and a session that the feed renews on its own. Reachable: everything the user sees — balance, the full ledger, statement export, QR receipts, IMT credits, NPS transfers. Effort is medium and concentrated in the auth chain. Durability tracks the app front end, so we keep a check that flags surface changes and refresh the parser as upkeep. Access is arranged with you during onboarding, against a consenting account or a test number — that setup is our step, not a hoop you clear first.

In-app statement export

The app lets the holder download about six months of statement. We script that export and parse it. It is low effort and stable, but historical only and capped at the window. We use it to backfill and to sanity-check the live feed, not as the live feed.

Bank-side NPS reconciliation

If the client is itself a bank or PSP on the National Payment System, the M-PAiSA leg of an NPS transfer is already visible from their own rail. We normalize both sides so a transfer reconciles end to end. This only reaches NPS bank-to-wallet movement, not in-wallet activity.

In practice we build the consented integration as the live spine, use the statement export to seed and audit history, and only touch the NPS path when the client already operates on that rail. The recommendation is rarely a single route — it is route one carrying the feed with route two underneath it.

What a statement pull looks like

Illustrative shape only; exact field names and the OTP handshake are confirmed against the live app during the build.

POST /m-paisa/auth/login
{ "msisdn": "679XXXXXXX", "pin": "••••" }
-> 200 { "challenge": "OTP", "txnRef": "a1f9..." }

POST /m-paisa/auth/otp
{ "txnRef": "a1f9...", "otp": "######" }
-> 200 { "session": "<token>", "expiresIn": 900 }

GET /m-paisa/account/transactions?from=2025-11-01&to=2026-05-17
Authorization: Bearer <token>
-> 200 {
     "balance": { "currency": "FJD", "amount": 412.55 },
     "items": [
       { "id":"TX...", "ts":"2026-05-15T09:21:04+12:00",
         "type":"IMT_IN", "corridor":"AU-FJ",
         "counterparty":"sender_ref", "amount":250.00,
         "balanceAfter":412.55 },
       { "id":"TX...", "ts":"2026-05-14T17:03:00+12:00",
         "type":"NPS_BANK_OUT", "counterparty":"ANZ",
         "amount":-100.00, "fee":-0.50, "balanceAfter":162.55 }
     ],
     "nextCursor": null
   }

# session expiry (900s) and OTP re-challenge are handled
# by the client so the feed re-auths without a person in the loop

What lands at the end of the build

Concrete artefacts, each tied to a real M-PAiSA surface:

• An OpenAPI specification covering login, OTP, balance, transaction ledger and statement export as the app exposes them.
• A protocol and auth-flow report documenting the MSISDN plus PIN plus OTP chain, session lifetime, and renewal behaviour.
• Runnable source for the key endpoints in Python and Node.js — authenticate, pull balance, page the ledger, fetch and parse the statement.
• A normalizer that types each record (P2P, bill, QR, IMT-in, NPS-bank, cross-operator) with FJD amounts and running balance.
• Automated tests against recorded fixtures, including the OTP re-challenge and NPS limit and fee cases.
• Interface documentation plus consent and data-retention guidance written for Fiji's payments framework.

Where teams plug an M-PAiSA feed in

• A remittance operator confirming that an inbound corridor credit actually settled into the recipient's wallet, separate from local transfers.
• A lender or scoring tool reading six-plus months of ledger to assess cash flow where the applicant has no bank statement.
• A merchant's accounting system importing QR settlement so M-PAiSA sales reconcile against the till.
• A treasury team matching the bank side of an NPS transfer to the wallet side after the October 2024 link.

The shape we normalize transactions into

{
  "txnId": "TX-2026-0007781",
  "postedAt": "2026-05-15T09:21:04+12:00",
  "type": "IMT_IN",            // P2P | BILL | QR_MERCHANT |
                               // IMT_IN | IMT_OUT | NPS_BANK | XOP
  "direction": "credit",
  "amount": { "value": 250.00, "currency": "FJD" },
  "fee": { "value": 0.00, "currency": "FJD" },
  "counterparty": { "label": "AU-FJ corridor", "ref": "sender_ref" },
  "channel": "imt",
  "balanceAfter": { "value": 412.55, "currency": "FJD" }
}

Fiji's payments rulebook and how consent works here

The Reserve Bank of Fiji oversees payment services under the National Payment System Act 2021 (Act No. 4 of 2021), which the Reserve Bank states came into effect on 30 September 2022. Under it, providers handling e-money issuance, merchant acquiring, domestic and cross-border money transfer, and account issuance are licensed by the Reserve Bank. Fiji has not introduced a consumer open-banking or account-information-services regime, and there is no general data-portability right to invoke. So the lawful basis for reading an M-PAiSA account is the account holder's own consent to their own wallet — not a regulator-granted data-sharing entitlement.

We operate that way as standard: access is authorized and documented, consent is recorded with scope and revocation, work runs under NDA where the client needs it, and the feed is minimized to the fields the use case requires. KYC identity matters here because M-PAiSA limits and the NPS leg are tied to verified account holders; we treat that as a design input, handled with you, not a gate placed in front of you.

What we account for on an M-PAiSA build

• The sign-in is mobile number plus PIN plus an OTP step. We design session and renewal around that OTP so the feed re-authenticates cleanly without a person each time; the consenting account or test number is set up with you during onboarding.
• The NPS limits Vodafone publishes — roughly FJD 1,000 per transfer and FJD 2,000 daily outbound, FJD 5,000 per transfer and FJD 10,000 daily inbound, plus a small per-transfer fee on the outbound leg — are modelled so reconciliation across the October 2024 boundary does not read a split transfer or the fee line as missing money.
• The in-app statement covers about six months. We treat that as the backfill ceiling and persist the live feed beyond it, so history is not silently truncated at six months.
• IMT credits, cross-operator M-PAiSA-to-MyCash transfers, QR payments and local P2P all land in one list. We tag each by type during normalization so downstream consumers can split flows the app shows together.
• The app front end changes. A validation check flags when its surface shifts, and refreshing the parser is part of ongoing upkeep rather than a surprise.

What we checked, and when

This brief draws on Vodafone Fiji's National Payment System page (the 14 October 2024 go-live, transfer limits and the per-transfer fee), the Reserve Bank of Fiji's mobile-wallet integration go-live release, the UN Capital Development Fund write-up on M-PAiSA features and the 2010 launch, and the Reserve Bank's page for the National Payment System Act 2021. Figures such as monthly inbound remittance value and registered-user counts are reported by Vodafone and UNCDF and are cited as such, not asserted independently.

Vodafone Fiji — M-PAiSA National Payment System · Reserve Bank of Fiji — Mobile Wallet Integration go-live · UNCDF — new M-PAiSA features in Fiji · Reserve Bank of Fiji — National Payment System Act 2021

Mapped by the OpenBanking Studio integration desk, May 2026.

The wider Pacific wallet and remittance picture

M-PAiSA sits in a small, interconnected set of Pacific money services. A buyer integrating one of these usually wants the others normalized to the same shape eventually.

• MyCash — Digicel's mobile wallet across Fiji, Samoa, Tonga and Vanuatu; holds wallet balances, transfers, bill and merchant payments, and connects to Fiji's National Payment System.
• CellMoni — Digicel's wallet used heavily in Papua New Guinea for inbound remittance and everyday payments.
• M-Vatu — Vodafone's mobile money in Vanuatu, a direct corridor counterpart for M-PAiSA outbound transfers.
• E-Moni — the Cook Islands mobile wallet linked to M-PAiSA for direct mobile-to-mobile remittance.
• KlickEx Pacific — a long-running Pacific remittance and top-up service that moves funds toward wallets like these.
• WorldRemit — an international transfer service that pays out into Pacific mobile wallets.
• Rocket Remit — Australia-based remittance into Fiji and Samoa mobile money.
• mHITs — a mobile remittance service that delivers into Vodafone M-PAiSA.
• Xe Money Transfer — cross-border transfers that can land in Pacific Digicel wallets.

Screens we worked from

Questions integrators ask about M-PAiSA

Can the feed tell an inbound international remittance apart from a local M-PAiSA transfer?

Yes. IMT credits, local wallet-to-wallet transfers, QR merchant payments, bill payments and the bank-side NPS legs all land in the same transaction list inside the app, so we tag each record by type during normalization. Downstream you get IMT-in, P2P, QR, bill and NPS-bank as distinct categories rather than one undifferentiated stream.

Since the October 2024 National Payment System link, do bank-to-wallet transfers read differently from wallet-to-wallet ones?

They carry a bank counterparty and sit under the NPS limits Vodafone publishes — about FJD 1,000 per transfer out and FJD 5,000 in, with a small per-transfer fee on the outbound leg. We model those limits and the fee so reconciliation across the NPS boundary does not read a split transfer or the fee line as a discrepancy.

Is the roughly six-month statement in the app a hard ceiling on history we can get?

It caps the backfill, not the live feed. We use the in-app statement export to seed history, then capture and persist new transactions continuously so your store keeps growing past six months instead of rolling off.

Fiji has no open-banking mandate — on what basis would you read the account?

On the account holder's own consent to their own wallet, arranged with you during onboarding, under NDA, logged, and scoped to the data you actually need. Fiji regulates payments through the Reserve Bank under the National Payment System Act 2021 but has not introduced a consumer data-sharing right, so consent here is contractual rather than regulator-granted.

A working M-PAiSA build is one to two weeks. Take it as runnable source for the wallet's endpoints — login, OTP, balance, ledger, statement export — with the OpenAPI spec, the normalizer and tests, for a fee from $300 that you settle only after delivery once it does what you need; or skip the build and call our hosted M-PAiSA endpoints, paying per call with nothing upfront. Tell us the wallet and what you want out of it on our contact page and we will scope it.