Fraud cases where the app, TLS, and strong customer authentication (SCA) all “work as designed”
The attacker still walks away with money. [web:30][web:34] This post is one of those cases.
A user’s iOS banking and approval apps were uncompromised in the classic sense: no credentials stolen, no TLS broken.[web:10][web:30] Instead, a fraudster used smishing plus a convincing phone call to talk the user into connecting via a “security proxy/VPN”.[web:1][web:10][web:15] From that moment, the attacker could drive the user’s already authenticated session and trigger the creation of an online debit card, which the user then legitimately approved in the approval app, believing it was a update to apple payment.[web:1][web:15][web:17]
The freshly created card was immediately used for in‑store payments in a different city (e.g., Berlin drugstores and supermarkets) while the customer normally lives and transacts around Frankfurt — exactly the sort of anomaly modern fraud engines should treat as high risk.[web:30][web:33] Technically, every authorization looked fine: same customer, same registered device, valid SCA.[web:17][web:24] From the backend’s point of view, nothing “broke”.
For us as software engineers, the lesson is simple: SCA + TLS isn’t enough if we don’t verify intent and context.[web:17][web:24][web:34]
The Real Problems
-
Session reuse without intent verification
PSD2 allows reusing authenticated sessions for multiple actions, including adding payment instruments, as long as SCA requirements are met.[web:17][web:18][web:24] In this case, the bank reused the existing session for a high‑risk action (new card) and relied on a generic SCA prompt that the attacker could socially reframe as an “update”.[web:17][web:21][web:27]