Fintech Billing: Multi-Currency, Real-Time Settlement, and Compliance

Fintech companies operate under billing constraints that most SaaS businesses never encounter. Cross-border B2B payments now represent a $1.5 trillion market growing at 10.8% annually, with B2B transactions accounting for over 72% of all cross-border payment volume[1]. Every one of those transactions carries multi-currency conversion requirements, regulatory compliance obligations, and settlement timing expectations that generic billing platforms weren't designed to handle.

The regulatory landscape is shifting fast. PSD3 reached political agreement in November 2025 and is expected to be formally adopted in early-to-mid 2026, with an 18-to-24-month transposition period for EU member states[2]. DORA (Digital Operational Resilience Act) came into force in January 2025, replacing earlier incident reporting frameworks. ISO 20022 will become the standard for most cross-border SWIFT payments by 2027. For fintech billing infrastructure, this isn't background noise — it's the operating environment your billing system must be built for.

This guide covers the specific billing challenges fintech companies face and the infrastructure requirements for handling multi-currency invoicing, real-time settlement, regulatory compliance, and cross-border payment orchestration at scale.

How is fintech billing different from SaaS billing?

Fintech billing differs from standard SaaS billing across three dimensions: multi-currency complexity requiring simultaneous handling of transaction, billing, and reporting currencies; real-time settlement where fees must be calculated per transaction rather than in monthly batches; and cross-jurisdictional regulatory obligations including PSD3, DORA, and local e-invoicing mandates that dictate how invoices are generated, stored, and reported.

Standard SaaS billing follows a predictable pattern: a customer subscribes to a plan, usage gets metered, and an invoice is generated at the end of the billing cycle in a single currency. Fintech billing breaks every one of those assumptions.

In fintech, a single customer transaction might involve three currencies: the customer's local currency for billing, an intermediary currency for settlement, and the platform's reporting currency for revenue recognition. Each currency conversion introduces exchange rate risk, rounding discrepancies, and reconciliation complexity. Multiply this by thousands of transactions per day across dozens of markets, and billing accuracy becomes an engineering problem that generic platforms can't solve with configuration alone.

Real-time settlement adds another layer. Traditional SaaS billing operates on monthly cycles — usage accumulates, invoices generate, payments collect. Fintech products often need to bill per transaction, apply fees at the moment of settlement, and reconcile across multiple payment rails simultaneously. According to McKinsey's 2025 Global Payments Report, real-time cross-border payment volumes increased 36% between 2023 and 2025[3], driven by demand for instant settlement in B2B contexts. Billing infrastructure that operates on batch cycles can't keep pace with this shift.

Multi-currency billing: beyond simple conversion

Multi-currency support in billing is frequently reduced to "we convert at the current exchange rate." In practice, fintech companies need far more sophisticated currency handling.

The three currency layers

Every fintech billing transaction involves up to three distinct currency contexts. The transaction currency is the currency in which the end user or merchant transacts — determined by the market they operate in. The billing currency is the currency in which the platform's customer (often a financial institution or marketplace) receives their invoice — typically their home currency or a contractually agreed currency. The reporting currency is the currency in which the fintech company recognizes revenue and reports to investors, auditors, and tax authorities.

Your billing platform must maintain all three simultaneously. When a payment platform processes a €50 transaction for a US-based customer who reports in GBP, the billing system needs to calculate the platform fee in euros, convert to USD for the customer's invoice, and record the revenue in GBP — all using the correct exchange rate at the correct point in time, with full audit trail for each conversion.

Exchange rate management

Exchange rate handling in billing involves more than calling an API. Fintech companies typically need rate locking at quote time for predictable customer billing, configurable rate sources (ECB, custom provider feeds, or internal treasury rates), historical rate storage for retroactive calculations and dispute resolution, and margin or markup application on top of base rates for revenue on FX spreads.

The billing system should support per-customer currency configuration so that each customer receives invoices in their contracted currency, regardless of what currency the underlying transactions occur in. This is especially critical for B2B fintech where enterprise customers negotiate billing terms as part of their contracts.

Real-time settlement and transaction-level billing

Fintech products that process payments, facilitate lending, or enable trading need billing systems that can operate at transaction speed — not batch speed.

Per-transaction fee calculation

The most common fintech billing model applies fees to each transaction as it occurs. A payment processor might charge 2.9% plus $0.30 per transaction. A lending platform might take a percentage of each loan disbursement. A trading platform might charge per trade based on volume tiers.

This requires your billing system to process events in real time, apply the correct fee schedule (which may vary by customer, transaction type, currency, and volume tier), and maintain running totals for invoicing. Percentage-based pricing with per-transaction minimums and maximums is the baseline — but many fintech companies also need graduated percentage tiers where the rate changes based on cumulative volume within a billing period.

With a billing platform that supports dynamic and percentage charge models, you can configure per-transaction fees with flat rate components, per-transaction min/max adjustments, and graduated percentage tiers — all applied automatically as events are ingested in real time.

Progressive billing for high-volume fintech

High-volume fintech customers can accumulate significant charges before the end of a billing cycle. A payment processor handling $10M in monthly volume at 2.9% generates $290,000 in fees — waiting until month-end to invoice that amount creates cash flow risk for the platform and bill shock for the customer.

Progressive billing (also called threshold billing) solves this by triggering invoices at predefined spending thresholds. For example, you might invoice at $10,000, $50,000, and $100,000 in cumulative fees, then switch to recurring invoices at a fixed interval after the final threshold. This approach improves cash flow predictability for both parties and reduces payment failure risk on large invoices.

Regulatory compliance and billing infrastructure

Fintech billing doesn't exist in a regulatory vacuum. The compliance requirements your billing system must satisfy depend on where you operate, what financial services you provide, and who your customers are.

PSD3 and the evolving payments regulatory framework

The transition from PSD2 to PSD3 introduces several changes that directly affect billing infrastructure. PSD3 elevates identity verification, strong customer authentication, and fraud prevention to explicit regulatory obligations rather than optional guidelines. It expands the scope of regulated activities and creates new requirements for transaction monitoring and reporting.

For billing platforms serving fintech companies, this means the audit trail must be comprehensive. Every invoice, payment attempt, fee calculation, and currency conversion needs to be traceable back to source data with timestamps, exchange rates, and the specific pricing rules applied. This isn't optional — regulators expect this level of transparency, and your billing system either provides it natively or you build it yourself.

DORA and operational resilience

DORA, which came into full force in January 2025, imposes operational resilience requirements on financial entities and their critical third-party technology providers. If your billing platform is a critical part of a regulated fintech's infrastructure — and it almost certainly is — it falls under DORA's scope.

The practical implications include requirements for business continuity and disaster recovery, incident reporting within prescribed timeframes, regular resilience testing, and third-party risk management documentation. Your billing vendor's uptime guarantees, incident response procedures, and data recovery capabilities are no longer just operational concerns — they're regulatory requirements.

Multi-jurisdiction tax and e-invoicing

Fintech companies operating across borders face a patchwork of tax rules and electronic invoicing mandates. The EU's ViDA (VAT in the Digital Age) initiative is pushing toward mandatory e-invoicing for intra-community B2B transactions. Individual countries — Italy, France, Germany, Saudi Arabia, India — have their own e-invoicing standards and timelines.

Your billing platform needs to support multiple tax rates per jurisdiction, apply the correct tax treatment based on the customer's location and entity type, and generate invoices in formats that comply with local e-invoicing requirements. This gets complex quickly when a single fintech customer operates across 15 countries with different VAT rates, e-invoicing standards, and reporting obligations.

Multi-entity billing for fintech organizations

Fintech companies frequently operate through multiple legal entities across different jurisdictions — a holding company in one country, regulated entities in others, and processing entities in yet more. Each entity may need to issue its own invoices with distinct branding, tax registration numbers, bank accounts, and compliance settings.

Why multi-entity matters in fintech

Regulatory licensing often requires separate legal entities per jurisdiction. A fintech licensed in the EU under passporting rules still needs local entity presence for certain regulated activities. Each entity issues invoices under its own tax ID, in the local currency, complying with local invoicing standards. Intercompany billing between these entities adds another reconciliation layer.

Beyond regulatory requirements, multi-entity billing supports commercial flexibility. A fintech might bill European customers from its Dublin entity in EUR, US customers from its Delaware entity in USD, and Asian customers from its Singapore entity in SGD — all using the same underlying plans and pricing logic, but with entity-specific configurations for tax, currency, and compliance.

Billing entities — separate invoice-sender configurations that share underlying plans and metrics while maintaining distinct settings for timezone, locale, tax registration, and payment methods — are essential infrastructure for fintech companies operating across jurisdictions.

Payment orchestration and processor flexibility

Fintech companies have more complex payment processing requirements than typical SaaS businesses. They often need multiple payment processors simultaneously — not as a future consideration, but from day one.

Why single-processor lock-in is especially dangerous in fintech

In standard SaaS, payment processor lock-in means higher fees and limited payment methods. In fintech, it can mean regulatory non-compliance, inability to serve certain markets, and customer loss. Different regions require different payment rails: SEPA Direct Debit in Europe, ACH in the US, UPI in India, Pix in Brazil. Different customer segments prefer different methods: enterprise clients want bank transfers, mid-market wants cards, some jurisdictions mandate direct debit for recurring charges.

A billing platform that locks you into a single payment processor limits your market reach and increases concentration risk. If your sole processor experiences downtime or changes terms, your entire revenue collection stops. With 62% of global enterprises increasing their cross-border transaction volumes in 2025[4], the ability to route payments through the optimal processor per transaction type and geography is becoming a competitive requirement.

Payment processor agnosticism in practice

True payment processor flexibility means your billing platform integrates with multiple processors natively and allows you to assign different processors to different customers, geographies, or transaction types. A European customer pays via GoCardless SEPA Direct Debit, a US customer via Stripe ACH, and an Asian customer via Adyen with local payment methods — all managed from a single billing configuration.

This also extends to fallback routing. If a payment fails through one processor, the billing system should be able to retry through an alternative — improving collection rates without manual intervention. For recurring payment failures, a robust dunning management system becomes essential for recovering revenue across multiple payment rails.

Credits, wallets, and prepaid models in fintech

Prepaid credit systems are particularly prevalent in fintech for both commercial and regulatory reasons. Many fintech products require customers to maintain funded accounts or prepay for transaction capacity.

How fintech companies use credit systems

Payment platforms often require merchants to maintain a minimum balance to cover chargebacks and refunds. Lending platforms may require prepaid credit deposits as security against default exposure. API-based fintech services (identity verification, credit scoring, compliance screening) typically sell credits that are consumed per API call.

Each of these use cases requires wallet functionality with specific capabilities: real-time balance tracking and deduction, multiple top-up methods (fixed recurring, target balance, threshold-triggered), multi-currency wallet support, expiration management for credits with time-limited validity, and detailed transaction history for audit and reconciliation.

The billing platform should support configurable wallet top-up triggers — automatically adding credits when the balance falls below a threshold, on a fixed schedule, or to a target balance — so that customers never run out of capacity while maintaining predictable spend.

Data sovereignty and self-hosting for regulated fintech

Financial regulators increasingly require that transaction data, customer records, and billing information remain within specific jurisdictions. The EU's data localization requirements under GDPR, combined with sector-specific rules from financial regulators like the EBA and national competent authorities, make data sovereignty a hard constraint for many fintech companies.

Cloud-only billing platforms that process and store data in the vendor's infrastructure create a compliance gap. You're trusting the vendor's data residency claims, their sub-processor agreements, and their interpretation of what constitutes adequate data protection — all of which are subject to change and auditor scrutiny.

Self-hosted billing infrastructure eliminates this concern entirely. For a detailed analysis of self-hosted vs. cloud billing trade-offs including TCO calculations, see our deployment guide. When you deploy billing on your own infrastructure — whether on-premise, in a private cloud, or in a specific regional cloud deployment — you have full control over where data resides, who accesses it, and how it's protected. This is why open-source billing platforms like Lago are gaining traction in fintech — they offer the deployment flexibility of self-hosting with the feature completeness of a commercial platform, including multi-currency support, real-time event processing at over 1M events per second, eight charge models (including percentage and dynamic pricing critical for fintech), multi-entity billing, and native integrations with Stripe, Adyen, and GoCardless.

Building a fintech billing stack: practical architecture

A fintech billing architecture typically involves four layers working together.

The event ingestion layer captures transaction events from your core platform in real time. Every payment processed, loan disbursed, trade executed, or API call made generates a billing event with properties like transaction amount, currency, region, customer tier, and product type. These events must be ingested with sub-second latency and deduplicated to prevent double-billing.

The pricing engine applies the correct fee structure to each event based on the customer's contract, the transaction properties, and any volume-based tiers or commitments. In fintech, this often means percentage-based fees with per-transaction minimums and maximums, graduated tiers based on monthly volume, and customer-specific overrides for enterprise deals.

The invoicing layer aggregates processed events into invoices at the correct frequency (per-transaction, threshold-triggered, or periodic), in the correct currency, from the correct billing entity, with the correct tax treatment. Multi-currency reconciliation happens here, converting transaction-level fees in source currencies to billing-currency invoice amounts.

The payment and reconciliation layer handles collection through the appropriate payment processor, manages retries and dunning for failed payments, and reconciles settled amounts against invoiced amounts — accounting for currency conversion differences, processor fees, and timing variations.

What to evaluate in a fintech billing platform

When selecting billing infrastructure for a fintech company, evaluate these capabilities as non-negotiable requirements rather than nice-to-haves. Our billing platform comparison framework covers general evaluation criteria — below are the fintech-specific requirements:

Multi-currency support must go beyond simple conversion. You need per-customer billing currencies, multi-currency wallets, and full audit trails for every conversion. Percentage-based pricing with per-transaction adjustments is essential for payment processing, lending, and trading fee models. Real-time event ingestion at scale is critical — fintech transaction volumes can spike unpredictably, and your billing system must keep pace without batching delays. Multi-entity billing enables jurisdictional compliance by issuing invoices from the correct legal entity with the correct tax and regulatory settings. Payment processor flexibility prevents vendor lock-in and enables optimal payment routing by geography and transaction type. And self-hosting capability ensures you can meet data sovereignty requirements without compromise.

Conclusion

Fintech billing is not SaaS billing with a currency conversion layer. It's a fundamentally different infrastructure challenge driven by multi-currency complexity, real-time settlement requirements, cross-jurisdictional regulatory obligations, and the operational demands of processing financial transactions at scale.

The fintech companies that get billing right treat it as core financial infrastructure — as critical as their payment processing engine or their compliance systems. The ones that underestimate it spend their first few years building workarounds, their next year migrating, and their investors wondering why the engineering team never ships product features.

Citations

[1] Juniper Research, Cross-Border Payments Market 2025

[2] European Central Bank, PSD3 and Payment Initiation Services

[3] McKinsey, Global Payments Report 2025

[4] EY, How Banks Can Unlock New Value in Cross-Border Payments