| Point | Detail |
|---|---|
| Point 1 | Passwords are the weakest form of authentication |
| Point 2 | Multi factor authentication, known as MFA |
| Point 3 | Digital certificates provide stronger authentication for systems and for some users |
| Point 4 | OAuth2 is the standard used when one application needs limited access |
| Point 5 | In practice, payment systems combine these methods into layered authentication |
Customer authentication: passwords, MFA and strong customer authentication
What you will learn
Your objective. By the end of this lesson, you will be able to explain authentication: passwords, mfa, certificates and OAuth2. Passwords are the weakest form of authentication, yet they remain common in payment portals.
Why it matters. This matters because a compliance failure is not a process error, it is a regulatory breach, a fine, or a frozen payment. The controls in this lesson are what keep the bank out of trouble.
Chapter objective: Learner explains payment security controls, including encryption, authentication, fraud monitoring, and PCI scope, and assesses the security of a payment flow. Learner applies this skill in realistic banking scenarios, with clear examples and correct terminology throughout.
Key learning points
- Passwords: weakest form of authentication
- Password: something user knows
- Extra step stops many fraud
- Certificate renewal and revocation
- It expires quickly
- Authentication review: who can authenticate, with what, for which action
Key terms
Open banking: A system where banks share customer account data and payment services with licensed third parties through secure APIs, with customer consent.
Payment hub: A central system in a bank that receives payment instructions from all channels, validates them, applies screening and routing rules, and sends them to the correct clearing system or correspondent.
pain.001: An ISO 20022 message a customer sends to its bank to instruct one or more credit transfers. It carries payment information, debtor and creditor details, amount, execution date and remittance data.
Regulatory comparison showing Authentication: Passwords, MFA, Certificates and OAuth2.
Practise this lesson
Exercise
Write the request and the expected response for the API call described in this lesson.
Use the API resources, operations and fields named in this lesson.
- What to do. Write the JSON request with the required fields, the success response, and one error response with its error code.
Correct result. A correct request has all mandatory fields, a valid idempotency key, and the right resource and operation. The success response confirms acceptance, and the error response names the field or rule that failed.
Why. An API contract is a promise between two systems. If the request is wrong, the API must reject it cleanly, not fail silently.
Check your understanding
Practice question
A payment instruction is sent with an amount of 10,000 but the receiving system records 100,000 because a decimal point was lost in a file mapping. Which control should have caught this?
Takeaway and next step
What to remember
If the answer is unclear, the authentication design needs work before the system goes live.
Run the exception from this lesson and follow the investigation to its resolution.
Open the Exception Investigation Simulator →
Builds on "The Threat Model for Payment Systems".
Transcript and full text
Show transcript
Passwords are the weakest form of authentication, yet they remain common in payment portals. A password such as Password123 can be guessed, stolen through phishing, or found in a data breach from another website. A bank that relies only on a password for a payment portal is exposed, because a single stolen password can lead to a fraudulent payment. Strong password rules help, such as a minimum length of twelve characters and a block on common passwords, but they do not solve the core problem. A password is something the user knows, and anything known can be copied or shared. Multi factor authentication, known as MFA, adds a second factor that is harder to steal. A user who logs into a corporate payment portal enters a password and then approves a push notification on a registered phone, or enters a six digit code from an authenticator app. An attacker who steals the password still cannot log in without the phone. For high value payments, banks often require step up authentication, so that a payment of 500,000 pounds needs a fresh MFA approval even if the user is already logged in. That extra step stops many fraud attempts that would otherwise succeed. Digital certificates provide stronger authentication for systems and for some users. A certificate is a digital identity issued by a trusted authority, stored securely and presented when a system connects. A payment hub that connects to SWIFT uses certificates to prove its identity, and a corporate customer that submits a pain.001 file may sign the file with a certificate. If the certificate is stolen or expired, the connection must fail. Certificate management therefore includes renewal before expiry, revocation when a key is compromised, and secure storage so that a private key cannot be copied from a shared drive. In practice, payment systems combine these methods into layered authentication. A user logs in with a password and MFA, a system connects with a certificate and mutual TLS, and an API client uses OAuth2 with a scoped token. Each layer checks a different fact, and each layer can fail safely without exposing the whole system. A security reviewer should ask who can authenticate, with what method, for which action, and what happens when a credential is lost or stolen. If the answer is unclear, the authentication design needs work before the system goes live. OAuth2 in payments follows a specific flow that a business analyst must understand. A treasury system that needs to read account balances through an open banking API does not use a password; it uses a client credential grant to obtain an access token with a limited scope, for example accounts:read, and a short expiry, often 15 minutes. The token is presented as a Bearer token in the Authorization header. When the token expires, the system uses a refresh token to obtain a new one. The scopes are critical: a token with payments:write can create payments, and a token with accounts:read cannot. A specification must state the grant type, the scopes, the token lifetime, and the refresh behaviour, because a token with too broad a scope is a security hole. Certificate lifecycle is where many API integrations fail in production. A certificate has an expiry date, and if it expires, the mTLS connection fails and payments stop. Banks have suffered outages because a certificate expired on a weekend and nobody noticed. The controls are a certificate inventory with expiry alerts at 90, 30, and 7 days; automated renewal where the provider supports it; and a runbook for emergency renewal. A business analyst should always ask for the certificate inventory, the renewal process, and the alert thresholds before signing off an integration. A system whose certificates are managed by memory is a system waiting for an outage. System authentication, OAuth2 grant types, scopes, token lifetimes and certificate rotation, is taught in full in lesson ch43s8, System authentication. This lesson covers customer authentication: passwords, multi factor authentication and strong customer authentication. The two are different controls for different actors, and a 15-year SME must be able to explain each separately. Last reviewed 7 November 2026.
Passwords are the weakest form of authentication, yet they remain common in payment portals. A password such as Password123 can be guessed, stolen through phishing, or found in a data breach from another website. A bank that relies only on a password for a payment portal is exposed, because a single stolen password can lead to a fraudulent payment. Strong password rules help, such as a minimum length of twelve characters and a block on common passwords, but they do not solve the core problem. A password is something the user knows, and anything known can be copied or shared.
Multi factor authentication, known as MFA, adds a second factor that is harder to steal. A user who logs into a corporate payment portal enters a password and then approves a push notification on a registered phone, or enters a six digit code from an authenticator app. An attacker who steals the password still cannot log in without the phone. For high value payments, banks often require step up authentication, so that a payment of 500,000 pounds needs a fresh MFA approval even if the user is already logged in. That extra step stops many fraud attempts that would otherwise succeed.
Digital certificates provide stronger authentication for systems and for some users. A certificate is a digital identity issued by a trusted authority, stored securely and presented when a system connects. A payment hub that connects to SWIFT uses certificates to prove its identity, and a corporate customer that submits a pain.001 file may sign the file with a certificate. If the certificate is stolen or expired, the connection must fail. Certificate management therefore includes renewal before expiry, revocation when a key is compromised, and secure storage so that a private key cannot be copied from a shared drive.
In practice, payment systems combine these methods into layered authentication. A user logs in with a password and MFA, a system connects with a certificate and mutual TLS, and an API client uses OAuth2 with a scoped token. Each layer checks a different fact, and each layer can fail safely without exposing the whole system. A security reviewer should ask who can authenticate, with what method, for which action, and what happens when a credential is lost or stolen. If the answer is unclear, the authentication design needs work before the system goes live.
OAuth2 in payments follows a specific flow that a business analyst must understand. A treasury system that needs to read account balances through an open banking API does not use a password; it uses a client credential grant to obtain an access token with a limited scope, for example accounts:read, and a short expiry, often 15 minutes. The token is presented as a Bearer token in the Authorization header. When the token expires, the system uses a refresh token to obtain a new one. The scopes are critical: a token with payments:write can create payments, and a token with accounts:read cannot. A specification must state the grant type, the scopes, the token lifetime, and the refresh behaviour, because a token with too broad a scope is a security hole.
Certificate lifecycle is where many API integrations fail in production. A certificate has an expiry date, and if it expires, the mTLS connection fails and payments stop. Banks have suffered outages because a certificate expired on a weekend and nobody noticed. The controls are a certificate inventory with expiry alerts at 90, 30, and 7 days; automated renewal where the provider supports it; and a runbook for emergency renewal. A business analyst should always ask for the certificate inventory, the renewal process, and the alert thresholds before signing off an integration. A system whose certificates are managed by memory is a system waiting for an outage.
System authentication, OAuth2 grant types, scopes, token lifetimes and certificate rotation, is taught in full in lesson ch43s8, System authentication. This lesson covers customer authentication: passwords, multi factor authentication and strong customer authentication. The two are different controls for different actors, and a 15-year SME must be able to explain each 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.