Circle Payments Network (CPN)
Circle's institutional payment network — pre-negotiated terms, multi-currency, bank-grade compliance.
CTR (USD 10,000+)TRAVEL-RULE (USD 3,000+)ENHANCED-DUE-DILIGENCE (USD 50,000+)
Step 1 · Sender Bank (Arc)Policy-Enforced
The originating bank's treasury desk — the corporate client's wire instruction has been received and validated. The SWIFT MT103 equivalent, but on stablecoin rails.
Sender bank initiates a cross-border payment via Circle's Payments Network (CPN) — Circle's institutional settlement layer that positions itself as the stablecoin-native alternative to SWIFT gpi. L4 Account (the bank's custodial sub-ledger on Arc) and L5 Application (CPN dashboard or API integration) are lit, both policy-enforced. The bank's own regulatory authorization (BitLicense, state MTL, OCC charter, or EU CASP registration) is verified at path entry — CPN is a permissioned network, and only licensed institutions can participate. Builder: CPN integration is API-first — the sender bank calls POST /v1/payments with originator details, beneficiary details, amount, and destination chain. The CPN API returns a paymentId that tracks the transfer through all subsequent steps. The bank's API credentials are scoped to its CPN participant profile. Compliance officer: GENIUS §6 AML/BSA obligations attach at the institutional level — the sender bank runs its own BSA program, and CPN inherits that screening rather than duplicating it. However, Circle also runs its own screening (Step 2) as a belt-and-suspenders approach. C8 (operational resilience) is flagged because CPN is a critical payment infrastructure: if CPN is unavailable, the sender bank cannot initiate the transfer. This single-vendor dependency is a concentration risk that institutional compliance programs should document.
Step 2 · Sanctions ScreeningCode-Enforced
The compliance screening leg of a SWIFT MT103 — all parties are checked against sanctions lists before value moves. The difference: CPN screens both addresses and entities simultaneously.
Circle's compliance engine screens originator, beneficiary, and all intermediaries against OFAC SDN/SSI, EU consolidated (Council Regulation 269/2014), UK OFSI, and jurisdiction-specific sanctions lists. The path halts at L3 Execution until screening returns clear. Because CPN operates on permissioned Arc, the screening has access to entity-level metadata — not just address screening (as on public chains) but full name, jurisdiction, and license verification for both counterparties. C3 (counterparty due diligence) is flagged alongside C2 (sanctions) because CPN performs counterparty verification beyond sanctions: it confirms the receiver bank is a valid CPN participant with active regulatory authorization. Builder: screening is handled server-side by CPN — your integration does not need to call a sanctions oracle directly. The paymentId from Step 1 will transition to 'screening_complete' status when this gate passes, or 'screening_failed' with a reason code if it doesn't. Compliance officer: GENIUS §6(a)(1) requires screening 'before effectuating a transaction.' CPN satisfies this by making screening a blocking pre-condition — the CCTP burn (Step 4) cannot fire until screening returns clear. The dual-screening model (sender bank screens + Circle screens) creates redundancy but also raises a question: if the sender bank's screening clears but Circle's doesn't (or vice versa), which governs? CPN's terms make Circle's screening dispositive — Circle can block a transfer even if the sender bank's compliance program approved it.
Step 3 · Travel Rule HandoffPolicy-Enforced
The SWIFT MT103 field 50/59 enrichment — originator and beneficiary information is packaged for the counterparty institution. The Travel Rule is the stablecoin equivalent of the correspondent banking information chain.
Travel Rule information is transmitted to the receiving institution: originator name, account identifier, physical address; beneficiary name, account identifier. The data format is IVMS101 (interVASP Messaging Standard), transmitted via Notabene's Travel Rule protocol. This checkpoint fires for all transfers above the jurisdiction's threshold — USD $3,000 in the US (FinCEN §103.33), EUR €1,000 in the EU (TFR Article 14), or €0 for EU-to-non-EU transfers (TFR Article 15). L3 is lit, policy-enforced: the Travel Rule is a regulatory obligation, not a smart contract gate. The transfer could technically proceed without Travel Rule compliance, but doing so would violate GENIUS §6 and expose both institutions to enforcement action. Builder: CPN handles Travel Rule transmission internally for CPN-to-CPN transfers — the data is packaged from the payment instruction in Step 1 and transmitted to the receiver bank's CPN endpoint. For transfers to non-CPN institutions, Notabene's API is called directly. Compliance officer: the Travel Rule is the most operationally complex compliance obligation in cross-border stablecoin transfers. The 'sunrise problem' — where the originator institution is required to transmit but the beneficiary institution has no system to receive — is partially solved by CPN's closed network (both parties are CPN participants with compatible systems). GENIUS §6(b)(2) specifically requires Travel Rule compliance for payment stablecoin transfers; this is not optional for GENIUS-licensed issuers. Honesty marker: Travel Rule compliance for stablecoin transfers is still inconsistently enforced globally. Many jurisdictions have adopted FATF Recommendation 16 but have not built the infrastructure to receive IVMS101 messages.
Step 4 · CPN Bridge (Arc → Destination)Code-Enforced
The nostro/vostro transfer — value leaves the sender's ledger and the correspondent produces a credit advice for the receiver's chain. CPN is the correspondent; CCTP is the settlement mechanism.
CPN orchestrates a CCTP V2 burn on Arc: native USDC is burned at the TokenMessenger contract and a signed attestation is produced by Circle's attestation service. The bracket spans L3 Execution, L2 Consensus, L1 Network — entirely below the enforcement line, all code-enforced. CPN handles the attestation relay to the destination chain automatically — unlike raw CCTP where the caller must fetch and submit the attestation, CPN abstracts this into its settlement pipeline. C10 (technology and cybersecurity) is flagged because the bridge is the highest-risk step in the path: the attestation service is a centralized component, and its compromise or unavailability would halt all CPN cross-chain settlements. Builder: CPN handles the burn internally — your integration monitors the paymentId status, which transitions to 'bridge_initiated' and then 'bridge_complete' when the attestation is confirmed. You do not call CCTP contracts directly when using CPN. Compliance officer: the regime crossing (permissioned Arc → blockchain-native Ethereum) happens at this step. Value that was fully identified and screened on Arc will land on Ethereum where the compliance surface is wider and entity resolution is harder. GENIUS §8 (extraterritorial provisions) applies if the corridor crosses a US/non-US boundary. The CCTP attestation creates a cryptographic link between the Arc burn and the Ethereum mint, which satisfies the audit trail requirement of GENIUS §4(c). Honesty marker: CPN is in limited availability as of April 2026 — the participant set is small (initial bank partners only), and the supported corridor set is narrower than SWIFT's. Circle has announced CPN but has not published the full participant list or fee schedule.
Step 5 · Receiver Bank (Ethereum)Policy-EnforcedBlockchain-Native
The beneficiary's credit-to-account — the correspondent bank credits the client's account and the wire is complete. The MT199 confirmation, in stablecoin terms.
USDC is minted on Ethereum via CCTP and credited to the receiver bank's custodial account — typically an institutional vault (Fireblocks, Anchorage, or BitGo class) with multi-sig governance. L4 Account and L5 Application lit — the path ends in policy-enforced territory on the destination chain. The receiving bank applies its own jurisdiction's recordkeeping and tax-reporting obligations: in the US, BSA §5313 (CTR for >$10,000); in the EU, MiCA Article 76 (CASP record-keeping); in the UK, MLR 2017 Part 3 (record-keeping). Builder: CPN transitions the paymentId to 'settled' status when the Ethereum mint confirms. The receiver bank's integration receives a webhook with the settlement transaction hash, amount, and Travel Rule data package. Compliance officer: GENIUS §4(c) (books and records) and §4(b) (monthly attestation) obligations roll up from this settlement. The receiver bank must retain the Travel Rule data from Step 3 for a minimum of 5 years (BSA) or as required by its local jurisdiction. C12 (tax reporting) is flagged because the receiver bank may have withholding or information-reporting obligations depending on the beneficiary's tax status — 1099 series in the US, DAC8 in the EU. The end-to-end CPN corridor (instruction → screening → Travel Rule → bridge → settlement) targets sub-1-hour completion, compared to 1-3 days for SWIFT gpi on the same corridor. The compliance advantage over SWIFT is the cryptographic audit trail: every step from originator instruction to beneficiary credit is anchored either on-chain or in Circle's attestation log, with no 'black box' correspondent hops where visibility is lost.
Resolved 5 steps across 2 chain(s). 3 threshold(s) triggered. Frameworks: Bank Secrecy Act, GENIUS Act, OFAC Sanctions Program, FATF Recommendation 16 (Travel Rule), Common Reporting Standard / FATCA.
CPN Settlement Bridge
CPN orchestrates CCTP V2 burn/mint across Arc → Ethereum — the nostro/vostro transfer with cryptographic attestation linking source and destination.
Travel Rule Validator
Build FATF Rec 16 Travel Rule messages in IVMS101 format — the data package CPN transmits to the receiving institution before settlement fires.
CPN Sanctions Screening
Circle compliance engine screens originator, beneficiary, and intermediaries against OFAC SDN/SSI, EU consolidated, and jurisdiction-specific lists.