Payments Academy
Customer authentication PAYMENT OPERATIONS STARTED LIVE 01 Customer authentication - step where the customer proves who they ACTIVE 02 Strong customer authentication - under PSD2 therefore requires two factors QUEUED 03 Step-up authentication - business rules set by the fraud team from QUEUED 04 Authentication methods and trade-offs - requirement must name the method QUEUED 05 Failure modes and worked - Worked example. QUEUED 06 BA requirements - requirement must name the factors QUEUED Customer authentication is the step where the customer proves who they are to the bank before an API is allowed to act for them, and it is separate from what the API is then allowed to do. Step 1 of 6 Customer authentication STARTED Customer authentication step where the customer proves who they ACTIVE Strong customer authentication under PSD2 therefore requires two factors QUEUED Step-up authentication business rules set by the fraud team from QUEUED Authentication methods and trade-offs requirement must name the method for each QUEUED Failure modes and worked Worked example. QUEUED BA requirements requirement must name the factors QUEUED Customer authentication is the step where the customer proves who they are to the bank before an API is allowed to act for them, and it is separate from what the API is then allowed to do.
Strong customer authentication PAYMENT OPERATIONS IN PROGRESS LIVE 01 Customer authentication - step where the customer proves who they DONE 02 Strong customer authentication - under PSD2 therefore requires two factors ACTIVE 03 Step-up authentication - business rules set by the fraud team from QUEUED 04 Authentication methods and trade-offs - requirement must name the method QUEUED 05 Failure modes and worked - Worked example. QUEUED 06 BA requirements - requirement must name the factors QUEUED Strong customer authentication under PSD2 therefore requires two factors from different categories: something the customer knows, something the customer has, and something the customer is. Step 2 of 6 Strong customer authentication IN PROGRESS Customer authentication step where the customer proves who they DONE Strong customer authentication under PSD2 therefore requires two factors ACTIVE Step-up authentication business rules set by the fraud team from QUEUED Authentication methods and trade-offs requirement must name the method for each QUEUED Failure modes and worked Worked example. QUEUED BA requirements requirement must name the factors QUEUED Strong customer authentication under PSD2 therefore requires two factors from different categories: something the customer knows, something the customer has, and something the customer is.
Step-up authentication triggers PAYMENT OPERATIONS IN PROGRESS LIVE 01 Customer authentication - step where the customer proves who they DONE 02 Strong customer authentication - under PSD2 therefore requires two factors DONE 03 Step-up authentication - business rules set by the fraud team from ACTIVE 04 Authentication methods and trade-offs - requirement must name the method QUEUED 05 Failure modes and worked - Worked example. QUEUED 06 BA requirements - requirement must name the factors QUEUED The triggers are business rules set by the fraud team from observed attack patterns. Step 3 of 6 Step-up authentication triggers IN PROGRESS Customer authentication step where the customer proves who they DONE Strong customer authentication under PSD2 therefore requires two factors DONE Step-up authentication business rules set by the fraud team from ACTIVE Authentication methods and trade-offs requirement must name the method for each QUEUED Failure modes and worked Worked example. QUEUED BA requirements requirement must name the factors QUEUED The triggers are business rules set by the fraud team from observed attack patterns.
Authentication methods and trade-offs PAYMENT OPERATIONS IN PROGRESS LIVE 01 Customer authentication - step where the customer proves who they DONE 02 Strong customer authentication - under PSD2 therefore requires two factors DONE 03 Step-up authentication - business rules set by the fraud team from DONE 04 Authentication methods and trade-offs - requirement must name the method ACTIVE 05 Failure modes and worked - Worked example. QUEUED 06 BA requirements - requirement must name the factors QUEUED The requirement must name the method for each channel and each customer type, not just say authentication is required. Step 4 of 6 Authentication methods and trade-offs IN PROGRESS Customer authentication step where the customer proves who they DONE Strong customer authentication under PSD2 therefore requires two factors DONE Step-up authentication business rules set by the fraud team from DONE Authentication methods and trade-offs requirement must name the method for each ACTIVE Failure modes and worked Worked example. QUEUED BA requirements requirement must name the factors QUEUED The requirement must name the method for each channel and each customer type, not just say authentication is required.
Failure modes and worked example PAYMENT OPERATIONS IN PROGRESS LIVE 01 Customer authentication - step where the customer proves who they DONE 02 Strong customer authentication - under PSD2 therefore requires two factors DONE 03 Step-up authentication - business rules set by the fraud team from DONE 04 Authentication methods and trade-offs - requirement must name the method DONE 05 Failure modes and worked - Worked example. ACTIVE 06 BA requirements - requirement must name the factors QUEUED Worked example. Step 5 of 6 Failure modes and worked example IN PROGRESS Customer authentication step where the customer proves who they DONE Strong customer authentication under PSD2 therefore requires two factors DONE Step-up authentication business rules set by the fraud team from DONE Authentication methods and trade-offs requirement must name the method for each DONE Failure modes and worked Worked example. ACTIVE BA requirements requirement must name the factors QUEUED Worked example.
BA requirements for customer authentication PAYMENT OPERATIONS COMPLETE LIVE 01 Customer authentication - step where the customer proves who they DONE 02 Strong customer authentication - under PSD2 therefore requires two factors DONE 03 Step-up authentication - business rules set by the fraud team from DONE 04 Authentication methods and trade-offs - requirement must name the method DONE 05 Failure modes and worked - Worked example. DONE 06 BA requirements - requirement must name the factors ACTIVE The requirement must name the factors, the thresholds, the lockout rule, the recovery path and the audit record. Step 6 of 6 BA requirements for customer authentication COMPLETE Customer authentication step where the customer proves who they DONE Strong customer authentication under PSD2 therefore requires two factors DONE Step-up authentication business rules set by the fraud team from DONE Authentication methods and trade-offs requirement must name the method for each DONE Failure modes and worked Worked example. DONE BA requirements requirement must name the factors ACTIVE The requirement must name the factors, the thresholds, the lockout rule, the recovery path and the audit record.

Key points of this lesson, in order.

0:00 / 4:01 Step 1 of 6

Customer authentication: MFA, SCA and step-up

API Banking and Open Banking, Lesson 5 of 9, Narration 4:01, D10 APIs and integration

AuthorisationRetryPSD2

What you will learn

Your objective. By the end of this lesson, you will be able to explain customer authentication: mfa, SCA and step-up. Customer authentication is the step where the customer proves who they are to the bank before an API is allowed to act for them, and it is separate from what the API is then allowed to do.

Why it matters. For a business analyst, product owner or subject matter expert, the test is to state, for every channel and every payment type, which authentication method applies, what triggers a step-up, what happens when authentication fails, and what evidence is kept.

Chapter objective: Learner explains API banking and open banking, including consent, authentication, and third-party access, and writes API requirements for a payment initiation use case. Learner demonstrates this skill using realistic banking examples, explaining each step clearly and using correct terminology throughout.

Key learning points

  • Customer authentication
  • Strong customer authentication
  • Step-up authentication triggers
  • Authentication methods and trade-offs
  • Failure modes and worked example
  • BA requirements for customer authentication

Key terms

Authorisation: Approval by the issuer for a card transaction to proceed, confirming the card is valid and funds or credit are available.

Retry: Repeating a failed request or message delivery after a delay, usually with a limit on attempts and a back off period.

PSD2: Payment Services Directive 2, a European Union law that opened banking to third party providers, required strong customer authentication, and set rules for payment services.

API request and response viewer showing Customer authentication: MFA, SCA and step-up.

Practise this lesson

Exercise

A bank offers three channels: a mobile app, an online banking site, and a branch counter. For each channel, name the customer authentication method, what triggers a step-up, and what happens when authentication fails.

The lesson covers passwords, one-time codes, biometrics, hardware tokens and step-up rules. A step-up is triggered by a new device, an unusual amount, a new payee, or a high-risk destination.

  1. What to do. Write one row per channel: method, step-up trigger, failure handling. Then check that the same payment type gets the same strength of authentication on every channel.

Correct result. Mobile app: biometric plus device binding, step-up with a one-time code for a new payee or an amount above the bank limit. Online banking: password plus one-time code, step-up with a hardware token for a high value payment. Branch: photo ID plus signature, step-up with a call-back for a high value payment. Failure on any channel stops the payment before authorisation and records the attempt.

Why. A customer who can move EUR 50,000 at a branch with a signature but needs a hardware token online has found a weak channel. Authentication strength must follow the payment risk, not the channel.

Check your understanding

Practice question

A third party app wants to initiate payments from a customer account. Under open banking, which OAuth2 flow should it use, and why?

Takeaway and next step

What to remember

If the treasurer's phone was stolen and the thief tried to approve the file, authentication would fail at the fingerprint, and the payment would never reach the balance check.

Call the API described in this lesson with a valid request, then with a missing field, and compare the responses.

Open the API Playground →

Builds on "PSD2 and Open Banking".

Transcript and full text

Show transcript

Customer authentication is the step where the customer proves who they are to the bank before an API is allowed to act for them, and it is separate from what the API is then allowed to do. When a customer opens a banking app and approves a payment, the app must prove the customer is genuine. When a corporate treasury system calls the bank API, the system must prove it is acting for the right customer. If that proof fails, the API must refuse the call, even if the payment instruction itself is perfectly formed. Authentication is about identity; the permission to move money is a separate check that happens after it. Multi-factor authentication is the standard for customer authentication, because one factor on its own is too easy to defeat. A password can be phished, a phone can be stolen, and a fingerprint reader can be spoofed. Strong customer authentication under PSD2 therefore requires two factors from different categories: something the customer knows, something the customer has, and something the customer is. A banking app that asks for a fingerprint and then a one time passcode is using two factors. A login that asks only for a password is not strong authentication, and a bank that accepts it for a payment is carrying the fraud risk itself. Step-up authentication is the rule that the bank asks for stronger proof when the risk is higher. A routine payment to a saved payee may pass with the factors the customer already gave at login, but a first payment to a new beneficiary, a payment far above the customer's normal pattern, or a payment from a new device triggers a step-up: the customer must approve the payment in the app or enter a fresh one time passcode. The triggers are business rules set by the fraud team from observed attack patterns. A business analyst writes these triggers as requirements with exact thresholds, because a trigger set too low blocks genuine customers and a trigger set too high lets fraud through. The methods a bank offers matter, because each one trades security against convenience. An app push approval is fast and hard to phish, but it needs the customer to have the app installed and the phone online. A one time passcode by SMS works on any phone, but it can be intercepted after a SIM swap. A hardware token is the hardest to defeat remotely, but customers lose tokens and forget to carry them. Biometrics are convenient, but a fingerprint match is a probability, not a certainty, and the bank must set the match threshold and handle the cases where the sensor fails. The requirement must name the method for each channel and each customer type, not just say authentication is required. Failure modes split along the line between identity and permission. An authentication failure means the bank could not prove who the customer is: a wrong passcode entered three times, a locked credential, a SIM swap, or a phishing attack. The recovery is to lock the credential, re-issue it through a trusted channel, and review the payments made while it was compromised. An authorisation failure means the customer is genuine but the payment is not allowed: insufficient funds, a closed account, or a limit breach. The recovery is a clear message and a retry, not a security lockout. Confusing the two failures is a common design error, and it leaves genuine customers locked out for a funds problem, or fraudsters free to retry after an identity problem. Worked example. A corporate treasurer uses the bank API to pay 500 suppliers every Friday, worth 1.2 million pounds in total. The treasury system first authenticates the customer: the treasurer approves the payment file in the app with a fingerprint and a one time passcode, which is two factors. The API then checks that the treasurer is authorised to release a file of that size, that a second approver has also approved it, and that the account holds the funds. If the treasurer's phone was stolen and the thief tried to approve the file, authentication would fail at the fingerprint, and the payment would never reach the balance check. If the balance was short, authentication would pass and authorisation would fail, and the treasurer would get a clear funds message. For a business analyst, product owner or subject matter expert, the test is to state, for every channel and every payment type, which authentication method applies, what triggers a step-up, what happens when authentication fails, and what evidence is kept. The requirement must name the factors, the thresholds, the lockout rule, the recovery path and the audit record. System authentication, how one system proves its identity to another with OAuth2 grants, scopes, token lifetimes and certificates, is a separate topic taught in ch26s9 System authentication. Customer authentication and system authentication are different controls, and the design must treat them separately. Last reviewed 7 November 2026.

Customer authentication is the step where the customer proves who they are to the bank before an API is allowed to act for them, and it is separate from what the API is then allowed to do. When a customer opens a banking app and approves a payment, the app must prove the customer is genuine. When a corporate treasury system calls the bank API, the system must prove it is acting for the right customer. If that proof fails, the API must refuse the call, even if the payment instruction itself is perfectly formed. Authentication is about identity; the permission to move money is a separate check that happens after it.

Multi-factor authentication is the standard for customer authentication, because one factor on its own is too easy to defeat. A password can be phished, a phone can be stolen, and a fingerprint reader can be spoofed. Strong customer authentication under PSD2 therefore requires two factors from different categories: something the customer knows, something the customer has, and something the customer is. A banking app that asks for a fingerprint and then a one time passcode is using two factors. A login that asks only for a password is not strong authentication, and a bank that accepts it for a payment is carrying the fraud risk itself.

Step-up authentication is the rule that the bank asks for stronger proof when the risk is higher. A routine payment to a saved payee may pass with the factors the customer already gave at login, but a first payment to a new beneficiary, a payment far above the customer's normal pattern, or a payment from a new device triggers a step-up: the customer must approve the payment in the app or enter a fresh one time passcode. The triggers are business rules set by the fraud team from observed attack patterns. A business analyst writes these triggers as requirements with exact thresholds, because a trigger set too low blocks genuine customers and a trigger set too high lets fraud through.

The methods a bank offers matter, because each one trades security against convenience. An app push approval is fast and hard to phish, but it needs the customer to have the app installed and the phone online. A one time passcode by SMS works on any phone, but it can be intercepted after a SIM swap. A hardware token is the hardest to defeat remotely, but customers lose tokens and forget to carry them. Biometrics are convenient, but a fingerprint match is a probability, not a certainty, and the bank must set the match threshold and handle the cases where the sensor fails. The requirement must name the method for each channel and each customer type, not just say authentication is required.

Failure modes split along the line between identity and permission. An authentication failure means the bank could not prove who the customer is: a wrong passcode entered three times, a locked credential, a SIM swap, or a phishing attack. The recovery is to lock the credential, re-issue it through a trusted channel, and review the payments made while it was compromised. An authorisation failure means the customer is genuine but the payment is not allowed: insufficient funds, a closed account, or a limit breach. The recovery is a clear message and a retry, not a security lockout. Confusing the two failures is a common design error, and it leaves genuine customers locked out for a funds problem, or fraudsters free to retry after an identity problem.

Worked example. A corporate treasurer uses the bank API to pay 500 suppliers every Friday, worth 1.2 million pounds in total. The treasury system first authenticates the customer: the treasurer approves the payment file in the app with a fingerprint and a one time passcode, which is two factors. The API then checks that the treasurer is authorised to release a file of that size, that a second approver has also approved it, and that the account holds the funds. If the treasurer's phone was stolen and the thief tried to approve the file, authentication would fail at the fingerprint, and the payment would never reach the balance check. If the balance was short, authentication would pass and authorisation would fail, and the treasurer would get a clear funds message.

For a business analyst, product owner or subject matter expert, the test is to state, for every channel and every payment type, which authentication method applies, what triggers a step-up, what happens when authentication fails, and what evidence is kept. The requirement must name the factors, the thresholds, the lockout rule, the recovery path and the audit record. System authentication, how one system proves its identity to another with OAuth2 grants, scopes, token lifetimes and certificates, is a separate topic taught in ch26s9 System authentication. Customer authentication and system authentication are different controls, and the design must treat them separately. Last reviewed 7 November 2026.

Full lesson text (all scenes)

Completing a lesson updates your progress dashboard on the homepage.

Scene timestamps are estimated by allocating the narration text proportionally across the real audio length. The audio playback position is the source of truth: pause freezes the visual, seeking restores the correct scene, replay restarts the scene animation.