Under AFASA and the BSP circular, accountability shifts toward the institution when adequate authentication controls are missing. Banks that fail to put sufficient controls in place may have to reimburse customers directly, so authentication design is now a governance and financial risk issue, not only a security one.
Why This Matters for Security Teams
Weak authentication on payment or transfer flows is not just an account takeover problem. In a bank, it becomes a question of control design, customer harm, and regulatory accountability. When authentication is too easy to bypass, the institution may be treated as having failed to apply adequate safeguards, especially where fraud patterns show that stronger checks were feasible. That is why controls must be judged against both security expectations and operational risk.
NHIMG research shows that 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, a reminder that authentication failures often start long before a scam reaches the customer-facing layer. The same pattern appears in the Twitter Source Code Breach, where access control weaknesses enabled broader compromise than a single login event would suggest. For baseline control expectations, banks should align to NIST SP 800-53 Rev 5 Security and Privacy Controls and document how authentication strength maps to fraud exposure.
In practice, many security teams encounter reimbursement disputes only after a scam has already been authorised and the control gap has become a legal argument.
How It Works in Practice
Accountability usually follows the control owner, not the attacker’s method. If the bank allowed a transaction with weak authentication, the key question becomes whether the authentication design was proportionate to the risk of the transaction, the channel, and the customer profile. Current guidance suggests that banks should be able to show a layered control model: step-up authentication for unusual activity, transaction signing or confirmation for higher-risk payments, monitoring for behavioural anomalies, and rapid fraud response when signals look suspicious.
In operational terms, that means the bank should be able to prove all of the following:
- Authentication strength increases when risk increases.
- High-value or unusual transfers trigger additional verification.
- Access logs, alerts, and approval paths are retained for investigation.
- Exceptions are time-bound, approved, and reviewable.
This is also why identity and access governance matters beyond the login screen. Weak controls over credentials, tokens, and privileged service paths can create the conditions for scam authorisation even when the customer did not knowingly approve it. The broader pattern is visible in NHIMG’s Ultimate Guide to Non-Human Identities, which notes that 97% of NHIs carry excessive privileges. In banking environments, excessive privilege can turn a single authentication weakness into a transaction integrity failure. Organisations should document their control intent against ISO/IEC 27001:2022 Information Security Management so that fraud, security, and compliance teams are assessing the same evidence set. These controls tend to break down when legacy payment rails, outsourced channels, and fragmented exception handling prevent consistent step-up authentication.
Common Variations and Edge Cases
Tighter authentication often increases friction, so organisations have to balance customer convenience against fraud loss and dispute exposure. That tradeoff becomes sharper in low-value transfers, first-party fraud cases, and mobile-first banking flows where customers expect speed. Best practice is evolving, but there is no universal standard for when a password-only flow becomes legally insufficient; regulators and courts generally look at the overall reasonableness of the bank’s control environment.
Edge cases also matter. A bank may argue that a customer shared a one-time passcode, but that defence weakens if the authentication process was itself easy to social-engineer or if the bank had no meaningful transaction-level controls. Likewise, an institution can have strong perimeter security and still be accountable if its payment authorisation workflow is weak. For this reason, governance teams should treat scam authorisation as a control assurance problem, not just a customer education problem.
Where evidence is thin, teams should assume that transaction logs, authentication metadata, and exception records will decide the outcome more than policy language alone. That is especially true when weak authentication is paired with poor NHI hygiene, because secrets exposure and over-privileged service accounts can undermine the bank’s stated control posture before a scam is ever initiated.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10, CSA MAESTRO and OWASP Agentic AI Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AC-1 | Weak authentication is an access control failure that maps directly to identity assurance. |
| OWASP Non-Human Identity Top 10 | NHI-03 | Credential weakness and poor rotation can enable fraudulent authorisation paths. |
| CSA MAESTRO | IA-02 | Accountability for agentic and automated access depends on strong identity assurance. |
| NIST AI RMF | Risk governance requires documented accountability for automated decisioning and exceptions. | |
| OWASP Agentic AI Top 10 | A2 | Autonomous or tool-using agents can amplify weak authentication into unauthorised actions. |
Tighten authentication assurance and verify access decisions are risk-based and logged.
