Banking Circle, Kraken and the False Comfort of a Name Match
In a recent Austrian victim case, three transfers totalling €60,749 went to Banking Circle IBANs displayed inside Kraken as fiat funding details. The payer saw his own name as beneficiary and received a positive Verification of Payee result. The name check was technically correct — and still dangerously misleading.
Between 28 May and 26 June 2026, an Austrian consumer made three transfers totalling €60,749 to German-format IBANs at Banking Circle S.A., displayed inside Kraken as fiat funding details for his Kraken account. On each receipt, the beneficiary was the payer himself. His bank returned the same reassuring result: “Name und IBAN passen zusammen” — name and IBAN match. On the information available to EFRI, that result appears to have been technically correct. It was also dangerous. The payments were not ordinary own-account transfers. They were the fiat on-ramp into a crypto-investment fraud.
The fraud did not need to defeat the name check. It needed the name check to work. That is only the automated version of a pattern running through the entire file.
This case shows, with unusual clarity, what “social engineering” means in practice. It is not a single deceptive phone call. It is the takeover of the victim’s decision-making environment. Over roughly one month, three separate intervention points were triggered: the crypto platform held a payment and asked questions; its anti-third-party-funding rule rejected a payment; and the sending bank became suspicious and asked for an explanation. But every control asked the customer — and the customer was no longer answering independently. According to the WhatsApp record reviewed by EFRI, the fraudster supplied the answers through the victim in real time. The system believed it was speaking to the customer. In substance, it was receiving the fraudster’s instructions.
The more serious finding is structural. Where a consumer transfer to a crypto platform is legible in the beneficiary data, the sending bank can still apply crypto-specific warnings, holds, limits or blocks at the last point where the money is usually still recoverable. A victim-named virtual IBAN changes that visibility. The beneficiary shown to the payer is the customer himself. The IBAN points to a regulated bank. The crypto platform may disappear from the beneficiary field. What is economically a crypto-ramp payment may therefore be presented to the payer — and potentially read by front-line systems — as an own-name bank transfer. The safeguard has not been defeated. It has been made inapplicable at the consumer-facing layer.
Kraken and Blockchain.com show that Banking Circle is not merely an incidental banking name in one fraud file. It is part of the fiat-access infrastructure used by major crypto platforms. Kraken describes its Banking Circle method as a unique bank account in the customer’s name. Blockchain.com, after moving fiat deposit details to Banking Circle, tells EUR and GBP users that the details are not a bank account under the user’s name but a unique virtual reference. That difference is not cosmetic. It determines whether the payer understands the payment at all. A consumer who sees “account in your name” will understand the transfer differently from a consumer who is told that the details are merely a platform-issued virtual reference.
Background
According to the police complaint and the chronology reviewed by EFRI, the victim was approached via WhatsApp in May 2026 by a crypto-trading operation presenting itself under the names Ironvex and Blackthorn Elite. The file contains the familiar apparatus of an online-investment-fraud scheme: a platform dashboard showing fictitious balances, purported investment advisers, instructions delivered via WhatsApp, a guarantee agreement and escalating demands for further payments. The narrative was built around participation in a form of “prop trading”. As is typical in such cases, the entry payment was small: a €250 card payment, described as necessary to open or activate the trading account.
The victim was then instructed by the fraudsters to open a Kraken account and use it as the fiat entry point into the alleged investment. In his later description, he referred to this route as “Kraken Bank”. EFRI does not suggest that Kraken described itself as a bank. The point is different: the Kraken app displayed manual bank-transfer instructions and told the user to use the provided bank details to transfer money from his bank. It also warned that the first and last name on the sending bank account had to match the name on the Kraken account.
Under “Your deposit details”, the app then displayed the victim’s own name as account name, a German-format IBAN, BANKING CIRCLE S.A. as the bank and SXPYDEHHXXX as the BIC. The victim therefore did not merely receive access to a crypto wallet or trading interface. He was shown individual fiat payment details connected to Banking Circle and labelled with his own name.
That presentation explains why the victim spoke of “Kraken Bank”. To a consumer being guided by fraudsters, the payment route could reasonably look like an own-name bank transfer: his name, a German IBAN and a regulated bank. In the payment architecture, however, it was something different: a fiat funding rail into a crypto platform, provided through Banking Circle’s virtual-account infrastructure. The distance between those two readings is the subject of this note.
The documented payment trail
The receipts reviewed by EFRI total €93,748; including the initial €250 card payment, the documented payment trail amounts to €93,998. Of that amount, €60,749 went to victim-named Banking Circle payment details displayed inside the crypto platform. The separate €32,999 transfer to a corporate beneficiary at a Lithuanian institution is recorded because it shows the operation changing channels once the crypto route encountered friction. Further items remain unverified at this stage: a later alleged €9,500 payment under a “legal verification” narrative and charges of €456 and €106.06. If included, these items bring the potential exposure to approximately €104,060.06, consistent with the police confirmation, which records suspected fraud by unknown perpetrators and states that the loss exceeds €100,000, with the exact figure still under investigation.
The credit layer sits inside the same operation. According to the victim chronology, the victim did not have the funds required for the alleged investments. The fraudster therefore pushed him towards online credit and walked him through the application process. The chronology records an online loan application of approximately €47,500 involving Targobank, completed by the victim himself, but under instruction and within the false investment narrative. The proceeds arrived on 16 June 2026; the €49,999 transfer to the victim-named Banking Circle/Kraken payment details left the same day.
The victim further states that around €33,000 later appeared in his account. He initially understood this as a partial return from the platform, but subsequently came to believe that it was a second online loan obtained through easybank using his identity documents. That allegation must be verified against the credit file, device data, application trail and bank records before it is treated as established. What is already clear from the chronology is the operational sequence: shortly after the amount appeared, €32,999 was transferred to Lithuania.
This is why the loans should not be treated as a side issue. They were part of the fraud mechanics. The fraudster did not merely persuade the victim to invest existing savings; he created additional liquidity by steering the victim into credit and, according to the victim, by reusing KYC material collected during the supposed trading onboarding. The same social-engineering relationship that produced the payment instructions also produced the documents, codes and explanations needed to pass through credit, platform and bank controls.
| Date | Amount | Route | Beneficiary shown to the payer | Evidence status |
|---|---|---|---|---|
| 25 May 2026 | €250 | Card payment | Ironvex / Blackthorn Elite onboarding | Chronology and WhatsApp record; not a Banking Circle leg |
| 28 May 2026 | €2,500 | Banking Circle DE IBAN (SXPYDEHHXXX) | the payer himself | Receipt records positive name/IBAN match |
| 16 June 2026 | €49,999 | Banking Circle DE IBAN (SXPYDEHHXXX) | the payer himself | Receipt records positive name/IBAN match; loan proceeds arrived the same day |
| 18 June 2026 | €32,999 | Lithuanian institution (MNNELT21XXX) | Tuuriowholes OÜ | Receipt records positive name/IBAN match; not a Banking Circle leg |
| 26 June 2026 | €8,250 | Banking Circle DE IBAN (SXPYDEHHXXX) | the payer himself | Receipt records positive name/IBAN match |
| Total | €93,998 | of which €60,749 to victim-named Banking Circle details | ||
What the Kraken/Banking Circle funding details actually showed
When the victim registered with Kraken he received a wallet address and individual Banking Circle fiat payment details. The app displayed bank transfer details, and those did the work of the description: the page “Anweisungen zur manuellen Banküberweisung”, telling him to transfer money from his bank to these details and that the first and last name on his bank account must match the name on his Kraken account; and under “Deine Einzahlungsdetails”, his own name as account name, a German-format IBAN, BANKING CIRCLE S.A. as bank, BIC SXPYDEHHXXX, Banking Circle as financing service. The app did not explain, in consumer-facing terms, that these were platform-assigned fiat funding details rather than an ordinary bank account held by the victim with Banking Circle.
Kraken’s support documentation confirms this is the standard model:
“The method assigns to your Kraken account a unique bank account in your name, matching the name on your Kraken account.”
It adds that for EUR SEPA the account is with Banking Circle’s German branch (SXPYDEHHXXX) with a DE-format IBAN, that withdrawals go via “the same personal named account”, and that “deposits from third-party accounts will be returned.”
Banking Circle’s public statement to consumers points the other way:
“Banking Circle does not service private individuals. For law enforcement enquiries, please be aware that Banking Circle provides (virtual) IBANs to our clients who then assign them to their own customers, with whom Banking Circle has no business relationship.”
It adds that its name appears on statements because the PSP or merchant uses its infrastructure, that it does not hold the consumer’s funds or manage the account, and that it cannot block transactions or return funds.
The tension is not that only one of these statements must be false. Kraken may display Banking Circle funding details in the customer’s name, while Banking Circle may still treat Kraken / Payward as its contractual client. The issue is different: the customer’s name is operationally used to label the virtual IBAN and to support a positive name/IBAN match, while the same person is contractually disclaimed as Banking Circle’s customer. The question is therefore not whether the victim was Banking Circle’s contractual customer. The question is who supplied, verified and returned the name data that made the green match possible — and what the payer was told that match actually meant.
A third statement bears on this. During a service disruption on 13 August 2026 Kraken described these accounts as provisioned dynamically for Kraken users at end-customer level. Dynamically provisioned identifiers at end-customer level are the definition of a virtual IBAN, not bank accounts held by the customer.
The same infrastructure can also be described very differently. Blockchain.com — whose UK entity, BC Operations Limited (FCA firm reference 1036678), moved its fiat deposit details from LHV to Banking Circle on 1 July 2026 — tells its EUR SEPA users: “This is not a bank account under your name; it is a unique virtual reference.” Both disclosure models may be lawful; they produce very different consumer beliefs. Where the platform says the details are in the customer’s own name and his bank then confirms the match, a fraudster has two independent institutions telling the consumer the payment is what he has been told it is.
The problem is not that virtual IBANs exist. The problem is that they can make a crypto-ramp look like an ordinary own-name bank transfer. Kraken and Blockchain.com show that Banking Circle is no longer just a bank name appearing in one fraud file. It is part of the fiat-access infrastructure used by major crypto platforms. That makes disclosure decisive. A consumer who sees “account in your name” will understand the payment differently from a consumer who is told that the details are merely a virtual reference and not a bank account under his name.
This comparison matters because it shows that the consumer-facing description is not technically predetermined. Blockchain.com can tell customers that the details are a virtual reference and not a bank account in their name. Kraken uses the language of a unique bank account in the customer’s name. Both structures may be lawful, but they do not create the same consumer understanding.
The model removed a control that was working
The most consequential thing this route does is not the green result. It is what it takes off the screen.
Before victim-named funding details became normal, the beneficiary field carried the platform’s name, and sending banks acted on it: across Europe and the UK, banks introduced warnings, holding periods, value limits and outright blocks on transfers to crypto exchanges, because investment-fraud losses were concentrated there. Whatever one thinks of blanket blocking — and it drew legitimate complaints about de-risking — the warning practice worked at the only moment that matters. Banks warned because they could see.
Here three signals were suppressed at once. Who the counterparty was: not a crypto platform, but the payer himself. What kind: a credit institution’s German branch, with nothing in the payment identifying a CASP as the economic recipient. Where the service sits: the platform relationship is with an Irish-authorised entity and the banking relationship with a Luxembourg institution, while the payment presents as a German IBAN.
That inversion runs against the supervisors’ own risk data. In its Opinion on new types of payment fraud and possible mitigants (EBA-Op/2024/01, 29 April 2024) the EBA identified “manipulation of the payer” as the leading emerging fraud type — this case’s exact typology — recorded that PSPs routinely treat strong-customer-authenticated transactions as authorised in social-engineering cases and refuse reimbursement (para. 21), and noted that cross-border transactions carry roughly nine times the fraud rate of domestic ones, instant payments roughly ten times that of ordinary credit transfers. In its virtual IBAN report the same year it recorded that payers’ PSPs cannot reliably distinguish domestic from cross-border transactions where identifier and master account sit in different countries, distorting fraud reporting data. Virtual IBANs suppress precisely the attributes that carry the risk signal, in the data set on which that signal is calibrated.
The information has not disappeared, though; it has moved. BIC SXPYDEHHXXX is on every receipt, and a bank maintaining current intelligence on which BICs belong to vIBAN issuers serving crypto platforms could still have recognised the rail — and seen three payments in four weeks to a known on-ramp, one on the day loan proceeds landed. The signal migrated out of a field the payer and the front-line system read into one only an institution with maintained rail intelligence can read. For the consumer it is gone; for the bank it is a question of whether it invests in seeing what its customer no longer can.
Who answered the verification request?
Article 5c of Regulation (EU) No 260/2012, as inserted by Regulation (EU) 2024/886, requires the payer’s PSP to verify that the payee’s name corresponds to the account identifier and to inform the payer of any discrepancy before authorisation. It applies to euro credit transfers generally, standard and instant, binding euro-area PSPs since 9 October 2025 and non-euro-area PSPs from 9 July 2027. Under the European Payments Council’s scheme the check is a request-and-response between institutions: the payer’s PSP asks, and the payee’s PSP — the “Responding PSP” — answers, with one of four outcomes (match, close match, no match, verification not possible).
The IBANs shown in the file are German-format IBANs at Banking Circle’s German branch. That makes Banking Circle the natural institution to identify in the receiving-side chain. It does not yet prove that Banking Circle itself technically generated the VoP response, or that the name data were not supplied through Kraken / Payward or another technical arrangement. What can be said is narrower but important: a positive name/IBAN result for a Banking Circle vIBAN presupposes that the responding side had access to a registered name for that vIBAN.
That is the unresolved question. If the victim was not Banking Circle’s customer, on what legal and technical basis was his name used to return a positive match on a Banking Circle IBAN? Was the match based on data held by Banking Circle, data supplied by Kraken, or another responding-PSP mechanism? The sending bank can identify the response code and responding PSP; Banking Circle and Kraken can identify the attribution data behind the vIBAN. Until then, EFRI treats this as the most plausible reading of the payment architecture, not as an established finding.
The European Banking Authority said this would happen
In its Report on Virtual IBANs (EBA/Rep/2024/08, May 2024) the EBA found that where the institution providing the master account has no contractual relationship with end users it has no visibility of their identities, complicating transaction monitoring (paras. 42–46); questioned whether such end users hold a “payment account” at all, and therefore whether PSD2 safeguards attach (paras. 70–73); and noted that consumers may believe funds are moving domestically when the master account sits abroad (para. 97).
At paragraphs 77–81 it addressed this precise point: how Article 5c payee-name checking applies where the end user is not the master account holder is unclear. At paragraph 82 it recommended that the Commission clarify it. Twenty-seven months later the clarification has not come. The obligation went live in October 2025 into an architecture whose own supervisor had told the legislator it did not know how the rule applied.
Two markers have appeared since. On 13 April 2026 the French ACPR and Tracfin published findings citing roughly €4 billion in monthly flows through virtual identifiers and, for end-2022, 1.7 million virtual accounts held by some 400,000 clients in France, recording that institutions frequently fail to conduct adequate due diligence on the users of secondary identifiers. On 28 July 2026 the French and German authorities jointly warned banks to tighten checks before granting payment firms virtual account numbers, citing high money-laundering risk and increasing use by fraudsters. EFRI has covered BaFin’s warning and, earlier, whether virtual IBANs are a risk for consumers; our running record is under Banking Circle.
The obligation that would most directly close the visibility gap — Article 22(3) of Regulation (EU) 2024/1624, requiring institutions to obtain information identifying the persons using any virtual IBAN they issue, and the servicing institution to be able to obtain it within five working days — does not apply until 10 July 2027. At the time of these payments it bound no one.
The strongest answer on the other side belongs first. Verification of Payee was never a fraud check, and its scheme owner says so: the EPC states that VoP “cannot be relied upon to identify a private or a legal person.” Named funding accounts are themselves a control — a unique account in the customer’s name, third-party deposits returned, withdrawals routed back through the same account, designed to prevent the third-party funding on which laundering typologies depend. The platform acted. And the payments were authorised: initiated by the payer, from his own account, to details he had been shown, with the verification result in front of him. No European instrument in force gives him a reimbursement claim. All of that is true, and none of it disposes of what follows.
Three controls fired. The fraudster answered all three.
Social engineering is not just the lie at the beginning of the fraud. It is the takeover of the victim’s decision-making environment. Through daily messages, calls and screen-sharing, trained boiler-room operators build trust, create dependence and make the victim believe that following instructions is rational and safe. That is why the controls failed in this case: when the platform or the bank asked the customer a question, the customer was already conditioned to obtain the answer from the fraudster.
The platform held the €49,999 and asked. The chronology records a ticket number and a questionnaire to be answered before the pending amount could be dealt with — and records that the affected person sent screenshots of the questions to the fraudster and copied the supplied answers into his reply. So the control failed at the moment it was working. A questionnaire answered under active social-engineering pressure is close to worthless as evidence of independent intent; the objective pattern was the better evidence — a recently verified account, a large first fiat inflow through a named virtual identifier arriving the same day as loan proceeds, immediate onward movement, signs of remote guidance and screen-sharing. Payward Europe Solutions Limited holds a MiCA authorisation from the Central Bank of Ireland, under which a crypto-asset service provider must act honestly, fairly and professionally in the best interests of its clients. Self-certification by a coached customer is a thin basis on which to discharge that — and the fiat on-ramp is where this typology is visible at all, which is why EFRI has argued that banks must watch the fiat ramp.
The anti-third-party-funding rule fired, and became a lever. A payment attempted by the supposed broker was rejected and the affected person was told the money had to come from his own account. He borrowed €8,250 from his brother. The rule is formally correct and worked as designed; here it extracted a further payment from the victim personally and pulled a family member into the loss.
The sending bank became suspicious and asked. When it raised questions, the fraudster supplied the explanations and documents through the customer — an institution formed a suspicion and had it dispelled by the person it was suspicious about. What it could see should be stated accurately: not a payment to a crypto platform, but a retail customer sending €49,999 to an account in his own name at a German institution the day loan proceeds landed, €32,999 to a corporate beneficiary in Lithuania two days later, and €8,250 back to the German route eight days after that — with a positive name-match on each. The pattern was visible; the nature of the destination was not. Two questions follow, and the match answers neither: whether a positive name result should reduce the intensity of the rest of the assessment on a large, out-of-profile, freshly loan-funded payment; and whether an explanation produced on the spot, by a customer in live contact with the person supplying it, should ever close a fraud query rather than merely open one.
It is unclear whether Banking Circle was asked at the relevant poinand holds the position that matters for recovery. It says it can identify the client behind a virtual IBAN, forward a case and cooperate with law enforcement, but cannot access end-customer transaction detail, reach funds or issue refunds. Whether that division is contractually accurate is a different question from whether it is operationally adequate: the speed of reconstructing the path — infrastructure bank to client, client to platform account, platform account to onward wallet — is the difference between a recoverable balance and a closed file, the asymmetry documented in Money Moves in Seconds. Banking Circle has meanwhile been authorised as a crypto-asset service provider by the Luxembourg CSSF (15 April 2026, announced 27 April 2026), offering fiat-to-stablecoin and stablecoin-to-fiat settlement in USDC, USDG and EURI; on its scale, see Banking Circle’s 2025 accounts.
The credit institutions did not necessarily see where the loan proceeds went. Their control point was the remote loan application itself: identity documents, income data, device traces, email, phone, video-identification and customer responses. In the Targobank strand, the victim appears to have completed the application himself, but under instruction. In the easybank strand, he states that a second loan was obtained using his identity documents. That allegation remains to be verified, but the risk is clear: online credit fraud starts when a victim’s identity is used inside a fraud-controlled process, not only when the money later leaves the account.
The Nordic experience with mature digital-identity systems is the warning for the EUDI Wallet era. Fraudsters can use real identities, real documents and real authentication steps while controlling the victim’s decision environment. Identity assurance is not fraud assurance. Here, credit created the liquidity, the victim-named Banking Circle/Kraken vIBANs created the safe-looking payment route, and the fraudster supplied the answers whenever a control asked a question. The system saw fragments; the fraudsters operated the chain.
No institution necessarily saw enough alone. The system fragmented the picture along the seams the fraud was built to exploit — and each fragment it did notice, it verified by asking the one participant who could no longer answer for himself.
What the reform in progress would not do
The Payment Services Regulation, agreed politically on 27 November 2025, strengthens name-and-identifier verification, introduces a reimbursement right where a fraudster impersonates a PSP’s staff (subject to the customer reporting to the police and notifying the PSP), obliges receiving PSPs to freeze suspicious transactions, and makes PSPs liable where they fail to operate appropriate fraud prevention.
None of it reaches this case. Nobody impersonated a bank. The affected person opened a genuine account at a licensed platform and funded it through details in his own name, using a verification service that answered correctly; on these facts he would have no reimbursement claim under the agreed text either. That is not a drafting oversight to be fixed in a recital — it is the boundary of the model: the closer a fraud stays to formally correct process, the less of it the model touches. EFRI has argued that the EU must urgently enact PSD3 and the PSR; this file is why we also say enacting them will not be enough and why we always point to a shared liability framework.
Our Assessment
A correct answer is not a safe payment, and consumers were never told the difference. What VoP verifies is narrow: whether a typed name corresponds to the data held against an identifier. It says nothing about whether the counterparty is legitimate, whether the account is a virtual identifier assigned by a crypto platform, whether the payer has just been put into debt, or whether someone is on a video call telling him what to type. In victim-named on-ramp cases a green result is not neutral — it supplies the reassurance the fraud requires. We said in May 2026 that its real danger was becoming a liability shield; this file is the demonstration.
A functioning control was engineered out of existence, and nobody decided to remove it. We experienced several cases when banks warned their customers about crypto on-ramp payments because they could see them. Victim-named funding details end that, not by defeating the control but by removing the field it read. No supervisor authorised the trade-off, no impact assessment weighed it, no consumer was told; it is a by-product of a design choice made for reconciliation and anti-third-party-funding reasons, and it silently moved risk onto the payer. The remedy is not blanket blocking, which produced its own harms, but making the routing legible again in the payment message: a machine-readable marker identifying an identifier as virtual and, where applicable, as a CASP funding rail. The EBA recorded in 2024 that the ISO IBAN standard carries no such marker; ACPR and Tracfin recommended in April 2026 that it be revised to label virtual account redirection. Two supervisors have asked for the same thing. It should be built.
Consent-based controls do not survive contact with a coached customer. Three controls fired here, and all three put their question to a person under third-party control for weeks. The framework assumes the customer is the reliable witness of his own intent; in social-engineering fraud that is precisely what has been defeated, usually before the first large payment. Objective indicators — account age, funding source, velocity, immediate onward conversion, destination, signs of remote guidance — are not supplementary to the customer’s answer; where coaching is plausible they are the only evidence worth weighing. Three things diverged here and the system treated them as one: the name on the account, the identity of the customer, and who directed the money. The chain confirmed the first two; the fraud lived entirely in the third — the same fault line as FINOM/Triventa from the opposite direction.
The supervisor named the gap and the legislator left it open. The EBA told the Commission in May 2024 (EBA/Rep/2024/08, para. 82) to clarify how Article 5c applies where vIBAN end users are not master account holders. The obligation went live in October 2025 without it, and this file is what the unanswered question looks like when it reaches a consumer: three payments, €60,749, three green results. The clarification should resolve whether a Responding PSP may return “match” against a name it has not itself verified as an account holder, and what it must return where the payee record is a client-assigned label rather than an account.
The limits of a single file are real: the second credit strand rests on the affected person’s account and is undocumented; whether he completed the video-identification sessions himself under instruction or a third party passed them is unresolved and legally material; the Responding PSP and the response code are unconfirmed; and nothing here establishes that any institution breached a duty. What the file does establish is that a fraud can run three payments through a live Verification of Payee system, collect a positive result each time, be questioned by three separate controls, answer all three through the victim, and pass invisibly through a category of payment European banks had learned to warn about — because the one field that identified it no longer says what it is.
