Getting Al-Ameen Funds statements, NAV and pension balances into your stack

Behind a single login, Al-Ameen Funds carries an investor's fund units, daily NAV, dated account statements and Voluntary Pension allocations — the records a portfolio tool or a payroll-linked pension dashboard would want to read on a schedule. The app is the mobile front end for UBL Fund Managers' Al-Ameen range of Shariah-compliant open-ended funds and pension schemes, with transactions running through what the listing calls the Jhatpat e-account. Our job on a page like this is narrow: name the data, name the authorized way to reach it, and say what the working integration looks like when we hand it over.

Bottom line: Pakistan has no mandated consumer data-rights interface that covers mutual-fund holdings yet, so the dependable basis here is the investor's own authenticated consent to their account. We build a consent-scoped integration against the app's own e-account back end, normalize what it returns, and document the auth flow so the feed keeps running. That is the route we would recommend for Al-Ameen Funds, and the rest of this page is about how it gets built.

What the app holds behind an investor login

The surfaces below come from the app's own description and the Al-Ameen Funds site. They map cleanly onto the kind of records an integrator pulls.

Two of these are worth a flag. Conversions run one-to-many and many-to-one, so a single instruction can touch several funds at once. And the pension side is not one product — it spans the Sarmayakari accounts, plus scheme-specific plans the operator lists such as KPK and Punjab pension funds.

Routes to the data, and the one we'd pick

Three routes genuinely apply to Al-Ameen Funds. Each works under the investor's own authorization.

Investor-consented interface integration

With an investor who consents to their own account, we capture and analyze the traffic the Jhatpat e-account exchanges with its back end, then re-implement the read and transact calls as a clean client. This reaches everything the app itself shows — statements, NAV, holdings, conversions, pension allocations. Effort is moderate; durability depends on the front end staying stable, which we plan for. Access is arranged with you during onboarding against a consenting account.

Protocol analysis under your authorization

Where you hold the authorization — for your own institution's accounts, or a documented arrangement — we work from the request and response shapes directly: auth handshake, token lifetime, the statement and order endpoints, error codes. This is the most precise route for a stable, typed client, and it produces the auth-flow report that ships with the code.

Native export as a fallback

Daily statements that the app can render or send are usable as a backfill and a cross-check, parsed into the same normalized schema. On its own it is coarse and manual; alongside one of the routes above it gives a reconciliation baseline for the live feed.

For this app we would lead with the consented interface route and keep export as the reconciliation check, because the records an investor actually needs — dated statements, per-fund NAV, pension allocation — all live behind the e-account and move on a daily cycle. The protocol-analysis route is the upgrade path once a target institution's authorization is in place.

What lands in your repo

Every engagement ships the same shape of work, tied to the surfaces above:

• An OpenAPI/Swagger spec for the endpoints we implement — session, statement, holdings, transactions, pension allocation.
• A protocol and auth-flow report: the token or cookie chain as it actually behaves here, refresh timing, and how the OTP/biometric onboarding step fits without us scripting it.
• Runnable source for the key calls, in Python or Node.js, with a normalized model for transactions and holdings.
• Automated tests against recorded fixtures, so a change in the back end shows up as a red test rather than a silent gap.
• Interface documentation plus compliance and data-retention notes — what is logged, what is minimized, how long records are kept.

A statement pull, sketched

Illustrative only — endpoint names and field shapes are confirmed during the build against a consenting account, not published constants. It shows the pattern: a consented session, a dated statement read, an explicit expiry path instead of a retry loop.

# Authorized, investor-consented session against the e-account back end.

import requests

def open_session(folio, otp_ref):
    r = requests.post(f"{BASE}/auth/session", json={
        "folioNo": folio,     # investor folio / CNIC-linked account
        "otpRef": otp_ref,    # SMS / biometric step handled in onboarding
    })
    r.raise_for_status()
    return r.json()["accessToken"]

def statement(token, folio, frm, to):
    r = requests.get(
        f"{BASE}/portfolio/statement",
        headers={"Authorization": f"Bearer {token}"},
        params={"folio": folio, "from": frm, "to": to},
    )
    if r.status_code == 401:
        raise SessionExpired   # refresh once, never loop the token
    return r.json()["transactions"]

# each row -> {date, fundCode, units, nav, grossAmount, type}
# type in {INVEST, REDEEM, CONVERT_IN, CONVERT_OUT, DIVIDEND}

Where integrators put this

• A net-worth app that shows a customer's Al-Ameen holdings next to their other Pakistani funds in one view.
• An HR or payroll system reading VPS pension allocations so staff see their voluntary-pension balance in-house.
• An accounting tool that reconciles RAAST ID and KuickPay inflows against the confirmed unit purchases they funded.
• A model-portfolio service that pulls daily NAV and an investor's risk profile to flag drift from target allocation.

Whose rules apply, and how consent is handled

The asset manager and its funds sit under the Securities and Exchange Commission of Pakistan. The SECP also set the digital account-opening framework that AMCs use for online onboarding, so the verified-investor model the app relies on is itself a regulated one. Voluntary Pension Schemes run under the SECP's VPS Rules, 2005. Payments move over RAAST, which the State Bank of Pakistan operates, and the SBP's open-banking framework — published but, on the sources we checked, still in implementation with technical standards in development — is where a future mandated data interface would come from. It is not in force today, and the page does not lean on it.

So consent does the load-bearing work. We build against the investor's explicit authorization to their own account, scoped to the records the use case needs and nothing wider. Consent is captured with an expiry and a revocation path, so the feed stops cleanly if the investor withdraws. Pakistan's comprehensive data-protection statute is still pending rather than enacted, so we treat minimization, access logging and consent records as how the studio operates, and put an NDA in place where the engagement needs one.

Engineering notes specific to this app

Things we account for in the build, so you do not have to:

• Conversions are multi-leg. We model a one-to-many conversion as a set of linked legs so it reconciles across every destination fund, not just the first one the response lists.
• The pension surface is scoped per scheme. Allocation and eligibility differ between the Sarmayakari accounts and the scheme-specific plans the operator runs (KPK, Punjab), so we read each as its own typed surface rather than flattening them.
• Instant redemption and forward-priced orders settle differently. We align statement and redemption reads to the daily NAV cycle so a Fauri Paisa instant redemption and a normal forward-priced order are not collapsed into one event.
• Onboarding uses biometric, liveness and facial matching. We keep the integration on the read-and-transact surfaces of accounts that are already open, and a consenting test account is arranged with you during onboarding rather than us scripting the identity capture.
• When the Jhatpat e-account front end shifts, a maintenance pass re-checks the captured request shapes before any new build ships, and the test fixtures catch the drift early.

How an engagement runs and what it costs

Source for the statement, holdings and pension endpoints — runnable, with tests and docs — typically lands in one to two weeks once a consenting account is in place. You can take it two ways. Source-code delivery starts at $300: you get the runnable API source plus its interface documentation, and you pay after delivery, once the work does what you needed. Or use the hosted version: call our endpoints and pay per call, with no upfront fee. You bring the app name and what you want out of its data; access, the test account and any compliance paperwork are arranged with you as part of the project. Tell us which records you need and we will scope it — start here.

Screens from the app

Store screenshots from the Al-Ameen Funds listing, useful for reading the surfaces the integration targets. Select to enlarge.

How this mapping was put together

Checked in June 2026 against the app's own store listings and operator site, the SECP's digital-onboarding and pension rules, and the State Bank's payment and open-banking material. The feature set (Jhatpat e-account, daily statements, instant redemption, RAAST/KuickPay/1Bill investments, pension re-allocation) is taken from the Play Store description and the Al-Ameen Funds website; the regulatory framing from SECP and SBP primary pages.

• Al Ameen Funds on Google Play (com.ublfm.alameen)
• SECP — digital account opening for mutual fund investors
• SECP — Voluntary Pension System (VPS) Rules, 2005
• State Bank of Pakistan — Raast instant payments

Mapped by the OpenBanking Studio integration desk · June 2026.

Other Pakistani fund apps in the same picture

Same category, named for context — an aggregator or a multi-manager dashboard usually wants several of these read the same way.

• Al Meezan Investments — Pakistan's largest Shariah-fund manager; its app shows a similar holdings, NAV and redemption set behind an investor login.
• Mahaana — a licensed digital wealth manager whose app holds goal-based portfolios and per-user transaction history.
• MCB Arif Habib Savings — runs conventional and Islamic funds with an online account carrying statements and conversion records.
• NBP Funds — NBP Fund Management's investor app holds open-ended fund units, daily NAV and dividend history.
• HBL Asset Management — a bank-linked AMC whose app keeps fund holdings, statements and VPS pension accounts.
• Faysal Funds — Faysal Asset Management's platform tracks unit holdings and redemptions across its fund range.
• Lakson Investments — manages equity and money-market funds with per-investor statement and valuation data.
• Sarmaaya — an aggregator that pulls NAV and performance across Pakistani AMCs into one research view.
• Behtari Capital — a mutual-fund marketplace where investors buy, redeem and track funds from several managers in one account.

Questions integrators ask about Al-Ameen Funds

Does Al-Ameen Funds being Shariah-compliant affect how the integration works?

Not technically. The Shariah label sits as fund metadata approved by the Shariah Advisory Council; it shows up as a field on each fund, not as a different access path. The statements, NAV, units and pension allocations are read the same way they would be for a conventional fund.

Can you read VPS pension allocations alongside the mutual-fund holdings?

Yes. Voluntary Pension accounts, including Provident-Fund-linked pension balances and plan re-allocations, are a distinct surface from the open-ended fund holdings. We scope them per scheme, since the Sarmayakari, KPK and Punjab pension plans carry different allocation and eligibility rules.

How do RAAST ID, KuickPay and 1Bill investments appear in the data?

Each inbound investment carries a payment reference from the rail it came through, whether a RAAST ID or a KuickPay or 1Bill voucher. The integration reconciles those references against the resulting unit purchase, so an additional investment ties back to the statement line it created.

Which regulator governs this, the State Bank or the SECP?

The funds and the asset manager sit under the Securities and Exchange Commission of Pakistan, which also set the digital account-opening framework for asset management companies. RAAST and Pakistan's still-emerging open-banking framework sit with the State Bank. Either way, the basis we build on is the investor's own authenticated consent to reach their account.