Cross-border payment settlement: where and when to convert

The payment was approved. The buyer paid over Pix, Brazil's instant payment rails, and the money is still not the ISV's cash. ISVs (Independent Software Vendors, software companies that sell their product to other companies) selling into Latin America know that interval well, and this piece is about the route that takes it off the vendor's calendar: selling through Nexforce's local infrastructure, the first of the company's two solutions for the international ISV, not the cloud marketplace route. The interval has a name: cross-border payment settlement, the stretch between payment confirmation and revenue available in treasury. On that route the buyer pays in local currency and the ISV is paid upfront, so the conversion question never reaches the vendor. The guide to cross-border payments for B2B SaaS covers payment friction up to approval. This one covers what comes after: three models, the risk in each, and the route where the decision leaves the ISV's desk.

What is cross-border payment settlement?

Cross-border payment settlement is the stretch between confirmation of the client's payment and the money available in the vendor's treasury account. Inside it happen the movement between accounts, the currency conversion, and the entry of the value into the vendor's country. It is a financial result variable, not a checkout parameter.

The interval looks technical. It is accounting. Each dollar inside it is revenue already invoiced that has not become cash, and what happens in that stretch decides how much of it arrives intact at the bank. Cross-border payment settlement moves six exposures at once, and none of them appears at checkout:

1. Foreign exchange risk. The rate stays open between transaction and settlement.
2. Liquidity. Working capital sits locked inside the interval.
3. Operational complexity. Reconciling different currencies consumes the finance team.

The first three show up in the month-end close. The next three, in the structure.

1. Regulatory exposure. Money moving between countries passes through regimes that vary by jurisdiction.
2. Control over the cash. Whoever decides when the money moves controls predictability.
3. Margin. Every conversion layer charges its own, and the sum appears in the price.

Why is settlement a treasury decision, not a payment decision?

Because settlement moves the invisible axis between invoiced revenue and cash received. The settlement decision belongs to treasury: it defines foreign exchange exposure, liquidity, and the moment the money moves. Most ISVs inherit the configuration from their payment provider and never treat it as a choice.

Charging ends when the buyer pays on the local rails, the half that B2B payment processing in Latin America covers. Settlement is the second. It is the journey of money already approved to treasury. Whoever does not ask three questions about that journey is operating a configuration someone else decided:

1. Which exchange rate is applied to the value?
2. When is it locked: at the transaction, at the payout, or at the final transfer?
3. Who controls the moment of conversion?

The Committee on Payments and Market Infrastructures (CPMI), at the Bank for International Settlements, gives the central risk of this stage its name: foreign exchange settlement risk, the danger of one side paying without the other delivering in the same instant. The standard antidote is payment versus payment (PvP), which conditions the two legs of the operation on each other. The CPMI final report on PvP, dated 27 March 2023, records that existing arrangements reduce this risk across most of the foreign exchange market, but that certain segments remain exposed, with coverage of emerging market currencies an open front. Most of the local currencies an ISV receives in Latin America sit in that set. Foreign exchange risk in international payments survives at the edge approval does not fix.

What are the three cross-border settlement models?

The market operates three generic architectures, with no owner and no brand: cross-border settlement with conversion at collection, local settlement with an owned entity, and conversion at transfer. The three names describe where the currency changes hands on the path between the client's payment and the ISV's treasury.

The three models are not products. They are architectures of the payments industry, and the choice happens at the ISV's desk, explicit or inherited. The whole difference lives in a question that rarely appears in the commercial proposal: at which point on the path between the client's payment and the ISV's treasury the currency is converted.

The table compares the three models against the criteria finance uses to decide:

Where conversion happens also decides the cost, the axis detailed in local currency payments and the cost of selling SaaS in Latin America.

Conversion at collection: when does cross-border settlement pay off?

Cross-border settlement with conversion at collection is worth it when the priority is speed of funds and simplicity. The ISV does not open a local entity, does not hold a balance in the country of sale, and receives in treasury already in hard currency. The price is giving up control over the moment of conversion.

It is the entry model. The provider that converts at collection fixes the exchange rate at the moment of the transaction and delivers the converted value to the vendor's account, in hard currency. Funds arrive fast and the cash lands in a single currency.

The trade-off has an owner: the timing of the conversion belongs to the provider, not the vendor. Between the buyer's transaction and the credit at treasury there is a window in which the rate is not the ISV's to choose, and the cost embedded in that conversion arrives inside the rate itself. The exchange is rational as long as there are no local expenses in the client's currency. Cross-border settlement with conversion at collection loses its reason to exist the day the operation starts spending in the currency it sells in.

Local settlement with an owned entity: why does capital get trapped?

In local settlement with an owned entity, the ISV collects and holds revenue in local currency, in the country's account, through an owned entity, and does not convert in the domestic cycle. The model serves operations with local expenses. The risk appears when revenue exceeds that need: trapped capital in local currency depends on a regulatory window to leave.

It is the model of installed operations. Settling payments in local currency is the model's point: collection happens on the rails the buyer already uses, such as Pix, SPEI and boleto, the local rails of Brazil and Mexico, and conversion only appears when revenue leaves the country. Approval improves when the buyer pays the way it already pays, and local cash serves local cash.

The problem is the asymmetry. Revenue grows faster than the local expense base, and the accumulated difference becomes trapped capital: revenue above what the operation consumes, with no immediate exit route. The route depends on each country's capital movement regime, and the restriction, when it exists, applies to money standing still. The model postpones foreign exchange risk; it does not remove it.

The regulatory layer is part of the design itself. The FSB final report on cross-border payment service providers, dated 12 December 2024, records that inconsistent approaches across jurisdictions for bank and non-bank providers create complex compliance and slower payments. An owned entity means accounting and compliance in the country of the revenue.

Conversion at transfer: control or complexity?

In conversion at transfer, local currency balances accumulate until treasury decides when to convert and when to transfer. It is the conversion of international receipts handed back to the ISV. The gain is timing chosen; the cost is the treasury maturity the timing demands.

It is the model for an international treasury that actually exists. The ISV holds a balance in the local account, chooses the conversion date against a hedge and liquidity policy, and transfers when the window favors it. Without an owned entity, the local account belongs to the billing infrastructure: the balance sits on a third party's books until conversion. Chosen timing smooths volatility: instead of accepting each day's rate, treasury protects the margin from unfavorable spikes.

The cost of currency conversion timing arrives before the finance does. It requires real-time balance visibility, a written conversion policy, and people to execute it. The unconverted balance stays exposed for longer, and exposure without a decision is risk without an owner. Conversion at transfer is the model of greatest control and greatest demand, and it coexists badly with one-person treasuries.

How do you choose the settlement model for your operation?

The choice crosses five variables: stage of the operation, local expenses, treasury maturity, risk appetite, and the physical presence each market demands. No universal settlement model exists. The expensive mistake is not choosing wrong; it is never having chosen and operating cross-border payment settlement by inheritance.

The first step is honest. Answer the five variables before looking at what providers offer. Stage defines speed of funds. Local expenses define whether it is worth holding cash in the client's currency. Risk appetite defines how much foreign exchange risk the operation accepts carrying between the buyer's payment and the arrival of the converted revenue in the treasury account. International treasury maturity defines whether timing is a gain or a burden. And the physical presence requirement varies by country.

With the answers on the table, the verdict is direct:

1. An operation entering now, without relevant local expenses and without a regional treasury: cross-border settlement with conversion at collection.
2. An installed operation, with payroll and suppliers paid in local currency, and revenue growing faster than the spend: local settlement with an owned entity and a formal repatriation policy.
3. A mature operation, with a treasury that executes a conversion policy and volume that justifies timing management: conversion at transfer.

The international ISV's map for selling SaaS in Latin America covers the entry channels; settlement is the variable the maps do not draw. This piece's position sits there: the three models serve; inheritance does not.

How does an ISV remove this decision with the Nexforce Marketplace?

Selling through Nexforce's local infrastructure, the decision of where and when to convert leaves the ISV's desk. The buyer pays in local currency, with Pix, boleto or card, in up to 12 installments, and the ISV is paid upfront. It carries no receivable, monitors no foreign exchange timing, opens no local entity.

This is the case where the question stops existing. On the Nexforce Marketplace, the ISV that wants to sell software in Latin America enters through Nexforce's local infrastructure, and its commercial process does not change: the operation works with its own contract standard and its own programs. No cloud commitment ties the transaction. And the cost account closes on both sides, two claims and not one: cheaper for the ISV and cheaper for the end client than the cloud marketplace route, which charges a fee per transaction.

Local currency covers all of Latin America, and the buyer pays with Pix, boleto or local card, in up to 12 installments, the way the region already buys. The reseller network puts the product where the ISV has no sales force of its own. The software alliance reaches what the ISV's own discount cannot reach: savings on the rest of the client's software spend make the purchase viable.

The upfront payment changes treasury. The ISV is paid upfront, the buyer pays in up to 12 installments, and the ISV carries no receivable and watches no foreign exchange window. At no cost to the ISV and with no minimum deal size, the route does not require a big case to be worth it. The interval this piece opened ends in two positions: the buyer paid in local currency and the ISV already paid.

Frequently asked questions about cross-border payment settlement

1. What is cross-border payment settlement?

It is the stage between confirmation of the client's payment and the money available in the vendor's treasury. Inside it happen the movement between accounts, the currency conversion, and the entry of the value into the vendor's country. It is a financial result variable.

2. What are the three cross-border settlement models?

Cross-border settlement with conversion at collection, local settlement with an owned entity, and conversion at transfer. None is a product. The names say where the currency changes hands on the way to treasury. The third is the only one in which the ISV's treasury chooses the conversion date.

3. When should revenue in local currency be converted into hard currency?

On the date the treasury policy defines, not the one the system chooses. Converting at collection solves simplicity and hands control to the provider, while holding a balance and converting at transfer returns the timing to the ISV and demands maturity to execute. The criteria are maturity and local expenses.

4. What are the risks of holding revenue in local currency in Latin America?

The central one is trapped capital: revenue above the local need that depends on a regulatory window to leave the country. Foreign exchange risk also stays open while the balance waits for conversion. Capital movement regimes that vary by jurisdiction come on top.

5. How does an international ISV get paid by clients in Latin America without opening a local entity?

Through Nexforce's local infrastructure, on the Nexforce Marketplace: the buyer pays in local currency, with Pix, boleto or card, in up to 12 installments, and the ISV is paid upfront. It opens no local entity, carries no receivable, and watches no foreign exchange window. The conversion decision leaves the ISV's desk.

References and Further Reading

Three primary sources support the claims in this piece, and each entry below carries its publication date so the claim can be checked at the source. That is the point of citing them.

• CPMI/BIS, the "Enhancement of cross-border payments" programme, G20 roadmap launched in 2020 and revised in 2023: Cross-border payments programme.
• CPMI, "Facilitating increased adoption of payment versus payment (PvP), final report" (27 March 2023): CPMI Papers.
• FSB, "Recommendations for regulating and supervising bank and non-bank payment service providers offering cross-border payment services, final report" (final report, 12 December 2024): FSB.

Where the decision stops being yours

An ISV that never chose a settlement model is operating an architecture the provider chose, with the exposure and the liquidity defined by that other party's choice. The three models in this piece exist so the choice stops being blind: cross-border settlement with conversion at collection for whoever is entering, local settlement with an owned entity for whoever installed, conversion at transfer for whoever has a treasury worth the name. There is also the exit that takes the decision off the table: selling through Nexforce's local infrastructure, getting paid upfront, and leaving local currency on the buyer's side. Cross-border payment settlement does not disappear. It changes owner.