Djamo, the neobank where a Visa card meets four mobile-money rails

Over a million accounts in Côte d'Ivoire and Senegal, a Visa card backed by Ecobank and BGFIBank, and transfers running across Orange Money, MTN, Moov, and Wave — that is the surface an integrator works with at Djamo. The data is interesting precisely because it sits at the join: a card ledger on one side, four mobile-money rails on the other, savings vaults and bill payments threaded through. A clean integration is one that hands you that join as a single normalized record, not four feeds you reconcile yourself.

What sits behind a Djamo account

The app's own marketing language is the cleanest map of the data inside it. "Centralisez et suivez mieux vos dépenses" describes the expense ledger; "transférez de l'argent à tous les mobile money (OM, MTN, Moov, Wave)" is the transfer engine; "coffres" is the savings-vault surface. Each maps to a structured object behind a session.

The interesting domain — the one that justifies an integration on its own — is the cross-rail transfer history. Outside Djamo, a business reconciling OM, MTN, Moov, and Wave activity for the same customer hits four feeds and four schemas. Inside Djamo, that work is already half done; we finish it and hand it over as one stream.

Authorized access routes

Three routes apply here. The fourth — guessing — does not.

1. User-consented session integration

The most durable path. The consenting account holder authorizes the studio to operate the mobile or web app on their behalf, with consent logged and scoped. We attach to the authenticated session, capture the structured responses the app already renders, and ship a server-side adapter that maintains the session for the user. Best fit when the integrator's product is also customer-facing — a budgeting tool, an SME accounting view, an analytics dashboard.

2. Protocol analysis of the app traffic

The studio's interface-integration practice: with the user's authorization, we instrument the app, observe its HTTPS traffic against the issuer back end, and document the request/response shape, the OTP/PIN bootstrap, the session cookie/token chain, and the field-level error model. The output is an OpenAPI document plus a runnable client. Best fit when the integrator wants source code they own outright rather than a hosted relay.

3. Native export, used as a fallback

Where Djamo offers an in-app statement download, we wire that into the same normalized schema so the integration has a paper-equivalent fallback on slow days. It is never the primary path — exports lag and lose the structured fields the live session carries — but it is useful belt-and-braces for reconciliation.

For most Djamo integrations the protocol-analysis path is what the build is driven from, with the consented-session adapter layered on top when the integrator's own product also faces the end customer. The studio handles access onboarding with the client as a normal kickoff step.

What ships at the end of a Djamo build

• OpenAPI document. One specification covering the endpoints we actually exercised: card balance, card statement, transfer history per rail, vault state, bill-payment record, card metadata. Fields named the way Djamo's responses name them, with English glosses.
• Auth-flow report. The session bootstrap — handset enrollment, PIN/OTP, token refresh, the device-binding behaviour as confirmed during the build — written so a second engineer can re-derive it.
• Runnable source. A Python client and a Node.js client. Polling jobs for the read endpoints, webhook stubs for downstream consumers, retry policy keyed to the issuer's observed error model.
• Automated tests. Fixture-replay tests for the four mobile-money rails, an FX-fee disambiguation test for card statements, a vault-state-transition test for coffres.
• Compliance posture & data-minimization notes. What's captured, what's hashed, what's discarded, and the consent record's shape — fit for review by Ivorian (ARTCI) or Senegalese (CDP) counsel.
• Interface documentation. A short engineer-readable handover: how the session is held, where it breaks, what to do when Djamo redesigns a screen.

A working sketch — pulling a statement, sorting by rail

Illustrative; field names and tokens are placeholders confirmed during the build against the consenting account.

import httpx, time
from typing import Iterable

BASE = "https://api.djamo.example/v1"   # exact host confirmed during the build

def session(handset: str, pin_otp: str) -> str:
    r = httpx.post(f"{BASE}/auth/session",
                   json={"msisdn": handset, "otp": pin_otp},
                   timeout=15)
    r.raise_for_status()
    return r.json()["session_token"]   # short-lived; refresh via /auth/refresh

def card_statement(token: str, since: int) -> Iterable[dict]:
    cursor = None
    while True:
        r = httpx.get(f"{BASE}/cards/primary/statement",
                      headers={"Authorization": f"Bearer {token}"},
                      params={"since": since, "cursor": cursor}, timeout=20)
        page = r.json()
        for tx in page["items"]:
            yield normalize_card(tx)
        cursor = page.get("next")
        if not cursor:
            return

def normalize_card(tx: dict) -> dict:
    # Djamo flags FX merchants on the response; keep merchant-side
    # and XOF-side amounts as siblings so downstream code stays honest.
    return {
      "ts": tx["posted_at"],
      "rail": "card-visa",
      "merchant": tx.get("merchant_name"),
      "amount_xof": tx["amount_xof"],
      "amount_orig": tx.get("amount_original"),
      "currency_orig": tx.get("currency_original"),
      "fx_fee_xof": tx.get("fx_fee_xof"),
      "status": tx["status"],
    }

One record for four rails

A normalized transfer record looks the same regardless of which mobile-money rail it came from. The rail itself becomes a field — it is not the schema.

{
  "ts": "2026-05-12T08:41:13+00:00",
  "channel": "mobile-money",
  "rail": "wave",            // or "orange-money" | "mtn" | "moov"
  "direction": "out",         // "in" | "out"
  "counterparty": "+225 07 11 22 33 44",
  "amount_xof": 12500,
  "fee_xof": 0,
  "djamo_ref": "DJ-2026-05-12-9F2A1",
  "status": "settled"
}

That shape is also what the card normalizer produces, with channel set to "card-visa" and the FX fields populated where the merchant triggered them. A consumer of the feed treats the whole user history uniformly and only branches on rail when it actually matters — for instance, when applying the OM-specific fee schedule.

Authorization, supervision, and the data law on the user

The dependable basis for a Djamo integration is the account holder's own authorization, recorded by the studio with a timestamped consent artifact that names the data domains, the retention period, and the revocation channel. That is the contract that lets the work happen — not the existence or otherwise of any external scheme.

Around it, three regimes shape how we run:

• BCEAO supervision over the financial layer. Customer funds sit with BCEAO-regulated partner banks (Ecobank, BGFIBank), per Djamo's own description; the Djamo Finances microfinance entity is supervised by BCEAO following the September 2025 approval announced via Djamo SA in Côte d'Ivoire. This shapes how an integration handles balance and statement data — as records belonging to a supervised institution, not freelance metadata.
• National data-protection law on the user record. Côte d'Ivoire's Loi n°2013-450 (ARTCI as supervisory authority) and Senegal's Loi n°2008-12 (CDP) set the consent, purpose, and retention frame for the personal record. The integration's consent artifact maps to whichever applies to the account holder.
• PCI DSS on the card path and 3D Secure on online card use. Djamo states it is PCI DSS certified and uses Visa 3D Secure; our card-statement work treats the PAN and 3DS material as out-of-scope tokens and never persists them.

The BCEAO PI-SPI instant-payment interoperability platform, which went into production in 2025 with a published participant list, is institutional plumbing between licensed actors. It does not give a third party shortcut access to a specific neobank's user data, and the integration does not pretend it does. It is mentioned here because it is part of the regulatory furniture an SME integrator will hear about and ought to understand the shape of.

Things the build accounts for

• Per-rail timestamp drift. Wave and Orange Money confirm transfers on different clocks; we map the offsets so a single user transfer that touches both ledgers lands on one timeline and isn't double-counted.
• 3D Secure on test runs. Exercising the card endpoints against the consenting account can trip the issuer's velocity controls. We design the integration test plan so 3DS challenges are handled in-band and rate limits are observed.
• Screen renames after app updates. Djamo iterates the front end. A re-validation script ships with the build, runs on a schedule against the consenting account, and flags mappings that need a small maintenance pass — the work is sized so this stays minutes, not days.
• French-language fields, English consumers. The app speaks French to the user (coffres, paiements, transferts). The OpenAPI specification keeps the original Djamo field names and adds English glosses so an anglophone integrator's stack does not have to do guesswork.
• SME vs individual accounts. Djamo serves both. We scope the build per account type because the available domains diverge — SME accounts surface bulk-transfer flows that an individual account does not.

Pricing and how the work runs

A normalized Djamo feed typically lands inside a one- to two-week cycle from the kickoff call. The work shows up as runnable source for the endpoints we map — OpenAPI document, Python and Node.js clients, the automated tests, the auth-flow report, the compliance notes — paid from $300 after we hand it over and you have inspected it. If you would rather skip owning the build, the same integration is also available as a hosted endpoint you call — pay only for the calls you make, no upfront fee, and we run the relay. Tell us the app and what you need from its data at /contact.html; access onboarding and the consent artifact are arranged with you as part of the engagement.

App screens we worked from

Where these notes come from

Drawn from Djamo's own French- and English-language listings, the company's CI site, primary trade-press reporting on the 2025 funding round and the September 2025 Djamo Finances launch, and BCEAO/UEMOA references for the regulatory layer. Specific deep links:

• TechCrunch — Djamo raises $17M, 1M users across francophone Africa
• Afrique Économie — Lancement officiel de Djamo Finances en Côte d'Ivoire
• Financial Afrik — BCEAO publishes PI-SPI participants list
• Djamo Côte d'Ivoire (vendor site)

Reviewed 2026-05-20 by the OpenBanking Studio integration desk; the mapping is re-checked when Djamo ships a notable app update.

Other apps a Djamo integrator usually sees in the same orbit

Plain-text references, not links. Each is a real franco/West-African player whose data an integrator may want to fold into the same normalized feed.

• Wave. Senegalese-origin wallet with aggressive low fees; the most common counter-rail to Djamo in remittance flows.
• Orange Money. The dominant telco wallet across UEMOA; a Djamo transfer to or from OM is one of the most frequent rail events.
• MTN Mobile Money. The other large telco wallet, strong in Côte d'Ivoire alongside OM and Moov.
• Moov Money. The third telco wallet rail; less volume than OM in CI but explicitly named in Djamo's own description.
• Wizall Money. Regional wallet backed by Banque Centrale Populaire / Banque Atlantique; overlaps in Senegal and CI.
• Mixx by Yas. Yas Group fintech with a Mastercard prepaid in partnership with Ecobank — a direct neighbour on the card-meets-wallet positioning.
• CinetPay. Ivorian payment aggregator on the merchant side; relevant when reconciling Djamo card payments to merchants who route through it.
• PayDunya. Senegalese payment aggregator playing the same merchant-side role; turns up across the same SME segment.

Questions integrators ask before starting

How do the four mobile-money rails appear inside Djamo — one feed or four?

Inside the app the user sees a single transfer history, but underneath each transaction carries the originating rail (Orange Money, MTN, Moov, or Wave). An integration normalizes those four into one timeline while keeping the rail tag, so an OM credit and a Wave credit aren't accidentally deduplicated.

Does the BCEAO microfinance approval for Djamo Finances change what an integrator can pull?

It changes the regulatory frame — a savings account or credit balance is now sitting inside a supervised microfinance institution rather than a payments wallet — but the surfaces an integrator works with are still the in-app account view and statement screens. The data domain expands, the access pattern doesn't.

What about FX adjustments on the Visa card — how does that land in a normalized feed?

Djamo's notes call out that some merchants and currencies trigger an FX-rate fee. We record the merchant-side amount, the XOF-side amount, and the inferred FX/fee component as separate fields so downstream reconciliation isn't ambiguous.

If the app gets a redesign, does the integration break?

The deliverable includes a re-validation script that runs against the consenting account on a schedule. When a screen renames or a response field shifts, the script flags it and the maintenance pass adjusts the mapping. That's part of how the build is scoped.