How to test a neobank multi-currency account

Neobank multi-currency account testing checks that an account can hold, receive, spend and convert funds in several currencies while keeping each currency's balance, transaction history and fees accurate. It verifies the customer journey and the underlying ledger, including exchange-rate selection, rounding, transaction state changes, integrations and recovery from failures.

Define the account and conversion rules

First establish how the product represents currencies. Some neobanks maintain a separate balance for each currency; others hold funds in a base currency and display estimates in other currencies. Test expectations depend on that model. A displayed valuation in another currency should not be treated as spendable funds unless the product converts and posts an actual transaction.

Record the supported currencies, currency precision, conversion direction, rate source, rate timestamp, quote expiry, fee rules and rounding method. Confirm whether a conversion debits a fee separately or includes it in the converted amount. These rules may differ by channel or transaction type, so use approved product requirements as the test oracle.

Prepare isolated test accounts and deterministic rate-provider responses. Include currencies with different minor-unit precision where supported. Keep the rate, fee, customer configuration and test time fixed for repeatable results. A rate-provider outage, stale quote or mismatch between the application and ledger can otherwise make a test fail for reasons unrelated to the behaviour under test.

Validate balances and transaction postings

For each operation, check the currency-specific ledger balance, available balance, transaction status and customer-visible history. Verify both sides of a conversion and any fee postings. The ledger entries should balance according to the neobank's posting model, and the application should display values in the correct currency with the configured precision.

Exercise deposits, card purchases, transfers and conversions in each supported currency. Check insufficient funds, currency restrictions, account limits and pending transactions. For card authorisations, distinguish a hold from a settled debit: available balance may change before the ledger balance does. Confirm that settlement, reversal or expiry updates the relevant balances once, without leaving a duplicate debit or stranded hold.

Test rounding at the point where the product specifies it, such as the converted amount or fee. Avoid assuming every currency uses two decimal places. Compare the posted result with an independently calculated expected value using the configured rate and rounding rule. A display-only conversion should also be checked against its stated rate and timestamp, without changing the account ledger.

Test rates, fees and failure handling

Cover the rate-selection rules with valid, expired and unavailable quotes. Verify that the customer sees the rate, fee and final amount before confirming a conversion when the journey requires a quote. After confirmation, check that the transaction uses the accepted quote rather than a later rate. Confirm the outcome when the quote expires before submission, the provider times out, or the provider returns an invalid response.

Check retries and duplicate submissions. A repeated request with the same idempotency key should not create an additional conversion or fee. If a downstream service fails after one side of a conversion has posted, verify that the transaction completes safely or follows the defined reversal and recovery process. Inspect the transaction history, ledger and reconciliation output for consistent status and amounts.

Include cross-application checks where the customer journey spans the mobile app, core banking platform, card processor or payment provider. Compare transaction identifiers, currencies, amounts and statuses across those systems. Environment drift, such as different currency configuration or rate-provider behaviour in test and staging, can produce misleading results, so record the configuration used for each run.

Worked example

Assume a test product converts GBP to EUR at a fixed rate of 1.170000. Its configured rule deducts a GBP 1 fee from a GBP 100 conversion before applying the rate. The expected target credit is EUR 115.83: GBP 99 multiplied by 1.170000. Verify a GBP 100 total debit, an EUR 115.83 credit, the fee entry, the final balances and the customer-visible transaction record. If the conversion is submitted twice with the same idempotency key, verify that the ledger still contains only one conversion.

Run this case through the user interface and, where available, the relevant application programming interface (API) or ledger query. Capture the request, accepted quote, response, transaction identifier and balance snapshots. A passing screen assertion alone does not prove that the ledger and downstream records agree.

How to judge test coverage

Map each requirement to at least one positive case and relevant boundary or failure cases. Prioritise conversion posting, balance accuracy, fees, duplicate prevention and recovery paths because defects can affect customer funds. Include regression checks after changes to exchange-rate providers, currency metadata, fee configuration or ledger posting rules. For related scenarios, see [Multi-currency account testing] and [Banking rounding and precision testing].