Payments Training Hub
Authentication versus authorisation PAYMENT OPERATIONS STARTED LIVE 01 Authentication versus authorisation - control that proves who you are before ACTIVE 02 Three authentication factors - Something you have QUEUED 03 Step-up and corporate authentication - business analyst writes these triggers QUEUED 04 Worked - Authentication passes. QUEUED 05 Authentication and authorisation failures - include insufficient funds QUEUED 06 BA requirements and audit evidence - requirement must name the factors QUEUED Authentication is the control that proves who you are before a payment is allowed to move, and it is not the same control as authorisation. Step 1 of 6 Authentication versus authorisation STARTED Authentication versus authorisation control that proves who you are before ACTIVE Three authentication factors Something you have QUEUED Step-up and corporate authentication business analyst writes these triggers QUEUED Worked Authentication passes. QUEUED Authentication and authorisation failures include insufficient funds QUEUED BA requirements and audit evidence requirement must name the factors QUEUED Authentication is the control that proves who you are before a payment is allowed to move, and it is not the same control as authorisation.
Three authentication factors PAYMENT OPERATIONS IN PROGRESS LIVE 01 Authentication versus authorisation - control that proves who you are before DONE 02 Three authentication factors - Something you have ACTIVE 03 Step-up and corporate authentication - business analyst writes these triggers QUEUED 04 Worked - Authentication passes. QUEUED 05 Authentication and authorisation failures - include insufficient funds QUEUED 06 BA requirements and audit evidence - requirement must name the factors QUEUED Something you have, such as a phone that receives a one time passcode, or a hardware token. Step 2 of 6 Three authentication factors IN PROGRESS Authentication versus authorisation control that proves who you are before DONE Three authentication factors Something you have ACTIVE Step-up and corporate authentication business analyst writes these triggers QUEUED Worked Authentication passes. QUEUED Authentication and authorisation failures include insufficient funds QUEUED BA requirements and audit evidence requirement must name the factors QUEUED Something you have, such as a phone that receives a one time passcode, or a hardware token.
Step-up and corporate authentication PAYMENT OPERATIONS IN PROGRESS LIVE 01 Authentication versus authorisation - control that proves who you are before DONE 02 Three authentication factors - Something you have DONE 03 Step-up and corporate authentication - business analyst writes these triggers ACTIVE 04 Worked - Authentication passes. QUEUED 05 Authentication and authorisation failures - include insufficient funds QUEUED 06 BA requirements and audit evidence - requirement must name the factors QUEUED 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. Step 3 of 6 Step-up and corporate authentication IN PROGRESS Authentication versus authorisation control that proves who you are before DONE Three authentication factors Something you have DONE Step-up and corporate authentication business analyst writes these triggers ACTIVE Worked Authentication passes. QUEUED Authentication and authorisation failures include insufficient funds QUEUED BA requirements and audit evidence requirement must name the factors QUEUED 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.
Worked example: EUR 28,000 payment PAYMENT OPERATIONS IN PROGRESS LIVE 01 Authentication versus authorisation - control that proves who you are before DONE 02 Three authentication factors - Something you have DONE 03 Step-up and corporate authentication - business analyst writes these triggers DONE 04 Worked - Authentication passes. ACTIVE 05 Authentication and authorisation failures - include insufficient funds QUEUED 06 BA requirements and audit evidence - requirement must name the factors QUEUED Authentication passes. Step 4 of 6 Worked example: EUR 28,000 payment IN PROGRESS Authentication versus authorisation control that proves who you are before DONE Three authentication factors Something you have DONE Step-up and corporate authentication business analyst writes these triggers DONE Worked Authentication passes. ACTIVE Authentication and authorisation failures include insufficient funds QUEUED BA requirements and audit evidence requirement must name the factors QUEUED Authentication passes.
Authentication and authorisation failures PAYMENT OPERATIONS IN PROGRESS LIVE 01 Authentication versus authorisation - control that proves who you are before DONE 02 Three authentication factors - Something you have DONE 03 Step-up and corporate authentication - business analyst writes these triggers DONE 04 Worked - Authentication passes. DONE 05 Authentication and authorisation failures - include insufficient funds ACTIVE 06 BA requirements and audit evidence - requirement must name the factors QUEUED Authorisation failures include insufficient funds, a closed or blocked account, a limit breach, and an expired authorisation. Step 5 of 6 Authentication and authorisation failures IN PROGRESS Authentication versus authorisation control that proves who you are before DONE Three authentication factors Something you have DONE Step-up and corporate authentication business analyst writes these triggers DONE Worked Authentication passes. DONE Authentication and authorisation failures include insufficient funds ACTIVE BA requirements and audit evidence requirement must name the factors QUEUED Authorisation failures include insufficient funds, a closed or blocked account, a limit breach, and an expired authorisation.
BA requirements and audit evidence PAYMENT OPERATIONS COMPLETE LIVE 01 Authentication versus authorisation - control that proves who you are before DONE 02 Three authentication factors - Something you have DONE 03 Step-up and corporate authentication - business analyst writes these triggers DONE 04 Worked - Authentication passes. DONE 05 Authentication and authorisation failures - include insufficient funds DONE 06 BA requirements and audit evidence - 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 and audit evidence COMPLETE Authentication versus authorisation control that proves who you are before DONE Three authentication factors Something you have DONE Step-up and corporate authentication business analyst writes these triggers DONE Worked Authentication passes. DONE Authentication and authorisation failures include insufficient funds DONE BA requirements and audit evidence 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 / 6:01 Step 1 of 6

Authentication: proving who you are before the money moves

Payment Lifecycle End to End, Lesson 9 of 9, Narration 6:01, D03 Payment lifecycle

AuthorisationHost to hostRefund

What you will learn

Your objective. By the end of this lesson, you will be able to explain authentication: proving who you are before the money moves. Authentication is the control that proves who you are before a payment is allowed to move, and it is not the same control as authorisation.

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 walks a payment from initiation through validation, screening, clearing, settlement, and reconciliation, and identifies the controls and failure points at each stage of the lifecycle. Learner applies this skill in realistic banking scenarios, with clear examples and correct terminology throughout.

Key learning points

  • Authentication versus authorisation
  • Three authentication factors
  • Step-up and corporate authentication
  • Worked example: EUR 28,000 payment
  • Authentication and authorisation failures
  • BA requirements and audit evidence

Key terms

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

Host to host: A direct file or API connection between a corporate customer system and its bank, used to send payment files and receive status reports.

Refund: A repayment of funds to a customer after a payment fails, is cancelled or is disputed. In card payments a refund returns money to the cardholder account.

Animated payment lifecycle showing Authentication: proving who you are before the money moves.

Practise this lesson

Exercise

A corporate treasurer instructs a EUR 28,000 supplier payment at 09:00. The account holds EUR 30,000, a EUR 500 card hold is already in place, and the treasurer authenticates with a hardware token plus a one-time code.

Authentication proves who the treasurer is. Authorisation checks whether the payment may proceed. The available balance is EUR 29,500 after the hold.

  1. What to do. State whether authentication passes, whether authorisation passes, and what the balance is after the payment. Then repeat the test with a balance of EUR 27,000.

Correct result. Authentication passes, because the token plus the code prove identity. Authorisation passes, because EUR 28,000 is within the EUR 29,500 available. After the payment the balance is EUR 1,500. With EUR 27,000, authentication still passes but authorisation fails on insufficient funds, and the customer gets a clear insufficient funds message, not a security error.

Why. Authentication and authorisation fail for different reasons and the customer message must say which one. A security error for an insufficient funds case sends the customer to the wrong team and hides the real problem.

Check your understanding

Practice question

A customer enters the correct password but the one-time code is wrong. The payment is stopped and the customer is told authentication failed. Which statement is correct?

Takeaway and next step

What to remember

It can also fail authentication and never reach authorisation, when a stolen password is used by someone who is not the customer.

Follow EUR 30,000 through every stage, from instruction to beneficiary credit, and note where it can stop.

Open the Payment Lifecycle Simulator →

Builds on "System design deep dive: how the lifecycle is built inside a bank".

Transcript and full text

Show transcript

Authentication is the control that proves who you are before a payment is allowed to move, and it is not the same control as authorisation. Authentication answers the question of identity: is the person or system instructing this payment really the account holder, or really the system it claims to be. Authorisation answers the question of permission and funds: is this payment allowed, and is the money there. A payment can pass authentication and fail authorisation, when a genuine customer with a genuine login tries to pay more than the available balance. It can also fail authentication and never reach authorisation, when a stolen password is used by someone who is not the customer. A 15-year SME must be able to explain which control failed, because the two failures have different causes, different evidence and different fixes. For a customer, authentication rests on three kinds of factor. Something you know, such as a PIN or a password. Something you have, such as a phone that receives a one time passcode, or a hardware token. Something you are, such as a fingerprint or a face match. A single factor is weak on its own: a password can be phished, a phone can be stolen, a fingerprint reader can be spoofed. Strong customer authentication under PSD2 therefore requires two factors from different categories for most electronic payments in Europe, and the bank must be able to show which two factors were used for every payment it accepted. Step-up authentication is the rule that the bank asks for stronger proof when the risk is higher. A routine 20 euro payment to a saved payee may pass with a single factor, 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 one time passcode. The triggers are business rules, and they are set by the bank's 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. Corporate authentication works differently, because the customer is an organisation and several people may act for it. A corporate payment usually needs dual approval: one person creates the payment and a second person approves it, and the system must prove that the two people are different and both authorised. Host to host corporate channels authenticate with certificates and signed files rather than with a person typing a password. The certificate identifies the corporate system, and the bank checks that the certificate is valid, that it belongs to the right customer, and that it has not been revoked. Worked example with real numbers. A customer holds EUR 30,000 and instructs a EUR 28,000 supplier payment at 09:00. The bank first authenticates the customer: the customer approves the payment in the app with a fingerprint, which is one factor, and confirms with a one time passcode, which is a second factor. Authentication passes. Authorisation then checks the available balance of EUR 29,500, after a EUR 500 card authorisation hold, and finds the EUR 28,000 is covered, so the payment is authorised and the funds are reserved. If the customer had failed authentication, the payment would never have reached the balance check. If the balance had been EUR 27,000, authentication would have passed and authorisation would have failed, and the customer would have received a clear insufficient funds message instead of a security error. Failure modes split cleanly along the two controls. Authentication failures include a wrong PIN entered three times, which locks the credential; a SIM swap, where an attacker takes over the phone number that receives passcodes; and phishing, where the customer is tricked into entering credentials on a fake page. The recovery is to lock the credential, re-issue it through a trusted channel, and review the payments made while the credential was compromised. Authorisation failures include insufficient funds, a closed or blocked account, a limit breach, and an expired authorisation. The recovery is to tell the customer exactly why, to release any reservation, and to offer a retry or a different payment method. Operations and regulation treat the two controls separately. Under PSD2, the bank must keep evidence of the authentication used for each payment, including which factors, which device and what time, because a dispute about an unauthorised payment turns on that evidence. If the bank cannot show strong customer authentication was applied, it may have to refund the customer even when the payment looks genuine. The audit trail must therefore record authentication and authorisation as separate events with separate timestamps, and a business analyst who designs a payment flow must specify both events, not just one. 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. A common design error is to write authorisation requirements that assume authentication has already happened, without stating how. Another is to treat a successful login as proof that the payment is authorised. They are separate controls, and the design must say so. Last reviewed 7 November 2026.

Authentication is the control that proves who you are before a payment is allowed to move, and it is not the same control as authorisation. Authentication answers the question of identity: is the person or system instructing this payment really the account holder, or really the system it claims to be. Authorisation answers the question of permission and funds: is this payment allowed, and is the money there. A payment can pass authentication and fail authorisation, when a genuine customer with a genuine login tries to pay more than the available balance. It can also fail authentication and never reach authorisation, when a stolen password is used by someone who is not the customer. A 15-year SME must be able to explain which control failed, because the two failures have different causes, different evidence and different fixes.

For a customer, authentication rests on three kinds of factor. Something you know, such as a PIN or a password. Something you have, such as a phone that receives a one time passcode, or a hardware token. Something you are, such as a fingerprint or a face match. A single factor is weak on its own: a password can be phished, a phone can be stolen, a fingerprint reader can be spoofed. Strong customer authentication under PSD2 therefore requires two factors from different categories for most electronic payments in Europe, and the bank must be able to show which two factors were used for every payment it accepted.

Step-up authentication is the rule that the bank asks for stronger proof when the risk is higher. A routine 20 euro payment to a saved payee may pass with a single factor, 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 one time passcode. The triggers are business rules, and they are set by the bank's 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.

Corporate authentication works differently, because the customer is an organisation and several people may act for it. A corporate payment usually needs dual approval: one person creates the payment and a second person approves it, and the system must prove that the two people are different and both authorised. Host to host corporate channels authenticate with certificates and signed files rather than with a person typing a password. The certificate identifies the corporate system, and the bank checks that the certificate is valid, that it belongs to the right customer, and that it has not been revoked.

Worked example with real numbers. A customer holds EUR 30,000 and instructs a EUR 28,000 supplier payment at 09:00. The bank first authenticates the customer: the customer approves the payment in the app with a fingerprint, which is one factor, and confirms with a one time passcode, which is a second factor. Authentication passes. Authorisation then checks the available balance of EUR 29,500, after a EUR 500 card authorisation hold, and finds the EUR 28,000 is covered, so the payment is authorised and the funds are reserved. If the customer had failed authentication, the payment would never have reached the balance check. If the balance had been EUR 27,000, authentication would have passed and authorisation would have failed, and the customer would have received a clear insufficient funds message instead of a security error.

Failure modes split cleanly along the two controls. Authentication failures include a wrong PIN entered three times, which locks the credential; a SIM swap, where an attacker takes over the phone number that receives passcodes; and phishing, where the customer is tricked into entering credentials on a fake page. The recovery is to lock the credential, re-issue it through a trusted channel, and review the payments made while the credential was compromised. Authorisation failures include insufficient funds, a closed or blocked account, a limit breach, and an expired authorisation. The recovery is to tell the customer exactly why, to release any reservation, and to offer a retry or a different payment method.

Operations and regulation treat the two controls separately. Under PSD2, the bank must keep evidence of the authentication used for each payment, including which factors, which device and what time, because a dispute about an unauthorised payment turns on that evidence. If the bank cannot show strong customer authentication was applied, it may have to refund the customer even when the payment looks genuine. The audit trail must therefore record authentication and authorisation as separate events with separate timestamps, and a business analyst who designs a payment flow must specify both events, not just one.

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. A common design error is to write authorisation requirements that assume authentication has already happened, without stating how. Another is to treat a successful login as proof that the payment is authorised. They are separate controls, and the design must say so. 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.