Multicurrency Banking by Design: Why FX Revaluation Cannot Be an Afterthought 

An EMI or PSP that holds client funds in euros, sterling, and US dollars, receiving income or incurring expenses in foreign currencies, is not operating a simple ledger with a currency flag attached to each balance. It is operating three distinct financial positions, each exposed to exchange rate movements that affect the real value of what it owes its clients, what it holds at its correspondents, and what it reports to regulators. It is getting even more complicated when, throughout the course of operations, PSP is encountering open foreign currency positions. The architectural question is not whether a core multicurrency banking platform can display balances in multiple currencies. Most can. 

The question is whether it handles multiple currencies as a structural design constraint, one that shapes how entries are posted, how positions are revalued, and how the ledger reconciles against external statements, or whether it treats currencies as a configuration option layered above a single-currency architecture built for a different world.

The distinction matters most at the intersection of accounting standards and operational risk. Under IAS 21, the IFRS standard governing the effects of changes in foreign exchange rates, monetary items denominated in foreign currencies must be retranslated at the closing rate at each reporting date, with exchange differences recognised in profit or loss, which may be realised (on open currency positions) or unrealised on regular holdings of foreign currencies. This is not a discretionary accounting policy. It is a mandatory standard with direct architectural implications: FX revaluation must happen somewhere in the core banking platform, and where it happens determines whether the result is auditable, reconcilable, and regulatorily defensible.

This article examines what multicurrency banking actually requires from a core banking platform, why FX revaluation cannot be an afterthought, and what the operational and compliance consequences of getting the architecture wrong look like in practice for any EMI or PSP holding positions in more than one currency.

Key Takeaways:

• Multicurrency banking requires architecture, not just configuration: FX revaluation must be recorded as dated, rate-attributed entries that exist in the institution’s books independently of reporting, so a report can include or exclude them but never create them.
• IAS 21 is not discretionary: foreign currency monetary items must be retranslated at the closing rate at each reporting date, with exchange differences recognised in profit or loss.
• Reporting-layer revaluation produces two versions of the truth: the ledger balance and the reported balance will permanently diverge by the amount of the FX revaluation.
• Safeguarding is affected: for EMIs holding client funds in multiple currencies, a reconciliation run on nominal amounts will conceal functional-currency shortfalls as exchange rates move.
• DORA requires a recoverable audit trail: under the Digital Operational Resilience Act, FX revaluation history must exist in the core ledger, not only in reports.

Part One: What Multicurrency Banking Actually Requires From a Core Platform

What does it mean for a platform to be multicurrency by design?

Multicurrency banking by design means that currency is a first-class dimension of the ledger architecture, not an attribute attached to individual transactions after the fact. In a platform built with multicurrency banking as a foundational constraint, every account has a denomination currency, every transaction records both its original currency amount and its functional-currency equivalent at the applicable rate, a new entry attributed to a date, a rate and the account revalued, rather than a silent adjustment to an existing balance, and every reconciliation can be performed in the functional currency against the same underlying record.

In a platform where multicurrency banking has been bolted on to a single-currency ledger, the reality is typically different. Transaction amounts may be stored in a single currency field with a rate applied at query time. Revaluation may happen only at report generation, with the result written to a separate data structure rather than posted to the ledger. Reconciliation may require joining tables that were not designed to be joined. The surface presentation, account balances displayed in multiple currencies, may look identical in both architectures.

The difference surfaces when a rate is applied inconsistently, when a revaluation is missing from one balance but not another, or when a regulator asks for the FX gain or loss position at a specific date for which you have not performed a revaluation. Daily FX revaluation is especially critical for EMIs and other PSPs that operate multicurrency customer accounts and need to conduct daily safeguarding reconciliations.

What is the difference between multicurrency support and multicurrency architecture?

Multicurrency support is the ability to accept, hold, and display balances in more than one currency. Almost every modern payment platform provides this. Multicurrency banking architecture is something more specific: it is the set of structural decisions that determine how currency exposure is tracked, how exchange rate changes affect the ledger, and how the institution can prove, at any point in time, that its foreign currency positions are accurately stated and correctly reconcilable.

The difference becomes visible in three operational scenarios that every multicurrency banking institution or a PSP will eventually face. First, at period-end financial reporting, when the functional-currency equivalent of every foreign currency balance must be stated at the closing rate and the resulting exchange differences recognised in the profit and loss account.

Second, during a regulatory inspection, when a competent authority requests the open currency position and the basis on which it has been calculated. Third, during a client dispute, when a client challenges the exchange rate applied to a specific transaction and the institution must demonstrate, from its own records, what rate was used and how it was applied. In a genuine multicurrency banking architecture, all three are answered directly from the ledger. In a support layer above a single-currency core, they require reconstruction from logs and reporting extracts that may not agree with each other.

How does currency exposure accumulate in a platform not built for multicurrency banking?

Currency exposure accumulates in a platform not designed for multicurrency banking in a specific and predictable pattern. The institution adds a second currency, adds a configuration option to hold balances in it, and the ledger stores the nominal balance with a currency code alongside it. When a balance needs to be expressed in the functional currency, a rate is applied at the point of query. 

As the multicurrency banking book grows and rate volatility increases, three problems emerge: different parts of the platform apply rates from different sources, producing inconsistent functional-currency equivalents for the same balance; the accumulated FX gain or loss may not be calculated between reporting dates, meaning the institution does not know its real open currency position; and when FX revaluation is eventually performed, the resulting entries may not map cleanly back to the accounts they relate to, requiring manual allocation work that does not scale.

Part Two: Why FX Revaluation Must Be a Recorded Entry, Not a Reporting Calculation

What is FX revaluation and why does it matter for an EMI or PSP?

FX revaluation is the process of restating the functional-currency equivalent of foreign currency monetary items at a new exchange rate, typically the rate prevailing at the balance sheet date, and recognising the resulting difference as an exchange gain or loss. For an EMI or PSP operating a multicurrency banking book, FX revaluation applies to client account balances, safeguarding, segregated, and nostro positions, and any outstanding foreign currency payment obligations or receivables.

The significance of FX revaluation for a regulated payment or e-money institution is not primarily accounting: it is operational and prudential. A client account denominated in US dollars has a nominal USD balance that never changes between transactions. But its EUR functional-currency equivalent, the amount the institution owes in euros if required to repay the client today, changes every time the EUR/USD rate moves. An institution that does not perform FX revaluation is understating or overstating its liability to that client in functional-currency terms, which directly affects its safeguarding position, its own funds calculation, and its ability to produce accurate regulatory reports, especially if there is an open foreign currency position on the balances owed to the clients.

What goes wrong when FX revaluation runs only at the reporting layer?

When FX revaluation exists only as a calculation in the reporting layer, it produces a result that is used but not recorded. The ledger continues to show foreign currency balances at their historical functional-currency equivalents. The report shows them at the current rate. The FX gain or loss exists in the report but not in the ledger, which means the ledger and the report are permanently out of agreement by exactly the amount of the unrealised FX position. 

This gap fluctuates as rates move, and anyone reconciling the ledger against the report must either ignore it, producing a false reconciliation, or adjust for it manually across every foreign currency account. In a multicurrency banking environment with hundreds of thousands of accounts across multiple currencies, this manual adjustment is not a sustainable control.

The more serious problem arises during a regulatory review or an audit. A regulator asking for the institution’s FX gain or loss for a given period will receive a number from the reporting layer. If that number is not traceable to a corresponding recorded entry, the institution cannot demonstrate that the gain or loss was actually recognised in its accounts, which is precisely what IAS 21 requires. In a multicurrency banking operation, FX revaluation must be a ledger event.

What does IAS 21 require, and what does it mean architecturally for a multicurrency banking platform?

IAS 21, the International Financial Reporting Standard on the effects of changes in foreign exchange rates, requires that at each reporting date or even daily (to satisfy prudential regulatory requirements) foreign currency monetary items are translated using the closing rate, and that exchange differences arising on settlement or translation are recognised in profit or loss in the period in which they arise. The standard applies to all entities reporting under IFRS, which includes the majority of licensed payment institutions and EMIs in the EU and UK and many other types of PSPs worldwide.

The architectural implication for a multicurrency banking platform is direct: exchange differences must be recognised, which means they must appear in the institution’s financial records as an identified amount for an identified period. They cannot be the difference between two numbers in a report. 

For a core banking ledger to support IAS 21 compliance, FX revaluation must post as a recorded entry: a debit to the FX revaluation account and a credit to the exchange gain or loss account, attributable to a specific date, a specific functional currency rate source, and the specific accounts revalued. This is the design constraint that separates a multicurrency banking platform capable of producing IFRS-compliant financial statements for any given day from one that requires its finance team to produce parallel adjusting entries outside the ledger at every period close.

Part Three: Compliance, Safeguarding, and Reconciliation in a Multicurrency Environment

How does a multicurrency banking position interact with safeguarding obligations?

For an EMI, safeguarding obligations require that the institution holds funds equivalent to its outstanding electronic money liabilities in a designated safeguarding account, segregated from operational funds, and reconciled daily. In a multicurrency banking context, this reconciliation must account for the functional-currency equivalent of foreign currency client balances, not just their nominal amounts. 

If an EMI has USD 500,000 on client funds liabilities and EUR 438,000 in its safeguarding account at a EUR/USD rate of 1.14, the safeguarding position is short by approximately EUR 596.49. The institution may be entirely unaware of this shortfall if its safeguarding reconciliation runs on nominal amounts rather than revalued functional-currency equivalents.

The FCA’s updated safeguarding requirements under PS25/12, which entered into force in May 2026, require firms to demonstrate that their reconciliation processes can identify and resolve discrepancies daily. In a multicurrency banking environment, this necessitates intraday FX revaluation capability, not just period-end adjustments. An institution whose multicurrency banking reconciliation runs on nominal amounts is not compliant with this standard.

What does DORA require from institutions holding multicurrency positions?

The EU’s Digital Operational Resilience Act, in force since January 2025, requires in-scope payment and electronic money institutions to maintain the integrity of their financial data as a component of operational resilience, not merely a bookkeeping concern. Under DORA’s ICT risk management requirements, institutions must be able to recover and reconstruct their financial records after a disruption and demonstrate the accuracy and completeness of their data at any point in time.

For a multicurrency banking operation, this means the FX revaluation history must exist in the system, not only in report outputs. If an institution’s reporting tool is unavailable and a regulator requires the current open currency position or capital adequacy report for a certain past date, the institution must be able to produce that position from its core records. This is only possible if FX revaluation entries have been posted to the ledger rather than calculated on demand from live rate data. An institution whose multicurrency banking position exists only in its reporting layer has a DORA gap in exactly this area.

How does a fragmented multicurrency banking architecture break reconciliation?

Reconciliation in a multicurrency banking environment involves matching three sets of records: the ledger balances in each currency, the correspondent bank statements in each currency, and the functional-currency equivalents used for regulatory and financial reporting. 

If all three are produced from the same underlying ledger using the same rates at the same moments, reconciliation is a clean comparison. If any one of them runs from a different data source or applies rates differently, an additional step is required to explain the gap before actual matching can begin.

The fragmentation that breaks multicurrency banking reconciliation most commonly occurs at the rate application point. The ledger may use a functional currency rate obtained at the time of transaction booking. The correspondent statement provides a rate at the time of correspondent processing. The reporting layer that sits elsewhere in a third-party analytics and reporting software uses a closing rate from a market data feed. Three sources, three different rates, and a reconciliation that cannot fully close without manual bridging entries. The larger the multicurrency banking book and the more volatile the rates, the larger these bridging entries become and the more operational resources they consume to explain and authorise.

Baseella’s Approach to Multicurrency Banking

The requirements described throughout this article – FX revaluation as a native ledger event, consistent rate application across all views of a foreign currency balance, daily reconciliation capable of identifying functional-currency shortfalls in safeguarding positions, and an auditable FX gain and loss history traceable to specific ledger entries – are not optional enhancements to a multicurrency banking platform. They are the baseline architectural requirements for any licensed payment institution holding client funds in more than one currency.

Baseella’s core platform treats multicurrency banking as a foundational design constraint. Every account is denominated in a transaction currency, every balance is maintained natively in that currency, and FX revaluation posts as a double-entry revaluation ledger event attributed to a specific date, a specific rate, and the specific accounts revalued. The resulting FX gain or loss is directly traceable in the ledger, satisfying both IAS 21’s recognition requirements and DORA’s data integrity expectations without requiring a separate reconciliation step between the ledger and the report.

For EMIs and PSPs evaluating their own multicurrency banking architecture, the diagnostic questions are straightforward: does your platform post FX revaluation as a ledger entry or calculate it only at report time; does your daily safeguarding reconciliation run on functional-currency equivalents or nominal amounts; and can you produce your open currency position from your core ledger without access to your reporting tool. The answers determine whether your multicurrency banking infrastructure is designed for the scale and regulatory environment of a licensed payment institution, or whether it is an extension of a single-currency architecture that was not built with currency exposure in mind.

F.A.Q.

• What is multicurrency banking in the context of a payment institution?

Multicurrency banking is the capability of a licensed payment institution to hold, process, and report financial positions in more than one currency, maintaining accurate records of both the nominal balance in each transaction currency and the functional-currency equivalent required for financial reporting and regulatory compliance.

• What is FX revaluation and is it required under IFRS?

FX revaluation is the process of restating foreign currency monetary items at the closing exchange rate at each reporting date and recognising the resulting exchange difference in profit or loss. It is required under IAS 21, the IFRS standard governing the effects of changes in foreign exchange rates, which applies to licensed payment institutions and EMIs reporting under IFRS in the EU and UK.

• What is the difference between multicurrency support and multicurrency architecture?

Multicurrency support is the ability to display and transact in more than one currency. Multicurrency banking architecture is the structural design that ensures FX revaluation posts to the ledger as an attributed entry, foreign currency positions reconcile in both transaction and functional currency from a single source of record, and the institution can demonstrate its open currency position at any point in time without reconstructing it from external reports.

• How does multicurrency banking affect an EMI’s safeguarding obligations?

An EMI’s safeguarding reconciliation must account for the functional-currency equivalent of foreign currency client balances, not only their nominal amounts. A safeguarding position calculated on nominal balances will appear correct in nominal terms while concealing a shortfall in functional-currency terms whenever exchange rates move, which is a breach of safeguarding requirements under the FCA’s PS25/12 and equivalent EU frameworks.

• What does DORA require from institutions holding multicurrency positions?

Under the Digital Operational Resilience Act, payment institutions must maintain the integrity of their financial data as part of their ICT risk management framework. For a multicurrency banking operation, this means FX revaluation history must be preserved in the core ledger rather than existing only as report outputs, so that the institution can reconstruct its currency position from primary records for any given day after a disruption or during a regulatory review.

---

Baseella is a core banking and payments platform built for electronic money institutions, payment institutions, neobanks, money service businesses, and crypto-asset service providers. To see how Baseella handles multicurrency banking, native FX revaluation, and safeguarding reconciliation as core platform capabilities, visit Baseella online or schedule a demo.