Multi-currency analytics for fintech is the process of modelling, converting, and reporting financial data across multiple currencies in a consistent, auditable, and governance-ready way. Done well, it gives your finance, product, and leadership teams a single view of revenue, cost, and margin regardless of the currency a transaction settled in. Done badly — and it is done badly at the majority of growth-stage companies — it produces numbers that disagree with each other, FX losses that appear without explanation, and month-end closes that take days longer than they should.
If your company processes payments in more than two currencies, the odds are high that your financial reporting has a currency problem you have not fully diagnosed yet. This post explains exactly what breaks, why it breaks, and how to rebuild it properly on a modern data stack.
Why Multi-Currency Financial Reporting Breaks at Scale
The failure mode is almost always the same. A company launches in one market, denominating everything in a single base currency. The data model is simple: transactions come in, revenue is summed, done. Then they expand — a second market, a third PSP, a treasury account in euros, payouts in USD — and instead of rebuilding the data model, someone adds a conversion column to a spreadsheet.
We see this pattern repeatedly in our work with growth-stage fintechs. Finance teams must track payments in different currencies with fluctuating exchange rates, data arrives from multiple partners and platforms in different formats, and reconciliation is done manually when systems do not sync automatically. By the time a company reaches Series A, they are typically running four to eight currency pairs through a combination of a core ledger, one or two PSPs, a banking provider, and an accounting system — each of which applies FX rates at different points in time using different sources.
The result is a fundamental single-source-of-truth failure. Revenue reported in the BI tool does not match revenue in the accounting system. The accounting system does not match the ledger. The ledger does not match bank statements. Every figure is technically defensible, because every system applied a rate — just a different rate, at a different moment, from a different source.
Without consolidated reporting, companies may struggle to see their global cash position in real time — and that visibility gap has a real cost. In one capital reconciliation engagement, a discrepancy that had been hiding in exactly this kind of fragmented multi-currency setup turned out to represent a $25M gap — at market borrowing rates, that was costing over $6,000 per day.
📺 Watch: Risk Management and Analytics with Fintech #FintechFridays
The Three Specific Ways FX Logic Corrupts Your Data Models
Before you can fix a multi-currency data stack, you need to understand where the corruption actually lives. In our delivery experience, there are three failure patterns that account for the vast majority of the damage.
1. Point-in-time rate vs. period-average rate confusion
A transaction that settled on the 14th of March was converted using the spot rate on the 14th of March. Your monthly P&L, however, uses an average rate for March. These are legitimately different numbers and both are correct for their purpose — but if your dbt models do not make that distinction explicit, downstream dashboards will silently blend the two methodologies. A dashboard showing "monthly revenue in GBP" may be mixing spot-converted transactions with period-average-converted ones, and no one will notice until the CFO asks why this month's number doesn't reconcile with the management accounts.
2. FX rate sourced at ingestion vs. at query time
Some teams store transactions in their raw settlement currency and apply FX conversion at query time using a live or recently-loaded rate table. Others convert at ingestion and store the converted value. Both approaches have valid use cases, but mixing them — which happens organically when different engineers build different parts of the pipeline — produces a model where the same transaction can return different values depending on which table you query it from. We have seen this produce revenue discrepancies of three to five percent across a portfolio of markets, which at Series B scale is material.
3. Missing or stale FX rate data
FX rate pipelines are brittle. A rate feed that fails silently — returning NULL, or returning yesterday's rate because no one built an alerting layer — will propagate wrong numbers through every downstream model without raising an error. Finance teams often discover this not through monitoring but through a month-end reconciliation that does not close. By that point, weeks of data may be affected.
A large proportion of cross-border payment friction comes from operational issues: reconciliation, dispute handling, manual processes, and a lack of payment-level identifiers. The analytics layer inherits all of that friction — and amplifies it.
How to Model Multi-Currency Data Correctly in a Modern Data Stack
The right architecture for multi-currency analytics is not complicated, but it requires discipline. Here is the approach we implement for clients on BigQuery and dbt, which is the stack we most commonly deliver for growth-stage fintechs.
Store in settlement currency, convert in the semantic layer
The golden rule: never overwrite the original transaction currency. Store every transaction in its native settlement currency in your raw and staging layers. Apply FX conversion only in your mart or reporting layer, where the conversion logic is explicit, versioned, and tested. This means your source-of-truth data is always recoverable, and you can restate historical figures if you change the rate methodology — which you will, at least once.
Build a dedicated FX rate table as a first-class data asset
Your FX rate data deserves its own ingestion pipeline, its own dbt model with freshness tests, and its own alerting. We typically build a dim_exchange_rates table that holds daily rates (or intraday rates where the business requires it), sourced from a primary provider with a fallback, and tested on every load for nulls, staleness, and out-of-range values. A rate that is more than 48 hours old for a major currency pair should trigger an alert before it reaches any downstream model.
Make conversion methodology a documented model property
Every dbt model that performs a currency conversion should document in its schema YAML which rate methodology it uses — spot, period-average, or month-end close — and why. This is not bureaucracy. It is the difference between a finance team that trusts your numbers and one that maintains a parallel spreadsheet to check them. If you are building for investor due diligence readiness, documented conversion methodology is exactly the kind of thing that gets scrutinised.
Test the conversion pipeline, not just the source data
Most dbt testing strategies focus on source data quality. Multi-currency pipelines need an additional layer: tests that validate the conversion logic itself. That means testing that every transaction currency has a matching rate in your rate table, that converted values are within a plausible range, and that the sum of converted revenue reconciles to within a defined tolerance against the accounting system output. If you are not already following a rigorous dbt testing approach, our post on dbt testing strategy for startups covers the full framework.
If you are currently working through how to implement this kind of architecture in your own stack, explore how Fintel Analytics approaches this — we design and deliver exactly this kind of multi-currency data engineering for growth-stage fintechs and payments businesses globally.
What a Production-Ready Multi-Currency Analytics Stack Looks Like
A working multi-currency analytics stack has five layers, each with a clear responsibility.
Layer 1 — Raw ingestion Transactions land from PSPs, banking providers, and ledger systems in their native format and native currency. No transformation at this stage. Every record retains its original settlement currency code, the provider-reported FX rate (if one was applied), and the settlement timestamp.
Layer 2 — Staging models
Light transformation: field renaming, type casting, deduplication. Still in native currency. The staging layer is where you standardise currency codes across providers — because one PSP will send GBP, another will send 826, and your model needs to handle both.
Layer 3 — FX rate dimension A separate, independently-tested table of daily (or intraday) exchange rates for every currency pair your business operates in. Built from a reliable rate feed. Monitored for freshness. This is the single source of truth for all FX conversion across the entire stack.
Layer 4 — Mart models
This is where conversion happens. Your fct_transactions mart joins to dim_exchange_rates using the appropriate rate date logic — typically the transaction settlement date for operational reporting, and the period-average rate for management P&L. The conversion logic is explicit, documented, and version-controlled in dbt.
Layer 5 — Semantic layer and BI Your BI tool — whether Holistics, Looker, or another platform — exposes pre-converted metrics to business users. Crucially, the currency context is part of the metric definition, not something applied ad-hoc in a dashboard filter. "Revenue" is always "Revenue in GBP at period-average rate" — not a raw figure that a user can accidentally compare to a spot-converted figure in another report.
This architecture is not an over-engineering exercise. It is the minimum viable design for a company operating in more than two currencies that wants financial reporting it can stand behind.
The Real Cost of Getting This Wrong
Companies are expected to execute around 16.3 billion cross-border B2B transactions in 2025, according to industry projections. For the fintechs and payments platforms building the infrastructure to process those flows, the analytics layer sitting on top of that volume is not optional overhead — it is the system through which every commercial decision gets made.
We have seen the cost of a broken multi-currency stack show up in several concrete ways:
-
FX loss misattribution: A payments company was reporting strong gross margin improvement quarter-on-quarter. When we rebuilt their currency models, the improvement was almost entirely explained by a favourable GBP/USD move that had been baked invisibly into their base currency conversion. The underlying unit economics had not improved at all.
-
Delayed closes: A Series A fintech with operations in six markets was spending three to four days at every month-end manually reconciling their management accounts against BI output because the FX rates in each system differed. Rebuilding the conversion layer in dbt and aligning it with the accounting system's methodology cut that to under half a day.
-
Investor reporting risk: Smaller cross-border transactions — marketplace payouts, SME invoices, subscription billing, SaaS fees — are exactly the flows where merchants feel the pain of unpredictable FX spreads and manual reconciliation overhead. At due diligence, a financial model that cannot be reconciled to the data warehouse is a red flag that costs founders time, credibility, and occasionally the deal.
ISO 20022 is the new data standard for payments, and as adoption is expected to cover 80% of high-value clearing and settlement by the end of 2025, richer, more structured data fields will enable institutions to share higher-quality payments information — significantly reducing manual intervention. That richer data will only deliver its value if the analytics layer on the receiving end is built to consume it properly.
When Should You Prioritise Rebuilding Your Multi-Currency Stack?
The honest answer: earlier than most companies do. The trigger most teams wait for — "when the numbers start disagreeing" — is already too late, because by that point you are dealing with historical data that may need restating.
The right trigger points are:
Pre-expansion: Before you launch into a second or third currency market, design the currency model you will need at scale, not the one that works for your first market. Adding currency support to an existing model costs a fraction of what it costs to rebuild a broken one.
At Series A data stack build: If you are doing a first-principles data warehouse build as you approach or close your Series A, multi-currency should be a first-class design requirement — not a feature added in a later sprint.
When finance stops trusting the dashboards: This is the most common trigger we encounter. A CFO or Head of Finance starts maintaining a parallel spreadsheet because "the dashboard numbers don't match the accounts." That is not a trust problem. It is an architecture problem. And it is fixable.
Before hiring a finance team: Once you have a Head of Finance or a full finance function, they will immediately need reporting that reconciles to the accounting system. If the data stack cannot deliver that on day one, you have a credibility problem with a team that will directly influence how leadership perceives the entire analytics investment.
If your company is at any of these inflection points, the unit economics analytics framework we have written about covers the broader metrics foundation — multi-currency modelling is a critical prerequisite for any unit economics analysis that spans markets.
Frequently Asked Questions
Q: What is multi-currency analytics?
A: Multi-currency analytics is the practice of collecting, modelling, and reporting financial data that spans multiple currencies in a consistent and auditable way. It involves storing transactions in their native settlement currency, maintaining a reliable FX rate data asset, and applying conversion logic explicitly within the data model — so that every metric has a documented, reproducible currency context.
Q: How should FX rates be stored in a data warehouse for financial reporting?
A: FX rates should be stored in a dedicated dimension table, loaded via a monitored pipeline from a reliable rate provider, and tested for freshness and completeness on every load. The table should contain daily rates at minimum, with intraday granularity for businesses that need real-time P&L. All downstream dbt models performing currency conversion should reference this single table, ensuring consistency across every report and dashboard.
Q: Should you store transactions in a base currency or the original settlement currency?
A: Always store in the original settlement currency at the raw and staging layers. Converting at ingestion destroys information — you can never recover the original settlement currency value, and you cannot restate historical figures if your rate methodology changes. Apply FX conversion only in mart models or the semantic layer, where the logic is versioned, documented, and testable.
Q: Why do different dashboards show different revenue numbers for multi-currency businesses?
A: This almost always traces back to inconsistent FX rate application. Different reports may be using spot rates vs. period-average rates, pulling rates from different timestamps, or sourcing rates from different providers. The fix is to centralise FX logic in a single dbt conversion layer referenced by all downstream models, and to define currency context as a property of each metric in the semantic layer — not as a filter applied ad-hoc in individual dashboards.
Q: How do dbt and BigQuery handle multi-currency financial analytics?
A: BigQuery stores all data in a schema-agnostic way — currency code and amount are just columns. The multi-currency logic lives in dbt: staging models preserve native currency, a dim_exchange_rates model holds rate data, and mart models perform the conversion join using documented rate methodology. BigQuery's support for parameterised queries and date-partitioned tables makes it well-suited to the kind of date-spine joins required for period-average rate calculations at scale.
Building reliable multi-currency analytics is not a nice-to-have for growth-stage fintechs and payments businesses — it is the foundation on which every financial metric, every investor report, and every cross-market commercial decision depends. At Fintel Analytics, we have rebuilt multi-currency data stacks for payments companies, global SaaS businesses, and cross-border platforms — from the FX rate pipeline through to the semantic layer definitions that finance teams can finally trust. If your dashboards and your accounts are telling different stories about the same revenue, that is a solvable engineering problem, and fixing it pays back in time saved, decisions made on correct data, and investor confidence that is very hard to put a ceiling on.