GLOBAL PAYMENTS KNOWLEDGEISO 20022 / SWIFT / SEPA / MT / MX

Articles / Learning brief

The real cost of payments

Your notes

What this means in plain language

Uses a hypothetical bank and transaction volumes to estimate the operating economics and potential profitability of domestic and cross-border payment services.

A payment service earns revenue from fees and foreign-exchange margins, but those figures are only the visible side of the economics. A bank also pays for scheme access, clearing, liquidity, correspondent services, fraud controls, compliance checks, technology, operations, investigations, and customer support. The useful question is therefore not simply how many payments are processed, but how much contribution remains after each direct and shared cost is assigned. A volume model helps teams compare products and see where automation or better routing could improve the result.

Understand the full idea, step by step

A payment receipt shows one fee. The payment itself consumed a dozen things that never appear on any receipt: a correspondent's charge, a slice of an FX spread, money parked in accounts so settlement never waits, the platform that processed it, and — for the unlucky few — an analyst's afternoon. What does a payment actually cost?

Where the cost of a payment arises

Fees
Explicit charges — the sending bank's fee, correspondent and scheme charges along the route
FX
The spread between the reference rate and the customer rate on any conversion
Liquidity
Money parked in nostro and settlement accounts so payments never wait for funding
Operations
The platform, screening, monitoring, and people that every payment consumes a share of
Exceptions
Repairs, investigations, and returns — rare per payment, expensive per case

The visible layer: fees and FX

Two of the five appear on Asha Traders' side of the deal, and the previous lesson measured them: Bank Alfa's transfer fee of EUR 15.00, and the FX spread worth EUR 216.34 against the reference rate. Under the SHA charge option a receiving-side deduction of USD 18.00 also came out of the amount — borne by the supplier, but still a cost of this payment. Everything the customer can see, in other words, can be added up from the quote and the charge option.

Bank Alfa's transfer fee (paid by Asha Traders)EUR 15.00
FX spread versus the reference rateEUR 216.34
Receiving-side deduction under SHAUSD 18.00
Deduction restated at the reference rate (18.00 ÷ 1.0800)EUR 16.67
All-in visible cost of this paymentEUR 248.01

This total takes the perspective of the deal as a whole — everything Asha Traders and its supplier together gave up compared with converting at the reference rate and paying no charges. It is an illustrative teaching total: real quotes shift with the market, and different routes carry different deductions. Notice what it excludes — every cost the bank absorbs to make the payment possible at all.

The hidden layer: liquidity, operations, exceptions

Bank Alfa keeps dollars sitting in its nostro account at Meridian Bank precisely so this payment could be funded on time — and idle money has a cost, because it could otherwise be earning elsewhere. The payment also consumed a slice of shared machinery: the processing platform, sanctions screening, fraud monitoring, reconciliation, and the staff behind them. Spread over millions of payments each slice is small, but it is never zero, and it must come from somewhere. Pricing that ignores the hidden layer looks generous right up until the product loses money.

You may be wondering: if the hidden costs are shared across millions of payments, why do they matter for any single one?

Because products differ in how much of the shared machinery they touch. A domestic transfer that validates cleanly and settles in a batch consumes almost nothing beyond its slice of the platform. A cross-border payment touches FX, correspondent accounts, heavier screening, and a much higher chance of manual work. Averaging everything together hides exactly the difference a pricing or routing decision needs to see — which is why Maya prices one payment at a time before averaging anything.

WHAT IF — A payment stops in the repair queue — a mistyped account number, an unclear beneficiary name, or a screening alert needing review

What happens: The payment still completes, but only after manual investigation. At an illustrative internal staff cost of EUR 30.00 per case, one exception can consume more than the fee income of dozens of clean payments.

How it is handled: Maya's team logs the reason code for every repair. Patterns matter more than cases: if one corridor or one customer's files keep needing repair, the economic fix is better validation at capture — preventing the exception — not faster handling of it.

COMMON CONFUSION

Our payment product handles enormous volume, so it must be profitable.

Volume multiplies whatever the per-payment economics are — including losses. A product earning EUR 1.00 per payment while consuming EUR 1.20 in platform share, liquidity, and exceptions loses more money the more it grows. Profitability is decided per payment and per product, by comparing all five cost sources against income; volume only scales the answer.

STRICTLY SPEAKING

Strictly speaking, every internal figure in this lesson — the EUR 30.00 exception cost, the platform slice, the liquidity charge — is illustrative. Real banks build unit-cost models with their own finance, treasury, and operations data, argue about how to allocate shared costs, and express uncertain inputs as ranges. The five cost sources are general; the numbers attached to them never are.

FOR NOW, REMEMBER

  • Payment costs arise in five places: fees, FX, liquidity, operations, and exceptions.
  • Fees and FX are visible to the customer and can be totalled from the quote — EUR 248.01 all-in for Asha Traders' illustrative payment.
  • Liquidity, operations, and exceptions are borne by the bank, shared across payments, and consumed unevenly by different products.
  • Volume never rescues bad per-payment economics; it only multiplies them.

TRY IT YOURSELF

Bank Alfa compares two products. Product A: fee EUR 1.00, fully automated, almost no manual work. Product B: fee EUR 12.00, but a meaningful share of its payments needs manual investigation at roughly EUR 30.00 per case, and it ties up correspondent liquidity. Which conclusion is soundest?

Product B is the profitable one — a EUR 12.00 fee is twelve times a EUR 1.00 fee.

Not this one — Income alone decides nothing. If enough of Product B's payments each burn EUR 30.00 of investigation time plus liquidity cost, the EUR 12.00 fee can be gone before the payment even completes.

Neither can be judged from fees alone; each product's income must be set against its own fees, FX, liquidity, operations, and exception costs per payment.

Correct — Exactly. The five cost sources land very differently on the two products — A consumes little beyond its platform slice, B consumes liquidity and manual work. Only a per-payment comparison of income against all five reveals which one actually earns its keep.

Product A must be loss-making, because no real payment can be delivered for EUR 1.00.

Not this one — A clean, automated domestic payment consumes very little: no FX, minimal liquidity, a tiny platform slice, and almost no exceptions. Low-fee products can be sound precisely because their all-in cost is genuinely low.

You have now seen both the visible and the hidden cost layers. The topic behind them goes deeper into charge options, conversion mechanics, and how quotes are built.

KEEP GOING

Three things to remember

  1. 01

    Payment volume alone does not show profitability.

  2. 02

    Costs span technology, operations, risk, liquidity, and networks.

  3. 03

    Unit economics reveal where improvement work matters most.

Where you would use this

USE CASE 01

A product manager compares the margin of domestic and cross-border transfer products.

USE CASE 02

An operations lead estimates savings from automating repair and investigation work.

USE CASE 03

A finance partner tests whether a proposed customer fee covers end-to-end delivery costs.

Put the idea into a real situation

Illustrative example: a bank processes 100,000 transfers and collects an average fee of $1.20, creating $120,000 in revenue. Network, processing, compliance, operations, and allocated platform costs total $95,000, leaving $25,000 before other overheads. If manual repairs affect 4% of transfers, the team can model whether better validation would lower that $95,000 cost base enough to justify an implementation project alone.

Evidence & review

REVIEWED 2026-07-13

General cost model for domestic and cross-border credit transfers; not specific to any scheme or jurisdiction

What this brief simplifies: All monetary figures are illustrative. Shared-cost allocation is reduced to a per-payment slice; real unit-cost models involve allocation debates, ranges, and institution-specific data. Liquidity cost is described qualitatively rather than priced.

Sources for this brief2
  1. Market practice

    Correspondent banking (final report)CPMI, Bank for International Settlements · Costs and frictions in correspondent banking

    Defines correspondent banking arrangements, including nostro/vostro account relationships, and analyses the decline in correspondent relationships and its drivers. · Checked 2026-07-12

    Published in July 2016; its statistics cover 2011-2015 and are dated, but the definitions and arrangement types remain widely used.

  2. Simplified educational illustration

    Payments Signal editorial teaching modelsPayments Signal · Five-cost-source model; all internal figures illustrative

    This site's own simplified teaching models. · Checked 2026-07-12

    Used wherever diagrams, scenarios, figures, or example values are didactic constructions rather than sourced facts; every such use carries a simplifications disclosure. All people, companies, banks, and list entries in examples are fictional.

Learn this properly

Related briefs

View Articles archive

CBPR+: ISO 20022 for cross-border payments

CBPR+ (Cross-Border Payments and Reporting Plus) is a set of usage guidelines that apply ISO 20022 to cross-border interbank payments over SWIFT, defining exactly how each message field is populated during and after the MT-to-MX transition.

READ BRIEF

Purpose codes in payments

Purpose codes and category-purpose codes are standard ISO 20022 external code lists that state why a payment is being made. They can influence routing, regulatory reporting, and screening, but a code is self-declared context, not proof.

READ BRIEF

High-value payments and HVPS+

High-value payment systems are usually central-bank real-time gross settlement systems that settle large payments individually and with finality. The HVPS+ (High Value Payments Plus) guidelines align how ISO 20022 messages are used across them, so a payment reads the same across borders.

READ BRIEF