How Cross-Border Settlement Works
On Monday morning, a customer in France buys a €100 digital product from an international merchant. The checkout says: Payment successful. The merchant's order system marks the purchase as paid. The customer receives the product. Finance does not see usable money in the merchant'
How Cross-Border Settlement Works: From Customer Payment to Merchant Funds
On Monday morning, a customer in France buys a €100 digital product from an international merchant.
The checkout says:
Payment successful.
The merchant's order system marks the purchase as paid.
The customer receives the product.
Finance does not see usable money in the merchant's bank account until Thursday.
When it arrives, it is not €100.
Perhaps the provider deducted processing fees.
Perhaps several Monday transactions were combined into one net settlement.
Perhaps a refund reduced the batch.
Perhaps part of the merchant's proceeds was placed in reserve.
Perhaps the merchant asked to receive USD, so EUR was converted before payout.
Perhaps the provider sent the resulting dollars through an international bank-transfer chain.
Nothing necessarily went wrong.
The confusion comes from treating customer payment success and merchant cash availability as the same financial state.
They are separated by a payment lifecycle.
For card payments, Mastercard publicly describes authorization, clearing, and settlement as distinct components of its switching services. The ECB defines clearing as the process of transmitting, reconciling and, where applicable, confirming and netting payment instructions prior to settlement. (Mastercard)
For merchants, the useful model extends beyond those interbank stages:
Authorization
→ capture
→ clearing
→ network settlement
→ acquirer/PSP settlement position
→ deductions and reserves
→ FX
→ payout
→ merchant-bank credit
→ reconciliation
Every arrow can introduce:
Time
Cost
Currency change
Liquidity requirements
Exception handling
Reporting differences
That is what cross-border merchant settlement actually consists of.
Monday, 10:03: the payment is authorized
The customer submits the card.
The merchant or PSP sends an authorization request through the acquiring side of the card network to the issuer.
The issuer evaluates the request and returns a response.
For our hypothetical purchase:
Approved: €100
This tells the merchant that the issuer has approved the transaction under the applicable authorization process.
It does not mean the €100 has already reached the merchant's bank.
Mastercard's card-processing description explicitly separates authorization from clearing and settlement, while Visa's rules distinguish authorization amounts from later clearing amounts and govern clearing and settlement in separate sections. (Mastercard)
What authorization answers
Operationally, authorization answers something like:
Will the issuer approve this payment request under the current transaction conditions?
It does not answer:
Has the merchant received the money?
Nor does it tell finance:
Which settlement batch will contain this transaction?
Merchant state
The merchant may record:
authorized
approved
payment_successful
depending on its system.
But those names should not be interpreted as bank-funding states unless the merchant's internal definitions explicitly say so.
Authorization versus settlement
This is the first essential distinction.
Authorization
Concerns approval of the transaction.
Typical participants:
Merchant
→ PSP/processor
→ acquirer
→ network
→ issuer
Settlement
Concerns discharge of the resulting financial obligations among relevant participants.
The BIS/CPMI glossary treats settlement as a distinct payment-infrastructure concept, while Visa and Mastercard maintain dedicated settlement processes and rules separate from authorization. (Bank for International Settlements)
Why merchants care
An authorization can be successful even though merchant funding occurs later.
That gap creates:
Working-capital exposure
Settlement receivables
Provider exposure
Reserve exposure
FX exposure
Reconciliation work
A merchant dashboard should therefore not use one undifferentiated status called paid for every financial purpose.
Monday, 10:05: the transaction is captured
Authorization and capture can occur close together in a straightforward ecommerce transaction, but they represent different functions.
Capture generally tells the payment system that the merchant intends to proceed with the financial transaction for the amount being submitted.
Some merchant models intentionally separate the two.
For example:
Hotel
Airline
Car rental
Marketplace
Pre-order merchant
Goods shipped later
may authorize before the final amount or fulfillment event is known.
Visa's current rules explicitly contemplate differences between authorization and clearing amounts under defined circumstances and maintain separate authorization and clearing requirements. (Visa)
Hypothetical simple transaction
Monday:
Authorization: €100
Capture: €100
The merchant now expects the transaction to proceed into clearing.
Hypothetical adjusted transaction
A travel merchant might instead have:
Initial authorization: €500
Final captured amount: €465
The amount ultimately entering the later financial stages can therefore differ from the original authorization under applicable transaction rules.
Capture is still not merchant funding
This distinction matters operationally.
A merchant can have:
Successful authorization
Successful capture
while still waiting for:
Clearing
Network settlement
PSP settlement
Payout
Bank credit
So a finance system should not interpret captured as:
Cash received.
The useful accounting connection is:
Captured transaction → expected settlement receivable
rather than:
Captured transaction → bank balance
The exact accounting treatment should be determined under the merchant's applicable accounting policies rather than inferred from payment-system terminology.
Monday night: transactions enter clearing
Clearing is where the payment system processes transaction information so that the obligations to be settled can be determined.
The ECB defines clearing as transmitting, reconciling and, in some systems, confirming transfer orders before settlement, potentially including netting and the calculation of final settlement positions. (European Central Bank)
Mastercard says its Global Clearing Management System is the clearing component of a broader architecture in which authorization, clearing, and settlement are separate functions. (Mastercard)
Clearing answers a different question
Authorization asks:
Should this transaction be approved?
Clearing helps determine:
What financial obligations arising from processed transactions need to be settled among the relevant participants?
That distinction explains why the original €100 authorization does not necessarily correspond to a €100 bank transfer from the issuer directly to the merchant.
Gross transaction amount versus settlement position
Imagine an acquirer processed these simplified transactions during a period:
Merchant A sales: €500,000
Merchant B sales: €250,000
Refunds and other adjustments: €20,000
The card network does not necessarily require a separate bank transfer corresponding to every individual customer purchase between every participant.
Payment systems may calculate net positions among participants.
Visa's VisaNet Settlement Service provides net settlement positions and reporting, and Mastercard's rules explicitly govern net settlement. (Visa)
That is why:
Customer transaction amount ≠ network settlement transfer amount ≠ merchant payout amount
Those numbers belong to different levels of the payment system.
Clearing versus settlement
These terms should not be used interchangeably.
Clearing
Determines, validates, reconciles and potentially nets obligations before settlement.
Settlement
Discharges the resulting obligations through the relevant settlement arrangements.
Mastercard's research on real-time payment systems states the distinction particularly clearly: clearing is the exchange of payment messages between banks, while settlement is the transfer of funds between banks arising from those payments. (Mastercard)
Merchant implication
When a provider says:
“The transaction has cleared,”
do not automatically interpret that as:
“The funds are in our bank.”
Ask which system state the provider means.
Tuesday: network settlement occurs
The next stage concerns financial settlement among network participants.
Visa's April 2026 rules describe national and international settlement services and define VisaNet Settlement Service as providing net settlement positions and settlement reporting to participating processors and members. (Visa)
Mastercard's June 2026 rules likewise address net settlement, settlement currency conversion, settlement messages, settlement instructions and participants' settlement obligations. (Mastercard)
This is an important control boundary.
The card network is settling obligations among its participating financial institutions.
That does not necessarily mean the individual merchant is simultaneously receiving a payout into its corporate bank account.
Network settlement versus merchant settlement
These two events are often collapsed into the word settlement.
They should not be.
Network settlement
Concerns obligations among:
Issuers
Acquirers
Other eligible network participants
under the applicable card-network settlement arrangements.
Merchant settlement
Concerns the acquirer or PSP determining the funds due to the merchant under the merchant agreement.
Those funds might be:
Gross
Net
Delayed
Partially reserved
Converted
Held as provider balance
Automatically paid out
The structure is provider- and contract-specific.
This distinction explains why network settlement can occur before the merchant sees funds.
What does the acquirer receive?
In a conventional four-party card structure, the acquirer sits on the merchant side of the card-network relationship.
Following clearing and network settlement, the acquirer's financial position reflects the transactions processed through the scheme, subject to the relevant network settlement rules.
The merchant's relationship with that acquirer or its PSP then determines when and how the merchant is funded.
Visa's rules even address reserves accumulated from merchant settlement funds, demonstrating that merchant-level funding can have additional controls after network transaction processing. (Visa)
That leads to another useful distinction:
Acquirer-side settlement does not automatically equal merchant cash availability.
Tuesday afternoon: the PSP calculates the merchant's position
Many international merchants do not receive individual card-network settlement directly.
They have a commercial relationship with:
PSP
Payment facilitator
Acquirer-processor
Merchant of Record
Another payment provider
The provider may maintain an internal financial ledger representing:
Captured transactions
Settled transactions
Refunds
Chargebacks
Processing fees
FX
reserves
Payouts
Adjustments
Exactly when a transaction becomes an available balance is provider- and contract-specific and must be verified rather than assumed.
A common conceptual progression
A provider ledger might distinguish:
Pending
→ processing
→ settled/available
→ scheduled for payout
→ paid out
Those are illustrative labels, not universal industry statuses.
A merchant should document the meaning of its provider's actual states.
Provider balance versus bank funds
This is one of the most important distinctions for finance and treasury.
Suppose the PSP dashboard shows:
Available balance: €480,000
That may mean the funds are available inside the provider relationship for eligible uses or payout.
It does not necessarily mean:
€480,000 is sitting in the merchant's own bank account.
The merchant should distinguish:
Provider ledger balance
A balance recorded under the PSP or acquirer arrangement.
Settlement balance
A provider-defined balance reflecting settlement activity.
Payout amount
The amount the provider instructs for delivery to the merchant.
Merchant bank balance
Funds credited to the merchant's own bank account.
Those states can occur at different times.
The merchant's €100 has now become part of a larger calculation
Imagine our Monday customer transaction sits inside this hypothetical settlement period:
Item
Amount
Gross captured sales
€1,000,000
Refunds
-€35,000
Chargeback adjustments
-€4,000
Processing and other contractually applicable fees
-€21,000
New reserve withheld
-€20,000
Reserve released from prior periods
+€5,000
Illustrative amount available before FX/payout
€925,000
These values are hypothetical.
The point is structural:
Settlement often operates on portfolios or batches of financial activity rather than treating the original €100 customer transaction as an isolated bank payout.
Gross settlement versus net settlement
Merchants should ask providers what they mean by gross and net.
Gross merchant funding
In a gross-funding arrangement, sales proceeds may be paid without deducting certain fees from the payout itself, with those charges collected separately.
Net merchant funding
In a net arrangement, deductions may be taken before the merchant receives the payout.
Potential deductions can include, depending on contract:
Processing fees
Acquiring charges
Network-related charges
Refunds
Chargebacks
reserves
Adjustments
FX fees
Payout charges
Do not assume that a provider advertising “T+X settlement” means the merchant receives the gross transaction total at that point.
Why a refund can reduce today's settlement for yesterday's sale
Refunds create an especially important timing issue.
Imagine:
Monday sales = $300,000
Tuesday new sales = $280,000
Tuesday refunds for earlier purchases = $40,000
Under a net-settlement model, Tuesday's merchant payout may reflect both:
New settlement inflows
Refund outflows
The provider may therefore pay an amount materially below Tuesday's gross sales.
The exact treatment depends on the provider contract.
Operational lesson
Finance should reconcile settlement against:
Sales
adjustments
− refunds
− chargebacks
− fees
− reserves
± FX adjustments
rather than comparing the bank deposit only to one day's sales total.
Reserves can separate settled revenue from available cash
Some acquiring arrangements maintain reserves to cover merchant payment obligations such as future chargebacks or other specified risks.
Visa's current rules explicitly contemplate reserves accumulated from merchant settlement funds in the acquiring context. (Visa)
A reserve can therefore create a state in which:
Customer paid
Transaction cleared
Network participants settled
Merchant settlement position was calculated
Portion of proceeds remains unavailable to merchant
Common reserve concepts
Depending on contract, providers may use:
Fixed reserve
Rolling reserve
Delayed availability
Risk hold
Minimum reserve
Those terms and calculations are provider-specific and should not be assumed from one provider's documentation.
Hypothetical reserve example
Merchant has:
$1,000,000 eligible settlement proceeds
Provider contract requires:
$100,000 maintained in reserve
Merchant currently has only:
$70,000 reserve balance
Provider may therefore retain another:
$30,000
before determining the current payout.
The underlying sale succeeded.
The merchant's cash availability changed because of the risk arrangement.
Reserve percentage
Where the provider uses a calculable percentage:
Reserve withheld during period
÷ eligible settlement proceeds during period
× 100
But merchants should also monitor:
Total reserve balance
Reserve release schedule
Reason for increases
Currency of reserve
Refund/chargeback usage
Whether the reserve earns no return
Whether reserve funds can be moved across provider entities or currencies
Do not infer one provider's reserve design from another's.
Currency can change after the customer pays
Now return to the French customer.
The customer paid:
€100
That does not tell us what currency the merchant ultimately receives.
The payment lifecycle can contain several currencies.
Presentment currency
What the customer sees and agrees to pay.
Example:
EUR
Transaction or authorization currency
Currency of the submitted transaction.
Often—but not necessarily identical to—the customer-facing price depending on the payment model.
Clearing currency
Currency used under the applicable clearing configuration.
Network settlement currency
Currency in which the relevant network participants settle under the scheme arrangement.
Visa's current rules explicitly distinguish local and international settlement services and recognize settlement-currency configurations. Mastercard's current rules separately address currency conversion within settlement. (Visa)
PSP balance currency
The currency in which the provider records funds for the merchant.
Payout currency
The currency sent to the merchant's bank.
Merchant functional currency
The currency used as the merchant's primary accounting currency under its applicable accounting framework.
These currencies may match.
They do not have to.
Hypothetical example: domestic-currency payment, cross-border merchant payout
Customer in Germany pays:
€100
Merchant is a U.S. company.
Provider processes and settles eligible payment activity through its European arrangements.
Merchant agreement says payouts are converted and delivered in USD to the merchant's U.S. bank.
One possible simplified flow is:
Customer: €100
↓
Card/acquiring settlement activity: EUR-related configuration
↓
PSP merchant balance: EUR
↓
PSP FX conversion
↓
Merchant payout: USD
↓
U.S. bank: USD
The customer experienced a euro payment.
The merchant experienced an international dollar payout.
The customer currency therefore did not determine the final merchant currency.
FX can occur at different points
Depending on the structure, conversion may occur:
Before acquiring settlement
During network settlement
Within the PSP
Immediately before payout
At the merchant's bank
Later at the merchant's treasury direction
The party performing the conversion may apply:
Reference market rate
Provider rate
Spread
Explicit fee
Bank conversion charge
Those components should be verified separately.
Effective FX cost
A useful metric is:
Reference-rate value − actual converted value after relevant conversion charges
÷ reference-rate value
× 100
The merchant must define:
Reference rate
Timestamp
Amount
Provider rate
Explicit fees
Bank charges included
before comparing providers.
Multi-currency provider balance example
Consider a merchant selling in:
United States: USD
Euro area: EUR
United Kingdom: GBP
Its PSP may support an arrangement in which eligible settlement activity accumulates in separate balances:
USD balance
EUR balance
GBP balance
The merchant might then:
Pay USD to a U.S. account
Retain EUR for refunds or European expenses
Convert GBP into USD
Consolidate balances periodically
That is a multi-currency settlement/balance problem, not simply a cross-border settlement problem.
The detailed mechanics belong in Multi-Currency Settlement Explained.
For this article, the lesson is:
A payment can finish network settlement while the merchant still has a treasury decision about whether and when the resulting currency should be paid out or converted.
Wednesday: the provider initiates merchant payout
At this point, the provider has determined the amount it intends to transfer to the merchant.
Suppose:
PSP balance after deductions: €925,000
Merchant requested:
USD payout to New York
Provider converts:
EUR → USD
and initiates the bank payment.
Now a new payment chain begins.
This merchant payout is not the original customer's card payment.
It is a separate funds transfer arising from the merchant's settlement relationship with its provider.
That distinction matters because the payout can have its own:
Payment rail
Bank cutoffs
Currency
Fees
Intermediaries
Compliance screening
Status
Failure modes
Cross-border card payment versus cross-border merchant payout
These phrases should not be used interchangeably.
Cross-border customer payment
Describes the customer-facing transaction when relevant merchant, issuer, acquiring, or network geography crosses jurisdictional boundaries under the applicable payment arrangement.
Cross-border merchant payout
Describes the later movement of provider/acquirer funds to a merchant beneficiary in another country.
A merchant can have:
Cross-border customer card payment + domestic merchant payout
Domestic customer card transaction + international merchant payout
Domestic acquiring + international payout
Cross-border acquiring + payout into a local-currency account
The architecture matters more than the label.
International settlement versus revenue repatriation
Another distinction matters here.
Suppose the PSP directly pays a U.S. merchant its European sales proceeds into a U.S. bank account.
That is a cross-border merchant settlement/payout arrangement.
Now suppose instead:
Merchant has a French subsidiary
French subsidiary receives EUR into its French bank
The group later transfers accumulated earnings from that subsidiary toward the U.S. parent through a legally appropriate corporate mechanism
That later movement can involve repatriation, depending on the legal and financial structure.
It is not simply the PSP settlement process.
Corporate transfers can have separate:
Tax treatment
Documentation
Corporate-law implications
FX requirements
Regulatory restrictions
Those issues belong in Repatriating Revenue From Foreign Markets and require specialist review.
Wednesday afternoon: the payout may enter correspondent banking
Not every international bank payment requires multiple correspondent banks.
But where the sending institution and beneficiary bank do not have the required direct relationship or access, correspondent banks can provide payment and account services across jurisdictions.
BIS explains that correspondent banking allows banks to access financial services in other jurisdictions and support cross-border payments. Its work notes that a cross-border payment can involve multiple intermediary correspondent banks depending on the relationships available. (Bank for International Settlements)
Simplified direct route
PSP's bank
→ merchant's bank
Simplified correspondent route
PSP's bank
→ correspondent bank
→ second correspondent or local clearing participant
→ merchant's bank
Not every corridor uses the same architecture.
Correspondent relationships can involve nostro and vostro accounts—accounts used by banks to hold and settle funds with one another. BIS describes their role in contemporary cross-border payment processing. (Bank for International Settlements)
Intermediary bank example
Hypothetical example
A provider initiates a USD payout from Bank A in Country X.
The merchant's beneficiary account is at Bank C in Country Y.
Bank A does not maintain the necessary direct USD correspondent relationship with Bank C.
The transfer moves:
Provider
→ Bank A
→ Correspondent Bank B
→ Bank C
→ Merchant account
Potential operational consequences can include:
Another processing step
Additional compliance screening
Additional cutoffs
Intermediary charges under the applicable payment arrangement
More complex payment tracing
The exact consequences depend on the banks and corridor.
Cross-border payments should therefore not be described as one standardized banking rail. BIS treats correspondent arrangements, linked systems, and other cross-border payment arrangements as distinct structures. (Bank for International Settlements)
SWIFT message does not itself mean money has reached the merchant
SWIFT is frequently misunderstood in settlement discussions.
SWIFT provides financial messaging infrastructure used by financial institutions to exchange cross-border payment instructions and related information. Correspondent banks can use those instructions to debit and credit the relevant bank accounts involved in the payment chain. (Swift)
A message being sent is therefore not the same state as:
Beneficiary account credited.
The merchant should distinguish:
Payment instruction sent
Intermediary processing
Beneficiary bank received
Beneficiary bank credited
Funds merchant can use
Settlement date versus value date
Payment and treasury teams should define their dates precisely.
The ECB defines value date as the date agreed for placing a payment or transfer at the receiving user's disposal. (European Central Bank)
Providers and banks may additionally display dates such as:
Transaction date
Capture date
Clearing date
Settlement date
Payout creation date
Bank processing date
Value date
Posting date
The labels can have product-specific meanings.
Do not measure settlement performance from vaguely named timestamps.
Thursday: the merchant's bank credits the account
At some point, the beneficiary bank processes the incoming payout and credits the merchant's account.
Now the merchant may finally have:
Bank-accessible funds
But even here finance has one task left.
It must establish:
What exactly does this deposit represent?
Perhaps the merchant sees:
USD 1,021,447.63
Its order system contains thousands of customer transactions.
Finance needs to bridge the two.
That is reconciliation.
Bank credit is not reconciliation
Money can reach the merchant's bank without finance knowing which activity produced it.
A good reconciliation chain connects:
Customer order
→ payment attempt
→ authorization
→ capture
→ provider transaction
→ clearing/settlement information
→ fees
→ refund/chargeback adjustments
→ reserve
→ FX
→ payout ID
→ bank credit
Without that mapping, the merchant technically has its money but lacks an auditable explanation for it.
The Cross-Border Settlement Chain
This is the core framework for the article.
Customer authorization
Financial question: Was the transaction approved?
Primary participants:
Merchant
PSP/processor
Acquirer
Network
Issuer
Merchant evidence:
Authorization response
Transaction ID
Amount
Currency
Main risk:
Treating approval as cash receipt
Capture
Financial question: What amount is being submitted to proceed into subsequent processing?
Merchant evidence:
Capture ID
Captured amount
Capture timestamp
Main risk:
Confusing captured revenue with bank funding
Clearing
Financial question: What obligations need to be reconciled and prepared for settlement?
Clearing can involve transmission, reconciliation, confirmation and netting before settlement. (European Central Bank)
Merchant evidence:
Provider/network settlement reports where exposed
Main risk:
Calling clearing “settled”
Network settlement
Financial question: How are the financial obligations among network participants discharged?
Visa operates net settlement services and Mastercard maintains net-settlement rules for its participants. (Visa)
Merchant evidence:
Usually indirect through:
Acquirer report
PSP settlement report
Main risk:
Assuming network settlement equals merchant payout
Acquirer-side funding and merchant settlement position
Financial question: What proceeds are attributable to the merchant under the acquiring relationship?
Possible influences:
Sales
Refunds
Chargebacks
Adjustments
Main risk:
Assuming gross transaction totals equal merchant receivable
PSP balance
Financial question: What amount has the provider recognized as available or pending for the merchant?
Possible states:
Pending
Settled
Available
Reserved
Payable
Terminology is provider-specific.
Main risk:
Treating provider balance as merchant bank cash
Deductions and reserves
Financial question: What amount remains payable after contractual adjustments?
Possible items:
Fees
Refunds
Chargebacks
reserves
Adjustments
Visa rules explicitly contemplate reserves derived from merchant settlement funds. (Visa)
Main risk:
Forecasting cash from gross sales
FX
Financial question: Does currency change before merchant payout?
Record:
Source currency
Target currency
Conversion amount
Reference rate
Provider/bank rate
FX spread
Explicit fee
Timestamp
Main risk:
Not knowing where conversion happened
Merchant payout
Financial question: What payment instruction is sent to the merchant beneficiary?
Record:
Payout ID
Amount
Currency
Beneficiary
Destination country
Bank details
Rail
Main risk:
Confusing payout initiation with beneficiary credit
Bank credit
Financial question: When can the merchant access the funds?
Possible variables:
Bank processing
Currency
Corridor
Correspondent banks
Cutoffs
holidays
Compliance review
Correspondent banking can involve several intermediaries where direct relationships are unavailable. (Bank for International Settlements)
Main risk:
Measuring provider performance only to payout creation
Reconciliation
Financial question: Can finance explain the bank credit from the underlying transaction records?
Required links can include:
Orders
Transactions
Fees
Refunds
disputes
reserves
FX
Payout
Bank entry
Main risk:
Cash received but financial records unmatched
Annotated settlement timeline
The actual timing varies materially by payment method, provider, country, currency, contract, bank, and operational calendar.
The following is therefore illustrative rather than a benchmark.
Time
Event
What merchant knows
What merchant does not yet know
Monday 10:03
Authorization approved
Issuer approved transaction
Merchant bank has not necessarily received funds
Monday 10:05
Captured
Amount submitted for subsequent processing
Final payout amount
Monday evening
Clearing
Transaction is incorporated into clearing activity
Merchant cash availability
Tuesday
Network/acquirer settlement activity
Financial obligations move through settlement process
PSP deductions/payout timing
Tuesday
PSP balance updated
Provider recognizes merchant proceeds under its model
Amount actually reaching bank after FX/payout
Tuesday/Wednesday
Fees/reserves/refunds applied
Net payable amount becomes clearer
Final banking deductions
Wednesday
FX applied if required
Payout currency determined
Beneficiary credit time
Wednesday
Payout initiated
Bank transfer instruction exists
Funds may not yet be credited
Thursday
Beneficiary bank credit
Merchant has bank-accessible funds
Reconciliation may still be incomplete
Thursday
Reconciliation
Finance links cash to transactions
Chain is operationally closed
The dates are hypothetical.
A provider advertising a particular settlement schedule should define precisely which two events that schedule measures.
Five settlement configurations merchants should recognize
Configuration 1: domestic currency, international payout
Hypothetical
French customer:
EUR payment
International merchant:
U.S. entity
Provider:
Supports EUR acquiring activity but merchant payout is USD to the United States.
Flow:
EUR customer payment
→ acquiring/clearing
→ provider EUR position
→ EUR/USD conversion
→ international USD payout
→ U.S. bank
Merchant implications
Customer sees EUR.
Merchant may incur provider FX.
Merchant receives USD.
Funds cross a border at payout.
Local-currency acceptance does not imply local merchant settlement.
Configuration 2: multi-currency provider balance
Hypothetical
Merchant collects:
EUR
GBP
USD
Provider allows qualifying proceeds to remain in corresponding merchant balances.
Merchant periodically:
Pays EUR to European operating account
Pays GBP to U.K. account
Pays USD to treasury
Merchant implications
FX may be deferred or avoided for operationally matched currencies.
Refund funding may come from the same currency balance.
Treasury now needs a currency-balance policy.
Provider balance remains different from bank cash.
Detailed treatment belongs in Multi-Currency Settlement Explained.
Configuration 3: payout through an intermediary bank
Hypothetical
Provider:
Country A
Merchant bank:
Country C
Currency:
USD
Provider bank lacks the direct required relationship with merchant bank.
Flow:
Provider bank
→ correspondent bank
→ merchant bank
Merchant implications
Potentially:
Additional payment-chain visibility required
Additional banking fees depending on arrangement
Additional exception points
More complex tracing
Correspondent banking commonly enables cross-border payments where banks need access to services in another jurisdiction. (Bank for International Settlements)
Configuration 4: reserve delays availability
Hypothetical
Merchant's settled activity before reserve adjustment:
$500,000
Required incremental reserve:
$25,000
Merchant payout basis:
$475,000 before other deductions
Merchant implications
The missing $25,000 is not necessarily:
Failed revenue
FX loss
Bank delay
It is:
Restricted merchant availability under the reserve arrangement
Finance should therefore maintain reserve as its own settlement category.
Configuration 5: refund reduces current settlement
Hypothetical
New settled sales:
€400,000
Refunds of older sales:
€45,000
Other contractual deductions:
€10,000
Illustrative current payable amount:
€345,000
Merchant implications
The bank credit cannot be reconciled simply against today's newly captured orders.
The settlement report must bridge the difference.
Who controls each stage?
Merchant
Usually controls or influences:
Capture timing
Provider selection
Bank accounts
Supported settlement preferences
Refund decisions
Treasury policy
Reconciliation
Currency-conversion decisions where provider functionality permits
The merchant generally does not control:
Issuer authorization logic
Network settlement mechanics
Intermediary-bank processing
PSP or payment provider
May control or influence:
Merchant ledger
Settlement schedule
Fees
reserve implementation
Supported settlement currencies
Payout schedule
Payout destination eligibility
Provider FX
Reporting
Retry of failed payouts
Exact responsibility is contractual.
Acquirer
May control or influence:
Merchant acquiring relationship
Clearing participation
Settlement configuration
Merchant funding
reserves
Chargeback debits
Settlement reporting
Visa and Mastercard rules place defined settlement obligations on acquiring/network participants, though the merchant-facing payout arrangement still depends on the commercial structure. (Visa)
Card network
Controls or governs, under its rules and infrastructure:
Transaction processing standards
Clearing
Participant settlement arrangements
Network reporting
Network obligations
Mastercard explicitly places authorization, clearing, and settlement within its switching-services architecture. (Mastercard)
Merchant bank
Controls or influences:
Account availability
Incoming transfer acceptance
Posting
Compliance review
Currency conversion where performed by bank
Beneficiary reporting
Correspondent bank
Where present, can provide:
Cross-border account access
Payment services
Interbank settlement chain connectivity
BIS describes correspondent banking as a mechanism through which banks obtain financial services in other jurisdictions. (Bank for International Settlements)
Settlement date is not enough
A provider dashboard may show:
Settlement date: Tuesday
Treasury observes:
Bank cash: Thursday
Which is correct?
Possibly both.
The system may contain separate dates for:
Network settlement
Provider settlement
Balance availability
Payout creation
Bank value date
Bank posting
The ECB defines value date specifically as the agreed date on which the payment or transfer is placed at the receiving user's disposal. (European Central Bank)
Therefore, merchant reporting should not say:
“Settlement takes three days”
without defining:
From which event to which event?
How to measure settlement properly
Settlement lag
Define the trigger first.
A merchant-facing version could be:
Elapsed time from captured transaction becoming eligible for provider settlement to funds becoming available in the merchant's provider balance
This is different from the formal payment-system concept of settlement lag used in financial-market infrastructure terminology. The merchant should label its internal metric accordingly.
Payout lag
Elapsed time from funds becoming payout-eligible in the provider balance
to payout instruction being submitted
This reveals:
Provider payout schedule
Batch effects
Minimum thresholds
holds
Bank-credit lag
Elapsed time from payout initiation
to beneficiary bank credit
Segment by:
Bank
Currency
Country
Corridor
Transfer rail
Cash-availability lag
Elapsed time from defined payment event
to merchant-accessible bank funds
The merchant must state the initial event.
For example:
Capture → accessible bank funds
or:
Provider-settled → accessible bank funds
Do not switch definitions between reports.
Payout success rate
Successfully credited merchant payouts
÷ eligible payout attempts
× 100
Define “credited” using evidence stronger than provider instruction creation where possible.
Failed payout rate
Payout attempts that fail before confirmed beneficiary credit
÷ eligible payout attempts
× 100
Segment by:
Bank
Country
Currency
failure reason
Beneficiary-account type
Effective FX cost
Reference-rate value − actual converted value after included FX charges
÷ reference-rate value
× 100
Document:
Reference source
Timestamp
Conversion amount
Actual rate
Explicit conversion charges
Deduction rate
Contractual settlement deductions during period
÷ gross eligible settlement proceeds during period
× 100
Do not combine unrelated deductions without preserving categories.
Segment:
Fees
Refunds
Chargebacks
reserves
Other adjustments
Reserve ratio
A useful merchant-specific metric can be:
Reserve balance
÷ defined eligible processing or settlement volume
But the denominator should match the contractual reserve definition.
Where the provider defines a specific reserve basis, use that instead.
Reconciliation-exception rate
Settlement, payout, fee, refund, or bank records requiring manual investigation
÷ settlement records reviewed
× 100
This is one of the most important operational settlement metrics.
A provider can pay quickly and still create poor finance operations if:
IDs do not match
Fee detail is missing
FX cannot be reconstructed
Refunds are aggregated without references
Payout reports do not match bank credits
Cash availability is the merchant's real endpoint
Payment teams often optimize:
Authorization rate.
Treasury optimizes:
Cash availability.
Finance optimizes:
Explainable cash availability.
Those are three layers of the same system.
A merchant should therefore distinguish:
Commercial success
Customer completed purchase.
Payment success
Payment instrument successfully reached the required transaction state.
Settlement success
Relevant financial obligations were settled under the payment/provider arrangement.
Payout success
Provider successfully delivered merchant funds.
Reconciliation success
Finance can explain those merchant funds from underlying transactions.
Only the final state closes the operational loop.
Why cross-border settlement can take longer
There is no universal cross-border settlement timeline.
Possible sources of elapsed time include:
Merchant capture schedule
Clearing windows
Network settlement schedule
Provider settlement schedule
reserves or holds
Currency conversion
Payout batching
Banking cutoffs
weekends
holidays
Correspondent banks
Compliance screening
Beneficiary-bank processing
BIS work on cross-border arrangements identifies PSPs, correspondent banks, and payment-system operators as distinct actors whose bilateral or multilateral arrangements influence payment service levels. (Bank for International Settlements)
That is why a generic claim such as:
“Cross-border settlement takes two days”
is not useful without defining:
Payment method
Provider
Countries
Currency
Start state
End state
Bank route
Calendar
“Instant settlement” needs the same discipline
A payment product can call itself instant while referring to a particular infrastructure stage.
For example:
Instant payment confirmation
Instant provider balance
Instant interbank settlement
Immediate payout instruction
Immediate beneficiary credit
Those are not synonymous.
Recent Mastercard announcements about expanded intraday and weekend settlement explicitly concern settlement flexibility for network participants, illustrating that the word settlement itself can refer to infrastructure-level events rather than an individual merchant's bank credit. (Mastercard)
Whenever a provider says instant settlement, ask:
Which balance becomes final or accessible, for which participant, on which rail?
What about weekends and holidays?
Each stage can have a different operating calendar.
A merchant may have:
24/7 checkout
24/7 authorization
Different clearing cutoffs
Network settlement schedules
Provider payout days
Bank business days
Currency-specific holidays
Mastercard's current reference material, for example, includes settlement holiday schedules, demonstrating that network settlement calendars are a distinct operational consideration. (Mastercard)
Merchants should maintain a settlement calendar by:
Currency
Provider
Acquirer
Bank
Payout rail
rather than using one corporate “business day” assumption.
The reconciliation model merchants should build
Each settlement should have an auditable bridge.
Transaction layer
Order ID
Payment ID
Authorization ID
Capture ID
Customer currency
Gross amount
Adjustment layer
Refund
Reversal
Chargeback
Fee
Reserve
Reserve release
Other adjustment
Currency layer
Original currency
Settlement currency
Converted amount
FX rate
FX fee/spread where available
Payout layer
Payout ID
Payout amount
Payout currency
Beneficiary
Payment rail
Payout date
Banking layer
Bank reference
Value date
Posted amount
Bank fee
Received currency
The reconciliation equation should ultimately explain:
**Opening provider balance
settlement inflows
− refunds
− disputes
− fees
± reserve movement
± adjustments
± FX/conversion effects
− payouts
= closing provider balance**
and separately:
Provider payouts
− bank/intermediary deductions where applicable
= identifiable merchant-bank receipts
The exact equation should reflect the provider's contractual reporting model.
What merchants should demand from settlement reporting
At minimum, reporting should allow the merchant to identify:
Transaction
Capture
Currency
Gross amount
Fee
Refund
Chargeback
Reserve
Net settlement
FX conversion
Payout
Bank reference where available
For multinational merchants, also preserve:
Merchant entity
MID
Acquirer
Provider
Customer country
Acquiring country
Settlement country
Bank country
Settlement currency
Payout currency
Without these dimensions, international treasury analysis becomes unnecessarily difficult.
Testing a settlement architecture before scaling it
A merchant should not discover settlement behavior only after its first million dollars of volume.
Run a controlled production or approved pre-production validation where feasible.
Test 1: normal transaction
Verify:
Authorization
→ capture
→ settlement
→ provider balance
→ payout
→ bank credit
→ reconciliation
Test 2: refund
Confirm:
Refund amount
Currency
Provider deduction
Which settlement period absorbs it
Customer-credit path
Merchant reconciliation
Test 3: FX
Use an approved transaction where currency conversion occurs.
Capture:
Original amount
Reference rate
Provider rate
Explicit fees
Payout amount
Test 4: payout failure
Where a safe test scenario can be arranged:
Invalid beneficiary or controlled failure
Provider failure status
Retry behavior
Returned funds
Fee handling
Reconciliation
Do not deliberately cause banking compliance issues merely to test failure handling.
Test 5: reserve
Where reserve applies, verify:
Calculation basis
Currency
Withholding
Release
Reporting
Test 6: cross-border bank route
Confirm:
Payout instruction
Beneficiary credit
Bank reference
Any intermediary deduction
Actual elapsed time
What would disprove the need for a more complex settlement structure?
Suppose treasury proposes:
“We need local settlement accounts in six countries.”
That should be a testable hypothesis.
Evidence against the change could include:
Existing international payout reaches the merchant within acceptable time
Effective FX cost is immaterial
Provider balance gives sufficient liquidity
Local expenses are low
Refunds do not require local funding
Bank fees are negligible
Reconciliation is simpler centrally
Local accounts add substantial compliance and operational work
The objective is not:
Maximize local settlement.
It is:
Design the simplest structure that gives the merchant acceptable liquidity, currency economics, control, and reconciliation.
The detailed local-versus-international comparison belongs in Local Settlement vs International Settlement.
Provider due-diligence questions
Do not ask only:
“How quickly do you settle?”
Ask:
What event starts your settlement clock?
What event ends it?
Is that provider-balance availability or merchant-bank credit?
Which transactions are eligible for each settlement period?
What are the capture cutoffs?
Which calendars apply?
How are weekends handled?
How are holidays handled?
Is settlement gross or net?
Which fees are deducted?
How are refunds deducted?
How are chargebacks deducted?
Are reserves withheld?
How is reserve release reported?
Which settlement currencies are supported?
Can balances remain unconverted?
When does FX occur?
Who sets the FX rate?
Are explicit FX fees separate from the rate?
Which payout currencies are supported?
Which payout countries are supported?
Is a local bank account required?
Does payout cross a border?
Which banking rail is used?
Can correspondent banks be involved?
Who bears intermediary fees?
How are failed payouts returned?
How are payout retries handled?
Which IDs connect settlement reports to bank credits?
Can reports expose entity, MID, acquirer, currency and payout information?
If the provider cannot define these states clearly, treasury cannot reliably forecast merchant cash.
Flow-of-funds diagram
CUSTOMER
|
| 1. Authorization request
v
ISSUER
|
| Authorization approval
v
CARD NETWORK
^
|
ACQUIRER / PROCESSOR
^
|
MERCHANT / PSP
|
| 2. Capture
v
================ TRANSACTION PROCESSING ================
CLEARING
Transaction data transmitted, reconciled,
and potentially netted
|
v
NETWORK SETTLEMENT
Issuer / acquirer obligations discharged
under applicable network arrangements
|
v
ACQUIRER / PSP MERCHANT POSITION
Merchant proceeds recognized under
merchant/provider arrangement
|
v
PROVIDER BALANCE
Pending / settled / available states
(provider terminology varies)
|
+---- 7A. Fees
+---- 7B. Refunds
+---- 7C. Chargebacks
+---- 7D. Reserves
+---- 7E. Adjustments
|
v
FX, IF REQUIRED
Settlement currency
|
v
Payout currency
|
v
MERCHANT PAYOUT INSTRUCTION
|
v
BANKING CHAIN
Provider bank
|
+--> Correspondent bank(s), if required
|
v
Merchant bank
|
v
MERCHANT-ACCESSIBLE CASH
|
v
RECONCILIATION
Order
→ payment
→ settlement
→ deductions
→ FX
→ payout
→ bank receipt
Core lesson
A successful payment closes the customer checkout. Reconciliation of accessible funds closes the merchant's financial lifecycle.
Settlement monitoring dashboard
A merchant settlement dashboard should contain at least five groups of indicators.
Liquidity
Cash-availability lag
Provider available balance
Outstanding payout balance
Reserve balance
Reliability
Payout success
Failed payout rate
Returned payout rate
Retry success
Currency
Settlement currency
Payout currency
Conversion volume
Effective FX cost
Economics
Gross settlement
Net settlement
Fees
Refund deductions
chargebacks
reserves
Bank fees
Finance operations
Reconciliation-exception rate
Unmatched payouts
Unmatched bank deposits
Missing fee detail
Missing FX detail
Required segmentation
Do not manage global settlement through one blended average.
Segment by:
Merchant entity
Customer country
Acquiring country
Provider
Acquirer
Payment method
Transaction currency
Settlement currency
Payout currency
Merchant bank
Beneficiary country
Corridor
Settlement schedule
Payout rail
Transaction value
Refund status
reserve status
This can reveal problems such as:
EUR payouts arrive normally while USD payouts into Bank B have a recurring extra-day delay.
or:
Provider X's authorization performance is excellent, but its settlement reports create three times as many reconciliation exceptions as Provider Y.
Those are actionable operational differences that a blended payment-conversion report would miss.
Settlement is a working-capital issue
Every additional day between sale and accessible cash increases the amount of revenue sitting somewhere between:
Customer account
Network
Acquirer
PSP
Bank
depending on the stage and model.
For a large merchant, that can affect:
Payroll funding
Inventory
Advertising
Supplier payments
Refund funding
Treasury borrowing
Liquidity forecasting
The important metric is not merely:
Average payout speed.
It is:
How much merchant cash is unavailable at each financial state, for how long, and why?
A useful, capability-neutral position is:
An international payment partner should be able to explain the full path from customer payment through acquiring, settlement, currency conversion, payout and reconciliation—not simply provide a checkout-success status and a payout date. Merchants should be able to identify where funds sit, which currency applies, what deductions occur, and which reports connect every payout to the underlying transactions.
Settlement models
Settlement frequencies
Supported settlement currencies
Supported payout currencies
Provider-balance functionality
FX process
Local settlement
International settlement
Bank-account requirements
reserve treatment
Reporting
Reconciliation
Marketplace payout capabilities
Final merchant recommendation
Cross-border settlement should be designed as a funds-control system, not treated as administrative cleanup after payment processing.
For every major payment route, build one documented chain:
Customer payment
→ authorization
→ capture
→ clearing
→ network settlement
→ acquirer/PSP merchant position
→ fees, refunds and reserves
→ FX
→ payout
→ merchant-bank credit
→ reconciliation
Then answer ten questions:
Which entity earns or controls the customer payment under the commercial model?
Which acquirer processes it?
Which currency does the customer pay?
In which currency does settlement occur?
Where does the provider hold or record merchant proceeds?
What is deducted before payout?
Where does FX occur?
Which bank account ultimately receives the funds?
Does that payout cross a border or use intermediary banks?
Can finance reconcile the bank credit to the underlying payments?
If any answer is unknown, the settlement architecture is not yet fully understood.
The correct operating principle is:
A merchant should not treat revenue as operationally complete when checkout says “paid.” It should treat the payment lifecycle as complete when the funds have reached the intended merchant-controlled destination in the expected currency and the amount can be reconciled to the underlying transactions, deductions, reserves, and conversions.
Original practical asset: Cross-Border Settlement Chain audit
This should accompany the published article as a worksheet.
Stage
Entity / participant
Country
Currency
Expected timing
Evidence
Financial owner
Exception path
Authorization
Issuer / acquirer / PSP
Authorization record
Payments
Capture
Merchant / PSP
Capture record
Payments
Clearing
Network/acquirer
Clearing report where available
Payments
Network settlement
Network participants
Acquirer/provider report
Payments/finance
Merchant settlement
Acquirer/PSP
Settlement report
Finance
Provider balance
PSP
Balance report
Treasury
Fees
PSP/acquirer/network
Fee report
Finance
Refunds
PSP/acquirer
Refund report
Finance
Chargebacks
Acquirer/PSP
Dispute report
Risk/finance
Reserve
PSP/acquirer
Reserve report
Treasury
FX
PSP/bank/other
Source → target
FX report
Treasury
Payout
PSP/acquirer
Payout ID
Treasury
Correspondent banking
Bank(s), if applicable
Bank trace
Treasury
Merchant bank credit
Beneficiary bank
Bank statement
Finance
Reconciliation
Merchant
Reporting currency
Reconciliation ledger
Finance
The asset creates a simple rule:
No stage should contain “provider handles this” without identifying the actual financial state, currency, evidence and owner.
Editorial-brief interpretation
This article should own one question in the Entity, Settlement & Cross-Border Funds cluster:
What actually happens to the money after the customer sees “payment successful”?
The central misconception is that authorization, clearing, settlement, merchant payout, and bank credit are simply different names for the same event.
They are not.
Official payment-system terminology distinguishes clearing—the transmission, reconciliation, and potentially netting of payment obligations—from settlement, when the resulting obligations are discharged. Mastercard likewise describes authorization, clearing, and settlement as separate core activities in its card-processing infrastructure. (European Central Bank)
For an international merchant, additional stages may exist after network settlement:
Acquirer accounting
PSP settlement
Reserves
Fees
Refund deductions
Currency conversion
Provider balances
International payout
Correspondent banking
Beneficiary-bank credit
Reconciliation
That makes the article's thesis:
Cross-border settlement is a chain of financial state transitions, not one bank transfer.
This interpretation follows the supplied article-specific brief.
Unique evidence anchor
Visa's current April 2026 rules separately govern clearing and settlement and describe VisaNet Settlement Service as providing net settlement positions and settlement reporting to participating processors and members. Mastercard's June 2026 rules likewise devote a separate chapter to net settlement, settlement currency conversion, and settlement instructions. (Visa)
Those network stages should not be confused with the later event in which a PSP or acquirer makes funds available to an individual merchant.
Editorial position
Merchants should monitor settlement as rigorously as authorization. A transaction is not operationally complete merely because the customer payment was approved; the merchant still needs to know when the amount becomes available, what was deducted, which currency survived the process, where the funds were paid, and whether finance can reconcile them.
Common assumption challenged
“Once the payment succeeds, the money is effectively ours.”
The merchant may have a successful authorization while the funds have not yet:
Entered clearing
Settled between network participants
Become available in the PSP's merchant ledger
Cleared a reserve policy
Been converted
Been paid out
Reached the merchant bank
Been reconciled
Merchant decision supported
The reader should be able to map any provider's settlement setup and answer:
From customer approval to usable cash, where is our money at each stage, in which currency, under whose control, and what can delay or reduce it?
Selected format
End-to-end flow-of-funds walkthrough
Structural rationale
Follow one hypothetical Monday payment chronologically until the merchant can actually use and reconcile the funds.
That approach keeps this article distinct from:
Multi-Currency Settlement Explained — which owns currency-balance mechanics
How to Choose Settlement Currencies — which owns the currency decision
Repatriating Revenue From Foreign Markets — which owns moving accumulated earnings through the corporate structure
Do You Need a Local Bank Account? — which owns account eligibility
Local Settlement vs International Settlement — which owns the comparative settlement-location decision
Proposed architecture
Monday: the customer pays; Thursday: treasury has cash
Authorization is not settlement
Capture moves the transaction forward
Clearing calculates what participants owe
Network settlement discharges those obligations
The acquirer and PSP create the merchant's settlement position
Fees, refunds, chargebacks, and reserves change the amount
Currency may change before payout
Provider balance is not the same as bank cash
Cross-border payout can introduce banking intermediaries
Bank credit, value date, and actual usability
Reconciliation closes the chain
The Cross-Border Settlement Chain
Five realistic settlement configurations
Metrics merchants should monitor
Provider questions and testing
Final merchant recommendation
SEO package
Recommended SEO title
How Cross-Border Settlement Works: From Payment to Merchant Funds
Alternative titles
How International Payment Settlement Works
Cross-Border Merchant Settlement Explained
From Card Payment to Bank Account: How Settlement Works
Payment Clearing and Settlement for International Merchants
How PSP Settlement and International Merchant Payouts Work
Recommended H1
How Cross-Border Settlement Works: From Customer Payment to Merchant Funds
Meta description
Learn how cross-border settlement moves from authorization and clearing through acquirer settlement, PSP balances, FX, reserves, payout, bank credit, and reconciliation.
URL slug
/how-cross-border-settlement-works
how cross-border settlement works
Secondary keywords
international payment settlement
cross border merchant settlement
PSP settlement process
payment clearing and settlement
international merchant payout
cross border funds flow
acquiring settlement
payment settlement timeline
Article excerpt
A successful customer payment does not mean the merchant has received its money. This guide follows a transaction through authorization, capture, clearing, network settlement, PSP balances, deductions, FX, international payout, bank credit, and reconciliation.
Related entities
Authorization
Capture
Clearing
Settlement
Net settlement
Acquirer
Issuer
PSP
Merchant settlement
Provider balance
Reserve
Rolling reserve
Settlement currency
Payout currency
Foreign exchange
Correspondent bank
Nostro account
Vostro account
Value date
Reconciliation
VisaNet Settlement Service
Mastercard settlement
Internal-link recommendations
Multi-Currency Settlement Explained
Best placement: immediately after the multi-currency balance example.
Suggested anchors:
how multi-currency settlement works
keeping settlement balances in multiple currencies
settlement currency versus payout currency
How to Choose Settlement Currencies
Best placement: after the FX section.
Suggested anchors:
choose the right settlement currencies
when to retain or convert a currency
Local Settlement vs International Settlement
Best placement: after the domestic-currency/international-payout example.
Suggested anchors:
local versus international settlement
where merchant settlement should occur
Repatriating Revenue From Foreign Markets
Best placement: after distinguishing PSP payout from corporate repatriation.
Suggested anchors:
repatriating foreign-market revenue
settlement versus revenue repatriation
Do You Need a Local Bank Account?
Best placement: after merchant-bank credit and payout destination.
Suggested anchors:
whether a local bank account is required
merchant settlement bank requirements
Cluster-entry context
Also link backward from this article to:
Do You Need a Local Entity to Accept Payments?
How to Accept Payments Without Local Incorporation
This creates the intended journey:
entity
→ banking
→ payment model
→ settlement
→ currency
→ repatriation
Authoritative source recommendations
For publication, prioritize:
BIS/CPMI payment-system glossary for clearing, settlement, settlement lag and related terminology. (Bank for International Settlements)
ECB payments glossary for clearing and value-date terminology. (European Central Bank)
Visa Core Rules and Visa Product and Service Rules, April 18, 2026, for authorization, clearing, settlement services, net positions and merchant-settlement reserve references. (Visa)
Mastercard Rules, June 2, 2026, for net settlement, settlement currency conversion and settlement obligations. (Mastercard)
Mastercard Switching Services for the authorization → clearing → settlement distinction. (Mastercard)
BIS correspondent-banking reports for international bank-chain mechanics. (Bank for International Settlements)
SWIFT for correspondent-bank messaging, ISO 20022 and cash-reporting architecture. (Swift)
Structured-data recommendation
Use:
Article
BreadcrumbList
A glossary-style structured element may be useful internally for the settlement terminology, but do not add FAQ structured data merely for SEO. The article is stronger with the settlement timeline and flow-of-funds asset than with a generic FAQ.
Supporting visual
“Payment Approved Monday. Cash Available Thursday.”
Create a horizontal timeline with two parallel rows.
Top row: payment-system state
Authorization
→ Capture
→ Clearing
→ Network settlement
Bottom row: merchant-money state
Expected receivable
→ PSP settlement position
→ Fees/refunds/reserve
→ FX
→ Payout
→ Bank credit
→ Reconciled cash
At every handoff show:
Participant
Currency
Status
Potential delay
Evidence/report
Highlighted distinction
Place a large marker beneath authorization:
CUSTOMER SEES “PAID” HERE
and another beneath bank credit/reconciliation:
MERCHANT HAS EXPLAINABLE CASH HERE
Caption
A successful payment and merchant-accessible cash are different states in the same financial chain.
Alt text
“Cross-border payment settlement timeline showing authorization, capture, clearing, network settlement, PSP balance, fees, reserves, FX conversion, international payout, merchant bank credit, and reconciliation.”
Proposed author and reviewers
These are recommended roles, not claims that review has occurred.
Author:
Required payments-operations reviewer:
Verify authorization, capture, clearing, network settlement, PSP settlement and payout terminology.
Required treasury reviewer:
Validate provider balance, settlement currency, FX, bank credit, liquidity and cash-availability framing.
Required reconciliation reviewer:
Validate settlement-report, payout and bank-reconciliation methodology.
Recommended banking reviewer:
Review correspondent banking, beneficiary credit and value-date terminology.
Recommended finance/accounting reviewer:
Ensure payment states are not inadvertently presented as accounting revenue-recognition rules.
Last reviewed:
Display a publication review date because network rules and provider settlement structures change.
Financial fact-check items
Before publication verify every claim involving:
Settlement frequency
Payout frequency
T+X claims
Gross versus net settlement
Processing fees
Network fees
Acquirer fees
Refund deduction timing
Chargeback timing
reserves
reserve release
FX
Payout charges
Intermediary charges
Bank charges
Working-capital impact
For any settlement-speed claim, document:
Start event → end event
For example:
Capture timestamp → provider balance available
rather than:
“T+2.”
Banking fact-check items
Verify by actual payout corridor:
Originating bank
Beneficiary bank
Payment rail
Currency
Direct relationship or correspondent chain
Intermediary involvement
Bank cutoffs
holidays
Value date
Beneficiary-credit evidence
Fee allocation
Failed-payment process
Returned-payment process
Required beneficiary data
Local bank-account requirements
Do not state that an intermediary bank is always used for international payouts.
Currency fact-check items
For each settlement configuration document:
Presentment currency
Authorization currency
Clearing currency where exposed
Network settlement currency where relevant
PSP ledger currency
FX source currency
FX target currency
FX rate
Explicit FX fee
Settlement currency
Payout currency
Merchant bank currency
Merchant functional currency
Refund currency
reserve currency
Do not infer settlement currency from customer currency.
Country-specific fact-check items
When a country is introduced, verify:
Applicable network settlement arrangements
Currency
Banking calendar
Local acquiring structure
PSP entity
Settlement country
Bank-account eligibility
Cross-border payout restrictions
Currency convertibility
FX-control requirements
Relevant payment regulation
Tax implications where settlement location is material
Effective dates
A country example should never imply that the same structure applies globally.
Regulatory, legal, tax, and treasury fact-check items
Settlement can intersect with:
Payment licensing
Safeguarding
reserves
Cross-border transfers
FX controls
Capital controls
Sanctions screening
Tax
Withholding
Marketplace funds
Merchant-of-record structures
Revenue repatriation
For every consequential claim identify:
Jurisdiction
Entity
Payment method
Currency
Funds owner
Provider
Bank
Applicable rule or contract
Effective date
This article provides general information and does not constitute legal, regulatory, tax, accounting, investment, or treasury advice. Merchants should confirm applicable obligations and financial arrangements with qualified advisers, banking partners, payment providers, and relevant authorities.
Amber-flag claims
Require specialist or primary-source verification before publishing statements that:
Payment settles in a defined number of days.
A network settles directly to a merchant.
A PSP balance is safeguarded in a specific way.
Provider balance represents final settlement.
A specific reserve percentage applies.
Refunds always offset the next payout.
FX always occurs at a specific stage.
A particular currency can be held without conversion.
International payout requires correspondent banking.
A correspondent bank charges a defined fee.
An international transfer arrives in a defined time.
A local bank account is required.
Settlement can occur cross-border in a named market.
Revenue can be freely repatriated.
Provider settlement is equivalent to legal ownership of funds.
“Instant settlement” means merchant-bank credit.
A specific value date guarantees immediately withdrawable funds.
A given PSP supports multi-currency balances.
Acquiring and settlement
Acquiring entities
Merchant-contracting entities
Local acquiring markets
Cross-border acquiring
Network-settlement relationships
Merchant settlement schedule
Gross versus net settlement
Balances
Available versus pending balance states
Balance currencies
Ability to retain currency
Currency-specific minimums
Reserve treatment
FX
Supported source currencies
Supported payout currencies
Conversion timing
Rate methodology
FX fees/spreads
Merchant-controlled conversion, if any
Payout
Supported payout countries
Supported banks/accounts
Local payouts
International payouts
Payout schedules
Payout status
Failed payout handling
Returned payouts
Correspondent-bank visibility
Finance operations
Settlement reports
Fee detail
Refund detail
Chargeback detail
Reserve reporting
FX reporting
Payout IDs
Bank references
Reconciliation exports or APIs
Broader capabilities
Multi-currency settlement
Local bank-account requirements
Marketplace payouts
Seller payouts
Revenue-repatriation support
Approved merchant outcomes
Do not claim any of these until verified.
Provider-specific verification requirements
For every PSP, acquirer, MoR, or settlement provider, document:
Contracting entity
Acquirer
Merchant entity
Network
Presentment currencies
Settlement currencies
Payout currencies
Payout countries
Provider-balance structure
Settlement schedule
Payout schedule
Gross/net treatment
Fees
refunds
disputes
reserve structure
FX conversion point
FX methodology
Bank-account requirements
Local/international payout
Correspondent-bank implications where known
Failed payouts
Returned funds
Reporting identifiers
Reconciliation capability
Effective contract version
Do not accept:
“We settle globally”
as a complete answer.
Cluster sameness-audit fields
Article: How Cross-Border Settlement Works
Cluster role: Movement-of-funds explanation.
Primary merchant decision: How to design and monitor the path from successful customer payment to merchant-accessible, reconciled funds.
Opening device: Monday payment approval contrasted with Thursday bank availability.
Unique evidence anchor: Authorization, clearing, settlement and merchant funding are separate financial states.
Editorial position: Settlement deserves the same operational discipline as authorization.
Common assumption challenged: “Once payment succeeds, the money is effectively ours.”
Writer influence: Ed Yong's interconnected systems explanation without stylistic imitation.
Primary format: Chronological end-to-end funds-flow walkthrough.
Structural logic: Authorization → capture → clearing → network settlement → merchant settlement position → PSP balance → deductions/reserves → FX → payout → bank credit → reconciliation.
Original framework: Cross-Border Settlement Chain.
Dominant supporting asset: “Payment Approved Monday. Cash Available Thursday.” annotated timeline.
Primary examples: Domestic-currency/cross-border payout; multi-currency provider balance; intermediary-bank payout; reserve hold; refund reducing net settlement.
Entity depth: Minimal; only identify the merchant entity receiving settlement.
Bank-account depth: Payout endpoint only; Article 2 owns eligibility.
Currency depth: Conversion location and effect only; Articles 4 and 5 own strategy.
Marketplace depth: Not central; Article 7 owns seller payouts.
Repatriation depth: Explicitly separated from ordinary PSP settlement; Article 8 owns it.
Primary metrics: Cash-availability lag, payout lag, payout success, effective FX cost, deduction rate, reserve balance and reconciliation-exception rate.
Control boundary: Network settlement, provider merchant ledger, payout banking and merchant reconciliation are separate layers.
Conclusion: The settlement lifecycle ends operationally when funds reach the intended merchant-controlled destination in the expected currency and finance can explain that cash from transaction through every deduction and conversion.
Need help narrowing down payment options?
Answer a few questions about your business and compare the capabilities that matter to you.
Explore matching options ↗