A virtual IBAN looks identical whichever provider issues it: a string of characters that routes a payment to a specific ledger entry inside a bank or e-money institution. What differs, and what rarely gets asked in procurement conversations, is how that provider actually gets the number connected to the payment schemes that move money. There are two broad models. Understanding which one sits behind a proposed integration changes how you think about settlement speed, resilience, and what happens when something goes wrong.

Two routes into the payment system

The first route is direct membership. A bank or authorised e-money institution holds its own account with the relevant scheme operator or central infrastructure, whether that is Bacs and Faster Payments in the UK, SEPA in the eurozone, or a correspondent relationship for cross-border payments SWIFT settlement. It carries a sort code and account number range, or an IBAN prefix, issued to it directly. Virtual IBANs generated by this institution sit on its own ledger, and payments land without passing through an intermediary's infrastructure.

The second route is aggregation, sometimes called an indirect or correspondent model. A fintech banking infrastructure provider builds a layer on top of one or more institutions that do hold direct membership. It issues virtual IBANs from its own range, but every payment ultimately travels through its underlying banking partner's rails. The provider's API banking platform abstracts this away from the end customer, but the mechanics of settlement, cut-off times, and failure handling are inherited from whichever bank sits underneath.

What direct membership changes in practice

Direct scheme membership means fewer hops between a payment instruction and final settlement. There is no intermediary bank to reconcile against, no additional layer that can introduce delay or a mismatched status code. For platforms running high-volume payment reconciliation, this generally means cleaner data: the entity issuing the virtual IBAN is the same entity that sees the raw scheme message, so metadata like the payer's name, reference, and originating sort code and account number arrives without translation.

Direct membership also tends to mean more control over operational detail: cut-off times, return handling, and how quickly a GBP collection account reflects an incoming Faster Payment. But it comes with a narrower footprint. A single institution's direct memberships rarely cover every scheme a platform needs. A firm with direct access to Faster Payments and SEPA may still rely on a correspondent bank for US dollar wires or emerging market corridors, because building direct membership into every scheme globally is neither practical nor proportionate for most institutions.

What the aggregated model actually gives you

An aggregated provider trades some of that directness for breadth. By sitting on top of several banking partners, it can offer EUR IBAN issuance, GBP collection accounts, and multi-currency reach from a single API, without each currency requiring a separate banking relationship on the platform's side. For a fintech building fast, this collapses months of individual bank onboarding into one integration.

The trade-off is that the provider's reliability is bounded by its weakest underlying banking relationship. If the bank behind its EUR rail changes its cut-off times, restricts a corridor, or experiences an outage, that constraint passes through to every customer using virtual IBANs issued against that rail, regardless of how well-built the API layer is. Any BaaS provider using this model should be able to state plainly which institutions sit behind each currency and rail, because that detail determines what actually happens during a disruption.

Client money and the safeguarding question

The model also affects how client money accounts are structured. Where a provider holds direct membership and its own regulatory permissions, it can typically hold safeguarded or segregated client funds on its own balance sheet, subject to the applicable safeguarding rules. Where a provider is itself relying on an aggregated arrangement, the actual safeguarding account sits with its underlying bank, and the provider's role is to instruct movements against it. This doesn't necessarily make one model less safe than the other, but it changes where accountability sits if a dispute arises over fund segregation, and it is worth establishing clearly before integration begins rather than after.

Cross-border reach and correspondent chains

For payments leaving the UK or EU entirely, both models usually end up relying on a correspondent banking chain for SWIFT settlement, because very few institutions hold direct membership of every national clearing system worldwide. The practical question isn't whether correspondent banking is involved, it almost always is somewhere in the chain, but how many links exist and how transparent the provider is about intermediary deductions, typical settlement windows, and where a payment can get stuck for manual review.

Questions worth asking before choosing

When comparing providers, it helps to ask directly rather than infer from marketing language:

  • Which schemes does the provider hold direct membership of, and which are accessed through a partner bank?
  • For each currency offered, which institution actually holds the underlying account?
  • How are client funds segregated, and whose name is on the safeguarding account?
  • What happens operationally if an underlying banking partner changes terms or is replaced?
  • Does the reporting API expose the original scheme message data, or a summarised version?

Neither model is universally correct. A platform that needs deep GBP and EUR volume with tight reconciliation might prioritise direct membership for those two currencies. A platform expanding into a dozen currencies for marketplace payouts might reasonably choose an aggregated provider for speed of coverage, accepting the dependency on its partner banks in exchange. What matters is knowing which model is in front of you, because the two behave differently when volumes spike, when a bank changes its terms, or when a payment simply doesn't arrive on time.