The Fiat Sandwich
A Plexo model for a payment route with fiat at each customer-facing end and a token between providers.
By Anton Titov, Founder · Plexo Institute
Plexo uses “fiat sandwich” to examine a possible payment route: fiat in, a token for an inter provider leg, and fiat out.
A fiat sandwich is one possible operating design: a provider can accept fiat, use a token for an inter-provider settlement leg, and make a fiat payout. It does not by itself establish a licence, a compliance sequence or a payment outcome.
Reading Guide
Plexo uses the label to make responsibility and evidence visible in one named route.
“Fiat sandwich” is Plexo terminology, not an official legal category. It describes an arrangement in which a sender and recipient can interact in fiat while a token may be used between providers. A real route can differ in its participants, assets, customer experience, timing, conversion steps and contingency process. The label should therefore start a diligence exercise, not end one.
| Conceptual leg | Question to establish | Evidence to inspect |
|---|---|---|
Funding | Who accepts funds from the sender and under what terms? | Customer agreement, account/funding record and applicable rulebook. |
Conversion | Who converts fiat and what asset is used? | Provider terms, token and chain record, conversion agreement. |
Inter-provider transfer | Who controls the token and when is the instruction treated as complete? | Wallet/control policy, transaction evidence and completion rule. |
Payout | Who owes the recipient and how is local value delivered? | Payout agreement, local-rail evidence and recipient terms. |
Exception handling | What happens if screening, conversion or payout fails? | Recovery, dispute and loss-allocation procedure. |
What a route must make explicit
Identify the legal counterparty at each customer-facing end, the party that controls each asset, and the party that owes the recipient. Do not infer that a customer has—or has not—token exposure from the route label alone. The relevant answer comes from the actual contracts, custody model and conversion process.
Name the token, chain, issuer/redemption path, conversion arrangement and source of liquidity. A token existing on two systems does not prove that a provider can fund, move, convert and pay out a specific corridor under its own operating conditions.
Separate technical confirmation from the moment a provider treats a payment as complete. A sound route specifies evidence of delivery, a failed-payout path, the holder of any interim exposure and the procedure for correction or return.
Compliance and legal boundary
FATF materials explain why originator and beneficiary information, counterparty assessment and risk controls can matter in relevant regulated activities. They do not prescribe one universal sequence for every token transfer. A provider may design pre-flight checks, screening, data exchange and exception handling, but the actual scope and order depend on its activity, counterparties, agreements and jurisdiction.
Likewise, the presence of fiat at the two customer-facing ends does not determine whether an activity is licensed, which authority supervises it or whether it is permitted. Those are questions for the named legal perimeter and current official rulebook in the relevant jurisdiction.
How to use the framework
Use the model to compare a real proposal with its documentary evidence. Ask who receives funds, who converts value, who controls the token, who is responsible for screening and data exchange, who makes the fiat payout, and who manages a failed leg. Then assess the named activity against the current rules of the relevant jurisdictions.
The framework does not rank rails, guarantee speed or cost, establish compliance, or certify a provider. It is a way to expose assumptions that otherwise remain hidden behind the phrase “fiat in, fiat out.”
Counter-Arguments & Limits
The model is intentionally narrow. It does not describe every stablecoin use, determine the customer experience in every payment product or settle a legal classification. A route may use a different asset, custody model or payout process; a regulator may apply a different activity perimeter. Those differences are reasons to inspect the underlying evidence, not exceptions that the label can erase.
About the Author
About This Explainer
Plexo developed this model as an operating and diligence lens. The primary sources above support the regulatory and cross-border-payment context, not a claim that the label is official, prevalent, permitted in every jurisdiction or appropriate for every route. This explainer is not legal, regulatory, financial, investment, tax or compliance advice.
Relevant Reading
What Is Correspondent Banking? — the legacy route this model can be compared against.
Travel Rule Explained — why relevant payment data does not travel in the token transfer itself.
Six Pathways — Plexo’s broader comparison lens for named settlement routes.