The Pre-SWIFT Moment

A public network can record a token transfer rapidly, but technical confirmation is not the whole payment process. A regulated participant may still need to identify a counterparty, apply its own policy, arrange liquidity, exchange required data, establish a completion rule and handle an exception.

The Travel Rule illustrates the operational context. FATF reported in June 2025 that 99 jurisdictions had passed or were in the process of passing Travel Rule legislation. That is a dated FATF observation, not a claim of uniform implementation or identical compliance outcomes.

Plexo’s analytical question is therefore practical: does a named route have the institutional context its participants require, in addition to a technically observable token transfer?

The useful comparison is not a neat sequence of 1975, 1995 and 2025. 1973: 239 banks from 15 countries formed Swift; 1977: Swift went live with 518 institutions in 22 countries. Its historical role was to standardize trusted messaging and coordination, not to move the underlying money. 1982: RFC 821 formalized SMTP as a way for independent systems to relay messages.

Plexo uses these examples as an analogy for a current design question. A stablecoin route can involve issuers, chains, custody providers, Travel Rule providers, banks and payment firms. Where independent participants need to work together, the route must make its coordination terms explicit. That is Plexo analysis, not evidence that every stablecoin market lacks one common protocol.

Plexo uses five questions to test whether a named token transfer could support a dependable cross-border payment route. They are an analytical checklist, not a claim that every market has the same gap or requires the same network.

Different participants may optimise for their own products, controls and customer relationships. That observation does not establish a universal coordination gap or a lack of interoperability in every arrangement. Plexo’s thesis is narrower: where a route relies on independent institutions and incompatible systems, its participants should make counterparty, policy, liquidity, data and completion terms explicit.

For four years I built a VASP in Europe. Each new remittance corridor meant finding another partner, agreeing an operating model, integrating an API and tuning an exception process. That experience is the practical origin of the “pre-SWIFT” analogy. It is an account of one operator’s coordination burden, not a universal network model.

Swift’s July 2026 announcement describes a bank-led shared-ledger initiative: bank payment commitments, tokenized deposits and final settlement through existing systems, with 17 banks preparing initial use. Plexo does not infer what the initiative will cover beyond that published boundary. A non-bank stablecoin route may face different counterparty, asset, payout and Travel Rule questions; it should document them on its own terms rather than position itself as a replacement for Swift.

Plexo’s design hypothesis is that a route can make its coordination terms more reusable without pretending that chains, issuers, fiat rails or compliance rules are identical. That hypothesis should be tested against named participant, corridor and rulebook evidence.

One possible control is a pre-flight check: a receiving participant can express the geographies, institutions, customer types, assets, limits and evidence it will consider. The route can then record whether the parties accepted, declined or need more information under their own procedures.

This is a design option, not a statement that every payment route can or should share one policy model. Participants do not need identical risk appetites; they need evidence for the operating decision they actually make.

The Pre-SWIFT Moment is Plexo’s analytical lens, not a promise that a new company or network will replace a global bank network. For a named route, the useful test is whether its participants can establish counterparty, data, policy, liquidity, completion and recovery terms with evidence.

A shared institutional layer may be one way to support such a route. It is not the only way, a regulator’s conclusion or a universal market requirement. The value of the lens is to make the design assumptions explicit before a participant makes a payment, integration or policy decision.

For the compliance mechanics behind this coordination model, continue with the Travel Rule explainer.