Reading ALMAJRABI MOBILY's remittance ledger on Yemen's CBY rails

Where this app sits

Almajrabi Exchange Company has been moving money around Yemen since the late 1990s, and the mobile app is now the place where its customers see their transfers, exchange quotes, beneficiary lists and branch balances. According to the company's own description it sits inside the wider Almajrabi Group and serves customers across Yemeni branches and into the Arab corridors. That is the surface an integration aims at.

The interesting half is the rail underneath. The Central Bank of Yemen, which licenses the company, has spent the last two years rewriting how domestic transfers move: the Aden-seated CBY has directed exchange companies onto the Unified Network for Money (UNMoney) for domestic flows and capped single foreign-currency transfers at roughly $2,000 with documentary evidence on file, per its 2024–2025 circulars. Any read of Almajrabi's app data is read against that backdrop, and any write is built to respect it.

What sits behind the screens

The data that matters for an integration, with where the app surfaces it and what an integrator typically does with it. Field names below reflect how we'd normalise the surface during the build; the originals are mapped one-to-one in the spec.

The names a customer sees inside the app are mapped against these normalised buckets in the OpenAPI we ship — the spec is the authoritative reference, not the prose.

The routes we use to reach it

Three routes are in play here, and we usually combine two. None of them requires the operator to expose a feature it has not been asked about; what they require is consent from the customer or written authorization from the operator, organised during onboarding.

Authorized protocol-implementation of the mobile traffic

The app's mobile client speaks to its back-office over a token-shaped session. With a consenting account, we capture the request/response shape during the build, normalise it into a documented spec, and ship runnable endpoints that replay the same conversation from a server. Reach is broad — anything the app shows, the integration can pull. Effort is concentrated in the auth and refresh cycle. Durability depends on how often the operator reshapes the client; we ship a re-mapping checklist for when that happens.

User-consented credential access

For consumer-side integrations (think a corridor-aggregation app a customer plugs Almajrabi into), we wrap login on behalf of the user. The user authenticates inside our integration, we store no plaintext credentials, and the session ticks under their control with a clear revocation path. This is the route we pick when the requirement is per-customer and explicitly opt-in.

Authorized export and back-office handshake

Where Almajrabi or a partner can produce a periodic export — CSV statement, branch reconciliation file, settlement report from the UNMoney leg — we ingest and normalise it, and use it as the durable backbone alongside one of the live routes for status changes. This is the most durable path when the operator can sign off on file-based delivery.

Recommended shape for most briefs we see on this app: the protocol-implementation route as the spine, with the user-consented path bolted on when the integration is consumer-facing. The export route is added when there is a sponsor on the operator side who would rather see a flat file leave the building than an authenticated session.

A reading we'd start the build from

Illustrative — the exact path, header set and field names are confirmed during the build against a consenting account or a sponsor sandbox. The shape below is the kind of thing the spec carries.

import requests, time

BASE = "https://api.almajrabi.example/v1"   # confirmed during the build

# The app uses a phone + PIN login that returns a short-lived bearer token
# plus a long-lived refresh cookie. The integration treats the bearer as
# disposable and the cookie as the credential of record.
def login(phone, pin):
    r = requests.post(f"{BASE}/auth/session",
                      json={"msisdn": phone, "pin": pin}, timeout=15)
    r.raise_for_status()
    return r.json()["access_token"], r.cookies

def list_transfers(token, since, until, currency=None):
    params = {"from": since, "to": until}
    if currency:
        params["currency"] = currency
    r = requests.get(f"{BASE}/transfers",
                     headers={"Authorization": f"Bearer {token}"},
                     params=params, timeout=15)
    r.raise_for_status()
    # Each item carries: id, status (pending|settled|failed|reversed),
    # source_amount, source_currency, dest_amount, dest_currency,
    # beneficiary {name, msisdn, ref}, branch_id, created_at, settled_at.
    return r.json()["items"]

def fx_quote(token, base, quote):
    r = requests.get(f"{BASE}/fx/quote",
                     headers={"Authorization": f"Bearer {token}"},
                     params={"base": base, "quote": quote}, timeout=10)
    r.raise_for_status()
    return r.json()   # {bid, ask, ts, source}

Three things this snippet bakes in on purpose. Bearer tokens are kept disposable. Status is a small closed enum, so a poller can be cheap. FX quotes are read against a published timestamp so a stale read can be detected.

What lands on your side

Whether the engagement is source delivery or hosted, the artefacts are the same; the difference is where they run.

• OpenAPI / Swagger spec for the reachable surface of ALMAJRABI MOBILY, with the normalised field names in the table above mapped to the operator's originals.
• Auth-flow report covering the phone/PIN login, the bearer + refresh-cookie chain, and the documented revocation step a consenting user can use.
• Runnable endpoints in Python and Node.js for the surfaces you actually need — transfer reads, balance reads, FX quotes, beneficiary list, branch directory, KYC state, notification stream.
• Automated tests against a consenting account or sponsor sandbox: contract tests for the spec, a smoke suite for the live calls, and a regression set we re-run when the operator reshapes a screen.
• Interface documentation aimed at the integrator who will keep this running — failure modes, retry shape, rate-limit posture, and the re-mapping checklist for the day the mobile client changes.
• Compliance and retention notes covering KYC handling, the $2,000 CBY-Aden single-transfer ceiling on write-side flows, and a data-minimisation profile so downstream systems do not hoard what they shouldn't.

The Yemeni rail and what it asks of the build

Yemen's central bank runs from two seats — Aden and Sana'a — each licensing exchange companies under its own circulars. CBY-Aden has been the more visible regulator on digital-transfer questions: in 2024 it stood up the Unified Network for Money (UNMoney) as the mandatory rail for domestic transfers handled by exchange companies, and through 2025 has, per Barran Press reporting, suspended licences of more than two dozen exchange establishments for non-compliance. The same authority imposed a per-customer cap of around $2,000 on single foreign-currency transfers, with documentary evidence (passport, visa, ticket, medical or academic letters as relevant) on file.

The integration treats consent as the dependable basis: a consenting customer, or written authorization from Almajrabi or a sponsoring operator, is the durable ground for any data we move. On top of that we encode the CBY rules — the UNMoney shape on the settlement side, the $2,000 ceiling on the send side, the KYC-document references where the rail expects them — so the build does not drift over them. Logging is kept tight, customer-identifying fields are minimised at every hop, and an NDA is signed where the engagement reaches non-public operator material.

What we account for on this build

These are the parts of the work we plan around up front. They are not preconditions the customer has to clear before we will start — access, sandbox arrangements and any operator-side authorization are organised with you during onboarding.

• The two-CBY split. We scope the integration against the seat that licenses the operator we are integrating with, and keep the FX-read tolerant of divergent rate sheets between Aden and Sana'a so downstream dashboards do not crash when the same pair has two truths the same day.
• UNMoney reconciliation. A transfer surfaced in the app has a corresponding leg on the UNMoney rail. The build is wired so the app-side record and the rail-side state can be reconciled against each other, and a status flip on one is observable on the other within the next sync window.
• The $2,000 write-side ceiling. Any flow that initiates a transfer refuses over-limit values at the edge and carries KYC-document references with the request, rather than letting the rail reject downstream.
• Mobile-client drift. Exchange-company apps in Yemen reshape often as the regulator turns. We wire a quick re-mapping pass into maintenance so a screen change does not become a silent outage; the test suite catches the auth-shape variants first.
• Branch network volatility. The CBY's enforcement waves have closed branches and revoked licences for peers; the build does not assume the branch directory is static and treats removed entries as a normal event, not a parse error.

Other Yemeni exchange and wallet apps in the same conversation

If the goal is a one-corridor or one-country build, the field around Almajrabi looks roughly like this. Names are plain text; each is referenced for context, not endorsement.

• Al-Ameri Exchange — long-running Sana'a-based exchange company with a documented branch and service-point footprint across Yemen; similar transfer, FX and beneficiary domains.
• Al-Hamdi for Exchange and Remittances — exchange company with a corridor-facing mobile presence and overlapping data surface.
• Al-Marry for Exchange & Money Transfer — Yemeni exchange company with an agent network and remittance-app data shape comparable to Almajrabi's.
• Floosak — Yemen-licensed digital wallet covering balance, peer transfers, bill payments and merchant flows.
• mFloos — Al-Kuraimi Islamic Microfinance Bank's wallet, with banked and non-banked customer flows and SMS-anchored transaction state.
• Jaib Digital Wallet — Yemeni e-wallet with bill, top-up and transfer flows; the wallet shape overlaps the exchange-app shape on transfers and balances.
• Cash Yemen — Yemen-facing mobile payments app with transfer and bill-pay surfaces.
• Jawali — exchange-house wallet (WeCash) with mobile transfer flows used inside Yemen.
• CAC Mobile-Money Wallet — CAC Bank's wallet, with bank-account-anchored balance and transfer data and Ria-corridor remittance receive flows.
• UNMoney (Unified Network for Money) — not a customer app, but the rail Almajrabi's settlement leg now runs over; sometimes part of the same build for back-office reconciliation.

When a buyer says "we want to plug into every Yemeni exchange app", what we usually deliver is one normalised spec across the named operators, with per-operator adapters underneath — the same shape we'd ship for Almajrabi, repeated.

Questions we get on Yemen exchange app jobs

Where does the Central Bank of Yemen's UNMoney requirement fit into an integration with this app?

For domestic transfers, the CBY (Aden) directive in 2024 routed exchange-company traffic through the Unified Network for Money (UNMoney). When the build touches send-side flows, we treat UNMoney as the settlement rail behind Almajrabi's mobile surface and design queries so a transfer's mobile-app state and its UNMoney leg can be reconciled without duplicating the message.

Can transfer history and live status both be read from the same build?

Yes. The historical endpoint pages back through settled items, and the same record carries a status field that flips when the back-office moves it through. A poller on the status field is usually enough; for higher-volume jobs we add a per-record delta query so a long history sync doesn't rewalk closed months.

Does the $2,000 single-transfer ceiling change what's reachable for an integrator?

The CBY (Aden) circular caps a single foreign-currency transfer or FX sale at $2,000 per customer, with documentary evidence on file. It doesn't restrict what an integrator reads. It shapes the write-side: any flow we wire to initiate a transfer is built to refuse over-limit values up front and to carry the KYC-document references the rail expects.

How do you handle the Sana'a / Aden CBY split when scoping?

Yemen's central bank operates from two seats, each issuing its own circulars and licensing. We scope per the seat that licenses the operator we are integrating against, then keep the integration tolerant of divergent rate sheets between the two zones so downstream reports don't crash when the same currency pair has two truths the same day.

What we checked, and where

Primary sources opened for this brief: the Unified Network for Money (UNMoney) site for the rail's own description; Avanza Solutions' partnership write-up on UNMoney's platform integration; Barran Press's reporting on CBY-Aden licence suspensions and on the $2,000 foreign-transfer ceiling; and the ezeePayment 2026 round-up of Yemen mobile payment apps for the peer set context.

• UNMoney — Unified Network for Money (Yemen)
• Avanza Solutions on the UNMoney / Monex platform
• Barran Press — CBY new limits on foreign transfers and currency sales
• Barran Press — CBY suspends licences of more exchange companies

Mapping reviewed by the OpenBanking Studio integration desk, May 2026.

How the engagement runs

One short note instead of a sales paragraph. For Almajrabi-shaped work, source-code delivery starts at $300 — you get the runnable endpoints, the OpenAPI, the auth-flow report, tests and the interface documentation, and you pay after delivery once you are satisfied. The alternative is the pay-per-call hosted API: we run the integration, you call our endpoints, and there is no upfront fee. Cycle from kickoff to delivered build is 1–2 weeks for a single-app scope. Tell us the app name and what you want out of the data — start the conversation on the contact page — and access, sandbox and any operator-side authorization are arranged with you from there.