SWIFT gpi + Stablecoin Settlement
Traditional SWIFT messaging layer with stablecoin settlement replacing nostro/vostro accounts.
CTR (USD 10,000+)TRAVEL-RULE (USD 3,000+)ENHANCED-DUE-DILIGENCE (USD 50,000+)
Step 1 · Originating Bank — SWIFT MT103 / pacs.008Policy-EnforcedTradFi
The originating bank's treasury desk initiating a cross-border wire — payment instruction composed on the SWIFTNet messaging rail before any value moves, and the counterparty chain of correspondents identified.
The originating bank — a SWIFT member institution with an assigned BIC — composes an MT103 single-customer credit transfer, or increasingly an ISO 20022 pacs.008 message under the CBPR+ migration program. The bank's KYB/KYC posture is pre-established: the SWIFT BIC directory acts as a global institutional registry, and the originating-bank identity is inherited by every payment instruction that leaves the institution's SWIFTNet queue. L4 Account and L5 Application are lit, both above the enforcement line — the identity, authorization, and payment-composition steps sit in policy-enforced territory because they are executed by the bank's internal systems, not by public-chain validators. The regime tag is 'tradfi' because value has not yet crossed onto a blockchain; only an ISO 20022 message exists so far. Builder: the payment is originated through the bank's corporate payments API (e.g., the Swift SDK, Volante, Finastra GPP+, or in-house gpi-enabled cores), with the Stable402 Worker or equivalent middleware intercepting the instruction only after the gpi tracker confirms sanctions-screening has cleared. Compliance officer: GENIUS §6 AML/BSA obligations attach to the originating bank's customer identification program under 31 CFR §1010.220; the bank's MTL (or OCC charter, or comparable non-US license) is the load-bearing C5 Licensing anchor. For EU-bound corridors, MiCA Article 68 originator-information rules and the EU Transfer of Funds Regulation (TFR) both apply at this step. Honesty marker: SWIFT membership does not, by itself, satisfy the BSA — a bank's domestic charter does — and nothing in this step prevents the bank from originating an instruction whose on-chain leg ultimately fails downstream compliance; the originating step is the attachment point for accountability, not the gate.
Step 2 · SWIFT gpi Compliance Gateway — Sanctions + Travel RuleCode-EnforcedTradFi
SWIFT's Transaction Screening Utility (TSU) — every cross-border payment screened against OFAC, EU, UN, and HMT lists before it can leave the originating bank's queue, with the gpi tracker stamping a UETR for end-to-end visibility across the correspondent chain.
The SWIFT gpi Compliance Gateway runs the payment through SWIFT's Transaction Screening Utility (TSU) and the Payment Controls Service: OFAC SDN, EU consolidated list, UN 1267/1373, HMT UK, and bank-configured internal watchlists all fire in parallel. Behavioral AML pattern detection (velocity, structuring, layered round-tripping) runs against the bank's own historical corridor book. The gpi tracker assigns a UETR (Unique End-to-End Transaction Reference) — the deterministic 36-character ID that will later link this TradFi instruction to the downstream on-chain settlement transaction hash. For qualifying amounts ($3,000 US / €1,000 EU / any amount under Singapore MAS PS-N02), Travel Rule originator/beneficiary data is packaged via the SWIFT CBPR+ pacs.008 schema — CBPR+ is the industry's bank-to-bank Travel Rule plumbing and is the one place in this path where the on-chain and off-chain worlds share a wire-compatible format. L3 Execution and L4 Account are lit; the screening straddles the enforcement line because the code-enforced boolean 'SanctionsCheck: PASS' is the gate, but the bank's compliance officer retains discretion over borderline hits via the alert-queue workflow. Builder: SWIFT's Screening API returns a pass/fail verdict plus match details in <2s; banks layer their own policy engine on top to handle false-positive resolution. Wire the Chainalysis or TRM Labs on-chain sanctions oracle in parallel at this step if you want symmetric off-chain and on-chain screening before the nostro conversion fires. Compliance officer: this step satisfies GENIUS §6 (AML/BSA) screening obligations and §7 (Travel Rule / Interoperability) for qualifying cross-border amounts; for foreign-issuer stablecoins on the on-chain leg, §8 extraterritorial screening also attaches here because a Treasury-banned token in the settlement step would invalidate the payment retroactively. Honesty marker: CBPR+ is bank-to-bank only. It does not solve the Travel Rule sunrise problem for non-SWIFT counterparties (crypto-native VASPs, exchanges, non-custodial wallets), and no production on-chain parser converts CBPR+ pacs.008 Travel Rule bundles into IVMS101 — bridging remains a manual reconciliation task for the beneficiary bank's compliance desk.
Step 3 · Nostro Replacement — Fiat-to-Stablecoin ConversionCode-EnforcedBlockchain-Native
The nostro-account debit in traditional correspondent banking — but instead of debiting a pre-funded foreign-currency account at a correspondent bank (with all the trapped liquidity and FX fragmentation that entails), the bank debits its domestic deposit account and mints an equivalent amount of USDC via Circle Mint or acquires USDC in the wholesale liquidity market.
This is the regime crossing. The bank debits its domestic deposit account and either mints USDC via Circle Mint (requiring an institutional Circle Account and a signed originator attestation) or acquires USDC from a wholesale liquidity provider (Coinbase Prime, Kraken Institutional, a regulated OTC desk). Nostro/vostro pre-funding is eliminated — no foreign-currency float sits idle at a correspondent bank. Reserve-backing integrity (C6) attaches to the USDC in transit: Circle must maintain 1:1 USD / short-term Treasury reserves per GENIUS §4(a), and the monthly attestation under §4(b) must cover the float period. Operational resilience (C8) covers the bank's ability to reverse the mint if the downstream settlement fails before beneficiary credit — Circle's Mint/Redeem SLA (2 business-day redemption under GENIUS §5) is the outer bound. L3 Execution and L4 Account are lit; the conversion itself straddles the enforcement line because the mint is a code-enforced ERC-20 event on Ethereum but the fiat debit remains a policy-enforced bank ledger entry. The step carries a 'tradfi' regime tag because the governing record is still the bank's core-banking system; the Ethereum mint is the first artifact visible to a public-chain observer, and the `chainBoundaryAfter` marker crystallizes that the next step executes under a different regime. Builder: call Circle's Mint API with the SWIFT MT103 UETR as the idempotency key so the mint can be cleanly linked back to the originating gpi instruction and reconciled by the beneficiary bank's compliance desk. Store the UETR → on-chain-tx-hash pairing in a durable key-value store (R2 or S3 with WORM compliance add-on) as the anchoring artifact for C11 recordkeeping under GENIUS §9 custody rules. Compliance officer: this step is where the greatest prudential exposure concentrates — a failed mint, a frozen mint authorization, or a Circle attestation gap during the float period would all invalidate the payment from the originating bank's perspective while the SWIFT MT103 still reads 'SENT'. Banks piloting this path (Kinexys, Partior, Fnality) add a same-step reversal mechanic tied to the gpi tracker's 'Cancel' event. Honesty marker: Circle Mint access is institutional-gated and not yet widely available to non-US banks; correspondent-banking relationships with Circle-tier liquidity providers are a prerequisite; and the 2-day redemption window under §5 is a ceiling, not a typical latency — in pilots, end-to-end mint is ~30–60 seconds but the regulatory ceiling still defines the resilience envelope.
Step 4 · On-Chain Settlement — USDC Transfer on EthereumCode-EnforcedBlockchain-Native
The settlement leg of a Fedwire or CHIPS transfer — value moves irrevocably from the sending institution's account to the receiving institution's account inside the settlement window, with the authorizing message and the value movement finally collapsed into a single atomic event on a shared ledger.
USDC transfers on-chain from the originating bank's Ethereum settlement wallet to the beneficiary bank's wallet in a single ERC-20 transfer (or, for privacy-sensitive corridors, via Aztec's encrypted-balance scheme). The bracket spans L1 Network, L2 Consensus, and L3 Execution — every layer at or below the enforcement line fires. Strong settlement finality attaches at two Ethereum block confirmations for institutional amounts (~24 seconds), which is the operational threshold most wholesale pilots use. The SWIFT gpi tracker is updated in-line: the Stable402 or equivalent middleware writes the Ethereum tx hash back to the UETR record via SWIFT's gpi API so that the traditional gpi tracker UI shows both the MT103 flow AND the on-chain settlement tx in one timeline. Same compliance posture as the originating screening, faster settlement: finality in seconds vs. T+1 or T+2 on traditional correspondent rails. Builder: for cross-border corridors, pair this step with a Chainalysis OFAC oracle call against the beneficiary address before the transferFrom fires; for CCTP-based corridors (e.g., USDC on Arc minted for the originating leg), swap this step for a CCTP V2 burn+mint instead of a raw ERC-20 transfer. Compliance officer: GENIUS §6 re-anchors here because the code-enforced OFAC check against the destination address is the last guard before irrevocable transfer; §7 interoperability obligations are satisfied by the on-chain tx hash being written back to the SWIFT UETR (the regulatory-grade audit linkage); §4 reserve-backing continues to apply to the in-transit USDC. Honesty marker: Ethereum mainnet settlement latency is ~12s/block which is faster than any traditional RTGS but still 5–10x slower than bank-grade payment rails (Fedwire is sub-second for accepted instructions); for institutional pilots, Layer-2s (Base, Optimism) or alternative settlement chains (Arc, Kinexys Digital Payments, Fnality) are being evaluated to close the latency gap.
Step 5 · Beneficiary Bank — USDC Receipt + Local-Fiat ConversionPolicy-EnforcedBlockchain-Native
The beneficiary bank's credit-to-account event — the correspondent payment has arrived, the beneficiary bank runs its own inbound screening under its home-jurisdiction AML framework, and the end-customer credit fires once the bank's own books record the value.
The beneficiary bank's Ethereum wallet credits the USDC. Inbound screening is a fresh, independent pass: the bank runs its own sanctions check, its own AML pattern review against its corridor book, and — for EU beneficiaries — a fresh TFR/Travel Rule verification against the CBPR+ bundle that arrived with the pacs.008. Conversion to local fiat happens via Circle Redeem (if the bank holds a Circle Account) or via the bank's wholesale OTC relationship; for banks that want to hold the USDC as a stablecoin reserve, the step is a direct hold-to-ledger entry. L4 Account and L5 Application are lit on the receiving side, both above the enforcement line — the beneficiary bank's compliance posture is policy-enforced, not code-enforced, because the on-chain USDC is now a bank asset subject to the bank's own internal controls. Builder: wire the Chainalysis Address Screening API at the receive event so the bank's ledger never accepts a USDC credit from a sanctioned address (this is a belt-and-suspenders check against the upstream screening at Step 4). The bank's core-banking system writes the credit entry via the SWIFT gpi tracker 'CREDT' message, which the originating bank sees in near-real-time. Compliance officer: the beneficiary bank's home-jurisdiction AML framework (31 CFR §1010.410 in the US, MiCA + TFR in the EU, MAS Notice 626 in Singapore, JFSA PSA 2023 in Japan) applies fully — SWIFT screening at Step 2 does not absolve the beneficiary bank's independent BSA obligations. C11 recordkeeping anchors to the inbound tx hash + the UETR + the bank's own CIP record for the end-customer beneficiary. Honesty marker: very few non-US banks have Circle Redeem access as of April 2026; the more common pattern is for beneficiary banks to park the USDC and redeem in batches via wholesale OTC — which introduces FX timing risk that the path's 'atomic same-day settlement' pitch doesn't fully eliminate.
Step 6 · Settlement Finality & Reconciliation — UETR AnchoredPolicy-EnforcedBlockchain-Native
End-of-day correspondent-banking reconciliation — the nostro/vostro account balance tie-out that traditionally takes 24–72 hours and generates hundreds of breaks per corridor per month — completed in minutes because there is no nostro/vostro account to reconcile.
Settlement is final. The SWIFT gpi tracker shows end-to-end completion from originator instruction (Step 1) through sanctions clear (Step 2), mint (Step 3), on-chain transfer (Step 4), beneficiary credit (Step 5), to this finality event. Both banks hold matching settlement records: the SWIFT MT103 / pacs.008, the UETR, the Circle Mint tx hash, and the on-chain settlement tx hash — all linked by the UETR as the anchoring key. Traditional nostro/vostro reconciliation is eliminated because there are no nostro/vostro accounts: the bank holds USDC, not foreign-currency float at a correspondent. L5 Application is lit — finality sits in the policy layer because the regulatory record of settlement is the bank's own books, not the on-chain tx (the on-chain tx is evidentiary, not dispositive, under GENIUS §9 custody rules). Builder: for recordkeeping-grade archival, write the full UETR → mint-tx → settle-tx → CREDT bundle to R2 with a WORM-compliant retention policy; index by UETR for SAR lookup and examiner access. Compliance officer: C11 recordkeeping obligations under GENIUS §6 and §9 attach to this bundle with a 5-year retention floor (FinCEN), 7-year for EU, 10-year for some FATF jurisdictions — the storage layer must outlive the on-chain availability of the originating block. C12 audit/attestation obligations roll up the bundle into the bank's monthly BSA program review and the examiner's periodic on-site audit. Honesty marker: the end-to-end gpi + stablecoin settlement story is production-piloted by JPMorgan Kinexys, Partior, Fnality, and a handful of regional banks (DBS, HSBC, Santander) as of April 2026, but mass-market SWIFT-member adoption is not live — most banks still use traditional nostro/vostro correspondents for cross-border settlement, and the compliance architecture described here is the prototype more than the norm.
Resolved 6 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.
Travel Rule Validator · CBPR+ bridge
Build FATF Rec 16 Travel Rule messages in IVMS101 format. SWIFT CBPR+ pacs.008 carries the same originator/beneficiary bundle for the TradFi leg — use this tool to see how the CBPR+ schema maps to IVMS101 for the on-chain leg.
Chainalysis OFAC Oracle
The on-chain symmetric check that pairs with SWIFT TSU screening at Step 2 — screen the beneficiary address before the ERC-20 transferFrom fires so a sanctioned destination cannot accept the stablecoin settlement.