Three product ledgers behind one Alfardan Exchange login

One Alfardan Exchange login sits in front of three different financial products — cross-border transfers, doorstep foreign-currency orders, and gold bullion — and each keeps its own server-side record set. The breadth is the point. A single authorized session reaches a remittance ledger, a set of currency-delivery orders, and a stack of gold purchases carrying weights, purities and locked prices.

Alfardan has run in the Qatar market for decades and routes outbound transfers through roughly 120 correspondent banks, per its own site. The task here is to get those records out as clean, structured data and keep them current. What follows is how we would do it, what comes back, and what we hand over.

Where this nets out

Bottom line: the valuable data is the per-customer ledger across all three products, and it all comes back over one authenticated mobile session. So the route we would actually build is authorized interface integration against a consenting account — one capture, three product lines, normalized into a single schema on the way out.

What the app keeps per customer

These are the surfaces the app exposes once a customer is signed in. Field names are as the app presents them where we could confirm them; the rest is mapped during the build.

Getting to the records

Two to four routes apply here. Each is described by what it reaches, how much work it is, how long it holds up, and what we set up to run it — access is arranged with you as part of the project, not something you assemble first.

Authorized interface integration

We capture and replay the app's own authenticated traffic against a consenting account. This reaches everything behind the login: the remittance ledger, beneficiaries, currency and gold orders, and the live boards. Effort is moderate. Durability is tied to the app version, so we re-validate when the client front end or its API shifts. Test credentials or a consenting account are arranged with you during onboarding.

User-consented session access

Where the goal is to act for one account holder, we run against that customer's own QID + OTP login with their consent. It reaches that user's full ledger and is quick to stand up. How long a session lasts depends on the token model, which we map and handle in the refresh logic.

Bank-side AIS via Qatar's open banking

Qatar's open banking is real but bank-led: QNB went live with account-information APIs in 2024 and the QCB runs a sandbox under its fintech strategy. An exchange house is not a participant a regulated AIS call returns today. Where a transfer settles into a Qatari bank account, bank-side AIS can sit alongside the interface integration to confirm the receiving leg.

Statement and receipt export

Where the app or portal lets a customer download receipts or a history file, we parse those as a low-effort copy of the transaction record. It is a useful complement for audit trails rather than a full feed.

Concretely, the build we would put first is authorized interface integration against a consenting Alfardan account: all three product lines come back over one authenticated session, so a single capture covers transfers, currency orders and gold in one pass. We only reach for bank-side AIS when a corridor settles into a Qatari bank account and the receiving side matters as much as the send side.

What we hand over

Everything is scoped to the surfaces above, not a generic template:

• An OpenAPI / Swagger spec covering the remittance, beneficiary, currency-order, gold-order and rate endpoints as mapped.
• A protocol and auth-flow report: the QID + OTP exchange, token issuance and refresh, and the session chain it depends on.
• Runnable source in Python and Node.js for the key calls — login, transfer history, beneficiary list, gold orders, live rates.
• A normalized schema that unifies the three product ledgers so a gold weight never lands in a corridor field.
• Automated tests, including the token-refresh path and at least one live corridor.
• Interface documentation plus consent and data-retention guidance for running it in production.

A worked request against the ledger

Illustrative. Endpoint paths and field names are confirmed during the build, not assumed; the auth shape follows the QID + one-time-password pattern these Qatar exchange apps share.

# 1) Exchange the OTP for a short-lived session token
POST /api/v1/auth/verify-otp
  { "qid": "<Qatar ID>", "mobile": "+974XXXXXXXX", "otp": "######" }
  -> 200 { "access_token": "...", "refresh_token": "...", "expires_in": 1800 }

# 2) Page the remittance ledger
GET /api/v1/remittances?from=2026-01-01&status=all
  Authorization: Bearer <access_token>
  -> 200 {
       "items": [
         { "ref": "ALF-XXXXXX", "beneficiary_id": "...",
           "corridor": "QA->IN", "send_ccy": "QAR", "send_amount": 1500.00,
           "rate_applied": 22.91, "receive_ccy": "INR",
           "status": "PAID", "value_date": "2026-06-12" }
       ],
       "next_cursor": "..."
     }

# 3) Gold orders carry product, purity and the locked price
GET /api/v1/gold/orders
  -> 200 { "product": "PAMP 50g", "purity": "999.9",
           "price_locked_qar": 12345.00, "locked_at": "2026-06-10T08:42:00Z",
           "delivery_status": "SCHEDULED" }

# 401 on an expired token -> POST /api/v1/auth/refresh with refresh_token,
# retry once. The sync owns this loop so a run never silently stalls.
      

Where teams put this to work

• A wallet or neobank reconciling the outbound remittances its users send through Alfardan against its own ledger.
• A wealth app folding a customer's Alfardan gold holdings — weight, purity, cost basis — into a portfolio view.
• A treasury or pricing tool watching Alfardan's live QAR rate board to price its own corridors.
• A compliance function syncing saved beneficiaries for ongoing sanctions screening.

Authorization and Qatar's rulebook

Alfardan is licensed by the Qatar Central Bank as a money exchange house, per QCB's supervisory framework. Two pieces of the rulebook shape how we work: the QCB Payment Services Regulation, which governs licensed payment activity, and the QCB Data Handling and Protection Regulation, which requires customer consent before data is shared. At the national level, Qatar's Personal Data Privacy Protection Law (Law No. 13 of 2016) sets the privacy baseline.

Consent is scoped to the records the project actually needs — pull the ledger without dragging in full KYC where the ledger is all that is wanted. Consent records carry an expiry and can be revoked, and the sync respects both. Everything is authorized, documented and logged; data is minimized at the point of capture; an NDA is in place where the engagement calls for it. Qatar's open banking is described above as where the framework is heading, not a present-day mandate for exchange houses.

What we plan around on this build

Three things about Alfardan specifically that we design for, so they do not bite later:

• Login and session renewal. Access is gated by a Qatar ID and an SMS one-time-password, the pattern these exchange apps share. We build token capture and refresh around that step using a consenting account, so the session renews on schedule instead of dropping the sync when it expires.
• Three record shapes, one schema. A remittance row, a doorstep-delivery order and an allocated-bullion line carry different fields. We normalize the three up front rather than pretending it is one ledger.
• Fast boards and many corridors. The FX board and gold price refresh often, so we tune capture cadence to preserve each price-lock timestamp without hammering the endpoint. And with roughly 120 correspondent corridors, beneficiary requirements differ — IBAN here, account-plus-branch there, cash pickup elsewhere — so we map field rules per corridor.

How an engagement runs, and the price

Source for the endpoints you care about lands in your repository — runnable, with the QID/OTP token flow already wired and tests beside it. Take it as a one-time delivery and the price starts at $300, paid only after we hand it over and you have confirmed it works. Prefer not to host anything? Call our endpoints instead and pay per call, with no setup fee. Most Alfardan-scope builds run one to two weeks end to end. Tell us the app name and what you want from its data on the contact page, and we will scope it back to you.

Screens we worked from

What we checked

We worked from the app's store listings and Alfardan's own site, then read across Qatar's payments and open-banking material to fix the regulatory picture, in June 2026. The gold detail comes from Alfardan's gold-bars-and-coins page; the licensing and open-banking framing from the Qatar Central Bank's published payments regulation and fintech strategy. The links below go to what we opened.

• Alfardan Exchange — Gold Bars & Coins
• App Store — Alfardan Exchange Send Money (Qatar)
• Qatar Central Bank — Payment Services Regulation (PDF)
• Qatar Central Bank — Fintech Sector Strategy (PDF)

Reviewed 2026-06-15 by the OpenBanking Studio integration desk.

Other Qatar exchange and remittance apps

These sit in the same field. The point of naming them is a combined feed, not a ranking.

• Al Zaman Exchange — another Doha exchange house with its own app for transfers, live rates and tracking; the same transfer-ledger and beneficiary shapes make it a natural companion in a multi-provider feed.
• Al Dar Exchange — over two decades in Qatar; its app covers bank transfer and cash pickup with status tracking, sharing Alfardan's remittance-status surface.
• Doha Exchange — established 1979; holds beneficiary management, status tracking and real-time rates, overlapping closely on what a unified remittance view needs.
• Al Mirqab Remit — a long-running Qatar institution's remittance app whose outbound transfer records line up with the same normalized schema.
• Ooredoo Money — a Qatar mobile wallet that routes transfers through partners; it adds a wallet-balance surface alongside transfer history.
• MoneyGram Qatar — a global payout network used from Qatar; its transaction and payout-status data complements local exchange-house ledgers.
• Western Union — worldwide transfers and cash pickup; integrators often want its send/receive history beside a local provider's.
• Remitly — a digital-first remittance app whose transfer and recipient records map onto the same corridor-and-status model.
• Wise — multi-currency accounts and cross-border transfers with their own balances and statements; useful where a customer mixes an exchange house with a multi-currency wallet.

Questions integrators ask about Alfardan

Can you pull my Alfardan remittance history and my gold-bar orders in one feed?

Yes. Both sit behind the same Alfardan login, so a single authorized integration reaches the transfer ledger, the foreign-currency orders and the gold bullion purchases. We normalize the three different record shapes into one schema before they reach you, with the per-order product details — weight, purity and the locked price — preserved on the gold side.

Which regulator covers Alfardan, and does Qatar's open banking change the route?

Alfardan operates as a money exchange house licensed by the Qatar Central Bank. Qatar's open banking is moving forward but is bank-led for now — QNB went live with account-information APIs in 2024 and the QCB runs a sandbox — so an exchange-house feed is not something a regulated AIS call returns today. The working route is authorized interface integration against a consenting account; bank-side AIS is worth adding only where a transfer settles into a Qatari bank account.

How do you deal with the QID and SMS one-time-password at login?

We build the token capture and refresh around that step using a consenting account, arranged with you during onboarding. The OTP exchange returns a short-lived session token; our sync handles the refresh so it does not quietly expire mid-run. Nothing about this is a hurdle you clear before we start — it is part of the work.

Do the gold orders carry the live price-lock and product details?

They do. Each gold order records the product as the app lists it — PAMP or Royal Mint, weight from one gram up to a kilo per its gold page — along with the price locked at purchase and the timestamp of that lock. We capture all of it so a downstream portfolio or net-worth view shows the real cost basis.