Picture the transaction file after the fact: the right customer, the right device, the right OTP, the right authentication flow, completed without error. Every control an FRM system was built to check came back clean. And the transaction was fraud — because the person completing it had been convinced, not compromised.
The Authentication Trap
Authentication answers one question: is this really the account holder? Social-engineering-led fraud makes that question almost irrelevant, because it is, genuinely, the account holder — acting on a fake support call, a fake refund, a fake emergency. The technical control was never designed to catch a customer who has been deceived into cooperating.
The Real Question
The question an FRM system actually needs to answer is different: is this really what the account holder intended? That is a behavioural question, not an authentication one — and it requires signals authentication was never built to provide: a new beneficiary used unusually fast, a device change shortly before a large transfer, a screen-sharing session active in the background, a transaction pattern that breaks sharply from the customer's own history.
How can an FRM system identify a transaction that is technically valid but behaviourally abnormal?
Authentication and behavioural risk are different questions, and a control built to answer one cannot be assumed to answer the other. The technically valid transaction is exactly where behavioural risk deserves the closest look.