What is the difference between MFA and PSD2 dynamic linking?

How MFA and PSD2 dynamic linking solve different problems

MFA answers a who question, it reduces the chance that an unauthorised person can sign in. PSD2 dynamic linking answers a what exactly was approved question, it binds the authorisation to the specific payment amount and payee. A strong login can still be insufficient if the payment approval is not cryptographically or procedurally tied to the transaction details.

That distinction matters because payment fraud often happens after authentication, not before. If the approved transaction can be altered, replayed, or redirected without breaking the approval step, the authentication control did its job while the payment control failed. For the reader, the practical point is that these are layered controls, not substitutes.

What dynamic linking adds to the payment flow

Dynamic linking is designed to make the approval context explicit. The payer should be able to see, and approve, the amount and the payee in a way that cannot be changed without invalidating the approval. That is why PSD2 treats the approval step as part of transaction integrity, not just user authentication.

In practice, this usually means the bank or payment provider must generate a challenge that reflects the transaction details and then verify the response against those same details. The key control objective is to prevent a user from approving one payment while the system executes another. For implementation teams, the important verification question is whether the final authorisation is bound to the transaction record, not merely to the session.

Reader navigation can help here. The broader authentication side is covered in NIST SP 800-63 Digital Identity Guidelines, while payment-specific step-up and phishing-resistant patterns are often illustrated in NHIMG's MFA Guide and Passwordless and Passkeys Guide.

Why the difference matters in real incidents

Many payment and account compromises succeed because authentication is confused with authorisation. An attacker may obtain a valid session, coerce a user through social engineering, or intercept an approval flow, then change the payment context after login. If the control only proves that the user logged in, it does not prove that the user intended that specific transfer to that specific recipient.

That separation is why login MFA does not automatically satisfy a transaction approval requirement. In regulated payments, the security question is not simply whether the user was present, but whether the exact payment details were protected from substitution. The strongest implementations make tampering visible at the point of approval and reject any mismatch between the user-visible challenge and the executed payment.

This distinction is easier to see in incident patterns where valid credentials or an authenticated session still led to harmful outcomes. NHIMG's MFA Guide explains common bypass paths such as fatigue, relay and token theft, and CitrixBleed exploitation 2023 shows how session theft can skip the login step entirely. The lesson is that authentication strength and transaction binding are related, but they are not the same control.

Practitioner Guidance

What to verify: Confirm whether the payment journey re-checks the amount and payee at authorisation time, not just at login. If a user can approve through one channel and the system can execute a materially different transaction, the flow does not deliver dynamic linking.

Decision rule: Treat MFA as sufficient only for identity proof at sign-in. Treat PSD2 dynamic linking as failed unless the approval evidence is bound to the exact transaction parameters and the binding survives replay, substitution and session reuse.

Common mistake: Do not count "strong authentication" as proof of compliant payment approval. A design can be excellent for account access and still weak for transaction integrity if the approval screen, challenge, or signature does not lock to the payment details.

What good looks like: The user sees the final payee and amount, the approval is tied to those fields, and any change forces a fresh authorisation step. That gives auditors and investigators a clear trail from authenticated user to specific payment instruction.

Practitioner takeaway: Use MFA to establish who is signing in, then use dynamic linking to establish what they authorised. If those two questions are answered by different controls, do not let one be treated as evidence of the other.

Related resources from NHI Mgmt Group

• What is the difference between static and dynamic credentials?
• When should organizations transition from static to dynamic credentials?
• What is the difference between MFA and post-login containment?
• What is the difference between MFA bypass and token replay?