Banking Circle’s vIBAN Model in Practice: Kraken, Bano and the Look-Through Problem
EFRI has repeatedly argued that the principal risk of virtual IBAN structures is not the IBAN itself. It is the separation between the bank whose name appears in the payment chain, the regulated intermediary that is the bank’s contractual customer, and the end user who actually controls or benefits from the payment.
Recent developments involving Banking Circle make that problem unusually concrete.
Within a few weeks, three different sources have exposed different sides of the same architecture:
- Kraken now documents that individual customers can receive DE virtual bank accounts at Banking Circle in their own names;
- an Australian Federal Court case records Banking Circle Australia treating insufficient visibility over the customers of its PSP customer as a material AML/CTF risk; and
- in an EFRI fraud case, a Banking Circle virtual IBAN had been created in the fraud victim’s own name without his knowledge, while the identity of the Banking Circle client responsible for creating it remained inaccessible to the victim.
None of these facts establishes wrongdoing by Banking Circle. Taken together, however, they illustrate why the question of look-through responsibility in nested vIBAN structures can no longer be treated as theoretical.
Kraken: a Banking Circle account “in your name”
Kraken’s support documentation, last updated on 24 July 2026, describes its new Banking Circle funding method in unusually clear terms.
When an eligible Kraken customer selects Banking Circle for the first time, Kraken says that a personal bank account number is generated for that Kraken account. According to Kraken:
“The method assigns to your Kraken account a unique bank account in your name, matching the name on your Kraken account.”
For EUR transfers, Kraken identifies the account as being held with Banking Circle’s German branch, using a German-format IBAN and BIC SXPYDEHHXXX. GBP customers receive a corresponding account through Banking Circle’s UK branch. Kraken also states that withdrawals are processed through the same personalised account.
Kraken requires the sending bank-account name to match the name of the Kraken customer and states that third-party deposits will be returned.
From the user’s perspective, the structure therefore looks remarkably similar to an ordinary individual bank account:
Kraken customer name → DE IBAN → Banking Circle Germany
The contractual structure appears different.
Banking Circle itself states:
“Banking Circle provides (virtual) IBANs to our clients who then assign them to their own customers, with whom Banking Circle has no business relationship.”
Banking Circle expressly describes itself and its client as intermediaries forwarding the funds.
The apparent chain is therefore:
Banking Circle → Kraken → Kraken customer
This distinction is important. The person whose name appears against the IBAN may not be Banking Circle’s contractual customer at all.
That does not make the arrangement unlawful. But it means that account name, IBAN issuer, contractual customer and underlying customer can refer to different levels of the payment chain.
For fraud tracing, AML supervision and civil recovery, that distinction is fundamental as we already described in articles about virtual IBANs.
An operational incident made the architecture visible
On 13 August 2026, Kraken reported an incident specifically described as:
“Issues creating virtual account orders on Banking Circle.”
Kraken stated that the creation of new Banking Circle virtual accounts was affected, while existing accounts were not known to be affected. The incident began at 11:50 UTC and was reported as resolved at 16:06 UTC.
Reuters also reported the incident.
The technical disruption itself is not especially significant and there is no public evidence identifying its cause.
Its evidential value lies elsewhere: it independently confirms that Banking Circle virtual accounts are being provisioned dynamically for Kraken users at the end-customer level.
That makes Banking Circle’s layered account model visible in practice rather than merely in product documentation.
The same architecture becomes an AML issue in Australia
The more important development comes from Australia.
On 16 July 2026, the Federal Court of Australia decided Bano Pty Ltd v Australian Settlements Limited [2026] FCA 932. Australian Settlements Limited is part of the Banking Circle group and operates as Banking Circle Australia.
Bano relied on Banking Circle Australia for access to Australian payment rails. After an AML/CTF risk review, Banking Circle Australia sought to suspend the relationship. Bano applied for an interlocutory injunction preventing that suspension.
The court refused the injunction.
Importantly, this was an interlocutory proceeding. The judgment should not be presented as a final judicial determination that Bano breached AML legislation.
What matters for present purposes is the risk assessment placed before the court.
According to the detailed case analysis published by Hall & Wilcox, Banking Circle Australia considered that Bano had failed to provide complete transactional and customer information. A particular concern was what were described as “nested” cryptocurrency flows.
Bano’s institutional customers were themselves issuing virtual accounts to their own end customers. The consequence was that the individuals actually transacting through the payment infrastructure were not visible to Banking Circle Australia.
Hall & Wilcox summarised one of the implications of the decision succinctly: visibility over a customer’s own end users, rather than merely the immediate customer, is central to financial-crime risk assessment.
That point deserves attention.
“Not our customer” and “not our risk” are different propositions
Banking Circle’s public European position is straightforward: its client receives the virtual IBAN and assigns it to its own customer; Banking Circle itself has no direct business relationship with that end customer.
That may correctly describe contractual privity.
But the Bano case demonstrates that the absence of contractual privity does not make the downstream user irrelevant to the infrastructure provider’s AML risk.
Indeed, Banking Circle Australia appears to have taken precisely the opposite position when protecting itself from AML/CTF exposure: insufficient visibility over the persons using accounts further down the customer chain was treated as a reason why the relationship could become unacceptable.
The distinction should therefore be kept precise:
The end user may not be Banking Circle’s customer. That does not necessarily mean that the identity and activity of that end user are irrelevant to Banking Circle’s own compliance obligations and risk management.
The Australian judgment does not establish a general legal duty requiring Banking Circle S.A. to know every downstream user of every European vIBAN. Different entities, jurisdictions and regulatory regimes are involved.
But it provides important evidence of how the Banking Circle group itself assesses the risk created by nested payment structures.
Banking Circle knows its direct client — the issue is whether that information reaches investigators
There is no information gap at the first contractual layer. Banking Circle necessarily knows the client to whom it provides its virtual-account infrastructure. Banking Circle itself now states publicly that it can identify the Banking Circle client linked to a vIBAN, forward a fraud case to that client and cooperate with law-enforcement authorities. It further explains that, where the vIBAN has been assigned onwards to a client’s customer, Banking Circle can furnish information about its own direct client.
That is precisely why the FINOM/Triventa case is relevant. Banking Circle’s records contained the institutional identifier behind the relevant virtual-account structure. The identity was not disclosed to the victim because Banking Circle referred him to formal law-enforcement channels.
The problem is therefore not whether Banking Circle knew its own customer. It did.
The question is whether this information actually reached the investigating authorities when it mattered. In the criminal file reviewed by EFRI, the Banking Circle client behind the relevant merchant identifier remained unidentified at the stage at which the investigation was discontinued for lack of an identifiable suspect.
This does not establish that Banking Circle refused a properly formulated request from law enforcement. The available evidence does not yet show where the information flow failed. But it exposes an important operational gap: Banking Circle held the information; Banking Circle publicly identifies law enforcement as the channel through which such information can be obtained; yet the information did not become operationally available in the criminal investigation reviewed by EFRI.
For victims, the distinction between information being held and information being effectively transmitted is decisive.
The FINOM/Triventa case shows why this matters for victims
EFRI recently documented the consequences of precisely this layering in our case note FINOM/Banking Circle/Triventa: a €314k pass-through at a DNB-licensed EMI.
The case concerned a €54,000 payment by a German investment-fraud victim into the FINOM account of a recently incorporated British company.
During only six weeks of operation, that account received €314,183 in 67 credits, overwhelmingly from private individuals, and transferred €313,725 — 99.85% of its inflows — onward to accounts at Banking Circle.
The next layer was even more unusual.
Banking Circle’s GDPR disclosure showed that one of its clients had used Banking Circle infrastructure to create a POBO virtual IBAN personalised in the fraud victim’s own name months before the victim was contacted by the scammers.
The victim had neither requested nor controlled the IBAN.
Yet Banking Circle said it held no IP-address, device or comparable endpoint information relating to the underlying customers of its clients. The identity of the Banking Circle client associated with the relevant merchant identifier was not disclosed to the victim, although Banking Circle stated that the information had been secured internally and could be addressed through formal law-enforcement channels.
The problem is therefore not abstract.
In that case the regulated institutions were identifiable. The victim was identifiable. The payment was identifiable. The virtual IBAN carrying the victim’s identity was identifiable.
What the victim could not identify was the intermediary that had placed his identity into the Banking Circle infrastructure.
That is the information asymmetry created by the B2B layer.
This is the problem EFRI warned about
EFRI’s earlier analysis, Virtual IBANs — a Risk for Consumers?, examined precisely this structural problem.
The European Banking Authority had already warned that vIBAN arrangements can produce situations in which PSPs have insufficient information about the underlying end users and in which regulatory responsibility becomes fragmented across multiple institutions.
Banking Circle is particularly important because of the scale of its infrastructure. EFRI previously documented Banking Circle’s statements concerning tens of millions of issued virtual IBANs and its model of allowing institutional customers to assign them onwards to their own customers.
BaFin has since gone further.
As discussed in BaFin Warns About Virtual IBANs — But the Problem Is Years Old, the German regulator now expressly expects institutions involved in vIBAN structures to understand the underlying users, business model and risks of multi-layered arrangements and to incorporate those risks into due diligence and transaction monitoring.
The Australian Bano case is therefore not an isolated curiosity.
It is another manifestation of the same regulatory problem.
The question is no longer whether look-through matters
The Kraken documentation, the Bano proceedings and EFRI’s FINOM/Banking Circle/Triventa case describe three very different contexts.
Yet the architecture is strikingly similar:
regulated bank → regulated or institutional client → downstream user → virtual account carrying an individualised name
In the Kraken model, the system is being used for a legitimate regulated crypto platform and the customer receives a personalised Banking Circle bank identifier.
In Bano, insufficient visibility over the downstream users of nested virtual accounts became part of Banking Circle Australia’s justification for terminating a PSP relationship.
In the FINOM/Triventa fraud case, the same type of layered infrastructure resulted in a virtual IBAN carrying the identity of a fraud victim who had never requested the account, while the institutional actor responsible for inserting that identity remained inaccessible to him.
These cases should not be conflated. They demonstrate different outcomes from a common infrastructure model.
But together they narrow the regulatory question considerably.
The issue is no longer whether the customers of a Banking Circle customer can matter.
Banking Circle Australia’s own AML risk assessment demonstrates that they can.
The remaining questions are harder:
How much downstream visibility must the infrastructure bank maintain? At what point does reliance on the immediate PSP cease to be sufficient? What monitoring is required where millions of individually named virtual accounts are created through third-party platforms? And when the structure is misused for fraud, who bears responsibility for reconstructing the customer chain quickly enough to freeze or recover the money?
Those are questions for supervisors, courts and ultimately the European legislature.
For fraud victims, however, the practical lesson is already clear.
A Banking Circle IBAN carrying a person’s or company’s name should not be assumed to identify the institution’s contractual customer. The visible beneficiary, the underlying user, the Banking Circle client and the legal account holder may occupy different layers of the same payment structure.
And when those layers become opaque, the fact that a downstream person is “not our customer” cannot by itself answer the separate question of whether visibility over that person is relevant to the infrastructure provider’s own AML and fraud-risk management.
That distinction — between contractual customer status and regulatory relevance, is likely to become one of the central issues in the next generation of virtual-IBAN litigation.
