MVP API (v0.1) — This is the MVP release of the OpenFX Platform API. It covers the core workflows for onboarding, accounts, FX, payments, collections, and webhooks. Additional capabilities (staged intents, compliance gates, inbound payments, settlement routes, and more) will be added in future releases. Pin to the current version in sandbox integrations and monitor the changelog for updates.

​
The problem OpenFX solves

The financial infrastructure landscape for fintechs and crypto companies is fundamentally broken:
  • De-banking crisis. 80%+ of crypto and fintech companies have been de-banked or denied banking access. Only 14% maintain stable banking relationships.
  • Pipeline leakage. Approximately 40% of qualified OpenFX prospects drop out of the sales pipeline because no single provider offers accounts, FX, and payment origination through one integration.
  • Fragmented vendor stacks. Customers stitch together 3-5 providers for accounts, FX, domestic payments, international payments, and crypto — each with different auth, webhooks, error models, and status semantics. Reconciliation across providers is a full-time job.
  • No local rail advantage. Cross-border payments default to SWIFT ($25-45 per wire, 2-5 business days). Customers want to convert USD to GBP and pay via Faster Payments (instant, under 1 GBP) instead. No single provider offers FX + local rail origination from one API.
OpenFX is the unified platform that replaces 3-5 vendor integrations with a single API for accounts, FX, payments, and crypto.

​
Welcome to OpenFX

OpenFX is a B2B financial infrastructure platform that provides programmatic access to foreign exchange, multi-currency banking, and cross-border payments. The Platform API is the internal orchestration layer that abstracts over multiple banking and crypto infrastructure providers into a unified, consistent interface. With the MVP API, you can:
  • Onboard entities and customers via orchestrated onboarding with KYB review
  • Hold multi-currency balances in fiat and crypto accounts
  • Convert between currencies using real-time FX quotes
  • Send payments globally across 5 payment rails (ACH, Fedwire, SWIFT, Crypto, OPEN)
  • Pull funds via ACH debit collections
  • React to events with signed webhooks and an events API

​
Who is it for?

The OpenFX platform serves fintechs and businesses that move money at scale:
Customer typeUse case
Crypto on/off-rampsHigh-velocity fiat-to-stablecoin conversion. Accept USD via ACH, convert, and settle USDC on-chain.
OTC desksLarge-block FX conversions and multi-currency treasury management.
Payment providers / MTLsCross-border payments on behalf of end customers. Originate SWIFT payments from a single API.
Payroll providersMulti-country payment distribution across supported rails.
Corporate treasuryMulti-currency balance management, internal transfers, and automated FX conversions.
Primary target customer: Payment service providers (PSPs) using stablecoins for global payments are the minimum viable customer archetype. They need a US bank account that can hold USD, accept deposits via ACH or Fedwire, and send payments — with a path to stablecoin conversion.

​
Platform architecture

The API is organized into four layers that build on each other. Every integration follows this progression from identity to money movement. 
  Layer 3: PAYMENTS
  Move money to counterparties across 5 rails.
  ─────────────────────────────────────────────
         |
  Layer 2: BANKING
  Unified accounts (fiat + crypto), balances,
  account numbers, blockchain addresses, transfers.
  ─────────────────────────────────────────────
         |
  Layer 1: FX ENGINE
  Real-time quotes, currency conversions,
  indicative rates, asset pair discovery.
  ─────────────────────────────────────────────
         |
  Layer 0: IDENTITY & ENTITIES
  Orchestrated onboarding, customers
  (program-scoped), KYB review.
  ─────────────────────────────────────────────
Each layer consumes the ones below it. A cross-border payment touches all four: establish identity (Layer 0), fund the account (Layer 2), convert currencies (Layer 1), and originate the payment (Layer 3).
Read the Platform Architecture guide for a detailed breakdown of each layer, the entity-customer separation model, and how a cross-border payment flows through the system.

​
Build philosophy

“Proximity creates velocity.” The closer funds sit to a trade, the more often that trade happens. Banking is not a product bolt-on — it is the mechanism that keeps money on-platform and turns episodic trading into continuous workflow.“The platform is the product.” OpenFX is built as if it is a platform provider — because it will offer its API to others to build on over the longer horizon. The abstraction allows swapping out providers under the hood without disruption.

​
The liquidity flywheel

The platform economics improve with scale through a self-reinforcing cycle:
  1. Operational accounts keep money on-platform — customers hold working capital instead of sweeping to external banks between trades
  2. Retained balances deepen liquidity — larger, steadier balances enable better internal netting and stronger liquidity posture
  3. Deeper liquidity produces tighter spreads — narrower spreads, higher fill reliability, and more predictable settlement
  4. Better execution attracts more volume — customers consolidate more flows into OpenFX, which feeds back into step 1
Without operational accounts, OpenFX remains a direct B2B FX service with linear growth. The Platform API is the foundation that makes this flywheel possible.

​
What can you build?

​
Cross-border payments with SWIFT delivery

Convert USD to GBP via the FX engine and deliver via SWIFT internationally.

​
Stablecoin on/off-ramp

Accept fiat deposits via ACH or Fedwire, convert to USDC using the FX engine, and send on-chain via the crypto rail. Reverse the flow for off-ramp.

​
Multi-currency treasury

Open accounts in USD, EUR, GBP, and SGD. Move funds between accounts with internal transfers. Convert between currencies on demand or lock rates with FX quotes.

​
Payment orchestration platform

Build a payment product on top of the OpenFX API. Onboard sub-customers, manage their accounts, and originate payments on their behalf across any supported rail.

​
Key conventions

Before you start building, here are the conventions used across every endpoint:
ConventionDetail
AuthenticationEd25519 asymmetric request signing. Three headers required: Authorization (Bearer token), X-Signature (Ed25519 signature), X-Timestamp (Unix timestamp).
IdempotencyAll state-changing endpoints require an Idempotency-Key header (UUID v4 recommended).
PaginationCursor-based with starting_after / ending_before query parameters.
MoneyExponent-based integer representation. Requests: { "currency": "USD", "value": "150000" }. Responses add exponent and displayValue.
Resource IDsTyped prefixes for debuggability: ent_, cus_, acc_, pmt_, etc.
Field namingcamelCase for JSON fields. kebab-case for URL paths.
Forward compatibilityClients MUST ignore unknown fields in responses. New fields may be added without a version bump.

Quickstart

End-to-end sandbox walkthrough: onboard a customer, open an account, and send your first payment.

Authentication

Set up Ed25519 request signing, manage API keys, and understand the three-header auth model.

Payments overview

Unified payment creation and the payment lifecycle.

Payment rails

Rail-specific endpoints for ACH, Fedwire, SWIFT, Crypto, and OPEN.

API Reference

Full reference for all 64 operations, request/response schemas, and error codes.

​
API at a glance

The MVP specification defines 64 operations organized into the following functional groups:
GroupOperationsDescription
Onboardings3Orchestrated onboarding flows
Customers2Read-only customer retrieval
Accounts12Unified fiat + crypto accounts, balances, account numbers, blockchain addresses
FX7Quotes, conversions, indicative rates, asset pair discovery
Counterparties6Counterparty and payment method creation and retrieval
Payments3Unified payment creation, listing, and retrieval
Rail-specific10Direct rail access for ACH, Fedwire, SWIFT, Crypto, OPEN
Collections5ACH debit pull payments
Transfers3Internal account-to-account transfers
Transactions2Read-only transaction ledger
Events1Event polling
Webhooks7Subscription management, testing, and secret rotation
Rails Discovery3Programmatic rail capability discovery

​
Next steps

  1. Follow the quickstart — Onboard a customer, open an account, and send your first payment in under 10 minutes.
  2. Learn authentication — Understand the three-header request signing model.
  3. Explore the API reference — Browse all 64 operations with request/response examples.