Pulling remittance and PayPlus data out of the Al Ansari Exchange app

About 50 million transactions a year move through Al Ansari Exchange's tills and digital channels, per the parent's FY2024 disclosure on the DFM (ticker ALANSARI). The per-user ledger sitting behind that volume is what an integrator usually wants on day one — remittance history, beneficiary book, prepaid-card balances, rate alerts, bill-pay records. The interesting design call on the ingest side is the reconciliation window, because rates change minute-by-minute while statements settle on a banking-day cadence.

The honest bottom line: these surfaces are reachable and stable enough to support a daily ERP-grade pull. We do that work as a one-off engagement that ends with runnable client code on your side, or we host the endpoints and charge per call — pick whichever fits how the consuming team operates.

What the app surfaces to an authenticated user

These are the domains an integrator will care about, named the way the app names them. The right-most column is what we usually see them used for once the code is in.

Authorized routes to that data

Three routes apply here. The recommendation in plain prose at the end of this section.

Route A — Authorized interface integration of the app's documented protocol

The app talks to the eExchange back end (the web counterpart sits at app.eexchange.ae). Once we have a consenting account and the engagement letter in hand, we observe the session, document the endpoints behind remittance, beneficiaries, rate alerts, card and bill-pay, and build a stable typed client against them. Effort: a couple of weeks. Durability: high while the app's wire format is stable; we keep token rotation and field churn in the recorded regression suite so a quiet rename trips a red build, not a Monday-morning reconciliation problem.

Route B — User-consented credential access via UAE PASS

UAE PASS provides federal eKYC and legally binding e-signature under the UAE Electronic Transactions Law. The end user authorizes through their UAE PASS identity, the integration holds the consent record alongside the access tokens, and reads run server-side on a sliding refresh. Effort: light. Durability: tied to UAE PASS session policy and to the user not revoking consent. Useful when the consuming system serves the same person whose data is being pulled (employee self-service, personal-finance aggregation).

Route C — UAE Open Finance via the Nebras API Hub (forward-looking)

The CBUAE Open Finance Regulation (Circular 7 of 2023, updated by Circular 3 of 2025, in force 10 July 2025) routes regulated data sharing through a centralized Trust Framework and API Hub operated by Nebras Open Finance LLC. As of writing, the first phase is mandatory only for UAE-licensed banks, foreign-branch banks and insurance companies — Category B exchange houses are not yet in the binding scope. We code the data-holder side of the client so it can be repointed to the hub when scope expands, without rewriting call sites upstream.

In practice, Route A is what we ship for ERP, treasury and payroll consumers today. Route B sits next to it for the small set of consumer-facing cases where the end user is the data subject. Route C goes into the architecture diagram with a date next to it, not into the codebase yet.

What lands in your repo at the end of the build

Code first, paperwork next to it:

• Python and Node.js client libraries with typed endpoints for the seven surfaces in the table above — statement read, beneficiary list, rate-alert subscribe / poll, card balance + transactions, bill-pay history, mobile top-up history, profile read.
• A webhook handler skeleton for rate-alert events, with replay support keyed on alert_id and a daily reconciliation job that walks the ledger to catch missed pushes.
• An idempotent ingestion module for the daily statement pull, with cursor state and a back-fill mode for the first ~90 days.
• An automated regression suite recorded against a consenting account, so contract drift turns into a red build rather than a quiet corruption of downstream tables.
• UAE PASS OIDC flow integration with the refresh-ahead-of-expiry behaviour described below.
• OpenAPI / Swagger specification for the documented endpoints, plus an auth-flow report (UAE PASS OIDC handshake, token chain, session cookies, error vocabulary).
• Interface documentation written for a developer who has never seen the app, and a short data-retention note aligned with the CBUAE Consumer Protection Standards and the UAE Personal Data Protection Law (Federal Decree-Law 45 of 2021).

Sample: rate-alert webhook with end-of-day reconciliation

Pseudo-Python sketch — the real client and endpoint paths are confirmed during the build, then frozen in the typed SDK. The shape, not the literal URL, is what matters here.

# rate_alerts.py  --  push receiver for Al Ansari Exchange rate-alert events
# alerts arrive by push; the same window is back-filled from /statement at EOD
# auth: UAE PASS OIDC token, kept fresh by the SDK ahead of its validity floor

from al_ansari_client import AlAnsariClient, RateAlertEvent
from datetime import datetime, timezone

client = AlAnsariClient(
    auth = AlAnsariClient.uae_pass_oidc(
        client_id     = settings.UAE_PASS_CLIENT_ID,
        refresh_token = vault.get("al_ansari.refresh_token"),
        refresh_before_seconds = 300,   # window keeps the cron off the 401 path
    ),
)

def on_rate_alert(event: RateAlertEvent) -> None:
    # event.pair        e.g. "AED/INR"
    # event.threshold   e.g. 22.85
    # event.rate_at_fire, event.fired_at (UTC), event.alert_id
    if alerts_seen.contains(event.alert_id):
        return                          # repeat events with the same id drop here
    alerts_seen.add(event.alert_id)
    pricing.push(event.pair, event.threshold, event.rate_at_fire)

def end_of_day_reconcile() -> None:
    # banking-day cutoff is GST 23:00; we run at 23:30 GST
    today = datetime.now(timezone.utc).date()
    stmt  = client.statement(date_from=today, date_to=today)
    for row in stmt.rows:
        if row.kind == "RATE_ALERT_TXN" and row.alert_ref not in alerts_seen:
            # ledger row exists without a push counterpart -- fill the gap
            pricing.push(row.pair, row.threshold, row.rate_at_fire)
            alerts_seen.add(row.alert_ref)

Sync cadence, freshness windows, and the cost of getting them wrong

Two clocks run on the data. Rate alerts fire in seconds and a downstream pricing service usually wants them within the same minute. The remittance ledger settles on a banking-day cadence with a 23:00 GST cutoff — trying to pull a same-day statement at 22:00 will return a partial set that flips by morning. The build separates the two channels: rate alerts go through a push receiver, statements come from a 23:30 GST cursor-based pull. The push channel is reconciled against the pull at end of day, so a missed webhook becomes a quiet back-fill instead of a silent gap.

PayPlus card balance reads sit in between — the value is real-time when you ask, but the transaction list lands on the same daily cycle as the remittance ledger. We expose both as one card endpoint, with separate caching for balance vs. transaction list, because conflating them is the most common subtle bug we see when teams roll their own client.

Consent, CBUAE supervision, and where the Open Finance regime lands

Al Ansari Exchange is supervised by the Central Bank of the UAE under Article 65 of the UAE Central Bank Law, in the Category B band of the Exchange Business Regulations (foreign currency exchange plus remittance). Operating posture on every engagement: authorized, documented, user-consented; access logged; data minimised to what the consuming system actually needs; NDA in place where the deliverable touches the wire format.

The UAE Open Finance Regulation was published in the Official Gazette on 15 April 2024 and was updated by Circular 3 of 2025, which came into force on 10 July 2025. Its first phase is binding on UAE-licensed banks, foreign-branch banks and insurance companies — exchange houses are not yet inside the mandatory perimeter, which is why the page is honest that Route C is a future durable path, not the rail the integration rides today. The dependable basis right now is the consumer's own UAE PASS-anchored authorization plus the engagement-letter scope, which is what Routes A and B already use.

UAE PASS itself is delivered jointly by ICP, TDRA and Smart Dubai, supports the Vision 2031 paperless-economy agenda, and provides eKYC and e-signature with legal force under the UAE Electronic Transactions Law. The PayPlus salary card is issued under the Wages Protection System per MOHRE directives, which is the other consent surface that matters — see the next section.

WPS, Aani, UAE PASS — the build-time realities we account for

Three notes from the studio side. Each is something we hold in the build rather than a step you need to clear first.

• WPS PayPlus consent has two owners. The salary card is a Wages Protection System instrument, so the employer-side consent record matters as much as the employee's. We hold both consent artefacts in the build and scope the card endpoints separately from the remittance ones, so a revocation on the card side does not knock out the rest of the integration.
• Aani lives on the bank rail, not the exchange-house wallet. The Aani instant-payments platform launched by Al Etihad Payments on 16 October 2023 is plumbed into licensed banks; Al Ansari's outbound funding uses bank rails (Visa/MC, direct debit, online bank transfer) rather than Aani-on-self. The routing logic in the SDK models that asymmetry — we use Aani only on the destination side when the recipient bank participates, which keeps the cost and settlement-time math correct.
• UAE PASS OIDC tokens refresh on a sliding window. A daily statement pull that wakes up to a 401 is a recurring failure mode for teams who fold the refresh logic into the cron job. The SDK refreshes ahead of the validity floor on a configurable offset (300 seconds by default), and the regression suite asserts the refresh path runs before the first authenticated call.

What was checked, and where

Behind this page: the app's Play Store listing (app.alansari), the Al Ansari Exchange product pages for the mobile app, FlexiblePay and PayPlus card, the parent's FY2024 results filing on the DFM, and primary CBUAE rulebook entries for Open Finance and Exchange Business. The four most useful deep links, opened during the review:

• Al Ansari Exchange — Send Money mobile app (vendor feature page)
• CBUAE Rulebook — Open Finance Regulation
• CBUAE press release — Al Etihad Payments launches Aani (16 October 2023)
• Al Ansari Financial Services PJSC — FY2024 results (DFM filing)

Reviewed 2026-05-31 by OpenFinance Lab — UAE remittance integration review.

Peer apps in the same UAE / GCC integration neighbourhood

Teams that integrate Al Ansari usually want a unified remittance picture across more than one source. These are the real apps that show up next to it in those conversations; each holds a comparable ledger and is worth a same-engineer sweep when the scope grows.

• LuLu Money — UAE remittance app from LuLu International Exchange holding sender KYC, beneficiary book and corridor history to 170+ countries; the closest local peer for a unified remittance integration.
• Wise — multi-currency app holding balances, recipient bank details and mid-market FX transaction records across 70+ currencies; fits as the international transfer rail in a unified picture.
• Remitly — digital remittance app holding sender identity, payout-method preferences and corridor history from UAE to South Asia, Africa and the Philippines; complements an Al Ansari ledger for outbound coverage.
• WorldRemit — digital-first remittance service holding KYC data, mobile-wallet and bank beneficiary details and transfer history across 130+ destinations including the GCC.
• Western Union — global money-transfer app holding sender/receiver identity, cash-pickup location data and transaction history across 200+ countries; the legacy rail in most unified setups.
• Xoom (PayPal) — PayPal-owned remittance app holding linked funding sources, beneficiary bank / wallet / cash-pickup details and international transfer history.
• Botim Pay — Astra Tech UAE super-app holding chat-linked wallet balance and in-chat international remittance records to 170+ countries.
• Payit (FAB) — FAB-powered UAE e-wallet holding wallet balance, salary transfers, bill payments and remittance records to 200+ countries; direct peer on the UAE-side wallet axis.
• e& money — Etisalat-operated UAE digital wallet holding KYC, wallet balance, bill-pay data and remittance history popular with expatriate workers.
• Pyypl — GCC-licensed app holding prepaid Visa card data, wallet balance and cross-border transfers to 80 countries without requiring a bank account.

Interface evidence — what the app looks like to a user

Eight screens from the public Play Store listing, useful when teams want to see which surface a field is actually drawn on before they specify the schema. Click any image to expand.

Questions integrators ask before signing

How do you sync the rate alerts when the app pushes them, instead of exposing a polled feed?

We treat the alert channel as a webhook source and reconcile it against the daily statement read. Each alert is keyed on its alert_id at ingest, and the end-of-day statement pull is used as the ground truth for any alert that should have fired but never landed. The freshness window we design around is roughly 24 hours for the ledger and minutes for the rate event itself.

Is the PayPlus and FlexiblePay card data covered under the same consent as the remittance ledger, or does it sit on a separate authorization?

Both sit behind the same UAE PASS-anchored session in the app, but the PayPlus salary card is issued under the UAE Wages Protection System, so the employer-side consent record matters as much as the employee's. The build keeps the two consent artefacts side by side and scopes the card endpoints separately, so a consent revocation on the card side does not break the remittance read.

Does the integration go through the UAE Open Finance API hub, or directly against the app?

Today, directly against the app's documented protocol. The CBUAE Open Finance Regulation, in force since 10 July 2025, makes participation mandatory in its first phase for UAE-licensed banks, foreign-branch banks and insurance companies, and exchange houses are not yet in that mandatory scope. The codebase is structured so the data-holder side can be swapped to Nebras Open Finance hub endpoints when scope expands, without changing your call sites.

For a corporate ERP that needs daily statements across every employee on an Al Ansari PayPlus payroll, which engagement model is cleaner?

Source-code delivery is the natural fit. Your ERP team holds the client and the cron jobs, the per-employee statement pulls run on your infrastructure, and there is no per-call meter when the volume is a salaried headcount that does not move much month to month. Pay-per-call sits better the other way around — intermittent volume, or a team that would rather not host webhook plumbing and token rotation themselves.

For a UAE remittance plus WPS PayPlus build like this one, source-code delivery from $300 is what most teams pick: the Python and Node.js client, the OpenAPI spec, the recorded regression suite and the interface documentation land in your repository, paid after delivery once you are satisfied. Where you would rather not host the token rotation, the rate-alert receiver or the daily statement cron at all, we keep the endpoints on our side and you pay only for the calls you make, with no upfront fee. The build runs in roughly a one to two week cycle. The app name and what you want from its data is enough to start the conversation; access, a consenting sandbox account and any compliance paperwork are arranged with you as part of the engagement.