How Cross-Border Settlement Works

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. 1. 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

2. 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

3. 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”

4. 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

5. 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

6. 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

7. 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

8. 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

9. 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

10. 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

11. 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 1. 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.

2. 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

3. Bank-credit lag Elapsed time from payout initiation to beneficiary bank credit Segment by: * Bank * Currency * Country * Corridor * Transfer rail

4. 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.

5. Payout success rate Successfully credited merchant payouts ÷ eligible payout attempts × 100 Define “credited” using evidence stronger than provider instruction creation where possible.

6. 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

7. 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

8. 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

9. 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.

10. 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: 1. What event starts your settlement clock? 2. What event ends it? 3. Is that provider-balance availability or merchant-bank credit? 4. Which transactions are eligible for each settlement period? 5. What are the capture cutoffs? 6. Which calendars apply? 7. How are weekends handled? 8. How are holidays handled? 9. Is settlement gross or net? 10. Which fees are deducted? 11. How are refunds deducted? 12. How are chargebacks deducted? 13. Are reserves withheld? 14. How is reserve release reported? 15. Which settlement currencies are supported? 16. Can balances remain unconverted? 17. When does FX occur? 18. Who sets the FX rate? 19. Are explicit FX fees separate from the rate? 20. Which payout currencies are supported? 21. Which payout countries are supported? 22. Is a local bank account required? 23. Does payout cross a border? 24. Which banking rail is used? 25. Can correspondent banks be involved? 26. Who bears intermediary fees? 27. How are failed payouts returned? 28. How are payout retries handled? 29. Which IDs connect settlement reports to bank credits? 30. 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 ================

3. CLEARING Transaction data transmitted, reconciled, and potentially netted

4. NETWORK SETTLEMENT Issuer / acquirer obligations discharged under applicable network arrangements

5. ACQUIRER / PSP MERCHANT POSITION Merchant proceeds recognized under merchant/provider arrangement

6. PROVIDER BALANCE Pending / settled / available states (provider terminology varies)

| +---- 7A. Fees +---- 7B. Refunds +---- 7C. Chargebacks +---- 7D. Reserves +---- 7E. Adjustments

8. FX, IF REQUIRED Settlement currency | v Payout currency

9. MERCHANT PAYOUT INSTRUCTION

10. BANKING CHAIN

Provider bank | +--> Correspondent bank(s), if required | v Merchant bank

11. MERCHANT-ACCESSIBLE CASH

12. 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: 1. Which entity earns or controls the customer payment under the commercial model? 2. Which acquirer processes it? 3. Which currency does the customer pay? 4. In which currency does settlement occur? 5. Where does the provider hold or record merchant proceeds? 6. What is deducted before payout? 7. Where does FX occur? 8. Which bank account ultimately receives the funds? 9. Does that payout cross a border or use intermediary banks? 10. 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 1. Monday: the customer pays; Thursday: treasury has cash 2. Authorization is not settlement 3. Capture moves the transaction forward 4. Clearing calculates what participants owe 5. Network settlement discharges those obligations 6. The acquirer and PSP create the merchant's settlement position 7. Fees, refunds, chargebacks, and reserves change the amount 8. Currency may change before payout 9. Provider balance is not the same as bank cash 10. Cross-border payout can introduce banking intermediaries 11. Bank credit, value date, and actual usability 12. Reconciliation closes the chain 13. The Cross-Border Settlement Chain 14. Five realistic settlement configurations 15. Metrics merchants should monitor 16. Provider questions and testing 17. Final merchant recommendation SEO package Recommended SEO title How Cross-Border Settlement Works: From Payment to Merchant Funds Alternative titles 1. How International Payment Settlement Works 2. Cross-Border Merchant Settlement Explained 3. From Card Payment to Bank Account: How Settlement Works 4. Payment Clearing and Settlement for International Merchants 5. 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 Primary keyword

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.