NALA Send Money Globally — API integration & Rafiki access

Deliverables checklist

• OpenAPI / Swagger specification for every NALA endpoint we wrap
• Protocol & auth flow report (token issuance, refresh, device binding, headers)
• Runnable source for login, statement, FX-quote and payout-status APIs (Python and Node.js)
• Webhook receiver template (FastAPI / Express) for payout confirmations
• Postman collection, integration tests and a sample reconciliation notebook
• Compliance and data-minimization guidance (KYC, sanctions, retention)

Data available for integration

The table below maps the data NALA exposes inside the consumer app to the API surface we typically build for clients. It is derived from NALA's public help center, the official Rafiki product pages, and our own protocol analysis of the money.nala.remit Android build.

Technical implementation — three short examples

Below are three short, vendor-neutral snippets showing the shape of the endpoints we typically expose. Field names are illustrative — the real adapter is generated against the live protocol during the build phase.

// 1. Authorize a NALA-linked user (consumer-side, customer consent)
POST /api/v1/nala/auth/login
Content-Type: application/json

{
  "phone": "+447700900123",
  "device_id": "a3b1...e7",
  "otp": "493021"
}

200 OK
{
  "access_token": "eyJhbGciOi...",
  "refresh_token": "rt_84c...",
  "expires_in": 3600,
  "kyc_status": "verified",
  "home_currency": "GBP"
}

// 2. Fetch send-transaction statement (paged, filterable)
GET /api/v1/nala/transactions?from=2026-04-01&to=2026-04-30&corridor=GBP-KES&limit=100
Authorization: Bearer <ACCESS_TOKEN>

200 OK
{
  "items": [
    {
      "id": "txn_01HN2K9...",
      "amount_send": "150.00", "ccy_send": "GBP",
      "amount_recv": "24985.50", "ccy_recv": "KES",
      "fx_rate": "166.57", "fee": "0.99",
      "rail": "MPESA", "msisdn": "+2547******12",
      "status": "delivered", "delivered_at": "2026-04-12T08:15:42Z"
    }
  ],
  "next_cursor": "eyJvZmZzZXQiOjEwMH0="
}

// 3. Payout-status webhook (Rafiki-style B2B disbursement)
POST https://your-app.example.com/webhooks/nala
X-Rafiki-Signature: t=1714742142,v1=9b2a...
Content-Type: application/json

{
  "event": "payout.delivered",
  "payout_id": "po_01HN2P...",
  "corridor": "USD-NGN",
  "rail": "BANK",
  "bank_code": "058",
  "amount_recv": "62450.00",
  "settlement_id": "stl_01HN2Q...",
  "delivered_at": "2026-05-03T11:02:18Z"
}

// Verify HMAC, ack with 200, then post to your ops queue.

Typical integration scenarios

1. Diaspora payroll reconciliation. A UK staffing agency pays Kenyan and Nigerian contractors weekly. We connect their internal ledger to a NALA / Rafiki-backed payout endpoint, pull statement data via the transaction API and emit one matched journal entry per payout, mapping fx_rate, fee and delivered_at into their ERP for month-end close.

2. NGO grant disbursement to mobile money. A European NGO sends micro-grants to beneficiaries in Tanzania and Uganda. Using the payout webhook we surface real-time M-PESA and Airtel Money confirmations into a dashboard, so program managers can see every payout.delivered event without logging into the app.

3. Marketplace seller payouts. An e-commerce marketplace pays sellers in Pakistan and the Philippines (corridors NALA added in its 2024–2025 expansion). We aggregate batched orders, call the bulk payout endpoint, and reconcile the returned settlement_id against the marketplace's order ledger.

4. FX parity monitor. A treasury team compares NALA's live GBP→KES and USD→PHP quotes to interbank mid-rates every minute. We push the quote API into a Grafana board and trigger a Slack alert when spread breaches a configurable threshold — useful for hedging and pricing committees.

5. Compliance evidence vault. A regulated EMI must keep an auditable trail of each remittance, the recipient KYC tier and the consent record. We package transaction exports, KYC profile snapshots and consent timestamps into immutable JSON-L files in S3, indexed for sanctions and AML review.

Regulatory framing

NALA's footprint spans three regulatory blocks. In the United States, money transfer is provided by Evolve Bank & Trust (Member FDIC), a licensed bank, while Nala Inc. provides the technology platform — so US integrations are governed by FinCEN BSA/AML rules and state money-transmitter law. UK and EU flows fall under the FCA Payment Services Regulations and the EU's PSD2 / forthcoming PSD3 framework, including strong customer authentication. African receive corridors interact with central-bank rules such as Kenya's CBK, Tanzania's BoT and Nigeria's CBN.

What this means for you

• Authorized access only — we work either through Rafiki's documented B2B endpoints or with the end-user's explicit consent on the consumer side.
• Data minimization: we pull only the fields you need, with masked PII (e.g. partial MSISDN) by default.
• Sanctions and PEP screening hooks at quote time, not just settlement.
• Auditable consent & access logs delivered alongside the API source.
• GDPR and UK GDPR aligned data-retention policies; NDAs available on request.

About OpenFinance Lab

We are an independent studio that focuses on mobile-app protocol analysis, OpenData/OpenFinance integration and authorized API delivery. Our engineers come from banks, payment gateways, mobile-network operators and cloud platforms, with hands-on history shipping fintech and remittance integrations across Europe, North America, Africa and South Asia.

• Cross-border remittance, mobile money, digital banking and stablecoin payouts
• Custom Python / Node.js / Go SDKs and webhook receivers
• End-to-end pipeline: protocol analysis → build → validation → compliance review
• Source-code delivery from $300 — runnable API source and full docs, paid after acceptance
• Pay-per-call API billing on our hosted endpoints — no upfront fee, ideal for usage-based teams

Contact

Send us the target app (NALA Send Money Globally is already in scope), the corridors and data points you need (e.g. GBP→KES transactions, M-PESA payout webhooks, FX quote stream), and any sandbox credentials or B2B partnership references you already hold. We typically reply within one business day.

Open contact page

Engagement workflow

1. Scope confirmation: corridors, data points (transactions, FX, payout status), volume estimate.
2. Protocol analysis & API design (2–5 business days, depending on rail count).
3. Build, sandbox testing and idempotency hardening (3–8 business days).
4. Docs, Postman collection, sample reconciliation notebook and webhook receiver template (1–2 business days).
5. Hand-over: typical first delivery in 5–15 business days. Multi-corridor or Rafiki partner onboarding may extend timelines.

FAQ

Does NALA expose a public API for individual users?

Which corridors and payout rails can be covered?

How do you handle compliance, KYC and AML?

How long does delivery take and what does it cost?