Skip to main content

Architecture

CashXChain is built as a modular, API-first orchestration platform for modern payments. The architecture is shaped by the hardest cases — cross-border, multi-currency B2B — and applies to simpler payment workflows without modification.

The architecture separates customer experience, instruction checks, and regulated execution. This separation is central to CashXChain's security, scalability, and regulatory posture.

Architecture layers​

Plain text
Customer or Platform
        |
        v
CashXChain API and Dashboard
        |
        v
Instruction and Orchestration Layer
        |
        +--> Payout and conversion records, request logs
        +--> FX quotes
        +--> Accounts and beneficiaries
        +--> Verification, plan limits and payee-name checks
        +--> Webhooks
        |
        v
Regulated Partner Execution Layer
        |
        +--> Banking partner: accounts, payouts, FX, KYB review
        |
        v
Payment Rails and Networks

CashXChain responsibilities​

CashXChain is responsible for:

  • API and dashboard user experience.
  • Account and user permission model.
  • Instruction checks: ownership, verification, plan limits, the payee-name check.
  • FX quotes.
  • KYB intake and the onboarding pre-check.
  • Payout and conversion records, request logs.
  • Webhook delivery.
  • Statements and reconciliation views.
  • Integration tooling.

Partner responsibilities​

Regulated partners perform regulated activities where required, including:

  • Holding customer funds.
  • Business verification (KYB) review and approval.
  • Payment execution.
  • AML/CFT and sanctions screening.
  • Travel Rule obligations, where they apply.
  • Local payout processing.
  • Banking scheme participation.

Zero-custody design principle​

CashXChain does not hold customer funds or keys. It checks each instruction and sends it to our banking partner on the customer's behalf; the funds stay in partner-controlled accounts, where regulated execution takes place.

  • No customer private keys are held by CashXChain.
  • No customer funds are held by CashXChain.

Routing​

A payout leaves from the rail that holds its source account. CashXChain checks that the rail supports the currency and is reachable; if it is not, the payout is refused with 503 rather than sent another way.

Production payouts run on one rail today — our banking partner — over off-chain schemes: SEPA, SWIFT, Faster Payments, BACS, CHAPS, ACH, Fedwire, FedNow, EFT and Interac e-Transfer, and further domestic schemes depending on the corridor. No production payout uses a stablecoin yet. The sandbox adds a second rail, the digital-asset rail at our crypto-asset service provider, which holds the digital-asset accounts and sends from them; the same zero-custody rule applies — the provider holds the wallets, CashXChain sends instructions. See Rails.

Ledger-first accounting​

CashXChain records every payout, conversion and incoming credit it handles, with its status. For live accounts, balances and statement lines come from our banking partner's ledger; the sandbox keeps its own test ledger. These records do not replace partner records, bank statements, or legally required account records.

Environment separation​

Sandbox and production are separated by base URL, credentials, webhook endpoints, data, and operational controls. Never reuse production secrets in sandbox or sandbox secrets in production.