The layer below does not have to protect against replay attacks. In fact solely relying on such a protection would be a security issue itself. The user could just generate the TAN here and sign the transaction.
1 transaction every ($interval * 1.5) seconds ought to be enough for most non-commercial banking users? Even if you could tie the token to a non-separable 'bundle' of transactions for larger transactions (Payroll for all staff?)
Banking IT seems to have their heads in the clouds of regulations, and risk aversion to even proven modern secure solutions.
Well, the PSD2 opens the banking to third parties (basically OAuth, just for banks).
So an approved payment initiation services (PIS) can do transactions on your behalf. But you still want to have control over which transfers they actually send, so you want to make sure the confirmation code only works for a certain transaction.
I believe this would have to be implemented by the payment initiation service provider - as far as the bank is concerned, once you authorize the PIS provider the have full access and can initiate any transfers they want.
Compromising bank servers is less harmful than compromising individual customers, because it's the bank (or perhaps the insurance) that's bearing the consequences, not its customers.
Lacks the reference to a transaction. An attacker could send unlimited transactions for 15 seconds after you approved yours.