FPSF-CPP-001 — Governance
Layer: Governance · Audience: compliance officers, legal teams, regulators, risk managers For normative protocol requirements, see the Formal Specification.
1. Operator Eligibility
Any entity wishing to act as an Operator MUST:
- Be licensed and regulated in the jurisdiction(s) where it operates.
- Maintain KYC and AML compliance programmes applicable to its instrument type and jurisdiction.
- Be capable of locking and releasing funds with finality.
- Publish a Policy Document (see Section 4) before issuing any instruments.
This standard does not restrict which type of entity may be an Operator. Traditional banks, electronic money institutions, payment service providers, digital asset custodians, and other regulated entities are all eligible, subject to their local licensing requirements.
2. Amount Limits and Regulatory Alignment
The privacy properties of this protocol are strongest for intermediate bearers who are not identified. To remain compatible with anti-money laundering and counter-terrorist financing regulations in most jurisdictions, Operators MUST enforce a per-instrument maximum amount.
The appropriate limit is jurisdiction-specific. Common reference points:
| Jurisdiction | Reference Threshold |
|---|---|
| United States | USD 10,000 (Bank Secrecy Act cash transaction report threshold) |
| European Union | EUR 10,000 (4th/5th AMLD anonymous instrument threshold) |
| Brazil | BRL 10,000 (general cash transaction reference) |
| Others | Operators must determine the applicable threshold independently |
Setting the limit below the reporting threshold does not guarantee regulatory compliance. Operators remain responsible for their full AML programme, including transaction monitoring, velocity controls, and suspicious activity reporting.
3. Identity at the Edges
| Edge | Requirement |
|---|---|
| Issuance (Principal) | Must be a KYC-verified account holder. Identity recorded by Operator at issuance. |
| Intermediate bearers | Not required to be identified to the Operator. The protocol deliberately provides no mechanism for Operators to identify intermediate bearers. |
| Redemption (final bearer) | Must be identifiable to the Operator — either an existing account holder or a person completing KYC at redemption. |
This edge-KYC model is the foundation of the protocol's privacy architecture.
4. Operator Policy Document
Before issuing any cash-packs, an Operator MUST publish a Policy Document at:
https://{operator-domain}/.well-known/cashpack-policy.json
The Policy Document MUST include:
- Supported protocol version (e.g.,
CPP-1.0) - Maximum instrument amount per instrument
- Maximum instrument lifetime (RECOMMENDED: no more than 90 days)
- Maximum renewal chain depth (RECOMMENDED: no fewer than 20 hops)
- Velocity limits (maximum active instruments per Principal)
- Supported currencies
- Redemption identity requirements
- Operator signing public key (or reference to a JWKS endpoint)
5. Traceability
While intermediate bearers are not identified to the Operator, the protocol is not anonymous in the absolute sense. Social traceability exists: Alice received the instrument from Bob, who knows Alice's public key. John received it from Alice, who knows John's public key. The chain of custody mirrors the social trust network through which the instrument travels.
In a legal investigation, the Operator can produce the full renewal_chain — all public keys in order, with timestamps and signatures. Law enforcement may trace participants through subpoenas to communication providers, correlation with other transaction data, or voluntary disclosure.
The protocol provides practical privacy for ordinary transactions, not legally impenetrable anonymity. It is the digital equivalent of low-value physical cash — not an instrument for circumventing law enforcement.
6. Operator Risk Controls
| Control | Recommendation |
|---|---|
| Maximum instrument lifetime | No more than 90 days. |
| Maximum chain depth | At least 20 hops supported. |
| Velocity limits | Maximum simultaneously active instruments per Principal. |
| Aggregate exposure cap | Total value of all outstanding instruments, subject to capital management. |
| Cooling-off on redemption | Operators MAY impose a short delay on first-time redemption for AML monitoring. |
| Instrument freeze | Operators MUST have a mechanism to mark an instrument CANCELLED in response to a legal order, with funds held pending instruction. |
7. Regulatory Framing Guidance
Operators seeking regulatory approval or sandboxing for this instrument type are advised to frame it as follows:
"A standardized, operator-controlled, privacy-preserving payment instrument with delayed traceability, strict value limits, and full operator authority — designed as a digital analogue of low-value physical cash."
Operators should avoid framing that invokes cryptocurrency, virtual currency, decentralized money, or alternative monetary systems. The protocol is technically and legally closer to a prepaid instrument or cashier's cheque with bearer transferability than to any crypto asset.
8. Versioning Policy
This specification follows Semantic Versioning 2.0.0.
| Segment | Increment when... |
|---|---|
| MAJOR | Breaking change to data structures, cryptographic requirements, or protocol obligations. |
| MINOR | Backward-compatible additions (new optional fields, new use cases). |
| PATCH | Editorial corrections and non-normative clarifications. |
9. Changelog
| Version | Date | Summary |
|---|---|---|
| 1.0.0 | 2026-03-25 | Initial release. Adopts FPSF-CPD-001 v1.0.0. Defines all data structures, protocol obligations, API endpoints, and governance requirements. |
FPSF-CPP-001 v1.0.0 · Draft · Fabric Payment Standards Foundation · Apache-2.0