Basic-Fit, Booking.com, and the SEPA Direct Debit Fraud Kit

On Sunday 13 April 2026, two notification emails landed in Dutch inboxes. Basic-Fit, Europe’s largest gym chain, told members that attackers had accessed the central database bridging its turnstile and check-in systems, downloading data on approximately one million people — roughly 200,000 of them in the Netherlands — out of the company’s five million members across twelve countries. Booking.com, the Amsterdam-headquartered travel platform, told an undisclosed number of guests that “unauthorised third parties” may have accessed their booking details, names, email addresses, physical addresses, and phone numbers.

Two breaches, two fundamentally different attacks, and one downstream consequence that both companies know is coming: targeted fraud built on real data. Every other outlet today is covering the what. This piece is about the how — specifically, how a leaked IBAN actually becomes money leaving your account under the SEPA Direct Debit scheme, and what closes the window. The broader landscape of credential leaks and breach-driven fraud is covered in our Credential Leaks & Breach Response hub.

Basic-Fit: a smash-and-grab on operational infrastructure

Basic-Fit frames the incident as brief. Internal monitoring detected unauthorised access, shut it down “within minutes,” and the company notified the Autoriteit Persoonsgegevens within the 72-hour GDPR window. Six countries were affected: the Netherlands, Belgium, France, Spain, Germany, and Luxembourg. Clever Fit locations and franchise branches were untouched because they run on separate systems. Basic-Fit has said it is “not currently aware of any member data appearing online, either for free or for sale,” and continues to monitor.

By category, what the attackers walked out with is a textbook fraud toolkit:

• Full legal name
• Home address
• Email address and phone number
• Date of birth
• IBAN used for recurring membership payments
• Subscription number, subscription type, payment status
• A record of which clubs the member visited over the past week

No passwords. No identity documents — Basic-Fit does not store them. No credit card data.

The vector is under forensic investigation, and any article claiming to know it today is speculating. What the known parameters narrow is the shape of the compromise. An attacker who pulls a structured database of one million records in the minutes between first access and containment is not clicking through a web interface. This is automated extraction against a backend — consistent with an insufficiently authenticated API endpoint, a direct database query through an exploited application path, or a compromised service account with over-broad read rights. The “within minutes” detection headline is less reassuring than it sounds: in a rapid-dump scenario, detection and containment are downstream of exfiltration, not upstream.

Booking.com: a pattern that started in 2018

Booking.com’s disclosure is thinner in almost every dimension. The company will not say how many customers are affected, when access occurred, or how the attackers got in. Its email to guests references “suspicious activity affecting a number of reservations,” confirms that booking details, names, email addresses, physical addresses, and phone numbers were viewed, and notes that “any other information you may have shared with the accommodation” may also have been accessed. Reservation PINs have been reset. The standard warning is included: Booking.com will never ask for credit card details via email, phone, SMS, or WhatsApp.

This is not the first time the same platform has produced this same threat. In December 2018, attackers tricked staff at several Booking.com partner hotels in the UAE into revealing their extranet login credentials over the phone. Using those stolen credentials, the attackers accessed the records of 4,109 customers and extracted credit card details for nearly 300 of them. Booking.com learned of the incident on 13 January 2019 and reported it to the Autoriteit Persoonsgegevens on 7 February — twenty-two days later, well outside the 72-hour GDPR window. In March 2021, the AP fined Booking.com €475,000 for the late notification.

The pattern that incident established has never stopped running. Since at least 2023, Booking.com has been the named platform in a persistent, well-documented phishing scheme in which attackers compromise hotel extranet accounts — typically via infostealer malware on hotel PCs, occasionally still via phone social engineering — and then send payment-verification messages through Booking.com’s own in-app chat, through WhatsApp, or through the hotel’s own branded email address. Because the messages reference a real reservation, a real stay date, a real PIN hint, and often the real hotel’s staff names, they bypass the consumer reflex to “log in through the official app.” The official app is where the phishing is arriving.

Community reports in Dutch tech forums today include users who received hotel-impersonation messages as early as 24 March — nearly three weeks before Booking.com’s 13 April disclosure. Some received a second, generic Booking.com notification with a new reservation PIN on 12 April, suggesting the incident has been live, and silently propagating through compromised hotel accounts, for at least part of that window.

Whether this April incident is a single root compromise at Booking.com itself, a larger cluster of compromised hotel extranets, or both, is unknown. Booking.com has given itself operational cover by not saying. What is clear is that the downstream threat this breach creates is identical to the one that has been running on the platform for at least seven years.

The SEPA Direct Debit fraud kit, explained

This is the section that matters in a year’s time. The Basic-Fit and Booking.com news will cycle through by the end of the week. The fraud mechanics built on leaked IBANs will keep running.

How SEPA Direct Debit actually works

SEPA Direct Debit is the EU-wide scheme that lets merchants pull money from your account on a recurring or one-off basis. You authorise this by signing a mandate — a legal instrument that identifies you, your bank (via IBAN), the creditor collecting, and the scheme variant (Core for consumers, B2B for businesses). The mandate does not live at your bank. It lives with the creditor, who is trusted to hold it, reference it on each collection, and produce it on dispute.

When a collection hits your account, your bank does not verify the underlying mandate. It processes the debit on the basis of the creditor’s identifier and a mandate reference, and pushes verification to the dispute stage. This architectural choice is the reason the refund rights exist. It is also the reason fraud is possible in the first place.

The fraud kit

A fraudulent SEPA Core Direct Debit submitted against your account needs four inputs:

1. Your IBAN — the account to pull from.
2. Your legal name — must match the IBAN holder for the debit to clear without friction.
3. Your address — used for the mandate record and for creditor-side KYC where any is attempted.
4. A creditor identifier — which the attacker already holds because they registered a fake merchant, or bought an unused one.

That is the complete input list. Notice what is not on it: your password, your card number, your passport, any two-factor code. The Basic-Fit dataset supplies inputs one through three directly. Date of birth, also leaked, makes creditor-side fraud checks easier to pass if the attacker is setting up the fake merchant in parallel.

In practice, two patterns dominate. The first is high-volume, low-value: sub-€10 debits submitted against tens of thousands of leaked IBANs, using merchant names that mimic streaming subscriptions, “membership renewals,” or micro-donations. Most victims never notice because the amounts disappear into ordinary statement noise. The second is single-hit, high-value: one larger debit, typically €200 to €800, timed to land the day after salary or pension, against accounts profiled as likely to hold balance. The Basic-Fit data — which includes subscription status and visit patterns — makes that profiling easier than it should be.

Your rights, and the window

Under the SEPA Core scheme, you have eight weeks from the debit date to request an unconditional refund from your bank for any collection — no reason required, no dispute process, money back. For collections where no valid mandate exists, or where the collection does not relate to the mandate you signed, you have thirteen months from the debit date. In the Netherlands, the 13-month process is formally the Melding Onterechte Incasso (MOI) — a written declaration filed through your bank stating that no valid authorisation exists. Banks are obliged to process it and recover from the creditor bank downstream.

The SEPA B2B scheme, which business accounts can opt into, strips the eight-week unconditional window entirely. Business account holders retain only the thirteen-month protection for genuinely unauthorised collections. This is why B2B direct debit fraud is the harder category to unwind, and why fraud against SME accounts typically runs at higher ticket values.

In all Dutch retail banking apps, the consumer-side reversal is a button — usually labelled terugboeken or incasso storneren — against the specific transaction. You do not have to state a reason within the eight-week window and the bank cannot refuse.

One important caveat Betaalvereniging Nederland is explicit about: a reversal does not extinguish an underlying debt. If the collection was for money you actually owe — an unpaid invoice, a subscription you forgot to cancel, a membership still active in the provider’s system — reversing the debit does not cancel the obligation. The provider can still bill you through other means. Use the reversal to recover from fraud and from genuine errors. Do not use it as an informal cancellation tool.

What closes the window permanently

Refunds recover money. They do not close the exposure. Your IBAN, name, address, and date of birth will continue to circulate in criminal datasets regardless of how many individual debits you reverse. Three practical controls change the baseline, and all three are available at every major Dutch retail bank today.

First, IBAN-level allowlisting. ING, Rabobank, and ABN AMRO all offer the option to flip the default on your account from “accept all SEPA direct debits” to “accept none, except for a specified list.” ABN AMRO calls this a goedkeuringslijst; Rabobank and ING offer equivalent mechanisms. Under this setting, every recurring merchant you actually pay becomes an allowlist entry; everything else is rejected at the bank, not recovered after the fact. ABN AMRO additionally allows per-creditor limits — a maximum amount per collection, a maximum number of collections per year — which turns recurring fraud attempts into rejected transactions rather than refund requests. The features are all under-marketed and usually buried under incasso management in each bank’s app. Turning them on is a ten-minute exercise.

Second, creditor-level blocks (selectieve blokkade). All three banks allow you to block a specific creditor by creditor identifier rather than by account number, which means the block follows the attacker across every account and bank they try to collect from. Worth knowing: ING in particular is known for strict mandate-verification at collection time, actively cross-checking mandate IDs and dates against prior submissions, which catches a meaningful percentage of fraud at the scheme layer before it ever reaches your account.

Third, statement monitoring cadence. At least weekly, with per-transaction notifications set as low as your app allows — typically €1 is the practical floor. Attackers rely on volume and noise; alerts collapse the noise.

For the underlying identity layer — the fact that your name, address, and date of birth will continue to appear in data broker databases that attackers use as target lists — the only durable fix is removal. That is what The Eraser is built for, and why corporate exposure programmes like Corporate Audit treat broker data as the first surface to reduce, not the last.

What the Basic-Fit visit logs actually enable

Set the financial mechanics aside for a moment. Basic-Fit also leaked, for every affected member, a log of which clubs they visited in the past week. This is the kind of operational data that is invisible on an impact list and dangerous on reflection.

A week of gym check-ins produces, for a typical member, a routine map: which days they work out, which locations, which time windows — and by implication where they live, where they work, and how they travel between the two. For the ordinary member this is an abstract privacy loss. For a member who is an executive, a journalist, a judge, a protected person, or a survivor of domestic abuse, this is physical surveillance surface. Anyone holding both the Basic-Fit leak and the Odido leak — and the two have heavily overlapping Dutch victim populations — can now build a composite of name, home address, phone, IBAN, and weekly physical routine against named individuals.

This is the second dimension of the Basic-Fit breach that mainstream coverage has not addressed: operational data, once leaked, is not neutral. It tells an attacker not just who you are, but where you will physically be on Tuesday.

How this sits against the Odido pattern

For readers tracking the broader picture: the February 2026 Odido breach — 6.2 million records, ShinyHunters extortion, extracted through a vishing call against a telecom employee — is a human-vulnerability story. Attackers convinced a real employee to surrender SSO credentials in real time, then walked through the cloud environment on a legitimate session. We documented the mechanics and fraud escalation in How ShinyHunters Stole 6.2M Records, the 30-day fraud timeline, and the consumer response guide.

Basic-Fit appears to be a system-vulnerability story — automation against a backend, not impersonation against a person. Booking.com is a supply-chain story — compromised hotel extranets, not compromised Booking infrastructure — which maps more closely to the vendor-credential pattern we dissected in the European Commission breach anatomy.

Three breaches, three different root causes, and — from the perspective of a Dutch consumer whose data now sits in more than one of them — the same downstream exposure. The refund right resets with every debit. The underlying identity data does not.

Further reading

• When Someone Else's Security Becomes Your Breach: Third-Party Risk and Supply Chain Attacks Are Not the Same Problem. Structural framework for the IN vs OUT distinction. privacyinsightsolutions.com/blog/third-party-risk-vs-supply-chain-attack