FunZ keeps wallet, tag-transfer and bill-payment records behind one Nigerian login

Nigeria's Open Banking Registry and its central consent system are not switched on yet. A nationwide go-live slipped from August 2025, and Open Banking Nigeria's own write-up puts a phased start in early 2026. That timing is the first thing that decides how you reach FunZ data today: the regulated account-information rail is the destination, not the road you can drive this quarter. Meanwhile FunZ already holds a working set of per-user financial records — a funded wallet, a virtual account number, transfers addressed by FunZ tag, bill and ticket purchases, and a points ledger — all behind a single authenticated login, per its App Store and Google Play listings and the publisher's own blog.

The honest bottom line: there is real, structured, per-account data inside FunZ worth syncing, and a clean authorized path to it. Because the Nigerian regulated rail is mid-rollout, the route that produces a working integration in the next one to two weeks is documented analysis of the app's own authenticated traffic, with the output shaped so it switches onto the CBN rail later without a schema change. We tell you which fields are solid and which depend on a consenting account before any code is written.

Data FunZ keeps server-side

Each row below is a surface the app exposes to its own signed-in user, named the way FunZ names it where the listings make that clear.

Getting to that data — the routes that apply

Authorized interface analysis (recommended now)

We capture and document the FunZ app's own authenticated calls under your written authorization, decode the auth chain — a login-issued bearer token plus a separate transaction-PIN step-up for money movement — and map the endpoints behind wallet, transfers, bills and tickets. Reachable: everything the app shows its user. Effort: moderate, mostly in auth and the tag-resolution logic. Durability: medium; client releases can move fields, so we ship a re-validation suite with the code. We arrange capture access with you during onboarding against a consenting account — that setup is part of the job, not something you hand over first.

Regulated AIS via Nigerian open banking (forward path)

Once FunZ or its settlement bank is listed on the CBN Open Banking Registry and the central consent system is operating, account, balance and transaction data can be drawn through the standardized rail with BVN-anchored consent. Reachable: the regulated account and transaction set. Durability: high once live. We build today against the Open Banking API Standard v1 field shapes so moving onto this rail is configuration and a consent-flow swap, not a rebuild. Status is tracked for you so the cutover is planned, not reactive.

User-consented credential sync

For an ongoing feed where a consenting FunZ account is available, we run the documented flow on a schedule with the account holder's permission, refreshing tokens and re-validating consent before it lapses.

Native records as a fallback

Where FunZ produces its own transaction records and merchant history, those exports anchor a baseline reconciliation and a test oracle for the live integration.

The route that gets you a running integration this fortnight is the first one, engineered so the second becomes a switch rather than a second project. We say so plainly in the brief and design the schema once for both.

What lands in your repository

Everything below is tied to FunZ surfaces, not a generic kit:

• An OpenAPI specification covering wallet balance, FunZ-tag transfer, beneficiary, bill-payment, ticket and FunZScore reads, plus the money-movement calls that need the PIN step-up.
• A protocol and auth-flow report: login token issuance, refresh, the transaction-PIN gate, and how tag identifiers resolve to wallets and bank accounts.
• Runnable source for the key endpoints in Python and Node.js, with the tag-to-account resolver and a normalized statement model that merges consumer and merchant records under a role flag.
• Automated tests, including a re-validation suite that flags when a FunZ release shifts a field.
• Interface documentation and a consent/data-retention note written against the Nigeria Data Protection Act 2023.

A worked call: tag transfer plus wallet history

Illustrative shapes, confirmed and pinned during the build against a consenting account — field names are finalized at delivery, not guessed here.

// 1. Session: login token, then PIN step-up for money movement
POST /v1/auth/login            { phone, password }      -> { access_token, refresh_token }
POST /v1/auth/pin/verify       { access_token, txn_pin } -> { pin_session }   // short-lived

// 2. Resolve a FunZ tag before sending
GET  /v1/tags/resolve?tag=@ada -> { wallet_id, display_name, kyc_tier }

// 3. Wallet snapshot + paged history
GET  /v1/wallet                -> { balance_ngn, virtual_account: { number, bank }, currency }
GET  /v1/wallet/transactions?cursor=&type=transfer|bill|ticket|reward
   -> { items: [ { id, ts, type, direction, amount_ngn,
                    counterparty: { tag?, account?, biller? },
                    status, role: "consumer|merchant" } ], next_cursor }

// Error handling worth coding for, observed in this class of app:
//   401  -> access_token expired        : refresh, retry once
//   423  -> pin_session missing/stale   : re-run pin/verify, do NOT retry blindly
//   409  -> tag resolves to >1 wallet   : surface to caller, never auto-pick
//   429  -> rate ceiling                : honor Retry-After, back off per cursor page

Three integrations teams ask us for

• Personal-finance aggregation. A budgeting product pulls a FunZ user's wallet balance, transfer history and categorized bills into a unified statement alongside their bank accounts, refreshed daily with consent.
• Merchant settlement feed. A business tool reads only the merchant QR collection records and business-class metadata, role-filtered so personal wallet activity never enters the merchant ledger.
• Loyalty and referral sync. A rewards platform mirrors the FunZScore points ledger and referral events to reconcile perks against an external programme.

Consent and the Nigerian rulebook

Two regimes apply, and they are at different stages. The Nigeria Data Protection Act 2023 is in force, supervised by the Nigeria Data Protection Commission; it requires consent that is freely given, specific and informed, withdrawal that is as easy as granting, and a retained consent log — all of which we implement as standing practice. The CBN's open-banking framework — a 2021 regulatory framework and 2023 operational guidelines, with a central registry and consent system run through NIBSS — is drafted but not yet operational, so we do not present its access tiers or thresholds as settled obligations; we build to its published API shapes and treat the numbers as provisional until the rail is live. BVN-anchored identity is the sensitive piece: we keep it out of scope unless an engagement needs it, and minimize stored fields to what the integration uses. Access is authorized and logged; an NDA is in place where the work touches non-public interface detail.

Things we plan around on FunZ

Concrete judgments we account for, all handled on our side as part of the build:

• Tag versus account identity. A FunZ tag is an internal handle, not a bank account number. We build the resolver so a transfer record carries the tag, the resolved wallet, and the external NGN account when one is involved, keeping the payee graph correct for users who have both.
• Virtual-account top-in reconciliation. Money entering the virtual account credits the wallet through a partner-bank rail. We model the inbound-transfer to wallet-credit mapping so balance history matches the FunZ ledger rather than a raw bank webhook.
• Consumer and merchant records in one schema. Scan-to-pay and merchant QR collections have different shapes and business classes. We normalize them with a role flag so one statement model serves both without crossing the ledgers.
• Consent window on the future rail. Nigerian open-banking consent is BVN-anchored, time-bound and re-validated after inactivity. We design the sync around that refresh window so it does not silently expire, and run the same flow under your authorization until the registry is live — swapping rails without changing your schema. Access for either path is arranged with you during onboarding against a sponsor sandbox or a consenting account.

Working with us on this build

Source for the FunZ endpoints lands in your repository inside one to two weeks, and you pay from $300 after delivery, once it runs against your own consenting account and you are satisfied. The other model is our hosted API: you call our FunZ endpoints and pay per call, with nothing upfront and no commitment to the source drop. You bring the app name and what you want out of its data; access, the consenting account or sandbox, and the compliance paperwork are arranged together with you as part of the engagement. Tell us the target and the scope on the contact page and we will come back with the route and the field list for FunZ specifically.

Screens we mapped

Sources and what was checked

This brief draws on the FunZ App Store and Google Play listings (publisher FUNZUSA LLC, package com.funzmobile.app, the wallet, FunZ-tag, bill, ticket and FunZScore feature set, and the collected-data declarations), the publisher's own QR-payments write-up, the CBN Operational Guidelines for Open Banking, and Open Banking Nigeria's status page describing the registry, the central consent system and the slipped go-live. Citations: CBN Operational Guidelines for Open Banking, Open Banking Nigeria — status and standard, FunZ — QR payments in Nigeria, FunZ on the App Store.

Put together at the OpenBanking Studio integration desk and last checked on 2026-05-17.

Where FunZ sits among Nigerian wallets

Same-category Nigerian apps an integrator often unifies alongside FunZ. Named for ecosystem context only, not ranked:

• OPay — wallet, transfers, bill pay and POS records across a large consumer and merchant base.
• PalmPay — wallet, transfers, credit and bill payments, plus a wide agent network.
• Kuda — app-led banking with transfers, savings, cards and bill payments.
• Paga — long-running wallet and agent payments with transfer and bill data.
• Moniepoint — personal and business accounts with transfers and settlement records.
• FairMoney — wallet plus lending and savings, with instant transfers and bills.
• Flutterwave — payment infrastructure and consumer payment flows for collections and payouts.
• Nomba — merchant-leaning payments with collections and settlement history.
• Carbon — digital bank with wallet, lending and bill-payment activity.

Questions integrators ask about FunZ

FunZ moves money by tag rather than account number — does that change how transfer history is modelled?

Yes. A FunZ tag is an internal handle that resolves to a wallet, while a saved bank beneficiary is an NGN account at another institution. We model both edges so a transfer record carries the tag, the resolved wallet, and the external account when one is involved, and a payee graph stays consistent even when one person has both.

Nigeria's open banking is not live yet. Does that stop a FunZ integration today?

No. The regulated rail is the forward path, not the only one. Today we integrate FunZ through authorized analysis of the app's own traffic under your authorization; we build to the Open Banking API Standard v1 shapes so that when the CBN registry and consent system go live the swap is mostly configuration, not a rewrite.

Can merchant QR settlements be separated from a person's own wallet activity?

They can. FunZ records consumer payments and merchant QR collections with different record shapes and business classes. We normalize them into one statement model with a role flag, so a merchant-facing integration and a personal-finance one read the same schema without mixing the two ledgers.

How is BVN-linked identity data handled under Nigerian rules?

Identity tied to a Bank Verification Number is sensitive under the Nigeria Data Protection Act 2023 and, in the open-banking design, is anchored to BVN-verified consent. We keep that data out of scope unless the engagement explicitly needs it, log the consent basis, and minimize what is stored to the fields the integration actually uses.