Principle
| | | |
Member Organisations should define, approve, implement and maintain a standard for the authentication of customer, employee and third party credentials and instructions to ensure information is protected and unauthorised access or actions are prevented. This should be risk-based and utilise multi-factor authentication.
| | | |
Control Requirements
| | | |
| a. | A Member Organisation should define, approve, implement and maintain an authentication standard with input from both the Counter-Fraud Department and Cyber Security Team.
| | | |
| b. | A Member Organisation's authentication standard should consider the risks identified in its Fraud Risk Assessment and Cyber Security Risk Assessment.
| | | |
| c. | The authentication standard should consider both customer access to products and services, and employee and third party access to Member Organisation systems.
| | | |
| d. | When defining the authentication standard, Member Organisations should take note of the following Control Requirements outlined in The Cyber Security Framework:
| | | |
| | 1. | 3.3.5 Identity and access management
| | | |
| | 2. | 3.3.13 Electronic Banking Services
| | | |
| e. | A Member Organisation's authentication standard should cover both digital (e.g., online services and mobile app) and non-digital (e.g., phone, ATM and branch) channels.
| | | |
| f. | Member Organisations should adopt a risk-based approach to authentication with higher risk instructions or activity subject to multi-factor authentication before they are acted upon.
| | | |
| g. | Multi-factor authentication conducted by Member Organisations for identification or transaction verification should not solely consist of One Time Passwords (OTPs) sent via SMS. Member Organisations should implement additional factors, including but not limited to:
| | | |
| | 1. | Approval of transactions through Mobile App (e.g., sending a push notification to mobile app on a trusted device).
| | | |
| | 2. | Device characteristics (e.g., trusted/known mobile device).
| | | |
| | 3. | Geolocation (e.g., verifying location, IP address or checking mobile network).
| | | |
| | 4. | Behavioural profile (e.g., variations to usual transaction volume, value, frequency and/or currency).
| | | |
| | 5. | Biometric behavioural profile (e.g., identification of changes in the way a customer or employee uses a browser or device).
| | | |
| h. | Where an OTP is sent via SMS, the purpose, amount and merchant name should be clearly defined in line with SAMA approved notification templates.
| | | |
| i. | OTPs sent via SMS should be in the language selected by the customer on the account (e.g., Arabic, English).
| | | |
| j. | Member Organisations should define high-risk instructions or activity in the authentication standard which should include, but not be limited to:
| | | |
| | 1. | Registration process for online or mobile app product access.
| | | |
| | 2. | Activating a token on a new or additional device.
| | | |
| | 3. | Adding a credit/debit card to a digital wallet on a mobile device.
| | | |
| | 4. | Reset of security credentials following failed attempts to access phone, online or remote facilities.
| | | |
| | 5. | Logging in to digital products from a previously unknown device or location.
| | | |
| | 6. | Payments to an e-wallet or digital wallet.
| | | |
| | 7. | High risk transaction, withdrawals, or transfer of funds (e.g., exceeding pre-defined limits/thresholds, transfers large relative to overall balance or remittance/international transfers).
| | | |
| | 8. | Adding or modifying beneficiaries.
|
| | 9. | Change of account holder details (e.g., address or contact details).
|
| | 10. | Change of language used on the account (e.g., Arabic to English).
|
| | 11. | Reset of password or PIN.
|
| | 12. | Issue and activation of a new debit/credit card.
|
| | 13. | Reactivation of dormant accounts or blocked services.
|
| | 14. | A combination of activity(s) which may be indicative of fraud or account takeover (e.g., aggregated risk score following failed log-in attempts, buying gift cards, use of new device or new geolocation).
|
| k. | Member Organisations should require a third authentication factor (e.g., a phone call to the number on the account requiring verification of secure information, a physical visit to a branch, generating a token with a temporary password linked to a device, OTP) to validate an instruction when:
| |
| | 1. | A user log-in attempt to mobile and online services is detected as an anomalous session (e.g., a device ID or location is different from previously known log-in parameters, or the IP address is flagged as a risk).
|
| | 2. | A transaction is instructed from a non-trusted device to a newly added beneficiary.
|
| | 3. | An abnormal transfer rate (e.g., five transfers per hour for a retail customer) is exceeded.
|
| l. | Member Organisations should restrict activity where an anomalous session is identified to low level transactions until the organisation is able to authenticate the request originates from the genuine customer and can make the device trusted.
| |
| | 1. | Low level transactions should be defined by the Member Organisation in Fraud prevention standards (see 4.6).
|
