Reading remittance, FX and bill-pay records out of ALMAJRABI MOBILY

Where the data sits inside the app

Useful surfaces are mostly behind the customer login. The transfer ledger is the densest: senders, beneficiaries, the original Arabic name strings, branch code, settlement currency, FX leg, status. The rate board sits in front of login but matters because the parallel-market quotes shift through the day, and a useful copy of them needs timestamps and a UTC clock the supplier did not write.

Routes that actually apply here

Authorised interface integration against the app's own endpoints

This is the route we would lead with. The customer authorises the integration; we map the request and response shapes the app already uses against its own backend, harden the session and refresh logic, and put a typed client in front of it. Reach covers the full authenticated surface — ledger, beneficiaries, bill-pay receipts. Effort: a one-to-two-week cycle for the first usable drop. Durability: tied to the app's release cadence, so the contract is that we re-validate after any visible app update and roll the client forward.

User-consented credential access via a co-signed mandate

Where the engagement is with a downstream business that already has customers using Almajrabi, the practical pattern is a co-signed mandate: the end customer authorises pulls against their own account on a defined cadence, the integration layer stores no plaintext credentials at rest, and revocation is a one-call kill switch. Reach is identical to the first route; the difference is who carries the authorisation paper trail.

Branch-side back-office bridge

If the partner is a corridor counterparty or the exchange house itself, the cleaner route is a bridge against the branch back office rather than the consumer app — same ledger reality, different surface, and easier to put behind a service account. We design for both shapes so the project does not have to pick at the start.

Native export, as a fallback

Where it exists, a customer can pull a printable statement out of the app. We treat that as a backstop for back-fills, not as the main feed: the file is downstream of the very ledger we are already pulling, and it lacks the rate-board context.

What we ship into your repo

Code-first, in this order.

• Runnable Python 3.11 client — auth, session refresh, paged remittance-history pull, a single-call FX snapshot, and a beneficiary-book sync. Every call is typed, every error path is explicit.
• Runnable Node.js 20 client — the same surface, idiomatic for a JS/TS service. Shared fixture set so both clients can be diffed against each other.
• Webhook receiver scaffold for new-transfer notifications, with signature verification, idempotency keys, and a replay endpoint for re-delivery.
• Sync design — batch back-fill for history, delta poll for new activity, with a clear high-water mark; collision rules for transfers that change state late.
• Idempotency and reconciliation layer for transfer state changes so a re-run never double-books and a missed poll catches up cleanly.
• Automated test harness with recorded fixtures for the auth handshake, a paged ledger response, a rate-board snapshot, and the bilingual beneficiary normalisation cases.
• OpenAPI / Swagger specification covering every endpoint the client touches, so a future engineer can re-implement without re-reading the wire.
• Auth-flow and protocol report describing the session model the integration relies on, the refresh window, and the failure modes we engineered around.
• Interface documentation, plus a short runbook for the operational pieces (token rotation, fixture refresh, error budget).

What the ingestion call looks like

Shape only — exact field names and the auth header style are confirmed during the build against a consenting account or sponsored credentials. The structure below is the kind of thing we put in your repo.

# python: pull a remittance ledger page out of ALMAJRABI MOBILY
# session is established earlier and held in the client; refresh on 401.

from almajrabi_client import Session, LedgerQuery

s = Session.resume_or_login()  # short-lived token; refreshes on activity

page = s.ledger.list(LedgerQuery(
    since="2026-04-01T00:00:00Z",     # high-water mark from your store
    direction="send_and_receive",
    page_size=50,
))

for entry in page.items:
    # original Arabic name kept verbatim, plus a transliterated form
    yield {
        "id": entry.transfer_id,
        "status": entry.status,            # pending | settled | rejected
        "amount_minor": entry.amount_minor,
        "currency": entry.currency,        # YER | USD | SAR | AED
        "fx_leg": entry.fx_leg,            # quote_id + rate at booking
        "counterparty_ar": entry.counterparty.name_ar,
        "counterparty_latin": entry.counterparty.name_latin,
        "branch": entry.branch_code,
        "booked_at_utc": entry.booked_at_utc,
    }

# resume from page.next_cursor; persist the new high-water mark transactionally.

The same surface ships as a Node client. The webhook handler, where the partner exposes one, removes the need to poll for high-frequency activity — we still keep the delta poller in place as a belt-and-braces backstop.

Engineering notes specific to this app

• Dual supervisor reality. CBY-Aden and CBY-Sana'a both issue exchange-house licences and have suspended branches in recent quarters for non-compliance with their respective directives, per public CBY-Aden and Yemen Online reporting. We map which authority the customer's Almajrabi branch is under during onboarding and shape the AML/CFT logging so the audit trail lines up with the right supervisor, rather than producing one Yemen-shaped pile.
• Arabic-first counterparty data. Beneficiaries are written in Arabic by customers and that is the canonical string in the ledger. The client we ship keeps the Arabic field as the source of truth, emits a deterministic transliteration alongside, and the test set covers the awkward cases (combined names, honorifics, places where the same person is written two different ways) so downstream dedupe is not fighting the data.
• Parallel-market FX drift. YER quotes against USD, SAR and AED can move during a session as the parallel market re-prices. The rate-board ingestion writes every observed quote as an immutable row with a UTC timestamp from our own clock, and the snapshot endpoint returns what was true at a moment — enough to defend a transfer that was priced ninety minutes earlier.
• Session lifecycle. Tokens are short-lived and refresh on activity, which is normal for this kind of app. The session layer tracks the last good call, refreshes ahead of expiry, and surfaces a structured re-auth-needed error rather than letting the job degrade silently.
• Access onboarding is our step. A consenting customer account or a sponsored staging account at Almajrabi is arranged with the client at kickoff — the build runs against that account, not against a forced production touchpoint, and the cutover is its own phase.

Freshness, retries and what the operator sees

The remittance ledger is poll-able down to the minute on the customer surface; in practice a 60 to 120 second poll on the active high-water mark with a nightly reconciliation against the full history catches everything without putting weight on the app. The rate board moves faster and is cheaper to pull, so it lives on its own short interval. Every call is recorded with the consent reference, the operator that triggered it, and the response shape, so if the exchange house or its supervisor asks who pulled what and why, the answer is one query away.

Consent, the CBY backdrop and how compliance is carried

Yemen does not have a CBY-blessed open-finance regime in the sense PSD2 or Open Finance Brasil mean it, and we do not pretend otherwise on the page. The dependable basis for the integration is the customer's own authorisation against their own Almajrabi account, or the exchange house's authorisation where the engagement is direct. Around that, the CBY context still matters: the OECD's Yemen financial-sector review and the Sana'a Center trade-finance paper both describe an exchange-house sector that operates under lighter prudential rules than banks, and CBY-Aden has publicly suspended exchange establishments in the last two years for breaches of its directives. The integration is designed to sit on the right side of those directives: AML/CFT logging is kept, customer-consent records are retained, data is minimised to what the partner actually needs, and an NDA covers the build where the operator is involved. None of this is presented to the reader as a wall to clear before we start — it is the way the project is run, with the access and compliance pieces arranged alongside the engagement.

Apps in the same Yemen / GCC remittance corridor

Pulled from the same research pass; useful if you are unifying coverage across more than one exchange-house surface.

• Al Ansari Exchange — UAE-based, large branch network, runs an outbound corridor that lands in Yemen.
• Al Mulla Exchange — Kuwait-headquartered exchange house with a customer app that covers the same Yemen remit corridor.
• AlfaPay (Al Fardan Exchange) — UAE; outbound transfers and local bill payments inside one app.
• LuLu Money — Lulu Financial Holdings, GCC-wide network, retail remittance app.
• MoneyGram — global cash-pickup network with declared Yemen corridor support.
• Western Union — same shape, broader country reach.
• Ria Money Transfer — cash-pickup and bank deposit into Yemen.
• Swaid & Sons Exchange — Yemen-based exchange house, similar customer surface.
• Al-Noaman Exchange — Yemen exchange house listed on the IAMTN directory.
• Hubpay — UAE-licensed digital remittance, narrower corridor list but overlapping use case.

Questions integrators ask first

How this was put together

This brief is built off the app's own Play Store description, the Central Bank of Yemen's published guidance, recent Yemen Online reporting on CBY enforcement against exchange establishments, the Sana'a Center trade-finance paper, and the OECD's Yemen financial-sector review. The on-the-wire specifics of the app's session model are confirmed during the build against a consenting account, not asserted here.

• ALMAJRABI MOBILY on Google Play — operator's own description of the app and the company.
• Central Bank of Yemen — published guidance (CBY-Aden).
• Yemen Online — CBY suspends licences of 10 exchange establishments.
• Sana'a Center — Supporting Trade Finance in Yemen Amid Uncertainty.
• OECD — Promoting Economic Resilience in Yemen, financial-sector chapter.

Mapping reviewed 27 May 2026 by the OpenFinance Lab ingestion desk.

App profile

A confirmed build for ALMAJRABI MOBILY ships in one to two weeks once the route is fixed. You can pay it as a source-code drop priced from $300, settled after delivery when the code runs against your environment and you have accepted it — or call our hosted endpoints metered per request, with no upfront fee. Walk us through what you need from the app's data at /contact.html and we will come back with a build plan.