Path 04 · Banks & Financial Institutions
Fabric standards define how payment intent, authorisation, and settlement evidence are structured and exchanged — independently of any network operator. Compatible with existing core banking systems, ISO 20022 messaging, and current settlement infrastructure.
The structural problem
Settlement infrastructure — SWIFT, SEPA, RTGS, FPS — is well-developed in most corridors. The gap is not in the rails. It is in the lack of a standard, open model for expressing payment intent, capturing authorisation, and exchanging settlement evidence in a machine-verifiable way.
Without this, every institution implements its own bespoke interface. Every integration is bilateral. Every new corridor requires a new agreement. The cost of interoperability compounds with every participant added to the network.
The BIS and multiple central banks have identified this as one of the primary structural inefficiencies in the cross-border payment system. The G20 Roadmap for Enhancing Cross-Border Payments names common data standards as a core priority.
CPD-001 defines the minimal, implementation-agnostic model of a Payment — its entities, lifecycle states, and interfaces. A shared anchor for every institution to align against without changing internal systems.
Authorisation is expressed as a signed, machine-verifiable proof — not a credential token held by an intermediary. Settlement evidence is independently verifiable by any party with the public key.
Fabric operates as a messaging and structuring layer above settlement rails. It does not require changes to core banking systems, existing correspondent relationships, or current regulatory frameworks.
Every Fabric payment object carries a tamper-evident record of its complete lifecycle — from intent to settlement — available to authorised investigators and compliance functions without reliance on intermediary logs.
Capabilities
Depending on your institution's role and appetite, Fabric standards can be adopted incrementally — from a read-only alignment with the canonical payment model through to full Operator deployment.
CPD-001
Map your internal payment entities — instructions, authorisations, settlements — to the CPD-001 canonical model. This produces a shared vocabulary for integration with other Fabric-compliant institutions and creates a stable internal anchor for future improvements without requiring changes to your core system.
CPD-001 specification →CPP-001 · CashPack
Deploy a CashPack Operator and issue privacy-preserving bearer instruments against your existing customer balances. Use cases include corporate gift programmes, cross-border remittance corridors, tokenized deposit wrappers, and privacy-preserving structured settlement payments — all under your existing regulatory framework.
CashPack specification →SS-001 · Stablecoin Stack
Deploy the Stablecoin Stack as an Operator to issue stablecoin payment capabilities to your customers — or accept stablecoin payments from Fabric-compliant wallets. The acquiring model lets you earn a fee share on every payment originated by third-party distributors embedded in your ecosystem.
SS-001 Overview →API-as-a-Service
Operate as the regulated Operator behind third-party products. Fintechs, platforms, and retailers integrate your Operator endpoint and issue instruments under your regulatory umbrella. You earn the base fee on every transaction; they earn the acquiring commission. No proprietary lock-in for either party.
Business models →Architecture
Fabric standards are explicitly designed to sit above existing settlement infrastructure, not inside it. Adoption is additive — you layer Fabric-compliant interfaces on top of your existing systems.
The Foundation acknowledges the technical properties of distributed ledger systems but takes the position that regulated payment infrastructure requires auditability, legal accountability, and compliance frameworks that are difficult to achieve in fully decentralised systems. Fabric standards work across any settlement rail — including traditional interbank settlement — and do not require blockchain adoption. Where blockchain settlement is appropriate (for example, in the Stablecoin Stack), it is one option among several, not a requirement.
Every Fabric payment object carries a cryptographic chain of custody from intent through settlement. Nothing can be altered without invalidating the signatures.
Settlement evidence is independently verifiable by any party with the Operator's public key. No callback to a payment network, no trusted third party needed to confirm.
The complete lifecycle of every payment — from authorisation to settlement — is available in structured, machine-readable form for AML, KYC, and regulatory reporting without relying on intermediary logs.
Next steps
All FPSF specifications are publicly available and open under Apache 2.0. Start with CPD-001 for the canonical payment model, then review the spec most relevant to your intended deployment.
The Foundation welcomes institutional participation — as a reviewer of draft specifications, a working group member, or an early Operator deploying against a draft standard. All engagement is open and non-binding unless you choose to formalise it as membership.
Review the specifications, run the reference implementation, or reach out to discuss your institution's situation directly.