The Week “GDPR-Compliant” Stopped Being Enough
By Zanket GroupPublished: July 7, 2026
The short version
On June 29, 2026, the U.S. Supreme Court ruled that the law limiting the president’s ability to remove Federal Trade Commission commissioners violates the Constitution’s separation of powers. The decision matters well beyond the FTC itself: the European Union has relied in part on independent U.S. oversight when assessing whether European personal data can be transferred to participating companies in the United States under the EU-US Data Privacy Framework.
The framework did not disappear overnight. It remains formally in force unless it is withdrawn or annulled.
But the ruling reopened a question that had seemed relatively settled:
How much can Europe rely on U.S. regulatory independence when evaluating protections for data transferred across the Atlantic?
On June 30, privacy organization noyb asked the European Commission to prepare an orderly repeal of the current adequacy decision, arguing that the Court’s ruling undermines an important assumption behind it. noyb also explicitly acknowledged that the decision remains legally in force for now.
That distinction matters.
This is not a story about EU-US data transfers suddenly becoming illegal.
It is a story about a legal foundation becoming uncertain again.
For ExtMoney, that uncertainty matters much less for our core financial data because we deliberately built the product so that most of it does not need to cross the Atlantic in the first place.
Wait, what actually happened?
Since 2023, the EU-US Data Privacy Framework has provided an adequacy mechanism allowing personal data to flow from the EU to participating U.S. companies without companies having to build a separate transfer mechanism for every transfer.
One part of that system is enforcement.
Participating U.S. companies make privacy commitments, and agencies including the Federal Trade Commission have enforcement responsibilities. Independence matters because European data-protection law places significant weight on effective and independent oversight.
Then came Trump v. Slaughter.
On June 29, 2026, the Supreme Court held that the statutory protection allowing FTC commissioners to be removed only for cause was contrary to the constitutional separation of powers. In practical terms, that gives the president substantially greater control over whether FTC commissioners remain in office.
The next day, noyb wrote to the European Commission arguing that this creates a serious problem for the EU-US framework and calling for an orderly path toward repealing the adequacy decision.
That does not mean the Supreme Court invalidated the EU-US Data Privacy Framework.
It did not.
Nor does it mean a European company suddenly cannot use an American cloud provider.
What changed is the level of certainty behind a sentence that had become routine:
“We rely on the EU-US Data Privacy Framework.”
That is no longer quite as boring or settled as it sounded a month ago.
And we've been here before.
Safe Harbor was invalidated in 2015. Privacy Shield followed in 2020. Now, a little more than a decade after the first of those decisions, the legal architecture supporting transatlantic data flows is facing another serious question.
Why we didn't build ExtMoney around that bridge in the first place
ExtMoney's core infrastructure runs on servers in Germany.
For the parts of the product where your financial history actually lives — transactions, accounts, balances, debts, and net-worth calculations — our default architecture keeps that data in Europe.
That means we don't need a transatlantic transfer mechanism just to store your account balance or calculate your net worth.
This is where two phrases that are often treated as interchangeable turn out to mean very different things:
GDPR-compliant
and
EU-hosted
GDPR compliance is about whether data is processed according to the applicable legal requirements.
Data residency answers a different and much simpler question:
Where does the data actually live?
One does not replace the other.
EU hosting does not automatically make a service GDPR compliant, and GDPR compliance does not necessarily mean that every byte remains inside Europe.
But keeping core financial data in Europe reduces the number of international transfers that need a separate legal and technical justification in the first place.
That's the distinction we care about.
We don't need your financial data to make money
Privacy architecture starts much earlier than encryption.
It starts with the business model.
ExtMoney makes money from subscriptions.
Not advertising.
Not selling access to spending patterns.
Not building advertising profiles from what you buy.
Not quietly creating a second business model around financial behavior.
That matters because product incentives eventually turn into engineering decisions.
If collecting another category of data has no purpose for the feature the user asked for — and no advertising business is waiting to consume it later — there is much less reason for us to collect it in the first place.
Our goal is therefore straightforward:
Collect what the product needs. Protect it properly. Keep it only for as long as there is a reason to keep it.
Underneath that principle are deliberately unexciting security measures:
- TLS 1.3 for data in transit;
- AES-256 encryption for backups;
- backups stored separately from the primary infrastructure;
- two-factor authentication;
- no hidden advertising telemetry built around financial behavior.
None of those is a magic privacy feature.
That's the point.
Good security is usually made from boring layers that each do one job properly.
Some data still crosses the Atlantic
We could stop the article here and leave the impression that every byte handled by ExtMoney stays permanently inside Europe.
That would make for a cleaner marketing story.
It also wouldn't be true.
Some ExtMoney features benefit from large language models, including parts of AI-assisted financial analysis. Depending on the provider used, some processing can therefore take place outside the EU.
We think the useful privacy claim is not:
“Your data never leaves Europe.”
It's:
“We know exactly when it does, why it does, and what we send.”
When an external processor is required, we apply several rules.
1. The provider is disclosed
External processors should be identifiable as subprocessors, along with the reason they receive data.
“Trusted partners” is not a useful answer to the question:
Who can actually process my information?
2. We don't rely blindly on a single transfer mechanism
Standard Contractual Clauses are a separate GDPR transfer tool and can be used for qualifying transfers outside the EEA. They do not, however, make every transfer automatically safe or eliminate the need to assess the circumstances of the transfer and, where necessary, apply additional safeguards.
That's an important distinction.
The goal is not to find a legal phrase that lets us stop thinking about the problem.
The goal is to minimize the transfer first, then apply the appropriate legal and technical protections to what remains.
3. The data is minimized before it leaves
An external AI model usually does not need to know who you are in order to perform the task we asked it to perform.
So identifying information can be replaced with opaque tokens before the request leaves our infrastructure.
Conceptually:
Eugene Kononenko → USER_7F21
The external model sees the token.
The mapping between that token and the real value stays under our control.
When the response returns, the original value can be mapped back locally where necessary.
That is tokenization/pseudonymization, not a claim that the external processor magically receives no sensitive information at all.
The principle is simpler:
If a processor doesn't need a piece of information to do its job, don't send it.
Consent isn't a checkbox. It's a receipt.
A privacy policy that says:
“We ask for your consent.”
is a promise.
A system that can answer:
- what you agreed to;
- when you agreed to it;
- which version of the wording you saw;
- which feature that consent applied to;
is a receipt.
We built ExtMoney around the second model.
Consent events for features such as:
- voice processing;
- receipt scanning;
- AI-assisted insights;
- marketing;
are recorded in an append-only consent history tied to the wording presented at the time.
That matters because privacy language changes.
Six months later, the useful question isn't:
“What does our consent screen say today?”
It's:
“What exactly did this user agree to on that date?”
Those are very different questions.
Saying no should actually mean no
Consent also needs to change product behavior.
If a user disables an optional AI feature, the useful interpretation of that choice is not:
“Turn off the button but keep doing roughly the same processing somewhere in the background.”
It means the optional AI processing stops.
That does not mean every useful feature has to disappear.
For example, ExtMoney's anomaly detection can operate using statistical methods without requiring an LLM. AI can add another layer of explanation or interaction on top of that, but the underlying functionality does not have to depend on it.
That's an important product principle:
Privacy choices should not be fake choices.
A user should be able to decline an optional processing layer and still have a useful product.
Four privacy questions worth asking any finance app
1. Where does the data actually live?
Don't stop at:
“Are you GDPR compliant?”
Ask:
“Where are my transactions and account data stored?”
Both questions matter, but they answer different things.
2. How does the company make money?
A privacy policy tells you what a company promises to do.
A business model tells you what it has an economic incentive to do.
Ask whether the product is funded by:
- subscriptions;
- advertising;
- referral commissions;
- financial-product sales;
- behavioral data;
- or some combination of them.
None of those automatically proves good or bad privacy practices.
But you should know the answer.
3. What happens when I decline an optional feature?
If you say no to AI processing, does the data stop going to the AI provider?
If you withdraw marketing consent, does the marketing processing stop?
The behavior of the product after you say no tells you more than the design of the consent button.
4. Who are the subprocessors?
Ask for names.
Ask what each one does.
Ask what data each one receives.
Ask where the processing takes place.
A concrete answer is more useful than a paragraph about “carefully selected trusted partners.”
Where we'd push back on ourselves
Privacy marketing becomes dangerous when every design decision gets presented as an absolute guarantee.
So there are a few things we think are worth saying clearly.
We are not lawyers
Nothing here is legal advice.
The legal environment around international data transfers can change, and our compliance practices will have to evolve with it.
We designed the architecture to reduce unnecessary dependencies on international transfers.
We are not claiming that architecture makes ExtMoney immune to future regulatory change.
Some processing still leaves the EU
That's true today.
The useful distinction is that we try to make those transfers:
- necessary;
- limited;
- disclosed;
- minimized;
- protected by the appropriate transfer mechanism and safeguards.
We would rather explain the exceptions than hide them behind a cleaner slogan.
EU hosting is not the same as perfect privacy
Keeping core data in Germany removes some unnecessary cross-border complexity.
It does not solve every privacy or security problem.
Bad access controls on a server in Germany are still bad access controls.
Poor retention practices in Europe are still poor retention practices.
Data residency is one layer.
It isn't the whole system.
An append-only consent log doesn't enforce good decisions by itself
Recording consent correctly gives us evidence of what happened.
Engineering still has to check that consent at the right points in the system.
The schema makes good behavior possible.
It doesn't replace discipline.
ExtMoney is new
This describes the architecture we built and the principles behind it.
It is not yet a claim based on ten years of operating history or years of regulatory scrutiny at scale.
That's worth saying plainly.
“GDPR-compliant” still matters. It just isn't the whole question.
The lesson from the current EU-US data-transfer debate isn't that GDPR compliance suddenly became meaningless.
It didn't.
The lesson is that compliance labels alone don't tell you enough about how a finance app handles your data.
You should also be able to ask:
Where is it stored?
When does it leave that location?
Who receives it?
Why do they need it?
What happens when I say no?
How does the company make money?
Those answers describe the actual privacy architecture behind the policy page.
For ExtMoney, the goal is straightforward:
EU-hosted by default for core financial data. Subscription-funded rather than data-funded. Explicit about the places where external processing is still necessary. And a record of what you actually consented to — not just a checkbox saying that you did.
That's the standard we're building toward.
And if you want to know how any part of it works technically, ask us. We'll go deeper.