MerasDocs
Get API keys
A2A Banking

Bank-to-bank rails. Instant. Pre-funded.

Member banks consume one API to move funds customer-to-customer across Djibouti. MerasPay clears against pre-funded nostro pools at every bank and net-settles inter-bank positions to BCD SYRAD on a scheduled sweep window.

How it works

  1. Bank A sends a pacs.008 to POST /banking/v1/transfers.
  2. MerasPay validates (BIC routing, debtor/creditor sanity, UETR uniqueness), screens both parties against sanctions in <100ms, checks our nostro liquidity at the creditor bank.
  3. If green: ledger debits our nostro at Bank A and credits our nostro at Bank B (atomic, double-entry); response is pacs.002 ACSC.
  4. If borderline (sanctions hit, high-value): response is ACWP (HTTP 202) — accepted without posting, queued for 4-eyes approval.
  5. Bank Bcredits its customer from MerasPay's nostro pool (reconciled via camt.054 push and camt.053 statement at EOD).
  6. Sweep: end-of-day MerasPay computes net positions per bank and initiates BCD SYRAD wires to flatten the inter-MerasPay-position back to target.

Authentication

Three layers of trust on every request to the bank-facing API:

1mTLS

Load balancer terminates TLS, forwards the client cert sha256 as X-Client-Cert-Sha256. We pin against the registered fingerprint.

2JWS

Every mutating request carries an X-JWS-Signature header — a detached JOSE signature over the request body. Verified against the bank's registered JWS public key.

3IP allowlist

Optional CIDR allowlist per credential for defence in depth. Empty allowlist = any IP.

Quick example — JSON envelope

POST /banking/v1/transfersbash
curl -X POST https://api.merashub.com/banking/v1/transfers \
  -H "X-Client-Cert-Sha256: <pinned sha256>" \
  -H "X-JWS-Signature: <detached JWS>" \
  -H "Content-Type: application/json" \
  --data '{
    "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"
    }]
  }'
ℹ

Interactive simulator

Want to see exactly what the engine does for each scenario before writing a line of code? Open the A2A transfer simulator → Step through happy path, sanctions hold, AM04 liquidity rejection, 4-eyes approval, duplicate UETR, bad account, and post-settlement return — all client-side, no credentials needed.

More

Reference
Message reference→

pacs.008, pacs.002, pacs.004, camt.056 — XML and JSON envelopes.

Guide
Bank onboarding→

Conformance suite, cert provisioning, nostro funding, go-live approval.

Reference
Error codes→

ISO 20022 reason codes you'll see from the engine.

Guide
Sandbox→

Test cert, JWS keypair, BICs, deterministic scenarios.