Authentication & Consent

Credentials, strong authentication, permissions and customer control

Three questions before an action

Authentication tests control of accepted authenticators. Authorisation checks the user's rights for an action. Consent or permission records a relevant choice, such as allowing data access or approving a payment under its applicable framework. These concepts interact but are not interchangeable.

A valid login does not give an employee unlimited business-account rights. A permission to read transactions does not permit payment initiation. Strong authentication can protect an approval process without establishing that a customer was free from deception or that every resulting transaction is legally undisputed.

Choose authenticators for the threat

Knowledge, possession and inherence are common factor categories. Evaluate compromise, independence, usability and recovery for the actual design. Two prompts are not automatically two independent factors; two passwords remain the same factor category.

NIST SP 800-63B Revision 4 distinguishes authenticator assurance and phishing resistance. In its framework, a biometric is not a standalone secret and is used with a physical authenticator. Manually entered codes can be relayed by phishing; cryptographic binding to the legitimate service can provide phishing resistance for the authentication protocol.

Passkeys may be device-bound or syncable, depending on implementation. Their enrollment, platform security and recovery still matter. Phishing resistance does not mean immunity to malware, account recovery attacks or customer-authorised scams.

Match authority to the requested action

Check role, account mandate, product permissions, limits and relevant state when applying an effect. Additional authentication may be required under law or policy. Strong customer authentication and exemptions in a particular payments regime must be assessed in that regime; they are not global defaults.

Show the relevant action details before approval. Where rules require transaction linking, preserve and enforce that binding. A changed payee or amount should not silently reuse approval of a different instruction. Record the outcome without logging passwords, codes or unnecessary biometric data.

Permission lifecycle and withdrawal

Explain the recipient, purpose, data or action scope, duration and customer control appropriate to the arrangement. Enforce scope at the service boundary rather than assuming possession of any token means full permission. Distinguish provider identity from the customer's grant.

Withdrawal should stop relevant future access through the applicable systems, including token enforcement and caches. It does not necessarily reverse a payment already executed or erase records that must be retained. Account-data access, marketing choice, account mandates and privacy consent have different lifecycles and legal bases.

Worked example: permission narrower than login

In this fictional business account, an employee authenticates successfully but has view-only access. A payment request is refused by the authorisation check. Hiding the button alone would not enforce the restriction because a direct request could still reach the API.

A separate customer withdraws a third party's data-access permission. The bank blocks subsequent covered calls and records the effective change. It checks the actual recipient and retention obligations rather than promising that every past copy immediately disappears everywhere.

Enrollment and recovery

Bind new authenticators through an authorised process, notify customers appropriately and assess suspicious changes. Recovery should not rely solely on contact details changed in the potentially compromised session. Revoke affected credentials and sessions when warranted and provide legitimate customers an effective route to regain access.

Test stolen devices, authenticator replacement, role changes, concurrent revocation and permission expiry. Measure false restrictions and recovery completion alongside security outcomes. Evidence supports investigation; it does not automatically decide liability or reimbursement.

Takeaway

Secure banking joins authentication with action-specific authority and enforceable permissions. Enrollment, recovery and withdrawal must maintain those boundaries throughout the customer relationship.

Continue to Mobile Banking Experience.