A Cross-Border Payment Is Not Finished Just Because One Rail Says Completed
Map a cross-border payment from instruction to usable recipient funds. Compare bank, fintech and stablecoin boundaries with an original reconciliation worksheet.
Educational analysis, not a personal investment or payment recommendation. Check the dated sources and the rules that apply in your jurisdiction.
A transfer interface displays a green confirmation. The recipient still cannot pay a supplier. Both observations can be true when the confirmation refers to an intermediate event rather than the recipient's usable balance.
This is a useful way to read the renewed debate about cross-border payment rails. A faster message, a confirmed token transfer, and an available local-currency deposit are different outcomes. Before comparing routes, identify which outcome the customer actually needs and which organization is responsible for delivering it.
On October 19, 2026, the BIS published Working Paper No 1385, Competing rails for crossborder payments: banks, fintechs, and stablecoins, by Wenxin Du, Catherine Huang, and David Scharfstein. It is the authors' research, not a BIS policy position or a recommendation of a provider.
Read the recent research without turning it into a league table
The paper compares bank, fintech money-transfer, and stablecoin routes using harmonized all-in cost measures. Its discussion highlights continued dependence on intermediaries, conversion, local liquidity, and access to fiat funds. A stablecoin transfer can therefore complete one leg while conversion or bank processing remains outstanding.
That finding motivates the original operational worksheet below. The worksheet does not reproduce the paper's empirical dataset, infer today's price for a corridor, or establish that one route is always preferable. Its narrower purpose is to make the completion boundary visible.
Write the recipient outcome first
Suppose a fictional business must deliver 10,000 units of a recipient's local currency by a specified time. The requirement is not “send a message” or “move an equivalent-value token.” It is that the recipient can use the agreed amount in the agreed form by the deadline.
If the parties instead agree to settle directly in a particular token, the required endpoint changes. That agreement must be explicit. The sender should not silently substitute an asset that requires the recipient to open an account, pass new checks, or arrange conversion.
Separate three kinds of completion
The CPMI glossary treats final settlement as a legally defined point involving an irrevocable and unconditional transfer or discharge under the relevant contract. A screen label alone does not establish that legal conclusion.
Operationally, maintain separate fields for an instruction accepted, an intermediate transfer completed, and the recipient's required funds available. The system may need evidence for all three, plus a documented interpretation of when the underlying obligation is discharged.
| Status | What it might establish | What still needs checking |
|---|---|---|
| Instruction accepted | A provider has received a request | Execution, rejection conditions and actual delivery |
| Intermediate asset delivered | One account or ledger leg completed | Conversion, release and destination availability |
| Recipient funds available | Agreed funds are usable at the endpoint | Amount, identity, timing and reconciliation |
These are original worksheet labels, not standardized provider statuses. Map each provider's actual terms into the worksheet rather than assuming similar words mean identical events.
Trace the boundaries for each proposed route
For a bank route, ask which institution can confirm the beneficiary credit and which reference connects that confirmation to the original instruction. For a fintech route, ask whether the customer's receipt is distinct from the provider's own rebalancing transactions. For a token route, ask who handles conversion and which account the recipient ultimately needs.
These questions do not imply that every route has the same architecture. The team should draw the actual arrangement being purchased. If the provider cannot describe a boundary, record it as unresolved instead of filling the diagram with a convenient assumption.
Reconcile a batch without counting the middle twice
Imagine an original, fictional batch of 100 payments. At the review time, 94 have reached the agreed endpoint, four have completed an intermediate asset transfer but await conversion, one is on hold before that transfer, and one has been rejected.
The endpoint completion rate is 94 divided by 100, or 94%. The intermediate-transfer population includes the 94 completed payments and the four awaiting conversion: 98 in total. Reporting those 98 as completed payments would overstate endpoint delivery by four percentage points.
| Mutually exclusive batch state | Payments | Included in endpoint completion? |
|---|---|---|
| Required recipient funds available | 94 | Yes |
| Intermediate transfer done; conversion pending | 4 | No |
| Held before intermediate transfer | 1 | No |
| Rejected | 1 | No |
| Total | 100 | Denominator only |
The figures are invented to explain reconciliation. They are not a failure-rate estimate for banks, fintechs, stablecoins, or the BIS paper's sample.
Keep responsibility attached to the outstanding leg
For each pending payment, record the next required event, the organization responsible, and the evidence needed to close it. “Waiting” is not a complete operational state. Waiting for a compliance decision, a conversion execution, and a destination-bank credit require different follow-up.
A useful exception record has an owner and a next review time. It also preserves the previous reference when a provider retries or reroutes the payment. Otherwise, a second instruction can be mistaken for a second obligation, or a retry can produce duplicate delivery without an obvious link to the first attempt.
Test a failure before choosing the route
Ask a prospective provider to walk through an unavailable conversion partner, a rejected beneficiary credit, and a mismatched recipient identifier. Which balance does the customer hold during each interruption? Who can return it, in what form, and under which terms?
Use a small, authorized test and inspect the evidence at the recipient endpoint. A demonstration of a fast intermediate transfer is useful, but it does not test the recovery path. Do not generalize a successful small transaction into evidence that a large batch will have the same available liquidity or operational treatment.
Compare promises at the same endpoint
The strongest comparison sheet begins with the required outcome and then records the route, expected completion evidence, exception owner, and applicable terms. Quotes should refer to the same amount, asset, destination, recipient access conditions, and deadline. Otherwise, an apparent speed advantage may come from measuring a shorter journey.
This article supplies an operational framework, not a legal opinion on a particular transfer or a recommendation to use a token. Read the total-cost guide for cross-border transfers for the pricing side. For a related infrastructure distinction, see why participant-default resilience does not eliminate business-loss risk.
Sources and reading notes
- BIS Working Paper No 1385 publication page, October 19, 2026.
- Full working paper, including architecture discussion and research limitations. Research results belong to the authors; they do not necessarily reflect BIS or member-central-bank views.
- CPMI glossary of payments and market infrastructure terminology. The batch states and examples in this article are original teaching tools, not official terminology.