What it takes to integrate MyCAC, CAC International Bank's account app

CAC International Bank was the first lender in Djibouti to put e-banking, mobile banking and dual-currency cash machines in front of retail customers, and MyCAC is the account app sitting on that backend today. The interesting part for an integrator is not a regulator-mandated data feed — Djibouti has no open-banking scheme to consent through — it is that the app already moves real money in two currencies through several distinct rails: the bank ledger, the CAC Wallet, CACPAY QR, and cross-border transfers. Reaching that data is an exercise in authorized protocol analysis of the app's own traffic, not a hunt for a sharing mandate that does not exist in this market.

Bottom line: this is a credentialed, server-backed banking app with several ledgers worth syncing. The market gives no shortcut. We would reach it by mapping the authenticated session a consenting account produces and rebuilding the calls behind the screens you care about.

What MyCAC holds per account

Mapped from the app's published feature list and CAC's mobile-banking page, the surfaces an integrator usually wants:

Three jobs integrators bring us for this app

The work tends to land in one of these shapes:

1. A Djibouti fintech wants a consenting customer's combined DJF and USD balance plus a 90-day statement inside its own app, with each currency kept on its own running total.
2. A merchant-services firm needs CACPAY settlements matched line-by-line against its point-of-sale records, including which source account was debited.
3. An SME accounting tool wants standing orders and loan installment dates mirrored so cash-flow forecasts stay current without manual entry.

Getting to the data where Djibouti has no open-banking mandate

Two routes genuinely apply here; a third is a narrow fallback.

Authorized protocol analysis of the app session (recommended)

We run a consenting account through MyCAC, observe the authenticated traffic — login, OTP exchange, token issuance, then the balance, statement, wallet and standing-order calls — and rebuild those calls as a clean client. This reaches everything the table above lists, because anything the screen shows is something the app fetched. Effort is moderate and front-loaded into mapping; durability is good between app releases, with a re-check needed when CAC reworks the login or a screen. Access is arranged with you during onboarding, against a consenting account you control.

User-consented credential access

Where the integration is a customer-facing product, the end user supplies their own MyCAC credentials and completes the OTP and biometric step inside a consented flow. Same surfaces, with the consent record tied to each user rather than to a single test account. Heavier on session handling because the step-up happens per user.

Native export as a fallback

Any statement the app or CAC's web platform lets a customer download can seed a one-off load or a reconciliation baseline. It is not a live route and does not cover wallet or QR events, so we treat it as a bootstrap, not the integration.

For almost every brief on this app we lead with the first route. It is the only one that reaches the wallet and CACPAY events live, and it does not depend on a data-sharing regime Djibouti has not legislated. We fall back to consented credentials when the deliverable is an end-user product rather than a back-office sync.

What lands at the end of the build

For MyCAC the deliverable set is concrete and tied to its real surfaces:

• An OpenAPI specification covering the calls behind balances, statements, CAC Wallet movements, CACPAY events, loans and standing orders.
• A protocol and auth-flow report: the credential post, the SMS OTP exchange, the biometric step-up, token issuance and refresh, written as observed during the build.
• Runnable source for the key endpoints in Python and Node.js — login through to a paginated, currency-tagged statement pull.
• Automated tests against the mapped responses, including the dual-currency balance case and a wallet-to-account reconciliation.
• Interface documentation an engineer can follow without us, plus data-retention and consent-logging guidance for the Djibouti context.

A login-and-statement call, sketched

Illustrative shape only, reflecting MyCAC's observed step-up and dual-currency ledger; field names are finalized during the build.

POST /auth/login            { "username": "...", "deviceId": "..." }
  -> 200 { "challenge": "OTP_SMS", "txnRef": "a1b2c3" }

POST /auth/otp              { "txnRef": "a1b2c3", "otp": "######" }
  -> 200 { "accessToken": "...", "refreshToken": "...", "biometricBound": true }

GET  /accounts              Authorization: Bearer <accessToken>
  -> 200 [
       { "acctId": "DJF-001", "currency": "DJF", "balance": "...", "type": "current" },
       { "acctId": "USD-001", "currency": "USD", "balance": "...", "type": "savings" }
     ]

GET  /accounts/DJF-001/statement?from=2026-02-01&to=2026-05-01&page=1
  -> 200 { "currency": "DJF", "page": 1, "more": true,
           "entries": [ { "postedAt": "...", "amount": "...", "desc": "CACPAY ...", "channel": "QR" } ] }

# error contract observed: expired token -> 401 { "code": "TOKEN_EXPIRED" }
#   -> refresh, do NOT replay the OTP challenge; balances stay per-currency, never summed

Authorization and Djibouti's data rules

CAC International Bank is supervised by the Banque Centrale de Djibouti, which oversees the country's commercial banks. There is no Djiboutian open-banking or account-information regime to consent through, so our access is not a regulated data-sharing API — it is authorized or user-consented interface integration, run under a written engagement with the client and, where the data is customer-facing, with the end user's consent. On data protection: Djibouti adopted a Digital Code in 2025; legal summaries of it (for example Jones Day's July 2025 note) describe a GDPR-style regime with data minimization by default and a 72-hour breach-notification duty, with a new supervisory commission (CNDP) that those summaries say is not yet operational. We work data-minimized regardless — pulling only the fields the integration needs, logging consent and access, and signing an NDA where the engagement calls for it. Compliance posture, not a checklist we hand back to you.

What we plan around on MyCAC specifically

Two things on this app need deliberate handling, and we build for them rather than flag them as your problem:

• Two currencies, one app. CAC accounts run in DJF and USD and the ATMs dispense both. We model currency at the ledger-entry level — every amount carries its ISO code and every account keeps a separate running balance — so a balance or statement pull can never silently merge a franc figure with a dollar one.
• Wallet and bank account are different ledgers. CAC Wallet runs off a mobile number and does not need a traditional account, while the bank ledger is separate. We treat them as two sources joined by a link table so a transfer that moves money wallet-to-account reconciles instead of double-counting.
• Step-up auth that changes. Login is credentials, then SMS OTP, then biometric, with a separate CAC e-Token app in the family. We design the session and refresh handler around that step-up and keep a re-check step in maintenance for when CAC reworks the login screen, so a sync does not quietly stall on a changed flow.

Screens we mapped

The published store screenshots we worked from while scoping the surfaces above:

Where MyCAC sits among Djibouti banking apps

For an integrator standardizing across the local market, the apps in the same space — named for ecosystem context only, no ranking implied:

• CAC MobileNet — CAC International Bank's earlier mobile-net app; overlapping account data, different client generation.
• MyCAC Corporate — CAC's business-banking app; multi-user company accounts and approvals rather than retail wallets.
• MyCAC Islamic — CAC's Shariah-compliant retail line; similar surfaces under Islamic-finance product rules.
• Exim Online Banking — Djibouti — Exim Bank (Djibouti)'s retail app; balances, history and transfers for another locally licensed bank.
• Salaam Bank — Salaam African Bank's app; accounts, transfers and Islamic-finance products in the same market.
• Waafi — the Salaam-linked mobile wallet licensed by the BCD; mobile-money balances and P2P, comparable to the CAC Wallet rail.
• D-Money — Djibouti Telecom's mobile-money platform; wallet balances and bill payments outside the bank ledger.
• BCIMR — Banque pour le Commerce et l'Industrie – Mer Rouge, the dominant local lender; account and transfer data behind its own channel.
• CAC Islamic Bank — the Islamic-bank arm; deposit and financing records adjacent to the CAC group.

Questions integrators ask about MyCAC

MyCAC shows balances in both Djiboutian francs and US dollars. Does an integration keep those apart?

Yes. CAC International Bank runs dual-currency accounts and its ATMs dispense DJF and USD, so we key every amount to an ISO currency code and carry a separate running balance per currency. A statement or balance pull never folds the two into one figure.

Djibouti has no open-banking mandate forcing banks to share data, so how is MyCAC data reached?

Through authorized protocol analysis of the app's own traffic, run under your authorization against a consenting account. There is no regional AIS scheme to consent through here, so the route is documented interface integration rather than a regulated data-sharing API, and access is arranged with you during onboarding.

Is CAC Wallet data reachable in the same pass as the bank-account ledger?

The CAC Wallet and the bank account are distinct ledgers inside MyCAC; the wallet works off a mobile number and does not require a traditional account. We map them as two sources and reconcile wallet-to-account movements through a link table so a single transfer is not counted twice.

Does the SMS OTP plus face or fingerprint login break an automated MyCAC sync?

No. Login is credentials plus an SMS OTP plus a device biometric, and CAC ships a separate e-Token app in the same family. We build the session and token handler around that step-up so re-authentication matches what the app actually does, and keep a re-check step in maintenance for when the login screen changes.

How this brief was put together

Scoped on 18 May 2026 from the MyCAC store listings, CAC International Bank's own mobile-banking pages, and current legal coverage of Djibouti's banking and data regime. Primary sources opened:

• MyCAC on Google Play — feature list and package ID.
• CAC International Bank — Mobile Banking — dual-currency and CACPAY detail.
• MyCAC on the App Store — iOS build and app family.
• Jones Day — Djibouti approves a Digital Code (July 2025) — data-protection context.

OpenBanking Studio — integration desk · MyCAC mapping reviewed 2026-05-18.

A working build here is a one-to-two-week job. Source-code delivery starts at $300, invoiced only after we hand over the runnable client, specification, tests and documentation and you have confirmed it works against a live MyCAC session; or skip the licence entirely and call our hosted endpoints, paying only per call with nothing up front. You give us the app name and what you need out of its data — the balances, the wallet, the CACPAY reconciliation, whichever surface — and access and compliance are arranged with you as part of the engagement. Start the conversation at /contact.html.