[buzer]

Sure, but that's in connection with SARs and such (which have legal obligations are around secrecy). What I mean are the "generic" credit card payments where payment processors & banks process the personal data for things like fraud detection. That's perfectly fine legitimate interest, but that doesn't absolve them from article 14 requirements as fraud prevention doesn't have such requirements around secrecy around the fact that it even exists. They can restrict some detailed information e.g. regarding algorithm itself by relying on trade secrets, but that is different from their obligation to inform data subject that they received the information.

[disgruntledphd2]

> fraud prevention doesn't have such requirements around secrecy around the fact that it even exists

This is a tricky one, I really really dislike that accounts can be deleted with no recourse under the banner of fraud prevention.

But, OTOH, the best way to stop fraud is to prevent the fraudsters from knowing how you've detected them. It's not an easy problem.

[buzer]

So just to clarify there are two different things here:

The information that fraud detection is being performed is something that needs to be disclosed. That's what would be part of the article 13/14 (13 is when controller collects data directly from subject, 14 is when they receive it from anywhere else (including generating it themselves)) notices. It's very rare that any law would forbid giving any kind of article 13 notice, that's why banks do disclose that they process personal data for AML purposes in their privacy policies.

Article 14 itself however does allow omitting the notice in certain circumstances, but those are quite limited. Fraud detection can fit here, but usually only in the context where controllers transmit the information to other controllers regarding risky clients and such. The actual fraud detection itself is a different purpose and it's objectives are not, generally speaking, in risk just because someone knows that certain company ran the fraud detection on this transaction (since fraud detection is run on every single transaction).

The "how" is part of the second thing. That's generally more on article 15 (and 22) territory where controller could omit the information why exactly the transaction was denied (and possibly things like transaction's fraud score). I don't really like the current interpretations either (as it makes it pretty impossible to fix incorrect information) but unless CJEU gives some ruling in the issue it's unlikely that DPAs & EDPB are going to enforce some changes there.