What Is Fintech & Transfers?
Fintech covers the technology-driven transformation of financial services — from digital wallets and neobanks to real-time payment rails, open banking APIs, and cross-border transfer infrastructure that moves trillions globally.
📂 Explore by Sub-Topic
Digital Payments
Contactless, wallets, QR codes, tokenization, card-present
Cross-Border Transfers
SWIFT, remittances, international money movement
Neobanks & Banking-as-a-Service
Digital banks, BaaS, embedded finance, challenger banks
Open Banking
APIs, data sharing, account-to-account payments
Payment Rails & Infrastructure
Real-time rails, ISO 20022, gateways, acquiring banks
Emerging Fintech
BNPL, biometrics, embedded payments, Stripe case study
Related Finance Sub-Topics
Latest Fintech & Transfers Articles
Recently published expert guides from the Fintech & Transfers hub.
Open Banking Payments: How Account-to-Account Transfers Are Replacing Cards
Open banking payments are the most commercially significant fintech development for merchants since contactless cards. Zero interchange, instant settlement, no chargebacks, and biometric authentication built into the bank app — the merchant cost savings are material. For CFOs managing high-volume payment operations, understanding open banking payment economics and where they are viable is now essential. This guide covers how payment initiation works, who the major providers are, and how the business case stacks up against cards.
How Does a PSD2 Payment Initiation Work?
The open banking payment flow under PSD2 has five steps. First, the consumer selects 'Pay by Bank' at merchant checkout and chooses their bank. Second, the PISP (e.g., TrueLayer) sends an authorization request to the bank's open banking API. Third, the consumer is redirected to their bank app or web portal for biometric or OTP authentication — this is the Strong Customer Authentication (SCA) step, which is legally required for PSD2 payment initiation. Fourth, the bank confirms authorization to the PISP and initiates the payment — typically through SEPA Instant for instant settlement or standard SEPA Credit Transfer for next-day. Fifth, the merchant receives confirmation and can release goods or services immediately.
The entire flow takes 15–30 seconds for the consumer. The key UX challenge is the bank redirect — consumers unfamiliar with open banking may be confused or distrustful of leaving the merchant's checkout. Conversion rates improve significantly when merchants brand the experience clearly (e.g., 'Pay directly with your [Bank Name] account') rather than using generic 'Pay by Bank' labels. First-time open banking payment conversion is typically 70–80%; repeat-use conversion with saved bank preferences reaches 90%+.
| Dimension | Open Banking (A2A) | Card Payment |
|---|---|---|
| Route | Direct bank-to-bank | Via card networks |
| Merchant cost | Typically lower | Interchange + fees |
| Settlement | Often real-time | Batched, slower |
| Chargebacks | Limited | Established process |
| Auth | Bank app approval | Card + 3-D Secure |
What Is the Business Case for Merchants Accepting Open Banking Payments?
The merchant business case is strongest for high-value, B2B, and recurring payment use cases. For a business invoicing corporate customers for €5,000–50,000, open banking payment initiation costs €0.20–0.30 per transaction (PISP fee) versus €15–150 for a card payment at 0.3% interchange. The annual saving on 1,000 such invoices is €15,000–150,000. For recurring B2C payments (subscriptions, utility bills), open banking request-to-pay combines instant settlement with built-in SCA, eliminating card-on-file PCI obligations.
For standard e-commerce, the case is more nuanced. Consumer adoption of 'Pay by Bank' varies significantly — it is high in the Netherlands (via iDEAL, which processed over 1 billion transactions in 2023), growing in the UK and Germany, and nascent in Southern Europe. Merchants should offer open banking as a payment option alongside cards rather than replacing them, and track open banking adoption rates by customer segment.
How Does Open Banking Work in Turkey?
Turkey introduced open banking rules through the Payment Services Law (Law No. 6493) and subsequent BDDK regulations. The Central Bank of Turkey (CBRT) mandated that banks provide open banking APIs to licensed payment service providers from 2020 onward. Turkey's FAST instant payment system (launched 2020, similar to SEPA Instant) provides the settlement rail for open banking payment initiation in TRY.
Turkish banks including Garanti BBVA, İş Bankası, Yapı Kredi, and Akbank have implemented PSD2-equivalent open banking APIs. Licensed Turkish PSPs (fintech companies holding BDDK payment service licenses) can act as PISPs and initiate payments from customer bank accounts. The ecosystem is growing but less mature than the EU — consumer awareness of 'open banking payment' as a concept remains low, though bank app-based QR payments (using similar infrastructure) have achieved strong adoption via FAST.
What Are the Limitations of Open Banking Payments?
Open banking payments have three structural limitations that prevent them from immediately replacing cards. First, coverage: open banking APIs exist only for banks in PSD2-regulated markets. Non-EU, non-UK markets have no equivalent regulatory mandate — payments in North America, Asia, and Africa cannot use open banking initiation without analogous local frameworks. Second, no consumer protection equivalent to chargebacks: open banking payments are push payments with finality. Consumers who are defrauded or who pay for goods that are not delivered have no chargeback mechanism — only civil recourse. Third, user experience fragmentation: the bank redirect experience varies widely across banks. Some banks have excellent, fast mobile app authentication; others have slow or unreliable API connections that cause payment failures.
These limitations explain why open banking payments complement rather than replace cards for most use cases. The combination of open banking for B2B and high-value B2C plus cards for lower-value consumer payments and international customers is currently the optimal hybrid strategy for most multi-channel businesses. For the full picture of how payment methods fit together, see our payment infrastructure overview and the Digital Payments hub.
What Are the Major Open Banking Payment Providers in Europe?
The European open banking payment infrastructure layer has consolidated around a handful of specialist providers. TrueLayer (UK/EU) is the largest independent open banking payment provider, covering 12+ European markets with high API reliability SLAs. Banked specializes in UK open banking with a focus on e-commerce checkout. Token.io provides enterprise-grade open banking connectivity to banks in 20+ European markets. Yapily offers API coverage across 2,000+ EU and UK banks. Major payment platforms have also integrated open banking: Stripe Link can use open banking for bank account verification and payment in supported markets; Adyen's open banking payment method covers EU and UK.
Selection criteria for merchants: API coverage in your target markets, reliability and uptime SLAs (critical — a payment failure at checkout is a lost sale), settlement speed (SEPA Instant vs next-day SEPA CT), refund initiation capability, and integration complexity. For enterprise merchants, evaluate whether open banking payment data can feed into existing ERP reconciliation workflows with the same level of automation as card payment data. Our payment infrastructure overview covers how open banking fits the broader payment stack.
How Does Open Banking Payment Initiation Interact with Accounting and Reconciliation?
Open banking payments generate a different data model than card payments for accounts receivable reconciliation. Card payments arrive as net settlements (gross minus interchange/fees) batched by acquirer. Open banking payments arrive as gross amounts directly from the payer's bank, with PISP fees charged separately (often as a monthly invoice rather than per-transaction deduction). This means bank statement reconciliation must handle both gross-amount open banking credits and PISP monthly fee invoices, rather than the standard net settlement model from card acquirers.
For ERP integration, open banking payment confirmations include structured reference data (the payment reference you pass to the PISP appears in the bank statement credit). With ISO 20022 SEPA Instant transactions carrying full structured remittance data, automated AR matching rates for open banking payments should be higher than for traditional bank transfers and competitive with card payment reconciliation. Build your AR automation workflow to ingest PISP confirmation webhooks alongside bank statement data for same-day automated matching. This eliminates the manual reconciliation gap that some businesses encounter when first adding open banking payments to their payment mix.
What Is the Outlook for Open Banking Payments in the EU Under PSD3?
PSD3 (the third Payment Services Directive, currently in legislative process as of 2025) proposes several enhancements to the PSD2 open banking framework that will directly benefit payment initiation. Key proposals: mandatory dedicated open banking API infrastructure (banks can no longer rely on screen-scraping fallbacks as contingency), improved API availability SLAs with enforcement mechanisms, standardized consent frameworks to reduce consumer friction, and explicit provisions for Variable Recurring Payment (VRP) mandates for commercial use cases.
PSD3 also proposes a new Financial Data Access (FIDA) framework extending data sharing beyond payment accounts to investment accounts, insurance, and mortgages — creating the foundation for open finance. For businesses building payment operations strategy for 2025–2028, PSD3 will make open banking payment initiation more reliable, more consistent across EU markets, and more viable for recurring billing use cases. The trajectory is clear: open banking payments will capture an increasing share of online transactions in EU markets over this period, making now the right time to test and build merchant capability. Follow developments on the Digital Payments hub.
What Are the Major Open Banking Payment Providers in Europe?
The European open banking payment infrastructure layer has consolidated around a handful of specialist providers. TrueLayer (UK/EU) is the largest independent open banking payment provider, covering 12+ European markets with high API reliability SLAs. Banked specializes in UK open banking with a focus on e-commerce checkout. Token.io provides enterprise-grade open banking connectivity to banks in 20+ European markets. Yapily offers API coverage across 2,000+ EU and UK banks. Major payment platforms have also integrated open banking: Stripe Link can use open banking for bank account verification and payment in supported markets; Adyen's open banking payment method covers EU and UK.
Selection criteria for merchants: API coverage in your target markets, reliability and uptime SLAs (critical — a payment failure at checkout is a lost sale), settlement speed (SEPA Instant vs next-day SEPA CT), refund initiation capability, and integration complexity. For enterprise merchants, evaluate whether open banking payment data can feed into existing ERP reconciliation workflows with the same level of automation as card payment data. Our payment infrastructure overview covers how open banking fits the broader payment stack.
How Does Open Banking Payment Initiation Interact with Accounting and Reconciliation?
Open banking payments generate a different data model than card payments for accounts receivable reconciliation. Card payments arrive as net settlements (gross minus interchange/fees) batched by acquirer. Open banking payments arrive as gross amounts directly from the payer's bank, with PISP fees charged separately (often as a monthly invoice rather than per-transaction deduction). This means bank statement reconciliation must handle both gross-amount open banking credits and PISP monthly fee invoices, rather than the standard net settlement model from card acquirers.
For ERP integration, open banking payment confirmations include structured reference data (the payment reference you pass to the PISP appears in the bank statement credit). With ISO 20022 SEPA Instant transactions carrying full structured remittance data, automated AR matching rates for open banking payments should be higher than for traditional bank transfers and competitive with card payment reconciliation. Build your AR automation workflow to ingest PISP confirmation webhooks alongside bank statement data for same-day automated matching. This eliminates the manual reconciliation gap that some businesses encounter when first adding open banking payments to their payment mix.
What Is the Outlook for Open Banking Payments in the EU Under PSD3?
PSD3 (the third Payment Services Directive, currently in legislative process as of 2025) proposes several enhancements to the PSD2 open banking framework that will directly benefit payment initiation. Key proposals: mandatory dedicated open banking API infrastructure (banks can no longer rely on screen-scraping fallbacks as contingency), improved API availability SLAs with enforcement mechanisms, standardized consent frameworks to reduce consumer friction, and explicit provisions for Variable Recurring Payment (VRP) mandates for commercial use cases.
PSD3 also proposes a new Financial Data Access (FIDA) framework extending data sharing beyond payment accounts to investment accounts, insurance, and mortgages — creating the foundation for open finance. For businesses building payment operations strategy for 2025–2028, PSD3 will make open banking payment initiation more reliable, more consistent across EU markets, and more viable for recurring billing use cases. The trajectory is clear: open banking payments will capture an increasing share of online transactions in EU markets over this period, making now the right time to test and build merchant capability. Follow developments on the Digital Payments hub.
Frequently Asked Questions
Biometric Payments: How Face, Fingerprint, and Voice Payments Work
Biometric payments represent the convergence of payment security and frictionless user experience. Every time you pay with Face ID on your iPhone or tap a fingerprint on a payment terminal, you are using biometric payment authentication. The next frontier — standalone biometric payment at checkout without a device — is already live at scale in China and expanding to other markets. For payments professionals, biometrics changes the risk model: authentication is stronger, but data breach consequences are permanent since biometrics cannot be replaced like a password.
How Does Biometric Authentication Work in Mobile Payments?
In mobile wallets like Apple Pay and Google Pay, biometrics do not directly authenticate the payment — they authenticate access to a payment token. When you set up Apple Pay, your card is replaced with a Device Account Number (DAN) — a tokenized card credential stored in the iPhone’s Secure Enclave. When you pay, Face ID or Touch ID authenticates that you are the device owner, which releases the DAN for NFC transmission to the terminal. The card network processes the tokenized credential; your actual card number is never transmitted.
This architecture means that even if Apple were hacked, no actual card numbers would be exposed — only tokens that are useless without the device. It also means that biometric templates are processed entirely on-device by the Secure Enclave processor, which Apple cannot access. Google Pay uses a similar architecture through Android’s Trusted Execution Environment (TEE). This on-device model is why mobile biometric payment fraud rates are extremely low — reportedly 0.01–0.1% of card-not-present fraud rates.
| Method | How it works | Strength | Watch-out |
|---|---|---|---|
| Fingerprint | Sensor on device | Fast, familiar | Spoofing attempts |
| Face | Camera + depth map | Hands-free | Lighting, twins |
| Palm / vein | Scanner reads pattern | Hard to forge | Hardware cost |
| Voice | Voiceprint match | Remote-friendly | Background noise |
What Is Amazon One and How Does Palm Payment Work?
Amazon One is a palm recognition payment system deployed at Whole Foods stores, Amazon Go locations, sports stadiums, and select third-party retailers across the US. A customer hovers their palm above a scanner — the system captures palm vein patterns (which are unique and difficult to spoof) and matches them to a linked payment card in under 300 milliseconds. No card, phone, or PIN required.
Amazon One stores encrypted palm signatures on Amazon servers, not in the terminal, and links them to a customer’s payment method. This is a server-based biometric model — contrasting with Apple’s on-device model. The privacy implications are significant: Amazon holds a biometric identifier linked to purchase history for every enrolled customer. In the EU, this would require explicit GDPR consent as a special category data processor. In the US, several states (Illinois, Texas, Washington) have biometric data protection laws (BIPA) requiring written consent and mandating data destruction timelines.
How Is China Leading in Biometric Payment Adoption?
China has the world’s most advanced biometric payment ecosystem. Alipay’s Smile to Pay and WeChat Pay’s facial recognition checkout have been deployed at hundreds of thousands of retail locations — customers pay by looking at a camera. China’s scale advantage: government-issued national ID cards linked to face recognition databases enable rapid enrollment and low false-acceptance rates. Alipay reports over 100 million enrolled facial payment users.
The Chinese model depends on a national biometric database architecture that would be impossible (and illegal under GDPR) to replicate in Europe. However, the user experience lessons are transferable: checkout with zero friction (no device, no card, no PIN) drives adoption. Western markets are developing equivalents within their regulatory constraints — primarily through mobile wallet face unlock and, in the US, Amazon One’s palm system. The technology trajectory points toward biometric-first checkout as the default in physical retail within this decade.
What Are the Privacy and Regulatory Considerations for Biometric Payments?
Biometric data receives heightened protection because it is immutable — unlike a password or card number, a compromised biometric cannot be replaced. Under GDPR, biometric data processing requires one of three legal bases: explicit consent (Art. 9(2)(a)), necessity for contractual performance in exceptional circumstances, or another specific exemption. Most payment biometrics will rely on explicit consent, meaning consumers must actively opt in — and can withdraw consent, triggering data deletion obligations.
The EU AI Act, applicable from 2025, classifies real-time remote biometric identification systems in public spaces as high-risk AI with strict conformity requirements — relevant for any facial recognition-at-checkout system. For businesses operating in Turkey, KVKK (the Turkish personal data protection law) treats biometric data as sensitive personal data requiring explicit consent and mandatory registration with KVKK for processing activities. See the full digital payments landscape in the Digital Payments hub.
What Is Behavioral Biometrics and How Is It Used in Payment Fraud Prevention?
Behavioral biometrics analyzes patterns in how a user interacts with a device — typing rhythm, mouse movement, touchscreen pressure, device tilt, and navigation patterns — to build a continuous authentication signal. Unlike physical biometrics (face, fingerprint) which authenticate at a single point in time, behavioral biometrics provide continuous passive authentication throughout a session. BioCatch, NuData Security, and ThreatMetrix are leaders in behavioral biometrics for banking and payments.
For payment fraud prevention, behavioral biometrics is particularly effective against account takeover (ATO) fraud: even if an attacker has the correct password and passes SMS OTP, their behavioral patterns (typing speed, navigation path, device handling) will differ from the legitimate user. Banks implementing behavioral biometrics report 50–80% reductions in ATO fraud. The technology is invisible to legitimate users — no additional friction — which makes it the ideal complement to visible authentication like Face ID. For payment platforms processing thousands of daily transactions, behavioral biometrics as a fraud signal layer can be implemented through APIs from specialist providers without rebuilding authentication infrastructure.
How Does Biometric Payment Authentication Interact with SCA Requirements?
Under PSD2’s Strong Customer Authentication (SCA) requirements, a payment must be authenticated using at least two of three factors: knowledge (PIN/password), possession (device/card), and inherence (biometric). Biometric authentication satisfies the ‘inherence’ factor — making it one component of a complete SCA solution. On mobile, Face ID or fingerprint (inherence) + device possession (possession) = 2-factor SCA compliant authentication. This is why Apple Pay and Google Pay are inherently SCA compliant in EU markets — the combination of biometric unlock and device possession automatically meets PSD2 requirements.
For standalone biometric checkout systems (like Amazon One palm payment in a physical store), the design must ensure a second factor is present to meet SCA if the transaction is classified as a remote payment. Card-present transactions at a physical terminal are generally exempt from SCA (EMV chip handles authentication), but the regulatory classification of biometric-only checkout without a card could vary by national regulator interpretation. Legal review of the specific authentication architecture against the relevant PSD2 RTS (Regulatory Technical Standards) is advisable before deploying novel biometric payment systems in EU markets. Connect this context with the payment tech overview in our Digital Payments hub.
What Is the Commercial Outlook for Biometric Payments in the Next Five Years?
The trajectory for biometric payments over 2025–2030 is toward ambient authentication — where a combination of behavioral signals, device presence, and periodic explicit biometric confirms continuously authenticate users without active engagement. The consumer experience converges on: walk into a store, pick up items, walk out. The payment happens automatically. Amazon Go stores already implement this for small-format grocery; the technology is being commercialized for larger retail formats.
For enterprise payments (corporate card, travel and expense management), biometric authentication of card transactions through mobile banking apps is already the standard. The next evolution is biometric authorization of B2B wire transfers and ERP-initiated payments — where a CFO approves a €500,000 supplier payment with a fingerprint on their phone rather than a hardware token or call-back authentication. Several banks and treasury management systems are building this workflow for launch in 2025–2026. The security implications are significant: biometric approval creates an irrefutable audit trail for payment authorization, which has value for internal control frameworks and external audit purposes — a genuine advancement for finance function governance.
What Is Behavioral Biometrics and How Is It Used in Payment Fraud Prevention?
Behavioral biometrics analyzes patterns in how a user interacts with a device — typing rhythm, mouse movement, touchscreen pressure, device tilt, and navigation patterns — to build a continuous authentication signal. Unlike physical biometrics (face, fingerprint) which authenticate at a single point in time, behavioral biometrics provide continuous passive authentication throughout a session. BioCatch, NuData Security, and ThreatMetrix are leaders in behavioral biometrics for banking and payments.
For payment fraud prevention, behavioral biometrics is particularly effective against account takeover (ATO) fraud: even if an attacker has the correct password and passes SMS OTP, their behavioral patterns (typing speed, navigation path, device handling) will differ from the legitimate user. Banks implementing behavioral biometrics report 50–80% reductions in ATO fraud. The technology is invisible to legitimate users — no additional friction — which makes it the ideal complement to visible authentication like Face ID. For payment platforms processing thousands of daily transactions, behavioral biometrics as a fraud signal layer can be implemented through APIs from specialist providers without rebuilding authentication infrastructure.
How Does Biometric Payment Authentication Interact with SCA Requirements?
Under PSD2’s Strong Customer Authentication (SCA) requirements, a payment must be authenticated using at least two of three factors: knowledge (PIN/password), possession (device/card), and inherence (biometric). Biometric authentication satisfies the ‘inherence’ factor — making it one component of a complete SCA solution. On mobile, Face ID or fingerprint (inherence) + device possession (possession) = 2-factor SCA compliant authentication. This is why Apple Pay and Google Pay are inherently SCA compliant in EU markets — the combination of biometric unlock and device possession automatically meets PSD2 requirements.
For standalone biometric checkout systems (like Amazon One palm payment in a physical store), the design must ensure a second factor is present to meet SCA if the transaction is classified as a remote payment. Card-present transactions at a physical terminal are generally exempt from SCA (EMV chip handles authentication), but the regulatory classification of biometric-only checkout without a card could vary by national regulator interpretation. Legal review of the specific authentication architecture against the relevant PSD2 RTS (Regulatory Technical Standards) is advisable before deploying novel biometric payment systems in EU markets. Connect this context with the payment tech overview in our Digital Payments hub.
What Is the Commercial Outlook for Biometric Payments in the Next Five Years?
The trajectory for biometric payments over 2025–2030 is toward ambient authentication — where a combination of behavioral signals, device presence, and periodic explicit biometric confirms continuously authenticate users without active engagement. The consumer experience converges on: walk into a store, pick up items, walk out. The payment happens automatically. Amazon Go stores already implement this for small-format grocery; the technology is being commercialized for larger retail formats.
For enterprise payments (corporate card, travel and expense management), biometric authentication of card transactions through mobile banking apps is already the standard. The next evolution is biometric authorization of B2B wire transfers and ERP-initiated payments — where a CFO approves a €500,000 supplier payment with a fingerprint on their phone rather than a hardware token or call-back authentication. Several banks and treasury management systems are building this workflow for launch in 2025–2026. The security implications are significant: biometric approval creates an irrefutable audit trail for payment authorization, which has value for internal control frameworks and external audit purposes — a genuine advancement for finance function governance.
Are Biometric Payments Accessible to All Users?
Biometric payment systems must provide alternatives for users who cannot use a specific biometric — due to disability, injury, or religious/cultural reasons. Well-designed systems always offer a PIN or passphrase fallback. Operators deploying biometric-only checkout without a fallback option may face accessibility complaints or legal challenges under disability discrimination frameworks in the EU and UK. Multi-modal biometric systems (face OR fingerprint OR voice OR PIN) are the gold standard for inclusive payment design.
Frequently Asked Questions
Cross-Border Digital Payments: How International Transfers Work in 2026
Cross-border payments remain one of the most inefficient and expensive parts of the global financial system — and the most active area of fintech innovation. A company wire transferring payments to suppliers in Macedonia or Serbia, receiving payments from EU customers, or managing treasury across Turkey and the Balkans confronts a fragmented landscape of correspondent banks, variable FX spreads, and opaque fee structures. This guide maps the options clearly, from SWIFT to stablecoins.
How Does SWIFT Work for Cross-Border Payments?
SWIFT (Society for Worldwide Interbank Financial Telecommunication) is the messaging network used by over 11,000 financial institutions globally to communicate payment instructions. When a Turkish company sends a EUR wire to a Serbian supplier, the Turkish bank sends an authenticated SWIFT message (MT103 or, increasingly, ISO 20022 pacs.008) to a European correspondent bank, which forwards it to a Serbian correspondent, which credits the recipient’s bank. SWIFT itself does not move money — it carries the instruction; the actual transfer happens through pre-funded nostro/vostro accounts.
SWIFT gpi (global payments innovation), launched in 2017 and now covering over 90% of SWIFT traffic, adds tracking, speed guarantees (credits by end of business day), and fee transparency. Every gpi payment carries a Unique End-to-End Transaction Reference (UETR) — a tracking number merchants and corporate treasurers can use to monitor payment status in real time. For corporate treasury, requesting UETR tracking from your bank for all outgoing cross-border wires is now standard practice.
| Method | Speed | Cost | Best for |
|---|---|---|---|
| Bank wire (SWIFT) | 1–5 days | Higher, opaque | Large/critical sums |
| Fintech transfer | Minutes–hours | Lower, transparent | Everyday amounts |
| Card networks | Fast | Mid | Consumer payments |
| Real-time rail links | Seconds | Low | Linked corridors |
| Stablecoin/crypto | Minutes | Variable | Niche/tech-savvy |
How Does Wise (TransferWise) Work and Why Is It Cheaper?
Wise uses a local pooling model to avoid correspondent banking chains. Instead of sending money across borders, Wise maintains local bank accounts in each currency country. When a Turkish customer sends EUR to a German recipient, Wise debits the customer’s TRY in Turkey from a Turkish bank account, and credits EUR to the German recipient from a German bank account — the two movements are matched internally. Cross-border money movement is minimized, eliminating correspondent bank fees.
Wise’s pricing is transparent: a mid-market exchange rate plus a fee typically between 0.4% and 1.5% depending on the currency pair. For a €10,000 EUR transfer, Wise typically costs €50–150 total versus €150–400 through a traditional bank (fees + spread). The limitation: Wise is primarily a consumer and SME product. For large corporate treasury transfers (€500,000+), Wise’s per-transfer limits and lack of treasury-specific features (structured products, forward contracts) make specialist FX providers or multi-bank treasury platforms more appropriate.
What Is Ripple and Does It Solve Cross-Border Payments?
Ripple provides two distinct products: RippleNet (a messaging and settlement network for banks, competing with SWIFT) and On-Demand Liquidity (ODL), which uses XRP cryptocurrency as a bridge asset to avoid pre-funded nostro accounts in cross-border transactions. In the ODL model: USD is converted to XRP at the source, transferred via the XRP Ledger in seconds, and converted to the destination currency — avoiding the need for the sending bank to hold pre-funded accounts in the destination currency.
Ripple has had genuine adoption among payment providers in corridors like US–Mexico and Europe–Southeast Asia. However, the XRP price volatility (even within a few seconds of a transaction) creates FX risk that requires sophisticated hedging for large transactions. Ripple’s ongoing legal battles with the SEC (partially resolved in 2023–2024) created regulatory uncertainty that slowed institutional adoption. As of 2025, Ripple is one of several viable alternatives to SWIFT for specific corridors, but not the universal replacement it once claimed to be.
What Role Do Stablecoins Play in Cross-Border Payments?
Stablecoins — cryptocurrencies pegged to fiat currencies (USDC, USDT, EURC) — are increasingly used for cross-border settlement, particularly in corridors with limited banking infrastructure. A USDC transfer on Stellar or Solana settles in 2–5 seconds at a cost of fractions of a cent. For businesses operating in markets where banking is expensive or unreliable, stablecoin settlement offers a genuine alternative.
The practical barriers for corporate use remain: (1) on-ramp/off-ramp costs — converting local currency to stablecoin and back can cost 0.5–2%; (2) regulatory uncertainty — MiCA in the EU (effective 2024) provides a framework for stablecoin issuers but imposes strict reserve and disclosure requirements; (3) accounting complexity — stablecoin receipts may trigger crypto accounting requirements in some jurisdictions. For multinationals in Turkey and the Balkans, stablecoins are worth monitoring as a treasury tool but not yet standard operating procedure. For context on how payment standards are evolving, see our ISO 20022 guide and the Digital Payments hub.
What Are the Most Efficient Cross-Border Corridors in 2025?
Cross-border payment efficiency varies dramatically by corridor. The EU internal market is now extremely efficient for EUR transfers via SEPA Instant — effectively free, instant, and fully integrated. EU–UK remains efficient via Faster Payments (GBP) or SEPA for EUR. US–EU is served by SWIFT gpi with same/next-day settlement and Wise for lower amounts. EU–Turkey is moderately efficient via SWIFT with 1–2 day settlement; Wise operates this corridor competitively. EU–Serbia/Macedonia/Albania remains relatively expensive and slow — 2–3 day SWIFT via correspondents, with fewer alternatives. BIS Project Nexus is developing multilateral RTP connectivity for Southeast Europe but is not yet live.
What Is the True Cost of Cross-Border Payments for Businesses?
The stated bank fee for a cross-border wire (e.g., $30 flat) is rarely the full cost. The complete cross-border payment cost has four components: (1) outgoing bank fee ($15–50 at the sending bank); (2) intermediary fees ($5–25 per correspondent hop, deducted from principal mid-chain — often invisible until the recipient receives less than expected); (3) FX spread (0.5–3% above the mid-market rate applied by the sending bank, often embedded in the exchange rate quoted to you); and (4) receiving bank fee ($0–25 charged by the recipient bank).
For a €10,000 wire from Turkey to Germany: sending bank fee ~€30, FX spread ~€80 (at 0.8% above mid-market on TRY/EUR), intermediary fees ~€15, receiving fee ~€10. Total cost: ~€135 or 1.35%. For a €10,000 wire from Germany to Serbia: similar total cost, potentially higher due to fewer SEPA alternatives. Aggregated across a multinational operation making 500 cross-border payments per year, payment costs easily reach €50,000–150,000 annually — a material treasury optimization target. Wise Business, Currencycloud, or a specialist FX provider can reduce this by 50–70% on eligible corridors.
How Does SWIFT gpi Improve Cross-Border Payment Visibility?
SWIFT gpi (global payments innovation) introduced two game-changing transparency features for corporate treasurers. First, the UETR (Unique End-to-End Transaction Reference) — a tracking number that follows the payment through every correspondent hop and can be monitored via your bank’s gpi tracker or directly via the SWIFT gpi portal (if your company has direct SWIFT access). Second, Confirmation of Credit — the gpi standard requires that the receiving bank confirm credit to the recipient account, closing the loop on payment status.
Before gpi, corporate treasury teams routinely spent significant time chasing payment status — calling correspondent banks, sending trace requests, manually reconciling payment acknowledgments against bank statements. With gpi, payment status is available in near real-time. For companies managing treasury across Turkey, Macedonia, Albania, and the EU, implementing gpi tracker integration in your TMS (treasury management system) should be a priority — it eliminates most payment status inquiry workload and allows proactive identification of stuck payments before suppliers escalate. Upgrade your SWIFT connectivity knowledge with our ISO 20022 guide for the complementary data standards context.
What Is BIS Project Nexus and How Could It Change Cross-Border Payments?
BIS Project Nexus is a multilateral framework developed by the Bank for International Settlements that connects national instant payment systems to enable cross-border real-time payments. Rather than bilateral connections between every country pair, Nexus creates a standardized protocol (a “network of networks”) where a payment initiated on one country’s RTP system can be received on another’s. India’s UPI, Malaysia’s DuitNow, Singapore’s PayNow, Thailand’s PromptPay, and the Philippines’ InstaPay completed a Nexus pilot in 2024.
The EU’s EBA Clearing is exploring Nexus integration for SEPA Instant’s cross-border extension. For Western Balkans countries aspiring to EU payment integration — including Serbia, North Macedonia, Albania, and Bosnia-Herzegovina — Nexus-compatible connectivity represents a potential path to real-time, low-cost cross-border payments without full EU membership. The realistic timeline for operational Nexus connectivity in Balkan corridors is 2027–2030, but understanding the framework now positions treasury teams to adopt it early when live.
What Is the True Cost of Cross-Border Payments for Businesses?
The stated bank fee for a cross-border wire (e.g., $30 flat) is rarely the full cost. The complete cross-border payment cost has four components: (1) outgoing bank fee ($15–50 at the sending bank); (2) intermediary fees ($5–25 per correspondent hop, deducted from principal mid-chain — often invisible until the recipient receives less than expected); (3) FX spread (0.5–3% above the mid-market rate applied by the sending bank, often embedded in the exchange rate quoted to you); and (4) receiving bank fee ($0–25 charged by the recipient bank).
For a €10,000 wire from Turkey to Germany: sending bank fee ~€30, FX spread ~€80 (at 0.8% above mid-market on TRY/EUR), intermediary fees ~€15, receiving fee ~€10. Total cost: ~€135 or 1.35%. For a €10,000 wire from Germany to Serbia: similar total cost, potentially higher due to fewer SEPA alternatives. Aggregated across a multinational operation making 500 cross-border payments per year, payment costs easily reach €50,000–150,000 annually — a material treasury optimization target. Wise Business, Currencycloud, or a specialist FX provider can reduce this by 50–70% on eligible corridors.
How Does SWIFT gpi Improve Cross-Border Payment Visibility?
SWIFT gpi (global payments innovation) introduced two game-changing transparency features for corporate treasurers. First, the UETR (Unique End-to-End Transaction Reference) — a tracking number that follows the payment through every correspondent hop and can be monitored via your bank’s gpi tracker or directly via the SWIFT gpi portal (if your company has direct SWIFT access). Second, Confirmation of Credit — the gpi standard requires that the receiving bank confirm credit to the recipient account, closing the loop on payment status.
Before gpi, corporate treasury teams routinely spent significant time chasing payment status — calling correspondent banks, sending trace requests, manually reconciling payment acknowledgments against bank statements. With gpi, payment status is available in near real-time. For companies managing treasury across Turkey, Macedonia, Albania, and the EU, implementing gpi tracker integration in your TMS (treasury management system) should be a priority — it eliminates most payment status inquiry workload and allows proactive identification of stuck payments before suppliers escalate. Upgrade your SWIFT connectivity knowledge with our ISO 20022 guide for the complementary data standards context.
What Is BIS Project Nexus and How Could It Change Cross-Border Payments?
BIS Project Nexus is a multilateral framework developed by the Bank for International Settlements that connects national instant payment systems to enable cross-border real-time payments. Rather than bilateral connections between every country pair, Nexus creates a standardized protocol (a “network of networks”) where a payment initiated on one country’s RTP system can be received on another’s. India’s UPI, Malaysia’s DuitNow, Singapore’s PayNow, Thailand’s PromptPay, and the Philippines’ InstaPay completed a Nexus pilot in 2024.
The EU’s EBA Clearing is exploring Nexus integration for SEPA Instant’s cross-border extension. For Western Balkans countries aspiring to EU payment integration — including Serbia, North Macedonia, Albania, and Bosnia-Herzegovina — Nexus-compatible connectivity represents a potential path to real-time, low-cost cross-border payments without full EU membership. The realistic timeline for operational Nexus connectivity in Balkan corridors is 2027–2030, but understanding the framework now positions treasury teams to adopt it early when live.
Frequently Asked Questions
What Are Embedded Payments? How They Work and Why They Matter
Embedded payments are the most commercially significant shift in fintech since mobile wallets. When Uber collects payment without a checkout screen, when Shopify merchants receive payouts through Shopify Balance, when a SaaS platform offers its customers card acceptance — all of these are embedded payments. For platform businesses and CFOs evaluating payment strategy, embedded payments represent both a revenue opportunity and a regulatory responsibility that demands careful structuring.
How Does the Embedded Payment Model Work Technically?
Embedded payments rely on the payment facilitator (PayFac) model or its modern evolution, the PayFac-as-a-Service model. The platform (Shopify, Mindbody, Toast) becomes a master merchant with a payment processor, then onboards its customers as sub-merchants. The platform handles sub-merchant onboarding (KYC/KYB verification), transaction processing, and fund disbursement — all through APIs provided by an infrastructure provider like Stripe Connect.
The infrastructure layer handles: card network connections, acquiring relationships, fraud screening, chargeback management, and compliance. The platform layer handles: sub-merchant onboarding UI, fund routing logic (split payments to multiple parties, marketplace escrow), and customer support. The economics: the platform earns a margin on each transaction — typically 0.5–1.5% above the underlying processing cost — creating a recurring payment revenue stream alongside its software subscription revenue.
| Dimension | Embedded Payments | Traditional Integration |
|---|---|---|
| User experience | Seamless, in-context | Redirect / separate flow |
| Who owns UX | The platform | The payment provider |
| Setup | API / platform partner | Merchant account + gateway |
| Revenue share | Platform can earn | Mostly provider |
| Best for | SaaS, marketplaces | Standalone merchants |
What Is the Revenue Opportunity for Platforms?
Embedded payments are one of the highest-value revenue expansions available to software platforms. A SaaS platform charging €100/month per merchant earns €1,200/year from software. If that merchant processes €200,000/year through the platform at a 0.5% payment margin, the platform earns an additional €1,000/year — nearly doubling revenue per customer. At scale, payment revenue often exceeds software subscription revenue for mature platforms.
Shopify’s financial services segment (which includes payments and merchant cash advances) generates over 60% of Shopify’s gross profit. Toast (restaurant POS) generates the majority of revenue through payment processing. This pattern repeats across vertical SaaS: the software is the acquisition channel; payments are the profit engine. For platform businesses evaluating embedded payments, the key question is not whether to embed payments but how quickly the compliance and integration investment can be recovered.
What Are the Compliance Requirements for Embedded Payments?
Embedded payment platforms take on regulatory obligations that don’t apply to ordinary merchants. Key requirements: KYB (Know Your Business) — verifying sub-merchant identity, business registration, and beneficial ownership before onboarding; AML monitoring — screening transactions for suspicious patterns and filing SARs where required; PCI DSS compliance at the platform level; and in the EU, registration as a payment institution or partnering with a licensed PI/EMI for regulated payment activities.
The regulatory complexity is why PayFac-as-a-Service models (using Stripe’s or Adyen’s licenses) are preferred by most platforms over obtaining their own payment institution license. Under PSD2 in the EU, platforms that distribute payment services of a licensed PSP may qualify as agents of that PSP — a lighter regulatory registration compared to full PI authorization. The distinction matters for platforms operating in Turkey alongside EU markets: Turkish BDDK licensing requirements differ from EU PSD2 frameworks. Seek legal advice before launching embedded payments in a new jurisdiction.
How Do Split Payments and Marketplace Payouts Work?
Marketplaces (Airbnb, Etsy, Uber) use embedded payments with split payment or payout routing logic: a single consumer payment is split between the platform (its fee) and the seller (their proceeds), with payouts disbursed on a schedule. Stripe Connect supports three models: Direct Charges (funds go to connected account, platform takes application fee), Destination Charges (funds go to platform, then transferred to connected account), and Separate Charges and Transfers (maximum flexibility, complex compliance).
For international marketplaces, split payments intersect with FX conversion and cross-border payout complexity. A marketplace paying out to sellers in Turkey (TRY), Macedonia (MKD), and the EU (EUR) needs a payout infrastructure that handles local bank transfer formats in each market. Providers like Rapyd and Payoneer specialize in multi-currency mass payouts across the markets relevant to Balkan-EU commerce. See the broader context in our cross-border digital payments guide and the Digital Payments hub.
What Are the Limits and Risks of Embedded Payments?
The risks of embedded payments span operational, financial, and regulatory dimensions. Operational: as a PayFac, you absorb chargeback risk from sub-merchants. A single high-fraud sub-merchant can generate losses that exceed months of payment revenue. Implement transaction velocity limits, rolling reserves for new sub-merchants, and real-time fraud monitoring. Financial: payment margins compress over time as competitors enter and sub-merchants become more sophisticated about processing costs. Build moats around the payments experience — instant payouts, working capital products, integrated reconciliation — rather than competing on rate alone.
Regulatory: regulatory requirements for payment platforms are tightening globally. DORA (Digital Operational Resilience Act) in the EU creates operational resilience requirements for fintech platforms serving financial institutions. PSD3 (currently in legislative process) will expand agent registration requirements. Embedded payment platforms should engage regulatory counsel in each market and build compliance as a core product capability.
What Is the Embedded Finance Evolution Beyond Payments?
Embedded payments are the gateway to a broader embedded finance stack — where the platform becomes the primary financial services provider for its customers. The progression is: first, accept payments (the entry point); second, add embedded lending (merchant cash advances based on payment volume, like Shopify Capital, Square Loans, Stripe Capital); third, add embedded banking (business accounts, debit cards, IBAN accounts within the platform); fourth, add embedded insurance (coverage embedded in transactions, e.g., delivery insurance in logistics platforms).
Each step deepens the financial relationship with the sub-merchant or end user, increases switching costs, and creates additional revenue streams. A SaaS platform that has progressed through all four stages earns 4–8x more revenue per customer than one that only offers software subscriptions. The most advanced examples — Toast for restaurants, Mindbody for fitness studios, Procore for construction — generate the majority of their revenue from financial services, not software licenses. The strategic implication for platform businesses: embedded payments is not a feature addition, it is a business model transformation.
How Do Platforms Handle Regulatory Compliance Across Multiple Countries?
Multi-country embedded payment platforms face layered compliance requirements. In the EU, PSD2 agent registration allows a platform to distribute payment services under a licensed PSP’s authorization — each EU country requires separate agent registration (or relies on the PSP’s passporting). In Turkey, BDDK requires its own payment service license for companies facilitating payments. In the UK, FCA registration applies post-Brexit independently of EU PSD2.
The practical approach for most growth-stage platforms: use a global PayFac infrastructure provider (Stripe Connect, Adyen for Platforms, Rapyd) that holds the required licenses in each market and handles compliance on your behalf. You operate as a facilitator under their regulatory umbrella. As you scale, evaluate obtaining your own payment institution licenses in your core markets — direct licensing reduces per-transaction costs and increases control but requires 12–18 months of regulatory process and significant compliance headcount. The regulatory map for Balkan markets (Serbia, Macedonia, Albania) is less standardized than EU markets — check payment licensing requirements in each jurisdiction individually before launching embedded payments. Our cross-border digital payments guide covers multi-jurisdiction payment operations in depth.
What Metrics Should Platforms Track for Embedded Payment Performance?
Embedded payment performance requires a dedicated metrics framework beyond standard payment KPIs. Key metrics: payment attach rate (% of platform customers using embedded payments vs external processors — target 60%+ for mature platforms); GPV (Gross Payment Volume) per active sub-merchant; payment take rate (platform’s effective margin on payment volume); payout timing (same-day payout as a feature drives attach rate); and payment-driven NRR (net revenue retention attributable to payment revenue growth from existing customers).
Track chargeback rate by sub-merchant segment monthly — clusters of high-chargeback sub-merchants are an early fraud warning signal that requires immediate portfolio-level action. Set automated alerts for any sub-merchant exceeding 0.5% monthly chargeback rate, and implement payment holds and reserve requirements as the rate approaches 1%. The platforms that grow embedded payment revenue sustainably are those that treat payment risk management as a core product competency, not an operations afterthought.
What Is the Embedded Finance Evolution Beyond Payments?
Embedded payments are the gateway to a broader embedded finance stack — where the platform becomes the primary financial services provider for its customers. The progression is: first, accept payments (the entry point); second, add embedded lending (merchant cash advances based on payment volume, like Shopify Capital, Square Loans, Stripe Capital); third, add embedded banking (business accounts, debit cards, IBAN accounts within the platform); fourth, add embedded insurance (coverage embedded in transactions, e.g., delivery insurance in logistics platforms).
Each step deepens the financial relationship with the sub-merchant or end user, increases switching costs, and creates additional revenue streams. A SaaS platform that has progressed through all four stages earns 4–8x more revenue per customer than one that only offers software subscriptions. The most advanced examples — Toast for restaurants, Mindbody for fitness studios, Procore for construction — generate the majority of their revenue from financial services, not software licenses. The strategic implication for platform businesses: embedded payments is not a feature addition, it is a business model transformation.
How Do Platforms Handle Regulatory Compliance Across Multiple Countries?
Multi-country embedded payment platforms face layered compliance requirements. In the EU, PSD2 agent registration allows a platform to distribute payment services under a licensed PSP’s authorization — each EU country requires separate agent registration (or relies on the PSP’s passporting). In Turkey, BDDK requires its own payment service license for companies facilitating payments. In the UK, FCA registration applies post-Brexit independently of EU PSD2.
The practical approach for most growth-stage platforms: use a global PayFac infrastructure provider (Stripe Connect, Adyen for Platforms, Rapyd) that holds the required licenses in each market and handles compliance on your behalf. You operate as a facilitator under their regulatory umbrella. As you scale, evaluate obtaining your own payment institution licenses in your core markets — direct licensing reduces per-transaction costs and increases control but requires 12–18 months of regulatory process and significant compliance headcount. The regulatory map for Balkan markets (Serbia, Macedonia, Albania) is less standardized than EU markets — check payment licensing requirements in each jurisdiction individually before launching embedded payments. Our cross-border digital payments guide covers multi-jurisdiction payment operations in depth.
What Metrics Should Platforms Track for Embedded Payment Performance?
Embedded payment performance requires a dedicated metrics framework beyond standard payment KPIs. Key metrics: payment attach rate (% of platform customers using embedded payments vs external processors — target 60%+ for mature platforms); GPV (Gross Payment Volume) per active sub-merchant; payment take rate (platform’s effective margin on payment volume); payout timing (same-day payout as a feature drives attach rate); and payment-driven NRR (net revenue retention attributable to payment revenue growth from existing customers).
Track chargeback rate by sub-merchant segment monthly — clusters of high-chargeback sub-merchants are an early fraud warning signal that requires immediate portfolio-level action. Set automated alerts for any sub-merchant exceeding 0.5% monthly chargeback rate, and implement payment holds and reserve requirements as the rate approaches 1%. The platforms that grow embedded payment revenue sustainably are those that treat payment risk management as a core product competency, not an operations afterthought.
How Do Embedded Payment Providers Price Their Services?
PayFac infrastructure providers use two main pricing models. Interchange-plus: the platform pays exact interchange plus a fixed basis-point markup (e.g., interchange + 0.15% + €0.10). This is most transparent and best for high-volume platforms. Flat rate: a fixed percentage per transaction (e.g., 2.5%), simpler to model but less optimal at scale. Stripe Connect charges a platform fee plus the underlying Stripe processing cost; Adyen for Platforms uses interchange-plus for enterprise clients. Whichever model you choose, benchmark your effective rate per transaction quarterly against market rates — the embedded payments market is competitive and rates should improve as your volume grows.
Frequently Asked Questions
Buy Now Pay Later (BNPL): How It Works and What Businesses Need to Know
BNPL has become one of the fastest-growing payment methods in e-commerce — and one of the most debated in regulatory circles. For merchants evaluating BNPL as a checkout option, and for CFOs assessing the payment cost implications, understanding how the economics actually work is essential. This guide cuts through the marketing to show exactly how BNPL providers make money, what merchants pay, and what the regulatory landscape looks like in 2025.
How Does BNPL Work for Consumers?
The standard BNPL model is pay-in-4: the consumer pays 25% at checkout and the remaining 75% in three equal installments every two weeks, with no interest charged if payments are made on time. Providers like Afterpay, Klarna (Pay in 4), and Zip operate this model. A parallel model is point-of-sale financing (Affirm, Klarna Financing): longer-term loans of 3–36 months at APRs ranging from 0% (subsidized by the merchant) to 36%, competing with store credit cards.
The consumer experience is frictionless by design: a soft credit check (no hard inquiry that affects credit score) completes in under a second using real-time data signals — email age, device fingerprint, purchase history, and sometimes bureau data. Approval rates typically exceed 80% for standard pay-in-4. This frictionlessness is both the product’s appeal and regulators’ concern: consumers can accumulate BNPL obligations across multiple providers with no visibility to credit bureaus.
| Dimension | BNPL | Credit Card | Personal Loan |
|---|---|---|---|
| Approval | Instant, light check | Credit check | Full underwriting |
| Cost to shopper | Often 0% if on time | Revolving interest | Fixed interest |
| Repayment | Few fixed installments | Flexible minimum | Fixed schedule |
| Late penalty | Fees, can escalate | Interest + fees | Interest + fees |
| Best for | Small one-off buys | Ongoing spending | Larger amounts |
How Do BNPL Providers Make Money?
BNPL providers have three revenue streams. The largest is merchant fees — the 2–6% charged per transaction. For Afterpay, merchant fees accounted for over 70% of revenue historically. The second stream is late fees — typically $7–15 per missed payment, capped at 25% of the order value in some jurisdictions. The third is interest income on longer-term financing products (Klarna Financing, Affirm’s longer-duration loans).
The business model is fundamentally a credit model, not a payments model. BNPL providers hold receivables (consumer installments due) financed by debt facilities and capital markets. When interest rates rise sharply — as in 2022–2023 — BNPL providers’ funding costs surge while they often offer 0% financing to consumers. This caused significant losses across the sector and triggered consolidation. The longer-term viability of pure 0% BNPL depends on maintaining low credit losses, which requires disciplined underwriting as the consumer base scales.
What Is the Merchant Case for Offering BNPL?
The merchant case rests on three metrics: conversion rate lift (typically 20–30% improvement at checkout when BNPL is offered), average order value (AOV) increase (commonly 30–50% higher for BNPL transactions versus card), and new customer acquisition (BNPL providers surface merchants in their own apps and marketplaces). For a fashion retailer with a €120 average basket, BNPL might lift AOV to €180 while improving conversion — potentially justifying a 4% fee versus a 1.5% card rate.
However, merchants must also account for return rates (higher on BNPL purchases as consumers buy more impulsively) and chargeback complexity (BNPL disputes require different resolution processes than card chargebacks). For B2B merchants, BNPL-for-business products (Billie, Mondu, Hokodo in Europe) offer net-30/60 payment terms embedded at checkout — a compelling alternative to traditional trade credit management. For full context on how BNPL fits the payment stack, see our gateway and processor guide.
How Is BNPL Regulated in the EU, UK, and Turkey?
In the EU, the revised Consumer Credit Directive (CCD2), which member states must implement by November 2026, extends consumer credit rules to BNPL products: pre-contractual disclosure, affordability assessments, and right of withdrawal apply to interest-free BNPL for the first time. This will require BNPL providers to implement creditworthiness checks across all EU markets.
In the UK, the FCA brought BNPL under its consumer credit regulatory perimeter in 2024, requiring FCA authorization for BNPL providers. In Turkey, the BDDK regulates installment payments on bank cards (taksit) and has historically capped installment periods on certain categories — BNPL as a standalone fintech product operates in a greyer zone under BDDK’s payment service licensing framework.
How Do the Major BNPL Providers Compare?
Klarna is the largest BNPL provider globally by GMV, operating in 45 countries. It offers Pay in 4, Pay in 30 (invoice), and Financing products. Klarna obtained a Swedish banking license in 2017, enabling deposit-taking. Afterpay (owned by Block/Square) dominates in Australia and has strong US presence, operating a pure pay-in-4 model. Affirm focuses on US markets with a spectrum from 0% merchant-subsidized to 36% APR loans, and has deep integrations with Shopify and Amazon. PayPal Pay Later leverages existing merchant relationships — 35M+ merchants already integrate PayPal, reducing BNPL adoption friction to near zero.
In Europe, Scalapay (Italy/Southern Europe) and Riverty (formerly AfterPay by Arvato) compete with Klarna. In Turkey, local banks’ taksit (installment) features on credit cards have historically served the BNPL function — standalone BNPL fintechs are less established. The Digital Payments hub covers related payment innovations in depth.
What Are the BNPL Risks for Consumers and Systemic Finance?
The systemic risk regulators worry about is invisible indebtedness: a consumer using four different BNPL services simultaneously — each with its own app, no bureau reporting — may have €3,000 in BNPL obligations that no lender can see. When income shocks occur (job loss, health crisis), these obligations become unmanageable simultaneously. The UK Money and Pensions Service found that 40% of BNPL users had missed at least one payment.
For corporate finance professionals, the systemic concern is secondary to the operational one: if a key BNPL provider exits a market (as several did during 2022–2023 funding pressure), merchants dependent on BNPL for 20–30% of revenue face an immediate conversion rate hit. Treat BNPL as a supplementary payment method, not a core infrastructure dependency, and maintain card acceptance as the primary rail.
How Does BNPL Affect Merchant Cash Flow and Accounting?
From a merchant accounting perspective, BNPL works like a factoring arrangement: the BNPL provider pays the merchant gross transaction value minus merchant fee immediately (typically within 1–3 business days), and collects installments from the consumer directly. The merchant recognizes revenue at point of sale; the installment collection risk is borne entirely by the BNPL provider. Unlike credit card terminals, there is no consumer credit risk on the merchant’s balance sheet.
The accounting entries are clean: debit Cash (or Accounts Receivable from BNPL provider), credit Revenue, credit Sales Tax Payable. The BNPL merchant fee is recorded as payment processing expense. For companies using accrual accounting, the timing difference between sale recognition and BNPL payout (1–3 days) is typically immaterial. However, for businesses with very high BNPL volume (30%+ of revenue), monitoring BNPL provider settlement reliability — and having contingency payment method coverage — is prudent working capital management.
What Is the Impact of BNPL on Consumer Spending Behavior?
The behavioral economics of BNPL are well-documented and commercially significant. Payment decoupling — separating the pain of payment from the pleasure of purchase — reduces perceived price sensitivity. Consumers tend to focus on the installment amount (€25/month) rather than total cost (€100), making higher-priced items feel affordable. This effect is most pronounced for fashion, electronics, and home goods — categories where BNPL adoption is highest.
Research by the Klarna-affiliated Consumer Payments Research Center and independent studies by the FCA find that BNPL users are disproportionately younger (18–34), urban, and lower-income — demographics with less existing credit product access. For merchants targeting these demographics, BNPL is both a conversion tool and an inclusivity feature. For regulators, the same data raises debt spiral concerns: the customers most susceptible to BNPL impulse purchasing are also those with least financial buffer for missed payments.
How Is BNPL Technology Evolving — From Checkout to Anywhere?
BNPL is evolving beyond the online checkout button. BNPL virtual cards (Klarna Card, Affirm Virtual Card) allow consumers to use BNPL at any retailer — not just those with direct BNPL integrations — by generating a one-time virtual card number charged against the BNPL provider’s account. This dramatically expands the addressable merchant universe without requiring individual merchant integrations.
In-store BNPL (via QR code at POS) is growing in the US, UK, and Australia. Klarna’s in-store QR code allows a customer to split any purchase at a physical checkout. This convergence of online and in-store BNPL creates a unified installment payment method across all channels — potentially the most significant checkout innovation for physical retail since contactless payments. For merchants managing an omnichannel payment stack, ensure your payment provider can report BNPL transactions from both channels in a unified dashboard for accurate payment mix analysis. See the broader payment method context in our Digital Payments hub.
How Does BNPL Affect Merchant Cash Flow and Accounting?
From a merchant accounting perspective, BNPL works like a factoring arrangement: the BNPL provider pays the merchant gross transaction value minus merchant fee immediately (typically within 1–3 business days), and collects installments from the consumer directly. The merchant recognizes revenue at point of sale; the installment collection risk is borne entirely by the BNPL provider. Unlike credit card terminals, there is no consumer credit risk on the merchant’s balance sheet.
The accounting entries are clean: debit Cash (or Accounts Receivable from BNPL provider), credit Revenue, credit Sales Tax Payable. The BNPL merchant fee is recorded as payment processing expense. For companies using accrual accounting, the timing difference between sale recognition and BNPL payout (1–3 days) is typically immaterial. However, for businesses with very high BNPL volume (30%+ of revenue), monitoring BNPL provider settlement reliability — and having contingency payment method coverage — is prudent working capital management.
What Is the Impact of BNPL on Consumer Spending Behavior?
The behavioral economics of BNPL are well-documented and commercially significant. Payment decoupling — separating the pain of payment from the pleasure of purchase — reduces perceived price sensitivity. Consumers tend to focus on the installment amount (€25/month) rather than total cost (€100), making higher-priced items feel affordable. This effect is most pronounced for fashion, electronics, and home goods — categories where BNPL adoption is highest.
Research by the Klarna-affiliated Consumer Payments Research Center and independent studies by the FCA find that BNPL users are disproportionately younger (18–34), urban, and lower-income — demographics with less existing credit product access. For merchants targeting these demographics, BNPL is both a conversion tool and an inclusivity feature. For regulators, the same data raises debt spiral concerns: the customers most susceptible to BNPL impulse purchasing are also those with least financial buffer for missed payments.
How Is BNPL Technology Evolving — From Checkout to Anywhere?
BNPL is evolving beyond the online checkout button. BNPL virtual cards (Klarna Card, Affirm Virtual Card) allow consumers to use BNPL at any retailer — not just those with direct BNPL integrations — by generating a one-time virtual card number charged against the BNPL provider’s account. This dramatically expands the addressable merchant universe without requiring individual merchant integrations.
In-store BNPL (via QR code at POS) is growing in the US, UK, and Australia. Klarna’s in-store QR code allows a customer to split any purchase at a physical checkout. This convergence of online and in-store BNPL creates a unified installment payment method across all channels — potentially the most significant checkout innovation for physical retail since contactless payments. For merchants managing an omnichannel payment stack, ensure your payment provider can report BNPL transactions from both channels in a unified dashboard for accurate payment mix analysis. See the broader payment method context in our Digital Payments hub.
Frequently Asked Questions
ISO 20022: What the New Global Payment Standard Means for Businesses
ISO 20022 is the biggest change to payment messaging infrastructure in 30 years — and most corporate treasury teams are unprepared for its implications. When completed, virtually every cross-border wire transfer, domestic high-value payment, and real-time rail message will carry structured, standardized data far richer than anything legacy MT messages could accommodate. For multinationals operating in Turkey, the Balkans, and the EU, ISO 20022 compliance is not optional — it is already live on SEPA, TARGET2, and increasingly on correspondent banking corridors.
What Is ISO 20022 and Why Was It Created?
ISO 20022 is an international standard developed by the International Organization for Standardization (ISO) for electronic data interchange between financial institutions. Where legacy SWIFT MT messages were limited in field length and used codes and abbreviations, ISO 20022 uses structured XML/JSON with a rich data dictionary — supporting over 600 defined message types across payments, securities, trade finance, and foreign exchange.
The standard was created to solve a fundamental problem: when money moves globally, payment instructions and remittance data were truncated, misformatted, or lost entirely as they passed through different banking systems speaking different ‘dialects.’ This caused failed payments, manual reconciliation, and compliance screening delays. ISO 20022 defines a universal financial language that every system can understand natively.
| Dimension | Legacy (MT / proprietary) | ISO 20022 |
|---|---|---|
| Data richness | Limited, unstructured | Rich, structured |
| Compliance screening | More false positives | More accurate |
| Reconciliation | Often manual | Automatable |
| Interoperability | Fragmented | Global standard |
| Future-proofing | Being retired | The new baseline |
What Is the SWIFT ISO 20022 Migration Timeline?
SWIFT began its ISO 20022 migration for cross-border payments in March 2023, entering a co-existence period where both legacy MT messages and new ISO 20022 MX messages (pacs.008, pacs.009, camt.054, etc.) flow in parallel on the SWIFT network. During co-existence, a translation service converts between formats so banks on either standard can still communicate.
The co-existence period ends November 2025, after which MT messages for payments will be discontinued. All SWIFT member banks must either send/receive native MX messages or rely on a (potentially fee-bearing) translation service. For corporate treasuries, the deadline means ERP and TMS systems must be tested for ISO 20022 compatibility before that date.
How Does ISO 20022 Affect Real-Time Payment Systems?
Most modern real-time payment rails were designed natively in ISO 20022. SEPA Instant Credit Transfer (SCT Inst) uses ISO 20022. India’s UPI uses an ISO 20022-based message format. Brazil’s Pix uses a derivative. FedNow was built on ISO 20022 from day one. This means that as real-time rails grow in importance, ISO 20022 becomes the de facto language of instant payments globally.
The richer data in ISO 20022 enables request-to-pay (RTP) workflows — where a payee can send a structured payment request (with invoice data, due dates, and amounts) to a payer, who approves it with a single click, triggering an instant rail payment. This workflow eliminates manual invoice reconciliation for accounts payable teams. Learn more about how RTP rails work in our real-time payment rails guide.
What Are the Key ISO 20022 Message Types for Corporate Finance?
The most relevant ISO 20022 message types for corporate treasury operations are: pacs.008 (FI to FI customer credit transfer — equivalent to MT103), pacs.009 (financial institution credit transfer — equivalent to MT202), pain.001 (customer credit transfer initiation — the file your ERP generates), camt.052/053/054 (bank-to-customer account reporting, statements, and debit/credit notifications — equivalent to MT940/942).
For AP/AR teams, the pain.001 file format is the most immediately relevant. ISO 20022 pain.001 supports structured remittance information up to 9,999 lines per payment — versus the 140-character limit in MT103. This means a single payment instruction can carry complete invoice-level reference data, enabling fully automated matching in your ERP without manual reconciliation.
How Does ISO 20022 Impact AML and Compliance Screening?
ISO 20022’s structured data fields — including LEI (Legal Entity Identifier), purpose codes, regulatory reporting indicators, and fully structured debtor/creditor addresses — dramatically improve AML and sanctions screening. Legacy MT messages had free-text fields where names were often truncated or coded, causing high false positive rates in OFAC/EU sanctions screening and manual review backlogs.
With ISO 20022, screening systems receive machine-readable, complete entity data. LEI lookup enables instant identification of the ultimate beneficial owner. Purpose codes enable risk-based processing. For financial institutions and their corporate customers, this means faster payment processing, lower compliance costs, and fewer held payments. For companies operating in jurisdictions with elevated sanctions risk (including some Balkan routes), this is material.
What Do Corporate Treasury Teams Need to Do Before November 2025?
The to-do list for corporate treasury is concrete: First, audit your payment file formats — if your ERP generates MT101 or MT103 files, these need to be converted to pain.001 ISO 20022 format. Second, review your bank statement formats — ensure your TMS can ingest camt.053/054 reports for automated cash positioning. Third, verify your LEI registration is current — many ISO 20022 message types require a valid LEI for legal entities.
Fourth, test your beneficiary data quality — ISO 20022 requires structured address fields (street, town, country) rather than free-text. Clean your vendor master data now. Fifth, assess whether SWIFT connectivity (if you use SWIFT directly for corporate-to-bank messaging under SWIFT for Corporates) needs upgrading. The transition is manageable with 3–6 months of preparation. Explore the full payment stack context in our Payment Infrastructure hub.
How Does ISO 20022 Enable Straight-Through Processing (STP) in Corporate Finance?
Straight-through processing (STP) means a payment is initiated, executed, and reconciled in accounts receivable or accounts payable without manual intervention. ISO 20022 is the enabling standard because it allows complete remittance information — invoice numbers, PO references, line-item detail — to travel with the payment in structured, machine-readable fields. The ERP system receiving the camt.054 debit/credit notification can automatically match the incoming payment to open invoices.
For large corporates processing thousands of cross-border payments monthly, improving STP rates from 60% to 95% can save hundreds of hours of AR/AP manual work per month. Legacy MT103 messages routinely truncated beneficiary names and reference data at 35 characters per line, causing systematic reconciliation failures. ISO 20022 supports 140-character structured fields and multi-line remittance blocks with unlimited invoice lines. The practical result: a supplier payment from a Turkish entity to a Macedonian entity can now carry the full invoice breakdown, tax line, and WHT reference — eliminating the phone calls and email chains that previously resolved mismatches.
What Is the LEI and Why Is It Critical for ISO 20022 Compliance?
The Legal Entity Identifier (LEI) is a 20-character alphanumeric code that uniquely identifies a legal entity in financial transactions. Issued by GLEIF-accredited Local Operating Units (LOUs), LEIs are required by multiple ISO 20022 message types, particularly for financial institutions and increasingly for corporates in regulated payment flows. In the EU, LEIs are mandatory for corporates trading securities; their use in payment messages is expanding under ISO 20022.
For a group of companies like a multinational energy operator with entities in Turkey, Macedonia, Albania, and Serbia, each operating entity should have its own LEI. Registration costs approximately $100–200 per entity per year through LOUs like the London Stock Exchange or WM Datenservice. The LEI appears in the <Id><LEI> field of ISO 20022 payment messages, enabling financial institutions to instantly screen the entity against sanctions lists and verify ownership chains. Entities without LEIs will face delays or manual review on payments where ISO 20022 LEI fields are required — update registrations annually without exception.
How Should Finance Teams Test ISO 20022 Readiness Before November 2025?
A practical ISO 20022 readiness assessment for corporate treasury has five steps. First, inventory payment flows: list every bank account, every payment type (SWIFT, SEPA, domestic wire), and whether the associated payment file format is MT or ISO 20022. Second, test bank connectivity: submit a test pain.001 ISO 20022 file to each banking partner and confirm it processes without errors. Third, validate camt reporting: configure your TMS to ingest camt.053 end-of-day statements and verify automated cash positioning works correctly.
Fourth, clean beneficiary master data: ISO 20022 requires structured postal addresses — existing free-text address fields in your ERP vendor master will fail validation. Export your vendor master, identify all free-text address records, and restructure them into street number, street name, city, postal code, and country fields. Fifth, validate remittance mapping: ensure your ERP payment proposal maps invoice references to the ISO 20022 RmtInf/Strd structured remittance fields rather than the unstructured text field. Each of these steps can be done in a structured remediation sprint of 4–8 weeks. Explore the full Payment Infrastructure hub for related topics including real-time payment rails that use ISO 20022 natively.
How Does ISO 20022 Enable Straight-Through Processing (STP) in Corporate Finance?
Straight-through processing (STP) means a payment is initiated, executed, and reconciled in accounts receivable or accounts payable without manual intervention. ISO 20022 is the enabling standard because it allows complete remittance information — invoice numbers, PO references, line-item detail — to travel with the payment in structured, machine-readable fields. The ERP system receiving the camt.054 debit/credit notification can automatically match the incoming payment to open invoices.
For large corporates processing thousands of cross-border payments monthly, improving STP rates from 60% to 95% can save hundreds of hours of AR/AP manual work per month. Legacy MT103 messages routinely truncated beneficiary names and reference data at 35 characters per line, causing systematic reconciliation failures. ISO 20022 supports 140-character structured fields and multi-line remittance blocks with unlimited invoice lines. The practical result: a supplier payment from a Turkish entity to a Macedonian entity can now carry the full invoice breakdown, tax line, and WHT reference — eliminating the phone calls and email chains that previously resolved mismatches.
What Is the LEI and Why Is It Critical for ISO 20022 Compliance?
The Legal Entity Identifier (LEI) is a 20-character alphanumeric code that uniquely identifies a legal entity in financial transactions. Issued by GLEIF-accredited Local Operating Units (LOUs), LEIs are required by multiple ISO 20022 message types, particularly for financial institutions and increasingly for corporates in regulated payment flows. In the EU, LEIs are mandatory for corporates trading securities; their use in payment messages is expanding under ISO 20022.
For a group of companies like a multinational energy operator with entities in Turkey, Macedonia, Albania, and Serbia, each operating entity should have its own LEI. Registration costs approximately $100–200 per entity per year through LOUs like the London Stock Exchange or WM Datenservice. The LEI appears in the <Id><LEI> field of ISO 20022 payment messages, enabling financial institutions to instantly screen the entity against sanctions lists and verify ownership chains. Entities without LEIs will face delays or manual review on payments where ISO 20022 LEI fields are required — update registrations annually without exception.
How Should Finance Teams Test ISO 20022 Readiness Before November 2025?
A practical ISO 20022 readiness assessment for corporate treasury has five steps. First, inventory payment flows: list every bank account, every payment type (SWIFT, SEPA, domestic wire), and whether the associated payment file format is MT or ISO 20022. Second, test bank connectivity: submit a test pain.001 ISO 20022 file to each banking partner and confirm it processes without errors. Third, validate camt reporting: configure your TMS to ingest camt.053 end-of-day statements and verify automated cash positioning works correctly.
Fourth, clean beneficiary master data: ISO 20022 requires structured postal addresses — existing free-text address fields in your ERP vendor master will fail validation. Export your vendor master, identify all free-text address records, and restructure them into street number, street name, city, postal code, and country fields. Fifth, validate remittance mapping: ensure your ERP payment proposal maps invoice references to the ISO 20022 RmtInf/Strd structured remittance fields rather than the unstructured text field. Each of these steps can be done in a structured remediation sprint of 4–8 weeks. Explore the full Payment Infrastructure hub for related topics including real-time payment rails that use ISO 20022 natively.
