That's weird, I can login to my HealthEquity account (which contains HSA) without any issues and I don't have passkey setup. I confirmed it just now just in case.

That article does say "HealthEquity Mobile and web experience" so maybe it's just for customers who use both, I only use web.

> you agree to American terms and conditions, arbitrated by American courts.

"Designated Countries. We use the term “Designated Countries” to refer to countries in the European Union (EU), European Economic Area (EEA), and Switzerland."

"If you reside in the “Designated Countries”, you are entering into this Contract with LinkedIn Ireland Unlimited Company (“LinkedIn Ireland”) and LinkedIn Ireland will be the controller of your personal data provided to, or collected by or for, or processed in connection with our Services."

"If you live in the Designated Countries, the laws of Ireland govern all claims related to LinkedIn's provision of the Services" "With respect to jurisdiction, you and LinkedIn agree to choose the courts of the country to which we direct your Services where you have habitual residence for all disputes arising out of or relating to this User Agreement, or in the alternative, you may choose the responsible court in Ireland."

Source: https://www.linkedin.com/legal/user-agreement

I'm not sure from where you got your information.

According to AP News (https://apnews.com/article/international-court-sanctions-tru...) at least one judge had his bank accounts closed. So it's not just your own government who can debank you in Europe.

Of course in this judge's case there might still be some banks who are willing to work with him even at the risk of getting sanctioned as there weren't language in the news that he was completely debanked which I assume they would highlight if it was the case.

Personally I found Flowdock's thread model the best at least for small'ish teams (company size was <30). You can see it in action at https://web.archive.org/web/20210728031306/http://blog.flowd.... Unfortunately the company itself didn't survive. It was eventually acquired by CA which then killed it later.

(from my older comment) Essentially there is a default view which contains all messages as usual. Each message also has a symbol next to it. If it's grey message bubble, it's a message that is not tied to any thread (it can be replied to to start a new thread. Previously if no other messages have appeared on channel so far, it can be dragged & dropped to another thread). If it's colored message bubble, it's the first message in the thread. A colored arrow means it's part of the thread with that color.

This allows you to mostly just stay in default view with all of the channel's messages. As long as people are putting the messages in the thread itself, you could quickly use the colors to see which thread the message is on (color collisions did happen, but they were fairly rare). You would need to open the thread only if you needed more context or wanted to reply to it, though replying can also be done by writing to channel & dragging the message to thread.

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.