Authentication & Authorization

The bank's trust checkpoint for every digital and assisted action

Authentication and authorization are the controls that decide who is interacting with the bank and what that person, business, staff member, partner, device, or system is allowed to do. Authentication answers the question: are you really who you claim to be? Authorization answers the next question: even if you are genuine, are you allowed to perform this action on this account, product, company, payment, card, loan, case, or customer record?

Customers often experience these controls as login, biometrics, OTP, passkey, device approval, transaction signing, or a branch identity check. Business users experience them as roles, mandates, dual approval, maker-checker, and administration rights. Staff experience them as entitlements, queues, supervisor approvals, and audit. Partners experience them as API credentials, consent grants, scopes, certificates, and contractual access. The bank experiences all of this as one trust fabric.

Weak authentication creates account takeover. Weak authorization creates unauthorised actions even when the user is genuine. A real business administrator should not automatically approve their own high-value payments. A contact-centre agent should not reveal data without customer verification. A mobile user should not change a phone number and immediately approve a risky payment without step-up. A partner API should not access accounts outside consent. The platform must handle these situations precisely.

This chapter explains authentication and authorization in consumer and business banking from a functional implementation view. It covers identity proofing, login, MFA, passkeys, device binding, session control, step-up, risk-based authentication, entitlements, business roles, mandates, staff access, API access, consent, audit, fraud signals, recovery, testing, and production support.

Learning objectives

By the end of this chapter, you should be able to explain the difference between authentication and authorization, how registration differs from login, how MFA and step-up should be designed, how risk-based authentication works, how business mandates and maker-checker controls operate, how staff entitlements should be governed, how open banking and partner consent differ from customer login, and how audit evidence supports disputes, fraud investigations, and regulatory reviews.

You should also be able to recognise bad designs: OTP used as a universal answer, staff tools that bypass customer controls, business users with unclear mandates, API scopes that are too broad, device changes that are not risk-scored, recovery journeys weaker than login, and audit records that show an action happened but cannot prove who authorised it.

Authentication versus authorization

Authentication proves identity or control of a credential. Core authentication factors are knowledge, possession and inherence; location and behaviour can provide risk context but are not interchangeable substitutes for those factors. Passwords, PINs, passkeys, hardware tokens, mobile devices, biometrics, one-time codes, certificates, and behavioural signals can all participate. Authentication should be proportionate to risk and accessible to real customers.

Authorization decides permission. A customer may authenticate successfully but still be blocked from viewing a closed account, approving a payment above limit, changing a company mandate, waiving a fee, accessing another person's data, or initiating a product they are not eligible for. Authorization depends on customer relationship, account ownership, business role, mandate, product status, legal restriction, channel, transaction risk, staff role, and policy.

The two controls must work together. A strong login is not enough if authorization is weak. A perfect entitlement model is useless if attackers can take over credentials. Banking journeys should decide both: who is this actor, and what exactly is this actor permitted to do at this moment?

Functional authentication lifecycle

Authentication begins before first login. The bank must register the customer or user, bind credentials, verify devices, capture consent, explain responsibilities, and create recovery paths. A consumer may enrol in mobile banking after account opening. A business administrator may invite employees. A corporate API client may register certificates. A staff member may receive role-based access through workforce identity processes.

The lifecycle includes registration, credential activation, normal authentication, risk-based step-up, failed attempts, lockout, recovery, credential rotation, device change, credential revocation, dormant status, and closure. Each stage should have evidence. The bank should know when a device was enrolled, how the user was verified, which credential was used, what risk signals existed, and what action followed.

Recovery deserves special attention. Attackers often target password reset, phone-number change, SIM swap, device migration, and helpdesk recovery. A recovery journey should not be weaker than normal login. It should verify identity, use trusted channels where possible, apply cooling periods for high-risk changes, and trigger alerts.

Functional authorization lifecycle

Authorization begins when the bank defines roles, permissions, products, mandates, limits, and policies. It continues at runtime when a user attempts an action. The platform should evaluate who the actor is, what relationship they have to the customer or company, what role they hold, what action they request, what product or account is affected, what amount or risk level applies, what channel is used, what restrictions exist, and what approvals are required.

Authorization can be role-based, attribute-based, policy-based, relationship-based, transaction-based, or a combination. Consumer banking often uses relationship-based permissions: account owner, joint account holder, cardholder, guardian, power of attorney, or delegated user. Business banking requires more complex roles: viewer, creator, approver, administrator, payroll user, trade-finance user, loan user, file uploader, auditor, and relationship-manager contact.

Authorization also has lifecycle events: grant, change, review, suspend, expire, revoke, delegate, approve, deny, and audit. A business employee who leaves should lose access. A staff member who changes role should lose old privileges. A partner whose contract ends should lose API access. A dormant user may need reactivation checks.

Strong customer authentication and step-up

Strong customer authentication combines multiple factors and protects high-risk actions. It should be applied where law, policy, risk, or product requires it. Login may require one strength. A payment to a new beneficiary may require higher strength. Changing a phone number, adding a device, approving a business payment, viewing sensitive documents, or increasing a card limit may require step-up.

Step-up should be journey-aware. It should not ask for stronger authentication randomly, and it should not skip step-up for high-risk changes because the customer logged in five minutes ago. The platform should consider action type, amount, beneficiary, device, location, behaviour, recent profile changes, fraud signals, customer segment, and legal requirements.

Transaction signing is a stronger form of authorization where the customer approves specific transaction details. It should bind what the customer sees to what the bank executes: amount, currency, beneficiary, account, date, and reference where relevant. If the customer signs one set of details and the bank executes another, the evidence is weak.

Business mandates and maker-checker

Business banking authorization is fundamentally different from consumer self-service. A company may have many users, entities, accounts, products, approval rules, limits, and mandates. One user may create a payment. Another may approve. Some users may approve only up to a limit. Some may approve payroll but not international payments. Some may view statements but not initiate transactions.

Maker-checker is a common control where one user creates and another user approves. It reduces fraud and error, but only when implemented deeply. The checker must be independent where policy requires independence. The checker should see enough details to make a decision. The platform should prevent the maker from approving their own restricted transaction. Approval rules should support amount, currency, payment type, entity, account, beneficiary, file, product, and risk category.

Mandate management should be audited. Adding an approver, changing a limit, granting admin rights, or changing a company hierarchy can be more dangerous than approving one payment. Administration actions may need stronger approval than ordinary transactions. Business customers need visibility into their own audit trail, and the bank needs evidence for disputes.

Staff-assisted authorization

Staff channels require strict controls because staff can act for customers. A branch teller, contact-centre agent, relationship manager, operations analyst, fraud specialist, dispute handler, or collections user may perform actions that affect money, data, access, or customer outcomes. Staff authentication proves employee identity. Staff authorization proves job permission. Customer verification proves the customer is entitled to request the action.

A staff user should have the minimum access needed for their role. Sensitive actions such as address change, phone change, card replacement, high-value transfer, fee waiver, loan restructure, collateral release, fraud unblock, customer data export, or manual rate adjustment should require role permission, reason code, evidence, and sometimes supervisor approval.

Break-glass access should be rare and monitored. It may be needed for urgent customer harm or incident response, but it should require reason, time limit, enhanced logging, and review. A support tool should never become a hidden way to bypass product controls.

API and partner authorization

API access is authorization without a human screen. It must be tightly scoped. Open banking APIs may rely on customer consent and regulated scopes. Corporate APIs may rely on certificates, signed requests, OAuth grants, host-to-host agreements, file mandates, and IP controls. Partner journeys may use contractual access and customer consent.

A partner should access only the customers, accounts, products, data, and actions permitted by consent and contract. API scopes should be specific. A payment-initiation partner should not automatically receive broad account-history access. A broker submitting loan applications should not view existing account balances unless permitted. A payroll provider should not access unrelated company products.

API authorization should include token expiry, revocation, consent withdrawal, certificate rotation, rate limits, replay protection, audit, and anomaly monitoring. Partner access should be reviewed, and inactive or terminated partners should be disabled promptly.

Functional implementation catalogue

A world-class authentication and authorization platform is built from owned capabilities, not scattered checks in every channel. Each capability should have an owner, policy source, effective-date model, risk classification, audit record, support view, and test evidence. The catalogue below is intentionally practical for delivery teams.

Identity proofing

Identity proofing should define the actor type, eligible channels, credential or role requirement, policy owner, risk level, required evidence, failure handling, recovery path, and audit fields. Runtime behaviour should be deterministic and risk-aware: the same actor, device, role, account, company, action, amount, product, and restriction should lead to the same authentication challenge or authorization result unless a newer approved policy version applies. The platform should retain actor ID, customer or company ID, device or client ID, session ID, channel, action, policy version, result, reason, timestamp, and correlation ID.

For consumer banking, Identity proofing must balance security with human usability. Customers need safe login, accessible recovery, clear challenge wording, trusted-device visibility, alerts for sensitive changes, and support when they are locked out. For business banking, it must also support legal entities, delegated administrators, mandates, maker-checker, approval limits, file approvals, audit exports, and emergency role removal. Staff and partner versions must include least privilege, segregation of duties, monitoring, and contractual or employment lifecycle controls.

Testing should cover normal success, wrong credential, expired credential, lost device, new device, high-risk action, low-risk action, locked user, dormant user, revoked consent, expired role, exceeded mandate, self-approval attempt, supervisor approval, staff impersonation control, API token expiry, replay attempt, downstream timeout, duplicate approval, audit retrieval, customer complaint, fraud investigation, and production support repair. A capability is complete only when both the customer outcome and the bank evidence are clear.

Customer registration

Customer registration should define the actor type, eligible channels, credential or role requirement, policy owner, risk level, required evidence, failure handling, recovery path, and audit fields.

For consumer banking, Customer registration must balance security with human usability. Staff and partner versions must include least privilege, segregation of duties, monitoring, and contractual or employment lifecycle controls.

A capability is complete only when both the customer outcome and the bank evidence are clear.

For consumer banking, Segregation of duties must balance security with human usability. Staff and partner versions must include least privilege, segregation of duties, monitoring, and contractual or employment lifecycle controls.

Acceptance scenarios

Common implementation mistakes

Confusing login with permission

A user who logs in successfully is not automatically allowed to do everything. Authorization must evaluate account relationship, business role, product, action, amount, channel, and restrictions.

Weak recovery journeys

Password reset, device migration, and helpdesk recovery are common attack paths. Recovery must be at least as controlled as ordinary login.

Business roles too simple

Business banking cannot rely on viewer and admin only. Real companies need entity access, product permissions, amount limits, maker-checker, payroll separation, and delegated administration.

Staff tools bypass controls

If staff portals can perform actions that customer channels cannot, they need stronger audit, reason, and approval controls. Assisted service should not become a control bypass.

Over-broad API scopes

Partner and API access should be precise, revocable, monitored, and tied to consent or contract. Broad scopes create privacy and financial risk.

Poor audit evidence

An audit record that says approved is not enough. The bank needs who, what, when, where, under which policy, with which authentication, and for which exact action.

Best-practice principles

Separate authentication from authorization. Use risk-based step-up for sensitive actions. Keep recovery journeys strong. Model business mandates deeply. Enforce least privilege for staff. Scope APIs tightly. Preserve policy versions. Make customer messages clear. Monitor anomalies. Review access regularly. Test every high-risk journey with realistic cases. Keep evidence good enough for fraud, complaint, audit, and regulatory review.

Practical example: business bulk payment

A payroll user uploads a salary file. The user can create but cannot approve. The file enters pending approval. Two authorised approvers must approve because the total amount exceeds a threshold. One approver approves in web banking, another in mobile. The bank validates file integrity, mandate, available balance, cut-off, sanctions, duplicate file risk, and final submission. Audit shows maker, approvers, timestamps, channels, device, file hash, and policy version.

This is authorization as a business operating model. Authentication proves each user. Authorization proves each user had the correct role at the correct time for the correct company and action.

Practical example: customer device change

A customer installs mobile banking on a new phone. The bank recognises a new device and recent SIM change. Login succeeds only after stronger verification, and high-risk actions such as new payee creation are cooled for a period or require additional review. The customer receives an alert on the old trusted channel where possible. If the customer reports the device change as fraudulent, support can see the timeline.

This is authentication connected to fraud prevention and customer protection. The journey is not designed only for convenience; it is designed for trust.

Final perspective

Authentication and authorization are the bank's trust controls. They decide who enters, what they can see, what they can do, when extra proof is needed, and how the bank proves the action later. They must be strong without becoming cruel, precise without becoming impossible to use, and flexible without becoming loose.

World-class implementation treats identity, access, consent, entitlement, session, device, staff access, business mandate, and API scope as one controlled fabric. Customers feel protected. Businesses feel in control. Staff can help without bypassing rules. Partners can integrate without overreaching. Auditors can reconstruct what happened.

Standards and authoritative references

Implementations should use current official and bank-approved sources relevant to the institution, product, and market, including authentication, strong customer authentication, privacy, data protection, open banking, payment authorization, business mandates, operational resilience, outsourcing, access management, audit, fraud prevention, and customer communication requirements. Bank-approved identity policy, access policy, API security standards, entitlement model, staff access model, fraud policy, consent model, and incident procedures should be binding implementation inputs.

A valid login is not payment authority

Dev logs in successfully but can only prepare Harbour Tools payments. Noor approves a specific 25,000 supplier instruction. Release must recheck the current company mandate, account access, amount limit, beneficiary, approval content and separation of duties. If Noor's authority was revoked after approval, the earlier authenticated session cannot restore it. Persist the approved instruction version and reauthorise on the server; a hidden button is not a control.

Under NIST SP 800-63B-4, biometrics are not a standalone authenticator: they can activate a physical cryptographic authenticator. Location and behavioural signals can inform risk but do not substitute for the required authentication factors. NIST's assurance framework is technical guidance with a stated US government scope, not a universal statutory banking rule. A device biometric unlock, a phishing-resistant passkey and a bank's transaction authorisation are distinct control layers. Test recovery as carefully as login: changing a phone number must not automatically grant control of the old factor or bypass a payment challenge.