The Monetary Authority of Singapore’s (MAS) E-Payments User Protection Guidelines set baseline protections for individuals and sole proprietors using e-payments. They are often read as a bank-account and e-wallet matter, and in some respects they are: the liability rules explicitly exclude cards. But several duties apply to card issuers, and one of them governs what a one-time passcode message must contain, which goes straight to the design of EMV 3D Secure (EMV 3DS) challenges.
Which parts of the E-Payments User Protection Guidelines apply to cards
The current Guidelines, effective 16 December 2024, apply duties to the ‘responsible FI’ for a protected account, which includes credit card, charge card and debit card issuers. But the text carves cards out of several sections:
|
Part of the Guidelines |
Applies to card issuers? |
Note |
|
Duties of the responsible FI (Section 4) |
Partly |
Only paragraphs 4.2 to 4.6, 4.10 to 4.12 and 4.14 to 4.16 apply to cards |
|
Liability for unauthorised transactions (Section 5) |
No |
Card holders benefit from liability apportionment under the ABS Code of Practice for Banks – Credit Cards |
|
Erroneous transactions (Section 6) |
No |
Excludes card transactions |
|
Dispute timelines (paragraphs 7.5 and 7.6) |
Not where the issuer resolves the dispute under card scheme rules |
Paragraph 7.8 |
The separate Shared Responsibility Framework for phishing scams also excludes credit card, charge card and debit card accounts, as banks describe in their customer disclosures.
The duty that shapes 3DS challenge messages
Paragraph 4.16 is one of the duties that does apply to card issuers. It requires the information sent in the same message as an access code to let the user identify the payment: the account (such as the account number), the recipient by name or other credentials, the intended amount including currency, and a warning not to reveal the code to anyone. The Guidelines give one-time passwords sent by SMS, or equivalent push notifications through the issuer’s app, as examples.
For a card issuer, that describes the SMS or push message used in an EMV 3DS challenge. An OTP that says only ‘Your code is 123456’ does not meet it. The message should name the merchant and the amount, identify the card, and warn the cardholder not to share the code. The Guidelines also expect users to read that content and check the recipient before completing the transaction (paragraph 3.8).
Other card-issuer duties relevant to authentication
- Do not send clickable links or QR codes by email or SMS that lead to entering access codes or making payments (paragraph 4.4).
- Send real-time notifications for outgoing transactions in line with the notification threshold, including the merchant’s trading name for purchases (paragraph 4.10).
- Provide a ‘kill switch’ that lets the cardholder promptly block further mobile and online access (paragraph 4.14).
These sit around the EMV 3DS challenge rather than inside it, but they affect how cardholders recognise and react to unexpected authentication requests.
What it means for EMV 3DS design
Issuers should review the templates behind their SMS and push challenges against paragraph 4.16, using the merchant name and amount that arrive in the authentication request. That depends on merchants sending accurate merchant names, so merchants serving Singapore cardholders benefit from keeping that field clean. Issuers moving from SMS to app approvals should carry the same content into the approval screen, and our article on regulators retiring SMS OTPs explains why that shift is happening elsewhere.
Frequently asked questions
Do the E-Payments User Protection Guidelines apply to credit cards?
Partly. Some duties of the responsible FI apply to card issuers, but the liability apportionment for unauthorised transactions does not. Card holders rely on the ABS Code of Practice for Banks – Credit Cards for that.
Does the Shared Responsibility Framework cover card fraud?
No. Credit card, charge card and debit card accounts are excluded from the Shared Responsibility Framework.
What must a 3DS OTP message contain for a Singapore cardholder?
Under paragraph 4.16, information identifying the account, the recipient, the intended amount including currency, and a warning not to reveal the code.
Do the Guidelines require card issuers to stop using SMS OTP?
No. They regulate what accompanies the code, not the channel. SMS and app push messages are both given as examples.
Do the Guidelines apply to business cards?
Protected accounts are held by individuals or sole proprietors. Accounts of companies fall outside that definition.
Designing compliant challenges
GPayments’ ActiveAccess is an Access Control Server for issuers and issuer processors. To review how your challenge messages and flows serve Singapore cardholders, contact GPayments.