Bank-to-bank rails. Instant. Pre-funded by MerasPay.
Member banks consume one API to move funds customer-to-customer across Djibouti. MerasPay carries the liquidity at every bank so settlement is instant from the customer's perspective. Inter-bank positions net-settle to BCD SYRAD on a sweep schedule we run for you.
What banks use it for
Any time money has to leave one bank's customer account and land at another's, in seconds, with finality.
Domestic bank rails
Customer at Bank A sends money to a customer at Bank B in seconds. No ACH cutoffs, no card scheme, no correspondent. Single API call by Bank A; settlement final inside 10 seconds.
Merchant payouts
Banks settle merchant payouts straight to customer accounts at other banks without leaving their core. MerasPay handles routing, screening and finality.
Treasury / wholesale
Bilateral DJF funding between treasury teams — no SWIFT MT103, no manual reconciliation. Every leg is ISO 20022 native with a UETR for end-to-end tracing.
Salary & disbursement runs
Pay 10,000 salaries across 13 banks in one batch upload. Each line is a pacs.008 with its own UETR; failures land in a per-row exception queue.
Why this architecture works in Djibouti
The market is small, USD-pegged with no capital controls, with 13 banks and a central bank already running the rails we settle into. The conditions are unusually clean for a private clearing overlay.
Pre-funded clearing — no settlement risk
MerasPay carries the liquidity at every member bank. Your customer never waits for inter-bank settlement; we float the gap and net-settle to BCD SYRAD on a sweep schedule.
ISO 20022 from day one
pacs.008 / .002 / .004 / .007 / camt.054 / camt.053 — all the messages, all the structured fields, all the codes. SWIFT MT/MX coexistence ended 22 Nov 2025; we shipped MX native.
JSON fallback for bank cores not ready for XML
Pilot banks integrate against a JSON envelope that maps 1:1 to ISO 20022 pacs fields. Upgrade to native XML when your core team is ready.
mTLS + JWS signed messages
Open-Banking-grade transport + message-level security. Pinned client certs, detached JWS over every body, IP allowlists, audit-grade event log.
Sanctions screening at message-time
OFAC / EU / UN / BCD lists screened in <100ms on every pacs.008. Borderline hits land as ACWP (accepted without posting) for 4-eyes review without breaking finality.
Built-in liquidity manager
Per-bank min / target / max bands. Threshold breaches and scheduled sweeps generate rebalance orders automatically. Your treasury team sees a single dashboard.
The four-step onboarding flow
- 1
Onboard
Bank submits operational + legal pack; we provision sandbox creds (mTLS cert + JWS signing key). Conformance tests run end-to-end pacs.008 → pacs.002 against a mock counterparty.
- 2
Fund nostro
Bank funds MerasPay's nostro at their institution. Min / target / max bands configured; liquidity manager starts watching.
- 3
Go live
4-eyes approval activates the bank. The bank starts sending pacs.008; MerasPay clears, settles, returns pacs.002 ACSC.
- 4
Settle
End-of-day MerasPay computes net inter-bank positions and proposes sweeps via BCD SYRAD. Banks see camt.053 statements next day for reconciliation.
Wire-level reality
A real pacs.008 (in JSON envelope form) and the pacs.002 reply our engine returns. XML works identically; switch the Content-Type and the body is the same fields wrapped in the official ISO 20022 XML schema.
POST /banking/v1/transfers HTTP/1.1
Host: api.meraspay.io
Authorization: mTLS-pinned client cert
X-JWS-Signature: <detached JWS over body>
Content-Type: application/json
{
"type": "pacs.008.001.08",
"msg_id": "BANKA-2026-05-24-000123",
"created_at": "2026-05-24T10:15:30Z",
"settlement": { "method": "CLRG", "clearing_system": "MERAS" },
"transactions": [{
"uetr": "11111111-2222-3333-4444-555555555555",
"end_to_end_id": "ORD-42",
"amount_minor": 50000,
"currency": "DJF",
"debtor": { "name": "Alice Mohamed", "account": "DJ81…" },
"debtor_agent": "BSABDJJDXXX",
"creditor": { "name": "Bob Hassan", "account": "EAB-…" },
"creditor_agent": "EABKDJJDXXX",
"charge_bearer": "SLEV",
"remittance_info": "Order ORD-42"
}]
}Response.
HTTP/1.1 200 OK
Content-Type: application/json
{
"type": "pacs.002.001.10",
"msg_id": "MERAS-7c2a9f8…",
"created_at": "2026-05-24T10:15:31Z",
"transactions": [{
"uetr": "11111111-2222-3333-4444-555555555555",
"end_to_end_id": "ORD-42",
"status_code": "ACSC",
"status_text": "Settled"
}]
}Frequently asked
Who bears the settlement risk?▾
MerasPay does. We pre-fund a nostro at every member bank and float the inter-bank position between transfer time and end-of-day net settlement. Banks see their customer credited instantly; we sweep our own positions later.
What if MerasPay's nostro at the creditor bank runs out?▾
The transfer is rejected upfront with reason code AM04 (insufficient funds). Our liquidity manager queues a rebalance order the moment any pool dips below its configured minimum, so this is a steady-state never-event in practice.
How does this differ from BCD's ATS+ IFT rail?▾
ATS+ IFT is the central-bank instant rail; participation requires a banking license. MerasPay is a private clearing overlay — we are not a competing rail. We use ATS+ ourselves to settle our own positions at end of day. Banks can join MerasPay without becoming an IFT direct participant.
What about returns and disputes?▾
pacs.004 returns for post-settlement reversal, pacs.007 reversal for pre-settlement, camt.056 cancellation requests — all supported. Reason codes follow the standard ISO 20022 vocabulary (AC01, AM04, MD07, RR03, etc.). UETR is carried through every related message for end-to-end tracing.
High-value transfers?▾
Per-bank approval thresholds (default 5,000,000 DJF). Above the threshold a transfer is accepted as ACWP (accept without posting) and queued for 4-eyes approval. Banks see a 202 response immediately; settlement completes on approval.
Ready to integrate?
Get a sandbox account in minutes. Production goes live after a brief KYB review.