A virtual IBAN provider gives a platform the ability to issue account numbers to customers, sub-merchants or business units without opening a new bank account for each one. That part is well understood. What gets less attention is what happens after go-live, when real payments start arriving through real payment schemes and the platform's own systems have to make sense of them. Most of the problems platforms run into with virtual IBANs are not about the concept. They are about integration decisions made early, before anyone had seen live traffic.
Below are five mistakes that recur across platforms building on virtual IBAN infrastructure, and what tends to fix them.
Mistake one: treating GBP and EUR accounts as the same shape
A EUR virtual IBAN and a GBP collection account are not structurally identical, even when a single BaaS provider issues both. A GBP account typically presents as a sort code and account number pair, because UK domestic schemes route on that basis. A EUR IBAN is a single string that already encodes the country code, bank identifier and account number, because SEPA routes on the IBAN itself.
Platforms that hard-code a single field format for "the account number" run into trouble the moment they add a second currency. Payment instructions get rejected, or worse, silently misrouted, because the field mapping assumed one format everywhere. The fix is unglamorous: store the raw identifiers separately (sort code, account number, IBAN, BIC) rather than concatenating them into one display string early in the data model, and only format for display at the point the user sees it.
Mistake two: assuming every incoming payment behaves the same way
Not every payment lands on a virtual IBAN the same way. A domestic transfer through Faster Payments or SEPA Credit Transfer typically settles same day or faster, and arrives with clean, structured reference data. A cross-border payment routed through SWIFT correspondent banking behaves differently. It can take longer, the reference field may be truncated or reformatted by an intermediary bank, and the sender's name may not match what the platform expects.
Platforms that build their matching logic around one rail's behaviour often see a spike in unmatched payments as soon as international customers start paying in. The practical response is to design reconciliation logic that does not assume a fixed reference format, and to have a manual review queue for payments that arrive without a clean match, rather than treating every mismatch as an error state that blocks the transaction.
Mistake three: not checking what sits behind the provider's scheme access
A virtual IBAN provider does not necessarily hold its own membership of every scheme it advertises. Some connect to Faster Payments, SEPA or SWIFT directly; others route through a sponsoring bank or a settlement partner. This is not a red flag in itself, but it does affect what a platform can promise its own customers.
Indirect access can mean an extra hop in the payment chain, which affects typical settlement timing and how quickly a failed payment gets reported back. Before committing to an integration, it is worth asking a provider plainly which schemes they hold membership of directly, and which are accessed through a third party. That answer should shape the platform's own service expectations, rather than being discovered later through support tickets.
Mistake four: mixing client money with operational balances
Platforms that use virtual IBANs to collect funds on behalf of others, such as marketplace payouts to sellers or funds held for customers, need a clear separation between client money accounts and the platform's own operating accounts. This is not just an accounting preference. Regulatory safeguarding requirements in the UK and equivalent EU rules on client funds depend on being able to demonstrate, at any point, exactly whose money sits where.
A common integration mistake is allowing virtual IBANs issued for customer funds to feed into the same ledger structure as the platform's fee income or working capital, on the assumption that reconciliation will sort it out later. It rarely does cleanly. The safer pattern is to design the ledger separation before the first virtual IBAN goes live, not after volume makes it painful to unpick.
Mistake five: skipping payee verification because the account "looks right"
A virtual IBAN can be issued correctly and still receive a payment from the wrong sender, or send a payout to the wrong recipient, if the platform has not built in a name-check step. Confirmation of Payee in the UK and Verification of Payee under SEPA exist precisely because an account number or IBAN alone does not confirm who holds it.
Platforms sometimes treat this as optional, particularly for marketplace payouts where the recipient was onboarded through the platform's own KYC process. But onboarding checks and payee-matching checks answer different questions: one confirms who the customer is, the other confirms that the account details entered for a payment actually belong to that customer at the point of payment. Building both in from the start avoids a category of misdirected payment that is expensive and slow to unwind after the fact.
Designing the integration properly
Most of these mistakes share a root cause: treating the virtual IBAN as a static object rather than an active participant in several different payment schemes, each with its own rules. A sensible integration approach starts with a mapping exercise: which currencies, which schemes, which reference formats, which settlement expectations, before a line of production code is written.
It is also worth testing against realistic failure modes in sandbox, not just the happy path. Truncated references, delayed SWIFT payments, mismatched payee names and split currency flows are the conditions that reveal whether an integration was built for one rail or built properly for several. Platforms working with an API banking platform should expect to spend meaningful time on this mapping and testing phase; it is where most of the later support burden gets designed out, or in.