# Overview USDC off-ramp infrastructure for wallet providers, exchanges, and fintechs Madhouse Wallet is a **stablecoin off-ramp API** built for B2B partners. Integrate once and give your users the ability to send USDC and receive local fiat in **85 currencies** across Africa, Asia, Europe, Latin America, the Middle East, and Oceania. *** ## How It Works ``` Your user sends USDC to a deposit address ↓ Madhouse detects the deposit, converts at mid-market FX rate, and routes to recipient's bank ↓ Recipient receives local fiat (bank account, M-PESA, UPI, SEPA, etc.) ``` 1. **Create a recipient** — dynamic field validation per currency 2. **Get a quote** — mid-market FX, locked 5 minutes 3. **Submit a transfer** — receive a unique USDC deposit address 4. **Send USDC** — from any supported chain 5. **We do the rest** — conversion, routing, settlement *** ## Key Numbers | | | | ------------------------- | ---------------------------------------------------- | | **Fiat currencies** | 85 | | **Supported chains** | Arbitrum, Base, Ethereum, Optimism, Polygon, Solana | | **Off-ramp success rate** | 98% | | **FX quote validity** | 5 minutes | | **Settlement** | Instant (most rails) · ACH 1–2 days · SWIFT 5–7 days | | **Max transaction** | $1,000,000 (enterprise) | *** ## Navigate the Docs * [Quickstart](/quickstart) — make your first API call * [API Reference](/quickstart/api-reference) — all endpoints documented * [Transfer Flow](/quickstart/transfer-flow) — end-to-end walkthrough * [Dashboard](/quickstart/dashboard) — recipients, keys, history * [Supported Currencies](/supported-countries) — 85 currencies and rails * [Security](/security) — encryption, key management, compliance * [Fees](/fees) — transparent pricing *** **API Docs**: [developer.madhousewallet.com](https://developer.madhousewallet.com) **Changelog**: [business.madhousewallet.com/developers/changelog](https://business.madhousewallet.com/developers/changelog) **Contact**: # Getting Started Make your first API call in minutes This guide walks you through creating a recipient, getting a quote, and initiating a transfer via the Madhouse Wallet off-ramp API. *** ## 1. Get an API Key Sign in at [business.madhousewallet.com](https://business.madhousewallet.com) and navigate to **Developers → API Keys**. Create a new key. The full key is shown **once** — copy it immediately. ``` mw_live__ ``` Include it on every request: ```http Authorization: Bearer mw_live_xxxxx_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx ``` *** ## 2. Fetch Account Requirements Before creating a recipient, fetch the required fields for the target currency. Different currencies require different inputs (routing numbers, IBANs, sort codes, UPI handles, etc.). ```bash curl https://business.madhousewallet.com/api/payouts/account-requirements \ -H "Authorization: Bearer $API_KEY" \ -G -d "source=USD" -d "target=KES" -d "sourceAmount=500" ``` The response returns an array of field groups. Render each field according to its `type` (`text`, `select`, `radio`) and respect `validationRegexp` and `minLength`/`maxLength`. If a field has `refreshRequirementsOnChange: true`, POST the current form state back to this endpoint when that field changes to get updated requirements. *** ## 3. Create a Recipient ```bash curl -X POST https://business.madhousewallet.com/api/payouts/recipients \ -H "Authorization: Bearer $API_KEY" \ -H "Content-Type: application/json" \ -d '{ "currency": "KES", "type": "kenya_local", "accountHolderName": "Jane Mwangi", "details": { "legalType": "PRIVATE", "accountNumber": "1234567890" } }' ``` **Response:** ```json { "id": 123456789, "currency": "KES", "accountHolderName": "Jane Mwangi" } ``` Save the recipient `id` — you'll use it to get quotes and create transfers. *** ## 4. Get a Quote ```bash curl "https://business.madhousewallet.com/api/payouts/quote" \ -H "Authorization: Bearer $API_KEY" \ -G -d "targetCurrency=KES" -d "sourceAmount=200" ``` **Response includes:** ```json { "quoteId": "a1b2c3d4-...", "txFee": 2, "netUsdAmount": 198, "eurAmount": 183.12, "quote": { "paymentOptions": [{ "targetAmount": 28450.00, "fee": { "total": 1.20 } }], "deliveryEstimate": "Within hours" } } ``` Quotes are **valid for 5 minutes**. Pass `quoteId` to the next step. *** ## 5. Initiate the Transfer ```bash curl -X POST https://business.madhousewallet.com/api/payouts/transfer \ -H "Authorization: Bearer $API_KEY" \ -H "Content-Type: application/json" \ -d '{ "quote_id": "a1b2c3d4-...", "source_wallet": "0xYourUSDCWalletAddress", "amount": 200, "recipientId": 123456789 }' ``` **Response:** ```json { "transfer_id": "txn_abc123", "escrow_wallet": "0xDepositAddress...", "amount": 200, "currency": "KES", "expires_at": "2026-03-29T12:10:00Z" } ``` *** ## 6. Send USDC Send exactly `amount` USDC from `source_wallet` to `escrow_wallet` on any supported chain: * Arbitrum * Base * Ethereum Mainnet * Optimism * Polygon * Solana The platform detects the deposit on-chain, converts to fiat, and routes to the recipient's bank account automatically. *** ## 7. Poll for Status ```bash curl "https://business.madhousewallet.com/api/payouts/transfer-status/txn_abc123" \ -H "Authorization: Bearer $API_KEY" ``` | Status | Meaning | | ------------------ | ---------------------------------- | | `pending` | Awaiting USDC deposit | | `awaiting_deposit` | Deposit address issued | | `deposit_sent` | USDC confirmed on-chain | | `processing` | Converting and routing funds | | `completed` | Funds delivered to recipient | | `failed` | Contact support with `transfer_id` | Poll every 5 seconds. Stop polling on `completed` or `failed`. *** ## Next Steps * [API Reference](/quickstart/api-reference) — full endpoint docs * [Transfer Flow](/quickstart/transfer-flow) — architecture deep dive * [Supported Currencies](/supported-countries) — all 85 currencies and rails # API Reference Full endpoint documentation **Base URL**: `https://business.madhousewallet.com`\ **Authentication**: `Authorization: Bearer mw_live__`\ **Content-Type**: `application/json` Interactive API docs are available at . All successful responses are returned as JSON. Rate limits are per API key. *** ## MCP Server **Endpoint**: [`https://mcp.madhousewallet.com/`](https://mcp.madhousewallet.com/) Madhouse Wallet offers a hosted [Model Context Protocol (MCP)](https://modelcontextprotocol.io) server that exposes the payouts API as a set of tools your AI agents can call directly. Instead of hand-wiring HTTP requests, an MCP-compatible client (Claude, Cursor, or any agent framework) can discover and invoke wallet actions — fetching quotes, managing recipients, and initiating transfers — through a single connection. Use it to let AI agents: * Look up account requirements and create recipients * Request locked FX quotes * Initiate and track USDC off-ramp transfers * Programmatically orchestrate payouts as part of an agentic workflow Authentication uses the same `mw_live__` API keys described above. For setup instructions, the full tool catalog, and client configuration, see . *** ## Recipients ### GET /api/payouts/recipients List all recipients for the authenticated account. **Rate limit**: 30 req/min **Response:** ```json { "data": [ { "id": 123456789, "currency": "KES", "accountHolderName": "Jane Mwangi", "type": "kenya_local" } ] } ``` *** ### POST /api/payouts/recipients Create a new payout recipient. **Rate limit**: 30 req/min **Request body:** ```json { "currency": "KES", "type": "kenya_local", "accountHolderName": "Jane Mwangi", "details": { "legalType": "PRIVATE", "accountNumber": "1234567890" } } ``` Use `GET /api/payouts/account-requirements` first to determine the correct `type` and required `details` fields for each currency. **Response:** ```json { "id": 123456789, "currency": "KES", "accountHolderName": "Jane Mwangi" } ``` *** ### GET /api/payouts/recipients/:id Fetch a single recipient by ID. **Rate limit**: 30 req/min *** ### DELETE /api/payouts/recipients/:id Delete a recipient. Returns `409 Conflict` if a transfer for this recipient is in a non-terminal status. **Rate limit**: 30 req/min *** ## Account Requirements ### GET /api/payouts/account-requirements Fetch required fields for creating a recipient in a target currency. **Rate limit**: 60 req/min **Query parameters:** | Parameter | Type | Description | | -------------- | ------ | --------------------------------- | | `source` | string | Source currency (e.g. `USD`) | | `target` | string | Target fiat currency (e.g. `KES`) | | `sourceAmount` | number | Amount in source currency | **Response** (array of requirement types): ```json [ { "type": "kenya_local", "title": "Local bank account", "fields": [ { "name": "Account number", "group": [ { "key": "accountNumber", "type": "text", "required": true, "minLength": 10, "maxLength": 10, "validationRegexp": "^\\d{10}$", "refreshRequirementsOnChange": false } ] } ] } ] ``` Fields with `refreshRequirementsOnChange: true` (e.g. `legalType`) require a follow-up POST to this endpoint with the current form state to receive updated field lists. *** ### POST /api/payouts/account-requirements Refresh requirements after a `refreshRequirementsOnChange` field changes. **Rate limit**: 60 req/min **Request body:** ```json { "type": "kenya_local", "details": { "legalType": "BUSINESS" } } ``` *** ## Quotes ### GET /api/payouts/quote Get a locked FX quote. Valid for **5 minutes**. **Rate limit**: 20 req/min **Query parameters:** | Parameter | Type | Description | | ---------------- | ------ | --------------------------------- | | `targetCurrency` | string | Target fiat currency (e.g. `KES`) | | `sourceAmount` | number | USD amount to send | **Response:** ```json { "quoteId": "a1b2c3d4-e5f6-...", "txFee": 2, "netUsdAmount": 198, "eurAmount": 183.12, "usdAmount": 200, "quote": { "sourceCurrency": "EUR", "targetCurrency": "KES", "paymentOptions": [ { "payIn": "BALANCE", "targetAmount": 28450.00, "fee": { "total": 1.20, "currency": "EUR" }, "disabled": false } ], "deliveryEstimate": "Within hours" } } ``` Pass `quoteId` to `POST /api/payouts/transfer` within the 5-minute window. *** ## Transfers ### POST /api/payouts/transfer Initiate a USDC off-ramp transfer. **Rate limit**: 5 req/min **Request body:** | Field | Type | Required | Description | | --------------- | ------ | -------- | ------------------------------------------------------- | | `quote_id` | string | Yes | From `GET /api/payouts/quote` | | `source_wallet` | string | Yes | Ethereum address (0x...) sending the USDC | | `amount` | number | Yes | USD amount (must match quote ±$0.01) | | `recipientId` | number | Yes | From `POST /api/payouts/recipients` | | `customer_uuid` | string | No | Your own idempotency key (prevents duplicates on retry) | **Response:** ```json { "transfer_id": "txn_abc123", "escrow_wallet": "0xDepositAddress...", "wallet_address": "0xYourSourceWallet", "amount": 200, "currency": "KES", "status": "pending", "expires_at": "2026-03-29T12:10:00Z" } ``` Send exactly `amount` USDC from `source_wallet` to `escrow_wallet` before `expires_at`. **Error codes:** | Code | Meaning | | ----- | --------------------------------------- | | `400` | Invalid input or stale/mismatched quote | | `403` | Recipient not owned by this account | | `409` | Duplicate `customer_uuid` | | `429` | Rate limit exceeded | *** ### POST /api/payouts/transfer/cancel Cancel a transfer before USDC has been sent. **Rate limit**: 20 req/min **Request body:** ```json { "transfer_id": "txn_abc123" } ``` Returns `409` if the transfer has already received a deposit. *** ### GET /api/payouts/transfer/:id Get transfer status from the database snapshot. **Rate limit**: 30 req/min *** ### GET /api/payouts/transfer-status/:id Get transfer status with **live** quote data and recipient details fetched in real time. **Rate limit**: 30 req/min **Response:** ```json { "transfer_id": "txn_abc123", "status": "completed", "amount": 200, "currency": "KES", "recipientId": 123456789, "wallet_address": "0xYourSourceWallet", "created_at": "2026-03-29T12:00:00Z", "updated_at": "2026-03-29T12:08:00Z" } ``` *** ## Rate Limits Rate limits are **per API key**. Headers are included on every response: ``` X-RateLimit-Limit: 30 X-RateLimit-Remaining: 28 X-RateLimit-Reset: 1743254460 ``` When exceeded, the API returns `429 Too Many Requests`. Back off and retry after `X-RateLimit-Reset`. *** ## Errors All errors follow the format: ```json { "error": "Description of what went wrong" } ``` | Status | Meaning | | ------ | ---------------------------------------------- | | `400` | Bad request — check input parameters | | `401` | Invalid or missing API key | | `403` | Forbidden — resource not owned by this account | | `404` | Resource not found | | `409` | Conflict — duplicate or in-flight transfer | | `429` | Rate limit exceeded | | `500` | Internal server error — contact support | # Transfer Flow End-to-end architecture of a transfer This page describes exactly what happens from the moment a transfer is submitted to when funds land in a recipient's bank account. *** ## Overview ``` Partner API call ↓ POST /api/payouts/transfer ↓ Unique USDC deposit address issued ↓ Partner sends USDC on-chain ↓ Platform detects on-chain deposit (5–10 min) ↓ Funds converted at locked FX rate ↓ Outgoing transfer created and funded ↓ Funds delivered to recipient bank/mobile wallet ↓ Status → completed ``` *** ## Step-by-Step ### 1. Quote lock `GET /api/payouts/quote` returns a real-time mid-market FX rate locked for **5 minutes**. The response includes: * `quoteId` — required for transfer creation * `txFee` — fixed USD fee ($2 under $1,000 / $3 at or above $1,000) * `netUsdAmount` — amount after fee deduction * `eurAmount` — EUR equivalent after conversion * Estimated `targetAmount` in the recipient's currency * Delivery estimate ### 2. Transfer intent `POST /api/payouts/transfer` validates the quote, verifies recipient ownership, and issues a **unique USDC deposit address** for this transfer. No two transfers share the same deposit address — this is how each on-chain deposit is matched to the correct transfer record. The response includes `expires_at`. Send USDC before this timestamp. ### 3. On-chain USDC deposit Send exactly `amount` USDC from `source_wallet` to `escrow_wallet`. Any supported chain is accepted: | Chain | Notes | | ---------------- | -------------------------------------------- | | Base | Recommended — lowest fees, fast confirmation | | Arbitrum | Low fees | | Optimism | Low fees | | Polygon | Low fees | | Ethereum Mainnet | Higher gas, slower | | Solana | Fast, low fees | The platform scans for the deposit continuously. Confirmation typically takes **5–10 minutes** after the transaction is included in a block. ### 4. Conversion Once the deposit is confirmed, funds are converted from USDC to the target fiat currency at the rate locked in step 1. Conversion uses institutional FX liquidity with a mid-market spread. ### 5. Outgoing transfer An outgoing transfer to the recipient's bank account (or mobile wallet) is created and funded automatically. No further action is required from the partner. ### 6. Settlement Settlement time depends on the payment rail: | Rail | Settlement | | ------------------------------------- | ------------------ | | Local bank transfer (most currencies) | Instant – same day | | M-PESA (KES) | Instant | | UPI (INR) | Instant | | SEPA/IBAN (EUR, GBP, others) | Same day | | ACH (USD) | 1–2 business days | | SWIFT | 5–7 business days | ### 7. Completion `status` transitions to `completed`. If you have an email address on file for the recipient, a notification is sent. *** ## Transfer Statuses | Status | Description | | ------------------ | ------------------------------------------------------------- | | `pending` | Transfer created, awaiting USDC | | `awaiting_deposit` | Deposit address issued, monitoring on-chain | | `deposit_sent` | USDC confirmed on-chain | | `processing` | Funds converting and routing to recipient | | `completed` | Funds delivered to recipient's bank | | `failed` | Error — see `error` field; contact support with `transfer_id` | *** ## Concurrent Transfers Multiple transfers can be in flight simultaneously — for the same account or different accounts. Each transfer has a unique deposit address and is settled independently. There is no serialization or per-user lock. *** ## Failure Handling The platform automatically retries internal routing steps. If a transfer reaches `failed` status, the `error` field contains a description. Contact support at with the `transfer_id` for resolution. Transfers that fail before USDC is sent can be cancelled via `POST /api/payouts/transfer/cancel` and retried with a fresh quote. *** ## Idempotency Pass a `customer_uuid` in the transfer request body to enable safe retries. If you submit the same `customer_uuid` twice, the second request returns `409 Conflict` with the original transfer details — no duplicate is created. # x402 Agentic Payments Call Madhouse's compliance, payout, and KYC APIs from an AI agent — paying per request in USDC with no API keys, via x402 and the AgentCash MCP. Madhouse exposes three production APIs that an autonomous agent can call and pay for **per request**, in USDC, with **no API key, no signup, and no invoice**. Each endpoint is gated by the [x402 protocol](https://x402.org): the first request returns `402 Payment Required` with payment terms, the client signs a USDC micropayment, retries, and gets the data. You don't implement x402 by hand. The [**AgentCash**](https://www.agentcash.dev) MCP server holds a USDC wallet and handles the 402 → sign → settle → retry loop for you. From the agent's side, it's a single `fetch` call. | Service | Base URL | What it does | | ----------- | ------------------------- | ---------------------------------------------------------------------- | | **Scanner** | `scan.madhousewallet.com` | Wallet risk scoring + sanctions name screening | | **Payouts** | `try.madhousewallet.com` | Quote and send cross-border fiat payouts (80+ currencies) | | **KYC** | `kyc.madhousewallet.com` | On-chain identity attestation (EAS / SAS) + wallet sanctions screening | All three accept USDC on **Base, Polygon, Arbitrum** (EVM) and **Solana**. Payment settles through the Coinbase CDP facilitator, which sponsors gas — you only pay the listed price. *** ## How payment works ``` Agent ──fetch──▶ endpoint ◀── 402 Payment Required (price, network, payTo, asset) AgentCash signs an EIP-3009 / SPL USDC transfer for the exact amount Agent ──fetch (X-PAYMENT header)──▶ endpoint ◀── 200 OK + JSON body ``` There are no refunds — the `exact` scheme moves funds on-chain before the handler runs. Endpoints that mutate state (transfers, KYC sessions) are idempotent upstream, so a retry after a network blip does not double-charge the business logic, but **each HTTP attempt that reaches a 402 and pays is a separate USDC charge**. Cache successful responses; don't poll paid endpoints in a tight loop. *** ## Using AgentCash (the fast path) AgentCash is already wired into this environment as an MCP server. The workflow is three tool calls: **1. Check / fund the wallet.** Paid calls need a balance; the free endpoints don't. ``` get_balance() → { "usdc": "4.92", ... } list_accounts() → deposit addresses + funding link (if balance is low) ``` **2. Discover the endpoints for a base URL.** This pulls the live OpenAPI + price for every route — you don't hardcode paths. ``` discover_api_endpoints("https://scan.madhousewallet.com") discover_api_endpoints("https://try.madhousewallet.com") discover_api_endpoints("https://kyc.madhousewallet.com") ``` **3. Call the endpoint.** `fetch` handles the 402 automatically and returns the final body. ``` fetch({ url: "https://scan.madhousewallet.com/api/public/quick-scan?address=vitalik.eth", method: "GET" }) ``` Pick the network with `fetch`'s payment options if you want to pay on Polygon/Arbitrum/Solana instead of Base — otherwise it defaults to the first accepted network (Base). Use `check_endpoint_schema` before a POST if you're unsure of the body shape. > If you're not running AgentCash, any x402 client works — see [Calling raw x402](#calling-raw-x402) at the bottom. *** ## Pricing Prices are fixed per call, charged in USDC regardless of which chain you pay on. The `/solana` variant of any endpoint is the same price as its EVM sibling — it just settles on Solana. ### `scan.madhousewallet.com` | Endpoint | Method | Price | Notes | | -------------------------------------------------------------------------- | ------ | ------------- | ---------------------------------------------------------- | | `/api/public/quick-scan` | GET | **$0.01** | \~350 ms. Risk score + traits only. | | `/api/public/scan` | GET | **$0.01** | \~9 s. Full metrics incl. USD volumes, ENS, contract flag. | | `/api/public/sanctions-check` | GET | **$0.04** | OpenSanctions name/entity screening. | | `/api/public/quick-scan/solana`, `/scan/solana`, `/sanctions-check/solana` | GET | same as above | Pay on Solana. | ### `try.madhousewallet.com` | Endpoint | Method | Price | | ---------------------------------- | ------ | --------- | | `/api/public/quote` | GET | **$0.01** | | `/api/public/requirements` | GET | **$0.01** | | `/api/public/requirements/refresh` | POST | **$0.01** | | `/api/public/recipients` | POST | **$0.01** | | `/api/public/transfer` | POST | **$0.01** | | `/api/public/confirm-transfer` | POST | **$0.01** | | `/api/public/transfer-status` | GET | **$0.01** | > A complete payout costs \~$0.05–0.06 in x402 fees (quote → requirements → recipient → transfer → confirm), separate from the FX/payout fees on the money itself. ### `kyc.madhousewallet.com` | Endpoint | Method | Price | | --------------------------- | ------ | ----------------------------------------------- | | `/api/public/kyc/start` | POST | **$0.05** | | `/api/public/kyc/status` | GET | **$0.01** | | `/api/public/kyc/sanctions` | GET | **$0.02** | | `/api/public/kyc/verified` | GET | **Free** (60 req/min/IP) | | `/api/public/kyc/start-eoa` | POST | **Free** (wallet-signature gated, 5 req/min/IP) | Each paid endpoint has a `/solana` twin at the same price. *** ## Scanner — wallet risk & sanctions `scan.madhousewallet.com` ### Quick scan (cheapest, real-time) Best for pre-transaction screening. Accepts a 0x address or an ENS name. **Request** ``` GET /api/public/quick-scan?address=0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045 ``` **Response — flagged** ```json { "address": "0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045", "toxicScore": 0.95, "riskLevel": "CRITICAL", "shouldFlag": true, "traits": [ { "name": "initiator_scam_transactions", "risk": 0.95, "txsCount": 1, "description": "The address has initiated scam airdrops or poisoning attacks." } ] } ``` **Response — clean** ```json { "address": "0x1234…", "toxicScore": 0, "riskLevel": "PASS", "shouldFlag": false, "traits": [] } ``` `riskLevel`: `PASS` (0) · `LOW` (0–0.40) · `MIDDLE` (0.41–0.80) · `CRITICAL` (≥0.81). ### Full scan Same input, slower (\~9 s), richer output: `flaggedMetrics[]` carries `type` (`absolute` | `volume`), `incomingMoneyUSD`, `outgoingMoneyUSD`, plus `ens`, `isContract`, `addressExists`. ```json { "address": "0xd8dA…", "toxicScore": 0.04, "riskLevel": "LOW", "shouldFlag": true, "flaggedMetrics": [ { "name": "non_kyc_transfers", "risk": 0.03, "type": "volume", "description": "Transacted with non-KYC exchanges", "txsCount": 344, "incomingMoneyUSD": 15722.47, "outgoingMoneyUSD": 2484.15 } ], "ens": "vitalik.eth", "isContract": false, "addressExists": true } ``` ### Sanctions name check ($0.04) Screens a person/company name against OpenSanctions (EU, UN + 330 lists). **Request** ``` GET /api/public/sanctions-check?name=Viktor%20Bout&country=ru&birthDate=1967-01-13 ``` `name` is required; `country` (ISO-2), `address`, and `birthDate` (`YYYY` or `YYYY-MM-DD`) are optional filters that cut false positives. **Response** ```json { "sanctioned": true, "name": "Viktor Bout", "matchCount": 1, "matches": [ { "entityId": "Q314650", "caption": "Viktor Anatolijevitch BOUT", "entityType": "Person", "topics": ["role.pep", "sanction", "debarment"], "matchedOn": ["name", "country", "birthDate"], "datasets": ["us_ofac_sdn", "us_trade_csl", "eu_financial_sanctions_files"] } ] } ``` **Edge cases** * **Score normalization.** `toxicScore` is 0–1, but the upstream may return 0–100 for confirmed bad actors. The API normalizes (`s > 1 ? s/100 : s`) — trust the returned 0–1 value. * **Off-ramp rule:** only `toxicScore === 0` is truly clean. `shouldFlag` is `true` for any non-zero score. * **Sparse sanctions matching is AND-logic with fallback:** a name-only query (e.g. `John Smith`) returns many matches because `country`/`birthDate` filters are skipped when absent. Read `matchedOn[]` per match to judge confidence — a hit on `["name","country","birthDate"]` is high-confidence; `["name"]` alone is weak. * `503` from sanctions = MongoDB blip; retry with backoff. `400` = missing `name` or bad address format. *** ## Payouts — cross-border fiat `try.madhousewallet.com` KYC and sanctions screening on the funding wallet and recipient are enforced upstream, so these endpoints are safe to drive from an agent. The flow is six paid calls: ``` 1. GET /api/public/quote → quoteId + FX rate + fees 2. GET /api/public/requirements?currency=NGN → dynamic bank-detail fields 3. POST /api/public/requirements/refresh → (only if a field has refreshRequirementsOnChange) 4. POST /api/public/recipients → recipientId 5. POST /api/public/transfer → transfer_id + deposit_address (user sends USDC to deposit_address on Base) 6. POST /api/public/confirm-transfer → status: processing GET /api/public/transfer-status?id=… → poll to completed ``` **Quote** ``` GET /api/public/quote?targetCurrency=NGN&sourceAmount=100 ``` ```json { "quoteId": "7f3c1a2b-0d9e-4a6f-8c11-2b9d4e5f6a7b", "sourceAmount": 100, "targetCurrency": "NGN", "usdToTargetRate": 1580.42, "serviceFeePercent": 1.5, "quote": { "targetAmount": 155661.4, "transferFee": 0.5, "feeFxPercent": 0.47, "feeFxAmount": 0.32, "feePayoutAmount": 0.18, "estimatedDelivery": "2026-06-01T12:00:00.000Z" } } ``` **Requirements** return field descriptors that vary per currency (Nigeria needs `bankCode` + 10-digit `accountNumber`; an IBAN country needs `IBAN`, etc.). If any field has `refreshRequirementsOnChange: true`, call `requirements/refresh` with the values chosen so far to reveal the conditional fields. **Create recipient → transfer** ``` POST /api/public/recipients { "currency":"NGN", "type":"nigeria_bank_account", "accountHolderName":"Ada Lovelace", "details":{ "bankCode":"058", "accountNumber":"0123456789" }, "wallet":"0x1234…" } → { "id": 12345, "active": true, ... } POST /api/public/transfer { "quote_id":"7f3c…", "amount":100, "recipientId":12345, "customer_uuid":"2b9d…", "customer_email":"sender@example.com", "source_token":"usdc", "source_network":"base", "wallet_address":"0x1234…" } → { "transfer_id":"6650f1a2b3c4d5e6f7a8b9c0", "deposit_address":"0x…", "amount":100, "currency":"NGN", "instructions": { "send_amount":100, "send_token":"usdc", "send_network":"base", ... } } ``` After the user sends USDC to `deposit_address`, confirm with the on-chain tx hash: ``` POST /api/public/confirm-transfer { "transfer_id":"6650f1a2b3c4d5e6f7a8b9c0", "tx_hash":"0xabc…def" } → { "transfer_id":"6650…", "status":"processing", "message":"Transfer confirmed and queued for payout." } ``` `transfer-status` cycles through `pending → awaiting_deposit → deposit_sent → processing → completed` (or `failed`). **Edge cases** * **Quotes expire (\~5 min).** A stale `quote_id` fails at `/transfer` — re-quote and retry. * **`amount` must equal the quote's `sourceAmount`.** Validation rejects mismatches; max is 1,000,000. * **Idempotency:** `confirm-transfer` is idempotent on `tx_hash` — re-submitting the same hash won't double-pay out. Generate one `customer_uuid` per logical transfer. * **Conditional fields:** skipping `requirements/refresh` when required leaves you with an incomplete recipient body → `400`. * Recipient/wallet rejected by upstream sanctions screening surfaces as a `4xx` with a message — don't retry, surface it. *** ## KYC — on-chain identity attestation `kyc.madhousewallet.com` Verifies a real person via Stripe Identity (document + selfie) and writes a permanent attestation on-chain — **EAS** on Base/Polygon/Arbitrum, **SAS** on Solana. The wallet that pays the x402 charge is the wallet that gets bound to the attestation. **Start a session** ($0.05). Body is empty — the payer wallet comes from the payment header. ``` POST /api/public/kyc/start body: {} → { "kycUrl": "https://kyc.madhousewallet.com/verify/vs_1Taj…", "walletAddress": "0xef61…73f7" } ``` Open `kycUrl` in a browser to finish verification. A Stripe webhook then writes the attestation on-chain automatically — no further call needed from you. **Check status** ($0.01). Authoritative: reads on-chain and checks revocation. ``` GET /api/public/kyc/status?wallet=0xef61…73f7 → { "walletAddress": "0xef61…73f7", "verified": true, "chain": "base", "easUID": "0x9f8e…0100", "txHash": "0xa1b2…a1b2", "sasAttestationAddress": null, "verifiedAt": 1716500000, "verificationMethods": { "documentType": "passport", "selfieCheck": "verified" }, "riskScore": "low" } ``` **Free verification check** — for gating logic at scale. DB-only, no on-chain read, no revocation check, rate-limited 60/min/IP. ``` GET /api/public/kyc/verified?wallet=0xef61…73f7 → { "wallet": "0xef61…73f7", "verified": true } ``` **Wallet sanctions** ($0.02). Screens the *verified person* behind a wallet against OpenSanctions. PII is pulled transiently from Stripe and **never stored or returned** — only the match metadata comes back. ``` GET /api/public/kyc/sanctions?wallet=0xef61…73f7 → { "walletAddress":"0xef61…73f7", "sanctioned": false, "matchCount": 0, "matches": [] } ``` **Edge cases** * **`verified: true` requires the attestation to be on-chain AND not revoked.** A wallet mid-flow (`awaiting_stripe` / `attesting`) returns `verified: false`, not an error. * **`/verified` (free) vs `/status` (paid):** use free for cheap gating; use paid `/status` when you need the revocation-checked source of truth. * **`/sanctions` needs a completed attestation first** — screening a wallet with no on-chain KYC record returns `404`. * **Pay-network ≠ attestation-chain.** The attestation chain is fixed at `/start` (EVM → Base by default; the `/solana` route → SAS on Solana). Paying `/status` on Polygon doesn't move the attestation. * `start-eoa` is the free, signature-gated entry point: prove wallet ownership with a signed nonce (valid 60 s) instead of paying. Recovered signer must match `walletAddress` or you get `401`. *** ## Networks & assets | Network | CAIP-2 | USDC contract | | -------- | ----------------------------------------- | ---------------------------------------------- | | Base | `eip155:8453` | `0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913` | | Polygon | `eip155:137` | `0x3c499c542cEF5E3811e1192ce70d8cC03d5c3359` | | Arbitrum | `eip155:42161` | `0xaf88d065e77c8cC2239327C5EDb3A432268e5831` | | Solana | `solana:5eykt4UsFv8P8NJdTREpY1vzqKqZKvdp` | `EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v` | EVM endpoints accept all three EVM chains on the **main path**; Solana settlement uses the explicit `/solana` route. CDP sponsors gas on every chain, so your wallet only needs the listed USDC amount — no ETH/SOL for gas. *** ## Common status codes | Code | Meaning | | ----- | ----------------------------------------------------------------------------------- | | `402` | Payment required — the client signs USDC and retries (AgentCash does this for you). | | `400` | Bad input — missing param, malformed address/tx hash, unsupported currency. | | `401` | Signature didn't match the claimed wallet (`start-eoa`). | | `404` | No record — e.g. KYC sanctions on an unverified wallet. | | `429` | Rate limit — only on the free KYC endpoints. | | `503` | Upstream blip (sanctions DB / scanner) — retry with backoff. | *** ## Discovery Every service publishes machine-readable discovery, which is what `discover_api_endpoints` reads: * `GET /.well-known/x402` — list of payable resource URLs. * `GET /openapi.json` — full OpenAPI 3.1 with `x-payment-info` (price, currency, network) and `x-payment-networks` per operation. Endpoints are also auto-registered in the Coinbase **Bazaar** after their first settlement, so x402-aware agents can find them without a hardcoded list. *** ## Calling raw x402 Without AgentCash, use any x402 client (e.g. `@x402/fetch` with a funded signer): ```ts import { wrapFetchWithPayment } from "@x402/fetch" import { privateKeyToAccount } from "viem/accounts" const account = privateKeyToAccount(process.env.PAYER_PRIVATE_KEY) const fetchWithPay = wrapFetchWithPayment(fetch, account) // signs the 402 + retries const res = await fetchWithPay( "https://scan.madhousewallet.com/api/public/quick-scan?address=vitalik.eth" ) console.log(await res.json()) ``` The signer needs only USDC on Base (or Polygon/Arbitrum/Solana) — gas is sponsored. For questions or integration support, contact . # Dashboard Managing your account at business.madhousewallet.com The Madhouse Wallet partner dashboard is available at [business.madhousewallet.com](https://business.madhousewallet.com). It provides a UI for everything you can do via the API, plus tools for managing your integration. *** ## Recipients The **Payouts** section lists all recipients you have created. From here you can: * **Add a recipient** — dynamic form that adapts to the selected currency, showing only the fields required for that rail (routing number, IBAN, sort code, UPI handle, CLABE, etc.) * **Search and filter** — find recipients by name or currency * **Delete a recipient** — blocked with a confirmation if a transfer is in progress *** ## Transfer History The **Transfer History** tab shows all past and in-progress transfers with: * Amount, currency, and recipient * Current status with timeline * On-chain transaction hash (once USDC is confirmed) * Timestamps for each status transition *** ## API Keys Navigate to **Developers → API Keys** to manage your integration credentials. | Action | Notes | | ------------------ | ----------------------------------------------------------------------------- | | **Create key** | Up to 5 keys per account. Full key shown once — copy immediately | | **Rename key** | Label keys by environment or integration (`prod`, `staging`, etc.) | | **Revoke key** | Immediate effect — in-flight requests using that key will fail | | **IP restriction** | Lock a key to a single IPv4 address. All requests from other IPs return `403` | Keys follow the format `mw_live__`. Rate limits are per key — each key has its own quota. *** ## Interactive API Docs The **Developers → API Docs** section at [developer.madhousewallet.com](https://developer.madhousewallet.com) provides: * Live "Try It" panels for every endpoint * Enter your API key once at the top — it applies to all requests * Real responses from the production API * cURL examples with one-click copy *** ## Fee Display The dashboard shows your current fee structure on the Send Money modal: * Transaction fee (fixed) * Platform fee (percentage) * Settlement fee (variable by rail) * Exchange rate and estimated receive amount Enterprise accounts with custom fee overrides see their discounted rates labeled in the UI. *** ## Account Settings * **Developer settings** — configure IP restriction for API keys * **Passkey management** — add, rename, or remove authentication passkeys * **Theme** — light/dark mode toggle # API Keys Creating and securing your API credentials API keys are the credential used to authenticate all requests to the Madhouse Wallet off-ramp API. *** ## Key Format ``` mw_live__ ``` * `keyId` — 8-character identifier visible in the dashboard * `secret` — 32-character hex string (128-bit entropy) The full key is shown **once** at creation. It is stored as a SHA-256 hash server-side and cannot be retrieved again. If lost, revoke the key and create a new one. *** ## Creating a Key 1. Sign in at [business.madhousewallet.com](https://business.madhousewallet.com) 2. Go to **Developers → API Keys** 3. Click **Create Key** 4. Optionally name the key (e.g. `production`, `staging`) 5. Copy the full key — it will not be shown again Up to **5 keys** per account. Each key has independent rate limits and last-used tracking. *** ## Using a Key Include the key in the `Authorization` header on every request: ```bash curl https://business.madhousewallet.com/api/payouts/quote \ -H "Authorization: Bearer mw_live_xxxxx_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx" \ -G -d "targetCurrency=NGN" -d "sourceAmount=500" ``` *** ## IP Restriction Lock a key to a specific IPv4 address to prevent use from any other origin. 1. In the dashboard go to **Developers → Settings** 2. Enter your server's public IPv4 address 3. Save — restriction takes effect immediately Requests from any other IP will receive `403 Forbidden`. To update the allowed IP, replace it in settings. An admin can also force-enable IP restriction on your account — in that case you cannot disable it, only change which IP is allowed. *** ## Rate Limits Limits are **per key** (not per account). A second key gets a second set of quotas. | Endpoint | Limit | | ------------------------- | ------------- | | Account requirements | 60 req/min | | Quote | 20 req/min | | Transfer (create) | 5 req/min | | Transfer (cancel, status) | 20–30 req/min | | Recipients | 30 req/min | Rate limit headers on every response: ``` X-RateLimit-Limit: 5 X-RateLimit-Remaining: 4 X-RateLimit-Reset: 1743254460 ``` *** ## Revoking a Key Go to **Developers → API Keys**, find the key, and click **Revoke**. Revocation is immediate — any in-flight request using that key will fail with `401`. Create a new key to replace it. *** ## Security Best Practices * Store keys in environment variables or a secrets manager — never in source code * Use one key per environment (`prod`, `staging`, `dev`) * Enable IP restriction on production keys * Rotate keys periodically; revoke any key that may have been exposed * Monitor `lastUsedAt` in the dashboard for unexpected activity # Supported Currencies The Madhouse Wallet off-ramp API supports **85 fiat currencies** across Africa, Asia, Europe, Latin America, the Middle East, and Oceania. *** ## Payment Rails by Region ### Africa | Code | Currency | Country | Payment Methods | | ---- | ------------------- | ------------ | -------------------------- | | GHS | Ghanaian Cedi | Ghana | Local bank account | | KES | Kenyan Shilling | Kenya | M-PESA, Local bank account | | MAD | Moroccan Dirham | Morocco | Local bank account | | NGN | Nigerian Naira | Nigeria | Local bank account | | RWF | Rwandan Franc | Rwanda | SWIFT | | TZS | Tanzanian Shilling | Tanzania | Local bank account | | UGX | Ugandan Shilling | Uganda | Local bank account | | ZAR | South African Rand | South Africa | Local bank account | | BWP | Botswanan Pula | Botswana | SWIFT | | CVE | Cape Verdean Escudo | Cape Verde | SWIFT | | EGP | Egyptian Pound | Egypt | IBAN | | GMD | Gambian Dalasi | Gambia | SWIFT | | GNF | Guinean Franc | Guinea | SWIFT | | MUR | Mauritian Rupee | Mauritius | SWIFT | | NAD | Namibian Dollar | Namibia | SWIFT | | SCR | Seychellois Rupee | Seychelles | SWIFT | | TND | Tunisian Dinar | Tunisia | SWIFT | ### Asia & Pacific | Code | Currency | Country | Payment Methods | | ---- | ----------------- | ----------- | -------------------------------------- | | BDT | Bangladeshi Taka | Bangladesh | Local bank account, bKash, E-Wallet | | CNY | Chinese Yuan | China | Alipay, WeChat Pay | | HKD | Hong Kong Dollar | Hong Kong | FPS ID, Local bank account | | IDR | Indonesian Rupiah | Indonesia | Local bank account, E-Wallet | | INR | Indian Rupee | India | Local bank account, UPI | | JPY | Japanese Yen | Japan | Local bank account | | KHR | Cambodian Riel | Cambodia | SWIFT | | KRW | South Korean Won | South Korea | PayGate (personal), PayGate (business) | | LAK | Laotian Kip | Laos | SWIFT | | LKR | Sri Lankan Rupee | Sri Lanka | Local bank account | | MNT | Mongolian Togrog | Mongolia | SWIFT | | MOP | Macanese Pataca | Macau | SWIFT | | MYR | Malaysian Ringgit | Malaysia | DuitNow, Local bank account | | NPR | Nepalese Rupee | Nepal | Local bank account | | PHP | Philippine Peso | Philippines | Local bank account | | PKR | Pakistani Rupee | Pakistan | IBAN | | SGD | Singapore Dollar | Singapore | Local bank account, PayNow | | THB | Thai Baht | Thailand | Local bank account | | VND | Vietnamese Dong | Vietnam | Local bank account | ### Europe | Code | Currency | Country | Payment Methods | | ---- | ------------------ | ---------------------- | -------------------------------------------- | | EUR | Euro | Eurozone | IBAN (inside Europe), SWIFT (outside), Email | | GBP | British Pound | United Kingdom | Local bank account (sort code), IBAN, SWIFT | | CHF | Swiss Franc | Switzerland | IBAN | | CZK | Czech Koruna | Czech Republic | Local bank account, IBAN | | DKK | Danish Krone | Denmark | IBAN | | GEL | Georgian Lari | Georgia | IBAN | | HUF | Hungarian Forint | Hungary | Local bank account, IBAN | | ILS | Israeli New Shekel | Israel | IBAN | | ISK | Icelandic Krona | Iceland | SWIFT | | NOK | Norwegian Krone | Norway | IBAN | | PLN | Polish Zloty | Poland | Local bank account, IBAN | | RON | Romanian Leu | Romania | IBAN | | RSD | Serbian Dinar | Serbia | SWIFT | | SEK | Swedish Krona | Sweden | IBAN | | TRY | Turkish Lira | Turkey | IBAN | | UAH | Ukrainian Hryvnia | Ukraine | IBAN, PrivatBank card | | ALL | Albanian Lek | Albania | SWIFT | | BAM | Convertible Mark | Bosnia and Herzegovina | SWIFT | | KGS | Kyrgystani Som | Kyrgyzstan | SWIFT | ### Latin America & Caribbean | Code | Currency | Country | Payment Methods | | ---- | ------------------ | ------------------ | ----------------------------------- | | ARS | Argentine Peso | Argentina | Local bank account | | BOB | Bolivian Boliviano | Bolivia | SWIFT | | BRL | Brazilian Real | Brazil | Local bank account, Brazil business | | CLP | Chilean Peso | Chile | Local bank account | | COP | Colombian Peso | Colombia | Local bank account | | CRC | Costa Rican Colon | Costa Rica | Local bank account | | DOP | Dominican Peso | Dominican Republic | SWIFT | | GTQ | Guatemalan Quetzal | Guatemala | SWIFT | | HNL | Honduran Lempira | Honduras | SWIFT | | MXN | Mexican Peso | Mexico | CLABE | | NIO | Nicaraguan Cordoba | Nicaragua | SWIFT | | PEN | Peruvian Sol | Peru | SWIFT | | PYG | Paraguayan Guarani | Paraguay | SWIFT | | SRD | Surinamese Dollar | Suriname | SWIFT | | UYU | Uruguayan Peso | Uruguay | Local bank account | ### Middle East | Code | Currency | Country | Payment Methods | | ---- | -------------- | -------------------- | ------------------ | | AED | UAE Dirham | United Arab Emirates | Local bank account | | BHD | Bahraini Dinar | Bahrain | SWIFT | | KWD | Kuwaiti Dinar | Kuwait | SWIFT | | OMR | Omani Rial | Oman | SWIFT | | QAR | Qatari Riyal | Qatar | SWIFT | | SAR | Saudi Riyal | Saudi Arabia | SWIFT | ### North America & Oceania | Code | Currency | Country | Payment Methods | | ---- | ------------------ | ------------- | --------------------------- | | USD | US Dollar | United States | ACH, Wire, SWIFT | | CAD | Canadian Dollar | Canada | Local bank account, Interac | | AUD | Australian Dollar | Australia | Local bank account, BPAY | | NZD | New Zealand Dollar | New Zealand | Local bank account | | BMD | Bermudian Dollar | Bermuda | SWIFT | *** ## Notes * **Dynamic requirements** — use `GET /api/payouts/account-requirements` to fetch exact field requirements for any currency before creating a recipient * **Email transfers** — email payout (recipient claims via an emailed link) is only supported for **EUR** * **CNY to China** — in addition to Alipay and WeChat Pay, we support sending CNY to China via SWIFT * Currency support is subject to change. Contact for the latest availability in a specific market
# Fees Transparent pricing for off-ramp transfers Madhouse Wallet pricing is designed to be predictable. All fees are disclosed in the quote response before a transfer is submitted. *** ## Fee Structure Every transfer carries two layers of cost: | Fee | Amount | | -------------------------------- | ----------------------------------------------------------------- | | **MadHouse Wallet platform fee** | 0.3% of transfer amount | | **Network FX & payout fee** | Varies by destination currency — see the per-currency table below | The **0.3% MadHouse Wallet platform fee is layered on top** of the network FX and payout fees listed below. Both are shown in the quote response before you commit to a transfer. *** ## Per-Currency Sending Rates Live data pulled **May 27, 2026**. Each row is one currency, sorted by currency code (A–Z). Payout fees are shown in the destination's local currency. The FX fee percentages below **do not include** the 0.3% MadHouse Wallet platform fee, which is added on top. | Region | Currency Code | Currency | FX Fee % | Payout fee | | ------------------------- | ------------- | ------------------- | -------: | ------------: | | Middle East | AED | UAE Dirham | 0.46% | 10.95 AED | | Europe | ALL | Albanian Lek | 0.90% | 162.01 ALL | | Latin America & Caribbean | ARS | Argentine Peso | 1.38% | 393.97 ARS | | North America & Oceania | AUD | Australian Dollar | 0.43% | 0.77 AUD | | Europe | BAM | Convertible Mark | 0.90% | 3.33 BAM | | Asia & Pacific | BDT | Bangladeshi Taka | 0.82% | 184.36 BDT | | Middle East | BHD | Bahraini Dinar | 0.90% | 0.75 BHD | | North America & Oceania | BMD | Bermudian Dollar | 0.90% | 1.98 BMD | | Latin America & Caribbean | BOB | Bolivian Boliviano | 0.90% | 13.66 BOB | | Latin America & Caribbean | BRL | Brazilian Real | 1.01% | 2.12 BRL | | Africa | BWP | Botswanan Pula | 0.95% | 61.90 BWP | | North America & Oceania | CAD | Canadian Dollar | 0.43% | 1.22 CAD | | Europe | CHF | Swiss Franc | 0.43% | 1.35 CHF | | Latin America & Caribbean | CLP | Chilean Peso | 0.75% | 1,894.98 CLP | | Asia & Pacific | CNY | Chinese Yuan | 0.47% | 20.85 CNY | | Latin America & Caribbean | COP | Colombian Peso | 2.10% | 10,088.44 COP | | Latin America & Caribbean | CRC | Costa Rican Colon | 1.45% | 3,718.37 CRC | | Africa | CVE | Cape Verdean Escudo | 0.90% | 188.30 CVE | | Europe | CZK | Czech Koruna | 0.50% | 22.34 CZK | | Europe | DKK | Danish Krone | 0.43% | 6.95 DKK | | Latin America & Caribbean | DOP | Dominican Peso | 0.90% | 116.62 DOP | | Africa | EGP | Egyptian Pound | 0.95% | 144.16 EGP | | Europe | EUR | Euro | 0.00% | 0.95 EUR | | Europe | GBP | British Pound | 0.48% | 0.45 GBP | | Europe | GEL | Georgian Lari | 1.47% | 3.89 GEL | | Africa | GHS | Ghanaian Cedi | 0.76% | 20.77 GHS | | Africa | GMD | Gambian Dalasi | 0.90% | 145.02 GMD | | Africa | GNF | Guinean Franc | 0.90% | 17,333.37 GNF | | Latin America & Caribbean | GTQ | Guatemalan Quetzal | 0.90% | 15.09 GTQ | | Asia & Pacific | HKD | Hong Kong Dollar | 0.47% | 5.93 HKD | | Latin America & Caribbean | HNL | Honduran Lempira | 0.90% | 52.76 HNL | | Europe | HUF | Hungarian Forint | 0.64% | 156.06 HUF | | Asia & Pacific | IDR | Indonesian Rupiah | 0.61% | 13,103.75 IDR | | Europe | ILS | Israeli New Shekel | 0.53% | 8.90 ILS | | Asia & Pacific | INR | Indian Rupee | 0.57% | 55.67 INR | | Europe | ISK | Icelandic Krona | 0.90% | 243.82 ISK | | Asia & Pacific | JPY | Japanese Yen | 0.51% | 220.93 JPY | | Africa | KES | Kenyan Shilling | 1.15% | 280.78 KES | | Europe | KGS | Kyrgystani Som | 0.90% | 173.26 KGS | | Asia & Pacific | KHR | Cambodian Riel | 0.90% | 7,973.12 KHR | | Asia & Pacific | KRW | South Korean Won | 0.71% | 2,335.11 KRW | | Middle East | KWD | Kuwaiti Dinar | 0.90% | 0.61 KWD | | Asia & Pacific | LAK | Laotian Kip | 0.90% | 43,401.68 LAK | | Asia & Pacific | LKR | Sri Lankan Rupee | 0.61% | 455.36 LKR | | Africa | MAD | Moroccan Dirham | 2.02% | 39.73 MAD | | Asia & Pacific | MNT | Mongolian Togrog | 0.90% | 7,075.11 MNT | | Asia & Pacific | MOP | Macanese Pataca | 0.90% | 15.98 MOP | | Africa | MUR | Mauritian Rupee | 0.90% | 93.72 MUR | | Latin America & Caribbean | MXN | Mexican Peso | 0.66% | 12.12 MXN | | Asia & Pacific | MYR | Malaysian Ringgit | 0.49% | 2.36 MYR | | Africa | NAD | Namibian Dollar | 0.91% | 85.45 NAD | | Africa | NGN | Nigerian Naira | 0.62% | 1,005.47 NGN | | Latin America & Caribbean | NIO | Nicaraguan Cordoba | 0.90% | 72.90 NIO | | Europe | NOK | Norwegian Krone | 0.43% | 10.89 NOK | | Asia & Pacific | NPR | Nepalese Rupee | 1.19% | 180.13 NPR | | North America & Oceania | NZD | New Zealand Dollar | 0.46% | 1.40 NZD | | Middle East | OMR | Omani Rial | 0.90% | 0.76 OMR | | Latin America & Caribbean | PEN | Peruvian Sol | 2.02% | 9.82 PEN | | Asia & Pacific | PHP | Philippine Peso | 0.72% | 35.75 PHP | | Asia & Pacific | PKR | Pakistani Rupee | 0.70% | 236.80 PKR | | Europe | PLN | Polish Zloty | 0.50% | 3.55 PLN | | Latin America & Caribbean | PYG | Paraguayan Guarani | 0.90% | 12,067.48 PYG | | Middle East | QAR | Qatari Riyal | 0.90% | 7.22 QAR | | Europe | RON | Romanian Leu | 0.49% | 4.51 RON | | Europe | RSD | Serbian Dinar | 0.90% | 199.59 RSD | | Africa | RWF | Rwandan Franc | 0.90% | 2,897.58 RWF | | Middle East | SAR | Saudi Riyal | 0.90% | 7.43 SAR | | Africa | SCR | Seychellois Rupee | 0.90% | 29.07 SCR | | Europe | SEK | Swedish Krona | 0.45% | 11.63 SEK | | Asia & Pacific | SGD | Singapore Dollar | 0.45% | 1.55 SGD | | Latin America & Caribbean | SRD | Surinamese Dollar | 0.90% | 73.40 SRD | | Asia & Pacific | THB | Thai Baht | 0.74% | 61.90 THB | | Africa | TND | Tunisian Dinar | 0.90% | 5.73 TND | | Europe | TRY | Turkish Lira | 0.44% | 109.07 TRY | | Africa | TZS | Tanzanian Shilling | 1.00% | 3,151.15 TZS | | Europe | UAH | Ukrainian Hryvnia | 0.73% | 30.24 UAH | | Africa | UGX | Ugandan Shilling | 1.59% | 4,745.51 UGX | | North America & Oceania | USD | US Dollar | 0.00% | 0.00 USD | | Latin America & Caribbean | UYU | Uruguayan Peso | 1.25% | 459.85 UYU | | Asia & Pacific | VND | Vietnamese Dong | 0.69% | 34,354.88 VND | | Africa | ZAR | South African Rand | 0.59% | 51.01 ZAR | *** ## Volume Pricing Larger transactions carry smaller effective fees as a percentage of the total. Enterprise partners can negotiate custom fee structures. *** ## Enterprise & Partner Pricing Volume discounts and revenue share programs are available. Contact to discuss pricing tiers for high-volume integrations. *** ## Quote Validity FX quotes are locked for **5 minutes**. The rate shown at quote time is the rate applied to the transfer — there are no surprise adjustments after submission.
# Funding Your Account Before initiating off-ramp transfers from the Madhouse Wallet dashboard, your Safe wallet on Base needs a USDC balance. This page covers how to fund it. *** ## Accepted Tokens & Chains | Token | Chains | | ----- | --------------------------------------------------- | | USDC | Arbitrum, Base, Ethereum, Optimism, Polygon, Solana | **Always send on the Base network when possible** — it has the lowest fees and fastest confirmation times. *** ## Funding Methods ### From a Centralized Exchange Transfer USDC directly from Coinbase, Binance, Kraken, or any exchange that supports Base network withdrawals: 1. In your exchange, initiate a withdrawal of USDC 2. Select **Base** as the network 3. Paste your Madhouse Wallet address as the destination 4. Confirm the transfer Funds typically arrive within 1–5 minutes. ### From Another Wallet Send USDC from MetaMask, Phantom, or any wallet that supports the chains listed above. Ensure you select the correct network — sending on the wrong network may result in unrecoverable funds. ### Via Crypto Swap Use the **Deposits → Crypto** tab in the dashboard to swap: * USDC from Ethereum, Tron, or other non-Base chains → USDC on Base * USDT → USDC on Base Fixed-rate quotes lock the rate before you send. Deposit addresses are unique per swap. See [Crypto Deposits](/funding-your-wallet/international-payments) for details. *** ## Checking Your Balance Your USDC balance on Base is displayed on the dashboard home screen and updated in real time. # Crypto Deposits The **Deposits → Crypto** tab lets you swap USDC or USDT from other chains (or networks) into USDC on Base, deposited directly to your Safe wallet. *** ## Supported Deposit Assets | Asset | Networks | | ----- | --------------------------------------------------------------------------------------- | | USDC | Ethereum, Tron, Polygon, Arbitrum, Optimism, Solana (not Base — that's the destination) | | USDT | Ethereum, Tron, Polygon, Solana | *** ## How It Works 1. **Select the asset and network** you want to send from 2. **Enter the amount** — a fixed-rate quote is generated instantly 3. **Review the quote** — rate locked for the duration shown 4. **Confirm** — a unique deposit address is generated for this swap 5. **Send** the exact asset and amount to the deposit address 6. The platform converts and delivers USDC on Base to your wallet automatically *** ## Fixed-Rate Quotes Quotes are fixed-rate — the amount of USDC you receive is guaranteed at the time you confirm, regardless of market movement during the transfer window. *** ## Settlement Time Most crypto swaps settle within **5–30 minutes** depending on the source chain's confirmation speed. *** ## Notes * Send the **exact amount** shown — underpayment will result in a partial or refunded swap * Each deposit address is **single-use** — generate a new one for each swap * Do not send unsupported assets to a deposit address # Security Madhouse Wallet is built on a security-first architecture. This section covers encryption, key management, authentication, and infrastructure controls. *** ## Summary | Control | Implementation | | ---------------------------- | -------------------------------------------------------------------- | | **Data at rest** | AES-256-GCM encryption | | **Data in transit** | TLS 1.2+ on all API traffic | | **Signing keys** | AWS KMS — keys never leave the HSM | | **API key storage** | SHA-256 hash only — plaintext never stored | | **API key entropy** | 128-bit (32-char hex secret) | | **Response encryption** | AES-256-GCM per-session for dashboard users | | **Webhook verification** | RSA-SHA256 signature validation | | **Dashboard authentication** | MFA: email OTP + WebAuthn passkey (two independent factors required) | | **Infrastructure** | AWS us-east-1 | | **Certifications** | SOC 2 audit in preparation · GDPR · CCPA | *** ## Authentication The API uses long-lived API keys for server-to-server requests. The dashboard uses **multi-factor authentication (MFA)**: an email OTP verification step followed by a WebAuthn passkey — there are no passwords. **Dashboard login (MFA):** 1. Email OTP — a 6-digit code sent to the registered address confirms email ownership 2. WebAuthn passkey — biometric or hardware key assertion (Touch ID, Face ID, Windows Hello, YubiKey) Both factors are required in sequence. This ensures that neither email access nor device possession alone is sufficient to authenticate. API keys are: * Generated with 128-bit entropy * Stored server-side as SHA-256 hashes only * Shown once at creation — never retrievable * Independently rate-limited per key * Optionally locked to a single IPv4 `/32` See [API Keys](/quickstart/api-keys) for full details. *** ## Infrastructure All infrastructure runs on **AWS us-east-1**. Signing keys for on-chain operations are managed in **AWS KMS** using secp256k1 key material. Private keys never leave the HSM — all signing operations are executed inside KMS. *** ## Certifications & Compliance * **SOC 2 Type II** — audit in preparation * **GDPR** compliant * **CCPA** compliant See [Compliance](/introduction) for regulatory details.
# Architecture This page describes the technical architecture of the Madhouse Wallet off-ramp platform. *** ## System Components ``` Partner / API Key Caller ↓ API Gateway (TLS 1.2+) ↓ withExternalAuth — JWT or API key validation ↓ Rate Limiter (per-key, sliding window) ↓ Handler Logic ↓ ┌─────────────────────────┐ │ MongoDB (UserSession, │ │ PayoutTransaction, │ │ RecipientOwnership) │ └─────────────────────────┘ ↓ FX & Routing Infrastructure ↓ On-chain USDC detection (multi-chain) ↓ Outgoing fiat transfer (local rails / SWIFT / SEPA) ``` *** ## Request Authentication Every API request passes through `withExternalAuth`, which: 1. Detects whether the `Authorization` header carries a JWT (dashboard session) or API key (`mw_live_...`) 2. For API keys: looks up the SHA-256 hash in MongoDB, stamps `lastUsedAt`, checks wallet requirement, enforces IP restriction if enabled 3. For JWTs: verifies ES256 signature against the app's own ECDSA keypair, checks MongoDB session record 4. Applies per-key rate limits before the handler runs *** ## Transfer Pipeline Each transfer follows an immutable state machine: ``` pending → awaiting_deposit → deposit_sent → processing → completed ↘ failed ``` Every state transition is written atomically to MongoDB. The deposit address is unique per transfer — on-chain deposits are matched to the correct `PayoutTransaction` record via the deposit address, not scanned from a shared pool. *** ## On-Chain Detection The platform monitors deposits across all supported chains simultaneously: * Arbitrum, Base, Optimism, Polygon (EVM-compatible) * Ethereum Mainnet * Solana When a USDC transfer to a deposit address is confirmed on-chain, the associated transfer record is updated and the conversion pipeline begins. *** ## FX Conversion Conversion uses institutional FX liquidity with real-time mid-market rates. Rates are locked at quote time for 5 minutes. No rate changes occur after a quote is accepted. *** ## Outgoing Settlement The outgoing fiat transfer is created and funded automatically after conversion. Settlement rails used depend on the recipient's currency: * **Local bank transfer** — instant to same-day (most currencies) * **SEPA/IBAN** — same day (EUR, GBP, and other European currencies) * **M-PESA** — instant (KES) * **UPI** — instant (INR) * **CLABE** — local (MXN) * **ACH** — 1–2 business days (USD) * **SWIFT** — 5–7 business days (global fallback) *** ## Data Storage All transfer records, recipient ownership, and session data are stored in MongoDB hosted on AWS (us-east-1), with controls designed to meet GDPR and CCPA requirements for the protection of customer data and personally identifiable information (PII). ### Encryption | Layer | Method | | --------------------------- | --------------------------------------------------------------------------- | | Data at rest | AES-256-GCM encryption applied to all stored records | | Data in transit | TLS 1.2 or higher enforced on all connections | | API keys | SHA-256 hashed before storage — plaintext is never persisted | | Dashboard session responses | AES-256-GCM encrypted per-session | | Signing keys | Held in AWS KMS; keys are generated and used within HSMs and never exported | ### PII Handling Recipient banking details (account numbers, routing numbers, IBAN, and similar fields) are treated as PII and are: * Encrypted at rest using AES-256-GCM * Never logged in plaintext * Accessible only to the authenticated partner or user who submitted them * Not shared with third parties beyond the settlement rail required to complete the transfer ### Data Minimisation and Retention Only data necessary to execute and audit a transfer is collected. Short-lived records (OTP codes, deposit challenges) are automatically purged using TTL indexes. Partners subject to GDPR may request deletion of personal data via the account dashboard or the support channel; requests are processed within the timeframes required by applicable law. ### Access Controls and Audit Trail * Sparse indexes ensure per-user data is isolated and fast to retrieve without cross-tenant exposure * Atomic `findOneAndUpdate` operations enforce state-machine transitions and prevent double-processing or race conditions that could expose stale data * Every state change is written with a timestamp, creating an immutable audit trail for each transfer * Access to production data stores is restricted to authorised personnel via IAM policies and is logged *** ## Smart Account Infrastructure For dashboard users initiating transfers from the Madhouse Wallet UI, the platform uses ERC-4337 smart accounts (Safe v1.4.1 on Base). Signing keys are held in AWS KMS and never exposed. Gas is paid in USDC via an audited paymaster — no ETH balance required. | Component | Audit | | ------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------ | | Safe v1.4.1 | [Audit report](https://github.com/safe-global/safe-smart-account/blob/v1.4.0/docs/Safe_Audit_Report_1_4_0.pdf) | | Pimlico ERC-20 Paymaster | [Quantstamp certificate](https://certificate.quantstamp.com/full/pimlico-erc-20-paymaster/ce056730-3f75-4711-9e81-c5dbfdfce74d/index.html) | | USDC | [Circle transparency reports](https://www.circle.com/transparency) | # Encryption & Key Management AES-256-GCM encryption and AWS KMS key management *** ## Data at Rest All sensitive data stored by the platform is encrypted using **AES-256-GCM**: * API response payloads for dashboard sessions are encrypted end-to-end with a per-session derived key * Session keys are derived as `HMAC-SHA256(masterKey, userId:sessionId)` — each session gets a unique key * Rotating the master encryption key immediately invalidates all active sessions ## Data in Transit All API traffic uses **TLS 1.2+**. There are no unencrypted endpoints. Incoming webhooks (from payment networks) are verified using **RSA-SHA256** signature validation against published public keys. Requests with missing or invalid signatures are rejected and logged. *** ## API Key Storage API keys are never stored in plaintext. Only the SHA-256 hash of each key is persisted in MongoDB: * **SHA-256** is appropriate here (not bcrypt) because 128-bit entropy makes brute-force infeasible and enables fast O(1) indexed lookups * The full key is shown once at creation via the dashboard and is not recoverable afterward * Revocation is instant — deleting the hash record immediately blocks all requests using that key *** ## Signing Keys (AWS KMS) On-chain signing operations (ERC-4337 UserOps, Safe transactions) use **AWS KMS** with secp256k1 key material: * The private key is generated inside and never leaves the KMS HSM * All signing requests call `kms.sign()` — the plaintext key is never in application memory * The IAM role requires only `kms:Sign` and `kms:GetPublicKey` — no export permissions * DER-encoded ECDSA signatures are normalized (low-S) for EVM compatibility *** ## WebAuthn Passkey Authentication Dashboard users authenticate using **WebAuthn passkeys** (device biometrics or hardware security keys): * No passwords stored anywhere in the system * Private keys are generated and stored by the device's secure enclave * The server verifies assertions using `@simplewebauthn/server` — the private key never leaves the device * Signature counters are checked on every login to detect cloned authenticators For high-value actions (initiating a transfer from the dashboard), a second passkey ceremony is required — generating cryptographic proof that the user physically authorized the specific action. *** ## Session Security | Layer | Lifetime | Purpose | | ------------------------- | --------- | ----------------------------------------------- | | JWT access token | 3 hours | API credential, auto-refreshed every 30 min | | `mw_sess` httpOnly cookie | 7 days | Session identity — not accessible by JavaScript | | MongoDB UserSession | 7 days | Server-side revocation support | | Session key (in-memory) | Page load | AES key — never persisted to disk | Deleting a `UserSession` record from MongoDB immediately invalidates all tokens for that session, even within the 3-hour JWT lifetime. # Authentication Madhouse Wallet uses **multi-factor authentication (MFA)** combining email verification and **WebAuthn passkeys** — no passwords. *** ## Signing In Login requires two sequential factors: 1. Go to [business.madhousewallet.com](https://business.madhousewallet.com) 2. Enter your account email 3. **Factor 1 — Email OTP:** A 6-digit code is sent to your email. Enter it to confirm you control the address. 4. **Factor 2 — Passkey:** Authenticate with your registered passkey — Touch ID, Face ID, Windows Hello, or a hardware security key (YubiKey, etc.) 5. You're in Both factors must be completed successfully in sequence. A valid passkey alone is not sufficient without the prior email verification step. *** ## How Passkeys Work A passkey is a cryptographic key pair generated by your device. The private key is stored in your device's secure enclave and never leaves it. The server stores only the public key. When you authenticate with your passkey: 1. The server issues a challenge 2. Your device signs the challenge with your private key (biometric confirmation required) 3. The server verifies the signature against your stored public key No password is ever transmitted. Phishing is structurally impossible — the passkey is bound to the domain. *** ## Why MFA? The email OTP step adds a second, independent factor that cannot be satisfied by passkey compromise alone. Even if a threat actor obtained physical access to an enrolled device, they would also need access to the registered email inbox to complete login. *** ## Adding a Passkey From **Settings → Passkeys**, you can register additional passkeys (e.g. a YubiKey as a backup). You can have multiple passkeys on one account. Using a hardware security key (YubiKey or similar FIDO2 device) is recommended for maximum security — it cannot be compromised by malware on the host device. *** ## Removing a Passkey Passkeys can be renamed or deleted from **Settings → Passkeys**. Deleting your last passkey is blocked — you must always have at least one registered. If you lose access to all your passkeys, account recovery is available via email OTP verification. # Compliance Regulatory licensing, compliance framework, and partner responsibilities Madhouse Wallet is operated by The Walker Ledger Ltd, a company registered in Kenya, and maintains compliance infrastructure across all jurisdictions where funds are off-ramped. *** ## Regulatory Status | | | | --------------------- | ------------------------------------------------------- | | **Operating Entity** | The Walker Ledger Ltd — registered in Kenya | | **FX Infrastructure** | Licensed in all jurisdictions where funds are delivered | *** ## Compliance Partner AML, KYC, and sanctions screening are supported by **Comply Factor**. *** ## Compliance Sections * [Regulatory Licensing](/introduction/bitcoin-economics) — jurisdictional coverage and FX licensing * [Partner Responsibilities](/introduction/personal-finance) — what your integration is required to handle * [Risk Management](/introduction/risk-management) — AML controls, screening, and ongoing monitoring * [SOC Type 1](/introduction/soc-type-1) — internal controls, Trust Services Criteria, and compliance alignment # Regulatory Licensing *** ## International Payout Coverage Madhouse Wallet's FX and settlement provider holds the necessary licenses to operate in all jurisdictions where fiat payouts are delivered. This covers: * **Africa**: Kenya, Nigeria, Ghana, Tanzania, Uganda, South Africa, and others * **Asia**: India, Philippines, Indonesia, Bangladesh, Malaysia, and others * **Europe**: Eurozone (SEPA), United Kingdom, and others * **Latin America**: Brazil, Mexico, Colombia, and others * **Middle East**: UAE, Saudi Arabia, and others Partners operating in specific markets should contact to confirm current licensing status for their target jurisdictions. *** ## AML & CFT Program Madhouse Wallet maintains a full AML and Counter-Terrorism Financing (CFT) program aligned with: * FATF Recommendations * EU AML Directives (AMLD 5 & 6) * UK Money Laundering Regulations * UN Security Council Resolutions Full policy documentation is available in the [Legal Policies](/legal-policies) section. *** ## Data Retention Transaction records are retained for a minimum of **5 years** to satisfy regulatory requirements. Standard operational data retention is **90 days**, with custom retention periods available on request. # Partner Responsibilities Madhouse Wallet is a B2B infrastructure provider. Madhouse Wallet performs KYC and KYB on end customers who transact through the platform, and partners are also responsible for compliance with their own end users. *** ## KYC / KYB Responsibility Madhouse Wallet performs KYC and KYB on end customers who transact through the platform, including identity verification and sanctions screening. This is a shared, layered responsibility: **partners are also required to KYC their own end users** before allowing them to initiate transfers via the Madhouse Wallet API, as set out in our Master Services Agreement (MSA). Your compliance program remains responsible for: * Identity verification of end users * Sanctions screening of senders and recipients * Transaction monitoring for suspicious activity * Reporting obligations in your jurisdiction *** ## Partner Onboarding Partner KYB (your business's verification with Madhouse Wallet) typically takes **3–5 business days**. During onboarding you will provide: * Business registration documents * Beneficial ownership information * Compliance program overview * Target markets and expected transaction volumes *** ## Acceptable Use The API may not be used for: * Transactions involving sanctioned entities or jurisdictions * Structuring or layering to evade AML thresholds * Transfers with no identifiable legitimate economic purpose Madhouse Wallet reserves the right to suspend access for activity that violates our compliance policies or applicable law. *** ## Transaction Limits | Tier | Per-transaction limit | | -------------------------- | --------------------- | | Default (new integrations) | $9,000 | | Verified enterprise | Up to $1,000,000 | Limit increases are available after review. Contact . *** ## MSA & Legal All partners must execute a Master Services Agreement before going live. Contact to begin onboarding. # Risk Management *** ## AML Controls Madhouse Wallet operates a risk-based AML program. All transfers are subject to: * **Sanctions screening** — UN, EU, and UK consolidated lists checked on every transfer * **Transaction monitoring** — behavioral anomaly detection and threshold alerts (>$10,000) * **Recipient verification** — ownership of recipient accounts is enforced via our internal records; a recipient cannot be used by a different account * **Ongoing screening** — elevated-risk accounts are rescreened quarterly *** ## Risk Tiers | Level | Criteria | Review Cadence | | ------ | -------------------------------------------------------- | --------------- | | Low | Standard business profile, transactions under $10K/month | Every 5 years | | Medium | Transactions over $10K/month, cross-border | Every 2–3 years | | High | PEPs, high-risk geographies, complex ownership | Annual | *** ## Suspicious Activity Madhouse Wallet files Suspicious Activity Reports (SARs) within **7 working days** of detection. Red flags include: * Refusal to provide source of funds * Transfers to conflict zones or sanctioned states * High-volume transactions structured below reporting thresholds * Recipients that cannot be independently verified *** ## Transaction Failure Policy Transfers that fail compliance review are placed in a **hold** state (maximum 72 hours) for manual review. Madhouse Wallet does not hard-fail transactions for compliance reasons — only delays while review is conducted. The 98% off-ramp success rate reflects that the vast majority of transfers complete without intervention. *** ## Partner Obligations See [Partner Responsibilities](/introduction/personal-finance) for details on what your integration must handle, including end-user KYC and local reporting requirements. # SOC Type 1 Madhouse Wallet has undergone a SOC 1 Type I self assessment to demonstrate that the controls protecting partner and customer data are suitably designed as of a specific point in time. This page describes the principal control areas evaluated and how the platform addresses each one. *** ## What SOC 1 Type I Covers A SOC 1 Type I report evaluates whether a service organisation's internal controls relevant to user entities' financial reporting are **suitably designed** at a specific date. It does not test whether controls operated effectively over a period (that is covered by Type II). The examination covers five Trust Services Criteria: Security, Availability, Processing Integrity, Confidentiality, and Privacy. *** ## Security Controls are designed to prevent unauthorised access to systems and data. | Control | Implementation | | ------------------------------- | ------------------------------------------------------------------------------------------------------ | | API authentication | Every request passes through `withExternalAuth` — JWT (ES256 / ECDSA) or API key (SHA-256 hash lookup) | | API key entropy | 128-bit (32-character hex secret); plaintext shown once and never stored | | IP allowlisting | Per-key IPv4 `/32` restriction available to all partners | | Rate limiting | Sliding-window per-key rate limits enforced before handler logic runs | | TLS enforcement | TLS 1.2 or higher required on all inbound and outbound connections | | Signing key isolation | Secp256k1 keys held in AWS KMS; all signing operations execute inside the HSM — keys never exported | | Webhook integrity | RSA-SHA256 signature validation on all outbound webhook deliveries | | Intrusion and anomaly detection | AWS-native monitoring and alerting on IAM, network, and database layers | *** ## Availability Controls are designed to ensure the system is available for operation as committed. | Control | Implementation | | ------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Infrastructure | AWS us-east-1 — managed, multi-AZ capable environment | | Database resilience | MongoDB with atomic write operations; no single point of failure for state transitions | | Stateless API layer | Horizontally scalable request handlers; no session state held in application memory | | On-chain monitoring | Parallel monitoring across all supported chains (Arbitrum, Base, Optimism, Polygon, Ethereum Mainnet, Solana) ensures deposit detection is not dependent on a single RPC provider | | Incident response | Defined escalation path for infrastructure incidents; SLA commitments communicated to partners via the dashboard | *** ## Processing Integrity Controls are designed to ensure processing is complete, accurate, timely, and authorised. | Control | Implementation | | ------------------------ | ---------------------------------------------------------------------------------------------------------------------------------- | | Immutable state machine | Each transfer progresses through a defined sequence: `pending → awaiting_deposit → deposit_sent → processing → completed / failed` | | Atomic state transitions | `findOneAndUpdate` operations prevent double-processing and race conditions | | Unique deposit addresses | Every transfer receives a unique on-chain deposit address — funds cannot be misrouted to the wrong record | | FX rate locking | Rates are locked at quote time for 5 minutes; no rate change occurs after a quote is accepted | | Timestamped audit trail | Every state change is written with a timestamp, creating an immutable record of transfer lifecycle events | | Idempotency | Duplicate transfer attempts are rejected at the API layer before any state is written | *** ## Confidentiality Controls are designed to protect information designated as confidential. | Control | Implementation | | ------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------ | | Data at rest | AES-256-GCM encryption applied to all stored records in MongoDB | | Data in transit | TLS 1.2+ enforced on all API traffic and database connections | | API key storage | SHA-256 hashed before persistence — plaintext is never written to the database or logs | | Dashboard session data | AES-256-GCM encrypted per-session; session tokens validated against signed MongoDB records | | Recipient banking details | PII fields (account numbers, IBAN, routing numbers) encrypted at rest and never logged in plaintext | | Third-party data sharing | Recipient details are passed only to the settlement rail required to complete the specific transfer; no data is sold or shared for commercial purposes | | Access controls | Production data access restricted to authorised personnel via AWS IAM policies; all access is logged | *** ## Privacy Controls are designed to handle personal information in accordance with the organisation's privacy commitments and applicable regulations (GDPR, CCPA). | Control | Implementation | | ------------------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Data minimisation | Only data necessary to execute and audit a transfer is collected | | PII classification | Banking details, email addresses, and identity fields are classified as PII and subject to elevated controls | | Short-lived record expiry | OTP codes and deposit challenges are auto-purged via MongoDB TTL indexes | | Retention and deletion | Partners subject to GDPR or CCPA may request deletion of personal data via the account dashboard or support channel; requests are fulfilled within the timeframes required by applicable law | | Consent and disclosure | Data collection and use is documented in the [Privacy Policy](/legal-policies/privacy) | | Cross-border transfer controls | Personal data transferred outside the EEA is handled in accordance with GDPR Chapter V requirements | | Sub-processor oversight | Third-party processors (AWS, Comply Factor) are contractually bound to equivalent data protection standards | *** ## Logical Access and Change Management | Control | Implementation | | ---------------------------- | --------------------------------------------------------------------------------------------------------------- | | Principle of least privilege | IAM roles grant only the permissions required for each service or operator function | | Segregation of duties | Production deployments require review and approval; no single engineer can push to production without oversight | | Audit logging | All privileged access and configuration changes are logged and retained | | Change control | Code changes follow a documented review and approval process before deployment | | Dependency management | Third-party libraries are reviewed and pinned; updates are tested before production rollout | *** ## Compliance Alignment The controls described on this page collectively support the following certifications and regulatory obligations: | Framework | Status | | ------------- | -------------------------- | | SOC 1 Type I | Controls suitably designed | | SOC 2 Type II | Audit in preparation | | GDPR | Compliant | | CCPA | Compliant | For questions about the SOC 1 examination, to request a copy of the report, or to discuss control evidence with your compliance team, contact us at . # Legal Policies # Terms and Conditions Madhouse Wallet Terms and Conditions ("Terms") Please read these Terms and Conditions ("Terms", "Terms and Conditions") carefully before using the Madhouse Wallet website and the Madhouse Wallet mobile application (the "Service"). Madhouse Wallet is operated by The Walker Ledger Ltd, a company registered in Kenya ("us", "we", or "our", "The Walker Ledger Ltd"). \ Your access to and use of the Service is conditioned on your acceptance of and compliance with these Terms. These Terms apply to all visitors, users and others who access or use the Service.\ By accessing or using the Service you agree to be bound by these Terms. If you disagree with any part of the terms then you may not access the Service. \ Purchases\ If you wish to purchase any product or service made available through the Service ("Purchase"), you may be asked to supply certain information relevant to your Purchase including, without limitation: your name; your occupation and professional qualifications; your contact information such as your home or work address, telephone and email contact details; your payment details/financial information, such as your bank account or credit card details; any social media applications and services that we provide; your account security credentials, such as username and passwords; information about how you use our products and services; information in connection with communications you send us, for example to report a problem; and where necessary, additional information as part of our user authentication process. Automated collection of information \ Subscriptions\ Some parts of the Service are billed on a subscription basis ("Subscription(s)"). You will be billed in advance on a recurring monthly basis based on the Subscription you have selected. In order to serve you better, we might need the following information but not limited to: your name; your occupation; your contact information such as your home or work address, telephone and email contact details; your payment details/financial information, such as your bank account or credit card details; your social media applications and services that we provide; your account security credentials, such as username and passwords; information about how you use our products and services; information in connection with communications you send us, for example to report a problem; and where necessary, additional information as part of our user authentication process. Automated collection of information \ Content\ Our Service allows you to post, link, store, share and otherwise make available certain information, text, graphics, videos, or other material ("Content"). You are responsible for the content you post on any of our typeforms and shall be held liable for any incidents or terms arising from sharing such information. You are prohibited from using the Website to post or transmit any threatening, libellous, defamatory, obscene, scandalous, inflammatory, pornographic or profane material, any material that is contrary to applicable local, federal, or international laws and regulations, or any material that could constitute or encourage unlawful conduct. We may from time to time monitor or review material transmitted or posted using the Website and we reserve the right to delete any material our company deems inappropriate. We are under no obligation to do so and assume no responsibility or liability arising from any material transmitted or posted using the Website. \ Links To Other Websites\ Our Service may contain links to third-party web sites or services that are not owned or controlled by Madhouse Wallet. Madhouse Wallet has no control over, and assumes no responsibility for, the content, privacy policies, or practices of any third party web sites or services. You further acknowledge and agree that Madhouse Wallet shall not be responsible or liable, directly or indirectly, for any damage or loss caused or alleged to be caused by or in connection with use of or reliance on any such content, goods or services available on or through any such web sites or services. \ Changes\ We reserve the right, at our sole discretion, to modify or replace these Terms at any time. If a revision is material we will try to provide at least 14 days' notice prior to any new terms taking effect. What constitutes a material change will be determined at our sole discretion. \ Contact Us\ If you have any questions about these Terms, please contact us with the contacts provided on the Site. Madhouse Wallet is operated by The Walker Ledger Ltd, a company registered in Kenya. # Privacy INTRODUCTION This Privacy Policy governs the practices of how The Walker Ledger Ltd, a company registered in Kenya and the operator of Madhouse Wallet (referred to herein as “we”, “our”, “ours” or “us”, "The Walker Ledger Ltd"), collects, uses, transfers and shares personal information related to your use of our Services and the App. This Policy is designed to align with the General Data Protection Regulation (“GDPR”) provisions. It is committed to ensuring the transparent, lawful, equitable, and secure management of our Users' data. Our Privacy Policy explains what kind of personal data we gather through our App and Services, how and why we collect it, our purposes for its use, and the third parties we may share it with. Moreover, it explains how you, as a data subject, may exercise your rights about your data. We strongly encourage you to read this Policy to understand the processes involving your data and your associated rights. For inquiries related to this Privacy Policy, data collection and usage, data disclosure and sharing, or any other concerns or requests related to your data, please do not hesitate to contact us via the communication channels mentioned above. ‍ DEFINITIONS The following section covers the basic definitions used in this Privacy Policy. It describes what your data means and who controls and processes your data. Personal Data: Personal data means any information about an identified or identifiable natural person. This includes details like names, addresses, email addresses, identification numbers, and even IP addresses or cookie identifiers, as well as any information found online that may reveal your physical, genetic, mental, economic, cultural or social identity. Data Subject: The data subject is the person the personal data is about. In simpler terms, it’s you or any other individual whose personal information is being collected and processed. Data Controller: The data controller is the one who determines the purposes and means of processing personal data. In other words, they're the boss when deciding why and how your data is used. In this case, it would be us. Data Processor: The data processor, on the other hand, processes personal data on behalf of the data controller. In our case, they are vendors and partners we collaborate with that process your data for purposes determined by us. ‍ DATA PROTECTION OFFICER We have designated a data protection officer (“DPO”) to supervise inquiries regarding this privacy policy. Should you have any inquiries or questions concerning this Privacy Policy or our privacy procedures, or if you wish to exercise your legal rights as a data subject, please do not hesitate to contact our Data Protection Officer at . ‍ INFORMATION WE COLLECT We need to gather information about you to provide our Services and offer our Products. ‍ Information that You Provide This category covers your content and details using our Services and the App. We will never request information about your racial or ethnic background, personal life, sexual orientation, political views, philosophical or religious beliefs, biometric or genetic data, or trade union membership. When you create your Account, we may request your contact information, including your full name, personal address, email address, and phone number. Additionally, to verify your identity in compliance with legislative requirements, we may collect the following personal information as outlined in the table below: ‍ | Category of personal information | Examples of personal information (list non-exhaustive) | | -------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Identity data |

- Full name

- Date of birth

- Gender

- Nationality

- Passport number

- Social security number

- Driver's licence number

- National ID card details

| | Contact data |

- Email address

- Phone number

- Physical address

- Mailing address

- Emergency contact information

| | Financial data |

- Bank account numbers

- Credit card information

- Income details

- Tax identification number

- Financial transaction history

| | Location data |

- GPS coordinates

- Location history

- Wi-Fi access point data

- IP addresses

| | Employment data |

- Employment details

- Job titles and descriptions

- Workplace location

| | Transaction data |

- Purchase and sale history

- Transaction amounts

- Payment methods used

- Billing addresses

- Order amounts

| | Usage data |

- Website or app usage patterns

- Session durations

- Pages visited

- Clickstream data

- Error logs and crash reports

| | Marketing data |

- Marketing preferences

- Subscriptions and newsletter preferences

- Responses to marketing campaigns

- Engagement with promotional materials

- Referral sources

| | User Account data |

- Usernames and account identifiers

- Profile pictures and avatars

- User-generated content (profile descriptions, bios)

- User preferences and settings

- Social connections and followers

| | Social media data |

- Social media profiles

- User-generated content (posts, comments)

- Friends and connections

- Social network activity

| ‍ ‍ Communications If you contact us directly, we may request additional information such as your name, email address, personal address, phone number, and other relevant personal details. Whenever we ask for this information during communication, we will clearly explain the reasons behind it. Payment Information Our Services enable users to select their preferred payment method for executing Orders and Transactions via third-party credit and financial institutions and payment service providers. We do not retain your financial account information; the payment provider securely handles it. Note that these vendors may, in turn, collect and process your personal information on their behalf and for their purposes and obligations. To learn more about how third-party payment service providers and financial institutions collect, use and share your personal information, you are encouraged to read their privacy policies or notices provided on the official websites of the respective service providers. FBO Bank Account Providers We collaborate with third-party Merchant FBO Bank Account Providers to facilitate transactions with Fiat currencies. In such cases, we may receive information you shared with these Merchant FBO Bank Account Providers as part of your transactions. This information may include transaction history, account details, and other relevant financial data. Strict privacy and security standards govern our use of this data to ensure the confidentiality and integrity of your financial information. API Integrations We may integrate with third-party APIs like Plaid and Chainlink to provide you with certain features and services. These integrations allow us to access and retrieve specific financial data with your explicit consent. The data obtained through such integrations may include bank account information, transaction history, account balances, and other financial details. We utilise this data to offer enhanced features and allow you to purchase Crypto Funds in exchange for fiat currency before depositing it into your account. Your consent is sought and obtained when accessing your financial data through API integrations, and you retain control over the scope of data shared. Identity Verification Partners To ensure the security and integrity of our Services, we collaborate with identity verification partners who provide us with access to specific personal data required for identity verification purposes. This data may comprise full names, address information, identification document images and data, personal identification codes, identification document holder photos, date of birth, citizenship, place of birth and other relevant identity-related data. Blockchain Data We may collect publicly available blockchain data to monitor and detect illegal activities, including those defined by applicable laws and regulations. This data may include blockchain transaction details, wallet addresses, and other relevant blockchain information. ‍ HOW WE USE YOUR DATA Lawful Basis and Legitimate Interest Our collection, use, and sharing of your data are founded on various lawful bases, depending on the context. The following scenarios represent the circumstances in which we engage in data collection: Consent: We process your data when you grant your explicit consent. This typically occurs when you have reviewed our data processing purposes and willingly agreed to them. Examples include subscribing to our marketing notifications and campaigns or permitting the use of your personal information to enhance your experience while using our App and Services. Performance of a contract: We process your information when performing a contract with you is essential. This encompasses situations where your data is required for processing and finalising your orders or adhering to the terms of any other contractual agreement we have entered into with you. It also includes enforcing the terms of this Policy and other agreements, providing our Services, ensuring the quality of our Services, and offering customer service and support. Legal Obligation: We use your data when a legal obligation necessitates data disclosure. This occurs when compliance with legal requirements imposed by law or legal orders is mandatory. Legitimate Interests: We may process your data when we have a legitimate interest that aligns with the operation and provision of our Services. This includes activities aimed at improving our App, maintaining proper security measures, and preventing illegal activities related to your data. Our legitimate interests are pursued only when they do not infringe upon our fundamental rights. In the table below, you will find the list of purposes for which we use your data and what lawful bases we invoke for its use. ‍ | Purpose | Purpose description | Lawful basis | | ------------------------------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Providing and Maintaining Services and App | Providing and maintaining Services and the App: Managing the operation and maintenance of our Services to ensure their functionality and availability | Performance of a contract | | Payment Processing and Order Execution | Processing payments and executing Orders in compliance with market fairness, transparency, competitiveness, and genuineness rules | Performance of a contract | | Fraud Prevention | Detecting and preventing fund losses, including those resulting from fraud and misuse of our Services and App | Legitimate interest | | Compliance with Laws and Regulations | Ensuring compliance with relevant laws and regulations, including anti-money laundering, terrorism financing, fraud prevention, and other financial crime regulations |

Compliance with a legal obligation

Performance of a contract

Legitimate interest: ensuring that we do not deal with funds resulting from proceeds of crime, such as money laundering or terrorist financing, and do not assist in or facilitate in any manner any financial crime and other criminal activities.

| | User Communication and Support | Communicating with you directly or through our partners for customer support, notifications regarding changes and updates to the Services, crucial service-related information, marketing, and promotional purposes. | Performance of a contract | | User Notifications | Sending various communications, including notifications, reminders, and confirmations, to keep you informed about your activities and our Services | Performance of a contract | | Service Improvement | We are continuously improving the quality, performance, and features of our Services. | Legitimate interest: to grow our business continuously, to implement the industry's best practices and adhere to its standards, to attract potential customers and users to use the Services and the App | | Research and Development | Conducting research and development activities related to our Services, including the development of new features and functionalities of the App and the introduction of new products and services | Legitimate interest: to improve the functionality of our Services and the App, to ensure the competitiveness of our product, to grow our business and attract potential customers and users by introducing novel features and providing continuous development of the App | | Measurement and Analytics | Performing measurement and analytics to understand how our users interact with our Services, analyse user behaviour, and identify user preferences |

Legitimate interest: to learn how users interact with and use our Services and App, to conduct studies, to develop a marketing strategy and implement amendments to the Services, fixes and new features

Consent, if required

| | Safety and Security | Promoting the safety, security, and integrity of your funds, our Services, and data through protective measures and ongoing monitoring |

Legitimate interest: to ensure the security of our data and funds, to prevent unauthorised access to your account and irreversible loss of funds.

Performance of a contract

| | User Account Management | Managing user accounts, including account setup, recovery, and termination | Performance of a contract | | Personalization | Tailoring user experiences based on preferences and behaviours for personalised content and recommendations |

Legitimate interest: to ensure that our users receive information and content that they opt to see, to enhance user experience and customer satisfaction

Consent, if required

| | Third-Party Service Providers | Engaging third-party service providers for specific tasks such as payment processing and customer support |

Legitimate interest

Consent, if required

| | User Feedback | Collecting user feedback to improve our services and gather valuable insights |

Performance of a contract

Legitimate interest: to gather feedback from our users to learn of errors, issues and problems arising from the use of Services and the App, to implement fixes, to develop new features and to ensure customer satisfaction with our Services and the App.

Consent, if required

| | Record Keeping | Maintaining records for auditing, accounting, and compliance purposes by applicable laws | Compliance with a legal obligation | | Partnerships and Collaborations | Sharing data with partners, collaborators, or affiliates for joint initiatives, promotions, or integrated services | Legitimate interest: to ensure certain functionality of our App, to develop and grow our business | | User Education | Providing educational resources and training materials to enhance user knowledge and promote secure service usage | Legitimate interest: to educate our users and enhance your experience on the App | | Social Media Use | Using social media channels, such as Twitter and Discord, for advertising, notification and customer support, among others |

Consent

Performance of a contract

| ‍ HOW WE SHARE YOUR DATA We may share the information we collect with various third parties to support and enhance our business operations (data sub-processors). You may find a list of our sub-processors annexed at the end of this Policy. FBO Bank Account Providers In certain instances, we may share your personal information with FBO Bank Account Providers to facilitate the exchange of fiat currency to cryptocurrency as part of your transactions. Additionally, we collaborate with Metamask to enable the seamless connection of your wallet to your account for enhanced functionality. Identity Verification Services We utilise third-party identity verification services to ensure compliance with legal requirements under relevant law and to uphold your activities' safety, transparency, and lawfulness. Using our verification partners' services, we cross-reference the personal information you provide, or a third party offers with the information in our databases and public records. Law Enforcement We may share your information with law enforcement agencies and competent authorities in exceptional circumstances and as applicable laws and regulations require. This is done to support investigations, maintain legal compliance, and ensure the safety and security of our App and users. It may be necessary in the case of court proceedings, complying with a legal order or other legal process, as well as for financial crime, money laundering and terrorism financing prevention, if we have substantial grounds to believe any natural or legal person to be involved in or associated with the said forms of crime. ‍ HOW YOUR DATA IS SECURED At Madhouse Wallet we consider the security of your personal information paramount. We employ various technical, organisational, and administrative measures to safeguard your data against unauthorised access, disclosure, alteration, and destruction. These security measures include: Data Encryption: We utilise industry-standard encryption protocols to protect data during transmission and storage. This ensures that your information remains confidential and secure. Access Controls: Access to your personal information is restricted to authorised personnel who require access for legitimate business purposes. Access controls and authentication mechanisms are implemented to verify and restrict access. Employee Training: Our team is trained in data security best practices to ensure they handle your information with care and adhere to strict data protection guidelines. Incident Response: We have established incident response procedures to address and mitigate any security incidents or breaches promptly, should they occur. Blockchain Technology: Our App operates on blockchain technology, inherently providing transparency, immutability, and decentralisation. This ensures that your transactional and personal data is stored securely across multiple nodes, reducing the risk of unauthorised alterations or data breaches. User-Controlled Data: As an App User, you control your personal information through private keys and digital wallets. Your data is encrypted and accessible only by you, reducing the exposure to external threats. Smart Contracts: We employ intelligent contracts, self-executing and tamper-proof agreements, to govern and automate transactions. These contracts enhance security by reducing the need for intermediary intervention and minimising the risk of fraud. Cryptography: Robust cryptographic protocols secure data transmission and storage within our App. This ensures that your sensitive information remains confidential and protected from unauthorised access. Regular Audits and Updates: Our team conducts regular security audits and updates to identify and mitigate potential vulnerabilities or weaknesses in our App's infrastructure. We remain committed to staying at the forefront of security best practices in the blockchain space. Data Minimization: We collect and store only the minimum personal information necessary to facilitate your transactions and provide our Services. Unnecessary data is not retained, reducing the potential impact of any security incidents. User Education: We encourage users to educate themselves about blockchain security best practices and the responsible management of private keys and digital assets. We provide resources and guidance to help you protect your data effectively. While we take extensive measures to protect your data, it's also essential for users to play a role in their data security. We encourage you to: * Use strong, unique passwords for your Metamask and payment accounts connected to the App; * Enable multi-factor authentication when available; * Keep your login credentials confidential; and * Regularly update your account information and review access permissions. If you ever have concerns about the security of your data, suspect any unauthorised activity, or would like to know the specific measures undertaken to secure your data, please don't hesitate to contact us via Telegram or Discord. ‍ DATA RETENTION Your personal information is held and stored securely for your active account with us. We are committed to retaining your personal information only for the period necessary to fulfil the specific purposes for which it was collected. The retention periods may vary depending on the type of personal information and the purposes for which it was initially gathered. Here's an outline of our data retention practices: | Category | Retention purposes and periods | | ----------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Legal obligations | Personal information related to our legal obligations, such as compliance with anti-financial crime and anti-money laundering laws and regulations, may be stored for as long as these legal requirements mandate. We are dedicated to upholding our legal obligations and ensuring that data is retained as necessary to meet these standards. | | Marketing contact information | Contact information used for marketing purposes is retained only for your consent. If you decide to withdraw your consent, this data is promptly deleted from our records. | | Correspondence with us | Correspondence with us may be retained for up to five years. This ensures we can maintain accurate quality assurance, dispute resolution, and compliance records. | | Technical information | Information collected through technical means, such as cookies and analytics, is retained for up to one year. This data assists us in improving the performance and functionality of our services and enhancing your overall experience. | | Transaction history | Transaction records, including details of cryptocurrency transactions and innovative contract interactions, may be retained for up to five years to ensure transparency, auditability, and dispute resolution. These records help users track their transaction history and support the integrity of the blockchain network. | | Smart contract data | Data related to intelligent contracts executed within the App may be retained indefinitely on the blockchain for transparency and verification. Smart contract data is typically accessible and immutable as per the nature of blockchain technology. | | User preferences | User preferences and settings, such as language preferences or interface customisation, may be stored for as long as necessary to maintain a personalised user experience. This data allows users to have a consistent and tailored interaction with the App. | | Error and debug logs | Logs of errors and debugging information may be retained for up to three years to identify and resolve technical issues. These logs support the continuous improvement and maintenance of the App's functionality. | | Consent records | Records of user consent, particularly in the context of data processing, are retained for as long as the consent is valid, plus five years after its withdrawal. These records help verify that users have provided informed consent for specific data processing activities and comply with the relevant legal requirements imposed on us. | | Blockchain metadata | Metadata associated with blockchain transactions, such as timestamps and block numbers, may be retained as part of the blockchain's permanent ledger. | | Security and Access Logs | Logs of user access and security-related events, such as login attempts and authentication records, may be retained for security monitoring and threat detection for up to five years. These logs help protect the dApp from unauthorised access and breaches. | ‍ YOUR RIGHTS AS DATA SUBJECT As a User of our Services and the App, you have certain rights regarding the personal data that we collect and use. These rights are designed to give you control and transparency over your data. The following are your rights as a data subject: Right to Access: You can request access to the personal data we hold about you. This includes the right to obtain confirmation of whether we are processing your data and, if so, access to specific details of that processing. Right to Rectification: If you believe that the personal data we hold about you is inaccurate or incomplete, you have the right to request the correction or completion of such data. Right to Erasure (Right to Be Forgotten): You have the right to request the deletion of your data under certain circumstances. This right is not absolute and may be subject to legal requirements or legitimate interests that override your request. Right to Restriction of Processing: You can request the restriction of processing of your data in certain situations. We will limit how we use your data, but we may continue storing it. Right to Data Portability: In some cases, you have the right to receive your data in a structured, commonly used, and machine-readable format and to transmit it to another data controller. Right to Object: You can object to processing your data, including for direct marketing purposes or when we rely on legitimate interests as our legal basis for processing. Rights Related to Automated Decision-Making and Profiling: We commit to transparent and fair automated decision-making processes. If you are subject to automated decision-making that produces legal effects or significantly affects you, you can request human intervention and reconsider the decision. ‍ Exercising Your Rights To exercise any of the rights outlined above or if you have any questions or concerns regarding processing your data, don't hesitate to get in touch with our Data Protection Officer (DPO) at . Our DPO will assist you in addressing your data-related inquiries and ensuring that your rights as a data subject are respected and upheld. You will not be charged a fee for accessing your data or exercising any abovementioned rights. If your request is manifestly unfounded or excessive, we reserve the right to charge a reasonable fee. This fee, if applicable, will be based on the administrative costs associated with processing your request. Alternatively, we may refuse to comply with your request in these exceptional circumstances. If such a situation arises, we will explain our decision clearly and transparently. Please note that we will always act by applicable data protection laws and regulations when assessing the reasonableness of any fees or the validity of requests. Under the GDPR, we are committed to responding promptly to legitimate requests regarding your data. The statutory period for us to reply to such requests is one month from the date of receipt. However, when the request is particularly complex or has a high volume of requests, we may extend this period by up to two months as necessary. This extension will be based on carefully considering the complexity and number of requests received. ‍ POLICY CHANGES We may periodically update this Privacy Policy to reflect changes in our data processing practices and legal requirements or to improve transparency and clarity. When we make significant changes to this policy, we will notify you through the following channels: Direct updates to the Policy: Any substantial changes to this Privacy Policy will be incorporated directly into the Policy and available for viewing through the App. We encourage you to review this Policy periodically to stay informed about how we handle your data. Notification via Twitter: We will use our official Twitter account to announce essential updates and changes to the Privacy Policy. Follow us on Twitter to receive messages and stay informed about the latest developments. Contact Us\ If you have any questions about these Terms, please contact us with the contacts provided on the Site. Madhouse Wallet is operated by The Walker Ledger Ltd, a company registered in Kenya.
# Counter Terrorism 1\. Purpose & Scope This policy defines the commitment of The Walker Ledger Ltd, a company registered in Kenya and the operator of Madhouse Wallet, to prevent its platform—including investment dashboards, and related services—from being used for money laundering (ML) or terrorist financing (TF). Scope: * Applies to all clients (individuals and entities), employees, contractors, affiliates, and agents. * Covers onboarding, monitoring, transaction review, and ongoing due diligence. * Addresses compliance with international AML/CFT regulatory frameworks. 2\. Regulatory Compliance Framework This policy aligns with the following laws and recommendations: * Financial Action Task Force (FATF) Recommendations * European Union Anti-Money Laundering Directives (AMLD 5 & 6) * U.K. Money Laundering Regulations (MLR) * UN Security Council Resolutions related to terrorist financing * Applicable authorities based on geographic operations 3\. Key Definitions * Money Laundering (ML): Concealment of the origins of illegally obtained money. * Terrorist Financing (TF): Collection or provision of funds with the intention of supporting terrorist acts or organizations, regardless of whether funds are derived from a lawful or unlawful source. * Counter-Financing of Terrorism (CFT): Policies and controls aimed at identifying, preventing, and reporting activities related to terrorism financing. * Sanctioned Entity/Person: Individuals or organizations listed by national or international bodies as being involved in terrorism or other illicit activity. * Politically Exposed Person (PEP): Someone with a prominent public role, including their family members and close associates. 4\. CFT-Specific Obligations 4.1 Risk Identification * Transactions or relationships involving jurisdictions with documented terrorist activity, FATF black/gray-listing, or international conflict zones are flagged. * Transactions with no clear economic rationale, or involving frequent cross-border movements, especially to/from high-risk jurisdictions, are treated as high-risk. 4.2 Customer Due Diligence (CDD) * CDD measures include checking customers and UBOs against: * * UN 1267/1989 Sanctions List * EU Consolidated Sanctions List * Interpol watch lists * Customers must disclose any affiliation with religious, political, or humanitarian entities subject to international sanctions. 4.3 Enhanced Due Diligence (EDD) * Required when: * * The customer is from or transacts with a high-risk jurisdiction * A customer or UBO is on a sanctions or terrorist list * Inconsistencies arise in customer profile vs transaction behavior EDD includes: * Source of funds/wealth checks * Directorial or UBO background checks * Transaction activity monitoring with velocity and volume tracking * Senior management approval prior to onboarding or continuation 4.4 Sanctions Screening & Monitoring * Daily updated automated screening of all customers and counterparties * Transaction monitoring algorithms specifically trained to detect: * * Layering techniques * Use of informal remittance systems (e.g., hawala) * Transfers to/from conflict zones or sanctioned countries 5\. Governance & Reporting 5.1 Internal Oversight * A Designated CFT Compliance Officer shall be appointed to: * * Oversee implementation of CFT controls * Liaise with relevant authorities (e.g., FIU-IND) * Conduct annual risk-based CFT assessments * The Principal Officer retains overall responsibility for SARs, CFT policy updates, and compliance certification. 5.2 Suspicious Activity Reporting (SAR) * CFT-related SARs must be filed within 7 working days of suspicion. * SARs may include: * * Use of funds by a person linked to a terrorist group * Multiple small transactions meant to avoid detection * Fund transfers with no legitimate business or personal rationale * Tipping off (informing the customer of the investigation) is strictly prohibited. 6\. Record-Keeping & Audit Trails * All CFT-related data, including: * * Identification details * Transaction logs * Investigative notes * Sanctions checks\ will be preserved for a minimum of 5 years. * Audit logs are encrypted and accessible only to Compliance and designated officers. 7\. Training & Awareness * All staff undergo CFT training annually, including: * * Terrorist financing typologies * Red flags and escalation procedures * Legal obligations and reporting framework * Frontline and risk personnel receive scenario-based workshops on CFT trends. 8\. Policy Review and Updates * This policy is reviewed at least annually, or immediately following: * * Updates from FATF or the UN * Change in business model * Red flag incidents or internal investigations 9\. Red Flags for Terrorist Financing
Red Flag CategoryExamples
GeographicTransfers to conflict zones or sanctioned states (e.g. Syria, North Korea)
BehavioralRefusal to provide source of funds; attempts to obscure ownership
TransactionalDonations to unverifiable NGOs; inconsistent with customer’s known profile
StructuralFrequent use of third parties; high volume of small transactions under thresholds
10\. Commitment to Global Financial Integrity Madhouse Wallet acknowledges the global threat of terrorism and pledges to be part of the financial community’s effort to stop terrorist financing. This CFT-integrated KYC/AML policy supports our belief that financial transparency and vigilance are non-negotiable in safeguarding global peace and ethical innovation in finance. # Anti Money Laundering This Anti-Money Laundering policy is maintained by The Walker Ledger Ltd, a company registered in Kenya and the operator of Madhouse Wallet. 1\. Purpose & Applicability * To prevent misuse of our platform for money laundering, terrorist financing, fraud, or illicit activity. * Applies to all customers, users, merchants, agents, business lines, and relevant staff. 2\. Regulatory Framework This policy aligns with global best-practice and regional AML/KYC regimes, including: * FATF recommendations * EU AMLD6 * U.K. Money Laundering Regulations * Other applicable frameworks where operations or clients exist 3\. Definitions & Roles * Customer: Any individual or legal entity interacting with services, including franchises, and administrators. * Beneficial Owner (BO): Natural person(s) controlling ≥ 25% ownership in an entity customer. * Politically Exposed Person (PEP): Individuals in prominent public functions or their close associates. * Principal Officer: Appointed person responsible for overall AML compliance, filing Suspicious Activity Reports (SARs), and liaising with FIUs. * Compliance Team: Responsible for ongoing monitoring, risk assessments, training, and audits. * Board: Oversees and approves this policy annually. 4\. Customer Risk Assessment 4.1 Risk-Based Approach (RBA) Customers are assigned a baseline risk score—Low, Medium, or High—based on: 1. Geographic Risk 2. * High-risk jurisdictions (e.g., FATF grey/blacklist) * Special PEP screening when relevant jurisdictions are involved 3. Customer Type 4. * Retail individuals (typically low–medium risk) * Corporates, trusts, and partnerships (inherently higher risk) 5. Business Profile & Activity 6. * Share purchasers (investment nature) * High-volume or cross-border server hosting clients 7. Transaction Patterns 8. * One-off high-value cross-border invoice * Repetitive, rapid, or multi-jurisdiction deposits/withdrawals 9. Sanctions/Adverse Media 10. * Continuous watchlist and media screening 4.2 Risk Scoring
Risk LevelParametersMeasures
LowIndividuals in stable geos, invoices < $10K/monthStandard CDD; periodic review every 5 yrs
Mediuminvoices > $10K/month, entity accounts, cross-borderEDD; KYC reviews every 2–3 yrs
HighPEPs, sanctioned/named entities, high-risk geographiesEDD+, senior approval, annual KYC refresh
5\. Customer Identification & Verification (CIP / CDD) 5.1 Individual Customers Required Documents: * Government-issued photo ID (passport, driver’s license) * Proof of address (utility/phone bill ≤ 3 months old) * Selfie or liveness check via biometric solution Verification: * Use automated ID verification (e.g., facial match); fallback to manual if needed. * Sanctions, PEP, and adverse media screening pre-onboarding. 5.2 Business (Entity) Customers Required Documents: * Certificate of Incorporation / Registration * Memorandum & Articles or equivalent * List of directors + verified IDs * UBO declaration with ≥ 25% share confirmed via identity docs * Proof of address (entity) * Bank statement or ownership documents Process: * Validate UBOs and board members via ID and address proofs. * Politically exposed status and sanctions of directors/UBOs checked. * Ongoing adverse media, sanctions screening. 6\. Ongoing Monitoring & Transaction Surveillance * Real-time transaction monitoring with threshold alerts (e.g., > $10,000 / €10,000). * Behavioral anomaly detection—unusual geographic changes, frequency spikes, cross-border patterns. * System flags for atypical deposit sources or known bitcoin/wallet risk. * Monthly review of elevated-risk accounts by Compliance Team. * Sanction list rescreening quarterly or with updates. 7\. Enhanced Due Diligence (EDD) Triggered for: * High-risk geographies, PEPs, shell companies, complex ownership structures, large purchases. EDD Requirements: * Detailed source-of-funds (bank statements, income documents). * High-resolution ID, certified translation (if non-English). * Interview process (in person or video). * Senior Compliance Officer sign-off required. 8\. Sanctions & PEP Screening All new and existing clients and transactions screened against: * United Nations, EU, U.K., and locally relevant lists. * Repeat screenings quarterly or upon list updates. * Immediate account suspension for hits pending investigation. 9\. Suspicious Activity Reporting (SAR) * Any suspicious transaction filed as SAR within 7 days of detection. * Guidelines: * * Structuring/smurfing behavior * UBO concealment, false documentation * Rapid buy-sell without rationale * Compliance logs incident, escalates to Principal Officer, submits SAR to FIU. * No tipping-off allowed—employees trained accordingly. 10\. Record Retention * Identification documents: retain for 5 years post-account closure. * Transaction logs (purchases, hosting payments): 5 years retention. * SARs / Investigations: archived securely for 5+ years. * Stored with encryption; access restricted by role-based controls. 11\. Governance & Accountability * The Board of Directors oversees policy approval, updates, and compliance. * Principal Officer accountable for execution and regulatory liaison. * Compliance Team performs daily screening, monitoring, and internal audits. * External audit once per year; risk-based internal audits quarterly. 12\. Training & Culture * AML/KYC onboarding for all staff, contractors, server purchasers. * Refresher training at least annually or with legal updates. * Specialized sessions in fraud detection, PEP screening, sanctions, mobile payments, high-risk money flows. 13\. Technology & Integration * Biometric liveness from automated ID verification providers. * Sanctions/PEP screening through reputable data providers. * Transaction monitoring system with AI-based anomaly detection. * Investor dashboard for secure interaction, logs preservation. * Ongoing discussion with third-party cybersecurity consultants (per site note). 14\. Policy Review & Update * Official annual review by Compliance Team and Legal Counsel. * Immediate revision triggers: * * Regulatory changes (e.g., new EU rules) * Emerging financial crime techniques * Product expansions * Technological/logistics changes (e.g., third-party integrations) 15\. Governance Matrix
RoleResponsibility
Board of DirectorsPolicy approval and strategic oversight
Principal OfficerSAR filing, external reporting, policy implementation
Compliance TeamKYC verification, monitoring, audit, reporting
IT / Security TeamEnsuring system integrity, encryption, audit logs
All EmployeesFlagging AML/CTF concerns, completing training
16\. Annex – Risk Indicators & Red Flags * High-value purchases from obscure shell entities * Use of multiple IP addresses for same customer * Attempts to obscure UBO structure or beneficial ownership * Multiple small payments aggregating into large deposits * Transfers originating from high-risk jurisdictions * Discrepancy between customer profile and transactional behavior # Audits Madhouse Wallet's smart account infrastructure uses audited, battle-tested protocols. All smart contracts and tokens used in the platform have undergone independent security audits. *** ## Smart Contracts | Protocol | Purpose | Audit | | ------------------------ | ------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------ | | Safe v1.4.1 | Smart account wallet on Base | [Audit report](https://github.com/safe-global/safe-smart-account/blob/v1.4.0/docs/Safe_Audit_Report_1_4_0.pdf) | | Pimlico ERC-20 Paymaster | USDC gas payment for ERC-4337 UserOps | [Quantstamp certificate](https://certificate.quantstamp.com/full/pimlico-erc-20-paymaster/ce056730-3f75-4711-9e81-c5dbfdfce74d/index.html) | ## Tokens | Token | Issuer | Transparency | | ----- | ------ | ------------------------------------------------------------------ | | USDC | Circle | [Circle transparency reports](https://www.circle.com/transparency) | *** ## Infrastructure Security In addition to smart contract audits, the Madhouse Wallet platform undergoes regular security assessments: * **Penetration testing** — third-party security reviews of the API and dashboard * **Dependency scanning** — automated vulnerability detection on all dependencies * **SOC 2 Type II** — audit in preparation Contact to request security documentation under NDA. # Partner Program Madhouse Wallet offers a revenue share program for partners who refer integrations. *** ## How It Works 1. Introduce another business to Madhouse Wallet 2. They sign up and complete onboarding 3. Provide their account ID to us for verification 4. We link your account to receive commission 5. Earn **0.2% of all transaction volume** from that partner — for the lifetime of their account *** ## Who Qualifies Any business that becomes an active API integration partner via your introduction qualifies. This includes: * Wallet providers * Crypto exchanges * Fintechs and payment platforms * Payroll and remittance companies *** ## Getting Started Reach out to or via our support channel to register your referral and get started.
# Datasheet ## Madhouse Wallet — Off-Ramp API Datasheet **Company:** Madhouse Wallet\ **Website:** \ **API Docs:** \ **API Changelog:** \ **Support:** *** ### 1. Company Overview | | | | ------------------------ | ------------------------------------------- | | **Company Name** | Madhouse Wallet | | **Operating Entity** | The Walker Ledger Ltd (registered in Kenya) | | **Year Founded** | 2024 | | **Contact** | | | **Supported Flow Types** | Off-ramp (stablecoin → fiat) | | **Widget UI Sample** | | *** ### 2. API & Integration | | | | ------------------------------------------------ | ---------------------------------------------------------------- | | **API Documentation** | | | **Integration Models** | Direct API, Widget UI | | **Fully Programmatic (no front-end required)** | Yes | | **Versioned with Changelog** | Yes — | | **Sandbox / Staging Environment** | Yes | | **Sub-accounts / Virtual Account Creation** | No | | **Batch Multi-Currency Processing** | No | | **Webhooks (status & settlement notifications)** | Planned — not yet available | | **Developer Support** | Yes — dedicated Slack channel | #### Response Times | Operation | Typical Latency | | ----------------------- | ----------------- | | FX Quote | 2–3 seconds | | Trade Execution | 3–5 minutes | | Settlement Confirmation | 2–3 seconds | | ACH Settlement | 0–2 business days | | SWIFT Settlement | 5–7 business days | | All other local rails | Instant | #### Key API Endpoints | Method | Endpoint | Description | Rate Limit | | ------ | ----------------------------------- | --------------------------------------------------------- | ---------- | | GET | `/api/payouts/account-requirements` | Required fields for a target currency | 60 req/min | | POST | `/api/payouts/account-requirements` | Refresh fields after a dependent field change | 60 req/min | | GET | `/api/payouts/quote` | USD → target currency exchange quote | 20 req/min | | POST | `/api/payouts/transfer` | Initiate a USDC payout; returns deposit address | 5 req/min | | POST | `/api/payouts/transfer/cancel` | Cancel a pending transfer (before USDC is sent) | 20 req/min | | GET | `/api/payouts/transfer/:id` | Get transfer status and details (DB snapshot) | 30 req/min | | GET | `/api/payouts/transfer-status/:id` | Get transfer status with live quote and recipient details | 30 req/min | | GET | `/api/payouts/recipients` | List recipients | 30 req/min | | POST | `/api/payouts/recipients` | Create a payout recipient | 30 req/min | | GET | `/api/payouts/recipients/:id` | Fetch a single recipient | 30 req/min | | DELETE | `/api/payouts/recipients/:id` | Delete a recipient (blocked if transfer in flight) | 30 req/min | #### Transfer Flow (API Key Callers) 1. `GET /api/payouts/account-requirements` — fetch required fields for target currency 2. `POST /api/payouts/recipients` — create recipient with validated fields 3. `GET /api/payouts/quote` — get a 5-minute locked FX quote; receive `quoteId` 4. `POST /api/payouts/transfer` — submit transfer with `quoteId`; receive `escrow_wallet` (deposit address) and `expires_at` 5. Send exact USDC amount to the deposit address from `source_wallet` within the expiry window 6. The platform detects the deposit, converts funds, and routes to the recipient's bank account automatically 7. Poll `GET /api/payouts/transfer-status/:id` for live status updates *** ### 3. Compliance & Licensing | | | | -------------------------------------- | ----------------------------------------------------------------------- | | **Regulatory Licenses** | Licensed FX & settlement infrastructure across payout jurisdictions | | **Money Transmission** | Handled via licensed settlement partners | | **End-User Compliance (B2B)** | Madhouse Wallet KYCs end users; partners also KYC their own per our MSA | | **Compliance Partner** | Comply Factor | | **Partner KYB Onboarding Time** | 3–5 business days | | **End-Customer KYC** | Performed by Madhouse Wallet and the partner (layered KYC) | | **Travel Rule** | N/A | | **Ongoing AML / Sanctions Monitoring** | Yes | *** ### 4. Operational Performance | | | | ------------------------------ | ------------------------------------------------------------------- | | **Off-Ramp Success Rate** | 98% | | **Common Failure Causes** | Compliance review (delay only, max 72 hours — never a hard failure) | | **Automatic Retry on Failure** | Yes | | **Average Time to Resolution** | Minutes | *** ### 5. Pricing & Commercial Terms | | | | ------------------------------- | ----------------------------------------------------------------------- | | **FX Spread** | Mid-market rate | | **Transaction Fee** | 0.3% | | **Platform Fee** | 0.5% | | **Settlement Fee** | Variable; typically under 1% for transactions above 500 USDC | | **FX Quote Validity** | 5 minutes | | **Minimum Volume Commitment** | None | | **Enterprise / Volume Pricing** | Revenue share programs available — contact | *** ### 6. Currency & Market Coverage #### Off-Ramp Fiat Currencies Supported 85 currencies across Africa, Asia, Europe, Latin America, the Middle East, and Oceania. See the full table in Section 11. #### Operational Jurisdiction * FX infrastructure is licensed in all jurisdictions where funds are off-ramped #### Maximum Transaction Size | Tier | Limit | | ------------------------------ | -------------------------------- | | Default starting tier | $9,000 per transaction | | Verified / enterprise partners | Up to $1,000,000 per transaction | #### Daily / Monthly Capacity No per-currency cap — the underlying FX infrastructure is highly liquid. *** ### 7. Chain & Asset Support | | | | --------------------------------------- | ----------------------------------------------------------- | | **Supported Stablecoin** | USDC | | **Supported Blockchains** | Arbitrum, Base, Ethereum Mainnet, Optimism, Polygon, Solana | | **Deposit Addresses** | Per-transfer (unique address per transaction) | | **Multi-Chain Deposits** | Yes — specify the chain in the API request | | **Stablecoin Settlement Timeframe** | 5–10 minutes after deposit confirmation | | **Blockchain-Native AML / Travel Rule** | No | *** ### 8. Liquidity & FX | | | | ---------------------------------------------- | -------------------------------------------------------- | | **FX Spread Source** | Determined by our institutional FX infrastructure | | **Liquidity Model** | External institutional liquidity providers | | **Rate Refresh Frequency** | Real-time | | **Rate Lock During Execution** | Yes — 5-minute locked quote via `GET /api/payouts/quote` | | **Max Liquidity Per Currency Per Transaction** | $1,000,000 USD equivalent | | **Supported Pairs** | USDC → any currency in the supported currencies table | *** ### 9. Settlement & Payout Operations | | | | ------------------------------------------ | -------------------------------------------------------- | | **Settlement Timeframes** | Instant (most local rails); ACH 1–2 days; SWIFT 5–7 days | | **Programmable Disbursement via API** | Yes — fully API-driven after recipient creation | | **Settlement Currency ≠ Invoice Currency** | No | | **Settlement Netting** | Per-transaction gross settlement | #### Transfer Status Lifecycle | Status | Meaning | | ------------------ | ------------------------------------------ | | `pending` | Transfer created; awaiting USDC deposit | | `awaiting_deposit` | Deposit address issued; waiting for USDC | | `deposit_sent` | USDC confirmed on-chain | | `processing` | Funds being converted and routed | | `completed` | Funds delivered to recipient bank | | `failed` | Error — contact support with `transfer_id` | *** ### 10. Security & Data | | | | --------------------------- | --------------------------------------------------------------- | | **Cloud Infrastructure** | AWS us-east-1 | | **Encryption at Rest** | AES-256 | | **Encryption in Transit** | TLS 1.2+ (all API traffic); RSA for webhook verification | | **API Response Encryption** | AES-256-GCM per-session encrypted responses for browser clients | | **Key Management** | AWS KMS (secp256k1 signing keys never leave KMS) | | **Certifications** | SOC 2 audit in preparation; GDPR compliant; CCPA compliant | | **Standard Data Retention** | 90 days | | **Custom Data Retention** | Yes — available on request | #### API Key Security Controls * API keys use format `mw_live__` (128-bit entropy secret) * Keys are stored as SHA-256 hashes — plaintext is shown once at creation and never retrievable * Maximum 5 API keys per account * Per-key `lastUsedAt` timestamp stamped on every authenticated request * Optional **IP restriction**: lock API keys to a single IPv4 address (`/32`) * Admin-enforced IP restriction available for enterprise accounts * Rate limits are per-key (not per-user): isolated quotas per integration * Key management endpoints require browser session JWT — an API key cannot create or revoke other API keys #### Authentication * All API requests require `Authorization: Bearer mw_live_...` header * Self-hosted WebAuthn passkey + ES256 JWT auth for dashboard/browser users * No third-party auth dependencies *** ### 11. Supported Currencies | Code | Currency | Country | Payment Methods | | ---- | ------------------- | ---------------------- | ------------------------------------------- | | AED | UAE Dirham | United Arab Emirates | Local bank account | | ARS | Argentine Peso | Argentina | Local bank account | | ALL | Albanian Lek | Albania | SWIFT | | AUD | Australian Dollar | Australia | Local bank account, BPAY | | BAM | Convertible Mark | Bosnia and Herzegovina | SWIFT | | BDT | Bangladeshi Taka | Bangladesh | Local bank account, bKash, E-Wallet | | BHD | Bahraini Dinar | Bahrain | SWIFT | | BMD | Bermudian Dollar | Bermuda | SWIFT | | BOB | Bolivian Boliviano | Bolivia | SWIFT | | BRL | Brazilian Real | Brazil | Local bank account, Brazil business | | BWP | Botswanan Pula | Botswana | SWIFT | | CAD | Canadian Dollar | Canada | Local bank account, Interac | | CHF | Swiss Franc | Switzerland | IBAN | | CLP | Chilean Peso | Chile | Local bank account | | CNY | Chinese Yuan | China | Alipay, WeChat Pay | | COP | Colombian Peso | Colombia | Local bank account | | CRC | Costa Rican Colon | Costa Rica | Local bank account | | CVE | Cape Verdean Escudo | Cape Verde | SWIFT | | CZK | Czech Koruna | Czech Republic | Local bank account, IBAN | | DKK | Danish Krone | Denmark | IBAN | | DOP | Dominican Peso | Dominican Republic | SWIFT | | EGP | Egyptian Pound | Egypt | IBAN | | EUR | Euro | Eurozone | IBAN (inside Europe), SWIFT (outside) | | GBP | British Pound | United Kingdom | Local bank account (sort code), IBAN, SWIFT | | GEL | Georgian Lari | Georgia | IBAN | | GHS | Ghanaian Cedi | Ghana | Local bank account | | GMD | Gambian Dalasi | Gambia | SWIFT | | GNF | Guinean Franc | Guinea | SWIFT | | GTQ | Guatemalan Quetzal | Guatemala | SWIFT | | HKD | Hong Kong Dollar | Hong Kong | FPS ID, Local bank account | | HNL | Honduran Lempira | Honduras | SWIFT | | HUF | Hungarian Forint | Hungary | Local bank account, IBAN | | IDR | Indonesian Rupiah | Indonesia | Local bank account, E-Wallet | | ILS | Israeli New Shekel | Israel | IBAN | | INR | Indian Rupee | India | Local bank account, UPI | | ISK | Icelandic Krona | Iceland | SWIFT | | JPY | Japanese Yen | Japan | Local bank account | | KES | Kenyan Shilling | Kenya | M-PESA, Local bank account | | KGS | Kyrgystani Som | Kyrgyzstan | SWIFT | | KHR | Cambodian Riel | Cambodia | SWIFT | | KRW | South Korean Won | South Korea | PayGate (personal), PayGate (business) | | KWD | Kuwaiti Dinar | Kuwait | SWIFT | | LAK | Laotian Kip | Laos | SWIFT | | LKR | Sri Lankan Rupee | Sri Lanka | Local bank account | | MAD | Moroccan Dirham | Morocco | Local bank account | | MNT | Mongolian Togrog | Mongolia | SWIFT | | MOP | Macanese Pataca | Macau | SWIFT | | MUR | Mauritian Rupee | Mauritius | SWIFT | | MXN | Mexican Peso | Mexico | CLABE | | MYR | Malaysian Ringgit | Malaysia | DuitNow, Local bank account | | NAD | Namibian Dollar | Namibia | SWIFT | | NGN | Nigerian Naira | Nigeria | Local bank account | | NIO | Nicaraguan Cordoba | Nicaragua | SWIFT | | NOK | Norwegian Krone | Norway | IBAN | | NPR | Nepalese Rupee | Nepal | Local bank account | | NZD | New Zealand Dollar | New Zealand | Local bank account | | OMR | Omani Rial | Oman | SWIFT | | PEN | Peruvian Sol | Peru | SWIFT | | PHP | Philippine Peso | Philippines | Local bank account | | PKR | Pakistani Rupee | Pakistan | IBAN | | PLN | Polish Zloty | Poland | Local bank account, IBAN | | PYG | Paraguayan Guarani | Paraguay | SWIFT | | QAR | Qatari Riyal | Qatar | SWIFT | | RON | Romanian Leu | Romania | IBAN | | RSD | Serbian Dinar | Serbia | SWIFT | | RWF | Rwandan Franc | Rwanda | SWIFT | | SAR | Saudi Riyal | Saudi Arabia | SWIFT | | SCR | Seychellois Rupee | Seychelles | SWIFT | | SEK | Swedish Krona | Sweden | IBAN | | SGD | Singapore Dollar | Singapore | Local bank account, PayNow | | SRD | Surinamese Dollar | Suriname | SWIFT | | THB | Thai Baht | Thailand | Local bank account | | TND | Tunisian Dinar | Tunisia | SWIFT | | TRY | Turkish Lira | Turkey | IBAN | | TZS | Tanzanian Shilling | Tanzania | Local bank account | | UAH | Ukrainian Hryvnia | Ukraine | IBAN, PrivatBank card | | UGX | Ugandan Shilling | Uganda | Local bank account | | USD | US Dollar | United States | ACH, Wire, SWIFT | | UYU | Uruguayan Peso | Uruguay | Local bank account | | VND | Vietnamese Dong | Vietnam | Local bank account | | ZAR | South African Rand | South Africa | Local bank account | *** ### 12. Current Client Examples We specialize in emerging markets across Africa, Southeast Asia, and South America. Current integrations include: * **Remote talent agencies in Kenya** — international payroll settled in KES via M-PESA and local bank accounts * **Renewable energy businesses in Nigeria** — cross-border supplier payments settled in NGN * **Software consulting agencies in India** — contractor payouts settled in INR via UPI and local bank accounts All clients use USDC as the settlement stablecoin for international transfers. *** ### 13. Support | Channel | Details | | --------------------- | ---------------------------------------------------------- | | **Email** | | | **Developer Support** | Dedicated Slack channel (provided at onboarding) | | **API Docs** | | | **Changelog** | | | **WhatsApp** | Available upon request at onboarding | *** *Last updated: 2026-03-29* # Contact Us
*** ## Partnership & Sales **Email**: For integration questions, onboarding, pricing, and enterprise agreements. *** ## Technical Support **Developer Slack**: Provided at onboarding — dedicated channel for your integration team **Interactive API Docs**: [developer.madhousewallet.com](https://developer.madhousewallet.com) **API Changelog**: [business.madhousewallet.com/developers/changelog](https://business.madhousewallet.com/developers/changelog) *** ## Security Disclosures Report security vulnerabilities via GitHub Security Advisories: [github.com/Madhouse-Wallet/wallet-frontend/security/advisories/new](https://github.com/Madhouse-Wallet/wallet-frontend/security/advisories/new) *** ## Social **Twitter/X**: [@madhousewallet](https://x.com/madhousewallet) **YouTube**: [@madhousewallet](https://www.youtube.com/@madhousewallet) **General Email**: